Taking Note

Recently, I realized the importance of—good—notetaking.

I’ll admit that I’ve done this more than once.

My attitude toward note-taking used to be “If I don’t remember it, it must not be that important”.


This may have worked in an art college, were sketches and concepts were common. But, as I’ve moved deeper into the software engineer side of the track, remembering specific processes gets a lot harder.

For one, it’s not just the concept that needs to be recalled. But how.

Are you using Ruby or Javascript? The concept to get a random item from an array may be the same in both languages, but the syntax will be different. What about the output, what format should it be in? Or, does this need to account for an argument?

These are some of the things that come to mind when writing code that is similar to something that I’ve done before, but I can’t remember how I got there.

If I could dump the memory space in my brain currently occupied by every song lyric in Hercules, maybe I could remember all of the things, but for now, I’ll stick to taking better notes.

Here’s what worked for me.

Literally, Write Comments in Your Code

I’m probably not the only developer in the world that assumes future you will remember what your code does. This may be true in the short term, but long term (days, weeks, hours, etc) is a different story.

To combat this, I literally explain to myself, in the comments, what each line of code is doing.

Here’s an example using a method that randomly generates a new hex color each time it is run.

def createColor
  hexadecimalIntegers = ["0","1","2","3","4","5","6","7","8","9","a","b","c","d","e","f"] # Lists all possible integers that can be use in a valid hex code
  color = hexadecimalIntegers.sample(6).join("") # Randomly get 6 items from the hexadecimalIntegers array, then join them together at each character
  "Your new hex color is ##{color}" # Puts hex color

When writing comments, I like to think about how I would explain my code to someone else. I could go a step further and add a note explaining why I used .sample in place of .rand.

Write Notes by Hand

I will admit, I’ve debated if this is the route I wanted to go myself. I keep a bullet journal for to-dos but writing code by hand seemed silly when it’s so easy to copy and paste from one digital document to another.

There are studies that support pen and paper note-taking over typing, so I decided to give it a try.

My head was spinning when it came to classes in Ruby. It was a new concept with a lot of moving parts. I wanted to make sure I understood the core concepts before I moved onto the advanced parts.

When going back to review classes in Ruby, I reread the course material and took pen and paper notes. Any key concepts that I find myself forgetting—I’m looking at you instance variables—I would write it down. Similar to my inline comments, next to the code snippet, I would include in plain English what the function does in relation to the bigger picture.

Taking notes by hand, forced me to keep my notes concise and focused. Notes like this, paired with my inline notes, were helpful when comes to refactoring, which brings me to my next point.

Review and Refactor Often

Do you ever solve a problem, then feel like you don’t know what you actually did?

Perhaps it’s a side effect of wanting to learn a lot in a small amount of time. But, I’ve realized that I am better off taking the time to review the code, notes, and comments I wrote previously before moving onto new concepts.

This is where refactoring comes in.

Refactoring is a new concept to me, but I see it as improving the existing code while maintaining it’s functionality.

Usually, my inline comments present enough of a story that I know what problem the code was meant to solve, to begin with.

Then I can refer to my handwritten notes—which cover the broader concepts—to see where I can make improvements.

For example, are there variable names that I can clarify? Is there any redundant code that I can remove? Are there edge cases that my code should account for?

In closing, making an effort to write good notes can be a game-changer in your learning journey.

While written notes, supplemented by inline code comments works for me, it is important to use whatever note-taking format—written, typed, audio—works best for you.

How do you like to take notes when learning a new programming concept?

Asking for Help as a Developer

Uh oh.

Your code doesn’t work and you have no idea why.

Congratulations! Developer achievement unlocked!

Hitting a wall because of broken code with (seemingly) no solution in sight will happen at least once during your career as a developer.

And that’s ok.

The idea of running into a problem that you cannot solve is not meant to scare you. In fact, I mean for it to be the exact opposite. Knowing how to troubleshoot, when and how to ask for help is a valuable skill as a developer.

Here’s a short guide on how to ask for help in a way that concisely moves you toward a solution.

Be specific about your problem

When presenting your problem to ask for help, realize that someone outside of your codebase may not know what you are working with, which may make it difficult to offer solutions.

Some questions to ask yourself before presenting a problem include:

  • What were you expecting to happen?
  • What did happen?
  • What have you already tried and what was the result then?

Include details like operating system, browser or framework if it is relevant. Anything that may help someone else have an idea of is going on. That way, they have a good understanding of where you are, what you are working and how to jump in to help.

Share your code

