Live data from Hacker News

The Happy Demise of the 10X Engineer

a16z.com

41–50 of 111 posts

Re: The Happy Demise of the 10X Engineer

#41
The article makes the error of assuming that a 10x engineer is 10x because he has arcane knowledge about the intricacies of low level programming. This may be true for some layers of development. In my experience, for application programming, this isn't the "10x skill".

10x engineers are the guys that can grasp the complexities of large systems, enabling them to change them with minimal effort. When prompted with the need to implement a new use case, they understand the whole system or most of the system and thus they can plot the minimal change path to achieve the new functionality. They don't code faster. They code less, leveraging work that is already done.

If you have fewer engineers working on a system, because of better abstraction layers, then you only need the 10x guys. These are the ones that can drive the powerful machines.

What we are witnessing isn't the demise of the 10x engineer. It's the demise of the code monkey.

Re: The Happy Demise of the 10X Engineer

#42
A billion dollars for a one engineer social media company? Certainly possible, but then you'd have to ask yourself what you are paying for. Perhaps it's not just (or even mostly) the engineering; in which case I'd say the author slightly misses the mark here.

This is certainly not to say that I believe more engineers/engineering == better product or more value, far from it. Only that devaluation of skill and experience suggests that the problem being addressed might not be primarily focused on engineering tasks. And that perhaps the gargantuan sums we see being paid for some small collection of companies are calculated somewhat differently than we might be used to.

Even if I'm wrong about that, heralding the death of the highly skilled engineer is more than a little premature either way. I tend to think that problems will continue to present themselves to challenge our best tools, regardless of how much engineer quality of life improves. If that's not happening in social media (which I highly, highly doubt), then that can probably be considered a separate issue entirely.

Re: The Happy Demise of the 10X Engineer

#43
When I was in college in the mid-late 90s, my Software Engineer professor said that "In 5 years, programmers won't exist. With the revolution of Object Oriented Programming, creating software will be a matter of plugging blocks together".

Right.

Re: The Happy Demise of the 10X Engineer

#44
I love how all the top comments here are all devs in denial about this, but it's an inevitability that programming "becomes legos". Don't become the old men guys!

As said in the article and below, many products will still require very high-level engineers building without "legos", but the basic webapp kind of stuff probably will be full commodity able to be built by anyone with the motivation to see it through.

Re: The Happy Demise of the 10X Engineer

#45
This article is grossly oversimplifying and conflating things. All the examples cited are skewing the results to fit the agenda the author wants to promote. Specifically, the functionality, audience, and valuation are creating insane $$$-to-engineer ratios, that the author then tries to claim is the future of the industry.

Functionally, imgur is not very complex. Its an order or 2 of magnitude less complex than say, another "software is eating the world" business like a web-based CRM app. That's not to discredit imgur or Instragram. They are great achievements and successful apps. But it doesn't and shouldn't take dozens and dozens of engineers to make those.

The potential audiences for the examples are, essentially, the world. These apps can gain use very rapidly, and it can disappear just as fast. 1 person can make Flappy birds and the entire world can use it. The people to audience ratio here is huge compared to say, a SaaS invoicing product.

Imgur doesn't have a monetization strategy like, say, a SaaS product like a web CRM, or even something as simple as a WordPress backup SaaS product. Instragram had no business model. How much is it worth? This is where the crazy audience ratio comes in and messed up the results some more by effecting valuation. These valuations are not based on real revenue numbers. They are based on the wish and dream of extracting value from eyeballs. I'm sure they are worth something, but taking a Series A or Series B valuation and extrapolating is murky.

So, low functionality apps, with a huge potential audience, and a completely made up valuation number. Of course you are going to get $10B to 10 engineers ratios. That doesn't mean this is a trend in the industry, let alone business/enterprise software.

Re: The Happy Demise of the 10X Engineer

#46
Looks like I'm riding the wrong train, screw learning C++/Scala, Big Data and NoSQL database, looks like engineering is gonna be commoditized.

Not this time, I'm gonna get on the new train early this time! I'm gonna pivot to learn SEO, A/B testing, social media marketing and lean startup principles on how to manage coders to build startup's on the backs of free open source software hosted on Github donated by hobbyists!

Re: The Happy Demise of the 10X Engineer

#47
This post is making the completely wrong conclusion.

