How to grow as a developer without driving yourself crazy
Image by Biljana Jovanovic from Pixabay
XML, JSON, AWS and Wordpress.
JQuery, Webpack, MySQL and Postgres.
Serverless one-click deployments and Spring?
These are (more than) a few of my most urgent things!
Web developers are surrounded by technology. The list of techs we are expected to keep up with is quite long, and going beyond a basic familiarity on these techs can sometimes be a waste of time. In this article I want to present two skills that are never a waste of time: debugging and syntax familiarity.
Be able to quickly debug code
How does that old saying go? It's more important to know how to get the cows back into the barn than to be able to keep them there.
Being able to react and recover quickly when something goes wrong is vital to keeping your code alive and the operations that depend on it afloat. And make no mistake, something will always go wrong. Even if you have the tightest team with the most bulletproof process and the most brilliant architects, it's almost a law of nature that somehow, somewhere, a critical process will be halted by an exception, or a memory leak will take down a server, or some user data will be corrupted during a migration, and so on. Or even during development, it could be that moment when everyone realizes that the feature is going to take an extra day or week to complete.
You can tell when you have not mastered the art of debugging by how you respond to these incidents. You experience a roller-coaster ride of emotions. First comes surprise and willful disbelief, then confusion and bewilderment. Then comes the surrender and abject sense of defeat, followed by anger and intense regret. Finally, there's a light at the end of the tunnel, and you start planning out how you will never, ever make the same mistake again: it only happened because we weren't creating proper setters and getters; no. It's because we didn't extend the right exception class; no. It's because our user class was doing too much. And so on.
Actually, the moment you start blaming your coding practices, you have completely missed the mark, because there is no coding practice that can totally prevent bugs. It's much better to focus on getting better at debugging.
If you are comfortable debugging code, the entire process above is simply business as usual. The appearance of a bug doesn't surprise you and you don't take it personally, because you know that software defects and mistakes are entirely normal. So you remain calm from beginning to end, forming and testing hypotheses about the source of the error, and systematically narrowing down the problem space by process of elimination. You quickly identify the method or line of code behaving abnormally and suggest a fix. All of this takes place within your usual working hours.
My main point here is that so many developers fall into the trap of trying to design bugs out of their code with patterns, style guides, class hierarchies, unit tests, and so on. After a certain point, it becomes a fool’s errand. You will never be able to create 100% bug-proof code, and you won't be able to predict which parts of your code produce the most bugs, either. So why not just embrace the fact that bugs will be found? I'm not saying that you shouldn't apply patterns, write tests, and draw design diagrams when needed. I'm only saying that the law of diminishing returns applies to these techniques. Drawing the biggest design diagrams and having the longest architecture meetings won't make your code the cleanest or most bug-free.
As for debugging, then the returns do not diminish. If you improve your debugging skills by a factor of two, your job becomes easier by a factor of two. If you get ten times better, then your job is ten times easier. And that is why debugging is the main skill you need to become an awesome developer.
How do you build your debugging muscles? There are four main ways.
Never, ever run from a bug. Even if you're too busy to help your team investigate it at that moment, follow up later and find out what the cause was. This is because real bugs in application code tend to fall into predictable categories. A mismatched data type. A squelched exception. Lack of support in a certain browser. The more bugs you are exposed to with their causes, the easier it will be to anticipate the causes of future bugs. Whenever you hear of a bug, make it your business to know what went wrong and what the solution was.
Train yourself to approach bugs scientifically. Debugging is one of the few places in life you will ever need to use the scientific method. Be rigorous and methodical. Come up with a theory; design an experiment to test that theory; then re-evaluate the theory. Repeat. Resist any kind of bias in your thinking, such as the desire to shift the blame from your code, or dislike for a particular library or coding practice. Don't attach yourself to a theory until the evidence is so strong you can no longer rule it out. Shift all discussion about solutions towards the nature of the problem and the evidence for or against the preponderant theories about it. You really have to be more scientific than scientists here.
Use multiple debugging techniques. You have a wide array of tools and techniques to use in narrowing down a problem. Most programming environments have debuggers, verbose logging, and visualization tools. Git has a feature called git bisect that can be used to quickly pinpoint the change that introduced a bug. Even more primitive methods can be useful sometimes, like adding print statements and commenting out sections of code. Do whatever it takes to get to the bottom of it.
There is a final, fourth step to being great at debugging, but it deserves its own section. That's because it will help you in all aspects of your work, and it is the second skill required to become an awesome developer.
Know the syntax of your language thoroughly
I'll start this one with an anecdote. I once had to attend a 3-day seminar at my company on how to write clean object-oriented code. The seminar consisted of a walk-through of how to approach a very simple programming problem using a predefined set of techniques. The speaker, who we'll call Professor Smith, was well-known among developers for authoring books and giving classes on this topic.
Professor Smith brought along an assistant, and throughout the seminar, would constantly refer syntax questions back to this assistant. "Can I write this operator here? Okay, moving on…" "I can call this method here, right? Oh, well, let's try another way…"
When one of my co-workers showed Prof. Smith some real code from our application and asked: "What should we do to improve this?", Professor Smith was completely unable to offer any insight. "I guess, break it into two methods? No, that won't help because of these parameters. Make an object to contain the side effects? Hmm, that won't do, either." After floundering for a few minutes and not even attempting to run the tests, Professor Smith moved on.
I was taken aback by this. How can this person be up here giving a lecture to us developers about coding practices without having any chops?
It seems like it goes without saying that if you want to be an expert developer, you have to know the syntax of your language on an expert level. Yet somehow, this point is missed by the majority of people. You should be able to look at any line of code and immediately break it down into pieces in your mind. You should know exactly what the most common error messages mean, without having to look them up. You should have at least some of the standard library API memorized. It's true that with Google and Stack Overflow, you don't really need to know this stuff. But having it already in your mind helps you make technical decisions and gives you an extra boost of speed — not to code faster, but to see further.
Here are some tips for increasing your syntax knowledge:
Read a reference book. This is something a lot of people miss out on. Go buy a nice, thick, up-to-date reference manual for your language, and actually read it. Read it twice or three times if you like. The least you can do is buy it, put it on your desk, and read the table of contents.
Enable syntax highlighting in your editor. Syntax highlighting activates a biological shortcut, color, to aid in the processing of visual information. Find a plugin for your editor that can colorize strings, numerals, constants, method names, and reserved words, at the very least. Color-matching for parentheses is a plus. And choose a color scheme pleasing to your eyes.
Do coding exercises online -- sloppily! It's great to apply a standard of quality to your work, but just don't make it a crutch. You should be just as comfortable working with sloppy code as you are working with clean code. The key to really building your chops this way is to choose exercises that involve a lot of coding and not a lot of thinking, like translating data from one format to another, and resist any temptation to play architect. If you find that you can't make any progress without refactoring over and over again and designing long class hierarchies, take it as a sign that your coding skills aren't where they need to be yet. Train yourself to be perfectly capable working with a big ball of code mud, even if you have to really hold your nose!
Conclusion
Developers are quite well-known for making our own lives more complicated than they need to be. If you’re looking to level up in your career, make sure you spend just as much time on the basics as you do following buzzwords, if not more. It’ll help you more in the long run.