Don't enthusiastically agree to rewrite the system at work(blahaj.bearblog.dev) |
Don't enthusiastically agree to rewrite the system at work(blahaj.bearblog.dev) |
I think maybe if you're at a company like that, you should be very cautious in suggestions/timeline/etc about literally anything and everything technical. Certainly much more than you would be at a company that has a basic level of software engineering competency. It's kind of a different world...
At the same time, don't tackle everything at once. Cut it up into pieces, define interfaces between different parts, make sure the behaviour is documented in test cases. That way you'll be able to refactor parts of it while keeping the system working.
Go from working system to slightly better working system. It might seem like the overhead would take longer, but your sanity will save you much more time. You'll be able to quit or pause and maybe implement some new feature for the newly redesigned part, to keep business happy and to show that the refactor does help.
The second best solution is to just reiterate your original timeline and say NO(even if you do it quietly) when anyone tries to change it. If they keep meddling and trying to get you to work off hours, let them lay you off. The important thing to remember is a CEO and execs are helpless. Don't sacrifice yourself to shield them from their own mistakes and incompetence.
If they miss the deadline, they just spin another lie to the customers. To this developer, this work was the most important work of his life. To the ceo, firing him before anything is finished and spinning a lie to customers is just another tuesday.
“We’ll design it, test it, release it, and never touch it again !”
> "I'm hoping to close them out soon, ideally before I run out of goodwill."
Your goodwill is already depleted, time to move on.
And in terms of accountability/feeling the impact of their poor decisions - the blog is already describing them throwing the engineer under the bus, telling them they need to pull their weight, blaming them for mistakes, etc. Management isn't going to feel the impact of anything. Theyve got a convenient fall guy right there and they're already setting him up to take the blame if stuff goes south.
Sometimes stuff just sorta sucks ¯\_(ツ)_/¯
Be honest and look for someplace better if they refuse to accept it. That is in my opinion the only way to handle this responsibly.
The problem is that everybody has multiple responsibilities: if finding a new job is hard, and you've got rent to pay and a family to feed, you get into the territory of balancing the risks. Even so, I think it's always best to be clear and honest in your communication about timelines and expectations. If they reject them and insist on unrealistic timelines, point out the problems with those timelines, tell them it's their responsibility if it fails, so they can't blame it on you when it does fail.
Also, > tell them it's their responsibility if it fails, so they can't blame it on you when it does fail.
That's definitely not how any of this works. They can absolutely blame whoever they want and often have the power dynamic in place to get away with it. Especially in this case where they'll just say the author was given a senior title and a raise so it's on them to deliver and their attempts to shift the blame to management won't work to cover up the engineers failure to deliver etc. You just have no leverage as an engineer joining a company that doesn't care or doesn't need devs to the extent they go extended periods of time without a single one. And if you don't build that leverage within the company you pretty much have no option but to go somewhere else if put in a bad situation.
> And if you don't build that leverage within the company you pretty much have no option but to go somewhere else if put in a bad situation.
I think that's often the better option, when the situation is that toxic. Better than staying.