It's 7 AM in the morning and you're the first person in the office.
You sit down at your desk and open your laptop for the first time today after making a sweet cup of coffee on the new commercial-grade espresso machine they installed just the other day and feeling for a brief moment like you're not a developer, but a barista serving drinks and talking to new folks every day.
You know you only have 2 hours before the rest of your colleagues come barging in through the door disturbing your peaceful mindset and productivity environment you just settled into.
You open your editor and check what your next task is.
Oh, right. Yet another feature the client wants to add as soon as possible, despite your team's advice that you should first refactor parts of the application in order to make the code easier to maintain. He does not understand these things and seems yet again fixated on the idea that it's just a small change he wants - surely it should not have a big impact on the timeline.
Given your razor-sharp focus level this morning, you decide that today you will do something different.
You will follow your gut and go against the client's wishes, against that pressing deadline, against your PMs requests; and so, instead of adding more code to the project, you will spend the entire day trying to remove as much of the existing code as possible without breaking all the features you've spent the last one year and half building.
Yes, everyone might get upset with you, but in the end it's for the good of the project, right?
Thinking about it, you've read somewhere that Quality is the result of a million selfless acts of care and you just want to make that first step towards quality code after a long list of neverending "improvements" that you had to add in a timely manner.
So you start assessing your options for the day:
So on you go.
You put your noise-cancelling headsets on, open Spotify, select a classical music playlist. No, wait! This calls for angry British rock or something...and you start reviewing the code.
You follow Alice down the rabbit hole into another world. A world where everything is possible and there are no rules, deadlines or expectations. It's just you and the project. You feel like it's your baby, your startup, your code again. You want to make it better, not just make it.
You see some code commented out and stop for a second...what is that doing there? Delete. We use GIT for code posterity.
The frontend has been bugging you for a while now... someone created 10 files with Redux, just to send a contact form. Delete and refactor.
A part of your backend could be refactored in a separate service... Move and delete. You're always wanted to use microservices again. This feels great!
You realise the task you've spent the last week implementing could be fixed by using a timeseries database. It could also help complete the next 5 tasks you have pending in a quarter of the time and with better performance. Research, Delete and Reimplement.
Someone taps you on the shoulder.
You freak out. It's your PM.
You've missed the morning meeting. You tell them you've made a few 'improvements' to the codebase and push your code.
The others may have a few conflicts to fix afterwards, but it doesn't quite matter - they need to accept the new reality. You made the first step. Let them follow.
Now, back to what were you supposed to work on? Oh, right - that new feature the client wanted. You estimated it to 2 days before... seems a bit long now. You re-estimate to one hour; it's just a simple database query now.
The coffee finally kicks in, you open your eyes and look around you. The PM is not there, it's still 7AM and you are all alone.
Could I have been day-dreaming or just thinking what my day could be like?
You start to wonder:
- Could I really do all that?
- Would the team/PM approve?
- Will I get fired if I did?
- Am I good enough to refactor EVERYTHING alone?
- ...
- Better stick to what worked so far... at least I can say I did what was asked of me and everyone will still like me.
Working on long-term complex projects can be hard and stressful sometimes. However, with a bit of madness and initiative, you can turn an ever-increasing and decaying codebase into a project you feel proud about.
The PM may be focused on the big picture or the next goal and the client usually wants to make sure it works as expected and that it's delivered on time.
And so, it's your job to care about how that project is built, whether it's the code you write, the design you create or the feature you test.
You can show that care by making it better every time you interact with it. Simply put "Leave it better than you've found it". This philosophy does not apply just to the world, but to everything else one does too.
Large projects accumulate a lot of something we call "Technical Debt" and it's not something visible only for developers. It can happen with design, strategy, features, marketing and everything in-between. It's those parts that Seth Godin calls, in another context, Sunk Costs and which prevent you from making the right decisions today because you've made a whole lot of other decisions in the past.
Sometimes, these things are hard to change and harder to motivate to your PM or your client, but play a crucial role in building maintainable projects.
If you can incorporate just one small activity in your daily work that could have a huge impact later on, it would probably be thinking about how to diminishing the sunk cost.
In my daily work this translates into how much bad/old code I remove from the project compared to how much I add back. How does this translate for you?
If you have any questions regarding any of my articles feel free to send me an email at: cosmin[at]around25.com
