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.
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.
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).
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:
They don't understand that if they write good code covered with meaningful tests they don't do a favor to their employer. They do a favor for themselves. They learn, they practice how to craft good code. The become more employable.
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.
Do you like your job?
Some jobs suck, some workplaces suck, some projects suck, legacy code sucks most of the time.
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.
You have to find joy in what you do. And one way is to care and take ownership.
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?
But how can you not love what you do? you do it for 1/3 of your day!
I will repeat that again:
You have to find joy in what you do. And one way is to care and take ownership.
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.
Always leave the code you are editing better than you found it. (Robert C. Martin)
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.
Therefore without becoming the new rebel in your team, just keep in mind this quotes from Grace Murray Hopper:
the most important piece of advice that I can give to all of you: if you've got a good idea, and it's a contribution, I want you to go ahead and DO IT. It is much easier to apologize than it is to get permission.
Photo by bruce mars on Unsplash
Top comments (5)
Thanks for quoting my article!
These are the principles we try to foster in our team. Better ask for permission than forgiveness and the boy scout rule.
If something doesn't take a lot of time, but it would improve the developer experience (after all the quality and/or the productivity) go for it, at least show a proof of concept and then we'd see if it's really worth more time. Often it is!
thank you for your inspiring article!
It depends on whether it is easy for you to apologize. Telling you all the time no don't do this don't optimize that can be emotionally consuming as well.
The thing is that you could "sneak" optimizations as ticket deliverables. Also working from home gives you the advantage of hiding time as well so you can log less time and spend just a bit more time once requested.
sure. but the key here is understanding what we mean with optimize and sneak.
improving the code by splitting a method and writing a couple of unit tests for those methods is something that I would not even consider "sneaking in", it is just a good practice and something that should be part of the task itself. If you have to apologize for such things.. well, i guess there are bigger problems in your team/management...
agree. and in fact, even though all the team was on the same page about the necessity of having that framework everywhere, it was a mistake doing it at once on my own.
regarding changes to small parts of code, again, it depends on how small, and what you mean with "changing" them.
adding a unit test, rename a method, fix a typo, splitting big methods to make them more testable, and understandable, does not disrupt the code base not the coding experience of your colleagues.
but i agree with you, everyone should be aware. about this Dan Abramov shared a very nice experience of a code refectoring mistake he did in the past