4 ms·

> when I am supposed to fix tech debt? Try to lie about how long will it take. Just today I finished* 1-month almost total rewrite of firmware for one of devic

> when I am supposed to fix tech debt? 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. ..."

Chabsff 3y ago
> But I've got chill PM ... 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".
- Jtsummers 3y ago
  > I wouldn't be so cut-and-dry with your assertion that the parent post is "lying". 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").
  - yetihehe 3y ago
    Exactly, thanks for putting it so clearly.
- yetihehe 3y ago
  I didn't call him a liar, I told him that he should lie about what he does. Sometimes you need a little lie about how long will it take and ship good code a little later than bad code on time. > 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.
  - Chabsff 3y ago
    Oh, my bad. Thanks for the clarification. 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.
    - yetihehe 3y ago
      Staying in a place where everything is stacked against your excellency will mean you will not gain excellency. Whether just bringing some money home is enough for you is only up to you, but then don't complain that you can't do anything nice, it's just whining at that point. Saying all that I don't condemn people for working in boring shitty places. At least typically they try their best anyway and make world a better place bit by bit.
    - ryandrake 3y ago
      I've seen these people called "shit umbrellas". If your life as a developer is relatively chill and drama-free, in all likelihood you have a hero PM, PjM and/or EngM using themselves as the shit umbrella to shield you from all the madness being spewed from up above. Those are the best teams to work on.
      - HeyLaughingBoy 3y ago
        I just replied to /u/yetihehe. That is a perfect description of the PM we had on the project I was talking about. She was amazing!
- robotnikman 3y ago
  >Have you considered that perhaps your personal perspective is not exactly representative of large swathes of the industry 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.
  - eschneider 3y ago
    PM quality varies a lot and is hard to judge when interviewing for most IC roles. (As in, you often don't get to talk to those folks directly. You can ask probing questions of other folks, but feedback is a bit of a crapshoot.) 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.
shaneoh 3y ago
Where is the lie exactly?
- afterburner 3y ago
  I though he was suggesting OP should lie in order to look better?
candiddevmike 3y ago
I rewrote something from scratch, now we can finally fix all of the old bugs. Let me tell you the tale of a man named Sisyphus...
- yetihehe 3y ago
  Yeah, but that rewrite actually fixed a lot of other old bugs which we had to circumvent on server side. Before rewrite the code was just ugly spaghetti mess (interrupt routine of usart port was longer than main).
  - candiddevmike 3y ago
    The problem is you most likely introduced new bugs, created new build/test toolchains, and your team knew the previous codebase, probably quite well. 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.
    - yetihehe 3y ago
      I agree with all of your comment. This was indeed pretty unique case. No one in my small company (including me) actually knew that codebase, it was total mess written by original EE (who sayed himself he was not a programmer), it was pretty small (32kb of rom puts a limit on your codebase) by "team of programmers" standards and currently we have no one else who could actually do anything with that code, one coworker is learning to write firmware and new version is already much more readable and reasonable. It was TOTALLY in need of rewrite, but not all code is a good candidate for something like this. > 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.
justin_oaks 3y ago
In the same vein, don't tell your boss that you're going to refactor something, add tests, or write documentation. These are implementation details that you bake into your estimates and are part of doing software development. Your boss likely has no visibility into the tech debt in your codebase. Talking about refactoring, tests, and documentation gives the boss the opportunity to say "No, don't waste your time on that". 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.
- nradov 3y ago
  What we did is to explicitly list bringing any touched modules up to current coding standards as an explicit item on the definition of done. That way team members were expected to include any necessary refactoring and test coverage expansion in their story point estimates.
  - justin_oaks 3y ago
    This is a great way to increase the compliance to coding standards and test coverage. If you can automate enforcement of this, it's even better. For example, your CI build could fail (or just send out notifications) if it detects that a modified file doesn't pass current coding standards. 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.
HeyLaughingBoy 3y ago
Read your comments later about the specifics of what you rewrote. 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.

Chabsff 3y ago

> But I've got chill PM ... 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".

Jtsummers 3y ago
> I wouldn't be so cut-and-dry with your assertion that the parent post is "lying". 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").
- yetihehe 3y ago
  Exactly, thanks for putting it so clearly.
yetihehe 3y ago
I didn't call him a liar, I told him that he should lie about what he does. Sometimes you need a little lie about how long will it take and ship good code a little later than bad code on time. > 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.
- Chabsff 3y ago
  Oh, my bad. Thanks for the clarification. 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.
  - yetihehe 3y ago
    Staying in a place where everything is stacked against your excellency will mean you will not gain excellency. Whether just bringing some money home is enough for you is only up to you, but then don't complain that you can't do anything nice, it's just whining at that point. Saying all that I don't condemn people for working in boring shitty places. At least typically they try their best anyway and make world a better place bit by bit.
  - ryandrake 3y ago
    I've seen these people called "shit umbrellas". If your life as a developer is relatively chill and drama-free, in all likelihood you have a hero PM, PjM and/or EngM using themselves as the shit umbrella to shield you from all the madness being spewed from up above. Those are the best teams to work on.
    - HeyLaughingBoy 3y ago
      I just replied to /u/yetihehe. That is a perfect description of the PM we had on the project I was talking about. She was amazing!
robotnikman 3y ago
>Have you considered that perhaps your personal perspective is not exactly representative of large swathes of the industry 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.
- eschneider 3y ago
  PM quality varies a lot and is hard to judge when interviewing for most IC roles. (As in, you often don't get to talk to those folks directly. You can ask probing questions of other folks, but feedback is a bit of a crapshoot.) 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.

shaneoh 3y ago

Where is the lie exactly?

afterburner 3y ago
I though he was suggesting OP should lie in order to look better?

candiddevmike 3y ago

I rewrote something from scratch, now we can finally fix all of the old bugs. Let me tell you the tale of a man named Sisyphus...

yetihehe 3y ago
Yeah, but that rewrite actually fixed a lot of other old bugs which we had to circumvent on server side. Before rewrite the code was just ugly spaghetti mess (interrupt routine of usart port was longer than main).
- candiddevmike 3y ago
  The problem is you most likely introduced new bugs, created new build/test toolchains, and your team knew the previous codebase, probably quite well. 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.
  - yetihehe 3y ago
    I agree with all of your comment. This was indeed pretty unique case. No one in my small company (including me) actually knew that codebase, it was total mess written by original EE (who sayed himself he was not a programmer), it was pretty small (32kb of rom puts a limit on your codebase) by "team of programmers" standards and currently we have no one else who could actually do anything with that code, one coworker is learning to write firmware and new version is already much more readable and reasonable. It was TOTALLY in need of rewrite, but not all code is a good candidate for something like this. > 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.

justin_oaks 3y ago

In the same vein, don't tell your boss that you're going to refactor something, add tests, or write documentation. These are implementation details that you bake into your estimates and are part of doing software development. Your boss likely has no visibility into the tech debt in your codebase. Talking about refactoring, tests, and documentation gives the boss the opportunity to say "No, don't waste your time on that". 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.

nradov 3y ago
What we did is to explicitly list bringing any touched modules up to current coding standards as an explicit item on the definition of done. That way team members were expected to include any necessary refactoring and test coverage expansion in their story point estimates.
- justin_oaks 3y ago
  This is a great way to increase the compliance to coding standards and test coverage. If you can automate enforcement of this, it's even better. For example, your CI build could fail (or just send out notifications) if it detects that a modified file doesn't pass current coding standards. 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.

HeyLaughingBoy 3y ago

Read your comments later about the specifics of what you rewrote. 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.