> 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
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.
You obviously haven't used C++${CURRENT_YEAR}, React rand().rand().rand(), and (define-new-silo functional-p). They are so amazing, it's like the software writes itself. Too bad they are not compatible with each other, or we wouldn't even need programmers anymore, they are such an innovation.
I was working on 20 years old software with quite some technological debt and then on software doing fraction of the same thing for 4 years, written from scratch by today "methologies" (move fast, abstract is everything, so is framework, vm shipped, opensource integrated everywhere,...).
The "new" software has technological debt that far surpasses the old software - but this happened in 4 years, and the team surpasses size of the team for old software. I just cant see how it could survive 20 years. But it was written faster, on the other side, no one really knows its internals - however they brag - due to huge pile of code taken from open source projects. I predict that "death by thousand cuts" will occur spontanously.
Look no further than Docker, which is the tech equivalent of giving up on Earth and moving everyone to Mars because we've screwed up so bad. We transpile one version of JavaScript to another and our stack requires webpack now. Remember when the browser could just load JavaScript without half a dozen middlemen in the way? Back when you didn't have to compile one interpreted language to another, not even gaining a higher level language in the process.
It's rather laughable that software will solve the mess that software creates any time soon.
Docker is to deployment what an API is to development: Hide the complexity inside some barrier and present a cleaner interface. The complexity can be well-managed or not; the point is, the outside world shouldn't have to care what you're doing in there as long as it works and is reasonably efficient.
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.
Industrialization of clothing meant the amount of labor required to create clothing dropped drastically
Those jobs just moved to Bangladesh. I think they are just as inefficient as always. But the west traded textile jobs for other forms of service industries and more complex manufacturing.
No one makes clothing inside a western country as cheaply as they do in Asia, but the conditions in Asia are not heavily automated. They just have more people and an economies at a stage where that sort of work will provide.
I suspect we'll just make more software. You still have to think and there's an upper limit to how much you can automate, and how costly that last jump from some automation to full automation will take.
And what happens when Bangladesh (then Pakistan, then Ethiopia, then etc.) becomes developed enough? Eventually you run out of countries and regions to offshore to.
To clarify, in my metaphor I am comparing the efficiency of labor before and after the industrial revolution. Bangladesh is an industrialized country, so I am not sure I understand your point.
To weave enough cloth to make a single shirt by hand takes orders of magnitude more time than it takes for a loom to produce the same amount of cloth. This is true regardless of what country it happens in and how much the person operating the loom is paid. Yes, the cheap clothes one can buy at H&M, Uniqlo, or Gap are made in Southeast Asia, usually by workers being paid inhumanely low wages. But those clothes are universally made with fabric that is produced by looms and other modern machinery.
My point is just that the volume of clothes produced today (in southeast Asia, for example) would require orders of magnitude more workers to produce in a pre-industrial world.
Despite this massive efficiency jump, there are not less jobs in clothing and fashion related industries; there are more because we wear so much more clothes than we used to.
Eventually the market for software will be much more saturated than today. It has already happened for consumer desktop applications. The rate of new commercially successful desktop applications has dropped in the last thirty years. Sooner or later software for businesses will be "done" too.
I think that's just a shift. It's not that the market for the functionality dried up, it just all moved to the internet. And that market is everbooming.
No, it's saying that since most people in developed countries who want a car already have a car, the market for cars is markedly different from the first half of the 20th century.
My dad loves to tell this story about him going to engineering school in France in the 70's. He was suggested to stay away from CS or software by his guidance counselors - the reasoning? "We'll soon enough have programs able to write themselves - studying to be a software engineer is a dead end".
I'm not sure that some common engineering problems now being solved doesn't just mean that we can now redistribute that workforce on other unsolved problems, or to build new products on-top of those solutions.
I had a similar experience in France in the early 2000s. I went to the unemployment office (ANPE) to ask for a training and they told me that software was a dead end and that it wasn't possible to get training. So I did my own research, found a training organization and went back to the unemployment office giving them the exact reference of the training I wanted. The exact same person then reluctantly pulled a drawer of her desk and gave me an application form. That training kick-started my career in software.
Another thing that was commonly said over the 2000s period is that all software jobs would be quickly outsourced to India. That didn't happen either. Some big companies obviously tried that (and some still do) but a lot of them eventually realized that software wasn't something you could just specify and outsource to a team far away, with a different time zone, culture and language and expect to magically get working software as a result. In the meantime, I think that demand for software in India has also grown. I laughed at loud when in the early 2010s I received an email from an Indian recruitment agent offering me to come work in India.
It's kinda weird comparison, because (beyond necessary) buying clothing is consumption. But buying software is often an investment, so people and businesses can justify spending enormous amount on it, compared to clothing.
This sounds like it was written by someone who hasn't worked with ERP systems, to give an example of where software will never eat software. "Can we make A work with B?" -- a lot of businesses tie together Salesforce + 8 other systems, and that'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.
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't describe how the software is actually made: product solicits customer interviews/data to recommend new features, architects brainstorm a high-level solution, and the IC engineers implement the vision. Human factors, through and through.
In your specific SalesForce scenario they built SalesForce to stop people from coding CRM systems, and then people continue to make money building connected abstractions / Apps on top of other systems that are SalesForce compatible so you get an app ecosystem that abstracts away all of these integrations. The result is less code.
I agree that there is a lot of complexity specifically for "mission critical" or "last mile" systems that will not be addressed by the mainstream abstractions for many organizations, but I don't think SalesForce is necessarily the best example. I see the author's hypothesis freeing up time to do a lot more things within organizations that are otherwise on the back burner because you can't get to that feature set, and/or pivoting to solve either a) complex problems that are not yet solved or b) specializing on a layer that is now "platform". Somebody builds AWS, and Azure, and GCP. Somebody has to create, build and maintain the next platform / abstraction too.
I think your falacy is in the "less code" assumption when you say "The result is less code". I'd argue that empirially we've seen this to be false. The result isn't less code, at least in a global sense, its more productivity, more features, more customization, and more specificity at a cost of less code/feature. Software has really interesting economics where as the cost/feature decreases by a factor, say 1x, then the set of features that can be profitably worked on expands by like 10x, so paradoxically, as cost/feature decreases, it makes sense to hire more engineers and expand R&D budgets.
I think ultimately, the question is whether this trend will result in "fewer programmers needed", which is the most important by-product of "less code" in the author's thesis.
Did we slash R&D budgets once we standardized on the X_86 instruction set thus needing less compiler devs? Did we slash R&D budgets when we moved from on prem to cloud hosting? We have seen this happen many times before, we know the economics. Decreasing cost/feature is synonymous with increasing productivity. We know that a 1x increase in productivity results in a very large increase in the numbers of features that become feasible.
There isn’t some fixed factor here that causes it all to collapse. Productivity increases are plowed into growing the market 10x and building the business, not reducing eng budgets. At some point in the future this will slow down, but that is so far from happening, like many decades from now, maybe never in a non theoretical sense.
No, it's more code with a greater value:code ratio. It's lower code for the same delivered value, but no one stops at the same delivered value that they'd have without whatever tipped that ratio, because the incremental value for the next unit of code is higher.
Increasing the value delivered per unit of code increases the volume of code purchased.
Maybe, but that code tends to be extremely bad quality, because it is always written by "consultants" who know just enough programming to be dangerous and do the bare minimum to get the integration to work, without any concern for or the ability to follow software engineering best practices. And that introduces its own costs.
> This sounds like it was written by someone who hasn't worked with...
Every broad article I've seen like this speaks about 'software' as if it is a monolithic career path. The lives of web programmers, embedded engineers, AI researchers, ERP programmers(etc, etc) are all quite different. Most of the articles I've see on programming/software engineering don't capture the things I've experienced over my 23 years as a programmer.
And then there's the "invisible programmers", the ones who might cross-train as IT technicians, who write internal-only software on an as-needed basis. Need a report? Need a webapp so people can work with a business process database? Need to integrate a CRM into Jira by pulling information out of its backend database nobody has a schema for? Not the kind of stuff they teach you in school, bucko, but someone has to do it.
To me this is a super underrepresented group if you can call it that. Tons and tons of mid market companies have more of these programmers than traditional CS grads.
I think no-code is different than off-shoring. Wherewith offshoring you needed domain expert, some kind software architect which maps features and off-shored team, with you no-code you need usually only domain expert.
100% agreed that people are performing higher level functions today that software can't perform.
However, I think your first point about multi-system interconnectivity is ripe for change.
It's been the case that the literal act of running a business has been humans serving as copy-paste bots between systems, both internal and external. Come to think of it, from a purely software point of view, businesses look a lot like giant, multi-system ETL machines, except that the individual steps in the pipeline (Salesforce, SAP, Netsuite, etc.) don't talk to each other. This is even worse when it comes to interactions with other businesses (customers/vendors/partners) - everyone has different systems and none of them talk to each other.
So we fall back to the lowest common denominator - Email + attachments (XLSX, PDF), CSV over FTP etc.
The fundamental problem is not very different from the challenge of human language translations. Getting SAP to talk to Salesforce is a similar class of problem as enabling an English speaker to talk to a Hindi or Mandarin speaker. If the latter is a solvable (solved?) problem, I don't see why software talking to software is that different. There are of course domain specific challenges, like the fact that both systems being translated between require 100% translation accuracy.
We are working on solving this at https://42layers.io. It's early days for us, but this is exactly the problem we are solving.
Lots of companies trying to build low-code solutions to help business people glue systems together. However, for pretty much all of these solutions, while the end user isn't writing code, they are forced to think like a programmer - if/else, loops etc.
We are taking a very different approach.
We've built a transform engine that can be trained on transforming data from a source structure to a destination structure using a few (10s) of examples of source and destination. We can do this transformation without falling into the trap of figuring out acceptable confidence levels - a trap that most ML systems fall into, and thus have a hard time with enterprise usage.
We couple that with dynamic, configurable integration infrastructure ("connectors" in old school enterprise speak) that can send+receive data to/from lots of systems over many protocols and serialization systems.
End result is that end users can connect systems together with a few clicks and by providing a few lines fo training examples, not unlike what a business person would give a dev and say "extract a CSV from SAP and put it in that FTP folder. the CSV needs to look like this file"
That is the failure of every ORM and visual programming tool I have seen.
(But i happen to think that being forced to think like a programmer is good - on the order of being forced to think like a literate person would have been a few hundred years ago)
The way I see it, the fundamental problem is that the producers of these systems don't want them to talk freely to each other. Every vendor wants to control the conversation (and when you see someone calling their product a "platform", you know they want to control all the conversations in a given sector). E-mail is the lowest common denominator that works, because it happened in the age where computer technology was developed to coordinate, not to compete and control.
Conversations between systems is an easy problem, in the same way translating English to Mandarin is easy if both people are also fluent in Hindi - they can round-trip through the shared language. Systems designers can also negotiate a common protocol. It doesn't have to be automated, it can work just as well with some programmers continuously keeping the protocols up to date. The problem is, there's a strong business imperative to not do any of that.
Super underrated comment. What's even worse is that, internally, large companies have small groups that create bespoke solutions and then try to sell those solutions to the rest of the company. I've seen so many "final frameworks" that are going to solve all of the problems that are then sold to all of the other groups, who try to move their stuff onto that framework, but wait now Team X has another framework and oh man which one should we follow? It's just a new version of the fundamental problem of getting diverse human groups with diverse needs to standardize on some solution, with all of the economic incentives you described mixed in. Frankly I think the people who got this problem closest to right were the American Founding Fathers. This is fundamentally a political problem. The best technical solution I've seen proposed is in the talk "Architecture Without an End State," where the speaker talks about how to make smart decisions in a decentralized environment.
>This sounds like it was written by someone who hasn't worked with ERP systems, to give an example of where software will never eat software.
Software has already been eating software. Imaging building something like Salesforce or an ERP system using only Assembly. Just as programming languages like Java became an abstraction level over Assembly and simplified development of complex systems, something else will emerge (or is already emerging) as a higher level abstraction and will enable creating even more complex systems.
>The industry has already tried commoditizing by off-shoring.
Offshoring doesn't create a new abstraction level.
I don't really agree with the point that because we'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's the continual layering of abstraction that's been going on for decades.
I think the argument is that things like Wix put web developers out of business. Instead of real estate agents hiring a local webdev to make their listings site, or whatever, they can just use Wix.
Those webdevs are out of luck if they can't flex into something else. But, generally, I think you're right. When those jobs go away, in their stead we do other things with software. So instead of building websites for local real estate agents, SWEs are building systems to make virtual RE agents using ML.
I also find that sites like Wix are rarely used as a replacement for an in-house dev team or professional consulting, but rather by businesses that wouldn't have had an online presence in the first place.
I guess I've never considered mostly static brochure sites the purview of web development or "doing software" of the style referenced by this article. It's more like web design. WordPress, as ill-suited as it is, had already begun the incursion into design that Wix and others continued.
But, displacing static-site designers is a much easier task than displacing developers due to the latter's work with logic, interactions, etc. Back in the 90s webapps were still nascent and just moving past cgi-bin to some extent, but the bar on replacing devs gets higher with each passing year. So, absent a huge leap in tooling or code generation, etc., I see dev roles changing more than going away.
>A web store can now be made in minutes. A news site. A forum. Heck, there are tons of turnkey company intranet solutions...
Well, sure, yet demand for developers remains strong. They're now moving up the complexity chain, working on different problems, etc. And, of course many are integrating with turnkey solutions like some you mentioned. Notice how so many of these "turnkey" solutions offer APIs?
A web store or forum isn't going to differentiate a business to success any more than a snazzy website will. The bar is now higher. The cycle continues.
Exactly this. I work for a company that specializes in helping to scale business websites that have moved past the out of the box limits of things like WooCommerce and Shopify.
We do consulting for new businesses every month that have started with these turnkey solutions which worked great for them, until they grew big enough that the system starts to break and hiccup more and more. For those clients, we provide an extreme amount of value to keep their online machine well oiled and they happily write us that check every month.
I will say though, that often the platforms I mentioned are not the real issue in the chain, but rather other tools and custom code added on top to hastily support some business decision. Shopify is a great example. Awesome core product that is extremely performant, but a lot of the themes and pre-built templates out there are not built to facilitate a rich and performant experience for customers. Shopify will gladly let you serve a 20mb banner video that will make even modern desktops chug to render and it doesn't really affect them at all. It's our job as consultants to come in and show the business where they can optimize to increase their conversion rate. They already have a product people want, otherwise they wouldn't be having scaling issues, so it's nice for us to get quick wins that result in positive outcomes for everyone.
>Exactly this. I work for a company that specializes in helping to scale business websites that have moved past the out of the box limits of things like WooCommerce and Shopify.
Sure, but most of them wont move "past the out of the box limits of things like WooCommerce and Shopify". For the 1 that gets bigger or has special needs and does there would be other 9 that are just fine using those platforms...
And of course WooCommerce and Shopify can always add more customizability and capture those features eventually, so those devs who help companies "move past the out of the box limits of things like WooCommerce and Shopify", become comoditized glorified configurators (or the owner or admin of the company can even do it themselves).
>most of them wont move "past the out of the box limits of things like WooCommerce and Shopify"
Many of those who never move past that phase were likely not candidates for custom development anyway. They'd likely have sold on eBay or Amazon, whereas Shopify offered them the chance to have their own "store".
That is, many who can spend $29/month (or whatever) for a Shopify store wouldn't have been able to spring for $5K or $10K+ to have a custom store built. I would bet that's the overwhelming majority of Shopify customers.
So, arguably, you might even say Shopify helped some companies to get to the place where they can afford custom development.
But, this whole store thing is just a narrow focus anyway WRT the idea of obsoleting devs. There are plenty of more complex/differentiated businesses that have sprung up since e-commerce, and by the time any of those things have been commoditized, there'll be still more to take their place in this ongoing evolution.
No business I know paid "good money" for that. At most they would get a neighbor's kid (one of them being me) to throw together a few html pages. Fancy ones had a PHP visitors counter.
> I think the argument is that things like Wix put web developers out of business.
When I started only the most keen companies even had websites and I build them and many weren't much more complicated than you can do with Wix.
Now every company needs an online presence and most can get by with Wix but the number of companies that need a developer to build something competitive is larger now than it was back then.
The market is growing faster. But also the sophistication that users demand is going up as fast as there are tools to accomplish what was perfectly acceptable 10-15 years ago.
People use Wix, get some traction, and then reinvest. Over time, they want to do more and more, but begin bumping into the limitations of the platform. That's when they hire a web developer to build them something.
That company wouldn't have otherwise seen enough value in the web to pursue hiring a web developer.
>We make things easier for ourselves so we can then build upon it and then write more complex things to solve more complex problems.
Only with SaaS most of us aren't needed to "solve more complex problems". The SaaS team can already solve them and sell them...
Most companies don't have "more complex problems" anyway, just problems stemming from bad software integration, which affiliated SaaS services can also solve...
So while there will always be coding work (at building SaaS and at building highly customized solutions), there will much less of it...
>It's the continual layering of abstraction that's been going on for decades.
It had been going on for decades, until it got reversed with the Cloud and SaaS offerings. We just haven't seen the full impact of those yet. But that's what the article is about.
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.
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.
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.
> we will have more software written by a smaller number of people
This was the past IMO. Future will have larger number of people writing even more software.
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.
> Future will have larger number of people writing even more software.
When the majority of the population became educated inn literacy, there wasn't a huge jump for everybody to start writing novels. They merely started writing smaller things - letters, notes, and short form, one-off stuff.
It's the same with software skills. There are going to be an increase, but in the form of small scripts and one-offs for tasks, rather than more software "products".
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 now 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.
I suspect that more people will be writing software as part of their job. They just won't call themselves developers. As the underlying software becomes more powerful (I'm thinking of Microsoft'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.
> Many professional developers will find them selves migrating to solving harder more advanced problems
it may be wishful thinking that this is gonna just happen without major investment from some sort of entity for those developers. And i would also argue that advanced problems are more fewer and far between than "standard" problems being solved today by the majority of developers.
History has shown that displaced workers don't get to re-educate for free. Either the workers themselves will have to pay for such re-education (or advance their existing education to higher level, and thus able to do a more difficult job that hasn't been "automated" or trivialized via a tool), or the gov't pays to mass-educate.
If you currently work for a big-tech, and enjoy a high salary, it would be very prudent to try to invest your salary as much as possible to build a future stream of income for protection, for the eventual scenario where you are made redundant due to advances.
> If you currently work for a big-tech, and enjoy a high salary, it would be very prudent to try to invest your salary as much as possible to build a future stream of income for protection, for the eventual scenario where you are made redundant due to advances.
Good advice. That has always been true for programmers. We constantly have to invest in learning new kinds of things.
I don'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 "just" gluing libraries together.
Anyway, the other argument about salaries is more interesting. Most people seem to agree that there's a huge untapped crowd of qualified developers in small / mid sized US cities who would love to join $BIGCO but the only reason they aren'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 / NYC makes $350k+. I limit my search to Sr Devs because I assume college kids are happy to move to exciting cities like NYC / SF / Seattle on fat relocation checks.
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's talent - NYC as a tech hub wasn't a thing in 2012, but it's huge now for all the people who don't want to leave the east coast. Boston is pretty big. Colorado, Austin as well.
The only way supply of devs is increasing here is if:
* Sr Devs who did not move to tech hubs because they preferred to stay where they are. (Personally think this is unlikely)
* Qualified Bootcamp graduates
* CS Enrollments hitting pretty high numbers, so maybe we'll start graduating lots of CS folks.
* Immigration reform / Outsourcing
* Interviewing change so we skip the algo problem solving shenanigans.
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 / bar.
> 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 / bar.
The fact that big tech has not yet changed the format of the interview I believe shows that this convergence has not yet happened. This system is designed with tolerance for false negatives (qualified grads who will be rejected). At some point if these companies had a true demand for more graduates, they would revise the way they evaluated candidates to limit the number of qualified rejections.
If supply is tapped, then the risk of a mis-hire also increases (higher wages, more difficult to replace in a timely manner, etc). This might counteract any downward pressure on the hiring bar.
That's a pretty healthy salary in most parts of the US as well. I'm still young and make around $5k/mo USD before taxes as a web developer in Texas. Take home is around $4.4k
My SO and I have $30k left of student loans to pay off and then we're throwing our entire salary at buying a house before our city becomes even more expensive. We're hoping to be able to buy that house before the end of 2021.
Luckily we aren't in Austin or we'd be screwed already, but many parts of our city are already too expensive to own property in unless you're making $200k/yr or if you're comfortable leveraging more of your salary towards housing.
Now, we could move and I could keep my salary since I work for a fully remote company, but my SO's job is here in the city and she wouldn't make the same salary in a smaller market. We'd also be leaving our friends/family just to save some money on housing costs so the benefits aren't really worth it. It's dumb to have a really nice house in the middle of nowhere if we don't have visitors to share and enjoy it with.
So even with my healthy salary in a lower cost of living city, we're still struggling to get ahead due to student loan debt, healthcare costs, and housing costs. I would love to move to Europe and even take a slight pay cut to live in a more cohesive society, but from what I've researched, getting a visa without having $$$ in assets is difficult.
Idk where that was all going, but thanks for listening :)
Getting a visa and work permit for a programming job is pretty easy in many European countries once you have the job offer. There are coders from all over the world working in places like Berlin and Amsterdam.
>Sr Devs who did not move to tech hubs because they preferred to stay where they are. (Personally think this is unlikely)
You would be surprised at how many people value their hometown or where they have settled. Technical only equates to high aspiration in SF. There are smaller slower more steady tech companies (probably using the Microsoft stack) outside of the tech hubs that offer stable jobs with decent pay and good work life balance. Being a software engineer in SF means constantly learning new tech and 'keeping up' but if you're not building a massively scalable consumer facing product that doesn't matter so much. In SF even B2B SaaS is built like this but it doesn't have to be.
> Being a software engineer in SF means constantly learning new tech and 'keeping up'
No, it does not.
> You would be surprised at how many people value their hometown or where they have settled.
I would love to see actual data about this rather than articles from hometown newspapers and posts by hometown residents, enthusiastically praising their way of life. It's easy to argue the counterpoint as well, right?
1). There are many jobs that have to be done in person
2). Many people prefer to live in large cities and accept the downsides in order to get the benefits
So, next time you want to make a claim like this, can you share anything objective about this? Thanks.
I know this is more anecdata, but I'm from Ohio and worked on a joint project with a couple of New York devs at #{famous company}. They were very good, and I learned a lot from them, but I could definitely hold my own with them technically (as could another senior dev from my company). We're both family men in the Midwest with no desire to move. Even if you offered me $350,000 or whatever I'm still staying here. But I would obviously take a remote job with #{famous company} if it paid 60-70% of that and I felt like I wouldn't be a second-class citizen as a remote dev.
Chiming in as a Midwest engineering manager here (Michigan). There's no lack of talent in the Midwest, although it's certainly a different calculus to try and match hiring to the supply/demand of engineers here and not everyone does so appropriately.
>>Being a software engineer in SF means constantly learning new tech and 'keeping up'
>No, it does not.
Maybe you consider Kubernetes an old technology by now? Maybe you consider React.js an old technology by now? What about docker? How about ES6?
People at slower tech firms are still building working B2B web services with ES5 jQuery and ASP.NET. The engineers there have been working with jQuery since it's inception. They know it inside and out and have the skill and depth of knowledge to work around the drawbacks and design flaws.
This is from my experience working at smaller tech firms. I've moved to the city now and I can see the difference in tech and I can feel the difference in attitude too. I'm not going to link you a study or any data because no one is out there studying this stuff. This is opinion not science.
>1). There are many jobs that have to be done in person 2). Many people prefer to live in large cities and accept the downsides in order to get the benefits
Both of these statements are true but I don't see how they are relevant? I'm not denying either of these facts but it doesn't stop the small town engineers from existing.
> Maybe you consider Kubernetes an old technology by now? Maybe you consider React.js an old technology by now? What about docker? How about ES6?
My father (and many others like him) has been programming in C at a prominent SV company for the past 15 years (OK, it's based in the South Bay). I know many people in SF doing similar jobs, just coding away in Java or C++. Those people come to work, do their work, then go home. They don't tweet, or write Medium posts, or have dark green GitHub activity profiles. They don't work with you, so they don't talk to you. You aren't aware they exist. However, these people build many of the systems that make our day-to-day lives possible.
> I'm not denying either of these facts but it doesn't stop the small town engineers from existing.
I'm not saying they don't exist, I'm just saying that there just aren't that many of them.
Fair enough and I agree there aren't that many of them.
I have a lot of respect for people like your father. That's why I wanted to represent the small town devs who are similar in many ways. I personally am a little sick of the whole scene and constant newness.
I'm learning C++ in my free time because I've become disilusioned with life as a JavaScript developer. I know there are C jobs in embedded systems and OS dev but I didn't know there were still a lot of C++ jobs around outside of games.
I think you're confusing 'competitive' with 'skilled'. They are correlated but not the same thing. The best of the best who want to be the best relocate. The best of the best who don't care to be the best stay where they are. People in the second category are driven by an intense interest in their subject and their work rather than competition.
A big breakthrough can be in finding ways to use contractors instead of employees, or in other words allowing people to contribute when they want rather than being tied in a full-time employment contract.
Obviously there are big, possibly insurmountable, obstacles related to the cost of onboarding/learning bespoke tech stacks, the need to preserve trade secrets and serial dependencies that require work to be performed quickly.
> 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.
I think software is just a big pile of garbage. The thing is: our civilization depends on this pile of garbage. It's remarkable that the whole thing somehow chugs along.
Over time, the pile will just keep getting bigger and bigger and more people will be needed to keep it from collapsing.
The microservices make it easy to create a big ball of software that covers as much featurespace or ground as possible. That'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.
As soon as precision and performance become critical, you're back to dredging through the code because microservice were built on assumptions that your ball of software executes poorly.
This move for collective action attempts makes the independent wfh type irrelevant and then suck them back into the fold via 'collective bargaining' 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.
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've been hearing this same thing since the 80's when my friend's dad questioned why I would want to become a programmer when eventually computers would be able to program themselves.
In my opinion, the author is a bit disconnected from the reality of software.
We'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.
A lot of the gains we're seeing are built on top of the tremendous progress made by the hardware guys, we've been free-riding for a long time.
I think that a few bullshit jobs might be exposed/compromised by the transition to remote work, and that includes managers, but not people doing creative work.
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.
> Remote-First, Collective-Last
> 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.
Agreed, I found this to be the revelatory part of the post. It’s difficult enough in person to try to organize demands from management, I hadn’t considered how much more difficult that will become with a distributed workforce.
I connect with my colleagues on LinkedIn for this reason alone. It allows us to have discourse outside of work-sanctioned chatrooms. Having said that, I've never worked at a place where anything has resulted from private communications I've had with my peers. And it would have, had it been posted on the wall in the breakroom.
Will you trust LinkedIn to keep your data private when your employer (or a future employer) hands them a big fat check? Not trying to be snarky just want to point out the exposure points.
Because the majority of remote work communication will be electronic rather than face to face. It will be monitored, stored and searchable (Slack logs, GSuite email, etc.) That’s much more difficult to achieve at the proverbial water cooler.
Not sure which rock you’re living under, but tech is probably the last bastion of labor power in the US. Sure, they aren’t well organized, but Google employees recently canned a DoD contract [1]. Saying no to Uncle Sam is a huge flex, and you can bet that pissed off some overlords.
Blue collar workers in the US have lost almost all of their labor power due to offshore workers or immigration (i.e. scabs). Tech has had it easy for a while now, but it’s the next target; the immigration debate is already shifting from “jobs Americans won’t do” to “merit-based”. Gig economy is another false liberation ploy being used to weaken collective bargaining power. Remote-first is yet another.
> Because the majority of remote work communication will be electronic rather than face to face. It will be monitored, stored and searchable (Slack logs, GSuite email, etc.) That’s much more difficult to achieve at the proverbial water cooler.
The majority of communication is already electronic. I've worked in offices and remote, there is practically no difference on that front. Most discussion takes place in Slack, Jira, GitHub, and email either way. Most companies already have team members distributed across various offices, remote work isn't new. If you want to avoid monitoring, then spin up a Google Hangouts or Zoom meeting, nobody is monitoring that.
The difference is that in an office, 1. your physical presence is also monitored (no joke I worked at a office once where every day an office assistant would secretly record what time everyone showed up to their desks) 2. your internet is also monitored, which is extremely creepy and I'm surprised this doesn't get more attention.
When I work remotely, there are no IT managers able to spy on my internet traffic. Sure there may be some dystopian corporations who try to force their remote workers to log into "company VPNs" and install "monitoring software" - I have absolutely no interest in working for any such companies and have never had to deal with that.
As a software engineer I've been fighting for the freedom to work remotely for ever since I joined this industry, so having the freedom to live wherever I want, and work whenever I want is a huge win. I've already been working remotely since pre-COVID, so I'm happy that other workers will also be able to enjoy this freedom.
Good points. Not saying there isn’t an upside to remote work, but there are downsides as well, which in the long run, may overshadow the benefits. It’s much harder to build camaraderie in a Hangout or Zoom than in frequent, random, physical interactions with people. There’s also a biological component to bonding (pheromones, touch, oxytocin, body language, etc.) that simply won’t exist in a virtual environment.
I’d also point out, you’re enjoying the luxury of those freedoms (privacy, non-creepy norms) because labor power still exists and you can easily move to a different company or whatever. But fast forward 10 years, everyone is remote, labor pool is much larger, norms of monitoring and policing communication are established, then things start clamping down across the board as standard practice.
If you work at a corporation beyond a certain size, usually big enough to have an IT department vs one 'IT guy', there is definitely some sort of monitoring software installed on the computers given to you.
It just lives in kernel modules or as a OS config and they do not tell you as an employee, and it's done for 'compliance' or 'security' reasons so it's not obvious what it is when you look at a list of processes on your computer in the task manager.
Some popular ones in the bay area for macOS at startups are crowdstrike, carbon black, jamf, openvpn, umbrella, crashplan, munki, etc. Not mention the OS management configuration stuff like MDM profiles for macOS and active directory configurations for windows. A lot of brand name corps you might think are 'good guys' use this, like lyft or dropbox. Similarly with companies FANG, where it might custom software.
Osquery core developer, consultant, and technical committee member here...
We've always treaded carefully around privacy concerns as a project. This is why you don't see tables that access information such as browser history. If you join our Slack channels you will see open discussion of privacy implications for changes and improvements.
There's a balance to be struck between visibility and privacy. If a security team has no visibility into a system, they can't secure that system. This doesn't mean they need to be able to look at your family photos and read your messages.
I work with folks who care deeply about privacy and trust with their users. These folks ensure that osquery configurations are available to users, so that they can see what exactly is being monitored.
I think the real issue, that has nothing to do with osquery or any specific piece of software, is the corp being able to push any software on worker's computers and spy on their employees secretly. I call it the stalker IT employee problem or the psychopathic manager / lawyer problem.
The solution will be legal I think in the end, like in some european countries that don't let you do this kind of surveillance on your employees. And if you want to look at an employee's work emails, you do it in front of them with their lawyer present.
I'm glad you guys are trying to keep some semblance of privacy although.
If you’re working from home wouldn’t the way to go just to have a second physical machine set up next to your work machine and do your personal communication from there?
Yes that is what I recommend. At work I have a second BT keyboard and send messages through my phone.
There is definitely still friction in the entire process (ex send a link to an HN article to a friend that you saw in your work machine web browser) which induces a lot of people to just login directly on their work machines.
Since we are all WFH now I've been meaning to set up some sort of synergy setup so I can keep it really separated, but still have less friction in the 'share a link' scenario.
> 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.
Slightly tangential to this thread, but isn't this also tacit admission that employees will be collectively less creative when working remotely.
If only one company goes remote, then the collective power of employees certainly goes down (« divide and conquer «)
But if the entire /job market/ goes remote and access to the net is a public commodity, then you can apply for all jobs /anywhere/. Employees bargaining power increases significantly. Furthermore, any employee can start his/her competing business in an instant.
As a side effect, wages can go down but if you don’t work in the bay area you can come out /better off/.
So it’s not clear if the downside is going to be related to worker’s rights. I am personally more worried on the societal / mental issues with WFH.
Agreed that that was the most interesting part of the essay, but not with the “easier to spy upon” part - I’ve been working remotely for years now and whenever a conversation leads anywhere close to being “sensitive” (eg, even talk of potential side projects) I just quickly open a non work communication channel and do it there (eg another Slack, fb messenger, what have you)
Yes! So sad I have scroll so far down to see this. There is a huge risk here that we will be isolated more than ever, and yet more dependent upon other unseen actors---the contrast between these two phenomena is one of downsides of capitalism in practice, and this can crank it up.
Here are some crucial steps we must take in defense:
- Make sure working with non-employees is legal: no non-disclosure agreements saying you can't work in coffee shop or other shared space because of potential of overhearing. This would be the best hope
- Towns or cheaper cities, not exurbs. People must know their neighbors better if they know their coworkers less. Time spent walking around the office must be replaced with time spent walking elsewhere.
- More Aggressive anti-trust. If labor becomes more balkanized, capital must also be.
- Workers on boards. Like Germany, if you grow past a certain size this needs to be mandated.
Notice the last two point to the two healthy solutions: decentralized small businesses economy vs giant co-op socialism. The point is to basically all institutions must score high enough on the sum decentralization or democracy, and that the total of the two is far more important then the relative merits of each.
It's a false dichotomy, that because software is getting easier to write, less people will be writing software.
Yes it's true that software in the future will be easier to write, but we will not be solving the same problems as today.
In the past (20 years ago), developing a TODO app was relatively difficult and could of been a valid startup idea. However today it's a trivial application to develop and is the equivalent of a "hello world" program.
The reality is; Writing software gets easier, While the problems software solves get harder...
This is the right take. Same thing with 2D games to VR/AR. Infotainment systems to Self Driving, Real Player buffering to Netflix. And the list goes on. You can't get this progress simply by making better abstractions. You can only paper over the complexities of "solved" problems.
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.
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.
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:
> 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.
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.
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.
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.
I think there’s actually a significant risk to Silicon Valley here, which is the following potential vicious cycle:
- Big Tech decides all/mostly remote is the future.
- Big Tech mostly stops hiring in the Bay Area because why pay more for talent when they no longer “have to.”
- The COVID reset layoffs continue, resulting in a lot of Bay Area engineers looking for work at the same time.
- 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).
- Engineers who can no longer command crazy salaries to justify the rent start leaving the area (this is also already happening).
- Rents start to drop, and the housing market softens a little.
- Tech workers who have relatively recently bought homes get nervous and look to exit before they get underwater on million+ dollar loans.
- The housing market softens further...
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.
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.
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.
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.
The article really should have led with this second point, which is the most grounded in real-world conditions and most relatable to software engineers stuck in high CoL tech hubs, while the no-code first point is futuristic and the class consciousness of tech workers third point is sadly a little fanciful.
I do agree with your remarks, but I wonder what is it that reinforces the negationism to that new reality by most commenters here. I have doubts that companies want to go the offshore routes of yore, but effectively I expect this wfh trend will create a lot of new competition between IT work force, in the USA, at least.
A lot of people in the discussion disagree with the article's first point about no-code/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/PaaS reducing the number of in-house server engineers that companies need, and how the proliferation of open-source libraries/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't. Even in the face of self-driving cars and automated receptionist/call support agents that James Watt couldn't even dream of.
But whether no-code/less-code is inevitable, I think his first argument can still be substantiated from a different approach, at least in the near future: we're coming at the end of a tech bubble, the money will start receding, and organizations have already been realizing they don'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/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?
To some extent, yes, it's what'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't actually have tangible economic benefit to these organizations, and may have even led to worse outcomes due to unsustainable or reckless behavior.
Going back to the article, whether the first point can be explained by inevitable no-code/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:
> 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.
And the article'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.
> we're coming at the end of a tech bubble, the money will start receding, and organizations have already been realizing they don't need so many coders (and other staff) after all.
This is an interesting point. Is this really happening though? Tech valuations pretty much bounced back up. Gut feeling says yes something is wrong with the current monetary system, and a bust cycle should be coming, but with the 0% interest rate and massive quantitative easing, maybe this can go on for longer than we think...
Even if it isn't an outright recession, it appears that VC funding is drastically pulling back, though maybe it's COVID-19-specific [0]. And the ongoing implosion of the Softbank Vision Fund seems to have had a domino effect that preceded the pandemic, with the waves of layoffs across that fund's wide portfolio in January.
It certainly feels as if some bubble is getting burst, even if it's not the entire tech industry's.
Yes, the feeling is that something is off.
But a lot of economists have been feeling this for 5 years; some even claim we never really recovered from 2002 and 2008 busts but only snowballed the problem to the future.
That said, it very well may be that this cheap money era continues. It's very hard to determine when and what will happen.
I'd say exactly the opposite. It feels like there have been a succession of well-needed adjustments, rather than a bubble popping. On paper post-2008 has been the biggest bull run ever, but people still feel caution; the "irrational exuberance" that pumps up a bubble hasn't come yet.
The adjustments are still being made. I’d say your point would be stronger after more market corrections have been made- for example, the notoriously unsustainable and unprofitable food delivery app space is still being propped up by this crisis.
AirBNB had less than a few thousand employees in their HQ, I think their engineer count was under 1000. In the scheme of things that is not a lot of engineers.
And Uber did not write their own slack, they set up a mattermost instance and then put some logos on it. It's a bit more than complex running an exchange server in a corporation.
Most of the money burned by these companies was in the operations, marketing and incentive side, not on the engineering side.
My estimate at the end of this will be a second tech bubble, due to way more money being printed and given to bankers again, even lower interest rates and surprise surprise, software is one of the few things giving a return, yet again.
I'm not saying that engineering is necessarily the cost centers at these companies currently experiencing major layoffs (though the high salaries probably don't help), but it does call into question how much software being written is actually beneficial to these businesses, if they're able to shed engineers just like that.
The reason why these two companies are having major layoffs is because they are in the travel sector and COVID is a custom made disaster for any company in the travel sector. I think they are hurting themselves in the long run, but they are choosing long term survival and cutting of new incomplete initiatives for the more well proven cash cows, which hurts their future.
Also software in many companies managing large complicated multibillion business are a bit of an iceberg. There is a lot of internal software that you are not exposed to as an end user customer. I call it the google search effect. Why so many servers and engineers for a 2 page website?!
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.
438 comments
[ 6.3 ms ] story [ 314 ms ] threadMaybe 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 was working on 20 years old software with quite some technological debt and then on software doing fraction of the same thing for 4 years, written from scratch by today "methologies" (move fast, abstract is everything, so is framework, vm shipped, opensource integrated everywhere,...).
The "new" software has technological debt that far surpasses the old software - but this happened in 4 years, and the team surpasses size of the team for old software. I just cant see how it could survive 20 years. But it was written faster, on the other side, no one really knows its internals - however they brag - due to huge pile of code taken from open source projects. I predict that "death by thousand cuts" will occur spontanously.
It's rather laughable that software will solve the mess that software creates any time soon.
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.
Won’t we just write more software?
Those jobs just moved to Bangladesh. I think they are just as inefficient as always. But the west traded textile jobs for other forms of service industries and more complex manufacturing. No one makes clothing inside a western country as cheaply as they do in Asia, but the conditions in Asia are not heavily automated. They just have more people and an economies at a stage where that sort of work will provide.
I suspect we'll just make more software. You still have to think and there's an upper limit to how much you can automate, and how costly that last jump from some automation to full automation will take.
To weave enough cloth to make a single shirt by hand takes orders of magnitude more time than it takes for a loom to produce the same amount of cloth. This is true regardless of what country it happens in and how much the person operating the loom is paid. Yes, the cheap clothes one can buy at H&M, Uniqlo, or Gap are made in Southeast Asia, usually by workers being paid inhumanely low wages. But those clothes are universally made with fabric that is produced by looms and other modern machinery.
My point is just that the volume of clothes produced today (in southeast Asia, for example) would require orders of magnitude more workers to produce in a pre-industrial world.
Despite this massive efficiency jump, there are not less jobs in clothing and fashion related industries; there are more because we wear so much more clothes than we used to.
that's because a lot of what used to be possible only on desktop has been moved into web-based SaaS or mobile.
If you count mobile phones as "desktops" - there's millions more apps on mobile than there are on real desktops.
Software will likely dominate all other industries, as the absolute essence of automation is software.
I'm not sure that some common engineering problems now being solved doesn't just mean that we can now redistribute that workforce on other unsolved problems, or to build new products on-top of those solutions.
Another thing that was commonly said over the 2000s period is that all software jobs would be quickly outsourced to India. That didn't happen either. Some big companies obviously tried that (and some still do) but a lot of them eventually realized that software wasn't something you could just specify and outsource to a team far away, with a different time zone, culture and language and expect to magically get working software as a result. In the meantime, I think that demand for software in India has also grown. I laughed at loud when in the early 2010s I received an email from an Indian recruitment agent offering me to come work in India.
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't describe how the software is actually made: product solicits customer interviews/data to recommend new features, architects brainstorm a high-level solution, and the IC engineers implement the vision. Human factors, through and through.
I agree that there is a lot of complexity specifically for "mission critical" or "last mile" systems that will not be addressed by the mainstream abstractions for many organizations, but I don't think SalesForce is necessarily the best example. I see the author's hypothesis freeing up time to do a lot more things within organizations that are otherwise on the back burner because you can't get to that feature set, and/or pivoting to solve either a) complex problems that are not yet solved or b) specializing on a layer that is now "platform". Somebody builds AWS, and Azure, and GCP. Somebody has to create, build and maintain the next platform / abstraction too.
There isn’t some fixed factor here that causes it all to collapse. Productivity increases are plowed into growing the market 10x and building the business, not reducing eng budgets. At some point in the future this will slow down, but that is so far from happening, like many decades from now, maybe never in a non theoretical sense.
No, it's more code with a greater value:code ratio. It's lower code for the same delivered value, but no one stops at the same delivered value that they'd have without whatever tipped that ratio, because the incremental value for the next unit of code is higher.
Increasing the value delivered per unit of code increases the volume of code purchased.
Maybe, but that code tends to be extremely bad quality, because it is always written by "consultants" who know just enough programming to be dangerous and do the bare minimum to get the integration to work, without any concern for or the ability to follow software engineering best practices. And that introduces its own costs.
Every broad article I've seen like this speaks about 'software' as if it is a monolithic career path. The lives of web programmers, embedded engineers, AI researchers, ERP programmers(etc, etc) are all quite different. Most of the articles I've see on programming/software engineering don't capture the things I've experienced over my 23 years as a programmer.
https://news.ycombinator.com/item?id=14564455
However, I think your first point about multi-system interconnectivity is ripe for change.
It's been the case that the literal act of running a business has been humans serving as copy-paste bots between systems, both internal and external. Come to think of it, from a purely software point of view, businesses look a lot like giant, multi-system ETL machines, except that the individual steps in the pipeline (Salesforce, SAP, Netsuite, etc.) don't talk to each other. This is even worse when it comes to interactions with other businesses (customers/vendors/partners) - everyone has different systems and none of them talk to each other.
So we fall back to the lowest common denominator - Email + attachments (XLSX, PDF), CSV over FTP etc.
The fundamental problem is not very different from the challenge of human language translations. Getting SAP to talk to Salesforce is a similar class of problem as enabling an English speaker to talk to a Hindi or Mandarin speaker. If the latter is a solvable (solved?) problem, I don't see why software talking to software is that different. There are of course domain specific challenges, like the fact that both systems being translated between require 100% translation accuracy.
We are working on solving this at https://42layers.io. It's early days for us, but this is exactly the problem we are solving.
Lots of companies trying to build low-code solutions to help business people glue systems together. However, for pretty much all of these solutions, while the end user isn't writing code, they are forced to think like a programmer - if/else, loops etc.
We are taking a very different approach.
We've built a transform engine that can be trained on transforming data from a source structure to a destination structure using a few (10s) of examples of source and destination. We can do this transformation without falling into the trap of figuring out acceptable confidence levels - a trap that most ML systems fall into, and thus have a hard time with enterprise usage.
We couple that with dynamic, configurable integration infrastructure ("connectors" in old school enterprise speak) that can send+receive data to/from lots of systems over many protocols and serialization systems.
End result is that end users can connect systems together with a few clicks and by providing a few lines fo training examples, not unlike what a business person would give a dev and say "extract a CSV from SAP and put it in that FTP folder. the CSV needs to look like this file"
That is the failure of every ORM and visual programming tool I have seen.
(But i happen to think that being forced to think like a programmer is good - on the order of being forced to think like a literate person would have been a few hundred years ago)
But interesting if you can do it.
Conversations between systems is an easy problem, in the same way translating English to Mandarin is easy if both people are also fluent in Hindi - they can round-trip through the shared language. Systems designers can also negotiate a common protocol. It doesn't have to be automated, it can work just as well with some programmers continuously keeping the protocols up to date. The problem is, there's a strong business imperative to not do any of that.
> English to Mandarin is easy if both people are also fluent in Hindi
This is so true. In one of my tasks as a consultant at a law firm, this is literally what happened when working on a plaintiff side case.
A partner spoke Mandarin, Japanese and Hindi while I spoke English, Hindi. We were called upon by translators a lot to proof eDiscovery case files.
Software has already been eating software. Imaging building something like Salesforce or an ERP system using only Assembly. Just as programming languages like Java became an abstraction level over Assembly and simplified development of complex systems, something else will emerge (or is already emerging) as a higher level abstraction and will enable creating even more complex systems.
>The industry has already tried commoditizing by off-shoring.
Offshoring doesn't create a new abstraction level.
I don't really agree with the point that because we'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's the continual layering of abstraction that's been going on for decades.
Those webdevs are out of luck if they can't flex into something else. But, generally, I think you're right. When those jobs go away, in their stead we do other things with software. So instead of building websites for local real estate agents, SWEs are building systems to make virtual RE agents using ML.
Even your local real estate agent or plumber paid for a website...
But, displacing static-site designers is a much easier task than displacing developers due to the latter's work with logic, interactions, etc. Back in the 90s webapps were still nascent and just moving past cgi-bin to some extent, but the bar on replacing devs gets higher with each passing year. So, absent a huge leap in tooling or code generation, etc., I see dev roles changing more than going away.
Not that much when it comes to the majority of web development needs. A web store can now be made in minutes. A news site. A forum.
Heck, there are tons of turnkey company intranet solutions...
Well, sure, yet demand for developers remains strong. They're now moving up the complexity chain, working on different problems, etc. And, of course many are integrating with turnkey solutions like some you mentioned. Notice how so many of these "turnkey" solutions offer APIs?
A web store or forum isn't going to differentiate a business to success any more than a snazzy website will. The bar is now higher. The cycle continues.
We do consulting for new businesses every month that have started with these turnkey solutions which worked great for them, until they grew big enough that the system starts to break and hiccup more and more. For those clients, we provide an extreme amount of value to keep their online machine well oiled and they happily write us that check every month.
I will say though, that often the platforms I mentioned are not the real issue in the chain, but rather other tools and custom code added on top to hastily support some business decision. Shopify is a great example. Awesome core product that is extremely performant, but a lot of the themes and pre-built templates out there are not built to facilitate a rich and performant experience for customers. Shopify will gladly let you serve a 20mb banner video that will make even modern desktops chug to render and it doesn't really affect them at all. It's our job as consultants to come in and show the business where they can optimize to increase their conversion rate. They already have a product people want, otherwise they wouldn't be having scaling issues, so it's nice for us to get quick wins that result in positive outcomes for everyone.
Sure, but most of them wont move "past the out of the box limits of things like WooCommerce and Shopify". For the 1 that gets bigger or has special needs and does there would be other 9 that are just fine using those platforms...
And of course WooCommerce and Shopify can always add more customizability and capture those features eventually, so those devs who help companies "move past the out of the box limits of things like WooCommerce and Shopify", become comoditized glorified configurators (or the owner or admin of the company can even do it themselves).
Many of those who never move past that phase were likely not candidates for custom development anyway. They'd likely have sold on eBay or Amazon, whereas Shopify offered them the chance to have their own "store".
That is, many who can spend $29/month (or whatever) for a Shopify store wouldn't have been able to spring for $5K or $10K+ to have a custom store built. I would bet that's the overwhelming majority of Shopify customers.
So, arguably, you might even say Shopify helped some companies to get to the place where they can afford custom development.
But, this whole store thing is just a narrow focus anyway WRT the idea of obsoleting devs. There are plenty of more complex/differentiated businesses that have sprung up since e-commerce, and by the time any of those things have been commoditized, there'll be still more to take their place in this ongoing evolution.
You'd be surprised. Back in the day web devs couldn't decline enough jobs, and you could make a month's salary for what was a single static webpage...
When I started only the most keen companies even had websites and I build them and many weren't much more complicated than you can do with Wix.
Now every company needs an online presence and most can get by with Wix but the number of companies that need a developer to build something competitive is larger now than it was back then.
The market is growing faster. But also the sophistication that users demand is going up as fast as there are tools to accomplish what was perfectly acceptable 10-15 years ago.
People use Wix, get some traction, and then reinvest. Over time, they want to do more and more, but begin bumping into the limitations of the platform. That's when they hire a web developer to build them something.
That company wouldn't have otherwise seen enough value in the web to pursue hiring a web developer.
Only with SaaS most of us aren't needed to "solve more complex problems". The SaaS team can already solve them and sell them...
Most companies don't have "more complex problems" anyway, just problems stemming from bad software integration, which affiliated SaaS services can also solve...
So while there will always be coding work (at building SaaS and at building highly customized solutions), there will much less of it...
>It's the continual layering of abstraction that's been going on for decades.
It had been going on for decades, until it got reversed with the Cloud and SaaS offerings. We just haven't seen the full impact of those yet. But that's what the article is about.
They solve some problems and create other.
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.
This was the past IMO. Future will have larger number of people writing even more software.
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.
When the majority of the population became educated inn literacy, there wasn't a huge jump for everybody to start writing novels. They merely started writing smaller things - letters, notes, and short form, one-off stuff.
It's the same with software skills. There are going to be an increase, but in the form of small scripts and one-offs for tasks, rather than more software "products".
Well, we can always "learn to code"... oh, wait...
it may be wishful thinking that this is gonna just happen without major investment from some sort of entity for those developers. And i would also argue that advanced problems are more fewer and far between than "standard" problems being solved today by the majority of developers.
History has shown that displaced workers don't get to re-educate for free. Either the workers themselves will have to pay for such re-education (or advance their existing education to higher level, and thus able to do a more difficult job that hasn't been "automated" or trivialized via a tool), or the gov't pays to mass-educate.
If you currently work for a big-tech, and enjoy a high salary, it would be very prudent to try to invest your salary as much as possible to build a future stream of income for protection, for the eventual scenario where you are made redundant due to advances.
Good advice. That has always been true for programmers. We constantly have to invest in learning new kinds of things.
Anyway, the other argument about salaries is more interesting. Most people seem to agree that there's a huge untapped crowd of qualified developers in small / mid sized US cities who would love to join $BIGCO but the only reason they aren'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 / NYC makes $350k+. I limit my search to Sr Devs because I assume college kids are happy to move to exciting cities like NYC / SF / Seattle on fat relocation checks.
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's talent - NYC as a tech hub wasn't a thing in 2012, but it's huge now for all the people who don't want to leave the east coast. Boston is pretty big. Colorado, Austin as well.
The only way supply of devs is increasing here is if:
* Sr Devs who did not move to tech hubs because they preferred to stay where they are. (Personally think this is unlikely)
* Qualified Bootcamp graduates
* CS Enrollments hitting pretty high numbers, so maybe we'll start graduating lots of CS folks.
* Immigration reform / Outsourcing
* Interviewing change so we skip the algo problem solving shenanigans.
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 / bar.
The fact that big tech has not yet changed the format of the interview I believe shows that this convergence has not yet happened. This system is designed with tolerance for false negatives (qualified grads who will be rejected). At some point if these companies had a true demand for more graduates, they would revise the way they evaluated candidates to limit the number of qualified rejections.
My SO and I have $30k left of student loans to pay off and then we're throwing our entire salary at buying a house before our city becomes even more expensive. We're hoping to be able to buy that house before the end of 2021.
Luckily we aren't in Austin or we'd be screwed already, but many parts of our city are already too expensive to own property in unless you're making $200k/yr or if you're comfortable leveraging more of your salary towards housing.
Now, we could move and I could keep my salary since I work for a fully remote company, but my SO's job is here in the city and she wouldn't make the same salary in a smaller market. We'd also be leaving our friends/family just to save some money on housing costs so the benefits aren't really worth it. It's dumb to have a really nice house in the middle of nowhere if we don't have visitors to share and enjoy it with.
So even with my healthy salary in a lower cost of living city, we're still struggling to get ahead due to student loan debt, healthcare costs, and housing costs. I would love to move to Europe and even take a slight pay cut to live in a more cohesive society, but from what I've researched, getting a visa without having $$$ in assets is difficult.
Idk where that was all going, but thanks for listening :)
You would be surprised at how many people value their hometown or where they have settled. Technical only equates to high aspiration in SF. There are smaller slower more steady tech companies (probably using the Microsoft stack) outside of the tech hubs that offer stable jobs with decent pay and good work life balance. Being a software engineer in SF means constantly learning new tech and 'keeping up' but if you're not building a massively scalable consumer facing product that doesn't matter so much. In SF even B2B SaaS is built like this but it doesn't have to be.
No, it does not.
> You would be surprised at how many people value their hometown or where they have settled.
I would love to see actual data about this rather than articles from hometown newspapers and posts by hometown residents, enthusiastically praising their way of life. It's easy to argue the counterpoint as well, right?
1). There are many jobs that have to be done in person 2). Many people prefer to live in large cities and accept the downsides in order to get the benefits
So, next time you want to make a claim like this, can you share anything objective about this? Thanks.
Maybe you consider Kubernetes an old technology by now? Maybe you consider React.js an old technology by now? What about docker? How about ES6?
People at slower tech firms are still building working B2B web services with ES5 jQuery and ASP.NET. The engineers there have been working with jQuery since it's inception. They know it inside and out and have the skill and depth of knowledge to work around the drawbacks and design flaws.
This is from my experience working at smaller tech firms. I've moved to the city now and I can see the difference in tech and I can feel the difference in attitude too. I'm not going to link you a study or any data because no one is out there studying this stuff. This is opinion not science.
>1). There are many jobs that have to be done in person 2). Many people prefer to live in large cities and accept the downsides in order to get the benefits
Both of these statements are true but I don't see how they are relevant? I'm not denying either of these facts but it doesn't stop the small town engineers from existing.
My father (and many others like him) has been programming in C at a prominent SV company for the past 15 years (OK, it's based in the South Bay). I know many people in SF doing similar jobs, just coding away in Java or C++. Those people come to work, do their work, then go home. They don't tweet, or write Medium posts, or have dark green GitHub activity profiles. They don't work with you, so they don't talk to you. You aren't aware they exist. However, these people build many of the systems that make our day-to-day lives possible.
> I'm not denying either of these facts but it doesn't stop the small town engineers from existing.
I'm not saying they don't exist, I'm just saying that there just aren't that many of them.
I have a lot of respect for people like your father. That's why I wanted to represent the small town devs who are similar in many ways. I personally am a little sick of the whole scene and constant newness.
I'm learning C++ in my free time because I've become disilusioned with life as a JavaScript developer. I know there are C jobs in embedded systems and OS dev but I didn't know there were still a lot of C++ jobs around outside of games.
Obviously there are big, possibly insurmountable, obstacles related to the cost of onboarding/learning bespoke tech stacks, the need to preserve trade secrets and serial dependencies that require work to be performed quickly.
Eh, check out these sources:
10 Fastest Growing jobs in the USA--
https://www.bls.gov/ooh/fastest-growing.htm
IT Security & App Developer occupations have approximately 30% growth rates over the next 10 years.
Wages and projected openings by occupation--
https://www.bls.gov/careeroutlook/2019/article/wages-and-ope...
IT & Computer related occupations, in aggregate, have 250k-300k openings each year in the USA.
It's nice to have suspicions. It's even nicer to have data.
I think software is just a big pile of garbage. The thing is: our civilization depends on this pile of garbage. It's remarkable that the whole thing somehow chugs along.
Over time, the pile will just keep getting bigger and bigger and more people will be needed to keep it from collapsing.
As soon as precision and performance become critical, you're back to dredging through the code because microservice were built on assumptions that your ball of software executes poorly.
This move for collective action attempts makes the independent wfh type irrelevant and then suck them back into the fold via 'collective bargaining' 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.
The complexity just keeps ratcheting up.
We'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.
A lot of the gains we're seeing are built on top of the tremendous progress made by the hardware guys, we've been free-riding for a long time.
I think that a few bullshit jobs might be exposed/compromised by the transition to remote work, and that includes managers, but not people doing creative work.
> Remote-First, Collective-Last
> 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.
How does the freedom to work remotely make one more prone to being "spied on" than being in an office?
Also, when did tech have any "labor" power? Last time I checked any talk of "unionization" will get you fired at the drop of a dime.
Not sure which rock you’re living under, but tech is probably the last bastion of labor power in the US. Sure, they aren’t well organized, but Google employees recently canned a DoD contract [1]. Saying no to Uncle Sam is a huge flex, and you can bet that pissed off some overlords.
Blue collar workers in the US have lost almost all of their labor power due to offshore workers or immigration (i.e. scabs). Tech has had it easy for a while now, but it’s the next target; the immigration debate is already shifting from “jobs Americans won’t do” to “merit-based”. Gig economy is another false liberation ploy being used to weaken collective bargaining power. Remote-first is yet another.
[1] https://www.washingtonpost.com/news/the-switch/wp/2018/06/01...
The majority of communication is already electronic. I've worked in offices and remote, there is practically no difference on that front. Most discussion takes place in Slack, Jira, GitHub, and email either way. Most companies already have team members distributed across various offices, remote work isn't new. If you want to avoid monitoring, then spin up a Google Hangouts or Zoom meeting, nobody is monitoring that.
The difference is that in an office, 1. your physical presence is also monitored (no joke I worked at a office once where every day an office assistant would secretly record what time everyone showed up to their desks) 2. your internet is also monitored, which is extremely creepy and I'm surprised this doesn't get more attention.
When I work remotely, there are no IT managers able to spy on my internet traffic. Sure there may be some dystopian corporations who try to force their remote workers to log into "company VPNs" and install "monitoring software" - I have absolutely no interest in working for any such companies and have never had to deal with that.
As a software engineer I've been fighting for the freedom to work remotely for ever since I joined this industry, so having the freedom to live wherever I want, and work whenever I want is a huge win. I've already been working remotely since pre-COVID, so I'm happy that other workers will also be able to enjoy this freedom.
I’d also point out, you’re enjoying the luxury of those freedoms (privacy, non-creepy norms) because labor power still exists and you can easily move to a different company or whatever. But fast forward 10 years, everyone is remote, labor pool is much larger, norms of monitoring and policing communication are established, then things start clamping down across the board as standard practice.
It just lives in kernel modules or as a OS config and they do not tell you as an employee, and it's done for 'compliance' or 'security' reasons so it's not obvious what it is when you look at a list of processes on your computer in the task manager.
Some popular ones in the bay area for macOS at startups are crowdstrike, carbon black, jamf, openvpn, umbrella, crashplan, munki, etc. Not mention the OS management configuration stuff like MDM profiles for macOS and active directory configurations for windows. A lot of brand name corps you might think are 'good guys' use this, like lyft or dropbox. Similarly with companies FANG, where it might custom software.
I think this is a super good tool, except for all the privacy implications.
We've always treaded carefully around privacy concerns as a project. This is why you don't see tables that access information such as browser history. If you join our Slack channels you will see open discussion of privacy implications for changes and improvements.
There's a balance to be struck between visibility and privacy. If a security team has no visibility into a system, they can't secure that system. This doesn't mean they need to be able to look at your family photos and read your messages.
I work with folks who care deeply about privacy and trust with their users. These folks ensure that osquery configurations are available to users, so that they can see what exactly is being monitored.
If you are curious what osquery can do, I encourage you to check out https://osquery.io/schema/4.3.0/.
The solution will be legal I think in the end, like in some european countries that don't let you do this kind of surveillance on your employees. And if you want to look at an employee's work emails, you do it in front of them with their lawyer present.
I'm glad you guys are trying to keep some semblance of privacy although.
There is definitely still friction in the entire process (ex send a link to an HN article to a friend that you saw in your work machine web browser) which induces a lot of people to just login directly on their work machines.
Since we are all WFH now I've been meaning to set up some sort of synergy setup so I can keep it really separated, but still have less friction in the 'share a link' scenario.
Slightly tangential to this thread, but isn't this also tacit admission that employees will be collectively less creative when working remotely.
But if the entire /job market/ goes remote and access to the net is a public commodity, then you can apply for all jobs /anywhere/. Employees bargaining power increases significantly. Furthermore, any employee can start his/her competing business in an instant.
As a side effect, wages can go down but if you don’t work in the bay area you can come out /better off/.
So it’s not clear if the downside is going to be related to worker’s rights. I am personally more worried on the societal / mental issues with WFH.
Here are some crucial steps we must take in defense:
- Make sure working with non-employees is legal: no non-disclosure agreements saying you can't work in coffee shop or other shared space because of potential of overhearing. This would be the best hope
- Towns or cheaper cities, not exurbs. People must know their neighbors better if they know their coworkers less. Time spent walking around the office must be replaced with time spent walking elsewhere.
- More Aggressive anti-trust. If labor becomes more balkanized, capital must also be.
- Workers on boards. Like Germany, if you grow past a certain size this needs to be mandated.
Notice the last two point to the two healthy solutions: decentralized small businesses economy vs giant co-op socialism. The point is to basically all institutions must score high enough on the sum decentralization or democracy, and that the total of the two is far more important then the relative merits of each.
Yes it's true that software in the future will be easier to write, but we will not be solving the same problems as today.
In the past (20 years ago), developing a TODO app was relatively difficult and could of been a valid startup idea. However today it's a trivial application to develop and is the equivalent of a "hello world" program.
The reality is; Writing software gets easier, While the problems software solves get harder...
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.
> 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.
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.
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.
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.
I think there’s actually a significant risk to Silicon Valley here, which is the following potential vicious cycle:
- Big Tech decides all/mostly remote is the future.
- Big Tech mostly stops hiring in the Bay Area because why pay more for talent when they no longer “have to.”
- The COVID reset layoffs continue, resulting in a lot of Bay Area engineers looking for work at the same time.
- 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).
- Engineers who can no longer command crazy salaries to justify the rent start leaving the area (this is also already happening).
- Rents start to drop, and the housing market softens a little.
- Tech workers who have relatively recently bought homes get nervous and look to exit before they get underwater on million+ dollar loans.
- The housing market softens further...
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.
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.
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.
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.
But whether no-code/less-code is inevitable, I think his first argument can still be substantiated from a different approach, at least in the near future: we're coming at the end of a tech bubble, the money will start receding, and organizations have already been realizing they don'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/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?
To some extent, yes, it's what'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't actually have tangible economic benefit to these organizations, and may have even led to worse outcomes due to unsustainable or reckless behavior.
Going back to the article, whether the first point can be explained by inevitable no-code/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:
> 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.
And the article'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.
This is an interesting point. Is this really happening though? Tech valuations pretty much bounced back up. Gut feeling says yes something is wrong with the current monetary system, and a bust cycle should be coming, but with the 0% interest rate and massive quantitative easing, maybe this can go on for longer than we think...
It certainly feels as if some bubble is getting burst, even if it's not the entire tech industry's.
[0] https://www.geekwire.com/2020/caution-ahead-startup-report-p...
And Uber did not write their own slack, they set up a mattermost instance and then put some logos on it. It's a bit more than complex running an exchange server in a corporation.
Most of the money burned by these companies was in the operations, marketing and incentive side, not on the engineering side.
My estimate at the end of this will be a second tech bubble, due to way more money being printed and given to bankers again, even lower interest rates and surprise surprise, software is one of the few things giving a return, yet again.
https://news.ycombinator.com/item?id=22809778
I'm not saying that engineering is necessarily the cost centers at these companies currently experiencing major layoffs (though the high salaries probably don't help), but it does call into question how much software being written is actually beneficial to these businesses, if they're able to shed engineers just like that.
Also software in many companies managing large complicated multibillion business are a bit of an iceberg. There is a lot of internal software that you are not exposed to as an end user customer. I call it the google search effect. Why so many servers and engineers for a 2 page website?!