5 ms·

The Happy Demise of the 10X Engineer

114 points by mycodebreaks 12y ago

dman 12y ago
I would like to think there will always be a frontier, and there will always be people driven by their curiosity to seek the frontier out. Some of them will be called 10x engineers, some visionaries, some pioneers.
ojbyrne 12y ago
This seems to be pretty specious reasoning which has at its heart the principle that acquisitions are the final goal, not a functioning enterprise. I think the acquiring companies would tend to disagree.
mdgrech23 12y ago
This article fails to mention that our expectations for software have increased. We expect more from apps than ever before. This has lead to new specialities such as Front End Engineers and UX staff. Surely we can build more with less with current technologies as compared to the past but we also expect more. If our expectations outpace technological improvements this could lead to spending more time/money on developing apps.
- frozenport 12y ago
  Consider Bootstrap and the uniformity it offers in GUIs with little effort.
  - rjknight 12y ago
    Uniformity isn't so great for people who want to differentiate their products. (Not saying that they should want to differentiate their products visually, but they almost certainly do want this).
- timrosenblatt 12y ago
  Well put. The more software you write, the more you need. http://www.timrosenblatt.com/blog/2013/04/24/the-more-software-you-have-the-more-software-you-need/ http://www.timrosenblatt.com/blog/2013/04/24/the-more-softwa... disclaimer, that's my blog! ;)
nsxwolf 12y ago
This seems to be ignoring entire classes of software. I can't imagine the enterprise development world will be taken over with easy to snap together software packages any time soon.
- samg 12y ago
  Why do you think enterprise development is different?
  - nsxwolf 12y ago
    Because enterprises are infinitely complex and diverse and there will never be a single piece of software that can run all the businesses in the world with a couple configuration setting tweaks.
rahimnathwani 12y ago
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 problem solving? Programming will always be about problem solving, no matter how easy you make the final implementation of the design.
- jgable 12y ago
  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.
  - eldavido 12y ago
    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.
    - menzoic 12y ago
      You compare two people who have different skills. Presumably either one could learn the skills of the other. Why choose the one with the easiest skills to learn?
mikeryan 12y ago
Its funny I've always thought that Twitter could really be run by 100 folks (heck I've said 40) and be hugely profitable and it a lot of ways more efficient. Instead they've got 2300 employees to allow folks stream 140 character tweets.
- timrosenblatt 12y ago
  That's a bit optimistic. Their sales team alone is bigger than that. Companies aren't just engineers.
- deleted 12y ago
  [deleted]
chillacy 12y ago
It's already happening. There's an incredible difference (in personality, tooling, skills) between your typical full-stack web developer and kernel programmer, as there is between the kernel programmer and chip designer. They're each difficult in their own way, but one definitely has a lower barrier of entry.
EGreg 12y ago
I 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 source platform, http://phponpie.com http://phponpie.com Since then it's come a long way, and it turned into a real platform: http://platform.qbix.com http://platform.qbix.com Like mobile apps, social apps require an operating system that solves common problems in a standard way: * User signup and secure auth, login * Should work with emails, mobile #, facebook * Accessible from desktop, tablets, mobile * Contacts integration / friendlists * Real time collaboration from any device * Offline notifications via fb, sms, app notifications etc. * Access control and privacy - as expressive as possible * Native apps on iPhone and iOS via Cordova * Invitations and one-click account creation * Encourage best practices for scaling, web standards etc. * Installer to upgrade apps and plugin versions cleanly etc etc. All that stuff should have standard solutions which you can override. The apps and plugins should all interoperate. And finally, since I really care about decentralization, it would be cool if this whole operating system could be as decentralized as Wordpress is for blogs, as opposed to say facebook. That would also solve all the scaling problems that facebook and other centralized social networks have. That last part - decentralizing the social network - took the most effort, as I had to solve problems of security, identity, privacy, as well as app and plugin versioning and signing across a distributed network. Just like iOS is for mobile apps, and Bitcoin is for distributed contract apps, the Q Platform is if you want a social layer for your app, from user accounts to everything else, without having to write it from scratch. Yeah, so that's what I built. Link to the open source: http://github.com/EGreg/Q http://github.com/EGreg/Q
- EGreg 12y ago
  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?
  - GFischer 12y ago
jjoonathan 12y ago
> 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.
- nsxwolf 12y ago
  It seems this claim has been made forever. COBOL was supposed to make programmers unnecessary. So were rules engines. And code generators and an endless list of other technologies.
  - jjoonathan 12y ago
    I agree that Gerstenzang is premature. But it'll happen eventually. If it doesn't happen by making programming easy it will happen by flooding the industry with enough competent programmers to have the same effect (depressed wages, high unemployment, etc). See: non-software engineering occupations (excepting doctors, who have managed to turn the risks inherent in their profession into a legally mandated union).
    - kabdib 12y ago
      Human-equivalent AI has always been 30 years out . . . 20 years if you don't know the field. :-)
    - menzoic 12y ago
      Demand for engineers is increasing much more rapidly than non-software engineering occupations. Soon every company will need an software engineer of some sort.
- ardit33 12y ago
  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 happen. If you are a full stack engineer, and pair up with a buddy, you can make it happen, with a lot less. If you are a great engineer, you are the capital!
