Live data from Hacker News

Short fat engineers are undervalued

nested.substack.com

191–200 of 269 posts

Re: Short fat engineers are undervalued

#191
post #140

I think there's some dynamics at play here that obscure the situation. First of all, there's a tendency for depth engineers to be more visible. But this is extreme; there's a handful of top names in StackOverflow for a tag like csharp or django, but that doesn't mean number 1000 in a given tag is an amateur at it, he's likely pretty good. Similarly, not everyone writes respected blogs, but the people who do tend to b…

> If you have some person who did a lot of work in RoR, but you have a Py/Django project, couldn't you expect him to get up to speed reasonably quickly? I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it. It can’t be very long. Maybe 2 weeks? If you had a number, you could calculate the costs…

> I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it.

As someone who's done this probably too many times (Perl cgi -> cakePHP -> Play framework -> Spring -> Node.js/Express -> Flask -> Sinatra) I'd say your two week estimate sounds about right, at least given my personal experience.

After switching you quickly notice patterns and apply your past experience from other languages and frameworks. After a few weeks to a couple months you produce idiomatic code indistinguishable from your peers.

And those examples are just web framework transitions. As someone with not enough sense to stay put, I've wandered as far as:

* embedded C and assembly for microcontrollers

* writing kernel modules and device drivers

* designing, programming and assembling custom hardware (pcbs, enclosures)

* writing mobile applications (iOS/hybrid)

* being a frontend engineer (jQuery -> moo -> knockout -> backbone -> redux+react)

I've jumped fields from robotics research, social networking, healthcare, fintech, and consumer electronics.

It's been a wild ride and looking back I honestly wouldn't change much in hindsight.

As a generalist I work best on the early side of projects where I end up "wearing lots of hats." 'Tend to stick to a place for 5 or so years until everyone becomes specialists, then move on. As you say though the key is the willingness to learn.

As far as your point on generalists being cheaper than experts--I've found that pay honestly has more to do with soft skills than "expertise." (Good communication, self advocacy skills, etc.)

Re: Short fat engineers are undervalued

#192
post #176

Earlier quoted context omitted.

> I'm not sure how you can spend 5 years and not learn at least one thing in depth. You'd have to rotate technologies every 6-12 months and there's not that many technologies. That's kinda how SV is these days though. It's very common for engineers to jump companies every 1-2 years for a long period of time and the companies very frequently undergo a shift in technologies while engineers are there. So, unless you joi…

You wouldn't say you have deep knowledge of JS & front end frameworks?

Nope. My frontend knowledge has disappeared in the last year as I've done almost all backend. My knowledge of JS is enough to get the job done but deep knowledge? How could it be - I'm constantly building products, not toying with the minute of performance optimization or creating some impressively large framework. The stuff I do is extremely lean and relies very little on language nuances. The stuff I do could be done easily in many languages - it just happened to be in JS a lot of the time.

Re: Short fat engineers are undervalued

#194
post #184

Earlier quoted context omitted.

Sorry, not sure what you mean by ‘T’ shaped skill set. Could you elaborate..

It is used to describe a skillset which has a little experience in a wide number of areas (the top of the T) and deep experience in a single area (the stick of the T).

Thanks, yes, than that is what I was referring to, I just didn't know that there was actually a term for it.

Re: Short fat engineers are undervalued

#195

Do "height on demand". Constant abstract and compress the knowledge so you can ramp up in any area as needed. Really, this is why programming languages are my "home base" of expertise. It's the study of formal ideas and their communication.

> Constant abstract and compress can you expand on this? i feel like i do this but not quite sure what you mean

Well, taken to the limit, something like https://ncatlab.org/nlab . (I do endorse, but am no category theory wise by any stretch of the imagination.)

By default being extremely skeptical of all things computing related, and general being dour about the mainstream trends also helps. Skepticism is what allows separating the accidental and essential complexity, as some term it. Only learn the essential parts.

Re: Short fat engineers are undervalued

#197
post #126
post #90

Earlier quoted context omitted.

Diversity. I've had a conversation with a few bosses where at some point I stopped to say words to the effect of, "It's like you think I expect everyone a the project to be like me. I don't." A project with just me would have problems too. But every project needs at least a couple of people who think like me, which we aren't accomplishing. This whole expert thing isn't tenable on a long term project. The expert will…

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 trajectory. And if ever the non-experts decide to do something different, -that's their prerogative-. Because it's they who will be dealing with the fallout if they're wrong. And unfair to make them deal with the fallout if they were right, and the expert was wrong. It's incumbent on the expert to convince them, not dictate.

Re: Short fat engineers are undervalued

#198
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.

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.

Re: Short fat engineers are undervalued

#199

Do "height on demand". Constant abstract and compress the knowledge so you can ramp up in any area as needed. Really, this is why programming languages are my "home base" of expertise. It's the study of formal ideas and their communication.

Interesting to see someone else with the same base and thoughts on it, and I'd highly recommend it! At a lower level, I've found a PL/Compilers background lets me switch/pick up languages quickly often and also helps even finding quirks as you can often guesstimate where the bodies are buried from design choices of the language. Also very helpful for architect type roles where you're picking what technologies to build on, consulting experts when needed.

I think the idea of "you have to spend years and years to know the internals of X" is a bit flawed - you can get quite a good feel in ~6 months that's not equivalent but not terribly far off. If you do "height on demand" for long enough, you end up with a good number of these. As someone called it, a "comb" engineer, if you will.

Re: Short fat engineers are undervalued

#200
post #194

Earlier quoted context omitted.

It is used to describe a skillset which has a little experience in a wide number of areas (the top of the T) and deep experience in a single area (the stick of the T).

Thanks, yes, than that is what I was referring to, I just didn't know that there was actually a term for it.

The article discusses T shaped engineers. It's pretty good, I suggest reading it!
Post reply on HN