Software will eat software in a remote-first world

The premise that we are on the verge of some breakthroughs in software development that will significantly reduce the need for engineers is really weak, and is something people have been saying for decades (see the failed fifth generation of programming languages from the 1980s for an example).<p>In my experience, software engineering is endless, complicated decision making about how something should work and how to make changes without breaking something else rather than the nuts and bolts of programming. It’s all about figuring out what users want and how to give it to them in a way that is feasible.<p>The idea that we will have some abstraction that will someday (in the foreseeable future) save us from all of this difficult work sounds very far fetched to me, and I can’t imagine how that would work.<p>Even the example of hosting complexity being replaced by cloud companies seems kind of silly to me. Maybe that’s saving very small companies a sizable fraction of their engineering resources, but I really doubt it for medium or larger companies.<p>The cloud saves us from some complexity, but it doesn’t just magically design and run a backend for your application. You still need people who understand things like docker, kubernetes, endless different database options, sharding, indexing, failover, backup, message queues, etc. Even if the pieces are now more integrated and easier to put together, the task of figuring out how the pieces will interact and what pieces you even need is still outrageously complicated.

This sounds like it was written by someone who hasn&#x27;t worked with ERP systems, to give an example of where software will never eat software. &quot;Can we make A work with B?&quot; -- a lot of businesses tie together Salesforce + 8 other systems, and that&#x27;s how their business ticks. And a whole cottage industry forms around it: consultancies, etc. I need to see a clear non hand-waving explanation for how all of that complexity melts away.<p>The industry has already tried commoditizing by off-shoring. What we learned was high-performance teams require psychological safety and trust. The human factors involved in creating software are why engineers are not plug-n-play. Because that reduction of the problem doesn&#x27;t describe how the software is actually made: product solicits customer interviews&#x2F;data to recommend new features, architects brainstorm a high-level solution, and the IC engineers implement the vision. Human factors, through and through.

The problem is that while it is economical to hire a team of developers to automate a simple process executed by a lot of people, there is a huge amount of complex processes executed by a small number of people in companies. And you are never going to be able to justify a team of 3 developers or more to automate and maintain the code of the job of just one guy.<p>Machine learning won&#x27;t be the answer either. Machine learning is just another kind of software, you still need to set it up and maintain it. And you need data to train it, which for these complex processes often there is none.<p>The solution really is for non developers to write code to automate their tasks themselves. Here simple code with simple platform to run that code is the only solution. But we are taking the opposite direction. Newer generations are becoming increasingly remote from how computers work (teenagers seem to be struggling even with a file system), platforms are increasingly becoming locked down (both consumer and corporate environment). And I dispute the claim that software is getting easier. I am mostly evolving in a .net environment, and I think the platform is becoming increasingly messy and complicated, we are moving away from simple things. Same with technologies, every time I go back into the azure portal website, I feel I am lost in the hundred of products with evasive names.<p>What we need is the power of the almost &quot;draggy and droppy&quot; features of VBA, something end users can play with. It is shocking how much office processes rely on such an antiquated and neglected technology.

I don&#x27;t buy the argument that we will have such a leap in software development productivity that we need way fewer people to solve all the things that need technical solutions. You can unravel abstractions we build on all the way to the bits and bytes and 90% of software is just gluing libraries together. Infact, you could probably describe the entirety of several of big tech cos as &quot;just&quot; gluing libraries together.<p>Anyway, the other argument about salaries is more interesting. Most people seem to agree that there&#x27;s a huge untapped crowd of qualified developers in small &#x2F; mid sized US cities who would love to join $BIGCO but the only reason they aren&#x27;t is because it involves relocation. As an example, a Sr Dev in Orlando, FL makes $100-120k in total comp while one in SF &#x2F; NYC makes $350k+. I limit my search to Sr Devs because I assume college kids are happy to move to exciting cities like NYC &#x2F; SF &#x2F; Seattle on fat relocation checks.<p>My suspicion is that supply and demand have converged already and big tech has mined out the supply of talented devs in the US already. The other datapoint here is that companies have made it as easy as possible for folks to move by opening dev centers wherever there&#x27;s talent - NYC as a tech hub wasn&#x27;t a thing in 2012, but it&#x27;s huge now for all the people who don&#x27;t want to leave the east coast. Boston is pretty big. Colorado, Austin as well.<p>The only way supply of devs is increasing here is if:<p>* Sr Devs who did not move to tech hubs because they preferred to stay where they are. (Personally think this is unlikely)<p>* Qualified Bootcamp graduates<p>* CS Enrollments hitting pretty high numbers, so maybe we&#x27;ll start graduating lots of CS folks.<p>* Immigration reform &#x2F; Outsourcing<p>* Interviewing change so we skip the algo problem solving shenanigans.<p>I personally think if big tech wants to hire in the US and still pay lower $ than they currently do, the only lever they have left to pull is the interviewing format &#x2F; bar.

The most salient part of this essay was the last section. Remote-first is forming in a way to break tech labor power. Employees will be less able to bond, and their personal conversations will be easier to spy upon. This will drastically inhibit collectivization. WFH may have some upside, but there’s a huge downside looming.<p>&gt; Remote-First, Collective-Last<p>&gt; Lastly, let’s talk about the impact of remote-first on labor. Many months, before the virus hit, a CEO friend of mine “jokingly” told me that he believed all the “remote” buzz was as much about reducing the collective power of the employees as it was about saving a dime on salaries. He personally did not want his company to go full-remote but was under some pressure from investors to consider it. We were both hammered at the time, and I didn’t put too much thought into it, but it feels right the more I think about it.

&quot;Say software one more goddamn time!&quot;<p>I don&#x27;t really agree with the point that because we&#x27;re creating things that allow us to use less or no code, there will be less code to write. We make things easier for ourselves so we can then build upon it and then write more complex things to solve more complex problems. It&#x27;s the continual layering of abstraction that&#x27;s been going on for decades.

I thought this piece was really interesting.<p>His thesis seems plausible, but I’m far from convinced. It seems equally plausible to me that as software gets easier to write, we just write more software. Industrialization of clothing meant the amount of labor required to create clothing dropped drastically. However more people are employed in clothing and fashion related industries than ever, because we now just own and wear more clothes than ever before.<p>Won’t we just write more software?

