10 Mistakes Coders Think They’re Being Smart in Doing

We’ve all been there. As coders we all did something we thought was super-smart at the time just to have it back-fire at us and our colleagues in the end. 
Wait, did I say “we”? oh, no… I meant “them” - the other ones, not us of course. We obviously know what we’re doing, but just in case we bump into these mistakes made by others, lets make sure we know what they are and how they can be avoided :)


#1 The Single Line of Logic

Comes a time when you bump into a single line of code which has the landing procedure of NASA's eagle squeezed into it. I’m talking about something like this (taken from here):

var tablesToHide = $('table').length > 1 ? $('table') : $($('.nav > li[class="active"] > a').attr('href'));

The developer who wrote this probably thought she is being smart by saving some lines of code and using jQuery chaining, but the truth is that this is a piece of code which even she will need to read 4 times in order to understand later on. 
Relax, it does not mean you’re a poor programmer if you struggle reading a line which ends in the company’s kitchen. Function chaining can get out of hand and no one is smart by letting it lose.
One-liners of heavy (and even not-so-heavy) logic are hard to read, understand and maintain. A smart coder writes a couple more lines of code, and receives the appreciation of her colleagues and even herself when reading it later, which brings me to the next mistake…

#2 The Mad Scientist Syndrome

We are probably not the mad scientists we think we are. We’re not sitting in a dark basement lite by candles and inventing the new WWW in mysterious code no one understands but us. Sorry.
If we write vague code which no one but us can understand, it doesn’t make us smart, it makes us ego-centric, job-securing, non-collaborative dicks. 
If you work with other people, you are being smart by creating code others can take on, understand quickly and maintain.
Always think of the next person reading your code. This person might be you. If you don’t want others to approach you every minute asking what exactly you code does, make it clear to begin with.

#3 Unit-Tests? Later…

Smart developers write unit-tests, no?
well… yeah, they do, but I came to realize that the process in which we write the tests is critical. To be more precise - tests which are written after the code is implemented are bad.
It has been proven that when you write tests after the code is implemented you tend to “satisfy” the code, meaning you write tests which test the code already implemented, and if that code is not covering the whole required functionality spectrum, your tests will never cover that as well.
So we’re not being smart developers if we write unit-tests. We’re being smart developers if we write unit-tests first, a.k.a TDD.

#4 Code-Folding

Now this may raise some eyebrows… 
All of us know and use the line folding in our favorite code editor. You have some seriously long code, just smartly fold it in into these one-liners and then you can easily find your way, right?
Wrong.
If you find that you need to fold your code each time you approach it, it can only mean the following:
Too many lines of code per file or function generally indicate that the code is doing more than it should, and probably should be separated or extracted into several files/functions.
I know that this is more of a personal taste, but when I find myself in need to fold code I know that something is wrong with it. Now you can agree or not, but I ask you to do this - try to notice when do you use the line-folding and why do you use it. My guesses are that you’ll find out that the code can be re-factored into smaller parts which does not demand line-folding in order to be read easily.

#5 Write It From Scratch

So many times have I mumbled: “who wrote this piece of s#!t? if I wrote it from scratch it would be 10 times better”.
Why? cause I’m a smart developer, that’s why!
Well it doesn’t always work like that. You see, sometimes we are quick on the trigger of dismissing the time, effort, and mileage the code we’re about to replace went through, before arriving to our doorstep. Most of the “writing it from scratch” efforts ends up in falling into the same pitfalls the previous author made when first writing this code.
A smart developer respects and tries to understand the code she’s about to change before realizing it should be eliminated. I know it is easier to understand our own code rather than others, but this is not a good enough reason to start rewriting all the parts we didn’t write in the application. 
I say this with one disclaimer though - sometimes re-writing from scratch might actually be the best solution, mainly when dealing with old code which tangled through time and has become unsustainable.

#6 The Indiana Jones Syndrome

