> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.

On those complex systems in particular the problems start long before any code is written.

A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types.

For the first group code was never the hardest part. For the second group there was never any other part.

I would counter with it's easier to fix bugs, improve performance, pay down technical debt than it is to fix consensus, stakeholder buy-in, and strategic direction. So even though good code, design, and architecture isn't easy it's still the easy part in a relative sense.

Yup. And performance problems don't just bleed the user base, they also slow down development and testing internally, both directly and by nudging developers away from attempting some tests or use cases in the first place.

I can understand when people say the code was the way part, but under the assumption that the system design and architecture are clean, code is high quality or the project is greenfield, and there is proper testing and validation. Then, sure, the lines of code aren't the hardest but that's only because that hardest work was front loaded and given a different name. Even then it's still not always easy.

You've really seen a web software product die because of performance issues?

This is one of my theories why AI is well-suited for these kinds of projects. It's mostly CRUD, written in well-known patterns. This not to discount the programmer or the job in general, it's what the task calls for.

Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. Trying to make hardware go faster with more efficient code is much harder than optimizing an SQL query and safeguarding it, and these are well understood problems, in general.

It depends what you mean by enterprise project?

If you just mean a large company, I would say they absolutely exist - if you go looking for them. For me, these have included embedded systems for factories, UIs for specialist hardware, VR when that was a thing.

I would call my current project relatively systems-level too, as it's a network proxy. Not quite kernel level but definitely not trivial "if this then that" style coding. It does exist if you have the urge to find it.

My perspective is that application programming - CRUD, forms, IO orchestration - was always vulnerable, even before AI. Think about APIs for payments, APIs for subscriptions. E-commerce in a box type solutions.

That's why I always pushed to do more systems level work, on more exotic or weird technologies. It's not because I think I'm a better programmer, than someone slinging Spring code or React forms. But because in this industry it's better to be a goat than a cow.

Trading systems? Most complex things I've worked on.

[dead]

[dead]

> They imagine we spend 8 hours a day clacking at the keyboard.

I do, but the order of the keys makes a difference somewhat.

The percentages are different for different types of SWEs, not all SWEs spend 80% of their time on XFN comms. I agree with your larger point that a non-trivial amount of a SWE's time is spent on XFN comms and team alignment. My argument is that if an individual contributor is not spending a majority of their time on problem solving and implementation (including maintenance of legacy code), they are not maximizing their potential. If they are spending 80% of their time on non-coding activity they are better suited for an Manager role (Engineering or Product). At the end of the day, coding is not hard only if you are a good coder to begin with. If you are a good EM/PM then people issues will not be hard (which coders often complain about).

I feel like almost every standout product in the world was a result of someone with good instincts and not the results of XFN communication.

Unfortunately it is still the job...

The infra org has to also understand their internal customer!

Would add this is not exclusive to large corporations either. My smaller employer is also struggling hard because leadership simply cannot prioritize. Everything is either not being worked on or is the highest priority which in practice just means nothing is the priority, and no matter what myself and my team work on always seems to be the wrong thing.

It's absolutely devastating to team morale. We never feel like we're contributing.

A buggy big ball of mud that does mostly the right thing is still going to beat a high-quality, carefully architected solution that reliably does the wrong thing, though.

And for a huge amount of code, it's not very hard to make it good enough, because the requirements, once understood, are pretty straightforward and perfect correctness often matters much less than you would think.

I like Dave Farley's classification of Coders, Developers and Software Engineers.

https://www.youtube.com/watch?v=fcjBfSiyI0k

Sometime in the past 10-20 years there was a prestige shift where people started using the term "developer" for what you're describing as "programmer", relegating "programmer" to what you're describing as "coder", and "coder" to "hobbyist programmer/developer" (while weirdly "coding" remained colloquially the thing programmers do).

Advice to job seekers I remember in the 2010s was to not call yourself a programmer because that was where the bad "code monkey" jobs were, but it hadn't yet been much of a thing when I first started looking at the end of the 2000s.

> You can teach anyone the mechanics of coding well in like 6 months.

You can absolutely not do this

I've also been doing this professionally for about 30 years, plus another 10 as a hobby/learning before then, so I think I have much of the same experience as you, and I do agree. Although, I think with the advent of LLMs, programming is no longer the hard part. The hard part of programming is the convergence of context management for humans while also presenting it to a computer to do something. Much of data structures and algorithms "best practices" are ways to efficiently get your work done as well as keeping it so that a human has context.

For example, one guy I used to work with wrote this really awesome algorithm about 25 years ago, and I'm responsible for maintaining it since he long retired. I can't go into details, but this is the core algorithm in moving billions of dollars between institutions overnight. It's about 10 screenfuls of c that had been converted from the original FORTRAN 77 with dozens of gotos and weird branching statements and about 20 parallel arrays that store indices for pointer chasing. It's almost impossible for a human to follow (I've actually fed it to an LLM and said rewrite this with for loops and no gotos so I can understand it - and it worked!) but it's blindingly fast. The actual problem it solves can be stated in about three sentences, but programming it was hard because of the context management. The reason that my company keeps getting royalties on this is that it's so hard that they'd rather pay us than write it themselves. But I bet an LLM could write it from scratch now.

So maybe programming is no longer the hard part, or at least context management is no longer the hard part and that humans should move up the chain to help manage the context for LLMs so they can get more done efficiently.

Switching topics a little...much of what I think makes coding the hard part was the tension between big-design-up-front and you're-not-going-to-need-it philosophies. Early in my career I worked in health care and that was BDUF and the coding was easy because program managers spent years defining every screen that would be shown to the users, what queries were needed to fill the screen, all of that. We just took the spec and coded it. Coding was easy. But the failure of BDUF was that it still didn't really match what the customer wanted.

Then enter agile and YAGNI, in that limit, coding is easy, just write what the user story says. But then you have to refactor from what was left behind on yesterday's user story. So smart engineers would cheat a little with YAGNI and say, yes we will put an abstraction in because the next user story. I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill. And I think that's what all the wailing and gnashing of teeth is right now: the good engineers aren't needed anymore.

I can tell an LLM to code something, and as I add complexity it's happy to refactor and manage the context so we don't need to worry about "clean code" or "quality code". As long as what the LLM writes meets the spec, then we're happy.

Ah, sorry long rant and ramble. But I just think the "hard part" has been managing context, and the context we're managing context is just changing. Those good at managing context will be good at coding with LLMs, and those that weren't won't be.

the article means code as a whole not just the moment you input some if else in a screen but the whole act from thinking about it to make it live in prod.

I don't even sit in front of a computer to write programs, I do that in the car.

I type them in when I'm in front of the computer.

All the actual work though? That gets done in a space where there's no phone, no people walking up and talking to me, no distracting social media, no screens, just quiet-ish and a couple of hours to think.