4 ms·

My personal experience is that the majority of developers I ever encounter at work (as opposed to within my social network) are usually slow because they're bad

My personal experience is that the majority of developers I ever encounter at work (as opposed to within my social network) are usually slow because they're bad engineers who don't understand problems quickly, don't have the knowledge or experience to see solutions quickly, and in general don't think deeply quickly. It's not hard to 3x performance without sacrifices when the baseline is mediocre at best. "Fast must be cutting corners and not just actually better at programming" is a weird fallacy to hang your hat on.

3-cheese-sundae 3y ago
There is always a cost to everything.
- BugsJustFindMe 3y ago
  > There is always a cost to everything. There's a huge cost to having engineers who are bad at understanding and solving problems. The cost of having people who are good at understanding and solving problems is supposed to be that you pay them more, but that's not how employment incentive structures work in practice because information asymmetry and stigma around talking about salaries.
webdood90 3y ago
> the majority of developers I ever encounter at work are usually slow because they're bad engineers hm, something about this that I just can't put my thumb on
- screye 3y ago
  "Majority of people who drown cannot swim."
- xupybd 3y ago
  It's a bit elitist[1]. They're saying we should expect 3x better performance from engineers. We should also expect them to write good code at this pace. The only reason we don't have these things is that most engineers are simply bad engineers. Only people the author perceives as good enough should ever be used as a metric of normal productivity. Presumably the author puts themselves in this group of good engineers. 1. https://en.wikipedia.org/wiki/Elitism
another-dave 3y ago
While this is true, if a job ad is telling me that that's _their_ experience of their average hire, it's probably not somewhere I want to work!
- BugsJustFindMe 3y ago
  I agree (unless they also pay you three times as much, in which case fair enough).
kaba0 3y ago
Especially in CRUD settings when if people would just bother to learn at least a bit about the framework, they could outsource most of the code to that. It’s not like that filtering you have to implement is some brand new discovery that has never been done before.. these apps are literally fancy excel tables very often.
otikik 3y ago
I used to work with this kind of developer. He was bounds and leaps faster than all the other developers in the team. The code he produced was absolutely and completely unmaintainable. The joke was that this guy could program C in any language. His code kindof-sort-of worked, but only he understood it and when anyone else had to take over his stuff, the first thing they had to do was rewriting the part from scratch. Of course there were no tests, so when the new person broke something in their attempt to try to work with their code they were scolded. The person in question was the CTO of the company, by the way. He was 3x alright, but at the expense of everyone else on the team. I was very glad to see him go.

3-cheese-sundae 3y ago

There is always a cost to everything.

BugsJustFindMe 3y ago
> There is always a cost to everything. There's a huge cost to having engineers who are bad at understanding and solving problems. The cost of having people who are good at understanding and solving problems is supposed to be that you pay them more, but that's not how employment incentive structures work in practice because information asymmetry and stigma around talking about salaries.

webdood90 3y ago

> the majority of developers I ever encounter at work are usually slow because they're bad engineers hm, something about this that I just can't put my thumb on

screye 3y ago
"Majority of people who drown cannot swim."
xupybd 3y ago
It's a bit elitist[1]. They're saying we should expect 3x better performance from engineers. We should also expect them to write good code at this pace. The only reason we don't have these things is that most engineers are simply bad engineers. Only people the author perceives as good enough should ever be used as a metric of normal productivity. Presumably the author puts themselves in this group of good engineers. 1. https://en.wikipedia.org/wiki/Elitism

another-dave 3y ago

While this is true, if a job ad is telling me that that's _their_ experience of their average hire, it's probably not somewhere I want to work!

BugsJustFindMe 3y ago
I agree (unless they also pay you three times as much, in which case fair enough).

kaba0 3y ago

Especially in CRUD settings when if people would just bother to learn at least a bit about the framework, they could outsource most of the code to that. It’s not like that filtering you have to implement is some brand new discovery that has never been done before.. these apps are literally fancy excel tables very often.

otikik 3y ago

I used to work with this kind of developer. He was bounds and leaps faster than all the other developers in the team. The code he produced was absolutely and completely unmaintainable. The joke was that this guy could program C in any language. His code kindof-sort-of worked, but only he understood it and when anyone else had to take over his stuff, the first thing they had to do was rewriting the part from scratch. Of course there were no tests, so when the new person broke something in their attempt to try to work with their code they were scolded. The person in question was the CTO of the company, by the way. He was 3x alright, but at the expense of everyone else on the team. I was very glad to see him go.