Some advice for junior software devs

What follows is a response that I gave to a more junior coworker, who asked for advice on becoming a better software engineer; slightly edited to remove anything specific to that dev.


  1. I don’t totally feel comfortable giving advice, b/c you do a lot of stuff right and are a much better dev than I was at your stage of your career.
  2. But I guess it’s part of my job as a senior (citizen).

🚩 ​Actual answer starts here ⬇️ ​

Learn about the stuff you see

Something that has always served me well is: not taking things for granted and assuming everything I see (existing code in a project I’m working on, for example) has been done correctly. If I see a pattern that I don’t understand, I try to not just copy that pattern without understanding it (it can sometimes be embarrassingly obvious that someone has done this, to a code reviewer).​

Follow the rabbit hole of what that function you’re invoking does.

Ask, “is there a name for this pattern / way of doing things?” Then read about that.​

Read the docs

(or, ​RTFM, if you like)

When integrating third-party code/services, it is very tempting to look at “quick start” code sample, copy/paste that, then get to hacking & cracking (and I know, I used to be a ​hack crack addict).

Actually having the patience/focus to spend the 10+ minutes reading all of the documentation on something can be a superpower, in some situations.

Many times (ok, maybe twice) I have had a colleague stuck on making X do Y in some convoluted/hacky way, only to come in, spend a few minutes looking at X’s docs, and discover that there is a simple way to do Y explicitly spelled out.

Software becomes more complicated the more you pull it apart and less so the more you step back

(stole that, but I read it once and it stuck with me, so it’s mine now)

Pretty self explanatory. With that: is always good to ask the question “what are we trying to solve here?” Don’t get lost in the sauce and end up doing something some way because of inertia. Step back, away from the code, and think of what you are trying to achieve at the product level. This can unlock insights about different/better ways of accomplishing that product goal.​