Code Trashing Symptom | Hacker Noon

@eyalyoliEyal Yoli Abbas

A software engineer in my blood, co-founder and a CTO at FocalPoint Digital.

There are a set of skills and qualities which make the ideal software
developer we are all searching to be or searching for to employ. However, right now I am going to emphasize the importance of a quality that is mostly found in senior developers.

As a beginner, I remember the enthusiasm when I implemented my first app. It was in VisualBasic v6.0 with very basic UI and logic. From there on,
it was very hard to leave the keyboard without writing code daily. At
first, it was VB, then some HTML, JavaScript (when it was very buggy),
Java, and sometime later I became a true working developer/team-leader
for many years.

Reliving those days when I was an enthusiast developer, I remember the powerful feeling that kept me on my path. I was (and still) addicted to code. But it is not code I was after. It is the vast feeling of creating something your own. Creating something from within. This strong feeling of a new creation is addictive.

The problem with addiction is that you don’t recognize the limits of
yourself and your creations. Consequently, you are not guided by your

As a leader of development teams in different projects, I came across a
variety of situations with different developers. But this same question I kept hearing from time to time, “This is a great piece of code, do you really want me to remove it?”, and it is really a great piece of code with the ultimate design.

But what you shouldn’t forget that you and your team are here to accomplish something meaningful for your clients and users! Thus writing a greatly designed code with low correlation to requirements isn’t going to change anything.

When I moved to my current team and project, I found out that the project’s code was written beautifully and well designed. But it was insignificant to our client’s future requirements.

One of the best decisions I made was to gradually re-implement (remove old code and write a new one without reference nor copy-pasting any parts). The reason being the already written code was a big hurdle to bend to any new requirements we received

Sometimes it’ll be hard to ask for, especially when you’re asking the original author of the code. But always remind him of these facts: your main focus is your clients; if you miss your code, Github will always remember it for you.

Acknowledging your addiction to code is your first step to overcoming your unconscious desire to create worthless stuff that no one will use (and believe me, it hurts more to find out that your code is useless than
removing a code you’ve written).

Final Thoughts

From my personal experience, when you implement something hard to solve the first time, most of your energy and thoughts are invested in solving the problem and not in the most relevant design for the given requirements.

Rewriting the same code a second time gives you a second chance to spend your time (almost solely) in design (since the problem is already

The best design is a design made for the current (known) requirements and not future mystic stuff that we just came up with.

Remember: Refactor! Don’t predict!

Previous published on:

Lead image by Steve Johnson from Pexels


The Noonification banner

Subscribe to get your daily round-up of top tech stories!

read original article here