Live data from Hacker News

Short fat engineers are undervalued

nested.substack.com

241–250 of 269 posts

Re: Short fat engineers are undervalued

#241

In my career, I have met exactly one short fat engineer with >5yrs of exp that I was impressed by. That person is now a Product Manager at a FAANG company (albeit PM-ing highly technical stuff). I bring this up because I think there is a very good analogy to the point that the author is making and the distinction between PM and Engineers. Broadly put, PM's are good at figuring out the theta, and Engineers are good at…

I have been working for around 5 years now and haven't stuck to one programming language or framework more than 1-2 years. Not enough to an expert in any of them. Started from c#, than some web, than cpp and some Java, than some DevOps and now full time Java. Been doing Javascript along with out of interest only.

When I tell my friends how I feel about my knowledge and expertise they say I am only suffering from imposter syndrome. May be with more years I do become really good at one or two things.

Re: Short fat engineers are undervalued

#242

"Junior in every department" really struck hard for me. I know just enough of basically everything to get by or as a starting point, but I lack that really deep knowledge that comes from using a small group of skills and tools for years. I feel that switching languages and frameworks and tools and OSes a bunch of times early in my career has really held me back. I don't mind supporting my team, what I don't like is h…

I have also been working on different tech throughout my career. Do you suffer from imposter syndrome because of this? I often feel like I don't know as much as my peers do. I can't do things that quickly. I am in a very good workplace now where my manager appreciates my work. But most of the times I feel I am not contributing like others. I don't even understand that much.

Re: Short fat engineers are undervalued

#243
post #126

Earlier quoted context omitted.

The ideal is an expert who sets up the project, builds the guard rails, creates the patterns and basically sets up a framework for everyone to use. Then they teach everyone how to use it and why And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature. Force multiplier is the game.

No thank you. Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even if the project changes. The ideal is an expert who will be involved with the project, offering suggestions, providing a sounding board to non-experts working through issues, etc. Mentor and guidance, yes, but without first trying to lock people into a specific t…

This hasn't been my experience. When the non-experts decide to break patterns and remove guardrails because they don't understand their purpose, and then they break the project, the experts are once again pulled back in to try and scavenge the remains and get something workable.

It's fine if people want to do something different: just first become an expert.

Re: Short fat engineers are undervalued

#244
post #93

Earlier quoted context omitted.

As a generalist, I agree with bulk of what you're saying but at least my personal experience seems to echo the fact that generalists in general are undervalued since when someone asks a person "what can you do for me", a specialist always has a better and sharper answer than a generalist - and that makes all the difference. Personally I'll take a generalist any day since specialists suffer from the "if you only have…

My experience is that opposite. I'm a generalist and every company I've worked for is looking for generalists. If you're doing boring business work, which most of us are, you don't need to know every crevice of any technology. The majority of software development is not moving the needle on crypto or search algorithms, it's crud business apps and reporting.

> it's crud business apps and reporting.

And yet... as 'boring' as those things are, I constantly see basic errors crop up all the time because people aren't even moderately versed in the technologies.

For example, you don't need to "know every crevice of a technology", but if you're doing LOB reports for business systems, I would reasonably expect you to understand what indexes are, or what joins are and how to use them, in your SQL engine of choice,

Re: Short fat engineers are undervalued

#245

Earlier quoted context omitted.

No thank you. Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even if the project changes. The ideal is an expert who will be involved with the project, offering suggestions, providing a sounding board to non-experts working through issues, etc. Mentor and guidance, yes, but without first trying to lock people into a specific t…

This hasn't been my experience. When the non-experts decide to break patterns and remove guardrails because they don't understand their purpose, and then they break the project, the experts are once again pulled back in to try and scavenge the remains and get something workable. It's fine if people want to do something different: just first become an expert.

This thread shows the problems with both approaches. Being handed a design that isn't appreciated but expected to follow tends to go off in a direction that's unproductive, especially if there isn't someone who understands the value and maintains the key parts so as not to lose it.

