I’ve received a bunch of advice throughout my years as a developer. Some good ones I’ve forgotten, some bad ones I’ve ignored. Let’s face it, most I’ve forgotten. But the ones I share with you are pieces of advice I live by. And ones that I share with others day to day. There’s always room for improvement. Please reach out (DM me) if you see something that needs changing.
Pursue what is interesting to you. Drown out the hubbub, the trends, the absolutists. If you don’t know what’s interesting; experiment!
Go broad on a topic before going deep. This advice ties in with the one above. Experiment until you find something then go deep on it. Going broad diversifies your mental models. Going deep strengthens your models.
Learn how and when to skim vs read. For me, this advice applies most to finding information. I’ll skim or use cmd/ctrl + f to search for keywords. Then spend time reading once I’ve reached the relevant section.
Build your pattern matching muscle. Not regex, but pattern matching on problems. Pattern matching comes through experience and watching others.
Pair often and with different people. The benefits of pairing greatly outweigh working solo on a problem.
Introspect often and stay away from auto pilot mode. After finishing a tutorial take the time to understand what you learnt and how you could use that knowledge in other ways.
Have a career document aka brag document. Use it to show your impact at your role. Save all the good stuff people say about you or things that you’re proud of. Look at it whenever you’re feeling down or feeling that imposter syndrome.
Always be questioning. There’s always a reason for why a piece of code exists. It’s your job to test whether that reason is valid. Also, coding is more fun when you’re progressing. Questions can help you get over that hump! I find this advice the hardest to follow.
Keep your questions focused and do some research before hand so you can process the answer. Focused questions help the person who’s giving you help. If you can’t ask a focused question, step back and ask yourself if you’re missing a concept. Have someone teach you that concept.
Think about how your code fits into the bigger picture. Is this the best solution for the given constraints? Will this code be maintainable in the future?
Self documenting code is better than comments. Use comments to explain the why. Use good naming and structure to explain the how and what.
Say no. Overcommitting is stressful. Burnout is real, take the time to care for yourself.
Words carry power. Both in code and outside of code.
Naming is hard. Understanding the domain of your application can help. If possible, err on being specific with your name rather than general. Specificity is not equal to length of a name.
Career ladders are not a checklist. They can be quite nebulous and are different for every company. Level of impact on the code, team, and organization is what I use to measure where I am in my career. I find level of impact a better indicator than a career ladder. Being consistent with impact is key.
You don’t need to write blog posts, produce content, or commit to open source to be a successful developer.
You define success.