Programmers Aren't Productive Anymore - Jonathan Blow

I feel like his argument is misplaced. It's like saying "back in the day, you could just take a few logs and build a house in one day". Yes, and that house wouldn't have plumbing, electricity, sewer. It wouldn't have good insulation from the outside. The roof would leak a bit when it rains, making it impossible to store certain types of possessions. But hey, you'd have a house in a day. And on the flipside, you can still make simple things with simple computers, and people are still doing it. Grab an Arduino, flash it with whatever you want, and you can write your own OS. What's that? Oh, you want more than 64K of space, the processor is slow, and there's limited support for interrupts and no way to play realtime video? Well, welcome to Unix 1.0. Standards have changed. Programmers are also less productive, but I feel like he's getting further away from the "why" by looking at requirements. Whole lot of people are chasing the money these days, coming out of two week bootcamps, instead of having an actual passion for writing code.

I don't agree that abstraction is to increase productivity at all, abstraction allows you to increase the complexity of a system. You can now package ideas and interface with them in a way that is human friendly meaning your brain can keep track of a lot of interacting components.

It's a mistake to divide the "new features" at Facebook by the number of programmers at Facebook - most of what they are doing is not producing features that benefit users, but rather features that make Facebook more money, which are not visible to users (on purpose).

The big elephant in the room is that nowadays even if you program in assembly you still don't know what the CPU is doing with all the register aliasing, speculative execution, muop fusion, out-of-order execution etc

