I believe there are some programming jobs in which the code is absolutely the easier part. Not all of us work in signal processing, integrated systems or have to push upstream to Linux kernel because the company we work for really needs a memory allocation optimization for its data centers.
Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.
There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
IDK, 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. Those performance problems start out not mattering much, first it impacts one seldom-used part of the site, then another, but that chips away at users and can eventually tank the product. That doesn't even get into writing code such that it can be well-understood and modified easily later. It also says nothing about reducing/fixing bugs.
If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.
All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.
> 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.
No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software.
Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc.
The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road.
The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.
Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete.
> Code is a form of low-level design and is where the rubber hits the road.
Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to change one if you picked the wrong compound. It takes years to properly design a tire, not to speak of everything that sits on top of those tires. By the time you actually "meet the road" you already defined to a tee what you want to achieve from every perspective and everything you do is to meet that goal, even if you have to make tweaks. You don't find out if it's a scooter or a roadster tire while working on it.
> The best requirements, designs, marketing, etc are worth jack if one fucks up the code.
Why are you mixing some fundamental things which are essential and can't be changed along the way without massive effort and risk, if at all, with things like marketing?
Do you want to aimlessly write code while chasing a target that moves randomly and conflicting because your plan was to define things "at some point"? You're really making my point with your insistence that it's all about code and every other fundamental thing is "a detail" that just comes along the way.
No part of your list was just a detail, but all parts of the list consist of essential properties and details. As I said, many of those details will fall into place when one starts implementing the core architecture.
It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.
To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.
Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.
To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.
Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation.
Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch <-> dev feedback loop is one of the best methods I know to tackle that.
To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.
Your comment brings ripgrep to mind. Grep is about as ubiquitous a software tool as you can get with a very clear contract on input-output and it has absolutely stood the test of time. Then ripgrep comes along, it has the same contract as grep (with I think a few inconsistencies that were intentionally tweaked for modern use-cases...and also I'm sure a few edge-cases from its design), but is significantly faster. The fundamental contract with the user stayed the same, I'm sure some of the design changed, but fundamentally the only difference is the underlying code. And that makes such a big difference that I *always* use ripgrep over grep now as do many others.
That's just one half of it: Intelligent defaults + configurability of what files/dirs to skip. That part has been iterated on in prior tools like `ack` and `ag` and `git grep` for like a decade, and ripgrep was informed by that tradition.
The other part is extreme optimizations, from I/O and OS aspects to CPU, both asymptotic complexity (from scratch NFA regex engine), concrete complexity (rust, SIMD) and ad-hoc opitimizations for statistically common uses like fixed strings...
Then there are some "product" choices driven by performance insights, e.g. no line numbering, defaulting to non-deterministic unsorted output order — these go against most programmers' intuition for "ideal tool I'd like", but turns out the speed gains are significant and what I really like is how fast it is :-)
Both usability & optimizations are described in depth by the author in https://burntsushi.net/ripgrep/, which is one of the best perf. readings ever, highly recommended.
In my experience, the parent's view and your view are an example of the divide between the Silicon Valley / startup mindset -- it doesn't need to last, it just needs to get us a paycheck so we can go on to the next paycheck -- and actual software engineering where people build resilient systems meant for humans to use for a long time.
There's a conflation too that to approach things with this level of thought and care requires waterfall design (it doesn't), so people shrug it off or resist because if you want to think carefully and design thoughtfully you can't also Move Fast and Break Things.
Ironically, we all complain about enshittification.
I don’t think anybody except those working with e.g. DO-178B or ISO26262 does BDUF.
Iterative processes are state of the art. The RUP iterative lifecycle illustrates this nicely, with a big chunk of design in inception (first project phase), but also a non-trivial amount of implementation. The design & implementation flow in parallel in the next phases.
> Because if you ever go back a step, it is no longer the waterfall model
By this definition there has never been a waterfall project. They all need to correct, adapt, or redo something.
Look, I think I get your point but you seem too stuck in some formal definition riveted with assumptions to understand the other side. If you build a house you can correct some things after the fact. You forgot a power outlet or a light fixture? You need to move or resize a window? Probably fine and even decently low effort. You realize your foundation is too thin or too small? You forgot about one room? You put the bathroom on the wrong side of the house? Not so fine and definitely not low effort.
The state of software development is so bad because so many devs just jump head first into writing code and in the end they deliver a pile of barely held together shiny bits that technically works but is a pain to modify, extend, maintain, secure, extract the expected performance, etc. All because there are 100 brick layers and not one architect or engineer on the team.
I think most people who write code are the latter and not the former. The industry has diluted the term "engineer" so much that they maybe don't even realise that traditional engineering projects are about more than just implementation work.
Each unit of work in any given feature of a Web app has been implemented 500 times yesterday alone, and nearly each time exactly the same way. I mean that’s what programming basically is right? I’m surprised these patterns that are repeated so often by developers could have been/still be automated away even without AI/LLMs.
One thing I wonder about is how applicable your statement about web apps is to something like lamps or lighting generally. How many electrical engineers have re-designed a circuit that turns on/off a light? Are EEs who wind up doing mundane engineering like this still engineers?
You don't need to be an "Electrical Engineer" to do simple design work like this.
Professional Engineers are qualified to take on more liability than just creating a design. So you don't need an Engineer to design a product, but (depending on jurisdiction) you will need an engineer to certify that your product won't hurt or kill people.
If you do a lot of design work, then you may want to hire a Professional Engineer in-house so that your company has more confidence that they will produce compliant designs with fewer iterations.
Engineers are often the best people to work with if you need to do things that are done infrequently since theoretically, they're trained in the prerequisite first principles so they can make judgments that are rooted in rigorous analysis in addition to their practical experience.
"electrical engineers" aren't usually the ones making a lamp though. If you're paying EE wages to add a light switch to an Edison socket you're massively overpaying.
Lots of things have lights on them though. I'm thinking every status light on every piece of hardware.
Edit: also, I'm not exactly filled with knowledge on new lamp design/construction, but I have seen startups/kickstarters that make new lamps that seem like redesigns from the ground up.
Aerospace engineers who build rockets do not have some certification body allowing them to be called engineers. Same with most electrical engineers working on almost everything.
If you think a government deciding who is an engineer is a *good* thing then maybe you should ask yourself why the United States which doesn't require this for the two non-software engineering disciplines has the best engineers in the world.
Really? What evidence do you have for that? Are you saying that companies like Airbus, Mercedes-Benz, Ferrari, ASML, Leonardo, Rolls-Royce, Dassault Aviation, Toyota, Bosch, Komatsu, Siemens, ABB, Mitsubishi Heavy Industries, Alstom, Vestas, Samsung, Sony, Hyundai Heavy Industries, Mitsubishi Shipbuilding etc. don't have world class engineers?
The United States has the best engineers because it pays the best. Good engineers from other places move here to capture some of that. Obviously strict licensing laws would get in the way of that.
Outside of some exceptions which don't really exist in the US (shipbuilding and heavy forging) the American companies in those industries are highly competitive and often market share leaders.
Annoyingly, the US government still sometimes does.
If you want to take the patent agent exam, your CS degree has to come from an ABET-accredited program, though many of the very good ones aren't (Stanford, CMU).
Likewise, federal jobs also sometimes seem to want accreditation but not always.
You can call yourself engineer if you feel like it, however in case it comes to some court case due to liabilities and such, there might be some issues coming up with having Eng in that contract signature.
Many here would probably say that they have never did the exam, and nonetheless use the title, which is as mentioned, not an issue as long as you don't land in court and the validation of title doesn't come up.
Also in most European countries, being an Engineer even if not professionally qualified, automatically means that the person in question took a university degree in engineering, on an university whose engineering degree was certified as such by the government organisation responsible for all engineering professions.
If you can call yourself an Engineer if you feel like it, then it's not a protected title.
"Doctor", is for instance a protected title. You can not advertise yourself or your services as a doctor unless you're a qualified and practicing medical professional. I believe some kinds of legal practices are the same.
[MIGHT HAVE INACCURATE IMPLICATIONS BUT PRESERVED FOR POSTERITY:]
In Germany I don't think that counts. "Software Engineering" as a title isn't regulated (as kcexn is asking for). The German term "Softwareentwickler" more literally translates to "Software Developer" (as opposed to "Ingenieur") but I don't see companies having problems translating that in job posts and even contracts to "Software Engineer". I've never seen "Softwareingenieur" used tbf.
Getting into Germany as a Software Engineer (for app development) is also as relatively frictionless as it gets in comparison to more-traditional engineering fields.
Verdi is the German trade union so they have to make these kinds of distinctions about which professions they can represent. Don't quote me on this one but I think Verdi represents very little of the modern "app development" software engineers. I guess those who work for more traditional German industries like auto-manufacturing can fall under their umbrella.
---
[LESS INACCURATE EDIT AND MY THOUGHTS IN LESS WORDS:]
In Germany "Ingenieur" (Engineer) is a loaded term with legal implications so "Software Engineer" is "Softwareentiwickler" (Software Developer) instead. But really this is an HR sleight-of-hand trick. At the end of the day, getting into professional Softwareentwicklung is the same in Germany as in elsewhere that calls it "Software Engineering" (and IMO is what kcexn was asking about anyway).
Well, I have been well served by I.G. Metal, by working in industries they also covered.
Also I have yet to meet anyone doing agency work, that started as Azubi, Quereinsteiger, BWL,... and would sign any document or call themselves Engineers, like it is so very common in US out of a plain bootcamp.
I don't think Software Engineers in the US would sign any documents that expose them to legal liability as a professional engineer either.
It's still not clear to me from this discussion whether the term "Software Engineer" is legally protected in Germany (or any other European country) or if it's just a cultural convention.
The distinction is basically, if a software developer started a consultancy developing custom software solutions and called the company XY Software Engineering, would they be penalized for false advertising if they didn't have professional engineering qualifications?
Your mobile phone runs on a CPU architecture designed in Europe (ARM), manufactured by a machine that only a European company can make (ASML), using a number of protocols invented in Europe (Bluetooth for example), using protocols invented in Europe to browse the internet (HTML/HTTP), based on a very long history of computer science ideas and programming languages invented in Europe or by Europeans.
Give credit where credit is do.
Having said that, I do agree that US companies tend to be better at commercializing new ideas than European ones.
For sure there are great engineers that are from Europe, I've worked with a bunch in the US, but it's a numbers game, and there's no competition there. Partly because so many of those great European engineers come here.
It's an ARM CPU - ARM is built off Berkeley RISC. ASML would never exist if not for billions of dollars of R&D spending by American chip manufacturers, much of which was directly provided.
Obviously there are good engineers in Europe. There just aren't as many as there are in the US, in large part because the US encourages immigration with much higher salaries.
It is correct that a lot of talented Europeans get educated in Europe and then immigrate to the US starting successful companies. Without those Europeans, there would be a lot fewer successful US companies.
American rules, if you start a billion dollar company in the States you're one of us :)
On a more serious note, the US awards more college degrees per capita than most other developed nations. Strict licensing requirements or not, software engineering is just what it's called here because of the many and obvious similarities between it and other kinds of engineering.
The English term "software engineer" is not a protected title anywhere, FAFAIK. However, the local language equivalent of "engineer" is protected pretty much everywhere in Europe because it was awarded solely at technical colleges and universities. The title is (mostly) equivalent to a Master of Science degree, except that technical colleges could also award it (the English equivalent being Master without field designation).
Before I retired (in the US) the organization I worked for was heavily civil engineering oriented, and they were pretty insistent that the computer folks not call themselves engineers. The state licensing board was pretty insistent too.
I was also in a consulting CE firm working in software, but had moved from an engineering position and had an engineering undergrad degree. I was strongly encouraged to get my PE so the company could advertise it, even though the PE credentials had nothing to do with software development.
I think civil engineering is the main field in the US that relies on certifications/tests for FE/PE, there's probably more I'm unaware of though.
As I pointed out above though, aerospace engineers (working on rockets/space applications anyway, IDK about planes) and electrical engineers don't need those tests. Requiring it for CEs seems like a historical artifact more than anything.
> In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?
I think a better question is: what is the criteria those countries use to determine if someone can use the engineer title?
In general the software industry is still in an early confused state about standards, approaches, skills, etc.
Should we be using functional techniques? Object? Both? Relational? Column store? Push? Pull? etc.
The number of ways to build a working system is enormous and we have a fad-of-the-month every 5 years which starts as a silver bullet and always settles down to be just another option for another set of use cases.
The European Council of Engineers Chambers is seeking to standardise training programmes, beginning with the civil engineering sector: https://www.ecec.net/what-we-do/common-training-framework/.
Hopefully, this convergence will extend to other engineering professions.
I agree that all those pieces are important, for sure. But it can all be undercut by a few for-loops that don't consider string re-allocations. That covers the "don't understand good code in the slightest, make big mistakes" side of things, but the other side is being able to think about the algorithm that is being run in your system (sometimes across multiple layers of code) and writing code that eeks out the highest performance from the system you're on in the programming language you're using. Also, to be clear, "the algorithm" here doesn't have to be super complicated or theoretical it can be as straightforward as assembling some data structure in response to a user's query across a few different sources. That process requires being able to write good code.
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.
I did not mean to imply that consensus, stakeholder buy-in, and strategic direction are easy, or even that they are easier than writing good code. My point is just that the code part is not easy either. I think the article's point that "if good code was easy, we'd have amazing software everywhere instead of crappy software everywhere" is a very good one. The average code that gets written is horrendous, interviewing people who are presently employed and struggle to write a for-loop makes this really apparent.
A lot of those performance issues in enterprise systems are platform specific to begin with. I’ve never seen what I’d call a high performance ERP, even when on the cloud. It’s usually poorly documented. It’s unclear when a pick list passes QA today well, but in a year with the list exceeds X items, the whole application crashes or grinds under the weight. A lot of time these things are learned via scar tissue and could have been easily prevented if better standards or documentation was in place.
I’ve used a lot of Oracle ERP products and I always comment about how poorly their queries run for a database company. It used to be thought it was a hardware issue and they’d sell you accelerator licenses, but now that I see more and more I’m convinced they just don’t care about performance. They want it to slow down so they can sell you more. That, and the feeling that when you build a platform for all, you’re building a solution for none. Meaning, it’s such generic and customization heavy they can always point back at you and say it’s your implementation that’s problematic not our platform. Sometimes that’s true, but also when I pay what I pay, I should get better performance irrespective of how I implemented it. I run a simple query often that’s basically selects all the accounts numbers and names from my chart of accounts (accounting), this is a central and core part of the ERP, why does this query take 45 seconds to return 200 rows of 2 columns wide.
Fixing bugs, improving performance, paying down technical debt all require this as well, which makes them significantly more difficult to actually implement.
That’s because fundamentally you need those strategic items to have space to do those particular detail items. If you have the best strategy and no execution, you can probably hire for that. If you have no strategy and decent execution, you are driving the Titanic into the iceberg.
> IDK, 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.
I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement.
In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways.
There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.
I am quite plainly talking about writing code that runs efficiently to support a wide-variety of tasks. To do that, one needs to write code that runs fast on your targeted platforms and is extensible/easy-to-modify (not necessarily the same thing to be clear).
We may have different definitions of "architecture" though, I tend to think of "architecture" at the system level, i.e. "this service handles these responsibilities, this other one handles these, they communicate with this interface/contract, etc". I can see how you could take the term "architecture" down to a lower level where you talk about classes/files passing information between each other too. I think to do that sort of lower-level architecture well though you basically need to write code in your design, even if it's just pseudocode.
> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing
Yes, and absolutely nobody will care if it does the thing it was meant to do. Performance is near always an afterthought because there is no single team that gets judged on performance.
I think we often don't realize how much performance is part of the user requirements (i.e., "the thing it was meant to do") because users don't specify that as a requirement. And when they do we get all engineer-y about it and start asking about TTFBs, throughput rates, TPS's and nobody gets anything sensible out of the conversation. But users don't mention it because they don't know how slow complex systems could be or how complex a mere CMS could be that for them this is one of those requirements that don't even need to be said.
Anecdata time...
There was once a scrappy start-up who, like all scrappy start-ups, was taking on the heavyweight incumbent gorilla of the industry. They started poaching the small customers from the gorilla, just enough for the gorilla to notice. These customers often cited how "fast and lightweight" the start-up's platform was compared to the gorilla.
The claim wasn't really supported by Grafana. The numbers weren't bad; in fact they were very average. For some metrics, the gorilla was actually still the gold standard the scrappy start-up targeted. The engineers suspected "fast and lightweight" had more to do with the user experience (they had smoothly-animated loading screens) than actual server performance. Still, it's not a complaint so they took that as a win.
After a couple of years of steady growth poaching from the gorilla, they started getting bug reports of slow performance. The customers have been seeing more and more of the smooth loading screen animations and less of the data they actually need to work on. And this time, the claims were supported by Grafana! There was no way to massage the statistics to even claim the reports are outliers or to pass the blame on to the unreliable ISPs.
The problem, it turns out, was that they were sending emails as notifications for a bunch of user actions and at that point there were about 2-3 such user actions per minute. While they could async some of those, there were a bunch whose succeeding states assumed that the notifications have been sent.
After three weeks of profiling and going through the whole performance optimization playbook, the fix boiled down to a one-liner in SQLAlchemy that offloaded loading notification mailing lists to Postgres cursors rather than loading whole lists into memory in one go.
Moral of the story: no one is asking you to build a racecar but that doesn't mean performance is not table stakes. A good senior engineer knows just where the balance is to still deliver business value. That is the salary you are paying for.
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'm not american, and didn't follow that one deeply, but presumably that's not just "due to bad req. gathering", it's also due to the structure of gov procurement? E.g. it wasn't the pained users who approve the payment to the contractors, right?
You could counter "if only performance was legally included in the contracts, a better site would be delivered."
Maybe, but my point is there is big difference between internal "req. gathering" that informs work while everyone is long-term motivated for good user experience anyway, vs. external contract/deadline gathering for almost adversarial "deliver worst thing that passes and walk away" settings. Brushing both under same wording feels insufficient to me.
Web software I don't know but there are many "modern software" that were meant to replace COBOL code running on AS400 that ended up never making it to production because they were running so badly and projects ended up being money pits.
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.
Getting to a state where those assumptions are true is HARD. And takes a lot of careful programming.
Yes. Once it is true, the code is easy to write. But only because a lot of effort went into making it easy. And keeping it easy is also hard. Without focused effort to keep the code clean and easy to modify, it starts to rot.
I'm yet to work on an enterprise project where programming is beyond simple validation, simple SQL, simple sheduling, simple mapping, simple error handling. Might be more about web backend than the whole field, but the challenge always comes from formulating requirements in a rigid form with all edge cases considered.
This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.
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.
> 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.
I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure.
But for standard low latency (think microsecond hotpath, rather than nanos) the techniques are well known and easily codified with example code and AGENTS.md rules.
You can achieve very good results this way, and then further refine with human intervention and measuring. Measuring and iterating is often the hard part.
I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.
> I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.
This is not magic, this is true, but it's deep and very niche knowledge. Let me give an example from my Ph.D., where I did some low level, high performance programming in Boundary Element Method space.
The knowledge is not novel, but the formulae is. We developed the math, not optimized something already out there. Moreover, we had to optimize to the hardware architecture we had. This means tons of runs, profiles, optimizations, and even more runs.
There are some bottlenecks here. You can't make profiling faster since you're already going flat out. Memory bandwidth, processor's internal pipelines, load and store units are completely saturated. Perf returns numbers close to theoretical maximums, the systems are running at TDP limits, you're done. AI can't make it faster.
Developing the math, chopping the formula and sprinkling at different levels of the loop to minimize step count to use what you have at hand becomes important. You also check modeling accuracy here, testing around 32 significant digits precision, again takes time.
If you're changing processor architectures, load/store widths change; pipelining behavior change, memory bandwidth per core, NUMA structure change. You have to fine tune here and there to get the same efficiency from a different core.
So, method is not the bottleneck, but the novelty of the problem and method and runtime is. When testing engineering stuff precision and accuracy both matters, and seeing tradeoffs take time.
When there's nothing to draw from, maybe AI can point out blaring issues, but without running the code and seeing it for yourself, you can't reach to the point where you need to go.
For the "codification of it" part, humans have something called intuition which is a kind of tacit knowledge which shows us the way based on a wide network of knowledge. It's not easy to surface, define, codify and transfer. That knowledge esp. helps when systems act contrary to guesswork and rules break in myriad of ways. "Having a feeling of the machine" is only possible with experience, and can't be codified and transferred easily. This is why we have master/apprentice model and why it's so important in transferring knowledge.
> I think 99.999% of all coding/engineering is not like this example though.
No, it's certainly not. Even for really high-utilty personal projects, what you do, esp. when you compare to the previous example, is extremely simple. Some parsing here, some SQL there, a HTTP POST somewhere else.
Unless you're rendering something, developing a custom, binary file format, talking with the hardware, or doing something extreme like I have given in the example, most programming is very similar. Re-organizations of the very same building blocks.
Yep, LLMs excel here because most of the time analogous solution is already in the codebase. Most of my initial promtps include "look how it's done in X and do the same".
If you just mean a large company, I would say they do exist - though it may take some looking for them.
You can find them in companies that have to deal with "real" things (hardware, factories, production lines), or where there is an interest in taking advantage of emerging technology (advertising, e-commerce)
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.
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.
I don't know it either, but I read it as:
- 'goat' referring to both the 'greatest of all time' as in specialized and at the same time to it being a not-so-common animal,
- while 'cow' is simply just a common animal, so in this context it represents a plain worker.
I'm not aware of any 'cow' acronym, that would directly relate to work/proficiency as the 'goat' does but it would further enhance the meaning behind the quoted phrase.
In fact it's exactly what is missing, for the phrase to be instantly understandable by making it symmetric in both direct and acronymic reading.
So is there a 'cow' acronym, that is an antonym to 'goat'? I'm not aware of one.
Cows are the most common animal on the farm, and overall they produce the most value. But they are very replaceable. When times are bad, you slaughter them.
Cows are like your rank-and-file application developers: you scale them up and down with the times.
Goats are more niche. You don't have many of them on your farm. But they solve important problems (eating weeds), and they look after themselves, so you seldom slaughter goats.
Goats are like specialists in your company. People who know how the "real" things operate. You don't need many of them. But they are involved in enough critical things, niches that can't be scaled down, that you seldom lay them off
Maybe in Western culture, but a lot of cultures (Middle Eastern and Indian for example) really like goat meat and even raise them specifically for that.
I've been programming for 30 years and "Code was never the hard part" does not offend me. It's something i've been saying for a long time. You can teach anyone the mechanics of coding well in like 6 months.
Programming is the hard part! I want to make this distinction because to me programming is about solving problems and coding is a way to express the solution.
Designing algorithms, architectures, etc can be done without a programming language. Coding is putting it down into some language.
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.
The same thing happened in the 80's when people stopped using "Computerization" and labeled it "Information Technology", which is a misnomer, in my opinion, because computerization doesn't just involve information technology, it also involves human factors - which were stripped from the field in the labelling, because of the collective assumption that people who computerized were incapable of humanization - i.e. "nerds are not people-people, which is why they can only deal with computers."
But it's a fallacy. Computers mean nothing without humans. Software is 100% a social activity. Break this rule and your software will suck and eventually fail.
These waves where someone found a new way to focus on the valuable part and leave the grunt work to lowly others comes again and again. As always the truth remains that each step in the process is relatively trivial and is is the overall complexity e2e and scale and handling edge cases that are where value is created. But that won‘t stop groups trying to differentiate themselves by looking down on others even when it is clearly failing. As long as there is a benefit to the group driving it.
Especially writing code has rarely been very hard the past 10 years. It was always reading existing code and understanding its implications that was the hard part, and understanding how to adapt new requirements together with the existing ones.
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.
This is a very good comment, one of the best i've read here.
> I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill.
i think this is spot on and could be where the concept of "llm's have no taste" comes from. There is art (and science) in determining the right level of abstraction that satisfies the user story in a performant way while leaving the door open for extension.
> As long as what the LLM writes meets the spec, then we're happy.
going back to just meeting the spec vs the art of perfect abstraction is a bitter pill to swallow and I imagine removes a lot of the joy some found in software development.
I said this in another comment a few weeks back - but, at least for me the "joy" of software development was describing what I wanted and getting it. That used to mean fighting with code and trying to be clever and clean or following the right design pattern. But now, I get "joy" from using English to describe my problem and getting the right answer. When the LLM one-shots it, I get the feedback that I'm describing things correctly and clearly. I'm still getting the same joy just in a different form now. I'm old enough and have been doing this long enough that "giving up writing code" is not sad for me. I'm still expressing my ideas, just differently now.
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.
I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing back, managing up, collaborations, etc) and then plan out the actual coding (gather code pointers, look at past code, plan architecture, talk to the team). The last 10% is the coding. And then the other 10% is the maintenance of that and past code (which honestly should be a lot more but incentives are not aligned well).
It's hard for people to understand jobs they don't do. They imagine we spend 8 hours a day clacking at the keyboard.
> I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing back, managing up, collaborations, etc) and then plan out the actual coding (gather code pointers, look at past code, plan architecture, talk to the team). The last 10% is the coding. And then the other 10% is the maintenance of that and past code (which honestly should be a lot more but incentives are not aligned well).
That last 10% is the value-add. If you aren't doing that, the other 90% can be done by pretty much anyone, and they won't be "SWE", they'd be minimum-paid white-collar workers.
A lot of people miss this in their haste to rationalise their evaporating value - "I'm still useful, because AI is only doing that 10%, I am still needed for the other 90%", not realising that if they aren't needed for that last 10%, they are interchangeable with the office receptionist :-/
This logic makes no sense. If 90% of a software engineers job is not coding, then the valuable part of their job isn’t coding. It’s the other things. Else junior devs or interns would be doing all that work.
So no, they aren’t interchangeable with the office receptionist, else the office receptionist would already be doing that job.
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'm talking from the perspective of working in big tech. Working in a fast paced startup, percentages are definitely different. But alignment/deciding where to spend resources is more important than coding especially the higher you go, the more resources at your disposal (staff+ eng). Junior eng again different percentages.
I have been writing code professionally for almost 20 years, hard or at least non trivial problems what many would consider, and my job description does not resemble the tiniest of what you're describing. Coding _is_ difficult and dedicating only 10% of your time for that task will leave you very quickly without the job. Most of the time not only that you spend close to 100% of the time doing the coding part but even more than 100%. Some problems and domains are just difficult and not trivial to the part you can automate them. With the age of AI this may be changing though.
> There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, [...]
Why would they cover programming? That's what all the books on programming are for.
Also I see no need for signal processing to make programming a hard problem. Writing correct code is hard. Writing code that makes incorrect code easy to spot and hard to write is hard.
You can be great at local maximums, communication, establishing support for executing a plan or creating alignment on big efforts, and proceeded to still create a ball of mud. Bug ridden, hard to read, hard to debug.
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.
"carefully architected solution" is not what they are saying. A "buggy big ball of mud" will not generally "do the right thing", if it did, it would not be a "buggy big ball of mud". Straightforward requirements do not imply straightforward solutions. In the early 2000s Facebook wanted a quick way to search for friends updates, a straightforward requirement. Turned out they had to build a full graph DB inside MySQL, not straightforward code at all.
Mostly this. The phrase "code was the never the hard part" touches on a larger culture war. I was I was moving up in the ranksit was common to see people, both myself and then watching others, say things like "I just want to code".
Coding was the job. But there were diminishing returns in that getting better at coding wasn't as impactful as getting better at all the social skills, big picture strategy, and general scheming.
Maybe "code was never the hard part" should be replaced with "coding wasn't the most important part". But I think we all know what it means. Those higher level skills are the things that LLMs can't do, at least for now. Coding? It can do that, at least sort of.
It's exactly this - "coding was never the hard part" translates more directly to "coding was never was slowing me down". It's nailing down requirements, it's cross-functional team meetings, it's planning the testing and rollout, it's integrating with all the other parts of the product and systems, etc etc etc. Optimizing coding was just aiming at the fastest part of the job already.
> Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.
The really hard part of this does in my opinion not so much lie in the aspects that you describe, but rather in doing this without leaving scorched earth with most/all of the stakeholders involved.
In other words:
Doing what you described is in my opinion something that can be learned, and in my opinion a central reason why many programmers consider this to be difficult is that they never learned it, and/or (related to this) were never given the opportunity to be responsible for all of this, so they lack experience.
On the other hand, navigating the whole office politics, and running the political gauntlet that is collateral to it is hell on earth. The only way to survive this is to give a big "fuck you" to everyone, which I more politely described with "leaving scorched earth with most/all the stakeholders involved" above.
About halfway through my career, I spent about 10 years working in the enterprise SaaS/PaaS space. 6 as a developer, ~4 as a product manager. Both sides of that coin are difficult. Trying to create a product strategy that meets the needs of hundreds of large companies is a special kind of hell. And on the dev side, even "simple" things are not simple when they have to be implemented at scale, software updates cannot break existing customer code/configurations, and customers must have a hundreds knobs and dials and scripted escape hatches to implement their own business logic.
Even when code was not the hardest problem, it was still a hard problem.
A big problem with online discourse about programming if that so many people are in bubbles that they think are normal and think that anything outside of their experience is niche and rare.
‘Enterprise’ software includes SaaS, internal LoB software, integration work, and a bunch of other things I can’t name. The LoB and integration work is usually boring from a technical point of view, so articles don’t get written as much, and they likely wouldn’t do as well on HN, compared to something highly technical about scaling something to serve millions of users. There’s probably many more hours of work, and more programmers, doing LoB and integration, but people in a SaaS bubble don’t see what happens elsewhere.
yea, a lot of my prior work was in the "code is the easy part" I was a frontend engineer for years. And something like 90% of my job the code was not the hard part.
I loved writing GPU shaders or optimizing visualization performance, but most of the time it was wiring up netcode to UI elements that exist.
Ironically as I've moved into focusing on more GPU and kernel programming AI is now lapping me there anyway, however the impact of knowing what sort of algorithsm are state of the art in papers, what is causing memory bandwidth issues etc... does a lot to drive the machine.
IDK, I worked like in ~20 enterprises and I didn't really see what you describe.
"Navigating customer requirements" is mostly everyone speculating on customer needs and pushing the part they own, and whoever happens to get closer to the higher management's ear, wins. Then market decides if that's is a good thing or bad thing. If it's good, normally the person who pushed this doesn't even receive credit for it, because either the command chain too long or the stakeholder's memory too short and postfactum everyone pretends they authored good decisions and opposed bad ones.
It might be tiresome and exhausting, like all intense politics, but it's not hard in any technical sense. Most mediocre people can do it and do it.
For something to be hard and complex you need rules and professionals on all levels who understand and follow the rules and driven by meritocracy alone. That's simply never the case.
Yesterday I was working on some video editing tools to create a demo from screen recordings. I started with Gifox, recorded a 5 min video and then started cutting it in their UI (small things like remove these 5 seconds from here, etc). Everytime I performed an action, the spinner would start and take 10-30 seconds to complete. This was on a 36gb M3 mbp with almost nothing else running. It got so unusable and it slowed down my machine so much that I had to force kill the app, and that did nto work, I had to restart the machine.
Then I tried in iMovie. I tried importing the raw gifs. It would hang everytime and I had to restart it. So I had to export .mov directly from Gifox.
It worked great on iMovie, until I needed to speed up or slow down some clips. I noticed on the first operation, it would spin for about 3s, on the second, 5s, on the third, 10s, and by the 6th operation it would either spin for 1min or not stop at all. The machine started getting flow, iMovie was using 22.4gb of my 36gb machine. Had to also force quit iMovie several times. A task that should have taken 30-60min tops, took 5h.
Memory was definitely leaking somewhere, and in different application with completely different engineering budgets. The product was there, people were paying for it, the software was not delivering, which means it was costing customers time and money, meaning people were overpaying for it. This is not a thing product can solve. Programming is absolutelly the hardest part sometimes.
You could say throw more AI at it, and MSFT tried, how's that going for them with all the weird product decisions and bugs and apologies?
> Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve
True. And there is another angle: ownership. The author also said “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”. This is like saying that a programming language designer does not own the spec of the language itself but just wants to write hte compiler. I find such altitude counterproductive. Case in point, many companies hire PMs for their internal infra org. I mean, shouldn't the engineers in the infra org know exactly what they design to build? If you don't want to own what to build, you end up letting someone else tell you what to do, except that the person is neither an expert nor even your user.
And that should be the engineers' job instead of outsourcing it to PMs who do not even use any of the infra services -- I'm not insulting the PMs, of course, but to state a fact. Infra is used to serve the internal engineering teams, and the PMs don't code, so they don't have a need to use the infra.
This take is foolish and will always be foolish. Coding was mever easy in ANY domain (not just low level stuff) and the fact that we built syntax highlighting, high-level languages, auto-conplete, static analysis, debuggers, etc., in order to make it easier is the proof.
Take a step into the business side of software. Code is definitely not the hard part. You wouldn't say wood is hard part (heh) of wood working. It is planning and architecting. When to use the right tools. Just because a ruler has hash marks that doesn't mean measuring is hard it means the ruler doesn't work without it.
Writing some code that actually works for the problem at hand, can be fairly easy.
Writing code that does this while being clean and efficient is a lot harder. How many slow, buggy programs have been written because the assigned programmer did not yet have the expertise needed to do it right?
> How many slow, buggy programs have been written because the assigned programmer did not yet have the expertise needed to do it right?
Basically, all of it. By the time a programmer has enough experience to design and implement software properly they are “promoted” to some paper pushing management position.
What a grounded take on this and wished more people saw it this way
Just yet another case of people seeing only the extremes and not the entire spectrum
You nailed it: in a corporate setting, code is definitely not the hardest part and it’s why companies can sometimes make do with a skeleton crew of offshore engineers who make $20-$30 bucks an hour
The way harder part is building the right thing and just designing the thing soundly to begin with
This type of software is where AI absolutely kills it - problems with tons of forum posts, writing code for systems with a ton of various kinds of quality developer documentation
On the other hand, if you’re doing something novel or sending a $10bn machine to mars, you probably don’t want to yolo it with AI
> In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
This is true, and this is the thing that makes me want to not be part of this dumb system anymore. If leadership on the same company can't align, that shouldn't be my problem, and I hope they get replaced by AIs that can.
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.
What devastated me this week is that I was slogging so hard for the past several months trying to deliver on what I was asked to deliver on, only took 1 week of PTO out of the 4 weeks I have saved up, spent nights and weekends trying to honestly solve multiple high priority yet HARD problems that 500 other engineers in the company couldn't solve, I'm making good progress on a couple of them single-handedly, yet my manager, who just came back from 3 weeks of vacation just gave me a performance review saying I am not meeting the "bar" for my level and need to do more cross-functional work and amplify my "impact". He's going on vacation again next week to watch the eclipse.
Fuck this. I want to travel, I want to enjoy life. I used to chase eclipses, too. I tried my best, all I ever get is "what you are doing is not enough". What the hell IS enough then? I already don't take vacation and don't exercise, I've put on 7kg of weight since I joined, yet you told me THAT is "not enough". Should I stop sleeping and eating?
Change priorities all you want, honestly I really don't care, and I've dealt with customers too, it happens. Just don't tell me I didn't get anything done. Recognize the fact that I tried hard every time you changed your priority, and I only had 2 months out of 8 to work on your latest priority, and calibrate your expectations to 2 months of work, not 8.
I hope you’re already looking for a different job. Because it’s never worthwhile in the long run to sacrifice your own mental or physical health for someone else’s career prospects or profit.
This job is already way better than my previous job at Amazon, where people were more actively sabotaging each other. At my current company there is actual teamwork, at least :/ and my entire set of peers all gave me hugely positive reviews, just not my manager, who is going by some written "bar".
I honestly can't seem to find any company that has sane health standards and work-life balance anymore.
Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.
There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.