Title should have been
"People with lower IQ jump to conclusions"
If you don't think about edge cases, you get "solutions" faster.
That's why we have so much technical debt.
"People with lower IQ jump to conclusions"
If you don't think about edge cases, you get "solutions" faster.
That's why we have so much technical debt.
Maintaining/fixing/managing the code that the star developer produces is very ungrateful work.
Surely a group of people who deem themselves 'intelligent' can broaden their perspectives a little?
And no, I am not exaggerating the time needed to fix. The weekend bender, maybe. Average case is started on a weekend and in production two weeks later. The code did not improve over those two weeks.
I’ve dealt with this half a dozen times (maybe more) in my career. Enough that I want to struggle the next “rockstar” that shows up in Slack. They generate problems and support issues faster than a room full of monkeys on typewriters.
I get even more cranky when they decide to use the opportunity to learn Go or Haskell, a programming language no one else on the team knows. And of course they fuck it up because they haven’t used a statically-compiled, strongly-typed (or functional) language before.
I’m generally a careful programmer, but I can definitely write fast and cut corners if necessary. The difference is I know what corners to cut and how to document them.
It might take me 3 weeks instead of 2, but the reduced support cost is far worth the extra week of development.
The key problem is always the same. The business wants to move as fast as possible, and developers are extremely concentrated in either the overly defensive "let us discuss ad nauseam" camp or the willing/passive "let's develop something and deliver it" camp. I don't agree with either, but frankly, I've had far more trouble convincing the former of their problem (analysis paralysis and wasting time) than the latter of theirs, and the former group is extremely convinced they have the high ground over the latter.
>I’ve dealt with this half a dozen times (maybe more) in my career.
And I've dealt with 'seniors' willingly sitting in meetings not achieving anything and pushing silly refactors more than half a dozen times only to run into performance issues, bugs and terrible deployments. User complaints don't lie, the grass ain't greener on the other side.
No, as far as the star dev goes, he's done with the project and has moved onto the next one. He's far to valuable to the company to be fixing bugs. The buggy code is already in production because he promised it was done. The fact that others have to fix the problems implies that the star dev is done.
I wrote about a specific problem, not a generalization that all fast phased development is bad. Also, nothing in my story implies that I'm justifying overanalysing.
I've seen cases that if code is not ready by Monday then the company goes bust. The code is shipped riddled with bugs. Totally justified in that case.
But more often than not "people are done after their code hits production".
"Let's have discussions until 2 weeks before the deadline for something that needs 2 weeks of development time!"
"..wait, why are we having performance issues? Why did we not think of this one case that's occurring every 5 seconds?"
People are very eager to take article's example and use it to slam individuals they have a vendetta against, while looking away from the other extreme which has the exact same problem. Going too fast is a problem. So is going too slow and LARPing as a clairvoyant, getting close to a deadline and then business forces you to get disciplined and deliver something not battle-tested.
The more right on the curve you are, the higher the chances that you met people that decided too fast than too slow.
But yeah, your probably right.
And then slow builds and decisions would have to be rewritten anyway. Usually with many assumptions baked in.
So I highly prefer fast iteration where you get at least something out for the customers to use as soon as possible.
From article: "Participants were asked to identify logical rules in a series of patterns"
The more intelligent you are, the more different rules you can come up with for a pattern. It then becomes a task of figuring out which rule the interviewer thinks is the (only) correct one.
Magnus Carlsen does not move his pieces faster than bad chess players. He thinks thru more creative options and see more useful "edge cases" than the bad players.
A lot of this thread is this sort of thinking, that the comment author is the bright one and everyone else is a dunce.
Inexperienced dev code the first solution they have.
Experienced dev challenge their first solution with one (or more) other solution(s).