The other problem is that there aren't enough experts and how can they become experts without strengthening expert muscles. They have to practice and learn.

Depending on the distribution of abilities, what I've found to be give the most leverage is to convey a few specific design ideas significant for a particular project to someone on the project who can understand or at least commit to using them. You can check in from time to time and provide some input and clarity. Regardless of good intent on all sides, results still vary. But if done smoothly, everyone gets better at working together on high-level tech things and there's no resentment that doesn't fade away quickly.

Re: Short fat engineers are undervalued

#246
post #224

Earlier quoted context omitted.

A lot of people seem against this approach, but I'm all for it. In some sense, that's exactly how top level frameworks like react and Django get made- experts build them to make it easier for the rest of us to write the business-specific logic.

I'm half with you, and I see both sides. When it's done well , I think it's a fantastic approach. I'm in a situation right now where I'm kind of that "expert". Not because it was planned that way, but because I was the only person on the project at the start. Now I've got a couple of young EEs working under me, and they do most of the development work while I sit in meetings for a good chunk of the day. I come in and…

There's also the fundamental question of whether or not the expert is actually an expert. It sounds like in the unpleasant case you mention, maybe there wasn't so much expertise there.

I think you're right that having skin in the game is critical. It's important to have real accountability, so if there's painful design flaws, the expert feels it.

But it's easy to think it should have been done differently and better when you don't have the perspective of the designer. I still vividly recall being a junior engineer and thinking the design decisions made by the "expert" were ridiculous, and talking with the expert, and finding out I didn't know everything and I was wrong. Thank goodness he was patient.

Re: Short fat engineers are undervalued

#247

Earlier quoted context omitted.

No thank you. Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even if the project changes. The ideal is an expert who will be involved with the project, offering suggestions, providing a sounding board to non-experts working through issues, etc. Mentor and guidance, yes, but without first trying to lock people into a specific t…

This hasn't been my experience. When the non-experts decide to break patterns and remove guardrails because they don't understand their purpose, and then they break the project, the experts are once again pulled back in to try and scavenge the remains and get something workable. It's fine if people want to do something different: just first become an expert.

'decide to break patterns and remove guardrails because they don't understand their purpose'

Ensuring the non-experts understand their purpose is the role of the experts. NOT making the decision as to when to deviate. That's my point.

An org that leverages an expert to make others experts is an org that ends up with a team full of experts. An org that leverages an expert to make decisions for the non-experts is an org that is going to have a lot of issues in production, and likely high turnover.

Re: Short fat engineers are undervalued

#248
post #224

Earlier quoted context omitted.

A lot of people seem against this approach, but I'm all for it. In some sense, that's exactly how top level frameworks like react and Django get made- experts build them to make it easier for the rest of us to write the business-specific logic.

Wrong comparison. Django and React are products, if you were to say experts make it easier for us to write Django and React themselves that would better.

That doesn't make sense to me. Where do you draw the line between a framework and a product?

Google et all probably have lots of internal tooling and frameworks. Hell, react started as internal to FB didn't it? Does that count as a framework or as a product?

Lots of other companies have similar internal frameworks, probably with less resources devoted to them, but in the other hand with less use cases. Do those not similarly count as frameworks written by experts?

Re: Short fat engineers are undervalued

#250

Earlier quoted context omitted.

I’ve seen this crash and burn too often. If you have someone build something, and then explain it, you don’t find out until after if they are capable of explaining it. Just like a product MVP, you have to explain it as you go along. Without it, you start out with a multiplier but end with a divisor.

I think that's why it's very important to get buy-in and solicit feedback from coworkers even if you're the domain expert. Also, regression test coverage from the beginning is very important if you ever expect anyone else or even your future self to have a shot at safely modifying mission critical pieces of code.

You have to get people invested in the solution. Some people call that buy-in, others use that term a little more tepidly.
Post reply on HN