All good causes that he lists, but the biggest cause is the much higher demands on software today. I'm a third generation software developer and have talked with my dad and granddad about these things. Back in the day most programs were simple. Now you need a sophisticated and user-friendly GUI, Server/client or peer-2-peer communication over some protocol, complex databases, security, scalability, metric collection, statistics presentation, sophisticated rollback, integrations with all kinds of third-party systems. Plus a sea of technologies/frameworks/libraries/tools to get anything done because building your own XML-parser from scratch is stupid, but now you have to master all these things, where before you simply didn't need any sophisticated parser. Also as technology has allowed it more and more legislation and bureaucracy imposed by the state has effected the processes around software-development and even worse the software itself (GDPR for example). To all this add that users often demand more advanced features today (it was very basic what the software my dad made in the 80's had to do). Further more there are more bad software-developers. Many think being a developer is about writing code (as in you just need to know one or more programming languages in depth). It is correct that you write code, but think of it as articulating solutions so to speak (like when you make a mathematical proof and articulate it in a mathematical notation), but what is hard is recognizing the problems and conceive the solutions (like math). And you can't think of a solution and make somebody else code it because coding and crushing problems happen in tandem. Also, passing a complete solution to another human being would be the same as writing the code yourself.

After messing around in TempleOS out of interest I do get where Jonathan is coming from.

Today to be "full stack" you have to be 50% of a dev ops engineer in many an organization, especially in start ups and small-ish companies. That greatly interferes with software development productivity. Also too often today a large percentage of your job as software developer is to manage the use of up to a dozen SaaS packages that the CTO decided would "save effort and cost" each with their own peculiar merits, demerits, behavior as APIs and whatever the heck was in the heads of their devs. Banging on these to make it more or less satisfy business requirements dependably and with reasonable performance is a full-time job often. That leaves little time to write or think of writing the actual software that would most efficiently meet the business needs.

I can't believe he didn't comment on the key thing Ken hintet at that allowed him to write the first unix kernel: Being left the F alone! Teams ruin productivity and creativity. The bigger teams, the less productivity. The tools we are handed are generally cripled with a hateful OS - and add to that all the crappy antivirus, "group policies", lack of admin rights, firewalls blocking you from downloading standard programmer tools, SDKs, etc. - all things that are actively slowing you down (or outright preventing you from doing your work which you then need to spend a lot of time circumventing.)

0:54 "That's how people are wrong a lot of the times, you start out being right, then you extrapolate it too far into wrong territory"

I think a lot of the "lost productivity" is actually being wasted due to tech companies becoming too big and the bureaucracy associated with it. It literally was the same with mechanical engineering companies before. Some people build a product in a small environment and once it becomes a global success a lot of additional people are needed to simply manage everything (also the technical side) and those people again need new processes with new internal stuff and so on. Additionally, a lot of "lost productivity" actually is not lost but being spent on scalability and usability. Simply looking at it from the number of features implemented per employee/time is pretty stupid when Facebook started out with a few thousand users that would post once per day compared to the millions of users and corporations that use Twitter nowadays with multiple messages and videos being posted daily. Apps and Websites have evolved a lot in terms of usability the majority of users are not interested anymore in spending hours on grey or black and white forum web pages that only support text with a terrible search function. Comparing the pure functionality of some Mercedes a decade after it was invented to one now is basically the same. Both cars drive and get you somewhere but the comfort/usability of the two products are something completely different.

How is using one specific genius like Ken Thomson who worked at the most state of the art computer R&D lab at the time, a valid example to describe a whole generation of programmers. Its like saying that people in the 1900s were the smartest generation ever because Albert Einstein published his relativity theory at that decade. Makes no sense.

some whacky arguments being done here, large companies are eaten by bureaucracy, maintenance and very specially: communication among them. People and teams don't scale. Large companies and products try to avoid feature creep as it adds more maintenance, and collides with previous existing features and structures.

I’m a senior engineer at a large tech company and most days all we do is circlejerk about patterns and refactoring code and never deliver anything. Everything is hilariously over complicated to the point where extremely basic stuff takes weeks to do.

Gotta love a Jonny Blow take; big claims with no evidence but a lot of confidence

There is one thing we should keep in mind with the comparison of "number of developers employed" vs. "tangible developer efforts" at the big tech companies. They aren't necessarily hiring for productivity, I think. That hiring is, at least in part, driven by the need for infinite growth. They have to show that they're always growing to "make line go up." Later, they'll prune the developers they didn't actually need in the first place to show "fiscal responsibility" which will "make line go up." Still later, they'll overhire to "make line go up" again, etc.

"I know what we need to do to get back to the days where we could write an operating system in 7 days!" says the guy who takes 7+ years to deliver each game.

The majority of software and features that is built is never used. Just requests by managers, then when the software or features is ready 3 months later, those managers are onto something else, the business case for the software doesn't make sense etc. There are about 2.7 million apps for android, about 1.000 apps per day. Yeah right.

The reason programmers are "afraid of pointers" is that raw pointer arithmetic leads to a massive amount of bugs, in turn leading to applications in production going haywire in de most unpredictable ways. Also, programmers to do low-level programming well they need lots of time to concentrate at the issues at hand ... which is pretty much an impossibility in this day and age of DevOps and Agile.

The reason people were able to just create an OS in a few days is there were no standards. You complain that there's a shitton of different Shader languages? Besides vendor lock-in, which will likely attribute for some of it, the reason is that people went at it with your perspective. Why spend time trying to establish a standard, when we can just make stuff up ourselfes. The reason OS's complicate deploying Programms is because they allow one to use more than one program at the same time, and that requires coordination of shared resources. Yeah, if you'd write it from ground up PERHAPS (depending on what you're doing, probably not most of the time) you'd be quicker, but you won't be able to run that while also browsing on the same machine, and every program would have its own idiosyncraties that users would have to get used to.

Lisp is one of the most abstract languages around. At Symbolics, a company that sold Lisp-based hardware and software solutions, a VP once claimed their ambition was to make all but the largest of software projects achievable by a single developer. (Small teams would tackle the largest projects.) And it looked like they would be abke to do that. Small teams built Genera, the Lisp OS, their document management system, their expert system solver, and their suite of 2D/3D graphics tools that were the rival of anything produced by Pixar at the time. But large companies like large teams -- to a middle manager, a large team means a large budget and a large subordinate count they get to command -- and so as the capabilities of small teams grow, that extra productivity is taken away by the introduction of processes and methodologies designed to slow small teams down and necessitate large teams with large management infrastructures.