Get Ahead Of The Curve
Becoming A Better Developer, Part 3
So you want to become a better developer? This guide is divided into four parts. The previous installment was about working as a junior, while the third (the one in your hands right now) is devoted to developers that have certain experience and want to improve.
Tips to help you improve are shown in bold.
Personal experiences will appear in colored boxes like this one.
Devotion
Now let us consider the next step. You have been in the industry for a few years, and you want to become a better developer.
At this delicate juncture we must search our souls once again. Do you have the level of devotion needed to be, not just a regular software developer, but a really good one? Do you want to be at the top of your profession? Because honestly, you do not need to be: there are many people with an honest development job that are happy to punch a clock and do their time.
And then there are these people who do a lot of extra effort to look beyond what is asked from them, and learn new things every day.
Never despise great developers; never despise good developers; never despise regular workers.
I guess you can say it shorter: never despise other people for doing their job as best they can.
Impostor Syndrome
Perhaps you think you are a mediocre developer. Let me introduce you to this little concept called impostor syndrome, which some say is not even a syndrome.
Basically it means that you feel that you are not adequate at your work, even though external measures say you should. It is often felt by people of all conditions, especially high achievers. Albert Einstein famously said:
The exaggerated esteem in which my lifework is held makes me very ill at ease. I feel compelled to think of myself as an involuntary swindler.
If the most celebrated physicist in the 20th century was not immune to impostor syndrome, how can you expect to overcome it? I recommend focusing on two things:
- First, you don’t have to tell others how good or bad you think you are; just tell them what you have accomplished and let them draw their own conclusions. In time this will allow you to focus on results instead of on how good you are or are not.
- And then you can just work hard. Don’t give yourself a heart attack or spend your life on the keyboard; just do your best at whatever you do.
Well, what if you really are mediocre? Even if you feel you are below average, you can improve a lot in our profession just by working hard and focusing on results.
Give a chance to mediocre people. Especially to yourself.
So Are You Good Already?
According to a popular notion, one half of everything is below average. Wrong! This is only true if:
- quality can be measured,
- and it follows a Gaussian distribution.
Let us put aside the first item for a moment. The second condition is not just a fine point: many important variables follow highly skewed distributions.
Let me give you just one example. Household income is one of these highly skewed quantities that do not follow a Gaussian curve.
According to the quoted report by the UK Department for Work and Pensions,
In 2014/15 just under two-thirds of individuals had a household income less than the national mean average (£581 per week).
Surprise! Not one half below average, but two-thirds! Perhaps developer quality is similarly skewed.
Going back to the first condition brings us to an uncomfortable question: can we even measure developer quality?
The 10x Engineer
Fred Brooks writes in the classic “The Mythical Man-Month”:
In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!
This is the original study.
DeMarco and Lister found huge differences in productivity in an inter-company competition.
See how most people are below the average? Gradually managers realized that there were huge differences in productivity between developers.
From this emerged the figure of the 10x engineer: a person which is able to do 10 times as much work as the regular developer.
Your “Comfort Zone”
Why the #@&! would I want to leave my comfort zone? Do these people even know what “comfort” means?
Translated from @zezenzuska.
There are a lot of excellent resources about how to become an excellent developer. I particularly like Angelina Fabbro’s talk. It contains excellent concrete advice, like:
- learn a new language,
- use a new framework for your next pet project,
- or read books about your profession.
A common request from workers at most companies I know is: “we want more training”. It has always amazed me: how come companies are not willing to train their workers? That is a cheap request to make; in exchange they would get a better and more motivated workforce. But quite often those requests are not met.
If your company is not giving you training, look for it yourself. Get them to pay for interesting courses and conferences, or at least to give you time off so you can attend. If they don’t, consider other jobs. But while you are there, consider taking holidays for these activities.
Your career is your responsibility, not your company’s.
Trust Me, I’m An Engineer
“Engineer” is in many countries a prestigious title, derived from latin ingenium (cleverness).
- A programmer is tasked with writing a program, supposedly starting with a detailed specification.
- A developer has wider responsibilities: create a software system that solves a certain problem.
- An engineer is tasked with devising a solution to a necessity.
Not all solutions involve writing code. Sometimes it is better to adapt an existing package, or just to hack up a simple console script that does 80% of what we want. And sometimes the best solution is to write some code.
But other times the best course is to delete code. As Ken Thompson once said,
One of my most productive days was throwing away 1000 lines of code.
Always remember: writing software is a means to an end, not a goal in itself.
Strive to create value, not just to write software.
Find Your Specialty
You cannot be a top developer by just being a generalist. Luckily there are many disciplines inside software engineering. A few of them are:
- UX,
- data science,
- security,
- scalability,
- management,
- development methodology,
- gaming,
- DevOps,
- embedded systems,
- physics simulation,
- visualization,
- quality assurance,
- mobile apps,
- machine learning,
- analytics,
- …
Getting thrown into the wrong specialty can be very damaging.
In 2007 I joined ING Direct Spain as an analyst, which involved a lot of technical work and some programming. As I have told elsewhere, a couple of years later I was made a project manager, which means that I was supposed to use an office suite as my tool of choice, and not code anymore. My life was not easy from that point on. While it is nice to know how to manage people, resources and projects, I’m not comfortable in a 100% managerial position. After a couple of years I left and have done technical work since.
Find what discipline you you would like to specialize in, and strive to work in it.
Your knowledge should be T-shaped: a shallow familiarity with many disciplines, and deep understanding of one or two.
It is probably a good idea not to specialize too much: an “expert in jQuery” looked great five years ago, but nowadays it looks dated. Instead, focus on broad disciplines like frontend development or UX (which is itself a refactoring of UI).
Get Involved In The Community
Finally, a really good way to improve as a software engineer is to find a local community, and get involved. Just showing up is a great first step! Then you can stay for a couple of sodas afterwards. It is very rewarding to know more people that work in your field and exchange stories from the trenches. Talking with your colleagues from work is nice, but since you breathe the same environment it is not as interesting.
The next step is to attend a few conferences, both at the national and international level. This way you can broaden your circle of acquaintances: most people are quite open at conferences and are usually willing to speak to anyone during breaks.
Then you can try giving a talk at a local group, and seeing if people like it.
In 2012 I approached the organizers of MadridJS to propose a talk about Node.js and Websockets, something I had been working on in my spare time as part of the milliearth project I have mentioned before. We finally scheduled it in 2013. All the 70 available places in Meetup were gone in about four minutes, which goes to show how popular the subject was. It was unfortunately taped (in Spanish). You can see how nervous I was. Even so it was a great experience! Since then I have been involved in MadridJS, and today I help organize monthly talks.
Conclusion
There are many ways to improve as a developer, many of them have been repeated ad nauseam by now, while others are clearly not stressed enough.
To really improve you need a long-term goal; it will help you focus.
Set yourself a goal for the next five years, and then build a way to get there.
Your goal should not be something too specific, like “mastering Angular”: in five years it might not be that interesting (or it might not even exist). Instead of a project, a framework or a company, try focusing on a particular discipline, and work from there.
Part Four
The next installment is out! For you expert developers
Published on 2016-10-17, last edited on 2016-10-17. Comments, improvements?
Back to the index.