Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

Post reply on HN
Print view View original

481–490 of 543 posts

Re: “Normal” engineers are the key to great teams

#481

Post by hinkley »

logsr wrote: post #78
strangattractor wrote: post #22

Earlier 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…

> Focus is a super power this is crucial. from my own productivity I know that I can function at 1X or 10X depending on my focus. being a great engineer requires practice most of all, and the consistency of focus during that practice will impact its value. in my experience, engineering is all about efficiency, and as i have developed over time the scope of factors i take into account when calculating the efficiency o…

> engineering is all about efficiency

See, that’s a problem.

Engineering is all about effectiveness. Not efficiency.

Focus is great for slamming out a bunch of code that everybody else hates and has to tiptoe around you about because focus also made you so goddamned proud of your monster. Slow down and check the signposts before following your good intentions all the way to the end.

Re: “Normal” engineers are the key to great teams

#483

Post by hinkley »

xandrius wrote: post #387
strangattractor wrote: post #22

Earlier 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…

If you work twice as long as most, make code which is dubious/broken, take initiative out of sheer personal opinions and have to spend time the next day fixing your mess, that would be the definition of a 0.25X programmer. It took you 4 times as long to bring value to the company, you had lot of enthusiasm but were not using it right. Being a kX (k > 1) means that you need to work fewer hours to accomplish the same a…

10x is mostly theater. I’ve worked with 3x engineers that made everyone else better, and 3x engineers that make everyone else much worse. 4 times out of 5 a manager will point to the latter as 10x because he is getting so much more done than the people he has crippled and been loud about it the entire time. The former does well when their boss is that 1 in 5 person, but they are often fucked if the boss leaves.

Re: “Normal” engineers are the key to great teams

#484

Post by hinkley »

nntwozz wrote: post #46
strangattractor wrote: post #22

Earlier 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…

"Focusing is about saying no." — Steve Jobs https://www.youtube.com/watch?v=YgL8fpya8BA

There was a great article a little while back about how “yes, but” is powerful but “no, but” is almost as powerful.

No we won’t do that, but we can do this. Or that is trickier than it sounds but we will think about it until it makes sense.

Re: “Normal” engineers are the key to great teams

#485

Post by hinkley »

dennis_jeeves2 wrote: post #359
strangattractor wrote: post #22

Earlier 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 was once considered a 10X. I would work all night. You are part of the toxic culture until you realized that was that it is overall counterproductive. Collectively we software developers are to blame and no one else.

The thing about codependent relationships is that both parties are guilty. And this has definitely been a banger of a codependent relationship.

Re: “Normal” engineers are the key to great teams

#486

Post by __loam »

gilbetron wrote: post #192
0xB31B1B wrote: post #117

I 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…

In my 40 years of professional software development, rarely have I seen such an uninformed post. And ignorant. Did I mention ignorant? I've been the "10x" developer, multiple times. And there certainly are poor performers and exceptional performers, but great teams makes great software, not great individuals. The analogies are numerous. You can look at a great (american) football team and see the Quarterback as the 1…

Even in the examples he gives, I'm sure Linus would be the first to admit that Linux has a lot of maintainers that have been essential for the project.

Re: “Normal” engineers are the key to great teams

#487

Post by vineyardmike »

asdff wrote: post #251
ambicapter wrote: post #111

Earlier quoted context omitted.

I don't think it "attracted" a certain kind of people, I think the people who were already in tech just became more wealthy and powerful, and that, predictably, brought out the worst in some. The worst qualities of "tech" people can be conflated but I think have a different flavor than the worst qualities of "finance" people. It's really just the same obnoxious behavior you can spot in young tech people. Some people…

People in the trades relatively speaking in the midwest are easily far more wealthy than engineers in the bay area, and they have no such delusions of grandeur seemingly. They seem to understand that an electrician is an electrician and an engineer is fungible. That is why many of these engineers are unionized as well because they understand labor is replaceable and needs to advocate for itself. The coasts have much…

1. The data absolutely does not show that midwestern tradesmen are wealthier than Bay Area engineers.

2. I agree that unions are useful, and you’re starting to see them (eg Alphabet Workers Union). There is definitely opportunity here.

3. I think your visions of non-grandeur are blinding you to the possibilities that others live life and advocate for themselves differently, without it being wrong. Sometimes change is ok and sometimes people being different from you and your beliefs is ok.