harpastum 12y ago
I'm failing to follow the logic here. The initial point is that "The potential impact of the lone software engineer is soaring". However, the author then takes that to mean that engineers will be less valuable in the future? This analogy seems apt to me, and I think it makes the logical leap more obvious: Fifty years ago, if you wanted to design a new model of car, you had to get plywood and clay, and work hundreds of hours of to get even the most basic model completed. Now, you can open up a CAD program and begin making real decisions immediately. What previously took a large team to build, a single designer can now do. (The analogous logical leap to what the OP seems to be saying is) Soon, we won't need designers at all! A company will come out with a new car model simply by snapping design-legos together. In reality, removing inefficiency made designers more valuable. If you were the best car designer 50 years ago, you had to spend a significant amount of time molding clay. Today, you spend almost all of your time creatively finding solutions to problems. I see the value of individual engineers increasing significantly as we remove cruft in the creation process.
- akavi 12y ago
  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.
  - eldavido 12y ago
    I think the change is purely additive. Great engineering is no less valuable than it once was, but pure "idea guys" can do stuff now that they couldn't do before.
    - GFischer 12y ago
      If they do stuff, by definition then they aren't "idea guys" :) You might mean "nontechnical people can do a functioning MVP" which they couldn't before :)
  - monochr 12y ago
djb_hackernews 12y ago
Less overhead, more productive, yet still the same pay...
eldavido 12y ago
This has always been the case. Software people in the 70s and 80s already had the distinction between "systems" and "application" programmers -- the former understood to be concerned with making the pipes and plumbing, vs. the applications guys concerned with the end users. Applications have always been like legos. I work as a systems developer but often do consulting projects as an application developer, and it's a totally different mindset. Writing software for end users, I rarely even remotely think about CS, algorithms, pointers, recursion, numerical stability, memory allocators, etc, whereas I do care intimately about the tools I'm using, much like I suspect a carpenter cares about what drill he's got. On the other end of the spectrum, I can hardly go a day writing traditional "systems" software without considering things like what data structure MongoDB/Postgres uses to hold indices, and gigantic, complex consensus problems (distributed systems, e.g. how DNS behaves). I hope we start to treat these two endeavors differently because they require totally different mindsets and education. A typical app developer need know no more about how OSes work, than a plumber needs to understand the metallurgy used to make pipes.
- the_af 12y ago
  I see the overall point you're making, but it's not true programming applications is always (or even often) like building with Lego pieces. It's just that many of us have to write mindless web apps which mostly consist of CRUDs. Those definitely are like working with Lego. CS, algorithms, pointers, recursion, numerical stability, etc, etc, are all alive and well in the world of applications programming. Just not in the world of run-of-the-mill CRUDs.
  - eldavido 12y ago
    Sure. And to be clear, I in no way think applications is easier. In fact, applications, as they're closer to end-users, have to deal with all kinds of socially-imposed whimsy like people with four names, tax rules, interest rate calculations, and 100 other things that make my head hurt to consider.
