4 techniques to improve as a software dev

August 16, 2020

I spent many years struggling to improve as an engineer. Learning how to use modern tools and frameworks is not the same as actual improvement and in the long run I had not found that it had any kind of meaningful impact on the kind of input I would have in my team and company.

This article is aimed at the software engineer who is wondering how to get to the next level in their learning. Perhaps trying to have a larger input and a more direct impact on all manner of interactions. This can range from reviewing Pull Requests to team meetings.

Today we will be looking at 4 techniques that I have utilised to help me improve as an engineer.

  1. Experience more patterns and interesting solutions
  2. Improve your general problem solving
  3. Identify and learn from your current behaviour
  4. Utilise common management principles

1. Experience more patterns and interesting solutions

There is a huge amount to learn from other people's code. Most are expected to review code written internally but what about code written externally?

The JavaScript ecosystem is a jungle of public open-source tools, many of which have different and interesting designs. I would recommend finding your favourite 2-3 tools/frameworks. Start with some basic questions and dig deeper and deeper into the code, identifying any patterns and solutions which you may not be familiar with.

This is something I have experience with. I began an "under-the-hood of" series for this very reason and feel I have learnt a tremendous amount by applying this practice to TypeScript, Webpack and many more. But I encourage you to do it yourself and see the results.


2. Improve your general problem solving

If you are somebody who has sometimes struggled to identify optimal solutions to a given problem, I recommend using a technique called "diverse problem solving". This is how it works.

To start with a problem is identified (e.g. "should our onboarding form have a back button")

  1. Review the problem from as many key perspectives, for example:

    • The happy path
    • All possible error states
    • Mobile/tablet/desktop
    • Consistency with other products or the code
  2. Come up with 2-3 different solutions
  3. List the pros and cons of each
  4. Pick the most optimal 1

This technique helps you practice identifying areas which a given problem will effect and therefore determine the best possible solution faster.

It is a not a quick process so is not practical to do for every problem. But what I found was that applying this once/twice a week really helped me improve my overall problem solving. For me, it helped to write the output of each step down but feel free to do it the way you are comfortable.


3. Identify and learn from your current behaviour

I would sometimes look back on Pull Request comments or even my input in certain meetings and think "hmm yeah I could have said X better" or "I said Y but really it was not that relevant". I started applying a technique to help me identify the gaps in my skillset and behaviour which were leading to these kinds of (not quite negative, but not positive) input.

The technique goes like this.

  1. Keep a log of any input you give in a PR/meeting etc which you thought could have been better
  2. At the end of the week look back on all the points, and for each one fill in this template
Date:
Event:
What I said/did:
What I could have said/done:
Lesson:

From this I have collated a list of "lessons" which are helping me plug up those gaps I had which I would not have previously been able to. Do not focus on the negativity, put your focus on the lessons.

Some of these lessons may well come from colleague or manager feedback, but its not always easy for them to identify behaviour which made you feel bad or actively want to improve.


4. Utilise common management principles

Learning the right way to look at a problem, solution or agenda item is crucial to maximising your impact.

There are a couple of management principles which I have found over the years have really helped me in a given situation, despite the fact I am not a manager.

For example the "Eisenhower Matrix". Its obviously completely subjective when I say "for managers" as this kind of knowledge can be useful to anyone at anytime. But I only discovered it by starting to read management books and the sections on "how to prioritise".

For anyone who is not familiar with the Eisenhower matrix, its idea is to help you categorise an item into 1 of

  • Important and urgent
  • Important but not urgent
  • Not important but urgent
  • Not important and not urgent

Its definitions I have always found very helpful:

  • Important = lead to us achieving our goals, or others theirs
  • Urgent = Immediate consequence if left
The matrix

Inside a meeting or Pull Request I will always consider those 2 definitions and where the current issue fits in relation to them.

What I have found is that my reasoning has gotten stronger as my understanding on "why we would or would not do a task" has grown.

There are many other principles which can improve the way you look at a problem or agenda item.


I have spent the past couple years using these techniques and I have really found my input has improved. I can look back on my entries from 12 months ago and clearly see that I learnt the lessons.

The result of this is that I am much happier with my behaviour and overall impact within my team but also my company.

If you have any ideas for other techniques I would love to hear them, please email or tweet me. Thanks, Craig