4 ms·

Ok wouldn't have chosen the terms, but yeah there are some devs who can jump in and solve problems and others who seem to not understand the company business mo

Ok wouldn't have chosen the terms, but yeah there are some devs who can jump in and solve problems and others who seem to not understand the company business model after months or years of immersion. Those that get things done and those that seem to not even know what needs doing. Etc. So what about the -10x engineers? One trick that gets what the article calls 'weak' engineers to senior is procrastinating solving the business problems (they are weak engineers ergo they _can't_ solve the business's problems) and focusing instead on the toil of process, which they tend to inflate and extend. And this checks the boxes that managers are using to evaluate engineers and promote them. I've seen weak senior engineers completely tank whole dev orgs by overarchitecting the CI and adding gazillions of brittle tests and completely taking away any chance of the strong engineers ever getting solutions to the business's problems into production!

hnlurker22 2y ago
> I've seen weak senior engineers completely tank whole dev orgs by overarchitecting the CI and completely taking away any chance of the strong engineers ever getting solutions to the business's problems into production! Wow I thought I was the only one who saw such a thing. Glad I'm not alone
bloomingkales 2y ago
toil of process, which they tend to inflate and extend. I don’t know what to say about this. I remember this one dev who was super obsessed about code coverage (like, the actual coverage number - this detail is important). I don’t think this person even gave a shit about the tests, it just has to tick off that 90%+ test coverage metric which he was obsessed with, and the code needed to look exhaustive. I know this because that’s what his tests were exactly like. The tests were like the lamest tests ever, but they appeared comprehensive and exhaustive. It never really added much to the app, and it was just insane busy work. How do you tell a business this an absolute waste of money? You can’t because culturally code coverage is good. So I don’t even know who to blame here. This kind of shit happens constantly because we built some kinda tech culture that incentivizes it. We as an industry seem to have a really hard to time telling a 20 something (who may or may not be jacked up on stimulants) to settle the fuck down.
- chachacharge 2y ago
  Code coverage should be easy. if it's costing time, you're doing it wrong. if you're trying to apply it to an old project that did not use code coverage from the start: This is one way to do it wrong. you couldn't hold a gun to my head and make me do that. you can have a little bit of code coverage in this case, but not 85% - no. The moment it proves that it will be costing more time than it saves is the moment you can count me out.
  - bloomingkales 2y ago
    No no, let me be clear. It’s a business, my natural instincts were “this is a waste of money even if it doesn’t take much work”. It’s a business! It’s valid feedback. This is not true for all businesses, but for our business it was true. How do you tell many many many developers that the reason they shouldn’t focus on certain things is because it’s a waste of money? This not a topic that comes up a lot because most developers are divorced from the bottom line. Anyway, this topic can head off in all kinds of directions.
    - chachacharge 2y ago
      well you said it was "insane busy work" and I do not see how that is possible unless applied incorrectly. 90% plus coverage is some smoke ,for example. I don't use code coverage on most of my projects though because the teams are just one or two people, and the projects only live a few years without ever being updated. The teams would have to be bigger the updates more frequent, and the project life span longer.
- kazinator 2y ago
  I thought of a good way to break down why obsession with code coverage is poor. The same program can be represented in many different ways. And code is data. We can take the program and compile it to a byte code. We then represent the byte code as an array of bytes which is bundled with the virtual machine to make the working program. The byte code uses every instruction of the virtual machine. And so, wee, we have 100% code coverage. Of course not 100% of the byte code array is executed by the VM, but pay no attention to that. Code coverage is about code, not data! The only coverage that matters is the coverage of the state space: hitting all the cases that can occur. There isn't a nice one-to-one correspondence between control flow paths and cases. A routine which adds to unsigned 16-bit integers has 65536 x 65536 cases, but nowhere near that many paths through its control graph.

hnlurker22 2y ago

> I've seen weak senior engineers completely tank whole dev orgs by overarchitecting the CI and completely taking away any chance of the strong engineers ever getting solutions to the business's problems into production! Wow I thought I was the only one who saw such a thing. Glad I'm not alone

bloomingkales 2y ago

toil of process, which they tend to inflate and extend. I don’t know what to say about this. I remember this one dev who was super obsessed about code coverage (like, the actual coverage number - this detail is important). I don’t think this person even gave a shit about the tests, it just has to tick off that 90%+ test coverage metric which he was obsessed with, and the code needed to look exhaustive. I know this because that’s what his tests were exactly like. The tests were like the lamest tests ever, but they appeared comprehensive and exhaustive. It never really added much to the app, and it was just insane busy work. How do you tell a business this an absolute waste of money? You can’t because culturally code coverage is good. So I don’t even know who to blame here. This kind of shit happens constantly because we built some kinda tech culture that incentivizes it. We as an industry seem to have a really hard to time telling a 20 something (who may or may not be jacked up on stimulants) to settle the fuck down.

chachacharge 2y ago
Code coverage should be easy. if it's costing time, you're doing it wrong. if you're trying to apply it to an old project that did not use code coverage from the start: This is one way to do it wrong. you couldn't hold a gun to my head and make me do that. you can have a little bit of code coverage in this case, but not 85% - no. The moment it proves that it will be costing more time than it saves is the moment you can count me out.
- bloomingkales 2y ago
  No no, let me be clear. It’s a business, my natural instincts were “this is a waste of money even if it doesn’t take much work”. It’s a business! It’s valid feedback. This is not true for all businesses, but for our business it was true. How do you tell many many many developers that the reason they shouldn’t focus on certain things is because it’s a waste of money? This not a topic that comes up a lot because most developers are divorced from the bottom line. Anyway, this topic can head off in all kinds of directions.
  - chachacharge 2y ago
    well you said it was "insane busy work" and I do not see how that is possible unless applied incorrectly. 90% plus coverage is some smoke ,for example. I don't use code coverage on most of my projects though because the teams are just one or two people, and the projects only live a few years without ever being updated. The teams would have to be bigger the updates more frequent, and the project life span longer.
kazinator 2y ago
I thought of a good way to break down why obsession with code coverage is poor. The same program can be represented in many different ways. And code is data. We can take the program and compile it to a byte code. We then represent the byte code as an array of bytes which is bundled with the virtual machine to make the working program. The byte code uses every instruction of the virtual machine. And so, wee, we have 100% code coverage. Of course not 100% of the byte code array is executed by the VM, but pay no attention to that. Code coverage is about code, not data! The only coverage that matters is the coverage of the state space: hitting all the cases that can occur. There isn't a nice one-to-one correspondence between control flow paths and cases. A routine which adds to unsigned 16-bit integers has 65536 x 65536 cases, but nowhere near that many paths through its control graph.