Todd 12y ago
The Lego approach has been the holy grail of software development at least back into the 80's with OOP. Yet it still requires programmers who know about data structures, algorithms, etc. to write software. Even if they're just cobbling together libraries, there is still a lot of additional functionality required--not just 'glue' code. All we have now are improvements in efficiency (great, mind you), with operational improvements like IaaS and development improvements with the great OSS that we have now. It will require a sea change in the field of comp sci. to achieve Lego-like orders of magnitude improvements.
deleted 12y ago
[deleted]
7Figures2Commas 12y ago
> The same software foundation (open source software, development tools like Github, infrastructure as a service provided by the likes of Digital Ocean, and more) that allowed Whatsapp and Imgur to scale, means that experience and skill writing software become less important. The author focuses a lot on ease of scaling, but the bigger challenge has always been building applications (experiences) that need scale. If you build it, they will not come.
jeffchuber 12y ago
Let's compare writing software to writing English. (Writing is kinda an individual sport) Almost everyone can write a short story in English, but the 10x writers really really stand out. Writing isn't a perfect analogy - we generally think of programming as a skill (right and wrong, boolean, either you can or can't) and writing as an art (shades of gray, non-boolean skill). The assumption is that more people being able to make things with code would make the 10x engineer less valuable - but I think it makes them more valuable. In a noisy world - only the truly great can stand out. And to really make our future great, we are going to need a lot more than CRUD web apps. I could be wrong - but I don't think this is as cut and dry as the author claims.
throwaway1273 12y ago
Teams are not getting smaller. The original Macintosh team was not much larger than the teams he mentions and probably had much more technological impact. The web has been around for a quarter century now and still rather trivial websites that mostly could be replaced by tools sell for some $50k. Because even those basic tools we had 25 years to build are not there yet. Software engineering is actually becoming proper engineering, at least in Europe where much of it is focused more on industry. Crashes are mostly unacceptable now. Embedded software is sometimes formally proved. Finally, as everyone who actually develops software knows, we need to cut many needed features to ship in time. Think how incredibly long it still takes to implement what you can imagine: It takes many months. This is a good indication of how far we are actually from combining things in a lego-like fashion, from making dreams come true quickly because it is so easy.
atmosx 12y ago
The arguments are flawed and taken very lightly. One could argue the exact opposite: Engineers are needed now more than ever. A skilled engineer (what does this even mean in a context so wide?!) can run a website like PinBoard, serving millions of users, from the a jungle in Thailand, on a crappy 56k using a 250 USD ChromeBook. Of course it's possible but how many people do actually manage to do it successfully? And while having AWS, Github and you-name-it makes this possible (scaling was the big issue apparently), AWS and Github can not be run by a lonely engineer, you need an army of them.
morgante 12y ago
This article is wildly off base, particularly when you look at the examples the article cites. WhatsApp was able to scale to so many users while keeping the engineering team small precisely because they hired great engineers who wrote an extremely efficient system in Erlang. (Does he think commodity coders know Erlang? Really!?) They heavily tuned their architecture and built efficient paradigms which kept developer productivity & performance from degrading as their user base grew. [1] Commodity engineers don't write that sort of code. Yes, we increasingly have tools which allow mediocre coders to get stuff done. (For example, Ruby on Rails.) But the inevitable byproduct of letting mediocre coders loose on a stack they only partially understand is a mess of spaghetti code which takes even more developers to maintain. This is already what you see with non-tech corporations who employ dozens/hundreds of developers to maintain Drupal/RoR/Java apps which are significantly simpler in scale & complexity than WhatsApp or Instagram. If you want to use tools well, you need to hire people who understand the tools. Yes, the tooling has improved dramatically. A 10x engineer of yesteryear might actually be a 100x engineer today. But if you give a bad engineer modern tools, it just allows them to fail faster. I might be able to build a house with legos, but I expect to be spending a lot more time repairing it than if I'd just hired a carpenter in the first place. [1] http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...
- mtanski 12y ago
  If I remember correctly from a high scalability post about WhatsApp it was also on bare metal. So more complexity to manage then a simple AWS setup where you can tear up/down in seconds.
- coldtea 12y ago
  >WhatsApp was able to scale to so many users while keeping the engineering team small precisely because they hired great engineers who wrote an extremely efficient system in Erlang. They heavily tuned their architecture and build efficient paradigms which kept developer productivity & performance from degrading as their user base grew. [1] Commodity engineers don't write that sort of code. The problem is they did it with only a few (16?) "great engineers". That's the premise of the article -- our world today might need 100,000 great engineers to solve great problems. Tomorrow 1000 might be enough. As for the "near great" they would too be less needed, and commodity engineers would be the equivalent of burger flipers. >Yes, the tooling has improved dramatically. A 10x engineer of yesteryear might actually be a 100x engineer today. But if you give a bad engineer modern tools, it just allow. The first yes, the second not really. A bad engineer can get enormously more done with modern tools than he could 10 or 30 years ago. Essentially a bad engineer today can build stuff that took high level senior engineers to build -- and do it in less time too. It might be a little crude, but it will work. E.g a bad engineer can automate a workflow that would have taken expert engineers, custom software and several man-years to do 20 years ago, and can do it in a day. And because it's so abstracted, building something like that needs little influence from his skills, so his "badness" doesn't show up much.
ekm2 12y ago
Mathematically,is he saying that because the limit of a function tends to zero,it will actually be equal to zero?
goronbjorn 12y ago
The implications of this are pretty interesting. People will only use software that solves actual problems they have. Software development is now more accessible to more people because of all these frameworks and tools. It only follows that the people most familiar with actual problems will be able to create the most used software, and those people aren't necessarily going to be software engineers by trade. The question "How long before we have a billion-dollar acquisition offer for a one-engineer startup?" is crazy, but likely not too far in the future, but even more interestingly, "How long before we have a billion-dollar acquisition offer for a zero-engineer startup?" might not be that far off either.
spamizbad 12y ago
The author makes some good observations but I feel he is undervaluing post-foundation engineering skills. Sometimes the reason why certain companies end up with so many engineers due to the lack of those so-called "10x engineers" -- specifically, those who know how to build robust, scalable systems while coordinating with the needs of product development. I know some of the engineers who have worked for those lean, highly scaled shops and I know for a fact that they know their shit extremely well - and they've poured hundreds of hours into carefully scaling their infrastructure. They could not be replaced by your average full-stack engineer off the street as they'd immediately be in over their head and would have to spend the next few years learning all the hard-won knowledge of the more experienced engineer.
jamespitts 12y ago
Gerstenzang is watching the latest complexification of small shops into huge industries and projecting it onto the entire field. This is very silly reasoning and it ignores history. Transported back in time, he could say the same thing watching the small, passionate computer shops of the 1970s becoming huge organizations as customer money and investment capital flow in, as more engineers are hired, as efficiencies and industry-wide standardization set in. He could say that the emergence of low-skill labor in the mature industry was the end of engineering, that there was nothing more to do. But there will always be a new layer to this game. Once the previous layer has walked its arc from hobbyist to small shops to huge industries and maturity, there emerges a ragtag group that takes advantage of the new environment. Gerstenzang does identify and appreciate this crucial factor, he just seems to view it as an endpoint and not a beginning. Of course, an AI that can do real, human-level engineering might throw my own entire line of reasoning out of the window.
sergiosgc 12y ago
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.
courtf 12y ago
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.
danielrpa 12y ago
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.
nickpinkston 12y ago
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.
- harpastum 12y ago
  It's not about being in denial. It's that this argument has been brought up with every advance in the last 40 years. In the early '70s it was "Programming in C will allow anyone to program and commoditize the industry!". In the later '70s it was "Object-oriented programming allows modules to be created that snap together like legos, commoditizing the industry!". In the '80s-90s it was "Scripting languages like ruby and python are so simple, it's almost like writing real english! It's so simple you won't even need a programmer." In the early '00s it was "Scratch and other visual programming languages will create a platform that everyone can understand! You can learn it yourself, you don't need a developer." Now, it's "Libraries and tooling are getting so great, what used to take 100 engineers now takes 5. In a few years, it will take zero!" -- That obviously isn't proof that this time is the same as the others. However, this article gives no evidence that I can see why this simplification and removal of inefficiencies is any different than the others.
  - nickpinkston 12y ago
    Yea...and it has gotten easier. I'd bet the average level of software dev (writ large) today is lower than 20 years ago because it's getting easier. (Though I'd bet there's probably more great devs today ever because the pool of devs itself is growing and becoming more accessible) Sure, having MS Word doesn't make you a novelist, but Wordpress + plug-ins can let you make your own pretty high-quality news site with very little technical knowledge - that's real improvement. I'd say to just give it time. My company is doing this to another set of engineers in the mechanical / manufacturing space, so I hear these types of complaints all the time.
billyhoffman 12y ago
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.
noname123 12y ago
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!
birken 12y ago
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
- tferraz 12y ago
  I think the tools are not simpler as being simplist, but easier to use, maybe by having clearer objectives and design than it's predecessor. Also, it was not long ago that put a web system was hardm with lot's of workaround or using not specialized tools for the job. Today is clearer what one need to create and support such system online.
- judk 12y ago
  If AWS is so overpriced, why isn't Amazon profitable? Colo is only cheap if you have cheap sysadmins and have a very predictable non-decreasing long-term compute need.
aaronblohowiak 12y ago
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.
mortenjorck 12y ago
This article sets up a a few interesting points, but stops at only one. Yes, the ever-increasing level of abstraction available in information technology enables less technically-specialized people to creatively utilize the tools available to them, and that's pretty amazing. But the plumber analogy fails to capture the breadth of the tech world. What I would call equally exciting to the empowerment of less-technical developers is what highly technical "10x engineers," or whatever you want to call them, are enabled to do in a world of next-level abstractions.
Iftheshoefits 12y ago
Well, yes, if we restrict our domain to the set of application types for which development can be commoditized, then development becomes a commodity. Not all development is webapp and mobile app development, though, and some things, like actual engineering, just aren't things that can be commoditized (beyond a certain point).
rjknight 12y ago
This doesn't pass the sniff test. The demand for high-quality software continues to outstrip supply. Bad software is an imperfect-but-better-than-nothing substitute for good software, which is why so much of it gets written. The problem here is that there's a sort of Gresham's law effect - bad software drives out good software by infection. Your technology stack is only as good as the worst component, and if you're operating at the level of indirection that Sam Gerstenzang suggests, that's a lot of software that you need to depend on, and your software can only be better than the software it depends at the cost of a lot of effort. Some component in your stack doesn't work the way you need it to? Well, suddenly you're either three layers down the stack trying to fix it, or you're writing a non-trivial piece of software higher up the stack to make up for the deficiencies of the lower level. I'd also dispute Gerstenzang's basic premise that modern engineers need to know less than yesteryear's. 20 years ago, you could write an entire app in Visual Basic. It could integrate with a database, had a drag-and-drop GUI builder, was scriptable using a language that, for all of its many idiosyncrasies, was fairly easy to learn (and you could write plug-in components in C++ if you wanted to). A statically-compiled binary could be put in a floppy disk and would work on any computer running Windows, where it would look basically the same. Modern front-end web code needs to navigate a Rube Goldberg machine of preprocessors and build pipelines that would have embarrassed a C developer from 1988, and incompatibilities with particular browsers, operating systems or form factors frequently cause simple tasks to take longer than expected. Because nearly every modern application is a distributed application in some sense, you need to understand concurrency and network protocols, and if you want to work on both the client and server components of your application, you probably need to know more than one programming language, or the subtle differences in the runtimes that your language has on client and server. And that's just fairly simple web applications! WhatsApp was created by a small team, but that team needed to include skills in everything from Erlang to J2ME. That breadth of knowledge was what gave WhatsApp the key competitive advantage of being able to support almost every mobile device on the market, not just the latest generation of smartphones. You might be able to get a startup off the ground without engineering, but you won't be able to grow it much.
ninjakeyboard 12y ago
You can't scale without well crafted solutions - scaling your rails app on digital ocean would have a higher burn rate than hiring a few good engineers to build scalable code that needs fewer machines. AWS is pricey!!
tferraz 12y ago
This article is confusing two different things: engineer and the tools used by the engineers. It's not like the tools will ever substitute an engineer or exist one tool to rule all other tools or even one tool that do everything. What we have now better tools than before, which makes possible for few engineers to produce more than before. Examples from other jobs, graphic designers were not substituted by tools like Photoshop and InDesign, will they ever be? I don't think so - and that's by design, the tool is to easier the job, let the person concentrate where it makes more money, and not to substitute the person.
jnks 12y ago
The software equivalent to doing your own plumbing has been here since the mid-90s: build your homepage with Geocities.
incision 12y ago
Part me wants to agree the picture painted here, but bits like the one below make the whole thing out to be an veiled appeal for more naive investment targets without the myriad complications of engineers. Basically, they'd like a lazy Susan of people who've done a bunch of leg work on a 'lego' app or website and are ready to accept $50K for 60%, Shark Tank style. >'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.' Not exactly. In keeping with the analogies to traditional infrastructure and trades. This sort of commoditization of labor allows a certain class of problems to be solved - repeatable, fairly well-understood ones for which there are ready instructions and appropriate 'legos' available. Providers of these services race to the bottom and have to be kept in check with codes and consumer paid inspections to ensure that their snap-together builds meet barest minimums of safety and sensible design. In this race to the bottom, implementers don't care and won't pay for better components, just cheaper ones that meet the minimum spec. There's good reason people loathe calling a plumber or HVAC repairman as much as they love certain tech companies known for their design and engineering. This is probably fine for money men, but neutral to bad for nearly everybody else.
hharrisbrown 12y ago
Get ready for the next wave of "business bootcamps"
arach 12y ago
I happen to think that because the leverage is greater, the reward for hiring highly skilled & talented engineers is much greater than it ever was. All the products mentioned were functionally simple and I like billyhoffman's explanation of why the low functionality/large audience products don't represent the majority of the industry - https://news.ycombinator.com/item?id=8109434 https://news.ycombinator.com/item?id=8109434 I'm trying to understand how Sam Gerstenzang becomes a partner at Andreessen Horowitz and I can't figure it out. http://www.crunchbase.com/person/sam-gerstenzang http://www.crunchbase.com/person/sam-gerstenzang I don't want to ad hominem, I'm just a bit puzzled. It seems like he was an engineer for about 12 months. Anyone here know him?
elision 12y ago
Wouldn't that mean The Happy Demise of the VC as well?
hadoukenio 12y ago
> Software engineering is not yet plumbing — or Legos — because our standards are incomplete, our libraries incompatible, scaling is still not free and our software still buggy. I 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.
estraschnov 12y ago
10X engineers won't disappear, but they will do other things, and that's great! http://make.bubble.is/post/93505282266/conversion-10x-engineer http://make.bubble.is/post/93505282266/conversion-10x-engine...

114 points by mycodebreaks 12y ago

dman 12y ago

I would like to think there will always be a frontier, and there will always be people driven by their curiosity to seek the frontier out. Some of them will be called 10x engineers, some visionaries, some pioneers.

ojbyrne 12y ago

This seems to be pretty specious reasoning which has at its heart the principle that acquisitions are the final goal, not a functioning enterprise. I think the acquiring companies would tend to disagree.

mdgrech23 12y ago

This article fails to mention that our expectations for software have increased. We expect more from apps than ever before. This has lead to new specialities such as Front End Engineers and UX staff. Surely we can build more with less with current technologies as compared to the past but we also expect more. If our expectations outpace technological improvements this could lead to spending more time/money on developing apps.

frozenport 12y ago
Consider Bootstrap and the uniformity it offers in GUIs with little effort.
- rjknight 12y ago
  Uniformity isn't so great for people who want to differentiate their products. (Not saying that they should want to differentiate their products visually, but they almost certainly do want this).
timrosenblatt 12y ago
Well put. The more software you write, the more you need. http://www.timrosenblatt.com/blog/2013/04/24/the-more-software-you-have-the-more-software-you-need/ http://www.timrosenblatt.com/blog/2013/04/24/the-more-softwa... disclaimer, that's my blog! ;)

nsxwolf 12y ago

This seems to be ignoring entire classes of software. I can't imagine the enterprise development world will be taken over with easy to snap together software packages any time soon.

samg 12y ago
Why do you think enterprise development is different?
- nsxwolf 12y ago
  Because enterprises are infinitely complex and diverse and there will never be a single piece of software that can run all the businesses in the world with a couple configuration setting tweaks.

rahimnathwani 12y ago

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 problem solving? Programming will always be about problem solving, no matter how easy you make the final implementation of the design.

jgable 12y ago
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.
- eldavido 12y ago
  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.
  - menzoic 12y ago
    You compare two people who have different skills. Presumably either one could learn the skills of the other. Why choose the one with the easiest skills to learn?

mikeryan 12y ago

Its funny I've always thought that Twitter could really be run by 100 folks (heck I've said 40) and be hugely profitable and it a lot of ways more efficient. Instead they've got 2300 employees to allow folks stream 140 character tweets.

