50 Things I Wish I'd Known at My First Developer Job (Part 1)

I split this article into two parts because it was pretty long.

This is a list of 50 things I would tell myself if I could go back in time a few weeks before I started my first full-time software engineering job.

You probably won't agree with everything on this list, but that's okay because it's a list for me. However, I'd love to hear advice you would give to your younger self in the comments. 🤠

1. Most people want to help

Generally speaking, no one is rooting for you to fail. Your colleagues and acquaintances in this field usually want to help you succeed. It is a good idea to trust other developers and lean on them for support when you need it.

One rule of thumb that has served me well: Always assume other people have the best intentions.

2. Tests are your friend

Writing tests isn't always a lot of fun, but at my first job, it would have been incredibly helpful for me to build a lot of testing skill.

First, because writing tests is an incredible mental exercise for framing a problem you want to solve; it requires you to think through each step of completing the task.

Second, writing tests help to reassure you, and others, that your code does what you think it does. This practice would have given me a lot of confidence for the first few times I made pull requests.

3. No one knows what they are doing

I struggled a lot with imposter syndrome in my first job. A significant amount of that was rooted in believing that the people around me understood the technology better than me. I was incorrect; there are parts of every project that each person struggled with.

4. Some people know what they are doing

With respect to the fact that some part of a project is going to be challenging for every developer, there are some parts of a project that one or two developers on a team will have mastered.

Figuring out who those people are, and learning to ask them when I struggled with their area of expertise would have gone a long way in building my comfort with the project.

5. Open Source isn't scary

Open Source really, really intimidated me when I first got into writing software for a living. If I had known when I started that Open Source wasn't really scary, I would have gotten involved much sooner (and that's great for your career).

6. Your heroes are people too

People say that you shouldn't meet your heroes because they will let you down. I say that you should definitely meet your heroes because you will realize that they are human.

I've spent a significant amount of time in the last six or seven months meeting and getting to know my heroes.

What I've found is that the people I look up to are people just like me, and they struggle with a ton of the same issues that I struggle with.

That solidarity has encouraged me to try and act more like my heroes; if they struggle with the same problems I have, then there is no reason I can't do a lot of the things I admire them for doing.

7. You don't need to know everything

Software engineering is an absurdly complex and sprawling discipline. No on Earth has or will ever understand the field in its entirety. Therefore, you shouldn't try.

I felt paralyzed by my lack of knowledge in my first job. Instead of focusing on the things I didn't know, I should have picked something and spent time really learning it, and ignored the things I didn't have time to learn until a better opportunity arose.

8. Deep can be better than wide

To continue that thought, sometimes knowing something really well can be immensely valuable. I learned that from freelancing on the Open Source project I maintain.

9. Wide can be better than deep

Alternatively, the world needs generalists. Depending on your professional goals, having a full breadth of knowledge can be a fantastic resource.

In my current job, which involves a level of management, my ability to absorb a lot of unrelated information has been precious.

Also, that breadth has given me a solid foundation for learning new things.

10. Simple code is good

Too many beginners, myself included, think that complicated code is impressive.

The best code is simple and easy to understand. When code is too complicated to understand, you aren't at fault, the author of that code is at fault. Don't let that kind of thinking get in your head and cause problems for you.

11. Your job is to learn

This is something I encounter a lot with my interns and the juniors that I work with. You should not feel guilty for learning on the job, that is the job.

Even seniors spend a significant amount of their time at work reading tutorials and learning new skills. You should be doing this during the workday!

12. First-principles are better than memorization

Memorization works great. In fact, I encourage practice through repetition. However, it's not always the best way to learn to reason about a concept.

If I had taken the time to learn the reasoning behind the approaches embraced by the technology I used, I would have been much more effective at deciding the right strategy to solve each problem I encountered.

13. You should write about what you're learning

Case and point.

I didn't start writing about software engineering actively until very, very recently. The result has been remarkable. I'm retaining information more effectively, and I have references that I have written available at any time.

This is something Chris Oliver talked about when I interviewed him, but it doesn't make any sense to keep your learning private. Share your notes and thoughts on a blog or on dev.to.

Worst case scenario, you have a place online that you can refer to when you need to remember something technical.

Best case scenario, you are able to help others, and you get some benefit from name recognition.

14. Be vocal in code reviews

Even if you aren't right, you should share your opinion when doing code reviews or pair programming.

