Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

471–480 of 543 posts

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

#471

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

I spend at least half of my best days working on making our bad days better.

The thing about being intelligent is that you have the capacity to find wisdom faster. I’ve worked with too many intelligent fools, and nearly all of them quit rather than face the consequences of their own actions.

I tend to stay too long, either cleaning up after my own messes or someone else’s. Maybe I watched too many westerns as a child. Who knows.

But I’d rather work with someone wise who can’t reinvent bloom filters from first principles than someone who could, and thinks doing so is a good idea.

There’s an ethical trap where you think you’re the only one here who can make something work, because now you’re on the hook to support it and if you have a negative opinion of your peers, how is that going to work out, do you think? Did you think? Or were you too busy wondering if you could do it to think about whether you should?

I think the advice, “never be the smartest person in a room” is just about the biggest bullshit in tech. Intelligent people cannot teach you to be like them. They can’t change your brain much more than you already have, just surviving school and university. But a wise person can teach you three new things before lunch, sometimes without even trying.

Don’t be the wisest person in a room, and if you must be, don’t denigrate the wisdom of beginners. Good teachers learn from their pupils.

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

#472
post #419

Earlier quoted context omitted.

No. The engineer is ultimately responsible for the product. If a bridge falls, will the engineer wash his hands?

No, and neither will a software engineer wash her hands of a bug , but a construction engineer isn't responsible for the layout of a building being overly labyrinthine—that's on the architect. Likewise, product managers and designers who are talking to customers and conducting user experience research have the context to make decisions that engineers can't reasonably second guess.

We may be thinking of two different roles, which might fall under the engineer umbrella. When I think of an engineer (and especially so a 10x or elite engineer), they design and invent and create and have absolute control over what they do.

If an engineer doesn't have control or follows the designs of an architect, they are merely in an executor role, and their engineering skill is put to use not in inventing or solving a problem but merely executing.

There's a time and place for that, but it's definitely not the dream when I think of the engineer I would want to be.

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

#473
post #51

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

Software is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral fo…

Hyperbolic space indeed.

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

#474
post #20

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

>These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. Didn't we pass the rubicon on that in the early 2010s? I personally don't feel that its "like" finance but that its the exact same behaviors from the exact same set of people. Once tech stopped being a bunch of nerds in a basement and started being a source of wealth and power, it…

The story is that the reason Boeing got eaten by McDonnell Douglas is because the MD execs were meaner than the Boeing execs and they used their sharp elbows to take over a company that was objectively doing better than they were. And it started showing signs of unravelling on the first airplane they built under the new regime and has only gotten worse since.

The 787 did something Boeing vowed they would never ever do. They let Mitsubishi build the wings of the 787. They’ve never let a supplier do that. The wings are the heart of the airplane. I am completely amazed that Mitsubishi never progressed past commuter jets after that project (and I believe they shut that division down about 5-10 years ago). Just unfathomably dumb.

I don’t know what we in software need to learn from this. I don’t think being meaner makes anything better, but maybe more assertive is the answer.

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

#475

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

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’ve had too many experiences of starting a project at noon on one day and getting fixated on finishing it and failing, then after some sleep and reflection ripped half of it out and finishing the new idea before lunch, which isn’t even my most productive time of day.

If I’d had this perspective the day before I would have been finished before 5. But I got wrapped up in thinking I was close and I should have stopped for air.

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

#476

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 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 use his sudoku solver design to learn new languages and as an example of intrinsic versus accidental complexity.

Uncle Bob tried and failed to use his own strategy of many small functions to solve sudoku. There’s been a lot of Trough of Disillusionment talk about him lately. My impression of him is that he’s got the right code organization idea but for the wrong reasons, and so his ends often don’t justify his means. It’s a common pattern in software to guess the wrong reasons why something works, and then overfitting to the wrong reasons.

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

#477
post #373

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.

[deleted]

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

#478
post #257

Earlier quoted context omitted.

This is what happens anytime a field gets large in terms of job applications. Replace software engineer with anything else to that measure and you see the same things with wealthy families being overrepresented in the cohort because they always have an edge in getting the best credentials due to not having to work any part time jobs and having mom and dad (or even a paid advisor) actively working on your behalf to ve…

I doubt that has anything to do with getting "large in terms of job applications" alone. It's a correlation, alright, because wealthy families have it easier to get high-status and high-paying jobs for their kids, and if such a field grows, wealthy people flock to it like everyone else. But I sincerely doubt you'll find the wealthy over-represented in physical labor / blue collar jobs, regardless of how the ups and d…

> It's a correlation, alright, because wealthy families have it easier to get high-status and high-paying jobs for their kids

You have just written down a partial solution to this dilemma: make these high-paying jobs less attractive in terms of status for these wealthy families. :-)

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

#479

Earlier quoted context omitted.

> but great teams makes great software, not great individuals. For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals a…

https://openssl-library.org/post/2018-12-20-20years/ OpenSSL was made by a team, just read the history.

As per your own source:

> For the first 15 years, OpenSSL membership was mostly a small collection of individuals working on a part time basis and the membership fluctuated and changed through those years.

I never claimed OpenSSL was the product of a lone wolf or that teams have no place in coding. The essence of my point is that the invocation of "teamwork", often as a concept and practice distinct from the sum of its parts, obscures the significance of individual contributors who making great software. After all, code is a mirror of the mind. That one can distinguish between great and not-so-great code implies that one can distinguish between a great and not-so-great coder.

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

#480

Earlier quoted context omitted.

> but great teams makes great software, not great individuals. For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals a…

This example proves the exact opposite of the point you intended to make.

In what way?
Post reply on HN