Hell, even by engineering standards, tech has a lot more extremely opinionated people - with more extreme views on pretty much everything. I've always wondered why it is like that.
“Normal” engineers are the key to great teams
361–370 of 543 posts
Re: “Normal” engineers are the key to great teams
#362Earlier quoted context omitted.
I was once considered a 10X. I would work all night. Rewrite code simply because I found it objectionable - lots of things I'd never do now. Mostly after working those long hours I return after a long rest and spend most of my time fixing all the new and ridiculous problems I created while working tired. Things may have gotten done a little faster. Never once did it even matter - there was no material benefit to the…
> I would work all night. This is not a 10X programmer. A 10X programmer delivers the same amount of functionality in 1/10 the time. For me the first 10x programmer that comes to mind is Peter Norvig. This spell checker he wrote in a single flight remains a work of art: https://norvig.com/spell-correct.html Very few programmers would come up with something so concise and elegant yet powerful in such a short amount of…
I guess it’s worth pointing out that he does support one of the arguments the article makes:
> But they didn't, and come to think of it, why should they know about something so far outisde their specialty?
So yeah, he’s implicitly saying, “I have a lot of domain knowledge here.”
But that said: wow, that code is so concise and elegant, it gives me tingles. If anyone IS a 10x engineer, it’d surely have to be Norvig.
Re: “Normal” engineers are the key to great teams
#363Earlier quoted context omitted.
I was once considered a 10X. I would work all night. Rewrite code simply because I found it objectionable - lots of things I'd never do now. Mostly after working those long hours I return after a long rest and spend most of my time fixing all the new and ridiculous problems I created while working tired. Things may have gotten done a little faster. Never once did it even matter - there was no material benefit to the…
> I would work all night. This is not a 10X programmer. A 10X programmer delivers the same amount of functionality in 1/10 the time. For me the first 10x programmer that comes to mind is Peter Norvig. This spell checker he wrote in a single flight remains a work of art: https://norvig.com/spell-correct.html Very few programmers would come up with something so concise and elegant yet powerful in such a short amount of…
Yeah, he was at Google at the time (https://norvig.com/resume.html) so he was probably involved in the original development of the thing he was making a demo of.
He's definitely smarter than me with that CV but this particular project doesn't seem like some insane productivity achievement.
Re: “Normal” engineers are the key to great teams
#364Do people really question the existence of "10x engineers". It follows from Pareto distribution that some people are just exceptionally productive. That doesn't mean that its good or beneficial (depending on what the scope is). That also doesn't mean that its good to only have them, because they often carry their own baggage.
Re: “Normal” engineers are the key to great teams
#365I also have had the experience that some colleagues had worked on optimizing an algorithm for months and months. I too had looked at the algorithm and one day, almost out of the blue, I came up with a short cut that totally avoided said algorithm and implemented the required functionality with some calls to a function in standard library we were already using. Again, I was met with disbelieve when I presented the solution.
I feel that I am the guy who about once per year comes up with an idea that no one else had thought about and that most of the time I am just not very productive and often find myself daydreaming and not being very productive.
I also feel that often I am far ahead of other with respect to ideas and that I fail to convince others about a my '(too) advanced' approach. I several times have been in the situation that I proposed a solution to a problem and that some kind of manager decided to go for a simpler solution and that after months of develop time, it came to be that certain functionality did not work and that it was simply decided that that functionality was not going to be supported anymore.
Re: “Normal” engineers are the key to great teams
#366Earlier quoted context omitted.
Not op, but I'm clearly reading their message differently than you. Any type of physical engineering is based on hard facts, data, and well established historical research, mathematics, and more. I've seen many an electrical engineer say, "fuck it, this is too hard and pays too little" and so they pivoted into software engineering quite easily. On the other hand I've never seen the opposite. Real engineering is hard…
How are you reading noosphr’s comments? I read it as: “software is special because its design space is high dimensional, compared to all other engineering disciplines which are limited to 3 spatial dimensions. Large design space leads to ability to mess things up.” I wholeheartedly agree with you: “real” engineering (where lives are on the line) is hard . Most software that is made is not to control pace makers, air…
I totally agree with their post and get what they're saying.
Within circuits (big or small) it is possible to do some crazy stupid shit, but reality kicks in much sooner. Either because of physics or price.
Analog circuits (my specialty) are a perfect example of this. Sure I can try to cut corners and interconnect two distant parts of the circuit together in weird ways ("tight coupling" in software), but the options I will reach for are limited, and "nature" forces me to "decouple" them. With software I can just set a distant variable...
I have a Building Engineer on my team, who also moved to Software Engineering. I can ask for examples in his field too.
Re: “Normal” engineers are the key to great teams
#367I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…
You can have a single genuinely senior 10x engineer oversee all those efforts, executed by "normal" engineers. But no, not execute them all by the 10x engineer's self.
Re: “Normal” engineers are the key to great teams
#368Most time is wasted when you throw away and rewrite what you did.
Re: “Normal” engineers are the key to great teams
#369One more empty reaction epiphany rambling of another random-god-knows-who.
I'm seeing more reactions like this. I wonder if it's a consequence of reading AI generated drivel and not being able to tell content apart. Or perhaps people is asking for more action and less reaction. I don't know.
I find them very counterproductive, because instead of discussing actual issues and problems, people spend time justifying by all means that they’re in the “right camp”. Go outside, touch grass and actually talk to people you work in your org. Though I suspect most of those are written by ”influencers”(barf) that easier never worked with real people or don’t work anymore and want to sell their snake oil as ultimate truth.
Re: “Normal” engineers are the key to great teams
#370Earlier quoted context omitted.
Yes, exactly this. I never bought into TDD, but I can understand that it brings comfort for many normie enterprise CRUD developers... of which I am one myself!
I despise it because I've seen some absolutely HORRIBLE designs that excessively separate concerns (that are actually linked and shouldn't be) in the name of "testability". I would rather maintain 50 lines of clear idiomatic code than 1000 lines of TDD code salad full of 3 line functions that each take a bunch of fragile mocks. It's also my experience that a few well written integration tests are more useful and catc…
you mean concerns that should be seperated but they did it in a wrong way?