This is something some of us may already have experienced: we get a call during the weekend from our project manager asking us to modify and deploy an application asap. Many times the modification might be as inconsequential as a text change in some web page.
My advice? Since the answer is in the title, I’ll cut to the chase: it is risky, irresponsible, and it’s an insult to our profession.
We are developers, not firefighters
Let’s start with the obvious: developers are not firefighters. I know we all did it as juniors, and possibly we even felt good about it. Until we noticed how risky that was: we put in production code that was not tested, we we not certain of the impact of our changes, we inadvertently deployed bits of code that were not finished…
A firefighter is a brave soul with an emergency at hand. He is trained to react. He knows what he can do to stop a fire and take everyone to safety. He does not think it through, or at least not too much: by the time he’s done thinking a strategy, the house has burned to the ground and everybody is dead. So instead he is trained to recognize situations and act fast.
A developer does not react: he adapts. Every single project is different, every situation is different. So the developer sits, thinks and comes up with a solution. Thinking takes time and focus. It requires examining the options, selecting the best one based on the context, implementing the solution using a computer language. The developer measures the consequences of his code: he acts “slow”.
So a developer and a firefighter: definitely not the same job.
What could go wrong?
But just for a moment let’s say that a developer is willing to do a quick fix and deploy it asap. What could go wrong?
(You. Yes you, the Senior Developer. I can see you’re smiling. Memories are coming back to tease you, hey?)
A few years ago I did a small fix on the front end of our project. It was just a typo in the landing page, so I did not test it and immediately pushed it into production. Then I went home.
The next day the service desk was exploding with calls from angry users.
What happened? Well, the front end code included changes that would access the new REST API from the back end, which is a separate app. But the new REST was not in production, it was still being tested in acceptance. Now, because there was another bug we still hadn’t taken care of, there was no visible error message on screen. We had a console’s error logs, but it had been removed for production by that gulp plug-in we use to clean the code before we package it. So when the web app crashed the users did not get feedback: what they saw is an empty page because their data was not loading. In the user’s terms: “My data is gone!”.
My team was not happy about it. They obviously were right.
And so I learned that, when in a hurry, many things can go wrong. Mostly the ones you didn’t think of.
You will be replaced!
So what if we refuse to work outside office hours? Many times the answer I get is: “Watch out: we will be replaced by outsourced teams of ******”. [I previously named a country here, but despite emphasizing that the quote is not by be and that I’m strictly against stereotypes… well, some readers took it personally. I don’t want to hurt or insult anybody, so I removed any reference to anybody].
The “overseas outsourcing” cataclysm argument was already doing the rounds when I started programming about 12 years ago. I’m still waiting for it…
A company asks to develop a project internally or by a team of local consultants. The estimated budget is 200. Too expensive, so the company outsources it overseas.
The outsourced team replies with a budget of 100. The deal is done. Three months later the project comes back. It’s a cluttered mess.
So the company calls back those consultants to fix things. Many rewrites after the project is done. The budget has reached 500 and the project is way past deadline.
Why? It’s a complex issue, way more complicated than “****** can’t code”, which is an oversimplification. I’d probably blame communication issues…
Then again, maybe the reason why overseas outsourcing is cheap is simply because programmers are pressurized to code for 14 hours straight while being paid a misery?
Anyway, the consequence is that the demand for in-house developers has kept on increasing since I started as a developer. Even in a country whose labor costs are exorbitant.
You have the right to remain calm
Finally, let me look at this from another angle: your self-esteem and well-being.
Many of us are probably working during the weekend. We learn new technologies, we work on our pet project, we do code katas, we watch technical web casts on Youtube… We do all these things because we love our profession. We do it for ourselves because it brings us satisfaction. We want to do it.
On the other end, we have a project manager that has never read the “Mythical Man-Month“, “The Clean Coder” or “Death March“. He is convinced that developing code merely consists of typing a few simple keywords, easy peasy. He believes Kanban is his right to ban developers from the company if they don’t code fast enough, and introducing him to Agile is a discussion that always ends up with him drooling on the floor while mentioning some very beautiful celebrity lady.
(Yes, I witnessed that. No, I still can’t believe that guy was for real…)
So that manager ruins the project with his “I-know-better-than-you” decisions. Other developers hide under the desk when he’s out looking for people to join the team to make it go faster (Mythical Man-Month, for sure). And now, after demoralizing everyone on-board, he’s asking you to stop recharging your batteries and give up your well-earned relaxation time to do a quick fix?
My conclusion is…
Just. Say. No.
A company that is not listening to his work force, dissing his experienced software engineers’ advices and sinking projects as a consequence, does not deserve your “free time” investment as a compensation for their mistakes.
We should be professionals, not tired clumsy code hackers.
The topic is not new and is nowadays extensively documented by experts, for example in the aforementioned books.
If companies keep on ignoring the lessons learned from the others’ mistakes, they will end up with teams of disillusioned programmers whose only raison d’être is to earn as much money as possible before moving to the next employer.
Cheers!