How can a software developer absorb details from day to day work?

Question

On a given day as a developer, relatively quite new to my company, I encounter a lot of small details that I have to figure out or ask someone about. Ideally, I’d remember these and do the correct thing the next time or apply the knowledge next time it comes up. However, I have a horrible time keeping things in my head and often find myself looking at a situation, knowing I’ve encountered it before, but not remembering how to handle it.

I tried writing notes by hand about such things, but I ended up with a hodgepodge of disorganized notes. I have tried using notepad or word docs to organize them better, but this doesn’t work either because they are still very difficult to organize and I still don’t know where certain info would be.

Example: I need to use classes instead of the style tag for styling elements on the front end. I add this to my notes on “frontend development.” Now I have approximately 100 bullet points under there and remembering what to ctrl + f for next time I encounter this situation is almost impossible. I don’t want to make the same mistake again, but sorting through this random list of info is a huge hassle.

Answer 1

Learning is an active process. We learn by doing. Only knowledge that is used sticks in your mind - Dale Carnegie

To that, I would add:

For everything else there is 'search'

Keep taking notes and when you search again for some information, pay attention to how much you struggle to find it again and, most importantly, why. What was missing? How did you phrase it? Not enough details? Etc.

Then whatever you discovered, add it to your next notes. With time you will create a system specific to you to makes this easier.

But don't rely on notes only. Always reaching out for 'search' in your notes does not scale. Try to practice the knowledge to be easier to remember, as per the first quote. With time and patience all the things you use and need regularly you will remember, and search for the rest.

And finally, it's worth mentioning that you are not unique in this. Software developers need to absorb large quantities of information. And we are all humans with limits. Be patient. At some point we all need to lookup for things we can't remember from the top of our heads.

Answer 2

Take note of the frequency you have to search for specific things. When I started developing, I had a corkboard right above my monitor. If there was something I found myself looking up multiple times (eg display:none vs visibility:hidden), I would write it on a notecard and post it to my board. In the first year, I had my board filled with git, composer, css, common errors, & more. The more I used certain things, the less I had to look them up, because they were written directly behind my monitor. At the start, I had to look up padding vs margin frequently, but over time it became second nature. Eventually, you'll stop needing to look them up entirely.

(except for the life of me I can never remember the exact syntax for reverting the last git commit and have visited this page several dozen times)

Answer 3

Tagged notes.

You ARE on a Stack Exchange site, aren't you? :)

If you note, all information on SO/SE is organized by tagging it in a FINITE set of tags.

Do the same when organizing ANY information in your life, including your work notes.

Note the plural. One tag (frontend-dev) is, as you point out, not sufficient. But 3-4 tags should be enough.

frontend-dev + css would be far easier to find than 1 bullet out of 100 FED ones.

Tags in your notes shold be formatted specially, in a word/text document maybe square brackets around them, or use a spreadsheet and have 3-4 columns for tag1...tag4.

Answer 4

I've been using my own MediaWiki for years. I have one page called 'Today I learnt' where I link to specific pages. For each day, I write down noteworthly stuff that I think might be useful again in the future.

For instance, I have one Wiki page called 'Git' where I put git related stuff. Every page as a table of contents, so I immediately see which problems I solved in the past.

Answer 5

You are on the right path with writing notes down in a document. But the second step is to organize those notes. Not just in a file with some headers but in a Word or equivalent document that utilizes the different header levels. Then you can use the table of contents or navigator to find the area you are looking for. Periodically take 10 or 15 minutes to read through what you have, and move it around. As you accumulate more notes and need to look more things up, you'll come up with an organization that makes sense to you. And the mere act of going through your notes will help set them in your mind.

Answer 6

Lots of good answers already, but I feel like it's worth adding a few extra points:

Checklists

Have you found yourself fixing the same mistakes with multiple pull requests?

Create a checklist for yourself with all of the things that you needed to address and make sure to go through it yourself before opening a pull request or asking others to review your request.

At first you'll come up with a huge PR and it will feel like you are a lot slower than you used to be, but overtime the checklist items will burn into your memory and you will never make the same mistakes again.

Automation

Are there rules that your company likes you to adhere? Can you automate them with something like linting?

Shared notes

I can promise you that you aren't the only person who has the same questions. If you managed to find an answer, consider sharing it with other members of your company in a shared place like a company intranet, private wiki or simple README files in your codebase. Once people notice your work they will repay by adding their own notes making it easier for everybody else to work at your company.

Code references

Have polished some peace of code over and over until you are satisfied with it? Write down where this code lives, so that you can refer to it the next time you are facing a similar challenge and hopefully it'll be enough to jog your memory.

Answer 7

Instead of memorizing details, form a theory on how how the tools work. It is much easier to remember than a huge number of details, and it allows you to invent new ways to use the tools. Even if the theory is not completely correct, it can still be useful, and if it does not explain everything it can help to find the documentation.

I have found that it is easier to develop the mental model while working on tutorials. Especially for programming languages there are formal specifications, but they are difficult to read if you haven't seen the practical context where the ideas are used.

A classic example for software developers is Git. There are lots and lots cheat sheets and tutorials that help you with basic tasks but every now and then you will end up in a situation where the only way out is taking a new clone. I was in the same situation, but after reading a few chapters of Pro Git I understood out the "porcelain" model of how it works. After that, I have been able to find the help page that I really need and haven't had the need to start with a fresh clone.

There is an up front cost of doing some reading instead of just starting work, and you have to resist the temptation to just ask on StackOverflow or look up an existing answer, but it will pay off. Also, if you're going to use something only once, learning it is not going to be cost effective and can be counterproductive for your career.