“No code” platforms aren’t going to replace software developers. I’ve tried out several of the major ones and came away with the conclusion they are this generation’s microsoft access. Someone who isn’t a programmer might be able to build something in them, but their IT department won’t want to support those solutions and they will definitely need support. I expect a cottage industry of no code consultants, who will be programmers under a different name.<p>I think something like airtable or microsoft lists is going to replace a lot more custom software. They are this generation’s microsoft excel.

When someone posts about the inevitable commodification of software development, the response on HN is usually one of denial. I&#x27;m wondering if some of these responses are starting to sound a little angry too - maybe we&#x27;re going through the five stages of grief as a community!<p>Lowering the bar to software development and opening up the employment market to a global one is going to have an undeniable impact. It certainly won&#x27;t take away from the fact that problem solvers are needed to create solutions and it also doesn&#x27;t mean that there won&#x27;t be a place for the highly skilled people with specialist technical skills. But it <i>will</i> change the landscape significantly.<p>Software engineers will loose a lot of the influence and power they have enjoyed over the last decade. In my view, this is an important and necessary step. The ability to build software that solves meaningful problems shouldn&#x27;t be concentrated in the hands of a few people (even a few hundred thousand) who have a narrow view of the kinds of problems software should be put to work to solving.<p>The article expresses concern that this displaced power <i>could</i> end up in the hands of big tech. I&#x27;m more of an optimist and believe that we could go in the other direction all together. The ability to create problem solving software can and will be democratized to a much broader degree than ever before and will lead to more meaningful problems being solved across the world. As a software engineer myself, that&#x27;s the future I want to help build towards.

&gt; We are coming to a point where software is developing so fast and the abstractions getting better that soon we will have more software written by a smaller number of people.<p>I think software is just a big pile of garbage. The thing is: our civilization depends on this pile of garbage. It&#x27;s remarkable that the whole thing somehow chugs along.<p>Over time, the pile will just keep getting bigger and bigger and more people will be needed to keep it from collapsing.

It&#x27;s a false dichotomy, that because software is getting easier to write, less people will be writing software.<p>Yes it&#x27;s true that software in the future will be easier to write, but we will <i>not</i> be solving the same problems as today.<p>In the past (20 years ago), developing a TODO app was relatively difficult and could of been a valid startup idea. However today it&#x27;s a trivial application to develop and is the equivalent of a &quot;hello world&quot; program.<p>The reality is; <i>Writing software gets easier, While the problems software solves get harder... </i>

Not sure if this is actually a serious (but misguided) take, or just the kind of thing you have to write when you need to blog something but don&#x27;t have a good idea this week?<p>Software is getting more complex, not less.<p>No-code, no matter how magically great, won&#x27;t change the fact that you have to somehow understand and codify your requirements and figure out how to achieve them through available building-blocks. (A no-code solution is just a tradeoff in building blocks -- the more one does for you, the less flexible it becomes. The lack of flexibility has a cost: the degree to which one doesn&#x27;t exactly fit your system, it pushes complexity elsewhere, blunting or even reversing the value.)<p>The longer-term effects of a remote-first world are a much more interesting topic, at least (though I think the author stiff completely whiffs. The ideas on why remote work will be bad for the employees are very weak.)

In my opinion, the author is a bit disconnected from the reality of software.<p>We&#x27;ve clearly learned a few things during the last five decades, our abstractions are better today but progress has been mostly slow, painful, and linear.<p>A lot of the gains we&#x27;re seeing are built on top of the tremendous progress made by the hardware guys, we&#x27;ve been free-riding for a long time.<p>I think that a few bullshit jobs might be exposed&#x2F;compromised by the transition to remote work, and that includes managers, but not people doing creative work.

I&#x27;m not buying it. Just as MS Office didn&#x27;t reduce admin work, but instead created whole new categories of busywork for executives to do, so new software frameworks are mostly just increasing the complexity of the overengineered solutions we create to address what are really just simple CRUD interface problems in the majority of cases. If only classic ASP in VBScript was still being security patched, I guarantee you the majority of web apps could be written in that to be so much faster and more responsive than any of these &quot;modern javascript&quot; front ends that have to make 78 different API calls across a fleet of microservices just to show part of a database table on a page... after the user has sat looking at some dumb spinning beach ball for 5-8 seconds. Naturally, you could maintain that shit with only one or two developers instead of the rooms full of fullstack devops rockstars that it takes to build even the most basic thing these days. Without a kubernetes cluster in sight. But as long as our entire industry continues to throw away basic architectural and performance principles in favour of embracing the new hotness, your jobs are safe. Enjoy the busywork, folks, and let&#x27;s continue creating additional layers of abstraction and indirection to ensure the next generation requires even more armies of developers just to say &quot;Hello, world.&quot;

1. We have no-code already. It is called WordPress and its hundreds of thousands of plugins. Is WordPress eating everything? Nope. Is it destroying web development? Nope.<p>2. This entire post does not align with the existence of SAP, IBM, and Oracle. Vast, vast, vast, amounts of code are highly customized for a specific domain. These companies would already have lapped up these synergies to boost their own profits. I really want to know how no-code solves the processing of custom contract objects.

This is no different from saying that economic progress, in general, will eat itself until hardly anyone is employed. Which people worried about, for example, in the early 1900&#x27;s as farm employment fell dramatically due to efficiency.<p>Spoiler alert: it didn&#x27;t happen.<p>What people always seem to miss is that as things become more commodified and more efficient, we <i>move onto solving harder problems</i> that aren&#x27;t commodified or efficient.<p>As programming CRUD applications or managing databases becomes quicker, we start working on better product ideas, cleverer scalable architectures, and whole new product categories.<p>Innovation never eats itself. This is a myth that people seem to fall for decade after decade. (Unless we somehow reach the &quot;singularity&quot;, but that&#x27;s purely in the realm of science fiction for now, and certainly not worth worrying about until we solve AGI.)

