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

271–280 of 543 posts

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

#271

Post by throwaway2037 »

noisy_boy wrote: post #202
throwaway2037 wrote: post #182

Earlier quoted context omitted.

> It makes me wonder, if someone is so smart that they can do "10x" the work, would they not use that smartness to look at the meta of it all and wonder why they don't get 10x the rewards? It is hard to understand other people with freakishly high intrinsic motivation. They look like aliens to the normies.

Maybe because they enjoy the work they do because they love programming and are very happy that they are getting paid well, relative to most professions, for their hobby? Sample size of 1 tho.

    > Maybe because they enjoy the work they do
I feel the same when I read about a career staff engineer for NASA. They work on many cool projects, but the pay is average compared to the tech industry. When they talk about their work, you can see that they have very high intrinsic motivation.

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

#272

Post by throwaway2037 »

TylerE wrote: post #234
throwaway2037 wrote: post #171

Earlier quoted context omitted.

I would disagree about TDD. I am continuously surprised when I learn that yet another one of my teammates practices TDD. TL;DR: TDD is dead; long live TDD. I think that TDD will remain viable in enterprise programmer for decades, perhaps permanently, thanks to "vibe-coding", where LLMs eventually produce most code for CRUD projects (the vast majority of enterprise programming).

Just to be clear, do you mean full-dogma Rails tutorial write a bunch of trivial tests before writing code TDD?

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!

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

#274

Post by lovich »

callc wrote: post #244
noosphr wrote: post #176

Earlier quoted context omitted.

Not sure where you're getting that from my post. The point is that all other engineering disciplines don't have enough design space to make a true mess of their projects. Software by comparison hasn't been limited in its design space since the first super computers started having gigabytes of ram memory in the late 1980s. That doesn't mean that either discipline is better or worse, it means they are different. Other…

I say this as someone who loves software: software is not special. Every discipline has infinite depth. Railways in 2D may seem simple but there the simplicity may be intentional. Just like when you write software that runs things like planes, trains, or medical devices, all of a sudden you’re writing in C, without recursion, without function pointers, without using the heap, etc. Look at the concord airplane. A mess…

> I say this as someone who loves software: software is not special.

Based on your comment I’m interpreting “special” as “better”, or “harder”.

I interpreted the comment you replying to as software is “special” as in it is “different” and the differences require different solutions than other fields have.

Like when I talk to my civil engineer friends I only on the surface comprehend what they are dealing with when they need to move literal thousands of tons of mass. I can try and make an analogy to my own experience with bandwidth and memory, but nothing will be a 1:1 comparison with the amount of energy used when the physical mass of the entire internet is within an order of magnitude of a strawberry.

Simultaneously my civil engineers friends don’t have to deal with a situation of one of their apprentices making a logical mistake based on a single missed `!` and their features suddenly using up 100% of all resources everywhere

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

#275

Post by lovich »

noosphr wrote: post #267
callc wrote: post #263

Earlier quoted context omitted.

Thanks, I edited to assume the best interpretation of the thread. Since I want programming to be inclusive and not have a bad rap publicly, when a peer says “software is better than all other disciplines because of X, Y, Z” I want to convince them otherwise. As a leader and teacher with more grey hair every day, I feel this responsibility

>As a leader and teacher with more grey hair every day, I feel this responsibility You should probably do less of that since: 1). That's not what any of my posts said. 2). My degree says mathematical physics and not computer science or software engineering. 3). A field where you're tone policed by the tone deaf is the opposite of welcoming and inclusive.

Since I’m already in the thread defending you against the other poster, I’ll add here

U/callc appears to be reacting to the public perception of how this thread would read externally, you appear to be reacting based on hard logic, which is unpalatable to most of the public.

I think you two are talking past each other

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

#276

Post by chamomeal »

I’ve never liked the idea of a 10x engineer.

In my mind, the important distinction isn’t so much about the developers themselves, but more the environment that they are developing in.

If your codebase is an inscrutable mess, you don’t have agency to make even minor decisions without slacking 6 people for an afternoon, and there is no documentation on a service you suddenly own, then guess what? You have no chance of being a 10x engineer. You probably can’t even be a 1x engineer!

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

#277

Post by lovich »

TylerE wrote: post #233
tdeck wrote: post #195

Earlier quoted context omitted.

It was somewhat common in the 1970s and before for programming languages to support abbreviating variable names when you referenced them. So for example, you could say patients = 400 x = pat / 2 And x would be 200. This seems like an obvious footgun today and I don't think any language designer would even consider it, but it seemed to make sense for a while.

Were they actually supporting abbreviating or just doing something like only storing the first 3 characters of the name? That feels more like something a compiler trying to fit in 8k of RAM or whatever would do.

Is there a difference between doing something and supporting something?

This joke is like a decade old at this point https://xkcd.com/1172/

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

#278

Post by lovich »

throwaway2037 wrote: post #171
TylerE wrote: post #110

Earlier quoted context omitted.

TDD. Agile.

I would disagree about TDD. I am continuously surprised when I learn that yet another one of my teammates practices TDD. TL;DR: TDD is dead; long live TDD. I think that TDD will remain viable in enterprise programmer for decades, perhaps permanently, thanks to "vibe-coding", where LLMs eventually produce most code for CRUD projects (the vast majority of enterprise programming).

When you say TDD do you meant test driven design or the test first design actually practice when “doing TDD”

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

#279

Post by bigtunacan »

callc wrote: post #244
noosphr wrote: post #176

Earlier quoted context omitted.

Not sure where you're getting that from my post. The point is that all other engineering disciplines don't have enough design space to make a true mess of their projects. Software by comparison hasn't been limited in its design space since the first super computers started having gigabytes of ram memory in the late 1980s. That doesn't mean that either discipline is better or worse, it means they are different. Other…

I say this as someone who loves software: software is not special. Every discipline has infinite depth. Railways in 2D may seem simple but there the simplicity may be intentional. Just like when you write software that runs things like planes, trains, or medical devices, all of a sudden you’re writing in C, without recursion, without function pointers, without using the heap, etc. Look at the concord airplane. A mess…

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 because you actually have to get shit perfect. The wrong o rings and real people die.

There are a few real software engineering shops and real software engineers, but 90% are just slinging shit together for a bunch of enterprise CRUD and they are all just one bad deploy away from disaster.

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

#280

Post by [deleted] »

ljm wrote: post #246

Fuck this constant dehumanisation and categorisation of the working class. The key to a great team is great leadership. Most people are terrible leaders, and they think that what they are worth is what makes them leadership material, even though they didn’t earn that worth themselves and didn’t put in a hard graft. The key to a great team is a fucking team. Only then can there be a leader. Let’s talk about ‘normal’ C…

[deleted]
Post reply on HN