timrosenblatt 12y ago
That's a bit optimistic. Their sales team alone is bigger than that. Companies aren't just engineers.
deleted 12y ago
[deleted]

chillacy 12y ago

It's already happening. There's an incredible difference (in personality, tooling, skills) between your typical full-stack web developer and kernel programmer, as there is between the kernel programmer and chip designer. They're each difficult in their own way, but one definitely has a lower barrier of entry.

EGreg 12y ago

I 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 source platform, http://phponpie.com http://phponpie.com Since then it's come a long way, and it turned into a real platform: http://platform.qbix.com http://platform.qbix.com Like mobile apps, social apps require an operating system that solves common problems in a standard way: * User signup and secure auth, login * Should work with emails, mobile #, facebook * Accessible from desktop, tablets, mobile * Contacts integration / friendlists * Real time collaboration from any device * Offline notifications via fb, sms, app notifications etc. * Access control and privacy - as expressive as possible * Native apps on iPhone and iOS via Cordova * Invitations and one-click account creation * Encourage best practices for scaling, web standards etc. * Installer to upgrade apps and plugin versions cleanly etc etc. All that stuff should have standard solutions which you can override. The apps and plugins should all interoperate. And finally, since I really care about decentralization, it would be cool if this whole operating system could be as decentralized as Wordpress is for blogs, as opposed to say facebook. That would also solve all the scaling problems that facebook and other centralized social networks have. That last part - decentralizing the social network - took the most effort, as I had to solve problems of security, identity, privacy, as well as app and plugin versioning and signing across a distributed network. Just like iOS is for mobile apps, and Bitcoin is for distributed contract apps, the Q Platform is if you want a social layer for your app, from user accounts to everything else, without having to write it from scratch. Yeah, so that's what I built. Link to the open source: http://github.com/EGreg/Q http://github.com/EGreg/Q

