Try to lie about how long will it take. Just today I finished* 1-month almost total rewrite of firmware for one of devices at my work. It started as a 1-week small rewrite of part of communication module for a small bug and was scheduled as that. But I've got chill PM and coworkers who will appreciate that now we can actually fix some 8yr old bugs in legacy parts of that code.
* well, now some testing of edge cases and another round of fixes but at least remote code updating works so we can ship those devices...
Edit: "Lie" is call to action here, there were some misunderstanding in comments. Previous start of my comment was "Lie. ..."
Have you considered that perhaps your personal perspective is not exactly representative of large swathes of the industry and that many (if not most) workers do not have the agency and/or leeway to place place themselves in a comparable situation?
I wouldn't be so cut-and-dry with your assertion that the parent post is "lying".
Let me tell you the tale of a man named Sisyphus...
yetihehe is not accusing the parent poster of lying, they're telling them to lie. To claim the work will be X (just the feature, perhaps), and then slip in the extra work (tackling tech debt and other issues), and letting the work schedule "slip" (which they can do because they have a "chill PM").
> Have you considered that perhaps your personal perspective is not exactly representative of large swathes of the industry
Yes. HN is place for ALL kinds of people, sometimes they are not even programmers. Many tips are not applicable to everyone here.
In that case, I would heavily disagree with your suggestion. Your "chill" PM is likely actively running interference on your behalf in order to allow you to spend time on such endeavors. It's a great thing when you can have such a partner, but most PMs (in my experience) are not willing to put themselves on the line like that.
I have never in my professional career seen a solo developer rewrite something from scratch successfully in isolation. It almost always turns into the developer leaving, either because they became burnt out being the sole SME, or it fluffed their resume enough for them to find a new job. Everyone else on the team is left holding the bag.
I'm actually more surprised your manager/PM let you do this. Most of the time this happens as a skunkworks thing.
Rewrites should always be incremental, never big bang, and never in isolation.
> I'm actually more surprised your manager/PM let you do this. Most of the time this happens as a skunkworks thing.
I didn't know it will take so long, delving into this was like a frctal of bad code. When I've tried to fix something, it required fixes in other places which required fixes in another places. I could make several TDWTF posts from that code.
> Rewrites should always be incremental, never big bang, and never in isolation.
Yeah, but that codebase was not that big, so it was medium size bang. Never in isolation - there was no one other at my company who could actually do it and it was tested functionally by others once it was stable enough.
It's not lying to your boss, it's part of doing quality work.
Of course you shouldn't let perfect be the enemy of the good. You do still need to ship. I'm just suggesting that you don't let your boss know the ways in which you can increase your tech debt by cutting corners.
I've been in a similar situation and our approach was to make a business case for the rewrite.
* Original programmer who was the team lead was gone and had no interest in consulting for us
* Code was thousands of lines of completely uncommented 8051 assembly language
* Code had known bugs
* Bug fixing and documenting/understanding would likely go on for months
* We could not integrate the rest of the system functionality without a complete understanding of that undocumented code
* We were confident that one person could rewrite it in less than six weeks since we had complete knowledge of what it needed to do.
And then left it up to management as to what was the best approach. They were making a completely informed decision, but phrased the way we did, no reasonable person would have told us to continue with buggy, undocumented code that was at the heart of the system we were building.
I'm often on the receiving end of completely unrealistic estimates. It would piss me off to no end to find out that someone lied about how long they expected something to take.
First phase was about 4 years. Second phase started, and I was there in year 2 of that. 6 month contract on my part. Took me months just to figure everything out.
Background - the core engine was PHP. The 'rewrite' was also PHP.
I left, and got some updates from a few folks later. They hired some python and JS people ("we can't find/hire any PHP people!"). And... they gave the python and JS people greenfield "rebuild chunks of this system". And months later, this was all spun as "PHP sucks, node rocks". Because.. well... look what was getting done. They couldn't hire many PHP folks because... they weren't paying terribly well compared to the level of skill required to deal with the core engine.
This was far less about tech as it was management. Giving a team of JS people who are all colocated, have a working system to inspect and emulate, can choose their own tools, and are given a long time frame... it's not all that surprising they had some success compared to "let one guy go off on his own and don't talk to him for weeks at a time".
Looking back, the second guy was trying to recreate much of the flexibility of the first system, but in a 'modern' way, which was very much not a great idea (the complexity and flexibility were the core problems, from what I could tell). The node and python teams avoided implementing much of the flexibility, and they could get away with it a bit more because by that time the business was more established, and had a better understanding of what they needed and what was not.
Part of how I viewed it was "it took 12 people 8 months to recreate 20% of what one person did in PHP in a couple of years". But that's certainly putting an overly pro-PHP spin on it. ;). By all means, though, having just one person be the sole person who knows 90% of the system, with no time given to train others... huge red flag. Took me a few months to suss out just how precarious that was, and I understand the business need to spread out the risk. Was just very annoyed that the "rebuild" decision was spun as "php sucks" instead of "solo-expert-working-in-isolation" sucks.
Do most software engineering jobs not have good PM's? Asking since I started my first real software engineering job last year, it doesn't pay the best but the PM is great and very hands off. I wonder if that itself is worth holding onto the job a while.
If you have management that you like working with, and the work is pretty good, yes, that in and of itself is a pretty good reason to stay for a while.
Of course, it sounds like you have buy-in from management for these quality standards. For people who don't have this kind of buy-in for the whole team, they'll have to work individually to maintain quality.