The reason companies like Instagram, Imgur, etc are able to service large #s of users with 7 engineers is mainly because computers and tools are a lot CHEAPER than they used to be, not simpler.

Cheaper. Less expensive. This allows small teams to build really huge things because generally small teams don't have much money (because if they did, they'd have a bigger team!), and the fact that stuff is cheap allows them to build it in the first place. Open source = free. Computers, bandwidth = a lot cheaper than they were 5/10 years ago.

Snapchat couldn't have existed 10 years ago because it would have cost 100x what it costs today. In fact, things are so cheap these companies can overspend and run their service on AWS or Heroku because the price of computing doesn't matter as much [1].

Programming is just as complicated as it was before. In fact, anything where you have a team of 5+ people working on the same thing for years is going to be complicated whether it is software, legos, or plumbing. As tools get simpler, the product will compensate by becoming more complicated (which is why we are seeing more awesome software these days), and thus the level of complexity will be roughy the same.

Today I could build a product as a one-person team that would have been competitive 5/10 years ago, but today the bar is much higher, and of course it will continue to get higher as we software and the trade of building software improves.

1: Though companies like StackOverflow still build their own metal and because of that run their sites incredibly efficiently on a cost basis

Re: The Happy Demise of the 10X Engineer

#48
I have two problems with this:

1) Even if we are able to remove all of the inessential complexity of the problem (ceremony and routine drudgery,) we cannot automate the essential complexity. For crud apps, the essential complexity is very low. However, for many apps there is intrinsic complexity to the problem and how it relates to the domain. You might argue that what this leads to is a vast array of cheap specialty modules that can be plugged together. Well, the complexity is then in understanding the impacts of the modules and their interrelationships. The 10x engineers aren't 10x because they can set up logging or automated deployment, they are 10x because they can instantly cut through multiple layers of abstraction to see how their interactions lead to an emergent behavior that is different from the spec (for example.)

2.) Unfortunately, machines (and networks) are not fast enough to compensate for an unconsidered approach to information retrieval and propagation and this is not going to be helped by a "legos" approach to building software. This might be helped by a different set of tools (view-first rendering driving parallel backend requests..) but that brings up its own set of challenges.

Re: The Happy Demise of the 10X Engineer

#49
post #31

> As software becomes a high-impact, low-skill trade, we decouple the technical ability and experience needed to write tricky software from the ability to solve problems for people. It's one thing to know that capital secretly delights over the commoditization of labor. It's quite another to watch a16z gush so openly about a future where we can be tossed aside.

Great programmers move up the chain as well. If your skills are not being valued by your company as it is setup in a way that it needs only average engineers, you can move on and create your own company now. If you are a great engineer, then you are a walking capital by yourself. If somebody with an idea, and no skills, hires you, then it probably needs at least 300-500k (even for a smallish prototype) to make it hap…

Programming talent and skills do not translated into business talent and skills. And vice versa. It does not even translate into an idea doable by just two guys that can sell well and is not easily doable by other two guys. How many such products does exist?

Re: The Happy Demise of the 10X Engineer

#50
post #29

The article suggests that, as super-human programmers build ever-better platforms/languages/tools, those building apps/whatever on top of those will be less differentiated in terms of programming ability, because it will be so easy to develop stuff anyway. I'm not sure this is true. Are 10x programmers really 10x because they can grapple with technology stacks, or because they're really smart and experienced at probl…

I agree. Specific skills (e.g. working with a certain framework) will go in and out of style, but problem solving will always be in demand. Also, maybe I'm naive, but I just don't see the software-as-legos future as feasible. There will always be the need for customization and ever-more-advanced functionality.

I don't agree.

If you spend a few years at university (I have two degrees), you learn things like sorts, automata, proofs, and calculus.

On the other hand, most of the junk I deal with day-to-day as a working software developer turns more on my knowledge of tools like Chef/IntelliJ, software libraries (the stdlib of various languages, the Java/.NET BCLs), build systems, git/github, and how to do a proper code review.

For most stuff today, I would highly prefer the person with more tools experience. Granted, there are some problems people who aren't "10x developers" could never solve (e.g. writing linux) but for most stuff industrial software devs today are doing, it just doesn't matter. You just need to write the code, it needs to be maintainable, and it needs to be done as quickly as possible.

Post reply on HN