Hacker News new | comments | show | ask | jobs | submit login

As much as I'd like to agree with the author, the case stated is pretty holey.

To pick on the "We'll never be automated example":

It's not that one day programs will write programs that write--oh wait, that's already happened. It's not that tools will come around that making throwing up a simple website with ecommerce functionality ea--shit, that happened too.

It's that the core functions of software, from a business perspective, are pretty much nailed down now. It's that the average dudebro with an MBA and half a brain can throw together an MVP and start getting market feedback. It's that the homeless guy who lives down the street from me can publish an ebook from his acer.

The thing that we all love so much, the removal of gatekeepers and democratization of information capital? Yeah, so, that thing is what will put us out of jobs. And that's fine.

The thing the author misses is not that there won't be a few gigs around for people who need to optimize their database backends and red-black tree all the things and skiplist their twitters--it's that the vast majority of things that used to require people to find a coder to help them are now a few buttons away.

Oh, and also that we've cultivated a user base so ignorant and attracted to simple glossy black boxes that they can't appreciate what it is to have a real engineer along for the ride anyways, nor how to usefully communicate with them if they had one. That's going to sting too.




We do have programs that write programs. Who's using them?

I like your optimism, but the average guy with an MBA definitely can't throw a MVP together, especially not in 2013 when the low hanging fruit have been steadily picked off. The bar is continuously being raised, and it'll be cheaper for the MBA to hire a developer to throw that MVP together, using highly complex and abstract components.

If I'm getting the second half of your reply right, you're saying it's the availability of high-quality low-complexity zero-cost solutions to mundane problems that's going to put software developers out of a job. But that's exactly what I address in my post - these things were going to be automated anyway. And don't be disappointed by a user base attracted to glossy boxes - some of them will get curious eventually.


"We do have programs that write programs. Who's using them?"

If you count things like Weebly, the answer is: a "whole bunch of people", heading rapidly toward "everyone". Not that long ago, every Weebly customer would have meant a programming job for someone. That kind of work is gone.

Then take a close look at AWS, Heroku, Rackspace...those were all systems engineering jobs. Startups don't have to hire people to do that now. What used to be thousands of jobs is now maybe a tenth of that.

"the average guy with an MBA definitely can't throw a MVP together"

You're wrong. It happens all the time. It happens so often that's a cliche. You can't go to a meetup in the valley without being assaulted by ten brohans looking for "feedback" on their "MVP".

The important thing to realize is that the need for software engineers doesn't scale with the maximum complexity of software projects; it scales as a function of the average complexity: think of a bell curve, where the X-axis is "complexity", and "need for engineers" is the area under the curve to one side of some vertical line. We keep moving that line further and further toward greater complexity. So far, the distribution has shifted to keep up, but there's no guarantee that will keep happening.

Are we going to need people to write complex, novel software in 2050? Absolutely. Will we need more people than we need to write complex, novel software today? That's not a question with a predictable answer. It might well turn out that the "average" programmer (say, the ones who know how to use Rails and jQuery and are fond of complaining about interview questions involving algorithms) is a doomed creature.


A website is not a program, let's be fair. It's at most a minimum amount of logic wrapped around content. Automating it is easy, and it has long ago lost its prestige.

Re MBA guys - maybe we have a different understanding of MVP here. I don't mean PowerPoint-ware - I mean version 0.1 of a product solving real problems. MBAs that are working on something more complex than yet another social network will immediately look for an engineer.

I'm not missing the average/maximum-complexity point at all, but I have a different view on it than you do. The average complexity won't stay constant, it'll keep increasing, and the average programmer will have to adapt. Will that mean a reduction in demand? I doubt it - we've yet to see the full extent of how software can be used. On the flip side, I constantly see clients looking for someone to fix or alter their "automated" installations - the average programmer will surely be in enough demand from these cases alone.


>A website is not a program, let's be fair. It's at most a minimum amount of logic wrapped around content. Automating it is easy, and it has long ago lost its prestige.

Previously, most people would say that it requires programmers to make a website. Now you're demoting producing a website to something that doesn't even require programmers, saying it's been automated for several years.

