> 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.
> 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?
> 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.
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!
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.
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.
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.
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.
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.
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.".
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.