paint-brush
The hardest thingby@poli
368 reads
368 reads

The hardest thing

by Santiago Ignacio PoliOctober 7th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<span>S</span> o you have been coding for a long time and you’ve been awarded with the Senior Developer Badge. And you think the time has come: You have finally entered into the club and now you’re entitled to write more complex code. So you sit in front of your laptop to write the cleverest solution to the problem you are dealing with.

Company Mentioned

Mention Thumbnail
featured image - The hardest thing
Santiago Ignacio Poli HackerNoon profile picture

Fighting the urge to intentionally introduce complexity in code

S o you have been coding for a long time and you’ve been awarded with the Senior Developer Badge. And you think the time has come: You have finally entered into the club and now you’re entitled to write more complex code. So you sit in front of your laptop to write the cleverest solution to the problem you are dealing with.

When I write code, I assume the other developers are as clever as me — Some developer I met

That, my friend, is purely wrong. Being a Senior developer is not about writing complex code, but the contrary. It’s about solving the problem the right way. Great developers find simple solutions to complex problems.

One of the main differences between a Junior developer and a Senior one is that the latter can choose to write simple code. The Junior ones are more likely to introduce a_ccidental complexity_ and write code that is harder to read. They cannot choose. In fact, Senior Developers not only should avoid writing complex code, but help their fellow developers into writing simpler code.

Some so-called senior developers

The greatest misunderstanding comes when thinking that developers are paid to write code. They are not. Developers are paid to solve problems, and being professional means solving the problems in a simple, but reliable way.

Simple code doesn’t mean crappy code, and neither means incomplete code. It means code that complies with the given requirements. It doesn’t make assumptions about the future, yet is able to grow and adapt to change. It means it’s properly tested within the specification and it means it’s properly encapsulated within its boundaries. It means it’s clean and clear, and any developer in the team can understand its intent.

If you don’t take my word for it, at least take Kent Beck’s

The hardest thing about learning to code is learning not to code. It’s true: A lot of experienced developers doesn’t feel challenged with the problems they are faced with, so they make the challenge themselves. That’s how they turn a solution that should be simple, into the most complex code ever written.


One difference between a smart programmer and a professional programmer is thatthe professional understands that clarity is king. Professionals use their powers for good and write code that others can understand. — Robert C. Martin

I’ve been down that road myself, and I can tell that sometimes it’s better to find the challenges elsewhere. For example: Taking a look at the existing code and find better ways to express it, finding missing test cases, etc. No code is perfect, so you are likely to find problems in it.

With great power comes great responsibility — Uncle Ben

Remember, as Uncle Ben said: With great power comes great responsibility. And if you are experienced enough, your responsibility lies in keeping the business going. And writing code that is difficult to understand and change won’t do that.

So that’s it. I’m not trying to impose anything here, but I truly believe if everybody takes this advice, we’ll all become better programmers.

Thanks to Hackernoon for publishing my story!! 🗞🦄