I think this proves exactly the point of the GP.

Re Re MBA guys - I don't know how many MBAs are working on something more complex than another social network, because many successful businesses recently have been quite easy to build a MVP for with not a lot of programming skills.

Examples of succesful companies with not difficult to program MVPs: AirBnB, Instagram, Twitter, Groupon.

I believe many MBAs could build something like these given some time. If we want to broaden the category from MBAs to just STEM students, I know very few STEM students at my college (which is ~97% STEM majors) who couldn't build more than a MVP for one of these sites given 2-3 months.


@lightcatcher:

>Previously, most people would say that it requires programmers to make a website.

It hasn't required a programmer to build a website in many years now - HTML and CSS were declarative to begin with. It's only with the advent of CMS's - which are definitely NOT all automated (i.e. Joomla or WordPress) - that programmers entered the picture.

> Re Re MBA guys - I don't know how many MBAs are working on something more complex than another social network, because many successful businesses recently have been quite easy to build a MVP for with not a lot of programming skills.

Good point, but are they doing it? Facebook, Twitter, Instagram, and Airbnb all had technical founders. The true complexity of these startups lies in their server software - how to optimize at scale and so on. An MBA aware of this complexity deserves all the success he or she can get.


"It hasn't required a programmer to build a website in many years now - HTML and CSS were declarative to begin with. It's only with the advent of CMS's - which are definitely NOT all automated (i.e. Joomla or WordPress) - that programmers entered the picture."

Well, first off, you're just shifting the goalposts and redefining what it means to "program" to suit your needs: it's inconvenient for your argument that there's now software that does what programmers used to do, so you just call those things something else.

But it doesn't matter, because you can't run from the core of the argument: it isn't limited to static HTML & CSS. Want web forms, but don't know how to write software or use databases? There's Wufoo, and dozens of others. Want to send email? Mailgun. Mailchimp. Want to accept payments? Paypal, Stripe. Want to show an interactive map with stuff on it? Google maps has you covered. Want to implement search on your website, but don't know anything about search? Swiftype will do that. So will Google site search. Need a sophisticated customer analytics system. OK. That'll be one line of javascript, please.