Software automation has been going on for a long time - there&#x27;s no denying that. I don&#x27;t see what that has to do with remote work though. Seems like the author just stuck in the remote work buzzword to get some more clicks despite that being a completely separate topic.<p>&gt; a CEO friend of mine “jokingly” told me that he believed all the “remote” buzz was as much about reducing the collective power of the employees as it was about saving a dime on salaries.<p>I&#x27;ve spent the entirety of the ~6 years of my software engineering career wondering why a profession where you&#x27;re in front of a computer screen all day was so hostile to remote work. At every job I&#x27;d try to persuade managers to be more open to flexible hours and wfh, ultimately realizing it was impossible to change corporate office culture and giving up to exclusively work remote roles at remote-friendly companies.<p>So after years of fighting this fight for increased acceptability of remote work, it&#x27;s hilarious to hear some CEO telling people that remote work is a ruse intended to decrease our labor power. That&#x27;s like hearing a CEO say &quot;we&#x27;ve decided to increase the salaries of our engineers above market-rate in order to put them in &quot;golden handcuffs&quot; so they won&#x27;t leave&#x27;. Sure a conspiracy theorist can always theorize about some possible hidden motive, but I&#x27;ll take the raise, thanks.<p>Remote work might be damaging to the mediocre SF engineer who&#x27;s inflated salary until now has been protected by companies&#x27;&#x2F;investors&#x27; insistence on engineers being in SF, but it&#x27;s a boon to everyone else who never wanted to be tied down to SF and living in some office campus.

&gt; We are coming to a point where software is developing so fast and the abstractions getting better that soon we will have more software written by a smaller number of people<p>Maybe i m in the wrong planet, because all the software i see in the past ~10 years is an overcomplicated unmaintainable slow mess that needs more and more people to keep it from imploding.

I think it&#x27;s absolutely true that remote means less solidarity and connection between workers. Also hiring international remote workers are usually done on consulting basis, which less regulatory protections. I certainly see a world where software engineers become more fungible, and with the reduced messiness of human interactions, managers will be ruthless.<p>There are also some interesting arbitrage opportunities. For example, American companies would want to hire from countries with socialized medicine so that they don&#x27;t pay for health benefits.<p>It could be more efficient, and it could lead to reduced poverty in some places in the world, but on net I don&#x27;t think it&#x27;s a desirable.<p>Ironically, the people who champion remote work the most do it from the perspective of the benefit to the worker. But as this essay suggests, and I agree, if you play it out, it will work out to the benefits of the companies and executives.<p>To be clear I&#x27;m not against remote, and could see the benefit to everyone, but it&#x27;s naive not to play it through and think of the second-order effects of a fully remote industry.

Software started as flipping switches, then moved on to tape and punchcards and then to keyboards and the ability to write in words instead of bare machine logic. Soon we were in the print phase where &quot;print&quot; meant putting physical words on physical paper and sometime later you were able to actually view your program on a screen without needing to reprint it. A generation later we get code generation from a WSDL and squiggly lines under typos. A generation later we get AI that tries to predict if I&#x27;m more likely to buy the Smooshtek or Prodex version of the exact same item on Amazon but can&#x27;t come close to solving unknown business problems independently.<p>I guess that what I&#x27;m trying to say is that the first and last job of software is to eat its self. That&#x27;s the environment and if you want to make it making software you have to learn how to use the new impossible thing that software can do and not take it as the brand new end of the world.

Last few companies I&#x27;ve worked for were using what would be considered the latest trends in software development: SPAs, React, Redux, BFFs, monorepos, kubernetes... I can tell you, we&#x27;re not reducing the need for developers at all... if anything we&#x27;re building things so complex and overcomplicated that will require generations, and generations of developers to maintain an understand. So we&#x27;re pretty safe for the time being...<p>Yes, then you have things that would really cut down the number of people working on the field, such as Heroku, App Engine, Firebase... but this is such a small factor due to the few companies using it that compared to the messes we&#x27;re creating in other places I don&#x27;t see it causing any collapse of the job market.

Considering the struggle of companies to find qualified people to work for them, even when offering good salaries, it&#x27;s to me a huge exaggeration to say that going remote will represent a disadvantage for software engineers. I&#x27;ve been a software engineer for 10 years now. If you see the struggle we have sometimes with dumb topics like timezone issues or ridiculous security issues everywhere, you&#x27;ll understand that software is really far away from eating software.<p>Also saying that it&#x27;s easier for the company to get rid of people may somehow be true, but it&#x27;s easier for people to pivot and find better opportunities as well. To me it will increase job rotation, which in my particular experience has helped me A LOT to improve my skills. This will help improve job conditions as well, companies in search for more stability will have to be even more creative to keep smart people around. They don&#x27;t seem to have understood this yet unfortunately, good job conditions is not having a ping pong table and a bloody PS4 to play with.

It’s not the software engineers that will be automated out of a job, it’s everyone else. We will need to deal with the fact that jobs which require very little creativity and ad-hoc problem solving will largely be automated away much sooner than software will be writing itself.

I think the author is a little out of touch with reality. In reality, state government unemployment websites that are really simple CRUD apps collapse from a few thousand daily users. Lots of simple office work can’t happen remotely because people are still using paper files. There is plenty disruption to be had in the world that can be solved by software.

&gt; ... wrote a persuasive piece on how companies should people based on what value they add, not pay them differently based on where they want to live.<p>I learned the concept of &quot;golden handcuff&quot; the hard way. We paid a remote worker a fraction of the salary they&#x27;d make at a major European city. But that salary was still a multiple of what they&#x27;d make at a local job.<p>This turned into a golden handcuff, as the employee started to lose interest in the job, yet would try hard to convince themselves that they&#x27;re still interested. That was likely because any other job for them would mean a 66% pay cut at the least, and a significant downgrade in their standard of living (unless they&#x27;d find another employer as inexperienced as me).<p>Lesson learned: Negotiate close to market rate, and let the fulfillment of the job be the talent&#x27;s biggest motivator.

&gt; software is developing so fast and the abstractions getting better<p>Software won&#x27;t eat software because this isn&#x27;t true, yet.<p>IMO, the last 10 years have been an explosion of new frameworks and patterns that are overly-complicated and bloated. Because of this, there isn&#x27;t an easy cohesion between off-the-shelf solutions.<p>Think of how eye-opening UNIX was when it first came on the seen and the ability to pipe together commands to solve new problems. It was eye-opening. But, think of how hard that would have been if each tool read ASCII different, or piped text differently. Imagine if grep and awk where combined into one tool with a complicated set of switches.<p>I think eventually, working with off-the-shelf software to build solutions to tough problems will be as easy as gluing together 3-5 UNIX commands in a bash script to process some text files. But we aren&#x27;t there yet.

Is the success of the no-code trend really a given?<p>Insofar as I can tell no-code addresses configuration management of known entities. It’s not a dsl and it’s not a visual programming environment - it’s, generally speaking, a graphical layer on top of one or more yaml &#x2F; xml &#x2F; whatever-file(s) with a finite set of options.<p>That’s good enough in many, many cases. But it’s not a panacea. And it’s certainly not “no-code means no coders.”

I would argue this can never be true. If software gets to a point where today&#x27;s problems can be solved by a 5-minute specification, engineers will be able to do more high-level engineering, connecting dots with those building blocks.<p>One example is memory management: At some point, we started having languages and powerful-enough hardware that engineers didn&#x27;t have to worry about memory anymore (for certain classes of applications), so they could spend more time thinking of other things. It&#x27;s not like switching from C to Java would cause a software company to get rid of 40% of its devs because there&#x27;s now less work - it&#x27;s just that one hindrance is gone. But there&#x27;s always plenty to do; the backlog never gets emtpy.

Counterpoint: If this was going to happen it would have already.<p>Here&#x27;s RMS talking about secretaries extending Emacs with Lisp:<p>&gt; programming new editing commands was so convenient that even the secretaries in his [Bernie Greenberg] office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn&#x27;t say it was a programming. So the secretaries, who believed they couldn&#x27;t do programming, weren&#x27;t scared off. They read the manual, discovered they could do useful things and they learned to program.<p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;gnu&#x2F;rms-lisp.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;gnu&#x2F;rms-lisp.html</a>

I&#x27;ve been hearing this same thing since the 80&#x27;s when my friend&#x27;s dad questioned why I would want to become a programmer when eventually computers would be able to program themselves.<p>The complexity just keeps ratcheting up.

“Anyone who’s spent a few months at a sizable tech company can tell you that a lot of software seems to exist primarily because companies have hired people to write and maintain them. In some ways, the software serves not the business, but the people who have written it, and then those who need to maintain it. This is stupid, but also very, very true.“<p>This is exactly what happened to higher education. It seems to be a kind of entropy that signals that a system is in major need of complete overhaul so it can get back to doing what it was actually designed to do.

&gt; we will have more software written by a smaller number of people<p>This was the past IMO. Future will have larger number of people writing even more software.<p>I wonder if the author has met people working in non-software industries, but most software is still unwritten. What we have nowis most amount of software for software developers.

No-code is nice, there is only one problem though. Computers are not getting faster. Sure they can handle more parallel loads with more cores, and in the cloud you can scale horizontally, but building parallel systems is hard, and the higher up in the abstraction chain the harder it becomes. So the software might be built by some drag n drop tool, and it will look nice, but performance will be terrible, uptime will be terrible, and there will be weird issues once the software get many users.

Mo software, mo problems. Either coders will become the people managing all the different &quot;no-code&quot; solutions or companies will pay dearly for when, inevitably, their no-code solution meets a limit that was never considered. The problem with all the no-code solutions though is that it becomes mind-bogglingly difficult to remember how to navigate the graphical interfaces of each platform while the coder can focus on and enjoy the superior ergonomics of mere text editing.

There is no way that software will soon reduce the need to engineers.<p>One way to look at it is AWS for example. It removed the need for hardware and sysadmin skills. But the cost of this is that now instead of sysadmins you need devops and probably in bigger numbers.<p>The way I see it software crates problems at a higher rate than it solves them, hence the need to constantly change and evolve technologies,so that at least of the technical debt created can be written off.

I feel that every no-code tool that gets sophisticated enough to replace manual human coding work will have a significant learning curve. So much so that we will need trained professionals to operate these sophisticated no-code tools.<p>Yes, people will be more productive using no-code tools over manual coding&#x2F;deployment, but we will still need these skilled no-code professionals to use these things and ship faster.

My problem with &quot;everyone remote&quot; is the following scenario.<p>Suppose I&#x27;m sitting at my desk, and I need Bob&#x27;s approval to check in some piece of code. In the current (office) scenario, I send Bob the request. If I see him lounging back in his chair, playing some game on his phone, I can walk over to him and gently prod him to approve my request. He can&#x27;t deny his game-playing, so he has no option but to act right away.<p>In the remote world, I have no idea what&#x27;s keeping Bob busy and why he&#x27;s not approving my request. He <i>could</i> be playing games or out for a walk with his dog... or he could be fighting a (metaphorical) fire.<p>What we need is some sort of a &quot;presence&quot; signal. Unfortunately, we can&#x27;t have one without some privacy issues.

Software doesn&#x27;t actually get easier to write. Yes, you have more building blocks to choose from and sometimes (very rarely) improvements in abstractions. But this also means that your software sits atop an ever larger mountain of code that you do not understand. This means that it is easy to do things half way, but it still isn&#x27;t any easier to do things well.<p>Much software also has to model the world around us. Which doesn&#x27;t really get any simpler as we try to solve more problems in systems that need software. Like self driving cars, or even something as everyday as your mobile phone.<p>The piece was too long.

I have exposure to software in medical devices such as an MRI machine. As far as I can tell, in these expensive devices atleast, the predictions of this article &#x27;Software will eat Software&#x27; do not apply unless you are talking complete stagnation of new machine development. Apart from this it requires programmers to understand MR physics to even begin making any sort of real development - takes a minimum of 3 years to come to speed after an advanced degree IMHO.

&gt;In my first job at a small start-up, we had tons of physical servers. Now, it’s hard to imagine any &quot;webby” tech company ever interacting with any hardware at all.<p>My record on predicting tech trends is <i>terrible</i>, but wasn&#x27;t the outcome of that switch to cloud computing a massive <i>increase</i> in the demand for software developers? For now, at least, it seems that things that reduce the amount of work developers need to do actually increases their value.

I suspect that more people will be writing software as part of their job. They just won&#x27;t call themselves developers. As the underlying software becomes more powerful (I&#x27;m thinking of Microsoft&#x27;s recent demo of AI writing software) you need to be less skilled to build something we consider a complex app in the current time, relatively easily. Many professional developers will find them selves migrating to solving harder more advanced problems.

There is a simple truth about the modern world that many don&#x27;t seem to grasp:<p>Automation --&gt; Wealth --&gt; Opportunities --&gt; Automation...<p>The job of the software engineer is to automate their own job. Most people stop their reasoning there and don&#x27;t continue thinking about the downstream effects of that action.<p>The wealth generated from automation creates new opportunities that will be filled by the software engineer themselves because automation never ends. Software is never done.

&gt;<i>Put another way, the technology industry will soon get a taste of what has been going on in other industries.</i><p>Well, we can always &quot;learn to code&quot;... oh, wait...

A lot of speculating, nothing of value.<p>Software is a <i>tool</i> to get things done.<p>The only way software eats software, is by having intelligent people wanting better tools and abstractions to get shit done.<p>Building better tools and abstractions is hard work. For people to be motivated to do hard work, there need to be goals worth sacrificing for and a support system in place, to help and motivate the hard workers to keep going. Society has to <i>want</i> change and treat those on the front lines as <i>champions</i> for their cause.<p>That&#x27;s how real progress gets made, and not only in software, but in all areas of life.<p>Americans seem to have forgotten or maybe never knew, that this is how things work. This tendency to dumb everything down to never offending anyone and not letting anyone even have a chance to make a wrong move, has made everyone into a bit of a complacent dumb-ass, writing blog posts like these that say absolutely nothing.<p>If you want a bit of a shocking example of how deep this goes - you can&#x27;t customize, group, rank, save, or do <i>anything</i> on the number one photo-sharing app in the world. You can only mindlessly scroll, like, comment and share.<p>I mean, we&#x27;ve reduced an entire creative medium to a single algorithm of behaviour, optimized for maximum time spent zombie-scrolling.<p>When people wake up to what zombified lives they&#x27;ve been living and that it hasn&#x27;t been an accident but happened by design - it will not be software eating software, it will be software users eating software companies and then some for what they&#x27;ve done to humanity in the name of quarterly profits.

This is like saying building an abstraction of assembly language like C will put all the software developers out of a job. Rather it creates more opportunities.

As someone who has spent the last month fighting ansible and puppet: automation in software does not mean less work.<p>IMO: there’s an inverse relationship between maintainability and ease of use. Config files are extremely easy for <i>large groups</i> of people to maintain but it sucks making changes to them. As an individual I’ve found it’s often easier to rewrite the application myself to do what I need than to edit complex config files.

&gt; We are coming to a point where software is developing so fast and the abstractions getting better that soon we will have more software written by a smaller number of people.<p>This seems unlikely to me, or at least unsupported by current observations. Software tooling and abstractions have improved tremendously since the early days of programming. Going from machine code on punch cards to modern high-level languages with assorted libraries and frameworks and debuggers represents at least a few orders of magnitude productivity increase per programmer.<p>But has that incredible efficiency gain resulted in fewer programmer jobs? Nope, just the opposite: the better the tooling is, the more useful each programmer is, so the more it makes sense to hire. This makes sense when you consider how open-ended programming is as a field: it lets you manipulate data, and it turns out manipulating data has a seemingly endless number of uses. It&#x27;s not a field like, say, plumbing, where you need a set amount of plumbers, where going beyond that number doesn&#x27;t really accomplish anything.

I don&#x27;t see much evidence for the argument that software will destroy software development jobs. It&#x27;s true, we have automated a lot of tasks and develop at a higher level now than we did in the past, but there are also more people working in software now than in the past.<p>You can do impressive stuff with a small team or even alone now, but the past also had small teams doing impressive stuff. Look at how Apple was founded by two guys, how many startups started with a small team. In the 1980s, many very successful games were written by one or two people. We make more sophisticated games and systems now because we build on the abstractions created then.<p>The demand for more sophisticated software will continue to grow, and we&#x27;re not remotely near the point where every problem will have been solved. The focus of software development will very likely shift, as it has always done. But software engineers will continue to be needed as long as software is needed.

Until we solve all &quot;problems&quot;, we need software. At least in some of the solutions, part of the solution will require software. The whole no-code thing is BS in my opinion, because it is just another layer of abstraction. Maybe we make &quot;making software&quot; easier and more people can do it, but solving a problem will not go away.

Low code&#x2F;no code trumpet again. I work with it(Salesforce) and while it can do pretty cool things,as soon as something more complex comes up, I have to write good old code. I understand these things are improving a lot but it will take decades to get to the point where it&#x27;s wiping thousands of devs out of job market.

I have no evidence to back this up, but as a counter-point, I think that the construction of new things is always a platform upon which more new things can be made, which require people. If we reach some precipice where much more can be built with much less, the. I think that not only will the diversity (breadth) of software will increase, but also the complexity and power (depth). All of that still requires workers. As software becomes commoditized, it’s ubiquity and availability should provide a new base level on which to build. The only scenarios I can see where we lose opportunity for common growth is if we build machines that are better at innovating and making things for humans than we are or if the power of the tools we build all ends up concentrated into a few powerful hands. The later is why I believe FOSS is so important.

The microservices make it easy to create a big ball of software that covers as much featurespace or ground as possible. That&#x27;s not the end of software development. You need a lot of people to gut these microservices and reconfigure them to be part of your monolith and to wire in new workflows.<p>As soon as precision and performance become critical, you&#x27;re back to dredging through the code because microservice were built on assumptions that your ball of software executes poorly.<p>This move for collective action attempts makes the independent wfh type irrelevant and then suck them back into the fold via &#x27;collective bargaining&#x27; and other union tricks. I fail to see how this will play out any differently to historical unions. Blaming the current president is s basic move for bringing about your utopian collective.

SWE&#x27;s have been the ones pushing for remote work for years, now here come dozens of blog posts claiming that it&#x27;s our undoing. Ok sure. Trading some TC for lower housing costs, lower COL, less traffic, and a better quality of life outside of Silicon Valley seems like a decent trade.

As the author of a no code tool I disagree with this article. I think that we will need even more developers to manage the apps churned out by no code tools. Tools may go up the abstraction later, but developers will always need to debug ALL layers of the abstraction layer

Salaries will go down not because of less collective action (there was not any really to speak of with high salary people) but because now the (remote) applicant pool has many people living in relatively low-cost areas, many even in countries&#x2F;localities where the cost of living my be 70 or 80% less than the big US cities.<p>In such a situation, it is very easy to question the idea of hiring _anyone_ who lives in a big city and therefore requires a large salary.<p>As far as software eating software, it seems obvious to me that it is occurring, but may not be obvious to everyone because as that has been happening, we have also seen a rapid increase in software use in business and industry. And we have seen software projects become more mainstream, where in some places, almost every random person seems to think they need to build their own mobile app or web-based service, for example.<p>I think we are not yet close to the end of the level of automation of software development. Here is one thing that may be on the horizon: chat, voice, and UI-mockup - enabled software development bots that take advantage of large knowledge-bases of application templates and components, and use deep learning to smartly combine and configure them according to natural language instructions and intuitive UI interactions. This could also involve generating design assets with AI based on combining large libraries of starting points and styles.<p>I also personally believe that more advanced AI for programming is going to sneak up on everyone, including programmers, faster than most expect. Especially when you think of tackling specific types of software at a time. What the deep learning people are working on is making neural networks learn better-factored and more accurate models of the world. I believe this is probably feasible to do using mostly existing algorithms, by building up models (and networks) gradually with a progressive curriculum approach. Using that type of capability and very large datasets of specifications, design interactions, sample assets, templates, and final configurations, it will be possible to train AI to build many different types of software.

I agree with the author that software eats software. It took a sophisticated, expensive team just to launch an ecommerce line a couple decades ago, now you need no engineers at all. This trend will continue.<p>I disagree that this will result in net decrease for engineer demand in the foreseeable future. There appears to be no evidence for this at this time. Investor demand for new software products is currently endless.<p>I agree that a trend towards remote work could be a downward pressure on engineer salaries and power, particularly for silicon valley workers. On the other hand, it could instead be an upward pressure for all us engineers outside of silicon valley. It could be both, or maybe the remote trend will fizzle out in a year. Time will tell.

My take :<p>At some point in the mid-to-distant future, most human labor (certainly white collar labor) will potentially be automated away, with remaining blue collar labor not far behind (the physical interface, e.g. general purpose robots that are superior to humans in non-static environments will probably come last).<p>Until that point, the demand for a technically literate workforce will continue to grow, simply because the number of potential areas of application will also continue to grow. With every new digital encroachment on our analogue lives, we find new business verticals that previously simply didn&#x27;t exist. I don&#x27;t see that trend abetting anytime soon. Put differently, it&#x27;s not like software development ends with webapps. For every domain that gets commoditized, there will almost guaranteed be new ones in need of hands on skilled labor. There will of course be some developers who aren&#x27;t as effectively able to reposition themselves for new verticals (we&#x27;ve all probably heard some anecdote of a C programmer who simply couldn&#x27;t grok OOP, etc.), but by and large it&#x27;s difficult for me to see the demand for human-generated bespoke software development dissipating until we get close to that mythical land of general AI.<p>Now, on the payscale side I do agree with the author that the push towards remote work will definitely have an impact on many of our salaries that are currently tightly bound to geography. That seems fairly evident, to be honest. I live in northern Europe where our salaries are quite good relative to other parts of the continent, but you can still find high quality engineers for &lt;$100k USD - many of whom are on par with FAANG developers being paid &gt;$200k in SFBA or Seattle and the like. The further east &#x2F; south you go, the lower the current salaries are. It seems logical that decentralization of work will lead to a flattening of the income curve - raising some incomes, lowering others - as we increasingly all enter the same digital playing field. That said, wages - like housing prices - are to use econ parlance &#x27;sticky downwards&#x27; so if I were still a SV developer I wouldn&#x27;t start losing sleep yet.

Most of the comments so far are about his take on there potentially being less need for people to write software in the future. The more interesting part of the article IMO is the bit about salaries:<p>&gt; Most people would like to believe salaries are determined by a cost-plus model, where you get a tiny bit less than the value you add to the company. However, in reality, they are really determined by the competition. Companies are forced to pay as much as possible to keep the talent for leaving. In a competitive labor market, this is often a good thing for the employees.<p>He goes on to concisely explain why people get paid so much for working in the Bay Area, and why they won’t get paid like that elsewhere.<p>I think this is a keen insight, and should be sobering to the large cohort of HN that is clamoring for all the tech giants to go full remote.<p>As we saw already this week, when Facebook decides they don’t actually need you to live near Menlo Park anymore, that also means they don’t need to pay you Menlo Park wages any longer.<p>I think there’s actually a significant risk to Silicon Valley here, which is the following potential vicious cycle:<p>- Big Tech decides all&#x2F;mostly remote is the future.<p>- Big Tech mostly stops hiring in the Bay Area because why pay more for talent when they no longer “have to.”<p>- The COVID reset layoffs continue, resulting in a lot of Bay Area engineers looking for work at the same time.<p>- Supply and demand mean that engineers wages start dropping as smaller companies no longer have to compete with the giants (as a hiring manager in SF I’ve already seen this start happening).<p>- Engineers who can no longer command crazy salaries to justify the rent start leaving the area (this is also already happening).<p>- Rents start to drop, and the housing market softens a little.<p>- Tech workers who have relatively recently bought homes get nervous and look to exit before they get underwater on million+ dollar loans.<p>- The housing market softens further...<p>At this point most of these things sound like a much needed reprieve for the insane local housing market, but the funny thing about bubbles is the way they get hotter and hotter for a long time, and then tend to pop relatively quickly. Sometimes these things can lead to vicious cycles that take quite a while to come back from, where a bear market feeds on itself.<p>I love working in software. I loved it before I moved to the Bay Area and quadrupled my earnings. I’ll love it even if it all comes back down to earth and is just a “normal job” again.<p>But I think that could really happen, and I think Big Tech embracing remote is a great way to pop the balloon in the Bay Area with the result not being a utopia where people get to make Bay Area wages and then live on the beach in Cancun, but rather they get to make Omaha wages and live in... Omaha.<p>I haven’t really seen this community wake up to that possibility yet, which is surprising to me considering it’s a fairly obvious conclusion to the top paying companies all opening up the floodgates of worker supply by truly embracing remote work.

I agree with the writer. Microservices have already made it possible to commoditize many of the services that we used to re-implement over and over again in the past. We can now buy them as cloud services. But that is just the beginning. Our development work is still mostly non-business-logic effort and smart companies will figure out new ways to eliminate more and more of it.<p>The important point is that non-business-logic development work is never eliminated completely. But if you eliminate 50% of work, you need only half of the previous human effort. Then the other half needs something else to do. Preferably enjoy the increased productivity by gaining increased free-time.

I wonder if instead of completely eliminating software developers&#x2F;engineers to write the code, what if we had specification writing engineers. Just like tests, the specifications would describe what is needed, and then we&#x27;d let the machine figure out a way to make things work given all constraints. Very much like machine learning I guess. Of course, those specs&#x2F;tests would need to be covering almost every possible scenario, but then when you write code you write the code and rhe tests, so in this case you&#x27;d only write the tests, but the code would be figured out by the machine. Does this all make any sense?

Slack is a direct successor of IRC. Those who are familiar with the IRC are quickly getting used to. But if used by people without IRC experience, the result usually suffer as they don&#x27;t understand the IRC culture and can&#x27;t use it efficiently. I&#x27;ve heard a company failed so bad at using slack. Only the sysadmins has the privilege of creating the public channels, resulting just a handful of generic use channels and most channels are flooded with noise. To reduce the noise, they ban the non-essential post to the Slack, just nullifying the Slack as a communication tool.

&gt; Companies are forced to pay as much as possible to keep the talent for leaving. In a competitive labor market, this is often a good thing for the employees.<p>In practice they conspire to rip off the talent: &quot;Apple and Google&#x27;s wage-fixing cartel involved dozens more companies, over one million employees&quot;<p><a href="https:&#x2F;&#x2F;pando.com&#x2F;2014&#x2F;03&#x2F;22&#x2F;revealed-apple-and-googles-wage-fixing-cartel-involved-dozens-more-companies-over-one-million-employees&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pando.com&#x2F;2014&#x2F;03&#x2F;22&#x2F;revealed-apple-and-googles-wage...</a>

Feels as though this essay was written by Ned Ludd himself. Software has been constantly commodified and yet the hurdle the market expects you to clear gets higher at the same time.

Scary and true IMO. The difference is clear in the head counts &amp; philosophies of newer companies vs. old ones. To do anything in software, you had to be a software-first company. Now that part is easier, we see many more software-enabled companies instead - the business is front and center, only a few programmers needed, and they have a lot of software plumbing kind of work, not much software building.

If you could write a thing that actually did replace yourself as a programmer, would you?<p>Do we protect and perpetuate the priesthood or bring the fire down the mountain?

I feel like I&#x27;ve been worrying about this for now than a decade and it still isn&#x27;t true, and it&#x27;s not going to be true in a decade.

Just a reminder: Remote isn&#x27;t as special as it seems.<p>Teams where always working remote in respect to other teams.<p>The only thing that changed is what teams do internally.

I had written about my predictions about technology trends which are going to make a maximum impact in 2021 out of which no-code will have a definite impact<p><a href="https:&#x2F;&#x2F;jay.kanakiya.in&#x2F;blog&#x2F;what-i-am-excited-about-in-2020-and-2021&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jay.kanakiya.in&#x2F;blog&#x2F;what-i-am-excited-about-in-2020...</a>

I just don’t get it why more developers working remote would impact the amount of code needed to be written for their business.

People who think software will get simpler due to software should look at genetics. Complexity is infinite.

If you&#x27;re a developer, realize that this happening is going to make you filthy rich if you know how to play it correctly.<p>This is going to take a <i>boatload</i> of competition out of the industry and means that truly competent, experienced software developers will become rare.<p>The faster this happens, the better.

I&#x27;d argue that as abstractions and automation improves, it will bring in more complex demands to be met and therefore it will increase demand of programmers&#x2F;engineers. And the cycle continues.<p>Software will continue to eat the world until it creates an authoritarian utopia for humans.

“No-code” is great, and I love some products in the category (Airtable). But the idea that it is going to fundamentally transform anything is hyperbole, similar to soylent’s marketing when they were saying that nobody was going to eat food again.

Software development is a bit like fashion or music. There is no direction like forward or backwards. Good and bad are often just personal opinions. Some things get out of fasion, just to be discovered years later. Others are are stables.

Asana with its inbox workflow will help all remote companies. Didn’t believe it at first but after using it for onboarding all remote like how it enables a sync work. Disclaimer I am a recent Asana hire that I boarded remotely.

This seems hugely overblown verging on nonsense to me. Since when is it easier for your employer to surveil you outside their office than within it? There are more and better encrypted messaging tools than ever before. No-code tools are a long way off from being able to replace most software. We’ve been hearing this about the technology for at least 30 years at this point, and <i>now</i> it makes “most” software development irrelevant? In a lot of ways software engineering is better than it’s ever been, but there are huge swathes that don’t follow the “best practices” that newsboard technologists are known for promoting (myself included) and their software is going to need work forever.

Software development, imho, is mostly complexity management. If you believe that too, and believe the premise of this article, can you describe how those two fit together in your mind?

In progress. Support my project. <a href="https:&#x2F;&#x2F;github.com&#x2F;imvetri&#x2F;ui-editor" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;imvetri&#x2F;ui-editor</a>.

There&#x27;s lots of different points in the article, most of them tangential at best to &#x27;remote first&#x27;.<p>The remarkable thing about &#x27;software eating itself&#x27; is that it is true, in the sense that the <i>potential</i> of what a small team of good people can accomplish has gone up by orders of magnitude over the decades. We stand on the shoulders of gian( code base)s, but ... at the same time the dysfunctionality seems to have increased, and not just in corporations, but also in smaller outfits. Just as efficiency paradox observed in the infamous &#x27;Bulshitt jobs&#x27; article, it is as if there are these ubiquitous hordes of &#x27;overhead&#x27; cadre hiding in the wings relentlessly trying to bootstrap themselves at the slightest opportunity.<p>I&#x27;ll give an anecdote, but it is fairly typical for many situations I encounter. This job was putting a daily webpage dashboard on some existing data and and integrating an existing service that delivers new data-points. There were very few uncertainties, It was scoped as a one week effort for a team of two self-managed senior engineers, with a second week of polish and iteration. This is not what happened. First a manager was appointed for the project, who&#x27;s first &#x27;hire&#x27; was another line manager to keep track of meetings and progress. He hired a business analyst to write a spec, soon joined by two other analysts to read the spec and write more spec. Then a &#x27;data scientist&#x27; consultant was brought on, who (rightly) ignored most of the gibberish in the analysis document but managed to instate a full enterprise cloud BI stack (hey, we&#x27;re dealing with data and need to draw a chart), and instead of just reading the data from the nightly reports decides to integrate directly with the data-warehouse, now upping the need for enterprise security etc. etc. 2 months into the project this is still going and the end result will still just be a chart on a webpage.<p>Second anecdote. This one in reverse, but putting light on the same principle. This concerns a large organization that for years was pondering to go digital with its mailing system (this org deals with thousands of pieces of physical mail coming in and thousands of paper pieces going out every day, often requiring multiple official approvals and signatures etc.). Thos was seen as a complex and large project, taking a year probably running into the multiple millions of euro). COVID-19 hits, and the organization is forced to go fully remote. A pragmatic team of 3,5 FTE is called in to &#x27;just make this work ASAP&#x27;, as the mail-flow is vital to the org. They finish the job in 3 (hectic) days. The solution has now been running for months.<p>So there is this &#x27;paradox of efficiency&#x27; in software as well. Software eats itself, but as it does it has the tendency to become morbidly obese (to stay within the metaphor).

Anyone who brings up and doesn&#x27;t take a moment to laud the success in dismantling dragonfly earns a black mark in my book.

Website generators have been around since the 90s, but in 2020, people still work have full time jobs writing websites by hand.

A lot of people in the discussion disagree with the article&#x27;s first point about no-code&#x2F;less-code. While I do think the argument is a little fatalistic, the scoffing at the idea in the face of him bringing up evidence such as AWS and other IaaS&#x2F;PaaS reducing the number of in-house server engineers that companies need, and how the proliferation of open-source libraries&#x2F;frameworks has made creating software easier than ever, reminds me of economists pooh-poohing the notion that modern forms of automation will lead to unprecedented levels of job loss just because previous waves of automation didn&#x27;t. Even in the face of self-driving cars and automated receptionist&#x2F;call support agents that James Watt couldn&#x27;t even dream of.<p>But whether no-code&#x2F;less-code is inevitable, I think his first argument can still be substantiated from a different approach, at least in the near future: we&#x27;re coming at the end of a tech bubble, the money will start receding, and organizations have already been realizing they don&#x27;t need so many coders (and other staff) after all. Did Uber really need to build their own in-house version of Slack? Did Airbnb really need to pour so many resources towards adopting, even contributing heavily, to React Native, only to do an about-face and have to rewrite their mobile apps in their native platform? Did either company, like so many gig&#x2F;sharing companies during this bubble, have to invest so much in hyper-growth and expanding to so many markets before they were ready? Did so many of these companies have to fall prey to Not Invented Here syndrome and waste so much time in engineering boondoggles?<p>To some extent, yes, it&#x27;s what&#x27;s the investors wanted, or what corporate leadership thought would make the investors happy. And so this boom has led to massive hiring on a lot of busywork that doesn&#x27;t actually have tangible economic benefit to these organizations, and may have even led to worse outcomes due to unsustainable or reckless behavior.<p>Going back to the article, whether the first point can be explained by inevitable no-code&#x2F;low-code eating the world, or by the fact that a lot of software generated were due to the frenzy of a bubble, it still leads to the same point:<p>&gt; <i>Anyone who’s spent a few months at a sizable tech company can tell you that a lot of software seems to exist primarily because companies have hired people to write and maintain them. In some ways, the software serves not the business, but the people who have written it, and then those who need to maintain it. This is stupid, but also very, very true.</i><p>And the article&#x27;s subsequent conclusion about how widespread WFH will lead to cold calculated culling of a lot of unnecessary or redundant personnel, aided by the the emotional detachment of not having to see the faces of the people to be let go, still follows.

You are what you code

i work only with software that eats others software.

Kolmogorov complexity means programs cannot generate more information than they are provided with. However, I do think it possible someone will invent a much more efficient coding workflow that can create an assembly line sort of system. E.g. a very experienced dev can decompose a problem into a lot of subtasks and interfaces to outsource and complete in parallel. Once completed, boilerplate software automates the integration of completed tasks.

LOL. Nothing I’ve seen so far about Artificial Intelligence is intelligent at all.<p>And anyone that tells you that A.I. is intelligent, might as well be selling you some snake oil.

To get started in software development, people no longer need to learn about memory management, concurrency, networking, how numbers are represented in computers, serialization, compression, encryption, etc. And in some cases, they do not need to know about data structures and algorithms or object oriented programming either.<p>If you use something like node, garbage collection will handle memory for you, the event loop will make things fast enough, you will use JSON serialization, you will use REST, every number is a float... and you get the idea. That reduced amount of knowledge will get you very far.<p>Of course, eventually, you will run into a problem that will require some deeper level of understanding. But by that time you will be already employed.<p>The way I see it, wage depression is imminent.