EGreg 12y ago
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?
- GFischer 12y ago

jjoonathan 12y ago

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

nsxwolf 12y ago
It seems this claim has been made forever. COBOL was supposed to make programmers unnecessary. So were rules engines. And code generators and an endless list of other technologies.
- jjoonathan 12y ago
  I agree that Gerstenzang is premature. But it'll happen eventually. If it doesn't happen by making programming easy it will happen by flooding the industry with enough competent programmers to have the same effect (depressed wages, high unemployment, etc). See: non-software engineering occupations (excepting doctors, who have managed to turn the risks inherent in their profession into a legally mandated union).
  - kabdib 12y ago
    Human-equivalent AI has always been 30 years out . . . 20 years if you don't know the field. :-)
  - menzoic 12y ago
    Demand for engineers is increasing much more rapidly than non-software engineering occupations. Soon every company will need an software engineer of some sort.
ardit33 12y ago
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 happen. If you are a full stack engineer, and pair up with a buddy, you can make it happen, with a lot less. If you are a great engineer, you are the capital!

harpastum 12y ago

I'm failing to follow the logic here. The initial point is that "The potential impact of the lone software engineer is soaring". However, the author then takes that to mean that engineers will be less valuable in the future? This analogy seems apt to me, and I think it makes the logical leap more obvious: Fifty years ago, if you wanted to design a new model of car, you had to get plywood and clay, and work hundreds of hours of to get even the most basic model completed. Now, you can open up a CAD program and begin making real decisions immediately. What previously took a large team to build, a single designer can now do. (The analogous logical leap to what the OP seems to be saying is) Soon, we won't need designers at all! A company will come out with a new car model simply by snapping design-legos together. In reality, removing inefficiency made designers more valuable. If you were the best car designer 50 years ago, you had to spend a significant amount of time molding clay. Today, you spend almost all of your time creatively finding solutions to problems. I see the value of individual engineers increasing significantly as we remove cruft in the creation process.

