What makes a good developer?
I’ve met a lot of great software developers. Data transforming magicians, who can stack a bunch of lodash functions you didn’t even bother to read about, to split, join, manipulate and filter objects in one line of code. Backend Harry Potters, who provide necessary data and keep every operation secure, optimized and predictable. Front-end artists, who make your in-house designers’ wet dreams come true in few lines of code. You probably have met some of them as well.
But not every one of them is good. Not in terms of skills, no. Good as a co-worker, proving to be useful for the companies they work in. Why?
Because a good developer delivers good enough quality code which acts in a predictable way, does so in satisfactory time and is able to communicate well.
Simple as that? Not necessarily. Companies are here to make money. What they pay developers for is simply making profit. The profit in its broad sense — whether it’s a feature that earns new customers, an optimization saving money, or an improvement that helps to reduce a technical debt (it’s a long term profit which sadly, is sometimes ignored). On the other hand, developers invest their time to bring that profit. The time which is spent not only on finishing particular tasks, but also which has to be balanced between coding, communication, personal development and many more.
How to make sure you are not only skills-wise but you’re a good developer in general? Let’s get back to my definition and break it down. This time, we will focus on two virtues of a good developer which are the most common and are essential on every level of developer’s career.
Good enough quality code
This is probably the simplest factor to understand and you may perceive it as something natural. What I’d like to stress here is good enough. I studied automatic control, which taught me few things thanks to my thesis supervisor, who is an endless source of quotes . One of these is:
A solution of a problem is good as long as it solves the problem on a satisfying level and the costs of this solution are justifiable.
Which means — yeah, you got it — it is simply good enough.
How does it relate to software development? Imagine you developed a proof of concept of a method which transforms an object of random data. There are some conditions, some maps, some alterations. You clean up the code now, you merge some conditions. Yet, you still feel the code can be improved somehow. Maybe some more conditions can be merged? Maybe you could use an arrow function instead, and get rid of that nasty return? (Yes, I know, this is a simplified code case).
With your code, you want to reach a point where the code is:
- readable and maintainable by other human beings,
- well written (well-structured, extensible, compliant with universal programming rules and company’s code styleguide),
- efficient and reliable.
That means you basically can stop working on a given task if you say no to questions like:
- will this change make the code more readable?
- will the outcome be worth the time I will spend on it?
- will this make it work faster or more reliable?
- will this reduce a technical debt or at least won’t increase it?
- will this improvement change anything for better?
Ask your peers for help if you have problems answering those questions. It’s a good practice to ask a senior dev, your tech lead or CTO to check the code, whether it’s just taking a look at your screen or pushing your code to a review.
Keeping your code just good enough makes your company feel that the salary it pays you is transformed into decent, profitable work and not into countless hours of improving your code poetry skills. Your company is not an open source GitHub project which can be developed over years, and keeping that in mind will make both sides happy. You might be the best coder out there, but spending too much time on polishing things that don’t matter, won’t work in professional life. Not that you shouldn’t improve your skills — on the contrary, you should always strive to do that. Just do it wisely and don’t waste time on things that don’t bring any value.
Code that acts predictably
Predictability understood as reliability and maintainability is the aspect of programming that you care more about as you gain more experience and deal with other people’s code.
There’s nothing more frustrating than diving deep into the old code to fix a feature which doesn’t work properly for one user only. You do it to find out that there are no tests and the code leaves you with a huge what the… painted on your face.
Want to make sure people won’t use git blame against you and mention your person in ‘@yourlogin is a c**t!’ mean tweets? Please, just say yes to questions like these:
- is the code safe and gives the desired outcome every time?
- does it have automated tests if it needs to (a good QA engineer will convince you that in 95% it really does)?
- was it tested by me?
- was it tested by QA engineer, if necessary?
- did I make the code easy to understand and read?
- is the code extensible? (that kinda derives from good enough code principle)
If everything is alright with those, your company will thank you and at least two people will sleep well — you and your manager. Thinking about those questions will minimize the risk that you’ll do the same thing twice, instead of spending this saved time for more interesting tasks. It will also help you to keep technical debt in check. This way, your company will know that your work can be trusted upon and someone else won’t be needed to cover up for your mistakes. And that, believe me, is a great value.
And what about being a REALLY good developer?
We covered two aspects of developer’s work that are really essential. You need to make sure you don’t have any problems with them, as they are the foundation of your work. If you want to read about next two: delivering in satisfactory time and communication 101, jump to my next post — What makes a rockstar developer?
Any comments, questions are more than welcome. Please heart this post if you liked it!
Big thanks to my first readers and proofreaders: Magda, Paweł, Bartek and Jerry, I owe you a beer!
