The Secret of High-Performing Developers

Illustration by Sonia Budner

High performers

There is a lot of talk in the tech industry about the performance of developers. You can hear plenty about the role of a talent, experience, and motivation. “Be a talent scout!”, “We hire only seniors”, “Give them equity” — you can hear.

But quite rarely you can hear: “Improve skills”. Even popular lately coding bootcamps focus mostly on technologies, but not on coding skills.

What is the coding skill then? Knowledge of languages and frameworks is important, understanding algorithms is helpful, and sure experience pays off. But over and over again it surprises me that one thing that might have the biggest impact on day-to-day performance is skipped most of the time. I am talking about micro-strategies.

Micro-strategies

As I’ve worked with many high and low performers in the past I started seeing a clear pattern. High performers make better use of what I call micro-strategies. These are the ways developers organize their work — minute by minute. Three most important strategies I’ve noticed are: “play with it”, “quick feedback” and “binary debugging”.

#1 Play with it

Programming is a constant learning process. Technologies, projects, code bases. The flow of new stuff never stops. And it is no surprise that the first micro-strategy relates to that.

The anti-pattern: One common habit of slow performers is to google a piece of code on the internet, copy it to the application, adjust it and get frustrated when it doesn’t work. Or when it works — simply move on to the next task. This is a very popular pattern. Copy-paste strategies lead to writing a code which the coder doesn’t understand, and therefore the code is often not fully correct.

High performers, on the other hand, might look for an inspiration on the internet. The difference is that they play with the code first. They copy it to their console, check what different pieces of code do and what comes back for different input parameters (i.e. edge cases like nil, negative, overflow etc.). They also read the documentation for methods they’ve encountered. Then they write a small piece of code to play with.

This might seem like a small difference in approach, but it makes a huge difference in performance in a long run and there are a couple reasons for that:

• When you play with the code, it is more likely that it will stay in your head for a while. Next time you don’t have to google that — just write it from memory.
• Playing builds deeper understanding of how things work, adds up to mental programming model and will make it easy to understand similar concepts in the future.
• You test real behaviors of code, not the one described on the internet, in the documentation, or worse — misunderstood. Slight differences in those might lead to subtle bugs.
• You learn about edge-cases and more likely you will handle them correctly.
• Finally, you build yourself a stream of new valuable learnings, which helps you to gain more experience at the same time.

#2 Quick feedback

A lot has been said about the fast feedback in our industry. Agile, sprints, TDD, CI — you name it. But I am talking here about something a little bit different. About how to organize your work on a minute scale. There are many ways to enable quick feedback loops:

• Write a piece of code on the console and see how it works (similar to play with it strategy).
• Edit your HTML in the browser inspector.
• Have a test project on the side where you can test newly learned methods or try new approaches.
• Writing tests (TDD) that enable you to test in isolation how given pieces of code work.

The anti-patterns in this area are:

• Write and debug — Spend half an hour writing a class, then put it into the context of an application and see if it works. If not let’s debug. Ah yeah. About debugging…
• Random debugging — trying different approaches within the context of application. Maybe the problem is in this line? No? Maybe that line? OK, maybe let’s try this line?
• Logging and print debugging — let print what is the state of code at the different points of execution and see what it is.
• Using debugger for daily coding.
• Trial and error — similar to random debugging — when you keep solving a local problem in the code and then go back to an application.

#3 Binary debugging

In general I would say: if you need to debug — you’ve already lost your way. That being said we don’t write programs in total isolation. We work on other people’s codebases, connect to the technologies we don’t control and encounter subtle bugs not always related directly to our work.

Finally, I guess it’s okay to lose your way every now and then — as long as you know how to get back on a track quickly.

Binary debugging is a powerful technique that helps to solve most bizarre problems. The axioms are:

• You can’t assume anything about the correctness of any part of the code.
• You are not allowed to make guesses about what is the reason why something is not working.
• You can only make splits in space of all possibilities, e.g. “Let see if there is a problem before this line of code?” How do we test if everything is fine up to this point?

Habits — it’s all about habits.

If any of the anti-patterns sounds familiar for you, I advise to pay attention to the way you work and try to boost up your methods. Don’t underestimate things that seem to be small — they are actually a big part of your daily work and habits. When you will adjust your methods of work and make use of these small pieces of advice, your coding will probably be much more efficient and you will also be able to learn more quickly!

If you enjoyed this post, please don’t forget to tap ❤. You can also follow us on Facebook, Twitter and LinkedIn.