akavi 12y ago
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.
- eldavido 12y ago
  I think the change is purely additive. Great engineering is no less valuable than it once was, but pure "idea guys" can do stuff now that they couldn't do before.
  - GFischer 12y ago
    If they do stuff, by definition then they aren't "idea guys" :) You might mean "nontechnical people can do a functioning MVP" which they couldn't before :)
- monochr 12y ago

djb_hackernews 12y ago

Less overhead, more productive, yet still the same pay...

eldavido 12y ago

This has always been the case. Software people in the 70s and 80s already had the distinction between "systems" and "application" programmers -- the former understood to be concerned with making the pipes and plumbing, vs. the applications guys concerned with the end users. Applications have always been like legos. I work as a systems developer but often do consulting projects as an application developer, and it's a totally different mindset. Writing software for end users, I rarely even remotely think about CS, algorithms, pointers, recursion, numerical stability, memory allocators, etc, whereas I do care intimately about the tools I'm using, much like I suspect a carpenter cares about what drill he's got. On the other end of the spectrum, I can hardly go a day writing traditional "systems" software without considering things like what data structure MongoDB/Postgres uses to hold indices, and gigantic, complex consensus problems (distributed systems, e.g. how DNS behaves). I hope we start to treat these two endeavors differently because they require totally different mindsets and education. A typical app developer need know no more about how OSes work, than a plumber needs to understand the metallurgy used to make pipes.

the_af 12y ago
I see the overall point you're making, but it's not true programming applications is always (or even often) like building with Lego pieces. It's just that many of us have to write mindless web apps which mostly consist of CRUDs. Those definitely are like working with Lego. CS, algorithms, pointers, recursion, numerical stability, etc, etc, are all alive and well in the world of applications programming. Just not in the world of run-of-the-mill CRUDs.
- eldavido 12y ago
  Sure. And to be clear, I in no way think applications is easier. In fact, applications, as they're closer to end-users, have to deal with all kinds of socially-imposed whimsy like people with four names, tax rules, interest rate calculations, and 100 other things that make my head hurt to consider.

Todd 12y ago

The Lego approach has been the holy grail of software development at least back into the 80's with OOP. Yet it still requires programmers who know about data structures, algorithms, etc. to write software. Even if they're just cobbling together libraries, there is still a lot of additional functionality required--not just 'glue' code. All we have now are improvements in efficiency (great, mind you), with operational improvements like IaaS and development improvements with the great OSS that we have now. It will require a sea change in the field of comp sci. to achieve Lego-like orders of magnitude improvements.

deleted 12y ago

[deleted]

7Figures2Commas 12y ago

> The same software foundation (open source software, development tools like Github, infrastructure as a service provided by the likes of Digital Ocean, and more) that allowed Whatsapp and Imgur to scale, means that experience and skill writing software become less important. The author focuses a lot on ease of scaling, but the bigger challenge has always been building applications (experiences) that need scale. If you build it, they will not come.

jeffchuber 12y ago

