As career developers, it's natural that we want to measure our progress. We want to be able to see how far we've come and then look ahead to where we would like to be in the future. We want to know how good we are now and then find out how much better we can become in the future.
Following a moving target
Software development is a young, diverse and changing and developing field. As such, the specific knowledge and skills required of us can change from day to day, month to month, year to year. In such an environment, it becomes important to not only improve along specific measures, but also to get good at the process of measuring ourselves. Like an airplane in flight, we want to regularly check to make sure that we are headed in the right direction, making minor or major course corrections as necessary.
Coming up with these measures can seem like a task in itself. Being such a young, diverse and changing field as software is, there are a multitude of different competencies and a multitude of ways to measure ourselves. It can seem like there is not one direction but many directions.
There is no one source of truth, no oracle or guide who can tell us how well or poorly we are doing, where we are falling short and where we are strong and how to get from where we are to where we want to be.
The only solution I can think of, when faced with this multitude, is to try to narrow it down to a small number of broad areas in which either I am naturally curious and engaged, I need to understand them to do my job well or there is a lot of career and salary growth in them. And then learn everything I can about that small number of areas.
Over-confidence vs. under-confidence
Under-confidence can get our spirits down, but on the flip-side, over-confidence can be risky. If we are too harsh on ourselves, we may feel negatively and we may undersell ourselves when negotiating salaries. On the other hand, if we are too kind to ourselves, we may oversell ourselves, resulting in disappointed clients, failed projects, slowing of professional growth and/or inability to negotiate a realistic salary due to inflated expectations.
What we probably want is a realistic assessment of ourselves. We want to be worried where we are right to be worried, in order to motivate ourselves to improve. But we also want to be proud where we are right to be proud so that we can celebrate our improvements and figure out where to go next.
The list
After working in this industry for 10+ years, I believe I've barely scratched the surface of what it means to be a "good developer".
However, since this issue of self-measurement has been on my mind a lot lately, I've decided to write a list of measures that I am using, in order to self-measure. This list is almost certainly not exhaustive and I'm keen to see what your methods of self-measurement are. Please do share them in the comments.
0. Intuition
By thinking about yourself, you can gain intuitions as to where you sit as an individual developer. These intuitions may be fuzzy and not yet clear or coherent, but they can serve as a starting point for where to begin in self-measurement.
For example, from time to time I had an intuition that some of the code I had written might not work under all conditions. Eventually I narrowed down this vague feeling into a more specific issue – namely, satisfying so-called 'edge cases' or 'boundary conditions' in code. From there, I started to direct my focus to learning more about unit testing, assertions and reasoning about edge cases. The value of the intuition, however fuzzy at first, was that it prompted me to identify specific areas for learning and improvement and then take specific actions to address those areas. Actions such as reading books and articles on the topic.
If you have an intuition of something being wrong but can't quite put your finger on what it is, it may simply be a matter of drawing your thinking out over a longer period of time and collecting more relevant data until you do have a clearer idea.
1. Achievements
Reflecting on your past achievements can give you valuable insights into what you're capable of, what you're good at and how productive you are generally. From there, you can look for gaps where you could achieve more or better.
I like to keep a log book chronicling various small and large achievements on the software projects I have been involved in. If I resolved a networking issue, I'll note that down. If I managed to deliver a complex project on time, I'll note that down. Keeping track of these achievements in writing guards against forgetting them and collects them into one place, where they can be reviewed together.
Reviewing these achievements, you may notice recurring themes or clusters of similar achievements. You can identify areas of strength and competence. Maybe you often bring in some innovation to your client. Maybe you write very reliable code that doesn't break. Maybe you are good at troubleshooting problems rapidly.
Your achievements can indicate where you may be lacking. If you are always getting work finished fast, perhaps you are missing out some area of quality. If you are always building very fast systems, perhaps you are less comfortable with writing readable and maintainable code. Whatever your strengths are, you can identify converse areas where you are less strong. You don't have to be good at everything (no one ever is!) but you may notice just one or two areas where you think improvement would be worthwhile.
2. Pay
Pay is a great way to get a basic sense of direction with regards to self-improvement. Comparing your current or recent salary to your past salaries or to the advertised (or actual) salaries of other roles gives you an idea of what your trend is vs. what the industry's trend is. Also, money is an important measure in itself – after all, money has a very real and tangible effect on our personal lives – at least, those of us who aren't multi-millionaires!
Salaries reflect a mixture of factors, not all of which will be in your control. However, by analysing jobs and salaries, you can usually find factors which correlate with higher pay.
Such factors may include one or more of:
- Ability to lead a team
- Ability to learn and apply a "hot" new skill rapidly
- Ability to learn and apply a difficult skill
- Ability to completely master a skill
- Etc.
Salaries often go up at least partially in response to a skills shortage. If a skill is in scarce supply, there's usually a reason for that and it often has to do with a skill being challenging and difficult to acquire. If you focus on acquiring one of those difficult but demanded skills, then you can directly and positively influence your level of salary.
Sources of salary information include:
- Job boards
- Discussion boards
- Casual conversations with people in the industry
- Recruitment agents
3. Job descriptions
One source of readily available self-measurement is job descriptions, where you can compare your current skills with the required skills listed in job descriptions.
Looking across many job descriptions, you can begin to pick out recurring themes and common requirements. Prioritising ones with the highest salaries, most interesting work, best places to work or otherwise attractive features, you can get a rough idea of where you sit in relation to the job of your dreams, and from there, work out what skills you need to work on.
The job description may list some specific area of knowledge or skill that you don't yet possess. You can then begin to lightly research that area by searching the web, discussing it with colleagues/co-workers, reading snippets of books, articles, etc. This light research is not intended to be exhaustive, it's just enough to give you a general idea of how complex or difficult that area is and how much effort it would take to get into it. You can also observe your own subjective response – how interesting or dull you feel at the prospect of working in that area – to gauge how motivated you are to invest the amount of effort that will be required.
With this research in mind, combined with some introspection, you can narrow down on a few or maybe one challenging area in which to focus your effort. After a few months or years of dedicated focus, you may achieve a level of competence in that area, and then be able to effectively market yourself into a job in that area. After a few years, if it's a big enough area, you could build a whole career out of it. This is exactly what has happened for me in certain areas I've worked.
4. Technical tests
Any good technical test should challenge you, even if modestly. By observing what you find difficult about the test, you can figure out where you are lacking and could improve.
Technical tests are especially good measures because they are directly related to whether you get a job offer or not. So they have a connection to reality that self-study might not always offer. In a technical test you get to measure yourself against the judgement of a real-life human being, as opposed to static information from a job description, book, article, etc. Of course, as with any source of information, you have to think critically and not take any particular interviewer's assessment of you as gospel or as applicable to every situation.
Another useful attribute of technical tests is that there is usually an element of pressure that isn't present with other forms of learning. The test has to be completed by a particular deadline and/or to a certain specification of quality. Sometimes the instructions given in a test are vague, so part of the problem is to work out what the requirements are (both functional and non-functional) and then deliver on them. That process of constructing a clear problem from an ambiguous scenario is itself an area of competency that can be developed and improved.
I like to keep detailed notes on every technical I undertake, describing what went well, what didn't and whether I passed or failed. Where I failed, I note down any feedback given by the interviewer, along with my own thoughts on how I would have done things differently if I had a second chance.
5. Engineering competency models
Models have been developed, both in academia and industry, for measuring engineering competence. You can compare the competencies listed in these models to your own competencies to identify gaps or deltas.
Formal models for cataloguing and describing engineering competencies have been around for a long time. For example, the American Association of Engineering Societies publishes an Engineering Competency Model. While these may appear too academic and detached from the realities of the job market, very useful insights can be extracted from them.
For example, the model referenced above includes the following: "Anticipate or recognize the existence of a problem". This is something that rarely occurs to me. I am often so focussed on solving the problem at hand that I neglect to take time to step back and think about whether there are other problems lurking in the background, which I might not have even considered!
In an early passage in the book Database Reliability Engineering (Laine Campbell, Charity Majors), a very concrete example of such a situation is given: "Maybe you say, I’ll just report on the percentage of requests that are successfully served by my API. Okay...as reported by whom? By the API? That’s obviously a problem, because what if your load balancers are down?". This is an example of a problem you may have to go looking for, as opposed to being hit in the face by!
More recently, several software companies have published their own competency models. For example, CircleCI's Engineering Competency Matrix and the talk Engineering Competencies by Clara's Kevin Lochner.
Here are just two examples from the CircleCI's Matrix:
- "When taking action, weighs cost and value in order to take the most economic action"
- "Is aware of the organization's monitoring philosophy. Helps tune and change the monitoring on their team accordingly."
I gave myself a green tick on the first one – I have done this pro-actively many times in the past, before even having read about it in CircleCI's Matrix.
However, I gave myself a red cross on the second. What is a monitoring philosophy? What are current monitoring best practices? Yikes! I definitely need to improve and skill up in this area. Fortunately, I managed to dig up some good resources on the topic, such as Chapter 8 – Monitoring in the book Building Microservices (Sam Newman).
6. Comparing yourself to others
Contrary to many popular sayings, I think that comparing yourself to (and even emulating) someone else can be beneficial, especially where you can identify what habits and actions led to that person being in a position similar to where you would like to be.
One benefit of comparing yourself to someone else is that you don't have to take the risk of trying something new without knowing whether or not it will succeed. Rather, you can observe someone else's success, reverse-engineer its causes and then work out how to derive a similar outcome for yourself. Heck, if you're on good enough terms with the person, you could even ask them directly how you might get to where they are – they may just share a secret or two!
Just one example of this from early on in my career is observing the positive disposition of one of my colleagues. Rather than focussing on the negatives and downsides (which at the time were many), he was quick to offer positive ideas and upsides. This positive disposition, conveyed in an appropriate manner and context, made it more likely that co-workers and higher-ups would give him opportunities, as he came across as being willing and able to do produce great results.
There are many more similar examples I can recall, of how I observed people behave in a certain kind situations, and how that kind of behaviour produced a positive result for them. I've since been able to emulate that behaviour and achieve similar success.
7. Feedback from others
Asking for feedback can be a great way to get an idea of where to improve. If you raise the issue of feedback and effectively give the other person permission to be critical of you, then you can make good use of their comments.
One thing to note is that the criticism itself may or may not be valid or useful. But almost certainly that criticism will reveal something that is true and useful to know. If you can extract a grain of truth from even the most inaccurate criticism, by taking into account all of the surrounding factors, incentives of the other person, etc, then you use that truth as a guide to where you could self-improve. Fortunately, the vast majority of criticism is well-intentioned and taking it on board will more likely improve you than hinder you.
8. Knowledge gaps
Finally, we have all the more traditional sources of knowledge and learning - books, articles, courses, papers, etc. What's valuable here isn't only the knowledge itself but also what that knowledge reveals about you and your areas of strength and weakness.
If you open a technical book you've never read before, read a few pages of it and feel so familiar already can guess the whole contents of the book, then congratulations - you have probably mastered that subject! If not, then after some more reading, you can probably begin to discern where the gaps between your knowledge and the author's knowledge lie. Those gaps are where you should direct your focus in order to increase your own knowledge.
There may be whole categories of gaps where you need improvement. For me personally, mathematics is a big area for improvement. I can begin to measure my progress broadly by reading new mathematical material and observing how much of it I understand and how much I don't. A few months ago, 99% of almost any kind of math would have been unintelligible to me. These days it feels closer to 91%. That's a small but definite improvement. Seeing myself better able to read and understand mathematical material gives me motivation to continue my efforts to improve at math.
So there you have it – a snapshot of the methods I'm using to measure my own progress in learning and improving as a software developer.
I hope you found this useful and resonant.
Please leave your thoughts in the comments section. I'm sure I'm not the only one struggling to measure and improve and it's always great to see other fellow travellers on the journey toward competency. A long, long journey to be sure, but one with very pleasant scenery along the way!
Additional resources
A few articles and books on a similar topic:
Top comments (0)