Engineers: Stop trying to win other people's game

There are some good kernels of wisdom in this article but it goes a little too LinkedIn-influencer style with the extreme proclamations.

> Swarms of others have been developing expertise with technologies that emerged last decade for… at least a decade. It’s already their superpower. It’s unlikely to become yours, too.

I agree that juniors should be open to experimenting with new technology, but they shouldn’t ignore the basics. It’s true that you’re probably not going to become the premier React expert and rise to the top of the field, but that’s not a good goal to start with anyway. Knowing some core technologies well is basically mandatory so you have something to build upon.

It’s also key to being able to get a job. Being the junior who doesn’t have much foundational knowledge but has a bunch of surface level frontier AI experiments they don’t really understand in their GitHub portfolio is not a good place to be, but I’m seeing more and more junior applicants like this. They follow articles like this and think that learning anything that isn’t extreme cutting edge is a waste of their time. The result is a junior who doesn’t really have a good foundation of the basics, but also doesn’t really have the skills necessary to understand the frontier AI work they’ve been trying to get on to their resume.

So exploring and experimenting is good, but don’t neglect the mature technologies. Those mature technologies are what’s going to get you the job. Don’t become the person with the “AI engineer” resume who can’t do simple interview questions to demonstrate basic understanding of the boring things.

Ironic article that describes 'AI Engineering' as the frontier skill that separates you from the crowd. No - in this era of workslop everyone and their grandmother is an 'AI Engineer', being the one guy who can read the spec and debug the kubernetes yaml is actually going to separate you from the rest.

If you've actually mastered that quadrant - why would you be an engineer? Learn fundraising too (which in this environment is super-easy if you're AI-related, I've heard multiple reports of people in their 20s being offered $5M+ in seed funding if they start a company that has "AI" in the name) and make them acquire you. If you've got management and sales skills your startup might even succeed before they acquire you.

When the inexperienced move to become rare and on the frontier, sure they get an advantage but the field doesn’t get the benefit, they do. This is why the early days of Node were awful. So many jr devs (that’s being generous, mostly designers with a base knowledge of js) were jumping from writing front ends to entire stacks. They won, the stacks lost.

Experience matters and it’s an advantage, that’s not a reason for new people not to compete but rather one to understand that context and use it to help them grow.

Author here.

Thanks for all the feedback! To address some of the key points in the comments:

1. Completely agree learning the fundamentals is important. I did mention groking the underlying CompSci in the article.

2. The market has generally decided that an AI Engineer is an engineer who is proficient at applying AI in the products they create – not somebody who uses AI to create the products. This article used the former as its example, not the latter.

3. Completely agree that an engineer in the upper right quadrant could just as well be a fundraiser and founder, too. If that's what they want, more power to them. In any event, I love creating a culture on my teams that gets engineers routinely thinking like customer-centric founders. Which brings us to...

4. I don't view prioritizing new technologies as hype-chasing. There's an enormous amount of EQ required to understand which technologies are likely to be a net positive vs. negative to a marketplace and the customers that comprise it over the long-term, hence the point about customer-centricity. 20-30 years ago, I was all in on dyanmic web technologies but wasn't investing time or energy into Flash or Java applets. I was, generally speaking, never a proponent of NoSQL or microservice architectures, but did love iterative improvements to SQL databases and the advent of cloud-native platforms. For the past few years, I've been all in on LLMs but never bothered to dabble in blockchain, Web3, NFTs, or the metaverse. There's a reason for all of this contrast, and it's grounded in focusing on what actually drives outcomes for customers, not just what's trending. It comes down to making intelligent bets on the future.

Cheers!

The 'western front' was a lot more like the ending of Blackadder than a place with a lot of rapid innovation, from my understanding of history.

It seems contradictory to move to new and rare technologies with clear customer outcomes.

Would it be wrong to say the advice is to hype chase, lean into new stuff and bail quickly when it's not working out? They hand wave away hype chasing by saying it's for the customer but I'm not sure that really changes things.

At least the advice about how the goal is to serve the customer not the tech is good.

The Western Front has a different context in Europe, the trenches of WW1. I'm not sure what it means in the American context but maybe it's referring to the westward expansion and colonisation?

Highly AI generated article, including the whiteboard image.

"Your employability is higher if you get good at doing things that few other people are good at doing."

There, I just condensed the entire article into one sentence.

You should learn whatever field you are interested in, doesn’t matter if others are already masters in that domain. You life shouldn’t be oriented around how you can be most appealing to capitalist companies, but instead what interests you.

Imagine telling students in school to not bother learning physics or calculus, as others have already mastered those fields.

the main thing "rare" engineers would have in common is that they think for themselves and dont need preachy blog posts with ambiguously sexist AI graphics to tell them how.

another article singing the praises of asking an LLM to write code