Typing the code isn't hard.
Figuring out what code to type is.
Coding is problem solving, and solving problems can be very hard depending on the problem you're trying to solve.
Yeah, there was a running joke in our comp. sci. program that “we thought we’d make great comp. sci. majors because we had the typing skills (and desire).” The major says as much, you gotta understand the problem to work out a solution… and a solution may not be the solution — since we’re human so… get learning.
Cooking is easy. That's not an insult to a chef.
How do we thrive?
Accept that change happens. Be equal parts curious and critical about the new stuff.
That is not the solution. One cannot thrive if one cannot be seen or has been discarded as a relic no matter how up to date that person is. They will never be granted the opportunity to thrive as they have before as an employee. Their only hope to thrive is if they (magically) gain all the skills and networks necessary to be an entrepreneur that can do it all themselves. Nearly a unicorn.
Meantime while trying, they burn through what savings they have on the hope and dream of "being relevant again" and have about a 5% chance of success.
Maybe the author is misunderstanding the gist of the original article. Regardless, he raises an obviously accurate assessment of those who hold the hiring power. When I was recently out of college learning my craft, it was a common sarcastic refrain of either, "What could be so hard about it, it's all 1's and 0's" or "What's taking so long - you're just typing on a keyboard".
This has been a problem since long before I graduated from college (when classifieds called for 10 years experience on an IBM system that was released two years ago) (see, things don't change so much - names and places, sure, but not much else). People who are in leadership positions, who think they're better and smarter than most everybody else, frequently belittle those who do the grunt work, both physical and mental. It's gotta be a corollary to dunning-kruger theory (or maybe an example of it).
I read "Code was never the hard part" as "Writing the Code down is easier than the stuff you do before it (like Architecture, Design Patterns, Requirements) and after it (Testing, Troubleshooting, Refactoring, etc)".
Yeah, I feel like the author of this blog post read the referenced piece in a quite adversarial manner. Even if a programmer does no talking to stakeholders at all, the planning and design part of the process is still huge, and largely invisible if all you're looking at is the end result. That invisible skill and labour is the difference between a mediocre personal project of mine, and the output of a seasoned professional.
Writing code was never more than 20% of what I do as a programmer. All those other things are where I have always spent me time, and those are the hard part.
And to me the least fun. Programming is the fun part, everything else is stuff I have to deal with to do the fun part.
All of it has parts I hate there is a lot of boring code I've had to work on. And sometimes the fun code is things I finish and say nobody should every do that...
Then look at it again in a year and go, "Who wrote this?!" Do a git blame then go, "Oh, why did I do this?"
For me the part before it is the only easy one lol. For the rest, I don't even know how to program anything more than a basic Hello World in Python.
How could you possibly do things like architectude and design patterns without being able to code...?
I'm not sure why, maybe is because I live perpetually overstressed and I'm dyscalculic, but I can't just understand anything about the part of actually writing code. Like, I can conceptually and theoretically know really much about programming, programming languages and how they work (and how they would work better), but when it comes to start learning the syntax and what every symbol, word and all that means and how do they combine... Oopsie.
In few words, I do understand the theory, all the concepts and the programming semantics, but the code grammar is hard for me, and the syntax is nearly impossible as it involves too much maths.
As architecture and design are more about natural language and logical reasoning, and I'm actually good in those two things (I have hyperlogia [if "hypercalculia" is the polar opposite of dyscalculia, then this is the same for dyslogia]), or at least can be totally done without any maths and totally with only these two things (because yeah, symbolic logic is also hard for me), I can do these things to a pretty good extent.
Hope this allows you to better undertand. 😄
Code is integral. Everything they add to it, and build around it, is to support the code. Code is the God in the machine.
Code is the God in the machine.
Then God has no soul.
Yes, code defines what happens, how it happens. But what defines what the code is intended to do? Where is the intelligent design? You can wire up a bunch of relays with intelligent design, simple electrical work, define gates, build the gates into memory registers and arithmetic processing stages, make a CPU - but... are you any closer to achieving the goal for having done all that work?
Are you better off for having a hands-on deep understanding of the machine from electrical first principles, or does the warehouse full of circuits and wires and the power it consumes outweigh that benefit?
If you use a modern processor do you need to have hands-on the assembly code? Do you need to deconstruct and understand every stage of the compilers and linkers and optimizers? In the 1990s I did, because those stages weren't reliable enough, yet.
There's nothing different about "deterministic code" built on layers and layers of tools today than there was about assembly code built on the processors before than there was about assemblies of modular circuits that form processors and memories and peripherals... it's all parts of the system. And for critics of the "unpredictability" of LLM code generation, you might want to look into the mysteries of "garbage collected" languages.
If I eventually stop writing C or Rust or Go or Python or Javascript or any of the other hundreds of common choices of languages out there and instead learn to feed a LLM with instructions that generates the Rust that generates the Assembly that drives the CPU that manipulates the electron flows - that doesn't change the intelligent design of: making a thing do what it is intended to do.
"Code was never the hard part" is probably made up by someone who never had to program anything serious.
"Writting the code was never the hard part"
It's figuring out in detail what the program is suppose to do (i.e. Requirements), how it can and should do it given the technical constraints of the available deployment environment and performance & reliability requirements (i.e. Technical Analysis) and how it all gets structured from the highest level to the lowest level so that bugs are minimized, performance is suitable with the appropriate margin to absorb expect unexpected problems and costs for maintenance and future requirements implementation are low (i.e. from Technical Architecture and Systems Design down to Software Design) that are hard.
And I say this as somebody who has done all of those professionally, plus the coding (oh, so, so much coding) for systems of all kinds and sizes in various countries and industries, including some mission critical high performance distributed systems (which if they failed would have cost millions of $$$ in lost business income).
Fly by the seat of their pants coders who have never worked in a properly professional environment have no fucking clue just how much more there is to it than "coding" to go from no software at all to "reliable and robust software system that serves existing business needs".
A lot of "coders" are like I was in the beginning of my career: they think they're the shit, know nothing but a very limited range of work environments which they think "that's how things are done" when those environments are actually, amateur hour, every hour of every day, every day of the month, every month of the year - they're basically at the peak point of the Dunning-Krugger curve for software development knowledge.
For me, that is all integrated part of "programming". You missed the documenting the code part, but i consider this as an oversight.
It says a lot that you think a coding good practice like "documenting things in code" which is at the level of using descriptive variable and function names, should be in the same bucket as structural non-coding processes (which are often entire professionions or very senior professional branches) like Requirements Analysis or Technical Architecture, both highly-complex things (the latter being the very top in seniority of the technical career track) which are non-existent in a formal sense in improvisational (read: amateur as fuck) "programming" companies.
You're making my point on the whole Dunning-Krugger thing.
The interesting thing, to me, is how much/little architectural level design matters depending on the complexity of the system you have built, and the longevity of its maintenance in the field.
I watch things get built with bad architectural compromises for what appear to be bad reasons all the time, and they rarely "come home to roost" until years later... then the question becomes: was the implemented design a success for having gotten to market quicker and lasted so long without serious problems, or a failure for having created a mess 5 years down the road that could have been addressed with a 5 day delay of launch for a refactoring? Or, should we instead spend 5 weeks attempting to predict the optimal architecture before we even start and maybe get a good solution or maybe still end up learning things we didn't know during early development - and when we learn those things down the line from the initial architecture specification, when it it time to slaughter the sacred cow and re-arrange things?
Oh, they "come home to roost" almost immediately - you just don't see it because whole teams are doing everything they can to hide it or ignore it - nightly manual data update statements, etc.. Here's just one real example.
In my last (read: final) job as a senior software engineer, I discovered dozens of serious problems with the system I was assigned to "maintain". They ignored all of them - wouldn't let me fix anything. Meanwhile I was responsible to solve production problems on the daily (duplicate data, insert failures, performance slow-downs, etc).
It wasn't long before the fact those problems weren't going away that they became problems I "caused". Meanwhile, all the fixes I wanted to make were ignored. I had one problem I dissected and and gave my boss a brief write-up of the scenario. He told me I needed to do deeper analysis. When I came back a few hours later with a considerably more detailed explanation, he didn't read it and complained of a "wall of text", which he literally told me to write. Then he created a random-number hack to "fix" the problem.
They did not grasp the concept of data normalization and primary keys as they had one particular table that represented two levels of detail (for example, account -> order). They put both in one table and had a code based special update to the "account" number so they would not get a PK violation rather than just fix the data structure.
They had as single database connection open all the time to handle all inserts in a singleton service, then launched as second one on the same database to process messages faster - and couldn't understand why it didn't double performance.
The main routine had a cyclomatic complexity of 360! I shit you not! And everybody agreed it was "95% working" even as we continued manually fixing (the same) problems daily.
Week after week, the customer (internal) would raise more data issues as "new" problems. I'd routinely ask two to three questions about the data set and explain that's the same problem that's been going on for six months, and if we could just get my PR reviewed, we can test it and deploy it.
All these problems were in a single service.
I was let go not long after the 1 month probation they soon initiated and told I was not performing at the level of a senior developer.
This is how delusional these people are. They refuse to acknowledge their flaws even after hiring someone specifically to solve them. They blithely call their monstrosities "successful" while committing many staff to late nights and weekends "managing" it.
Not only in code. Documentation for the end user (or at least halfway there, the final document is done by a separate department), is important, too.
There is a reason that my job description is "Embedded Systems Architect". But I see this ccomplete packet as "programming".
Interesting thing I see is that LLM slop generators are actually quite efficient at generating documentation, both for the end users and for developers, and like human generated slop-docs, the more cycles you put into review and refinement of them (both human guided and LLM self-review/refinement) the better quality you get out. Investing even half the person-hours in LLM generated documentation generates higher quality, more complete, better organized and more readable documentation for me than "working with a team" of writers who all have to meet and re-meet and explain and re-explain ad-nauseum until we're all sick of the process and late for delivery of the documentation products.
When this documentation investment is made in the code, some remarkable things come out like: a project co-developed with Claude in Python took 10 interactive days to make. At the end, the Python was performing fine but a little on the noticeably slow side, so the LLM was told "do it again in Go" and 3 days later with very minimal prompting, the whole thing was re-implemented in Go, running 10x faster, and flawlessly performing the same functions which were developed in Python in 10 days - I believe precisely because a significant part of the Python project was: documentation of requirements, design specifications and automated tests.
You missed the documenting the code
Your words.
As for your job title, don't take this badly but "Systems Architect" is not at all the same as "Technical Architect".
If you're actually designing or at least tuning software development processes and coding standards across multiple teams (so, not just optimizing how teams work but also optimizing cross-team work), you're a Technical Architect.
A Systems Architect, when the title is properly used, just means that you're designing software whose operation spreads across multiple platforms (so, for example, multiple tiers in a multi-tier system).
Also there is quite a range in Systems Architect - knowing how to code in two or more platforms (say, STM32 and some Android, to make a bit of home electronics with a microcontroller be controllable from a smartphone) is not at all the same as knowing how to design a high-performance distributed system running in multiple machines, integrated with multiple external system working for ten/hundred of thousands of client front-ends and supporting things like Distribute Transactions so that any failures don't leave half-complete operations.
You can be a Systems Architect and be isolated form most of the concerns of the software development out there. especially if you're a team of one developing the software side of products based on some marketing person's idea of what customers supposedly want.
Unsurprisingly, Technical Architects are non-existent outside large companies and even there they're pretty rare.
Again, still making my point on Dunning-Krugger.
This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?
I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.
First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.
The things that take up more time in software development just for engineers, leaving aside things that design and pms do.
There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.
Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.
I'm a mediocre hobby programmer, and for me, the hardest part is coming up with the concrete specifics of what to implement.
I'm actually half decent now (for a hobbyist), but I remember that when I first moved from coding along with worked exercises in textbooks, to actually trying to solve real life problems, it got exponentially more difficult. The textbooks say "use this tool to achieve this goal", and even if you're bad at using that particular tool, you can put all your effort into doing it well. However when you're having to make the bigger decisions for yourself, you have to choose what tool to use, and I found that super hard — especially when having to choose between an approach that I felt confident with that wasn't quite the right tool for the job, and a new tool that was completely new to me (and if I am unfamiliar with a new approach, am I sure that it's the right tool?).
At one point, when I was deep in a personal project, I had a period of a few weeks where I had no reliable access to internet, and so I did most of my coding using paper and pen. It forced me to think more deeply about the implementation I was using, rather than just diving straight into the code
For me it was trying to interpret vague business requirements. But I was a designer / coder. I tried to insulate the other programmers from that nonsense.
Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI. Don't abdicate your responsibility. Don't be a meat proxy.
By expanding the ability to program to people without the knowledge of how that code works in the first place, it's naive to expect that most uses of AI in programming will be informed uses by senior developers able to recognize errors and security flaws.
Such a pro-AI position also ignores the enormous amount of theft that these tools are built on.
the ability to program
people without the knowledge of how that code works
Ain't that the biggest oxymoron you've seen today.
They are not given the ability to program, per se, in my opinion. They are doing something else.
Maybe I'm misunderstanding your comment though. Not sure if you're referring to the code output when you said "that code", or some other code. Please let me know if I got it wrong.
I appreciate the intent behind that sentence, and the problem is that is written (or said) by people who don't understand coding.
Syntax was never the hard part. Code syntax is a set of rules that you can teach a machine and it's "easy" enough for an LLM to grasp it. The problem here is that this phrase does a "code = syntax" but ignoring all the difficult things that actually are in the code. Architecture, design, tradeoffs, translation of vague requirements into concrete software components...
All of those things are terribly hard, and the reason why many LLM-first coding projects get abandoned at 70% and then companies need to hire a Software Development consultancy to mop up their mess.
Remember that story about the chalk mark engineer with Ford? Chalk mark 1$, knowing where to mark 1000$ ? Same with code. "Code" is easy. Knowing what to write, why and where, that's the hard part. LLMs have somehow managed to automate the code part, without the abstraction, at least in an error proof way. I don't think "coding isn't that hard" is insulting, and I don't use C++ because I think it's hard. But it's not because writing something is hard, it's because writing precisely what is needed is hard.
Anyway, this debate doesn't matter, negotiate better, be active politically to ban stuff or not, complaining on the internet won't do anyone any good. I know you're emotionally invested in this, just... breathe and do something else? Idk. Also I'm not your enemy on this, so no need to attack me.
Funny; I always heard þis fable as a plumber and a hammer-tap.
That try, the hard part is algorithmic and avoiding archictuctural traps and experience. Pissing code which didn't work or look like it work but don't is easy.
This is a most excellent place for technology news and articles.