Let's compare writing software to writing English. (Writing is kinda an individual sport) Almost everyone can write a short story in English, but the 10x writers really really stand out. Writing isn't a perfect analogy - we generally think of programming as a skill (right and wrong, boolean, either you can or can't) and writing as an art (shades of gray, non-boolean skill). The assumption is that more people being able to make things with code would make the 10x engineer less valuable - but I think it makes them more valuable. In a noisy world - only the truly great can stand out. And to really make our future great, we are going to need a lot more than CRUD web apps. I could be wrong - but I don't think this is as cut and dry as the author claims.

throwaway1273 12y ago

Teams are not getting smaller. The original Macintosh team was not much larger than the teams he mentions and probably had much more technological impact. The web has been around for a quarter century now and still rather trivial websites that mostly could be replaced by tools sell for some $50k. Because even those basic tools we had 25 years to build are not there yet. Software engineering is actually becoming proper engineering, at least in Europe where much of it is focused more on industry. Crashes are mostly unacceptable now. Embedded software is sometimes formally proved. Finally, as everyone who actually develops software knows, we need to cut many needed features to ship in time. Think how incredibly long it still takes to implement what you can imagine: It takes many months. This is a good indication of how far we are actually from combining things in a lego-like fashion, from making dreams come true quickly because it is so easy.

atmosx 12y ago

The arguments are flawed and taken very lightly. One could argue the exact opposite: Engineers are needed now more than ever. A skilled engineer (what does this even mean in a context so wide?!) can run a website like PinBoard, serving millions of users, from the a jungle in Thailand, on a crappy 56k using a 250 USD ChromeBook. Of course it's possible but how many people do actually manage to do it successfully? And while having AWS, Github and you-name-it makes this possible (scaling was the big issue apparently), AWS and Github can not be run by a lonely engineer, you need an army of them.

morgante 12y ago

This article is wildly off base, particularly when you look at the examples the article cites. WhatsApp was able to scale to so many users while keeping the engineering team small precisely because they hired great engineers who wrote an extremely efficient system in Erlang. (Does he think commodity coders know Erlang? Really!?) They heavily tuned their architecture and built efficient paradigms which kept developer productivity & performance from degrading as their user base grew. [1] Commodity engineers don't write that sort of code. Yes, we increasingly have tools which allow mediocre coders to get stuff done. (For example, Ruby on Rails.) But the inevitable byproduct of letting mediocre coders loose on a stack they only partially understand is a mess of spaghetti code which takes even more developers to maintain. This is already what you see with non-tech corporations who employ dozens/hundreds of developers to maintain Drupal/RoR/Java apps which are significantly simpler in scale & complexity than WhatsApp or Instagram. If you want to use tools well, you need to hire people who understand the tools. Yes, the tooling has improved dramatically. A 10x engineer of yesteryear might actually be a 100x engineer today. But if you give a bad engineer modern tools, it just allows them to fail faster. I might be able to build a house with legos, but I expect to be spending a lot more time repairing it than if I'd just hired a carpenter in the first place. [1] http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...

mtanski 12y ago
If I remember correctly from a high scalability post about WhatsApp it was also on bare metal. So more complexity to manage then a simple AWS setup where you can tear up/down in seconds.
coldtea 12y ago
>WhatsApp was able to scale to so many users while keeping the engineering team small precisely because they hired great engineers who wrote an extremely efficient system in Erlang. They heavily tuned their architecture and build efficient paradigms which kept developer productivity & performance from degrading as their user base grew. [1] Commodity engineers don't write that sort of code. The problem is they did it with only a few (16?) "great engineers". That's the premise of the article -- our world today might need 100,000 great engineers to solve great problems. Tomorrow 1000 might be enough. As for the "near great" they would too be less needed, and commodity engineers would be the equivalent of burger flipers. >Yes, the tooling has improved dramatically. A 10x engineer of yesteryear might actually be a 100x engineer today. But if you give a bad engineer modern tools, it just allow. The first yes, the second not really. A bad engineer can get enormously more done with modern tools than he could 10 or 30 years ago. Essentially a bad engineer today can build stuff that took high level senior engineers to build -- and do it in less time too. It might be a little crude, but it will work. E.g a bad engineer can automate a workflow that would have taken expert engineers, custom software and several man-years to do 20 years ago, and can do it in a day. And because it's so abstracted, building something like that needs little influence from his skills, so his "badness" doesn't show up much.

ekm2 12y ago

Mathematically,is he saying that because the limit of a function tends to zero,it will actually be equal to zero?

goronbjorn 12y ago

The implications of this are pretty interesting. People will only use software that solves actual problems they have. Software development is now more accessible to more people because of all these frameworks and tools. It only follows that the people most familiar with actual problems will be able to create the most used software, and those people aren't necessarily going to be software engineers by trade. The question "How long before we have a billion-dollar acquisition offer for a one-engineer startup?" is crazy, but likely not too far in the future, but even more interestingly, "How long before we have a billion-dollar acquisition offer for a zero-engineer startup?" might not be that far off either.

spamizbad 12y ago

The author makes some good observations but I feel he is undervaluing post-foundation engineering skills. Sometimes the reason why certain companies end up with so many engineers due to the lack of those so-called "10x engineers" -- specifically, those who know how to build robust, scalable systems while coordinating with the needs of product development. I know some of the engineers who have worked for those lean, highly scaled shops and I know for a fact that they know their shit extremely well - and they've poured hundreds of hours into carefully scaling their infrastructure. They could not be replaced by your average full-stack engineer off the street as they'd immediately be in over their head and would have to spend the next few years learning all the hard-won knowledge of the more experienced engineer.

jamespitts 12y ago

Gerstenzang is watching the latest complexification of small shops into huge industries and projecting it onto the entire field. This is very silly reasoning and it ignores history. Transported back in time, he could say the same thing watching the small, passionate computer shops of the 1970s becoming huge organizations as customer money and investment capital flow in, as more engineers are hired, as efficiencies and industry-wide standardization set in. He could say that the emergence of low-skill labor in the mature industry was the end of engineering, that there was nothing more to do. But there will always be a new layer to this game. Once the previous layer has walked its arc from hobbyist to small shops to huge industries and maturity, there emerges a ragtag group that takes advantage of the new environment. Gerstenzang does identify and appreciate this crucial factor, he just seems to view it as an endpoint and not a beginning. Of course, an AI that can do real, human-level engineering might throw my own entire line of reasoning out of the window.

sergiosgc 12y ago

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.

courtf 12y ago

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.

danielrpa 12y ago

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.

nickpinkston 12y ago

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.

harpastum 12y ago
It's not about being in denial. It's that this argument has been brought up with every advance in the last 40 years. In the early '70s it was "Programming in C will allow anyone to program and commoditize the industry!". In the later '70s it was "Object-oriented programming allows modules to be created that snap together like legos, commoditizing the industry!". In the '80s-90s it was "Scripting languages like ruby and python are so simple, it's almost like writing real english! It's so simple you won't even need a programmer." In the early '00s it was "Scratch and other visual programming languages will create a platform that everyone can understand! You can learn it yourself, you don't need a developer." Now, it's "Libraries and tooling are getting so great, what used to take 100 engineers now takes 5. In a few years, it will take zero!" -- That obviously isn't proof that this time is the same as the others. However, this article gives no evidence that I can see why this simplification and removal of inefficiencies is any different than the others.
- nickpinkston 12y ago
  Yea...and it has gotten easier. I'd bet the average level of software dev (writ large) today is lower than 20 years ago because it's getting easier. (Though I'd bet there's probably more great devs today ever because the pool of devs itself is growing and becoming more accessible) Sure, having MS Word doesn't make you a novelist, but Wordpress + plug-ins can let you make your own pretty high-quality news site with very little technical knowledge - that's real improvement. I'd say to just give it time. My company is doing this to another set of engineers in the mechanical / manufacturing space, so I hear these types of complaints all the time.

billyhoffman 12y ago

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.

noname123 12y ago

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!

birken 12y ago

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

tferraz 12y ago
I think the tools are not simpler as being simplist, but easier to use, maybe by having clearer objectives and design than it's predecessor. Also, it was not long ago that put a web system was hardm with lot's of workaround or using not specialized tools for the job. Today is clearer what one need to create and support such system online.
judk 12y ago
If AWS is so overpriced, why isn't Amazon profitable? Colo is only cheap if you have cheap sysadmins and have a very predictable non-decreasing long-term compute need.

aaronblohowiak 12y ago

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.

mortenjorck 12y ago

This article sets up a a few interesting points, but stops at only one. Yes, the ever-increasing level of abstraction available in information technology enables less technically-specialized people to creatively utilize the tools available to them, and that's pretty amazing. But the plumber analogy fails to capture the breadth of the tech world. What I would call equally exciting to the empowerment of less-technical developers is what highly technical "10x engineers," or whatever you want to call them, are enabled to do in a world of next-level abstractions.

Iftheshoefits 12y ago

Well, yes, if we restrict our domain to the set of application types for which development can be commoditized, then development becomes a commodity. Not all development is webapp and mobile app development, though, and some things, like actual engineering, just aren't things that can be commoditized (beyond a certain point).

rjknight 12y ago

This doesn't pass the sniff test. The demand for high-quality software continues to outstrip supply. Bad software is an imperfect-but-better-than-nothing substitute for good software, which is why so much of it gets written. The problem here is that there's a sort of Gresham's law effect - bad software drives out good software by infection. Your technology stack is only as good as the worst component, and if you're operating at the level of indirection that Sam Gerstenzang suggests, that's a lot of software that you need to depend on, and your software can only be better than the software it depends at the cost of a lot of effort. Some component in your stack doesn't work the way you need it to? Well, suddenly you're either three layers down the stack trying to fix it, or you're writing a non-trivial piece of software higher up the stack to make up for the deficiencies of the lower level. I'd also dispute Gerstenzang's basic premise that modern engineers need to know less than yesteryear's. 20 years ago, you could write an entire app in Visual Basic. It could integrate with a database, had a drag-and-drop GUI builder, was scriptable using a language that, for all of its many idiosyncrasies, was fairly easy to learn (and you could write plug-in components in C++ if you wanted to). A statically-compiled binary could be put in a floppy disk and would work on any computer running Windows, where it would look basically the same. Modern front-end web code needs to navigate a Rube Goldberg machine of preprocessors and build pipelines that would have embarrassed a C developer from 1988, and incompatibilities with particular browsers, operating systems or form factors frequently cause simple tasks to take longer than expected. Because nearly every modern application is a distributed application in some sense, you need to understand concurrency and network protocols, and if you want to work on both the client and server components of your application, you probably need to know more than one programming language, or the subtle differences in the runtimes that your language has on client and server. And that's just fairly simple web applications! WhatsApp was created by a small team, but that team needed to include skills in everything from Erlang to J2ME. That breadth of knowledge was what gave WhatsApp the key competitive advantage of being able to support almost every mobile device on the market, not just the latest generation of smartphones. You might be able to get a startup off the ground without engineering, but you won't be able to grow it much.

ninjakeyboard 12y ago

You can't scale without well crafted solutions - scaling your rails app on digital ocean would have a higher burn rate than hiring a few good engineers to build scalable code that needs fewer machines. AWS is pricey!!

tferraz 12y ago

This article is confusing two different things: engineer and the tools used by the engineers. It's not like the tools will ever substitute an engineer or exist one tool to rule all other tools or even one tool that do everything. What we have now better tools than before, which makes possible for few engineers to produce more than before. Examples from other jobs, graphic designers were not substituted by tools like Photoshop and InDesign, will they ever be? I don't think so - and that's by design, the tool is to easier the job, let the person concentrate where it makes more money, and not to substitute the person.

jnks 12y ago

The software equivalent to doing your own plumbing has been here since the mid-90s: build your homepage with Geocities.

incision 12y ago

Part me wants to agree the picture painted here, but bits like the one below make the whole thing out to be an veiled appeal for more naive investment targets without the myriad complications of engineers. Basically, they'd like a lazy Susan of people who've done a bunch of leg work on a 'lego' app or website and are ready to accept $50K for 60%, Shark Tank style. >'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.' Not exactly. In keeping with the analogies to traditional infrastructure and trades. This sort of commoditization of labor allows a certain class of problems to be solved - repeatable, fairly well-understood ones for which there are ready instructions and appropriate 'legos' available. Providers of these services race to the bottom and have to be kept in check with codes and consumer paid inspections to ensure that their snap-together builds meet barest minimums of safety and sensible design. In this race to the bottom, implementers don't care and won't pay for better components, just cheaper ones that meet the minimum spec. There's good reason people loathe calling a plumber or HVAC repairman as much as they love certain tech companies known for their design and engineering. This is probably fine for money men, but neutral to bad for nearly everybody else.

hharrisbrown 12y ago

Get ready for the next wave of "business bootcamps"

arach 12y ago

I happen to think that because the leverage is greater, the reward for hiring highly skilled & talented engineers is much greater than it ever was. All the products mentioned were functionally simple and I like billyhoffman's explanation of why the low functionality/large audience products don't represent the majority of the industry - https://news.ycombinator.com/item?id=8109434 https://news.ycombinator.com/item?id=8109434 I'm trying to understand how Sam Gerstenzang becomes a partner at Andreessen Horowitz and I can't figure it out. http://www.crunchbase.com/person/sam-gerstenzang http://www.crunchbase.com/person/sam-gerstenzang I don't want to ad hominem, I'm just a bit puzzled. It seems like he was an engineer for about 12 months. Anyone here know him?

elision 12y ago

Wouldn't that mean The Happy Demise of the VC as well?

hadoukenio 12y ago

> Software engineering is not yet plumbing — or Legos — because our standards are incomplete, our libraries incompatible, scaling is still not free and our software still buggy. I 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.

estraschnov 12y ago

10X engineers won't disappear, but they will do other things, and that's great! http://make.bubble.is/post/93505282266/conversion-10x-engineer http://make.bubble.is/post/93505282266/conversion-10x-engine...