If you can—please keep sensitive information in mind—share a snippet of your code. For someone trying to help, it is helpful to know exactly what code you are working with. With a code sample, they can quickly look for common gotchas like misspellings or syntax errors. They may also use your code to try and recreate the problem locally and test possible solutions.

Sharing full sections of code is ideal. If it a larger project, push your code to some place like Github and share the link to your repo. Mention which files, functions or lines of code you are currently having problems with.

For example, you may say that the math on your howManyDaysUntilHalloween function is off in the spooky.js file. This way, whoever is helping you can get right to the problem instead of searching your codebase and hoping they found the one they think you were referring too.

For smaller projects, sharing a single file or function is fine. If you can, attach the code as a text file or formatted as code. This way, the formatting remains intact and the code can easily be copy-pasted. If you are getting any specific error messages, you can share those as code snippets too.

What have you already tried?

Have you tried turning off and on again?

Why yes. Yes, I have.

Debugging, just like knowing when to ask for help is another key skill of being a developer. When you run into unexpected behavior, take a step back and spend a little bit off time trying possible solutions before asking for help.

If you are able to find a solution on your own, great! You can stop reading this guide and keep coding. Otherwise, you can share what you have tried and the results.

For example, if your code was working before, what was added recently that may be breaking it? What functionality were you trying to add?

Removing the most recent code additions—or temporarily commenting it out—may help you to see exactly where in the program it is breaking. Are you getting no output when there should be one? Or, are you getting an output but it’s not the result you were trying to achieve?

While you are debugging, make note of what you have tried, if it worked, kind of work, or didn’t work and share those with your code when you are asking for help. That way, your helper can skip over suggestions you have already tried and guide you in the right direction.

Ask questions

Thanks to your helper, your code is working now! Cool.

But, now that it is working…do you understand what went wrong in the first place? Or what the fix is actually doing?

Part of being a developer is learning from your mistakes. If you can, ask if your helper can explain what the problem was so that it can be avoided for future builds. They may be able to explain the why and why not’s behind a concept in a way that makes more sense in the context of your project. Consider asking if they have any resources they would recommend for further reading.

This is also a great time to take notes. Add comments to your code so that future you knows what each line of code is doing and why.

In summary, running into a problem you cannot solve is not the end of the world, even if it feels like it. By taking the time to analyze the problem, presenting it in detail with supporting code and expectations you can get the help you need in no time.

Documenting for Open Source

Thanks for attending my talk Documenting for Open Source at Write the Docs Portland. Slides, recording, resources and other fun stuff can be found here. The presentation is being recorded so check back later for the video!

As always, Tweet—and use the conference hashtag #writethedocs—or email me if you have questions!

Project Files

How Many Days Until Halloween? – The project that started it all! Not sure how many days until the spookiest day of the year? No worries, this webpage will do the counting for you!

Fork the project files on Github – Peak behind the code and see firsthand how this project evolved over time. Contributions are always welcome!

Presentation Slides [6 MB] – A PDF of my presentation slides can be downloaded here.


  • Hacktoberfest – Hacktoberfest is a month-long celebration of open source software
  • Open Source Guides – An extensive collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project
  • Open Source Survey – The Open Source Survey is an open data project by GitHub and collaborators from academia, industry, and the broader open source community
  • Bridget Kromhout’s Tweet on writing docs with empathy
  • Make a Read Me – A 101 guide to creating a README
  • Contributors Covenant – A boilerplate code of conduct for open source projects
  • Keep a Changelog – One of the many ways to structure your changelog
  • Documentation Guide – A living, breathing doc about writings docs from Write the Docs

The One Where 2018 Comes To An End


In the moment, it can be difficult to realize what you’ve accomplished in a year.

2018 is no different.

As the year comes to a close, I wanted to reflect on everything that I accomplished—or didn’t—in the past 365 days.

Continue reading “The One Where 2018 Comes To An End”

I Cried After Completing my Nanodegree And It Was Worth It—My Udacity Journey

The Start of the Journey

It’s hard to think that almost a year ago I was applying for a Nanodegree. I was not on the hunt for scholarships or looking to enroll in a bootcamp or nanodegree. I saw the opportunity on social media and almost did not apply. Afterall, I thought, I knew how to code—I had been learning to code for years! I was mostly self-taught but I was employed as an email developer. There were people with similar backgrounds as me who were struggling to find something—anything—in tech. I thought that I didn’t deserve the scholarship and this was before I even applied!

Continue reading “I Cried After Completing my Nanodegree And It Was Worth It—My Udacity Journey”