Underrated meta skills when starting out as a software developer
No long winded, whimsical introduction here. The following tips are exactly what the title suggests. Also, I am horrible at introductions and this is TOTALLY not a cope out. Here go my 7 tips:
1. Break down your task into small chunks
You know that feeling when you hit "submit” on that pull request or "close” a github issue? That feeling of fulfillment and rainbows and unicorns and everything wonderful even if short lived?
That my friend, is the feeling of progress and momentum. The power of small wins should not be underestimated. The dopamine hit of checking off an item from your todo list is very real, so leverage that. Break down your tasks — no matter how big — into smaller chunks that can be completed in half a day, or at maximum, a day.
Take designing and implementing a new feature, for example. It might not always be clear from the start how you might implement all the parts. In that case, just break down the first two steps you need to complete, and write down what you would need to figure out afterwards as your step 3.
2. Create small, easy to digest pull requests
This not just ties into the feeling of quick wins and consistent progress as mentioned above, it also gets others to:
review it more quickly and easily. It's less daunting to review a pull request of 10 lines than 1000.
catch any unintended consequences earlier keeping the code quality high.
onboard quicker as less context might be required per pull request.
As others have said already: ship small diffs, how this is an unwritten rule, and how to write one.
3. Get feedback early
Make a pull request with a [WiP] or “Work in Progress” title latest after half a day of work even when your code is far from ready (which should be easy to do if you're following tip 1 already). This not only gives others in your team a sense of where you are at and offer help proactively but it’s also easier to get help when you’re making a decision/debugging. You can simply point others to the relevant line where you’re stuck and get direct inputs.
4. Do a 3 minute reflection after each task
Whenever you have completed a task, take 3 minutes to reflect these 3 questions:
"Where did I get stuck?”
Answering this will help you identify any particular concepts that you might not have understood as well as you thought you did. Could be a specific language or library feature, could be a part of the code base you're working with or could be your mental model being different from what happens in reality.
"What took longer than I expected?”
The answer to this will often lie in
you not being familiar enough with a particular tool/library feature (regex is a notorious example). If you know that you will be using this tool/feature often enough, it might be worth the time to practice some drills to sharpen your skills (10-20 minutes might already do the trick!).
you not using the correct debugging tool. Take the time to create a good setup in this case or at least jot down which tool helped you in the end so you can reuse it the next time.
you uncovering wrong assumptions about the code base. By reflecting on this, you have already updated your mental model. Congratulations!
“Was there anything new that I learnt?”
You might just have learnt something super cool or spent a long time figuring out something that feels trivial in hindsight. By reflecting on it quickly though, you solidify that knowledge in your mind and give yourself a positive boost or a virtual pat on the back for learning something that you didn't know before! Or maybe you didn't learn anything new at all, in which case you might have at least gained some more practice time at a skill.
5. Be strategic when debugging
If you’re debugging something and it’s not working after your third trial, stop and start being more strategic than just random trial and error. Write down:
“What am I trying to solve?”
“What have I learnt so far?”
"What have I tried and what didn't work?”
Then make a tree of potential solutions and cross them of as you progress. Take a second to think “how surprised will I be if this solution doesn’t work?”
This little exercise will help you not get lost in the weeds especially when you're debugging by yourself and trying to avoid falling down the rabbit hole of “Oooh! I wonder what this shiny thing does.”
6. Enable others to help you
Say you are still struggling to debug that nasty bug after what feels like hours. Or, you are supposed to be implementing a new feature but you have stumbled up on a fork in the road (or more like many, to be realistic) and find yourself going in circles delving over the pros and cons.
Fear not! Ask your unsuspecting colleague for help. But for your colleague to help you without having to jump through hoops of confusing puddles of misunderstanding, do a little bit of preparation ahead of time:
For bugs:
jot down what you're trying to solve, what you have tried so far and what's not working — which you should have already if you were following the tip above.
have the relevant parts of the code open on your workspace so you can do a quick demonstration if needed
Many a times, just doing this little exercise can make the inner light bulb glow and help you see the solution that had been hiding in plain sight.
For feature design:
sketch out a quick block diagram of the design alternatives.
jot down your assumptions of the use case explicitly. You'll be surprised how many items you can end up with a simpler design just because one of your initial assumptions turns out to be not as important as you thought it would be!
lay out the trade-offs you're thinking of
make a recommendation while making it clear that you're open to suggestions. It's good to have somewhat of an opinion going in, so your colleague doesn't feel that the responsibility of choosing is being dumped on them unfairly.
Many a times, this can save you tons of wasted hours coding up a feature geared towards the wrong requirement or help you spot a gnarly dependency/constraint earlier than you might have noticed by yourself.
Besides making you efficient, by being a little more prepared when asking for help, you show others that you respect their time and this makes it easier for them to help you again the next time. They might even look forward to it!
7. "How would I implement that?”
If you're having a hard time understanding how a particular piece of code works, take a step back and think about the functionality it enables. Now, put your developer hat on and ask yourself:
if you were to implement this functionality, how would you do it?
what type of input would you need? How would you process it? What would be the output?
what could go wrong with this way of doing it?
Then revisit the piece of code and try to map the components you see to your mental model. Many times, they might even match 1 to 1. The other times, you might figure out either a different way of solving the same problem or learn about the corner cases this piece of code takes care of, that your imagined one might not have.
Either way, you have an easier time understanding the code and you learnt something new!
8. Bonus: Review others’ code
Especially when starting out in a new team, you might undervalue your opinion, and think that because you might not have all the context, you'd make for a bad reviewer. But don't!
Review others’ code as much as you can. Reading others’ code is a fantastic way for you to get started in a new code base, learn more about the unwritten guidelines, think through the implication of the code, and share your fresh view point that others might seriously benefit from too!
Explicitly ask a more experienced dev to review it as well, or even better, pair-review it together. This will not only make you feel more comfortable, but you also get to learn some points you might have missed in your review.
Conclusion
Not all of software development is logic puzzles and solving technical problems that you either just have the capability for or don't. By being a bit more proactive, bit more reflective, you can go a long way in making yourself effective. This way, you also retain much more of what you learn as many of these tips involve some form of active retrieval.
The sense of consistent progress generates an addictive momentum that's hard to get away from too! And finally, you accelerate your learning, problem solving skills and productivity as you put these tips in practice.
You don't have to do it all from the get-go, of course. The advice I often give is: pick out one of these tips, try to apply it in your day-to-day work and see how it works for you. Once it has become a habit, revisit these tips and pick up a new one.
Did any of this help you at all? Do you have some tips of your own you would like to share? Let me know in the comments below, or reach out to me on Twitter where I first wrote a part of this thread.