You remember those Indiana Jone scenes, where all seem lost and the walls are caving in, when Indy finds a hidden trigger which, to everyone else amazement and surprise, opens a secret door to a secret chamber that no one was supposed to enter…?
How is this related, you ask? Well, I bet you had the chance to see a developer hit some mysterious key combination which opened a backdoor into an even more mysterious logic of the application and then started messing around like freaking Neo. 
Regardless of the reasons for making it (debugging? monitoring? process shortcuts? what-have-you…), the developer creating these secret passes usually believes that he is some kind of a Dungeon Master, or a pharaoh tomb architect whose getting extra credit for traps and puzzles in his code.
These backdoors leave traces in code. Traces that aside from putting the application’s functionality and security at risk, complicate and make the code dirty, resulting in a code which is hard to understand and maintain. 
A smart develop tries to avoid these and be as clear as possible with the logic he produces. 
Just to be clear here, I’m not talking about feature-toggle, which is a concept on its own rights and has standard rules for implementation.

#7 Stick Only To What You Know

Design patterns are there to help us. Aside from providing proven solutions to common software challenges, they help us developers communicate our ideas better.
So there is no surprise that a smart developer will use design patterns within her solutions, but when a developer uses only the patterns she knows, here is where the smart turns into a mistake. 
Like in a set of tools, each design patterns addresses a certain software challenge. A hammer for a nail, a Decorator to enhance a class with extra abilities unobtrusively, keeping the same API. When a developer fails to learn other solutions and think that her tool set, which only has a hammer in it, is enough, you get a lot of bent-down, hammered-on screws in the code (have I gone too far with the metaphor here, or are we cool?).
A Smart developer uses the right solution for the problem and always explores and thrives to expand her tool set. Our learning phase is never over and that’s part of what makes our profession exciting. Developers who think they have nothing more to learn… well, you know where they can be found and lets keep it that way.

#8 Adopting The Latest Trick Around

For some odd reason, in the recent years I came to notice that coders are regarded as being smart if they adopt the latest trick around in the industry. It starts by bubbling about it for a month or two, followed by a weird implementation in the application’s core, which stops other “slow to adopt” developers from understanding and maintaining that code, and introduces yet another technology to the stack.
These smart developers have realized that they love learning new stuff, which is great. The thing is, they fail to understand that the company’s code base is not their own playground for POC’s and their colleagues are not their guinea pigs, Not to mention that sometimes there is no problem which fits the new technology so you find the “smart” developer creating one just to justify it.
A truly smart developer first understands if the new trick will actually help the project. Then checks in a side project, collects pros and cons, speaks to his colleagues and just then pushes code in if all is good.

#9 Explaining The Logic in Comments

You open the code you’re about to modify and your eyes fall on what can only be described as a short novel in a comment. In it you find a description of what the code below (if you’re lucky) does… or should do, no one really knows. You have bullets there and indentations, but me? that’s the last place I will look to understand what the code does. I will look at it to understand what the coder wanted it to do, but never as a reference to what it actually does.
A developer thinks he is being smart by writing comments, but comments do not modify with code and are rarely maintained after first written, and so you have a comment which is more confusing than helping. might as well not have it at all to begin with.
A truly smart developer writes tests. You wanna check out what my code does? read the tests. Tests alter with code and also break if code stops to satisfy them. You’ll do this and you will find that you stop writing so many comments and produce a better quality code.

#10 Doing Things Fast

Perhaps this should have been the first bullet here…
It is perceived by many that a smart programmer is one who delivers fast. Somehow this notion found it’s way to us developers, who started measuring others code quality by the time it takes them to spit it out from the keyboard to the source control.
I got rid if this twisted perspective years ago when I worked with a senior developer who used to code with a single finger in each hand at a type rate of a snail, but each line of code he produced was pure gold. You know why? because he was thinking before he started typing.
We, developers who code, are not measured by words per minute for we are not stenographers. We are measured by how good the content of our typing is. If you’re typing extremely fast and quick on the “push to git” button, I’m not thinking highly of you, but rather thinking how careless you are by risking everyone’s work with a hasty commit.
Here is an obvious one for you: A smart developer is paid to think.


So these are what I consider as “being smart” coding mistakes. We’ve all done them, perhaps some of us still do. 
I hope you found it useful and if there are “being smart” mistakes you know of, do share :)

Cheers

Show your support

Clapping shows how much you appreciated Matti Bar-Zeev’s story.