While I do think unions are important, Silicon Valley engineers are responding in-kind to their fungibility. It’s pretty common to see people jump around every few years, chasing opportunities instead of loyalty. Usually collecting a pay bump. It’s generally not looked down upon in hiring, because it’s increasingly normal, and the extra pay and corresponding savings protects against periods of unemployment. Regardless of people’s thoughts on the practice, “resume driven development” grew as a reaction to the fungibility - forcing their own self-growth upon a disloyal employer.

Big urban areas with lots of job opportunities are difference employment environments, and employee’s actions of self protection evolved differently. Is there room for learning? Always. But this entire comment seems to pass judgement upon a world that frankly doesn’t exist.

As a Bay Area resident who once lived in the Midwest, I can confidently say that people on the coast don’t have such a negative view of “corn lands” - this narrative is very much self imposed.

Re: “Normal” engineers are the key to great teams

#488

Post by khazhoux »

nextts wrote: post #373
khazhoux wrote: post #356

Earlier quoted context omitted.

Your post is super offsensive. And true. The number of times I've reviewed someone's code that's been "in progress" for 3 weeks, to see it's 200 lines of simple python code... ugh " oh, but it was really actually complex and you just don't get it " --> Incorrect

Or maybe they aren't pushing flaky shit into prod and actually thinking about their work. Maybe they did 1k lines (counting lines LOL!) of code reviews, fixed some bugs, helped on an outage etc. Fuck. This one dimensional view of things. Look how any company makes money. Let's say Google. It is not by the number of lines of code.

I don't know how many engineers and different engineering teams you've worked with. But I see this all the time.

I worked once with a young engineer that spent 3 weeks for 2 lines of code. We celebrated him as a fucking superstar, because those 2 lines were in a low-level linux library, and he went so deep to find that bug, it was insane. He earned the reputation as one of the top problem-solvers in a multi-hundred person org.

So that's not what I'm talking about. I'm talking about the developers (so many of them) who spend 2+ weeks in standups saying they're "working on automating the deployment", and when it's done you look at their code, and it's an argparse block followed by 6 lines of calling docker with trivial parameters. You've seriously never seen this? Lucky you, then.

Re: “Normal” engineers are the key to great teams

#489

Post by khazhoux »

flavio81 wrote: post #439
khazhoux wrote: post #356

Earlier quoted context omitted.

Your post is super offsensive. And true. The number of times I've reviewed someone's code that's been "in progress" for 3 weeks, to see it's 200 lines of simple python code... ugh " oh, but it was really actually complex and you just don't get it " --> Incorrect

So, you think productivity or even quality can be measured in "amount of lines of code produced". Which is completely wrong.

When a developer takes weeks to come up with trivial code, they are not productive.

I understand that complex problems can (should) be solved with simple code. That's not what I'm talking about.

Simple problems should be solved with simple code, and good developers do this quickly. If someone takes 3 days to figure out how to make a one-line REST api to a well-documented service, they are not productive.

Maybe I just unfairly expect developers at top companies to be able to not get stuck at every step and to not get confused by basic programming. I probably just need to recalibrate and understand that what I consider to be slow developers (certainly by comparison to the many excellent people I've worked with), are actually the norm, and I should just be OK with that.

Re: “Normal” engineers are the key to great teams

#490

Post by araes »

antonvs wrote: post #446
grandempire wrote: post #253

Earlier quoted context omitted.

That’s why the bill gates story got so much public attention. It’s surprising. Their Harvard kid is doing what?

I suppose it may have been surprising to anyone completely out of touch with what was happening at the time. I'm only a little younger than Gates, and it seemed like, what else would you do? PCs were revolutionizing the world.

A slight addition to this topic. A lot of jobs also became software, even if your intention in signing up for the jobs was different to begin with. PCs were revolutionizing the world.

For about a decade I worked as an engineer in a field where the expectation (at least starting) was that metal gets cut, stuff gets built, and there's physical hardware.

Those existed. May have actually had more hardware interaction than many in engineering. Yet much of the day to day rapidly became computer simulations of the metal that might get cut someday.

In many fields, the organizational choice decrement on anything involving capital expenditure or purchase was so severe that usually the obvious choice was to run a computer model, and simulate what might occur. What else would you do?

Post reply on HN