Earlier quoted context omitted.
The problem with the article's conclusion (and title) is that they don't stop with 100,000 -> 1,000 engineers. "Tomorrow, that billion-dollar startup acquisition might not need an engineer at all." The article's claim is not that startups are going to keep having smaller and smaller teams of higher-value engineers, they're saying that they're going to have zero engineers. Which I don't see at all from the evidence pr…
Well, they might technically have an engineer, but it could be some average joe, using a "21st century" equivalent of Hypercard -- building a whole startup with some composable cloud components and some logic. After all, the basic skills for a successful startup, even today, are not hardcore engineering skills, but idea, business, finances, etc. I mean, most startups bought for multi billion dollars work on BS trivia…
The Happy Demise of the 10X Engineer
101–110 of 111 posts
Re: The Happy Demise of the 10X Engineer
#102I think it's more that plumbing has been with us for thousands of years. Imagine if we had computers 5000 years ago - software surely would have been plug-and-play by now as Sam writes about.
Re: The Happy Demise of the 10X Engineer
#103> 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.
It's great when both problem-solving and outstanding engineering exist within the same individual, in some positions even essential.
Realistically, problem-solving is the more uncommon natural ability of the two. If it were not, there would be a lot less problems with software by now.
Re: The Happy Demise of the 10X Engineer
#104Earlier quoted context omitted.
Replace "software engineer" with "person building a product" in that first quote. The value of engineering skills as they are defined today is falling, but the value of a single person with an idea and the drive to implement it is soaring.
Back when I was a physicists every two bit crank used to go on about how ideas were more important than knowledge. Now I'm hearing the same in programming. And it's just as wrong here. Picking the right algorithm and stack means the difference between a website that can handle 2,000 people and one that can handle 2,000,000. How many websites start off with a bad idea, get popular and then need to hire hundreds of eng…
Sometimes skimping on the engineering is better than skimping on the idea. That's what MVP and quick-to-market are about, correcting the idea so you can architect a solution to the RIGHT problem.
Re: The Happy Demise of the 10X Engineer
#105> 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.
Alternatively, a creator can now build a product with fewer people and doesn't need to raise capital. This trend is extremely empowering of labor.
Labor = show up, do your job, get paid. Capital = put money at risk without any guarantee of getting anything back, let alone earning a profit. Capital makes the rules because half of America is two paychecks away from bankruptcy (I read this somewhere credible) and can't/won't take any risk.
Re: The Happy Demise of the 10X Engineer
#106I had this vision 5 years ago, for sort of an operating system for social apps. Where a regular user could build their own app by just installing some plugins, dropping a chatroom and some other components on a page, paying a developer to wire them up, and paying a designer to design the theme. And there would be a marketplace of components built by more experienced developers. So 5 years ago I started my first open…
How come every time I post about the platform I've spent 3 years building someone here decides to vote it down? I'm just curious. Is it really something you don't want to be spoken about?
My experience with HN is that it's a very hard-edged, no-shit crowd. People here expect things to be described with simple, crisp language, no jargon (especially not computer/science/technology terms with precise meanings), and a minimum of hand-waving. It's a bit hard on the ego, but it'll make you a better communicator.
In the first sentence of your post, you described your thing as a "social operating system" or something like this -- this immediately sets off my bullshit alarm. "Operating system" is a very specific thing to software people, but for whatever reason, non-technical people love using this term to talk about something perceived to be big and complicated.
In general, try to cut the fat. If it's a library of software components you're making, say that. If it's a Ruby gem, or an app, or some kind of a specification, just describe it for what it is. You don't gain much here trying to hype it up.
Other things I notice:
- You say you can "override" -- how? Using what?
- What is a "social app", anyway? Aren't all apps "social" today? This descriptor (social) adds very little value. Github, facebook, twitter, instagram, linkedin, could all be considered "social" apps.
- "Social" is a very overused buzzword in SF. Everyone here is building bullshit "social" companies and all the devs here get like 10 job ads/day for some dumb social network for cats.
- Again, "interoperate". How? Via a REST API? Server-side includes? Be specific.
- Don't say "it's come a long way". Stop telling. Show.
- "Decentralized". Again, what does this mean? It can be hosted anywhere? The software is widely distributed? What is a "distributed network"? Aren't all networks "distributed"?
Re: The Happy Demise of the 10X Engineer
#107This 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 t…
Re: The Happy Demise of the 10X Engineer
#108Earlier quoted context omitted.
How come every time I post about the platform I've spent 3 years building someone here decides to vote it down? I'm just curious. Is it really something you don't want to be spoken about?
I think this got downvoted due to the way you describe it. My experience with HN is that it's a very hard-edged, no-shit crowd. People here expect things to be described with simple, crisp language, no jargon (especially not computer/science/technology terms with precise meanings), and a minimum of hand-waving. It's a bit hard on the ego, but it'll make you a better communicator. In the first sentence of your post, y…
Re: The Happy Demise of the 10X Engineer
#109Earlier quoted context omitted.
> Well, not really, because somebody will have to build all those elaborate abstraction layers people will use. It's almost as though you completely ignored my next sentence, which clarified that great engineers continue to be valued outside of abstraction/infrastructure companies.
Well, I don't find it valid to be frank. They might be valued, but they are valued less and less, and will be valued even less in the future. An enterprise that used to need 100 engineers, with the cloud, SaaS, PaaS etc, can even today make do with 1/5 of that. Is there any trend showing companies needing MORE software engineers?