Should you ask permission to write better code?

Image for post
Image for post

Many years ago, I started working on a project, the code base was huge, developed by about 25 different developers over a span of 3 years.
The most recent parts were using a Dependency Injection framework, the older parts ( basically 70% of the entire code) were not.

One day, after I had finished my ticket in advance, I was so pissed I had to waste so much time to achieve something trivial, that I decided to create a branch and refactor the entire thing to use that framework.
It took me overall 2 or 3 days of work, split over many days of spare time ( whenever I had time after other tickets). Then I submitted the merge request to my Lead.
Expecting pat on shoulders and public appraisal.

Image for post
Image for post

Not really.

He was very very mad at me because I did not ask and I used my time to work on something that had not been planned or estimated.

Image for post
Image for post

On the other hand, he had a hard time hiding some satisfaction — and relief — because I did — and rather quickly — a great job, which was bringing enormous benefits to the project and save lots of everyone’s time ( and he knew that the management back then would have never approved such refactoring — that was actually quite hard to estimate)

Now I understand that that was a mistake. I should have at least share my intentions with him and especially plan more carefully a dedicated QA session for it ( because I could have added some nasty hard to find bugs in areas of the code not affected by the current sprint / planned feature).

Image for post
Image for post

Does it mean that you should not take the initiative of improving the code base you are working on?

Absolutely Not!

Some time ago I ended up on this old post here on DEV.to. which I really suggest.
As soon as I read:

I commented immediately and then kept on thinking about it for the rest of the day.

Because that sentence is exactly what I tell often to some colleagues, who complain all the time because their job is boring, because they mostly copy-paste similar code from other parts of the application or add chunks of logic to other methods.

Image for post
Image for post

Do you like your job?

If you realized you don’t like programming, you should look for something else — if you hate your boss and coworkers, well you should probably move on somewhere else. If the problem is just the project or code you are working on, maybe there is something you can do rather than just complaining.

Of course I know there are boring projects and ugly code bases that make you want to pull your hair off. But in many cases, they become ugly and messy because people do not put effort, care, love in them.

Without passion, without ownership, without fighting against complexity and entropy, the code base degrades over time: this time is a redundant chunk of code, the next time is a typo, the next time a quick workaround and so on; until it does not matter anymore what you put in it.
It’s the broken window theory. The more you find crap in your code base, the more crap you feel allowed to put in ( because, “ehi!, what’s the point in change it anyway”)

And when it does not matter anymore if you are making it worse, how could you care and be passionate about what you do?

Image for post
Image for post

But how can you not love what you do? you do it for 1/3 of your day!

I will repeat that again:

Empower yourself.
Do not wait for anybody else doing it for you.
Do not wait for somebody else to motivate you.
Do not wait for anyone to let you work better or become better.

You have to do it yourself. You CAN do it yourself

Does it mean I can refactor the codebase without asking anyone?

Speaking of Refactoring might be a bit dangerous or misleading.
I often met some of those bored employees who embarked on major refactorings that took ages and were not necessary at all.
Those are bad, even when they are allowed.
With care about what you work on and “unallowed” refactoring, I mean small things, details that just improve the code you found when working on it.

The boy scout rule is a must for me (it could be fixing a typo, split a long method into smaller readable and unit-testable ones, etc), and adding a small unit test on everything I touch when bug fixing is another one.
The boy scout rule is the only way to fight daily against code entropy, and to some extent give more purpose to everything I commit.

For these, you don’t really need to ask for permission.

Just do them, it’s part of your task.
And if you think, or are told that you are not allowed to write code that is linted and unit-tested, well then you should probably rediscuss your team’s “Definition of Done” and reevaluate how your teams do the Estimates.

You don´t need permission to be awesome

I am not, in any way, suggesting you go against your superior’s will, because that could put you under a bad light, could cause a lack of trust and in some case — and I was very close — you could even lose your job.

But the inner motivation of being proactive, of doing always your best, and ultimately caring about what you work on is fundamental to love your job, have fun with it, and in the long run, it could positively impact your career.

Image for post
Image for post

Therefore without becoming the new rebel in your team, just keep in mind this quotes from Grace Murray Hopper:

Photo by bruce mars on Unsplash

Originally published at https://dev.to on May 11, 2020.

Written by

Sport addicted, productivity obsessed, avid learner, travel enthusiast, expat, 2 kids. Technical Lead (NodeJs Serverless)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store