One, this has the potential to improve the quality of code your team is outputting. It could also be an opportunity to provide mentorship to your coworkers (even those senior to you).

Two, you have the opportunity to be corrected when you're mistaken. You should view it as an opportunity. Even when people are rude, you can find the silver-lining and learn something!

15. Drive when pair programming

I feel pretty strongly that the least experienced developer in a pairing situation should be the one at the keyboard.

There was a number of times that I would have benefitted greatly from taking the keyboard away from a senior coworking in my first job. The benefit of a junior driving during pair programming is twofold:

Firstly, when the junior is driving, it becomes necessary for a senior to explain each step which encourages the senior partner to share context and background knowledge.

Secondly, this practice mitigates the inevitable scenario in which the frustrated senior spits out a dozen lines of code without explaining a thing. Nothing is worse than the senior running off without explaining how a problem was solved. Don't let a senior coworker skimp on teaching you; it's part of their job.

16. Build breakable toys

When I first started programming professional, I was focused on building software that was useful.

I didn't build anything because I wasn't quite ready to start building things that other people could use.

If I had just built simple projects that were good for hacking on without fear of breaking something important, I would have learned at a much faster rate. That would have enabled me to build useful stuff down the road.

17. Take breaks

Take care of your brain. This job is all about cognitive efficiency. Working 90 hours a week does not promote cognitive efficiency.

18. Exercise

Much like taking breaks, exercising is fantastic for your brain health.

This is something I let slip during my first job, and I paid the price. Bad health, a terrible sleep cycle, anxiety, and more were side effects of getting zero exercise.

I've got plenty of recommendations: If you don't like high impact, or want a leisurely activity, try Disc Golf. If you're into problem-solving, indoor bouldering is a ton of fun. If you are interested in stretching your brain and ability to focus, pick up distance running. Recently, I've been getting into Thai Boxing, which is excellent for people who seek practical athletic activities.

19. Don't obsess over refactoring

I spent way too much time trying to write perfect code. As a junior, it's not your job to write perfect code. Let your coworkers see your sub-optimal code, and they will help you improve it.

20. Write down your mistakes

It took me way too long to start journaling about the things I messed up. Keeping a record of your mistakes (and strategies for avoiding those mistakes) helps you to avoid repeating your mistakes.

21. Write down your wins

Similarly, it's essential to keep a record of your wins, but for a different reason.

One of the best strategies for fighting imposter syndrome is reminding yourself of all the great things you've been able to do in your career.

For example, remind yourself of any code you have running in production, any improvements you've made to process or documentation, any automation you've built. All of those things are valuable and can be used to remind yourself that you are a valuable developer.

22. Finding mentors can be simple

I thought, when I first started working, that a mentor had to be a formal arrangement.

I was looking for a senior engineer to talk through my concerns once a week or something. A relationship like that can be a great resource, but it's not necessary.

Later I learned that a mentor could be much more informal. All of the guests on my podcast are mentors to me.

I do have a few friends that I grab coffee with every few months, but it's not crucial that every mentor is a regular standing date. Find some people in your community and ask for 30 minutes of their time, you'll be surprised what you can learn.

23. You don't have to be an expert to mentor others

Beginners should be mentors.

When I was new to the software field, I always felt that I needed some level of expertise before I could mentor, but that's not strictly true.

Sure, don't go try to give a talk on React if you've never built anything in JavaScript, but you can help those around you even when you don't know everything.

Look for opportunities to share the things you know with those around you; it can be as small as a cool text editor plugin you found. Sharing with others will help you to grow more comfortable with sitting in that mentor role.

24. Saying, "I don't know," is a good call

A lot of engineers are afraid to admit when they are ignorant of something. I was, at one point in my career, but eventually, I realized that the only way to learn was to admit ignorance.

Get comfortable with admitting your ignorance, and you will be astounded at how often the others around you will follow your lead. Also, if you're lucky, people who know a little more will teach you!

25. Remember to say yet

As a follow-up to the "I don't know" advice. Remember to append yet whenever you can.

I personally think yet is one of the most powerful words in the English language, and if you use it correctly, it can encourage you even when you feel the worst about yourself.

"I don't know yet."
"I'm not good enough, yet."
"I can't contribute to Open Source, yet."

This mindset radically changed my relationship with my profession; I wish I'd have known its value when I was in my first job.

Part 2 of this article is on the way!

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.