Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Problem Solving Big Projects with Alexandra Waite
52:16 with TreehouseThis talk provides beginner programmers an essential view of how to tackle big projects, the importance of reading code, examining the error stack, and more.
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
Welcome to Sessions, y'all.
0:04
I'm Toni again.
0:05
Hope y'all are having a great time.
0:07
Well, our next speaker is
a Bay Area local, Alexandra.
0:09
I'm sorry, Alexandra Waite, or Alex,
has gotten into coding with a friend
0:15
told her that it's possible to become
a software engineer without a degree.
0:20
And she probably said, what?
0:25
So now she's here to
tell you about her story.
0:28
So she joined a coding boot camp to
embark on a journey that led her to
0:30
working as a software engineer at Pandora,
0:34
where she is continuing her
professional development.
0:37
Please welcome Alex.
0:41
>> Hi, thank you so much.
0:45
[LAUGH] Awesome.
0:47
So one moment while I share my screen.
0:49
Awesome, so here we go.
0:55
[COUGH] Hi, everyone.
0:58
And thanks for coming today.
1:01
My name's Alex Waite, and
I'm a software engineer at Pandora Media.
1:02
And I'm currently living in Huichin,
also known as Oakland,
1:07
California, on occupied
Chochenyo Ohlone land.
1:12
Today, I'm gonna talk about some knowledge
I've picked up over the last couple
1:16
of years working at my job and
problem solving through some big projects.
1:22
And please double tap this portion of
the presentation to make it larger
1:27
on your screen.
1:32
So first off for the agenda,
1:36
we're gonna go over some common
architectural patterns for projects and
1:38
then go over how you can utilize them
to identify your project's pattern.
1:43
Then we'll go over
the importance of reading code,
1:50
how to best navigate code,
some problem-solving techniques, and
1:54
common pitfalls leading
to problems in projects.
1:58
And then at the end,
we're gonna have some time for Q&A.
2:03
All right, so let's start with
application architecture and
2:09
how knowing it can really help
you out with problem solving.
2:13
App architecture is used
to define the skeleton,
2:21
the high-level components of a system,
and how they all work together.
2:24
An architectural pattern is
a general reusable solution for
2:31
a commonly occurring
problem in your software.
2:34
Identifying and understanding your
project's architectural pattern will help
2:38
you to navigate the project and allow you
to work more quickly with more confidence.
2:43
As new features are added,
2:50
it will be clear which part of
the architecture needs to be modified.
2:52
And you and your teammates will then be
able to work together on different parts
2:56
of application at the same time and
with ease.
3:01
And here's some common
architectural patterns.
3:07
Up first we have MVC, or
Model-View-Controller, and
3:11
it's probably the most well-known
architectural pattern.
3:14
Because of this, we're gonna go into more
detail in this pattern in the next slide.
3:18
But in your own time, check out some of
these other architectural patterns and
3:23
read more about them, as you're
likely going to encounter various
3:28
flavors of them throughout your career.
3:31
So Model-View-Controller, or
MVC, one of the most widely
3:37
used architectural patterns in web and
app development.
3:42
Here, the model represents the structure
of the data in your project and
3:49
how it's stored.
3:53
On a client-side project,
the model can be a Redux store.
3:56
This code can hold raw data or define the
essential components of your application.
4:01
So for example, if you're building
a to-do app, the model would define what
4:08
a task is, and what a list is, since those
are the main components of that app.
4:13
And then the view.
4:20
The view is the user interface,
and it makes up components and
4:21
functionality that a user interacts with.
4:25
Views utilize the model and present
data in a form that the user wants.
4:29
And finally, the controller.
4:35
The controller acts as a connector
between the view and the model.
4:37
It receives user input via this
user action from the view and
4:42
then translates that input
to grab data from the model,
4:47
which then passes that
data back to the view.
4:51
And here's an example file structure
we can break down to determine its
5:00
architectural pattern.
5:05
I found this nicely organized
project on goodfirstissue.dev,
5:08
which is a site that provides easy issues
for your first open source contribution.
5:12
So this example is an app called
Guppy that helps beginners build
5:18
React applications.
5:22
It provides a graphical user interface for
common React tasks,
5:24
like creating new projects and
running a development server.
5:28
It's an electron app,
meaning it's a desktop application written
5:33
with web technologies such as React and
Redux.
5:38
I really like how the directories in
this project are clearly named and
5:43
grouped by type.
5:47
All of the app code lives
in this source directory.
5:49
Then, within this source directory,
there's a directory for
5:53
components, reducers, services, and etc.
5:57
But here we don't see files or
folders specifically named model,
6:03
view, or controller.
6:08
And this goes to show that it's often
not immediately clear what a project's
6:10
architectural pattern is based off
the names of the directories and
6:15
the files alone.
6:20
But with some knowledge of React and
Redux,
6:22
we're able to work out how these
translate to the MVC pattern.
6:25
In this project,
the actions serve as a controller, and
6:30
they fire actions here in
this actions directory and
6:35
handle that logic here in
the reducers directory.
6:39
And then the Redux store is
the model in this project,
6:45
since it holds all of the app's
data here in this store directory.
6:48
Finally, React is the view
layer of this project.
6:55
And React views are generally gonna be
located in a components directory here.
6:59
So with this understanding of the various
components of our project and
7:05
how they relate to each other,
7:10
it helps us in developing our
understanding of the codebase as a whole.
7:12
Once we've identified the architectural
pattern of the project to use as a guide,
7:20
the next important piece that
will help us problem solve big
7:25
projects is actually reading the code.
7:29
Reading code is the vast majority
of a software engineer's job.
7:34
And being able to read code is just
as important, if not more important,
7:38
than being able to write code.
7:43
It fosters familiarity and
comfort with a codebase.
7:45
When reading code,
7:49
you start to pick up on the styles of the
developers working within that project,
7:50
allowing you to adopt and then continue
that style when contributing to the code.
7:55
Making it easier for
the next contributor to follow.
8:00
The more code you read, the easier it
gets to understand other people's code.
8:05
You also get faster at it, and
8:10
this makes the entire process of
coding more fun and more enjoyable.
8:12
Trust that understanding and
8:19
skill will develop over time with
continued practice and effort.
8:21
And now here's some tips for
some more constructive code reading.
8:29
Tip number one, just concentrate on
a general understanding in the beginning.
8:36
Skim the project at first to
get a rough overview, but
8:42
if you try to understand each and
every piece before moving on to the next,
8:45
you'll get lost and
bogged down in the details.
8:50
So don't focus too much on
the implementation details early on.
8:54
The first thing you wanna
get is a high-level
8:58
general understanding of what
the code is trying to do.
9:01
A text editor feature that I use
to make this process easier and
9:06
less overwhelming is code folding.
9:09
By folding the code within a function or
a method, I'm able to hide all of
9:13
the nitty-gritty details and
only show the names of those functions.
9:18
This way, I'm taking in only the relevant
information that I need to get an idea of
9:24
what the code's doing.
9:29
I can always expand code when
I wanna go in more depth.
9:32
But this process helps me to stay
conscious of not going down a rabbit hole,
9:36
since that can be really easy for me.
9:40
And tip number two, run your project and
9:44
interact with it as a user
to see how it behaves.
9:48
And to better inform your understanding
of how the code is functioning.
9:52
Try out different use cases and
explore all of its features.
9:57
Then choose a part of that project, and
then dig into that part of the code.
10:02
Many start with the project's entry point.
10:08
This could be a main function,
or a controller, and
10:10
then follow how the code
branches out from there.
10:13
For me, I generally start with
the view portion of the code.
10:17
I pick a user action, or
a view that interests me.
10:22
And then I find it in the code, and
see how it's implemented there, and
10:25
figure out how it displays the data.
10:30
Then from there, I'll see how the
controllers are manipulating that data.
10:34
And then I can move on to the model layer.
10:38
Tip number three,
while digging in and exploring code,
10:44
just try to focus on one piece at a time.
10:48
Make it a goal to understand one piece,
just enough before moving on to the next.
10:52
Utilize documentation to improve your
understanding of the code as you're
10:58
reading it.
11:03
In addition to documentation, you should
pay special attention to the comments in
11:05
the code whenever you run into them.
11:10
Comments are there for a reason.
11:13
And it's usually because it isn't
immediately clear what the code is doing,
11:15
and it needs additional context.
11:19
Git commits are another
extremely helpful way, and
11:22
form a documentation explaining
why each line of code was added.
11:26
So make good use of git blame
as you're reading through code,
11:32
through better insight.
11:36
And reading and processing code
drains a lot of mental energy,
11:42
so it's important to be cautious
conscious of taking breaks.
11:45
Too often, I find myself hitting a wall in
my understanding hours into working, and
11:50
then I reach a point where I
realize I've just hit my limit.
11:55
And I'm not gonna do my best work, or
11:58
improve my understanding by reading a line
of code over and over with a headache.
12:00
So please remember to take
breaks throughout the day.
12:06
For me, breaks could look like having
a snack, doing a workout, going outside,
12:10
or listening to music, whatever feels
like it fills me up and recharges me.
12:16
These may vary in length, but generally,
the longer the break, or the more
12:22
fulfilling the activity, the fresher I
feel when I come back to the screen.
12:27
And if you don't take my word for
it on the importance of reading code,
12:35
you can take software expert Robert C
Martin's, the author of Reading Code.
12:39
Reading code isn't always
the most fun activity.
12:45
But it gets easier over time.
12:48
And we can take solace in knowing
reading code makes it easier to write,
12:50
in turn, making us better programmers and
problem solvers.
12:55
Keeping these tips in mind, and using
them as a guide, please don't feel bad
13:01
when you find yourself in the weeds,
or down a rabbit hole.
13:06
Don't expect it to be a linear process,
and
13:10
don't expect to understand
everything fully.
13:13
Remember, code bases can take months, or
13:17
even years to become familiar with,
so give it time.
13:20
Now, let's go over some
ways to best navigate code.
13:28
It's important to dedicate time to
learning how to quickly and efficiently
13:35
navigate large projects to help you
problem solve them, and level up in them.
13:40
We'll cover some tools for optimizing
productivity while doing this work.
13:45
Learn and implement shortcuts for
common development tasks in your editor,
13:54
or any other applications related
to your projects development.
13:59
These are some of my favorite
shortcuts and snippets on a Mac.
14:06
For Windows, you can generally
replace the CMD key with the CTRL key.
14:10
In VS Code, I use Shift+CMD+K
to delete an entire line, or
14:15
highlighted section without having
to hold down the backspace key.
14:19
CMD+P opens an input box for
me to type in the name of the file,
14:24
and go straight to that file.
14:29
Shift option up or down copies whatever
line your cursor is currently on,
14:31
and places that above or below the code
without having to copy and paste.
14:37
Ctrl+G takes you to a specific line.
14:43
CMD+D lets you select the variable name or
a piece of code,
14:47
and then find every match of
that selection in a file.
14:52
CMD+Shift+F allows you to
search an entire project.
14:56
And then we have one of
my favorite snippets.
15:01
And a snippet is essentially
an alias you create for
15:04
any code you want to run,
without having to type it out.
15:07
So I use this one a lot, clo tab.
15:12
It creates this pre-written
console log statement,
15:15
allowing me to type what I wanna log,
and then a message describing it.
15:18
I also updated my OS keyboard settings,
this key repeat and delete until repeat,
15:25
so that my cursor travels extremely
fast when I navigate an editor, or
15:31
a terminal with my keys.
15:36
Here's some ways to implement shortcuts or
snippets.
15:41
Shortcutfoo was something I used when I
started programming to practice shortcuts.
15:45
It gamifies learning shortcuts for various
text editors, apps, and the commandline.
15:51
You can also search for extensions in
your editor for whatever language or
15:58
framework that you use the most.
16:02
I google shortcut cheat sheets for
all of the applications that I use, and
16:05
then I bookmark those for easy reference.
16:10
Workspace organization applications
offer a great way to utilize shortcuts,
16:13
and to boost productivity.
16:18
You can use apps to organize your
workspace, like Spectacle or Magnet.
16:21
You can also make your own shortcuts and
snippets in your editor, or
16:27
your operating system.
16:31
I use Hammerspoon,
which allows you to create shortcuts for
16:33
window organization, and
lots of other OS automation tasks.
16:37
Now problem solving.
16:46
Now that we've identified some
architectural patterns, and
16:50
how to best read and navigate code,
16:54
we can dive deeper into the logistics
of actually problem solving code.
16:56
When coding, you're inevitably
going to run into errors.
17:04
This will happen at all
stages of your career, so
17:08
it's crucial to get comfortable with them.
17:10
This is something I struggled
a lot with starting out,
17:14
because it felt like every
error was a failure.
17:17
It seemed like the majority of my
coding time was spent hitting errors,
17:21
rather than having my code
actually runs successfully.
17:24
But over time, you realize that this
is expected and totally normal.
17:29
So getting comfortable with errors
makes the process of coding a lot
17:34
less frustrating.
17:38
Let's get more familiar with errors, and
17:40
then go over how we can utilize
them to help us problem solve.
17:42
The two types of errors you're likely
to encounter are compile time and
17:49
runtime errors.
17:54
Compile time errors are caught early.
17:56
And they're often syntax errors, like
missing a parentheses call in a function,
17:59
IDs, and some text editors
with syntax highlighting.
18:04
Highlighting and
18:09
linters will often alert you of
compile time errors as you write code.
18:10
Otherwise, they'll get triggered
when you try to run the code.
18:15
Runtime errors are errors your code
encounters when the code is running.
18:19
You'll know you've had a runtime error
when you encounter an error message and
18:24
a stack trace.
18:28
This can show up in your browser console,
in your terminal, your IDE, or
18:30
in your logs.
18:35
An error stack trace is a printout
of information about the call stack
18:39
at the time the error occurred.
18:44
Since our errors will often show up
with a message and a stack trace,
18:46
we wanna be sure we
understand their structure.
18:50
So what is a call stack?
18:56
You can think of a program as pushing and
popping methods from a stack.
19:00
This stack is known as the call stack.
19:05
Whenever there's a function call,
19:09
you can visualize it being
pushed on top of the stack.
19:11
And after it finishes running, it then
gets removed, or popped from the stack.
19:15
When no methods are left
in the call stack,
19:20
that means the program
has finished running.
19:23
And understanding code as a stack helps
us make sense of an error stack trace.
19:26
An error stack trace shows you each
line of code that your program's called.
19:35
Somewhere in that stack of calls,
an error was triggered, and
19:41
the system was unable to continue
popping items off of the stack.
19:45
So let's take an example.
19:50
Here, we can start by reading
the error message this provides.
19:52
Type error dB101 is not a function.
19:56
Now we can move into the stack trace.
20:01
Generally, the cause of the error is going
to be coming from this first line in
20:04
the stack trace.
20:08
A lot of the information below
this line isn't really helpful,
20:11
because you didn't run much
of this code knowingly.
20:14
It happens at a lower level.
20:18
Each line includes a variable name,
the file paths, and then a line number.
20:21
So we can go and examine in our code
using these to devise a solution.
20:29
I recognize the variable name here,
this getCityById.
20:36
So I can go to the line 17 here
in this cities_js actions file.
20:40
Now that I've isolated where
exactly the error is coming from,
20:48
I can return to the message.
20:51
I didn't write this function
from scratch though.
20:55
It's coming from this external DB library.
20:58
Since it's complaining
it's not a function,
21:02
I can go through a checklist in my head,
and figure out why that is.
21:05
Did I misspell it somehow?
21:10
Yep, yeah, this method, one or none.
21:13
It's supposed to be one or none, [LAUGH]
but I misspelled it here and forgot an n.
21:17
And while this is a fairly minor error,
it's a common one.
21:24
And having a process in place
helps us to solve it quickly.
21:29
Sometimes the stack trace is referencing
code you wrote, like it is here,
21:34
but that's not always the case.
21:39
Sometimes the most nebulous stack traces
are those in which the error was caused by
21:42
a third party library.
21:47
If this is the case, still try to do your
best to read through the stack trace, and
21:49
reason about what part of
the code broke and why.
21:54
Now that we're familiar with errors and
their stack traces,
21:58
we can look into more
tools to help debug them.
22:02
Logging and printing.
22:08
Logging print statements are a perfectly
valid practice for debugging.
22:10
As a JavaScript developer, adding console
logs is a very common way to debug.
22:15
Print statements can be used
similarly in other languages.
22:21
It's a good practice to add
a descriptive string to the log, so
22:26
you can easily find it among your output.
22:30
The limitation though with log and
print statements is that developers
22:33
need to deliberately select
which information to log.
22:38
Which can result in a lot of trial and
error, as well as leave out the program's
22:42
bigger picture, Googling the error.
22:46
Looking up the error on Google is always
the go-to option that offers helpful
22:53
results more often than not.
22:58
When googling your error,
try to keep it generalized, and
23:00
include only the keywords in the error.
23:03
Try to leave out specific variable names
from your code, or details related to
23:07
your local machine, as they might prevent
the most useful results from appearing.
23:11
It can also be helpful to include the
framework, or the library you're using,
23:17
and the search term,
if the error is not library specific.
23:23
I'm sure many of you have already had
plenty of practice googling errors.
23:28
And that's something you're gonna
continue throughout your career,
23:32
as you're constantly learning and
keeping up with technologies.
23:36
So refining the skill will come with time,
and
23:39
you'll develop a practice
that feels best for you.
23:42
I generally start with copying
the base error message, and
23:47
I try to keep it as short and
specific to the error as possible, but
23:51
not too specific to my particular code.
23:55
And I include the associated language or
library if necessary.
23:59
And depending on the caliber of results,
I'll continue editing that search to
24:06
either be more or less specific, maybe
adding quotations to parts of the error
24:10
that I absolutely want to see results for
until I find the most useful result.
24:15
If the error is specific to my
company's proprietary software,
24:21
instead of googling first,
I'll utilize the same process, but
24:25
search the error in our
communications channel.
24:29
There have been plenty of times where
doing this unblocked me right away, and
24:33
then saved me from going down a googling
path that likely wouldn't have helped.
24:38
Debuggers, debuggers solve the pain
points of printing and logging,
24:47
by allowing developers to walk through
a program step by step as it's running,
24:52
and stopped to examine variables
with more fine tuned control.
24:57
Doing this allows you to see a variables
are assigned to their expected values,
25:03
and to go through the programs flow, and
ensure that it's executing properly.
25:08
There are many ways to use a debugger.
25:14
If you're running JavaScript,
you can use the inspector and
25:17
set break points as your code runs in
the browser, like in this example here.
25:20
If you're in an IVE, or a text editor,
you can set break points in
25:26
the code before running your
code to utilize the debugger.
25:31
And tests,
25:39
tests serve as documentation to understand
the intent behind code in your project.
25:40
Reading through existing tests in parts of
the code base where your problem solving
25:47
can help you to understand
the codes expected behavior, and
25:52
hopefully provide some clarity for a fix.
25:55
After resolving an issue,
be sure to update us to account for
25:59
the bug you fixed.
26:03
And if there aren't any tests, then add
them for the person coming after you.
26:06
If none of the previous methods help you,
you can always ask for help, or
26:14
request a pairing or knowledge share
session with a teammate on the project.
26:19
When asking for help, be sure to provide
as much relevant information as possible.
26:25
Include the technologies you're using,
the version numbers,
26:31
the error in the stack
trace you encountered, and
26:35
all the steps that you've exhausted
already in trying to debug it.
26:38
This is easier said than done,
26:44
especially as a new programmer
coming into this field.
26:46
Asking for help has been one of my biggest
struggles, because it requires a lot
26:50
of vulnerability in admitting your
struggles, and what you don't know.
26:55
And it opens up the potential for
judgment.
27:00
But the reward of overcoming that fear and
getting unblocked is always worth it.
27:04
You may be surprised to learn that others
more senior than you had gone through
27:11
the same thing.
27:15
Doing this publicly also helps
those who come after you, and
27:17
encounter the same error in the future
by reducing hardship on their end.
27:21
So you can also think of
it as paying it forward.
27:27
And finally, I'll go over some common
pitfalls that I've encountered when
27:34
working in problem solving and
large projects.
27:38
Misspellings, a very common source of
error is the result of misspellings or
27:44
small typos, especially early on.
27:50
Like what the error stack that I shared
earlier, sometimes I'll get an error, and
27:54
then I get lost in
the stack trace details.
27:59
And I don't catch on a first glance
that maybe one letter's off,
28:01
and then causing my code to go haywire.
28:06
And it sends out either the package that
incorporates a spell check in my code to
28:10
save me from these issues in the future,
which I highly recommend.
28:14
Also, make good use of your
projects linting setup.
28:19
Having clear style rules defined, and
28:23
then utilizing a linter extension in
your editor can save you time and
28:26
trouble by showing you typos and
syntax errors as you're coding.
28:32
And they can fix them for
you by simply saving the file.
28:37
Version issues, when working on a project,
28:44
be sure to thoroughly read the readme,
or documentation for development setup.
28:47
And ensure you're using the correct
versions of libraries and
28:53
packages specified in the project.
28:57
Version issues have been one of the most
common source of errors for me, and
29:00
often trigger cryptic errors from deep
within libraries that aren't clear
29:04
about how they relate to my code.
29:08
Usually, if I encounter errors like this,
before going to Google,
29:11
I check if all of my versions I'm
on are compatible with the project.
29:16
Many times, the versions of libraries
on my local machine might have diverge
29:21
after some subsequent installs,
without my knowledge.
29:26
Or I forgot to activate and
run the project in a virtual environment.
29:31
And that environment is the one that
contains the appropriate versions.
29:36
Undefined variables,
in JavaScript, look out for
29:44
undefined variables which
can throw runtime errors.
29:48
These are generally easy to catch,
but they can happen often.
29:53
For example, if a value didn't come back
from an API call that you were expecting
29:57
Or you're pulling data, or a property
from an object that doesn't exist.
30:03
Environment variables, sometimes you
may have a bug where the environment
30:12
variable you need to get
data isn't being set.
30:17
For example, the API key
variable you need isn't set, or
30:21
the application is maybe trying to pull
a URL from a certain environment variable.
30:25
And that's not being set,
or the secret key, or
30:31
some key you need to grab
sensitive data isn't being set.
30:34
Missing these values in your environment
variables, or having them change, and
30:40
then being out of date with
them can cause errors.
30:44
So if you're running into errors making
API calls, or trying to retrieve data,
30:47
checking the state of your environment
variables is always a good call,
30:52
especially if you've been scratching your
head and trying to debug for a while.
30:56
To wrap up, we've gone over identifying
a project's architectural pattern,
31:05
the importance of reading code,
and how to read code.
31:11
Code navigation,
some debugging techniques, and
31:15
common culprits for errors, and
31:19
apply these guides in a way that feels
best for you in any order you wish.
31:22
None of these are set in stone,
but they're all useful for
31:28
leveling up your knowledge in
a project and problem-solving skills.
31:32
It's important to acknowledge that
coding is a journey with ups and downs,
31:37
and developing these skills takes time.
31:42
Please be gentle with
yourselves when it gets hard.
31:46
Trust that you'll get more comfortable
with the unknowns over time,
31:49
and take solace in the fact
that you're not alone.
31:53
We're all on the same journey together.
31:57
And there's guaranteed someone is in
those same position as you are right now.
32:00
Wherever you are right now is perfect,
and it's exactly where you need to be.
32:06
Thank you so much for coming to my talk,
and thank you to treehouse for having me.
32:11
It's an honor to be here.
32:15
And I'll now open it up to some questions,
if there are any.
32:17
Okay, great, pulling up Q&A.
32:24
Okay, from Prashant, can you please
explain that last snippet part?
32:31
How would I do that?
32:38
Let's go back here to the snippets slide.
32:39
Yeah, so again, depending on your IDE,
or a text editor,
32:48
it's likely to have a lot of
extensions where you can search for
32:53
either an extension, or a plugin.
32:58
And just search whatever language.
33:01
Or maybe if you're using react,
33:03
the framework that you're using
in a project, essentially,
33:06
you can just search any of
the technologies in your project in
33:12
an extension search, and then look for
any snippet applications.
33:17
So for me, I don't remember the exact
name of the extension package,
33:23
but I just looked up JavaScript.
33:29
And it was one of the first
extension results, and
33:31
they have so
many useful snippets like clo,
33:36
where you just hit this with tab,
and then it puts a cursor
33:40
on both the log message, and
whatever you want to log.
33:46
And you can just go right in there,
33:51
plus lots of other useful ones,
like just a console log, or
33:54
importing a file once to react,
just to set up a component.
33:59
There's so many.
34:05
But yeah, they have ones that
are premade for you like this.
34:06
Or you can dig in more into your text
editor settings, and be able to update.
34:11
There should be a snippets file where
you can create your own shortcuts,
34:17
or snippets even similar to these.
34:22
You can essentially make a short cutter
snippet for anything you do in a project.
34:25
And it will generally be in some sort
of settings, or configuration file, and
34:30
there are plenty of tutorials online.
34:35
I literally Google [LAUGH] how do I
create my own snippet in my text editor?
34:38
And there's plenty of tutorials that step
by step walk you through how to do it.
34:43
So yeah, hopefully that
provides more insight there.
34:51
And let's see, from Roberto, does stack
tracing run top bottom or bottom top?
34:58
Excellent question.
35:05
So yes, for stack traces, you're gonna
look at them from top to bottom.
35:08
The error, whenever the stack trace
appears, and your program's in error,
35:17
the top line is where the error
was encountered in your code.
35:24
So here, it ran the code, and
35:30
then when it got to this get city by
a D function in my travel project,
35:32
it encountered the error
here within that function.
35:38
And again, gives you all of this
useful info, like the line number,
35:44
the character count on that
line where exactly it happened.
35:48
So always start with the top.
35:53
And then if it's useful, sometimes
it's useful to continue reading below.
35:55
Essentially, the stack
trace gives you a better
36:02
idea of the program when
this error occurred.
36:07
So it ran this function, and
36:13
this function was called
within this function.
36:16
And again,
kind of having this visual helps me a lot,
36:22
cuz you can think of as okay,
this program is the main call.
36:27
And then after the program is called,
36:34
the first function called
is this print square.
36:36
Then that gets on top.
36:40
And then inside print square, we called
square n, so that gets put on top.
36:42
And so you can just think the concept
of call stacks use Last In,
36:49
First Out, so whatever call is on
top was the last call that was made.
36:55
And then once that call finishes,
it gets popped off.
37:04
So that might be a little helpful
visual to keep in mind when you
37:08
run into an error stack trace,
can be okay, this is the top of the stack.
37:13
So this was the last function
called in my program.
37:20
And if this program were to
have continued running without
37:24
any errors,
then this would have been popped off.
37:29
And then these functions would all
continue getting popped off until there
37:34
aren't any more left, and
that means your program ran successfully.
37:38
So yeah, hopefully that was a bit useful.
37:43
And then Paula asked,
37:48
do you import or install a debugger?
37:51
This generally varies.
37:56
But I'm not sure if you necessarily
need to install the debugger.
37:59
I believe it's generally accessible
within whatever environment
38:07
that you're developing your project in.
38:11
So for example, again,
yeah, if you're working
38:15
on a web application, or using JavaScript,
38:20
an easy not having to get two
set up in a debugger option
38:25
is exploring your console
in the web browser.
38:30
And if you open up the developer tools,
oops, this is Firefox.
38:36
But Chrome and
38:43
other browsers have debugger located
somewhere within the developer tools.
38:44
And can easily Google how to utilize them,
and
38:51
there's usually plenty of
step-by-step tutorials for that.
38:54
But yeah, they live somewhere in
your developer tools in the browser.
39:01
And then from here,
you can just step into your code,
39:06
and then set these breakpoints,
wherever you want the code to stop,
39:12
and then be able to sort
of analyze each variable in
39:18
this call stack as you run
the code on a browser.
39:23
But yeah, there's also a debugger
available in node that you get for free.
39:28
So I don't believe you
necessarily have to install it.
39:37
It's just a matter of finding a tutorial,
and
39:40
figuring out how to get that set up, and
configured for your specific project.
39:43
And I use VS Code.
39:49
VS Code has the debugger built in as well.
39:51
So no importing necessary,
I just again There may be some things
39:56
you have to connect to that are specific
to your project to make best use of it.
40:02
And they're available.
40:08
And I think,
most if not every other text editor,
40:10
definitely available and
IDEs like IntelliJ, Eclipse.
40:14
And then, full disclosure, [LAUGH].
40:19
I'm definitely not a debugger expert,
I use them occasionally.
40:23
But honestly, I'm able to get by
mostly from using console log or
40:28
print statements when developing and
debugging.
40:33
Awesome, and then, Paula again.
40:37
How long should you wait for
until you ask for help?
40:43
This is a good one, definitely subjective.
40:46
I've had mentors or people recommend,
waiting a super short time,
40:51
even 20 to 40 minutes before asking for
help.
40:58
For me, that's
41:03
a goal to strive to.
41:07
But I guess, especially coming from
a self-taught coding boot camp.
41:13
We're so reliance on ourselves for
41:20
learning and
having to figure it out on our own.
41:25
I still can have those stubborn
tendencies where I'm just like,
41:31
no, I need to figure it out.
41:36
I got this.
41:38
And then where as the time goes,
suddenly it's been a few hours.
41:39
And that can be a workday sort of lost.
41:44
So I try to keep it within an hour or two.
41:47
But yeah, these things, they ebb and
flow over time, and again are subjective.
41:55
I know some coworkers who, they encounter
an error and it's very immediate.
42:00
[LAUGH] Post in the channel,
has someone encountered this?
42:06
Could someone help me?
42:11
So yeah, definitely,
kind of just feel it out for
42:13
yourself, see what feels best.
42:18
But like I said,
I generally keep it within an hour to
42:21
a couple hours before I ask for help.
42:26
But also depends on the urgency,
42:29
if it's super time sensitive
the task needs to get done.
42:33
Then that definitely means I'll like
ask within maybe 20 minutes or less.
42:39
So yeah, can be like feeling it out for
yourself.
42:47
And then Miguel asked, how do you jump
out of a tag when you're programming?
42:53
When a auto inserts a tag,
is there a way to jump out of it?
42:58
Jump out of a tag when you're programming.
43:07
I'm not sure if you mean
maybe an HTML tag or
43:13
something that is specific to
43:19
your text editor that's popping
43:24
up to try to help you code.
43:29
But [LAUGH] is it necessarily helpful?
43:33
Yeah, I'm not sure.
43:40
Cuz I don't know if I've
encountered this issue myself.
43:41
But if it is something that's like
some sort of autocomplete in your
43:44
text editor as you're coding,
that you're having some issues with.
43:50
I would definitely just try to dig
into exactly why that's happening.
43:55
Is it some default setting
that's configured on your
44:03
editor that is just kind
of continuing to pop up and
44:08
be annoying and not useful?
44:13
Then I would try to figure out
why exactly that's popping
44:16
up as you're coding and
figure out how to disable it.
44:21
Or how to change wherever that rule or
44:26
setting is defined in
your editor settings.
44:30
And either get rid of it or
make it more useful for,
44:35
what would be helpful for
44:41
you to have something appear like that?
44:44
I hope I understood that [LAUGH] properly.
44:48
But I haven't encountered myself,
so I am not 100% clear.
44:50
And then, again, I sometimes have
trouble with pulling data from an API.
44:56
What are some simple best practices
when encountering errors?
45:03
Having trouble in pulling data from API.
45:08
That's a good one.
45:10
So again,
kind of like I mentioned towards the end,
45:11
one common culprit for
errors being variables not being
45:17
assigned the values that you're expecting.
45:23
This is a common one for
API calls, where maybe something
45:29
isn't necessarily set properly
with how you're using the API key.
45:35
At least for me, with API calls,
I first kinda isolate,
45:42
well, here is my API key,
what I expect it to be.
45:47
And I also try calling it in different
environments to test it as well.
45:52
I could think of maybe a pep
project they did recently where
46:01
I was making an API call with
the provided API key just in the browser,
46:07
and was getting the data I
expected back from the browser.
46:14
But when I tried doing it in my project,
46:20
outside of the browser in
a different text editor.
46:23
Then for some reason,
46:27
I was getting an error code response back.
46:30
I don't remember exactly,
it was just something, maybe a 500 error,
46:36
something wasn't authorized.
46:40
And so for me, check the API key.
46:43
Clearly that was good because
it was working in the browser.
46:50
So honestly, at that point, it can just
be useful to sorta Google the error.
46:54
And again,
similar to what I mentioned when googling,
47:01
including the error that you received.
47:08
Maybe the API that you're using,
where you're using it,
47:13
and how you're using it,
what library are you using?
47:18
Is it the Axios library?
47:23
Are you using a fetch library?
47:24
And yeah, the exact error you're getting,
can add the error and
47:28
quotation marks just to get
a specific result back.
47:33
And, for me, that resolved my problem by
47:37
including the fetch
library that I was using.
47:42
It turned out that I was
missing some of the request
47:47
parameters that were
necessary in order for
47:53
the API that I was trying to hit,
to accept my response.
47:58
And be like, okay,
I have the proper request that I need.
48:04
So I was able to get
a response after that.
48:11
So a lot of times it's missing
certain keys on your request
48:15
within the library where
you're making that call,
48:20
can be a good place to start after
you're sure that the key is working.
48:25
Is that error stacktrace in the terminal?
48:34
That can vary depending on the project,
but,
48:38
well, in terms of where exactly it is.
48:42
If you're running code in your terminal,
then yes, it'll appear there.
48:46
But if it's a web application,
48:52
sometimes it'll just appear
inside of the browser console.
48:54
So if you go to your dev tools in
the console within your browser,
48:59
that's one thing I always
do when developing.
49:05
I'll run code in a terminal, but
on the browser, I'll also always have my
49:10
developer tools up with that console app
as well, just so I can catch any errors.
49:16
Because they can vary depending
on where they show up.
49:22
So just having both your developer
tools and your console up, and
49:25
then a terminal, and
then just keeping an eye on both.
49:30
And they can show up in either.
49:34
Sylvester asked, at my work, we don't use
any testing tools for our front end code,
49:37
and mostly checked by running the website
locally and test for expected behavior.
49:43
Is this normal for
front end web developers?
49:50
Or do you have any
advice on testing tools?
49:53
I don't believe that's normal.
49:56
[LAUGH] From what I know especially in
our company, we're pretty big on testing.
50:01
And so,
while behavioral testing on a browser is
50:08
absolutely important, and we do as well.
50:13
We try to do our best anytime we can.
50:18
And I do believe most
companies are like this,
50:22
we should be the goal.
50:28
Because like I mentioned, tester,
super useful when you're going
50:31
through debugging and coding,
because they serve as a document, right?
50:36
As to why code is set up a certain way.
50:41
So definitely recommend.
50:45
And for front-end code,
it depends on the library.
50:46
But for our code at Pandora,
we use React and Redux.
50:50
And so we'll use, Jest is a great
testing library for unit tests in React.
50:56
And we also use Airbnb's test library,
Enzyme, for
51:03
testing specific functionality
within the browser.
51:07
And ensuring that the CSS and
everything looks the way it should.
51:12
But whatever languages
you use in your project,
51:18
I would highly recommend
Google searching those.
51:22
And then getting the initiative
going on implementing those for
51:25
every portion of your project, absolutely.
51:30
Okay, awesome.
51:34
So I think that's time for
the presentation.
51:36
But thank you all so much for coming and
51:40
offering me the space to share
what I've learned today.
51:43
And also have my contact info here, please
feel free to reach out to me anytime.
51:47
I am happy to go into more detail of
this presentation or just any questions
51:54
about software engineering or
career development in general.
52:00
Happy to connect.
52:04
So, thank you.
52:06
Thank you.
52:07
And I'll go ahead and stop sharing.
52:08
Thank you so much.
52:14
Take care.
52:15
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up