3 ms·

> …the biggest thing was we didn’t have good tests or good types, so I had to do a lot of work to do e2e testing of stuff whenever I wanted to ship stuff Shou

> …the biggest thing was we didn’t have good tests or good types, so I had to do a lot of work to do e2e testing of stuff whenever I wanted to ship stuff Shouldn't solve that one by itself after a couple iterations? If one's really testing what they wrote + surroundings because there were no tests, there will be tests over all of the codebase very fast.

sfn42 3y ago
Lot of BS excuses in there. The ones about nitpicking in reviews too, if the comment is a tiny nitpick then surely it's trivial to fix? I regularly fix a whole bunch of minor things people comment on in minutes, it only takes long if it's a big change. You can also work on other stuff while waiting for reviews. Similarly one guy complained about pipeline runs, like what? Does it take hours? Are you just waiting for it to finish? Are you not running tests locally first?
- hahahafevs 3y ago
  Most of these complaints are from people that are essentially causing the problems they complain About. They just can’t see past “must write garbage code as fast as possible” Writing docs? Waste of time Reviews? Waste of time. Usability to other engineers? waste of time. Waiting for CI because they can’t be bothered to test thing locally first? Waste of time. Stakeholder approval? lol waste of time, we don’t care if people want the software we write. Having any idea how anything works outside of whatever tiny thing being worked on? Waste of time.
  - RetroTechie 3y ago
    > Most of these complaints are from people that are essentially causing the problems they complain About. They just can’t see past “must write garbage code as fast as possible” +1. The article summarizes well as: reasons not to ship code asap. Do it right the 1st time. Failing that: make sure any fixes absolutely, 100% fix the problem, are well tested & don't cause regressions. Isn't [determine requirements], running builds, QA etc supposed to take time? Is development velocity even a goal worth striving for? Whatever you kick out the door, could be on others' systems for ages.
- dilyevsky 3y ago
  At one former gig we pulled telemetry from devs machines and lo and behold - the biggest complainers ran the pipeline twice a week or something. At this point i am convinced surveys is the worst way to go about “measuring” productivity. People are just going to tell you what they think you want to hear mixed with some self-serving bs and you will end up pouring resources into fixing the wrong things
P_I_Staker 3y ago
IME, it just becomes about: "I shouldn't have to do all this to make my one little change." You need the team on board that there could be unexpected slowdowns, due to the scope of the work being greater (or I guess you can look at test coverage during planning stage). I've been on one team that had the philosophy: "if we touch a file, all the technical debt becomes the responsibility of the team implementing" Not to say it was perfect, because if people skip technical debt once, they're likely too again later. However, so many managers in some fields would get all wound up about the potential for "unexpected issues", that we lost site of the big picture. This is how change works efficiently. Since the work was organized by file it actually becomes common sense to make everything right in the file, including in some cases unrelated changes to meet static (lint) analysis (though of course this leads to even more testing work). If it was something small, it takes so much more effort to plan a cleanup story, and execute that. Additionally, it's highly likely to be de-prioritized. Basically you want to clear the sink after you start doing dishes.

sfn42 3y ago

Lot of BS excuses in there. The ones about nitpicking in reviews too, if the comment is a tiny nitpick then surely it's trivial to fix? I regularly fix a whole bunch of minor things people comment on in minutes, it only takes long if it's a big change. You can also work on other stuff while waiting for reviews. Similarly one guy complained about pipeline runs, like what? Does it take hours? Are you just waiting for it to finish? Are you not running tests locally first?

hahahafevs 3y ago
Most of these complaints are from people that are essentially causing the problems they complain About. They just can’t see past “must write garbage code as fast as possible” Writing docs? Waste of time Reviews? Waste of time. Usability to other engineers? waste of time. Waiting for CI because they can’t be bothered to test thing locally first? Waste of time. Stakeholder approval? lol waste of time, we don’t care if people want the software we write. Having any idea how anything works outside of whatever tiny thing being worked on? Waste of time.
- RetroTechie 3y ago
  > Most of these complaints are from people that are essentially causing the problems they complain About. They just can’t see past “must write garbage code as fast as possible” +1. The article summarizes well as: reasons not to ship code asap. Do it right the 1st time. Failing that: make sure any fixes absolutely, 100% fix the problem, are well tested & don't cause regressions. Isn't [determine requirements], running builds, QA etc supposed to take time? Is development velocity even a goal worth striving for? Whatever you kick out the door, could be on others' systems for ages.
dilyevsky 3y ago
At one former gig we pulled telemetry from devs machines and lo and behold - the biggest complainers ran the pipeline twice a week or something. At this point i am convinced surveys is the worst way to go about “measuring” productivity. People are just going to tell you what they think you want to hear mixed with some self-serving bs and you will end up pouring resources into fixing the wrong things

P_I_Staker 3y ago

IME, it just becomes about: "I shouldn't have to do all this to make my one little change." You need the team on board that there could be unexpected slowdowns, due to the scope of the work being greater (or I guess you can look at test coverage during planning stage). I've been on one team that had the philosophy: "if we touch a file, all the technical debt becomes the responsibility of the team implementing" Not to say it was perfect, because if people skip technical debt once, they're likely too again later. However, so many managers in some fields would get all wound up about the potential for "unexpected issues", that we lost site of the big picture. This is how change works efficiently. Since the work was organized by file it actually becomes common sense to make everything right in the file, including in some cases unrelated changes to meet static (lint) analysis (though of course this leads to even more testing work). If it was something small, it takes so much more effort to plan a cleanup story, and execute that. Additionally, it's highly likely to be de-prioritized. Basically you want to clear the sink after you start doing dishes.