And what's more: it's only a matter of time before someone rolls all of these tools together into a pointy clicky interface that eliminates the token integration work (assuming they haven't already). There's no part of your argument that is safe from the trends that have been driving our industry.

"The true complexity of these startups lies in their server software - how to optimize at scale and so on."

True, but like I said before: almost nobody needs that. There's always going to be the need for complex software...it's just not clear how many people will be asking for it.


Even if you limit it to static HTML and CSS, there are still many people who do that as a job. The only thing that has really been automated away is when someone is willing to use bog standard templates.

And in that respect, that kind of optimization has been happening since the dawn of the personal computer. Lotus 1-2-3 was the defining application of the PC, allowing average users to do programming-like operations that were once only in reach of programmers.


@timr:

> Well, first off, you're just shifting the goalposts and redefining what it means to "program" to suit your needs: it's inconvenient for your argument that there's now software that does what programmers used to do, so you just call those things something else.

Definitely not. I think "website automation" is among the simplest kinds of software automation and historically it has not required a significant amount of programming.

> But it doesn't matter, because you can't run from the core of the argument: it isn't limited to static HTML & CSS. Want web forms, but don't know how to write software or use databases? There's Wufoo, and dozens of others. Want to send email? Mailgun. Mailchimp. Want to accept payments? Paypal, Stripe. Want to show an interactive map with stuff on it? Google maps has you covered. Want to implement search on your website, but don't know anything about search? Swiftype will do that. So will Google site search. Need a sophisticated customer analytics system. OK. That'll be one line of javascript, please.

That's a stretch. Wufoo, PayPal, Stripe, Mailgun, Google Maps, and MailChimp are not going to cover 100% of use cases, nor do they all come free. You're also ignoring that many of these services are alternatives, not integrations (MailChimp, PayPal, Stripe, Mailgun, Google Maps), of older services (AWeber, Authorize, MapQuest) that filled the same function, and a few of them are filling a need that simply didn't exist before prior automation tools (MailChimp for email lists, Stripe for payment processing). It's not a zero-sum game, nor do the same players stay on top throughout time.

> And what's more: it's only a matter of time before someone rolls all of these tools together into a pointy clicky interface that eliminates the token integration work (assuming they haven't already). There's no part of your argument that is safe from the trends that have been driving our industry.

I actually mentioned that in the post: "For every API that wraps around a business process, there's an application yet to be written (and an API around that application in due time)." You seem to think there's some end point, where most software will just be done and most activity automated. I doubt that will ever be the case.

> True, but like I said before: almost nobody needs that. There's always going to be the need for complex software...it's just not clear how many people will be asking for it.

You seem to imply that in the future, most non-complex (i.e. average) software will just either exist or be generated on demand. That seems far-fetched - there are programs orders of magnitudes simpler than "software generators" that routinely need to be adjusted and tuned to produce correct output (as will all the automated APIs in the future).


"MBAs that are working on something more complex than yet another social network will immediately look for an engineer."

Put bluntly, I think that both Groupon and Zappos started as glorified Wordpress installs.

I don't think that the average complexity for business programs is going to change--at their core, most all of them have the business proposition "Take my X so I can get Y in time Z". Everything else is window dressing.


Has anyone ever considered groupon as a technical challenge? Most of their personnel were salesmen, were they not?


> Not that long ago, every Weebly customer would have meant a programming job for someone.

Isn't that kind of like saying that every pirated album == a lost sale?


Right, that's the fallacy being made constantly here - as if Weebly and Google Maps are taking jobs from developers, when really there would have been no need for a site or a mapping component in their absence.


"...as if Weebly and Google Maps are taking jobs from developers, when really there would have been no need for a site or a mapping component in their absence."

There were once a great many programmers who did custom website development. That market doesn't exist anymore. It's not a "fallacy" if it actually happened.

What you're really trying to argue is that Weebly and Google Maps and the others expanded the market for professional software development -- that all of those people who did simple websites are now doing harder things. That's true so far, but there's no guarantee that it will continue to be true.

What's happening here is that you're arguing sound-bite economics, and we're arguing a point that's about five steps ahead of where you are: eventually, automation will reach a point where the average need of a customer will be satisfied without the assistance of a programmer. That we have not yet reached that point is not an effective counterargument. It has happened in nearly every other industry, and thus far, programming appears to be following the same curve.

It's the same reason that we no longer pay artisan woodworkers to make most of our furniture.


> There were once a great many programmers who did custom website development. That market doesn't exist anymore.

This is not true; just try doing a search for "web developer" in any major city. There will be dozens, if not hundreds of jobs listed on almost any day of the year.


>It's not that one day programs will write programs that write--oh wait, that's already happened

Hi, I write software for a living. Just replace the most tedious part, please: debugging.

Say what? You can't even give me a probability [1] that my program has an infinite loop in it?

[1] http://en.wikipedia.org/wiki/Chaitin%27s_constant


What makes you think that you can give a probability that a program has an infinite loop in it?

As for your request:

https://ece.uwaterloo.ca/~lintan/publications/r2fix-icst13.p...

But bugs aside, part of the allure of having a program generate a program is that it is much less likely to produce bugs in the first place. That said, we still have a ways to go before we achieve human-like synthetic developers.


>What makes you think that you can give a probability that a program has an infinite loop in it?

I can't. That's why I basically rummage through the code base, using all kinds of heuristics, most of which I make up on the spot. Sometimes it takes me two minutes to find that off-by-one, and other times two days.

Interesting paper. I don't think it will help that much though:

>Ideally, we want to automatically generate patches for all bug reports. Realistically, it is impossible. [...] Even among bugs that can be fixed, some are too complex to be fixed automatically [...] Therefore, a realistic goal is to automatically generate patches for relatively simple bugs [where] the bug reports contain useful information, e.g., the buggy file and the symptom


Yeah... my last project at the company I worked for was basically to automate myself out of a job. They kept one developer to maintaining everything, the rest of us were kicked off the assembly line.


Hint: you should be constantly automating yourself out of your current job and into your new one.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: