4 ms·

> His code is not elegant, it barely works, requires constant full rewrites, is an endless source of segmentation faults, deadlocks, sleep() in the main thread

by pif 3y ago

> His code is not elegant, it barely works, requires constant full rewrites, is an endless source of segmentation faults, deadlocks, sleep() in the main thread and whatnot. A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader. Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance. Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business.

quickthrower2 3y ago
Not testing your code though. Places that value that shit speed at any cost eventually go bust, it is not smart and indicates a dumb culture which probably carries over to strategy and financials. That has been my experience. There is a basic level of standards. No need for architectural astronauts or monad fanatics but some sanity!
- pif 3y ago
  > There is a basic level of standards. I agree with you, and it's very simple to define such a level: use as much discipline as you need to ensure shipping features at an acceptable rate in the long term. Too much polishing lowers your release rate. Too little discipline will hurt the "in the long term" part.
  - quickthrower2 3y ago
    Thats a good way to put it. Shipping value rather than features though. Which is represented as long term shareholder value, but within some kind of ethics (don’t fuck the customer type stuff). Thinking in terms of value could mean you sometimes suggest weird things like removing features, cancelling WIP (sunk costs) etc. when appropriate. Or spending way more time polishing than seems necessary or conversely getting something out that looks way too quick and dirty. There are cases where no tests are OK despite what I said but usually MVP stage stuff where no market fit exists yet.
- arethuza 3y ago
  "Places that value that shit speed at any cost eventually go bust" That has not been my experience...
  - quickthrower2 3y ago
    Have you experienced just speed. Or speed at any cost? I.e. releasing really buggy features that customers complain about and churn on? Obviously with enough VC and marketing dollars anything could be possible.
guappa 3y ago
> A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader. But the functionalities don't work and generate customer support load… I should perhaps mention the time he compiled a binary on his machine, committed it on github and went on vacation. And then we couldn't fix the bug that needed urgent fixing. > Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance. We do have customers yes. > Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business. You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?
- pif 3y ago
  > But the functionalities don't work and generate customer support load… And this is the first issue you should have mentioned! All the rest is peanuts...
- pif 3y ago
  > You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist? I'm not defending him. I'm just refuting that a developer's competency can be judged without taking into consideration, first and foremost, the benefits he produced for the users of his software.
switchbak 3y ago
Shipping broken, especially code that looks ok but it secretly broken - is far worse than having no code at all. Once it's in place, it gets dug in like a tick, and if it's a pile of poor assumptions and wrong logic, you're in a much worse spot than you were with a clean slate.
Apes 3y ago
If everyone else is spending all their time cleaning up the broken shit he built but won't fix, and he continues to produce more broken shit faster than everyone else can keep up with fixing it, he is a 10X programmer. Not because he's actually 10X better, mind you - he just makes everyone else 10X slower.
mcguire 3y ago
Corollary 3: This is one reason why many businesses deliver one product and then sink without a trace. Corollary 4: Never buy version 1 of anything.
- IIsi50MHz 3y ago
  4.1.00175-update3: Never buy version x.1 from a company that never ships version x.0 of anything. This kind of company is often run by people who think "People don't buy x.0 because they're afraid of bugs, so always ship x.1 as though we fixed the bugs." while failing to actually do the QA to earn that version bump. Which predictably results in customers refusing the company's x.1 because, in their own words, "I'm not going to pay to be their beta tester.".

by pif 3y ago

quickthrower2 3y ago

Not testing your code though. Places that value that shit speed at any cost eventually go bust, it is not smart and indicates a dumb culture which probably carries over to strategy and financials. That has been my experience. There is a basic level of standards. No need for architectural astronauts or monad fanatics but some sanity!

pif 3y ago
> There is a basic level of standards. I agree with you, and it's very simple to define such a level: use as much discipline as you need to ensure shipping features at an acceptable rate in the long term. Too much polishing lowers your release rate. Too little discipline will hurt the "in the long term" part.
- quickthrower2 3y ago
  Thats a good way to put it. Shipping value rather than features though. Which is represented as long term shareholder value, but within some kind of ethics (don’t fuck the customer type stuff). Thinking in terms of value could mean you sometimes suggest weird things like removing features, cancelling WIP (sunk costs) etc. when appropriate. Or spending way more time polishing than seems necessary or conversely getting something out that looks way too quick and dirty. There are cases where no tests are OK despite what I said but usually MVP stage stuff where no market fit exists yet.
arethuza 3y ago
"Places that value that shit speed at any cost eventually go bust" That has not been my experience...
- quickthrower2 3y ago
  Have you experienced just speed. Or speed at any cost? I.e. releasing really buggy features that customers complain about and churn on? Obviously with enough VC and marketing dollars anything could be possible.

guappa 3y ago

> A lot of negative points, indeed, but the first priority is to ship new functionalities. If he was the only one focused on shipping, while you others loved to get lost in useless architectural debates, he was the best candidate to team leader. But the functionalities don't work and generate customer support load… I should perhaps mention the time he compiled a binary on his machine, committed it on github and went on vacation. And then we couldn't fix the bug that needed urgent fixing. > Corollary 1: clean, maintainable code is only important when you have customers expecting maintenance. We do have customers yes. > Corollary 2: in the Real World (tm), the alternative to technical debt is getting out of business. You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist?

pif 3y ago
> But the functionalities don't work and generate customer support load… And this is the first issue you should have mentioned! All the rest is peanuts...
pif 3y ago
> You're defending this guy so much… why so defensive? Do you reject the notion that incompetents exist? I'm not defending him. I'm just refuting that a developer's competency can be judged without taking into consideration, first and foremost, the benefits he produced for the users of his software.

switchbak 3y ago

Shipping broken, especially code that looks ok but it secretly broken - is far worse than having no code at all. Once it's in place, it gets dug in like a tick, and if it's a pile of poor assumptions and wrong logic, you're in a much worse spot than you were with a clean slate.

Apes 3y ago

If everyone else is spending all their time cleaning up the broken shit he built but won't fix, and he continues to produce more broken shit faster than everyone else can keep up with fixing it, he is a 10X programmer. Not because he's actually 10X better, mind you - he just makes everyone else 10X slower.

mcguire 3y ago

Corollary 3: This is one reason why many businesses deliver one product and then sink without a trace. Corollary 4: Never buy version 1 of anything.

IIsi50MHz 3y ago
4.1.00175-update3: Never buy version x.1 from a company that never ships version x.0 of anything. This kind of company is often run by people who think "People don't buy x.0 because they're afraid of bugs, so always ship x.1 as though we fixed the bugs." while failing to actually do the QA to earn that version bump. Which predictably results in customers refusing the company's x.1 because, in their own words, "I'm not going to pay to be their beta tester.".