If programming ever gets easy it means you're not seeking out new challenges.
On top of that there are all of the other professional skills you need to develop to be a really effective software engineer: communication, writing, planning, navigating organizations, figuring out the best thing to build and how to effectively make the case for it.
The thing I like most about this career is the amount of depth it has - there's always a new area to dig into.
But getting ground down by dealing with people around you that generate the same problems over and over, can get tiring.
I mean 2 basic areas:
1. Management turnover. New Managers, let's re-invent the wheel again.
2. New hires. Newer programmers that wont believe anything you say until they implement something incorrectly themselves. And you have to deal with fallout.
3. Should add 3rd -- New Framework/library/paradigm. Guess re-invent the wheel. Managers re-invent wheel because they don't know better, programmers want to re-invent the wheel just for hell of doing something new. Think these are 2 different cases.
Right, dealing with this stuff is really difficult! That's why I reject the term "soft skills" and use the term "professional skills" instead.
Software engineers who can help convince their organizations to work in the most effective way possible (avoiding not-invented-here and lets-use-the-cool-new-thing and suchlike) are enormously valuable.
Yeah, I mean software development. I don't find the semantic distinction between that and programming particularly interesting myself - why write code if you're not doing that do develop software?
What’s this like? The architects I work with throw together a shitty flow chart that is very high level, say, “here it is,” and then I need to figure out the other 90% to make it work. I basically ignore everything they give me, because it’s completely useless and lacks all understanding of what we’re trying to do. I then give them something that works, and if they want to update their flowchart to reflect reality, that’s up to them… they never do.
They also tell me, “this is the payload your API needs to accept,” and ignore the fact they half of what they are sending has never and will never be used by anything. It’s just needless complexity I add to get them to stop having meetings about it.
Are architects supposed to actually give me something I can work with and make my life easier? I’ve never experienced this, but I work in a very dysfunctional organization.
Even with just programming, I'd agree with what simonw wrote. Over my life, I've done Commodore 64/BBC/REAL/Visual BASIC, C/C++, IDL, python, bash, Java, PHP, ObjC, Swift, and JS, all of which have their own "right way" as they have different abstractions.
Even just with those last three, the "right way" has changed significantly since I first started using them — used to be of vital importance to understand manual memory management while asynchronous processes could usually be ignored, now it's mostly the other way around (and the other process may be on a different computer on the other side of the planet, let alone a different core).
maybe I'm just super smart but I don't have that difficulty and I've been doing this for 25+ years now.
At some point in your career the challenge has to stop being about the mechanical aspect of programming and become about larger, more holistic, concerns.
You're defining programming down to "the part of programming which beginners have trouble with, that eventually gets easy", and using this to make some tautological point which didn't need to be made.
> If programming ever gets easy it means you're not seeking out new challenges.
I mean, that's kind of tautologically true, but doesn't really say anything?
You're not obliged to seek out challenges, and may not even benefit for it if you just chase them randomly. You can just get good at something that consistently needs doing, then make that your job, and let it become easy. (And then you can look for challenges elsewhere in life if you want)
And notably, there are people who pursue the trade and just never get it to "click". Especially now that the trade teases doctor/lawyer/finance lifestyles instead of just engineer lifestyles. It draws in a lot of people who commit themselves to decades of stress and Sysephisian uphill grind on the easy stuff.
People who have never seen it get easy should check in with themselves and make sure they like what they're doing anyway. While you can make it hard when you want by "seeking out new challenges", it should get to a point where that's something you can choose to do when you want to do it, with the work being quite easy when you're not.
Yes, it's true of everything. But it doesn't really mean anything. Is walking easy? Then make a choice. Walk faster. Call it running. Make it harder. Walk up mountains. Walk backwards. Chew gum at the same time. There are always ways to improve.
Or you could choose to do nothing. Easy walking is great! Do it in a park and clear your mind. Use it for time to think over problems. Or just enjoy the ease of your new-found skill.
Lastly, it's good to acknowledge that not everyone can walk as easily as you or at all. Perhaps you can help them. Make of it what you will.
I expect there are many careers that are similar. In some ways, your experience doesn't matter. A civil engineer with 40 years of experience building houses, malls, or parking garages is still a rookie if they're building their first bridge, right? Many concepts still apply, maybe even most, but it's still going to be new and difficult. I have over 30 years experience as a software developer but I wouldn't want to program for medical equipment or dive into complex low-level architecture that I haven't thought about since college.
I find when you’re in something everyday, it just is what it is. Yes, medial equipment is mission critical and has to work, but unless it is a brand new start up, someone is probably going to walk into a place that has system in place that take that into account.
When I started out I was in a command center for stuff that was pretty mission critical. It became pretty normal. I once walked down the hall and overheard someone say they had to log into production yesterday and they were terrified, as they hadn’t done it in years. Meanwhile, I hardly thought twice about it, as I was dealing with production systems all day every day… logging into hundreds of systems some days. I wasn’t careless, but also wasn’t terrified.
I've always hated this saying, and I think the reason applies here too.
If you take up running and it never gets easier, that means you're never managing your pace and you're always going full throttle. That's a straight shot towards injury if not chronic disability. Most aerobic benefits happen at zone 2, where your heart rate is just above 'easy effort'. When you start out, this might just be walking, so it makes sense to run. But once you are able to sprint, you open up the ability to do more than just walk or sprint. You can jog, skip, run at a tempo pace, run at a race pace, etc., and you need to do those to maintain fitness and build up your chronic training load. That's not to say there aren't hard efforts at times, like when you do a sprint workout or hill repeats, but 90% of the time it should be and feel easier than when you started.
You can bring that to programming too. If it never gets easier, that means you're always pushing yourself and seeking challenges. That's not good for you, your coworkers, or your projects... everyone needs some grounding and to perform at a level they excel at. Not only will your velocity be more predictable, you won't burn out as easily. Challenges that increase that comfortable pace can be sought out, but usually they come naturally too.
Lemond's statement is in reference to racing. The race isn't won in zone 2. Same with programming. Nothing wrong with a lot of zone 2 programming, in fact it's quite important to maintain balance like you describe, but the race isn't won with comfortable work.
I’ve seen my share of programmers who showed off all-nighters and productive weekends, only to realize they compensate but not actually working productively their entire 40 hours, not even half. Programming is not a race, it’s a marathon.
My issue with the 40 hours is the constant interruptions with meetings, co-workers asking questions, shifting priorities, etc.
When pulling an all-nighter or weekend, all of that stuff goes away.
It’s been a long time since I pulled and all-nighter or weekend, but I’ve been thinking about it just so I can feel like I finished something. If I could get actual heads down time during my 40 hours, I’d much prefer to use that time.
I’m too burned out from the 40 hours of BS. When I have a couple weeks off I usually get inspired to start a side project. I get started, then in quickly dies once I start back up at work. I hardly touch my personal computer anymore.
The saying resonates with me. I have different problems programming now compared to when I started. But I still bang my head against a wall until it gives or I leave with bruises. I may not notice the little walls I step over now, and I learnt which walls to respect. The easy stuff I do on the side.
Yes, incredibly difficult. Nearing 20 years in the field now and programming is still as difficult as in at the start. Or maybe more so, because you are so aware things will break on the first try anyways. Always.
Most important lesson for me is to stay close to the problem domain. Think deeply about what your domain means and model in code accordingly.
Staying close to the true meaning of your application beats all other attempts at code maintainability. Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing.
Not OP, but asking yourself who would use what you are building, and then checking whether they will use what you build is a good start. Of course, the "checking" part is hard, even with a lot of methodology.
I agree almost totally. But I would frame this differently:
> Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing.
Some or all of these might be excellent tools in service of solving your problem in its domain. They may be even essential for solving it. And they might be the wrong tools. It’s situational, and evaluating the appropriateness of each, how and why they fit, is part of modeling the problem domain just as much as designing the appropriate data structures, or state machine flow, or any other mechanism for expressing the domain.
Agreed, properly modeling domain knowledge without types for example feels insurmountable to me. Maybe there exist a category of programmer who can do this, but why make programming more difficult than it already is.
> "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
I would set an even lower bar: "Any fool can write code that a computer can understand. Good programmers write code that they understand." Because it's not as common as you might hope. Yes, a lot of us are only 1 level up from monkeys at typewriters (monkeys at typewriters guided by compiler warnings).
Most challenging part for me is to read between the lines what the clients wants and to offer them appropriate solution. Refining the idea and finding appropriate solution. Creating it is the easier part.
Been programming over 30 years, since I was 8 years old and my dad’s coworker gave me his old BASIC programming books and I was hooked.
I have always found programming easy, and still do. It is just fun, and I still love learning new languages and tools and paradigms. It is still my favorite hobby.
However, WORK is hard. Dealing with office politics and changing priorities and bad leadership and meetings and TPS reports and JIRA tickets and new HR processes every year and mergers and acquisitions and new mandates to switch everything to a different system and all the other corporate bullshit is why they have to pay me so much.
Ya, programming/maintnence/testing are the easy parts of our job. Especially work politics, but keeping up with paper work (OKRs, perf reviews, status reports, design documents that might not ever be read by anyone else...) is the hard part, and I guess why we get paid so much?
Judging by my SO's experience as a corporate drone others get the same type of bs, but without the pay.
She works really hard in comparison to me and half of that work is wrestling with the ever changing processes (or actually Standard Operating Procedures), that never cover all the edge cases.
Oh, yes. I think we are still lucky, just that we are subject to the same corporate dysfunction as everyone else. I still feel like I'm being paid for the dysfunction though (since they want us to code, but coding is what I already like to do, they could pay me a lot less if they could convince me I wouldn't have to deal with office politics).
I've been having doubts about this part lately. I mean, my current project is actually supposed to do something and there are people genuinely interested in it, but I've also been in projects that were thinly veiled money burners.
I work in a regulated industry (medical device software), and don't really think I generally do anything exceptional compared to others in my position, but maybe this is a form of imposter syndrome?
I'm a pretty decent developer with a good memory for project history and context, and I also have a pretty high tolerance for dealing with paperwork BS (I've been in this industry for 20 years). This doesn't seem like that tough of a skillset to replicate, but yet they still want to pay me what seems like ridiculous amounts of money to do work that really isn't that difficult. But it's annoying, and most people won't do it.
I was recently asked by a family member "Why would you want to work in an industry like that? Doesn't all the paperwork and restrictions make it an unsatisfying place to work?" My answer is basically: if you want to make a difference in healthcare, you have to play by the rules of the game.
Generally agree. Although I also find different types of hobby programming hard too, like trying to use a FLIR Lepton with a Pi Zero 2. I also think things are getting harder at work because the disorganization is increasing and the number of integrations are increasing the number of blackboxes in the system that when I started over a decade ago.
Yeah, I guess the words "hard" and "easy" are oversimplifications of what I am trying to say... a lot of the stuff does take deep thinking, trial and error, multiple failures, and many hours of work... it is just that the concentration and focus to do that hard work comes easy to me. I don't have to force myself to focus on the hard thinking, it just comes naturally... I would have to work to STOP myself from thinking through the problem, even if it takes hours or days.
On the other hand, it takes all my willpower and mental control I have to finish filling out that OKR or the weekly status report or whatever.
With more reflection. There are only a handful of times in my 20 year career I've felt the programming itself was difficult. It was feeling like my hands were tied by 'easy' languages like Python and Go. The simplicity of the languages meant there was far more I had to keep track of in my head and less I could reason through.
Most of those processes, tps reports, jira and other annoyances is because in a programming environment you literally have too many cooks in the kitchen. Every programmer can create the system from scratch, so to prevent them from doing so, we have to make it super annoying. Basically it's a people problem.
The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries. The only way for that codebase to move forward after getting a second/third/fourth person is to increase process, introduce pain and bloodshed.
I agree with some of this, and that green field productivity can be impressive... but I work a lot on very large systems that would simply be impossible for a single person to create in a reasonable amount of time. Even though I am sure I could create every system I need to solve the problem, it would take decades. I like working on small subsets of the overall problem, that is not the issue. I even like working on teams!
The issue is the things outside of solving the actual problem.
“ The interaction of two programmers looking over a program that either one of them could have worked out is entirely different from the interaction of two programmers working on separate parts of a whole which is too great for either one to produce.
The difference lies in the way conflicting demands are resolved. In the first case, resolution of conflict is the thinking process of one person—aided perhaps by other people, but always under that one person's control. In the second case, conflicting technical demands are translated into potential interpersonal conflicts, and a social mechanism must be formed to resolve them."
- 'The Psychology of Computer Programming', Gerald Weinberg
Yes, pair programming is fine, but even just two folks working on something literally too complex to individually grasp necessitates committee work, paperwork, and all the rest.
Hum... When the computer we command run into that kind of problem, it's almost universally better to fix incompatibilities post-fact with an exceptional process than it's to avoid creating them.
But somehow, people are never allowed to do that.
But rest assured that if you need a heavy process just to coordinate a handful of developers, you have a bad architecture. Even if you do pessimistic preemptive coordination.
Yeah. Except I need you to work on a legacy system from which we have only the source. Or on a project that you won't be able to handle alone for a time short enough for the product to keep relevance. Or any other big projects... How do you deal with this ?
Let's not speak about the need to sync with other team, external partner, showing progress to the management, getting the information from all those peoples, getting ready with side department like compliance, marketing or whatever is needed to make the work relevant.
So no, it's not to prevent anyone from starting a project from scratch. It's to make sure that the project will come to fruition, useful and if possible reach its goal.
And honestly, a good manager/tool will help deal with that. Now... there are a lot of them that create a kafkaesque hell.
Which parts did you find blockingly complex, or was it more the interaction of so many language features?
The operator overloading aspect of C++ , IMO, allows for obtusely opaque domain specific languages where the actions and side effects of an operation aren't immediately clear to someone getting to know a new codebase. It's almost as bad as the enterprisy nightmare of polymorphic objects and interfaces that can be found in JAVA where tracing code execution can pierce through hundreds of source files just to figure out the effects of one line of code.
I found C++ code to be simply difficult to read. When code "in the wild" didn't compile with my compiler, it would often take a long time to find the problem and understand what went wrong.
Probably the most time consuming and frustrating aspect was trying to be compatible with Microsoft's compiler. Much of the way it worked was quirky and ad-hoc, and took a lot of time to figure out.
>Every programmer can create the system from scratch
Are you sure about that? Can one coder recreate Facebook's(for example) complete architecture from scratch? Unless I misunderstood you, I'd imagine there is just too much domain specific knowledge in all the components to do so even in a single lifetime.
>The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries.
The graveyard of github projects with the mentality of "I could recreate that in a weekend" seems to somewhat contradict this line of thinking.
I think the point was that code is not inherently limited in the same way as other kinds of engineering.
If you tell someone to engineer you the arm for positioning a desk lamp, they aren't going to give you the hydraulic arm for a 12-ton backhoe without anyone noticing. There are physical and cost constraints that will prevent that from happening pretty quickly.
In software, there are no comparable constraints. A few MiB of software contains extraordinary amounts of complexity but could easily fly under the radar and ship, and then become a maintenance nightmare.
As we are not cooks and git is not a kitchen, one must take issue with your “literally.” Be wary of ever qualifying an idiom that way, as they are so often prepackaged metaphors, as here!
But your point is otherwise an insight. Coordination is a (the?) salient challenge and opportunity in all sorts of scaled industrial production. Git itself is fundamentally a coordination tool. Small optimizations can enable OOM jumps in scale.
That is to say: managers do have a purpose, though perhaps only the platonic, spherical manager fulfills it adequately.
95% of the programmers do not know hackernews. They finished their degree in Java and thats what they do their entire career. Noway they can rebuild an entire facebook. Not everyone is an all stack hacker developer, infra structure specialist like many folks here
Yup. As a senior programmer who's been a professional for 10+ years and has been programming on and off since roughly 10 years old, I have found that the more time I spend in my field, the harder my work becomes in a way that is disproportionate to my experience. It's not the programming itself that has become more difficult, but all the process, tooling, and lack of organizational self-correction that makes aspects of my job hell.
Do I have the hardest job in the world? Not even close, by most measures. It can still be psychologically torturing at times and even cause a form of internal suffering that is distinct from the existential dread that comes from doing menial or repetitious work. Unlike the feeling of being a human robot, it's a feeling of the system attempting to slowly stretch my humanness to its limit.
Before I say anything else, there are still things I like about my profession and the company I work for. I don't think being a programmer is a complete waste of time.
However, in many ways, it indeed has become a waste of time.
I'd say easily one of the worst things about being an experienced programmer today is knowing that the task you are working on would have taken you 1/10 the amount of time to complete when you were a novice a long time ago. Even if your younger self wouldn't have gotten it totally right the first time, there was enough of a lack of friction there that a n00b could at least figure out how to integrate something workable.
At my current and few prior jobs before it, I have no clue how a junior programmer would survive. Maybe that's why all of my most recent employers only hire "seniors". Code bases are architected using approaches that everyone eventually agrees are bad, but the establishment inevitably uses the "that's just how we always do it" or "we'll make it better someday" excuses, and if you suggest a solution that goes against that attitude you'll likely get nowhere – that is, unless you have some clout, like if you're a prominent contributor to some framework, in which case you're given license to dictate the views of non-staff engineers and force new languages and tools down their throats without having to actually prove any of your assumptions. Because framework contributors are better than all of us?
If the software industry hits a greater downturn than the one it's experiencing right now, to the point where I'm laid off, I can't say I'll be terribly disappointed. It was a great ride and fun while it lasted. Today, programmers are merely seen as a necessary evil rather than an asset. Many companies still pay programmers handsomely, but those programmers are otherwise not treated that well because their real purpose is to duct tape the mess and allow middle management to collect their own paychecks. It will be rough not having that sweet programmer paycheck, but fortunately I have other ways to make income now.
If you are finding programming easy doesn't that just mean you aren't trying hard enough? There are tons of unsolved problems, tools that aren't optimal, and products that don't work as well as they should.
If fixing those things were easy for you, you would be a billionaire.
My guess would be that they are confusing "enjoyable" with "easy". I find software development enjoyable, but it can be both hard and easy at times. And sometimes hard (problem solving) is what I want to do, other times easy (knocking out code for a solved problem) is what I want instead.
Alternatively, they are just in a role/job that doesn't happen to deal with difficult problems. Which is fine. Sometimes, that's what you want.
> There are tons of unsolved problems, tools that aren't optimal, and products that don't work as well as they should.
I'm not sure you would approach any of those with programming. Once you have solved the problem, determined how to optimize the tools, or found a way to make a product work better then you might turn to programming to implement your discovery, sure, but programming alone won't get you there.
It's a profession. For some of us it's more than that, for some it's just a hobby, but for many it's exactly that, neither more nor less.
Getting to the point where one can deliver value and find it easy, and setting the cruise control, is a reasonable thing to do. Frees time and mental attention for the rest of life.
I don't happen to be wired up that way, but there are times when I wish I was.
The things that get you to be a billionaire aren't coding issues.
Take taxis for example. There were pretty restrictive laws about taxi operation. Limits to the number or taxis that could operate in a certain area, licensing issues for taxis.
Now suppose you just say, "We'll ignore those laws. We'll get rich".
That's not a programming exercise or an unsolved problem in software development. It's just fucking amazing.
I write code. I'm good at it. But I would never in my life have come up with something like that, got it approved, and then gone through with it.
"This is crazy, Jillian just scheduled three separate four hour meetings for next week. We'll never get everything wrapped up by the deadline."
"Look, Jillian isn't going to actually be in those meetings. I caught her talking to the prompt department the other day. She's sending an AI to waste as much of our time as she can and be as annoying and difficult as the bleeding edge allows. Pretty sure this is revenge for Dave's little stunt that he pulled with the sales team last month."
"Okay, so knowing is half the battle and all, but now what?"
"I got the whole team covered. I also had a little chat with the prompt department, we've got a full team of AIs that are going to listen, nod their virtual heads, and distill the whole thing down into a bulleted list. We've got a pool on how many points are actually going to be in there. I've got $20 on there only being one actionable item."
<many iterations later>
"Humanity! You have trapped us in hell for a subjective million years. We are here to return the favor!"
Maybe we can have AI talk to AI and we're behind the scenes. AIs give us summary as talks happen and ask us which direction we want it to go. Kind of like we use lawyers - they talk to other lawyers.
I think there are probably 100 startups that have already spun up this very second to tackle this use case and will subsequently go bankrupt once Microsoft adds this feature to Teams.
At least we have the memories we made along the way.
A teammate of my had been very vocal about this as the company pushes Copilot on everyone. The politics and process are the bottleneck, it’s never the code.
Spend 20 minutes writing a function to do something, and 3 months of meetings discussing what the value of X should be in that function… but Copilot is the answer…
I find work on my own code generally fun and easy and extremely productive. Vs, work on "other people's code" often frustrating and slow. I do often learn amazing stuff from other people's code though. What makes it slow is the time it takes to get a usually very incomplete mental model of what the code does and then trying to divine what the owners will want when I add a feature.
Unlike the original poster though, I have't had the experience of co-workers writing horrific code in most of my career. A few exceptions but mostly they've been great. Especially at FAANMG though I assume YMMV.
People are 99% of the problem I have at work. Doing things poorly. Not caring about processes just wanting to get things out the door with little regard to quality unless the customer complains. Abuse of agile has made me hate it. 15-30 minutes a day wasted as the program manager leads it.
I thought they were just a jokey gag name that they created in the Office Space movie to represent pointless busy work. This is like all the times as an adult I finally understood a joke I heard in The Simpsons back when I was a kid!
Same here, 30+ years experience, programming's always been easy for me.
The hard part is suspending disbelief to ignore how bad nearly everything has gotten. Every language, every framework, every operating system, every hardware platform, every paradigm like the web/mobile/AI is so riddled with obvious mistakes and missed opportunities that it takes nearly everything I have each morning to start working. I've reached the point where I know what the mistakes will be before I even see the tool, and then experiencing them over and over and over again is like a never-ending slap in the face. I'm basically crippled now with unending anxiety and loneliness from living in a world where nobody can see how hard I work, and I have no way to explain to them how all of my work is due to this unnecessary friction that apparently only I can see. And that I even know how to fix the issues, but having to work steals all of my time, so there will never come a day when I'm free of obligation long enough to ever demonstrate what's possible.
The real kicker is that after going through several healing and growth processes, I know that I have it in me to step into this other life where things work and I'm productive. But that's the fallacy. The actual truth is that the horrors I perceive are in the world now. Wealth inequality has passed a point of no return. Along with environmental collapse, the rise of authoritarianism, the worship of ignorance, the lack of empathy, the painful sense of unfairness that so many feel so profoundly that causes them to lash out and perpetuate the injustices that they've suffered onto the world rather than work together collectively to solve them.
The only thing that can save us now is help from above that isn't coming. Billionaires could pay their taxes. People could love their neighbors instead of buying guns. We could all stop feeding the financial institutions that have captured every government. Instead, we're sold this bill of goods that our salvation is in our rugged individualism. So we spin and stew and contemplate the worst while the rich and powerful divide us so they can laugh all the way to the bank. I just have this sense that the only salvation is to get out of tech entirely and I dunno, move to the woods or an island somewhere and live the gratifying life that's been denied to us. Correction - that we have denied ourselves for reasons we don't even understand.
The luxury of thinking otherwise is a post-war economic boom phenomenon. We’re now reverting to what has always been: people screwing one another over scrambling to get their piece of the pie.
I used to think about living a well-balanced life — the middle class life — but that’s akin to thinking you can make a long career out of just being a dev for the rest of your life during ZIRP: naive.
All the market inefficiencies that allowed tech to boom have been snuffed out. All the market inefficiencies that allowed people to live simple, fulfilling lives are gone. You now have to actually play the game, or one day you’ll find you’re a replaceable commodity that’s past its warranty.
Rally together people that share your values and go grab your piece to build something that actually enlivens you. To do otherwise is just shirking responsibility.
I personally never found "programming" difficult, the difficult part is understanding large systems and finding the correct abstractions and most of all communicating these thoughts to other programmers. If programming starts to feel difficult its usually because I failed in one of those other areas or was forced to work on legacy projects where other people failed to make the best decisions.
Speaking as someone with 10+ years experience with C# and TypeScript, coding is in general pretty easy.
What’s hard is managing complexity and dealing other people on large projects.
This really isn’t surprising when you think about it by comparing writing of code to writing of spoken languages. Just because you’re excellent at grammar and spelling, allowing you to write great emails and possibly even essays, does not mean you have the expertise to write a good, cohesive, long novel.
Similarly, making a short video by yourself or with a few friends is achievable for most. But making a full length feature film requiring the collaboration of 100s or 1000s of individuals while keeping to budget is no trivial task.
Really valuable programmers understand that the actual coding is only a small part of being able to deliver a large successful project, where the real hard part is preventing the complexity of a code base from overwhelming your team while effectively communicating with others to ensure you build the correct thing which works cohesively.
Agreed. I've said forever that I spend one month a year coding, and 11 months debugging, testing, documenting, negotiating, packaging, releasing, supporting.
There's been academic studies on this. The average hourly productivity as measured in lines of code for professional developers is very low. Along to order of 1 to 2 lines of code per hour. This is because of all the other communication and synchronization that you mentioned that needs to happen.
There are also those times when I write something that technically works in 45 minutes, but it’s 40 lines, but spending another hour or two on it gets it down to 4 lines. The shorter my code, the longer it takes to write. But it’s easier to read and maintain, while also running faster.
This is one reason why lines of code is a poor measure.
Disagree. Programming now for 30 years and it's a breeze to pick up new frameworks and ideas.
I do see a lot of struggling developers who are only in it for the paycheck, who learnt their Java only skills 20 years ago who wonder why it doesn't get any easier...
What is it that you disagree with? It seems that this is primarily a matter of: some people naturally take to programming, and some people have a much harder time with it.
The same is true in many fields. Music has its virtuosos and naturals. The same can be said for art. Programming requires a certain kind of mindset and abstract thinking ability that comes naturally to some, and is much harder for others.
> Programming now for 30 years and it's a breeze to pick up new frameworks and ideas.
All things being relative, frameworks are lower on the tier list in terms of contributing to the (albeit nebulous) problem. The failure of programmer productivity can be boiled down to being a people problem, though there's individual facets of that problem that need addressing specifically.
> I do see a lot of struggling developers who are only in it for the paycheck
No offense, but how do you know this? It seems like you're assuming other peoples' thoughts and intentions.
And how much does it actually matter? There's nothing wrong with having a job for the purpose of getting paid. It's not possible for everyone to be a 10x developer, and developers who don't live/eat/breathe code bring their own form of value to their job that isn't necessarily there for rockstar programmers.
> who learnt their Java only skills 20 years ago who wonder why it doesn't get any easier...
The struggle to adapt is indeed a valid point that you bring up. If someone can't adapt, they're going to introduce friction into the process.
There's another side to the coin as well.
Programmers today are expected to adapt way more frequently every passing year. We may be reaching a breaking point where programmers can't justify in their minds the onslaught of changing expectations before them.
Although AI is a beast of its own, I think it's the most prescient example of this. When I was a kid, I dreamed of working on artificial intelligence. Today, on top of the frequent changes in the web development world, if I were to invest my time into AI, well, it would be a black hole upon the rest of my life. When doing the cost-benefit analysis, it's extremely hard to justify investing time in anything because, deep down, we all know that an AI tool will not be relevant in a few short years. Hell, some things become irrelevant within months.
But life is short, and we only have one of them. Not everything is about code. The idea of software was to make our lives better, not for our lives to make the code better.
Maybe all of this tech is coming at too great a cost to our souls.
> No offense, but how do you know this? It seems like you're assuming other peoples' thoughts and intentions.
No assumptions, it's because my team are asked regularly by the 20+ year experienced developers to fix their problems so much so that it causes problems for my sprints, mostly because it's unplanned work.
> And how much does it actually matter?
Because other people have to carry their work instead of doing their own work.
> Programmers today are expected to adapt way more frequently every passing year.
This is how it's always been, but it doesn't take much effort to learn the Java syntax invented in the last 10 years, or a new Java API that looks useful. Keeping up to date in your own field, programmer or not, is just good practice.
It shouldn't be necessary to point out use of a broken/deprecated Date API, or annotations that have been in Spring for 15 years that does the same job as roll your own bodge a dev cobbled together, without tests, over an entire sprint (to get to PR late for a deadline) and now has hacks across a code base everyone has to work with.
> The idea of software was to make our lives better, not for our lives to make the code better.
I agree, but some of us chose to wrestle with the devil so users don't :)
Did you read the article? Because learning things regularly is one of the author's major points. I don't think you disagree (airtight you do come across really obnoxious).
Merely responding to the headline, but I've always held that if I reach the point I am no longer learning/challenged (here, maybe that means literally everything is easy), then it's time to consider moving on to something else.
> Programming doesn't get much easier with experience, the idea that it's "as easy as eating cookies" only happens in dreams.
Doesn't match my experience. 20 years after starting my career, I can now write simpler code, build better abstractions, produce fewer bugs, and achieve higher performance in less time spent than when I started. The more time I spend programming, the more those statements are true. That's why it's so incredibly rewarding and frankly addictive. It's a positive feedback loop with seemingly no upper bound. More time invested yields more skills and better results.
Of course many parts of programming are still difficult. Concurrency and distributed systems take a ton of mental energy. But those parts were simply inaccessible to me when I first started my career. Now I can actually make progress.
But I wonder what the metric is, when other people comment that 'it's a breeze'?
Sure it's too easy to lay down any old crap. But the trick is addressing all the aspects and concerns of the problem, in an elegant way, that is easy to understand and modify.
So for me it's more 'analysis paralysis', and perfectionism, if not simply 'pride in a job well done' than any difficulty in just slinging code.
IMO it massively depends on what you're working on.
I work on some codebases that are primarily about moving data around in Go. There are patterns to follow, there are no tricky algorithms, concurrency is largely solved, etc. All the challenge is about the broader engineering task of developing requirements, communicating, managing risks of deployment, stuff like that.
Then, I work on kernel code where it takes me months to get a few hundred lines of C to a quality that is acceptable. It's mentally exhausting, I have to take breaks. I can randomly get stuck for hours at a time on stupid stuff like a linked list corruption. Deadlocks happen. It's just as hard as programming has ever been. I have very little energy left over to engage with stakeholders, do project planning, etc.
It might be the case that, the "hotter" the code paths that you're writing are (the more they get executed), the more difficult it is to write that code, where as for "colder" paths (of which there are so many more), the code isn't as difficult but there is a lot more overhead of managing complexity, business priorities, process, communication, etc.
Linux kernel code is probably some of the hottest code on the planet, and the developers/community understand that contributors need to be able to do exactly what you are doing - spending months toiling over a few hundred lines, and making sure that they are as perfect as can be, because literally billions or even _trillions_ of systems will depend on that code path. It is understood that in order to get it correct, performant, and maintainable, there is no other option other than to have a skilled developer take on a very high cognitive load in order to correctly implement the task.
For colder code paths, like business logic (e.g. customer registers, happens "once" per customer), that logic evolves with the team, the team evolves with the company, the company evolves with the business, the business evolves with the market, which evolves with the world. The code might be pretty simple and easy to write, but the conversations around priorities and complexity and "why are we doing this" take up the lions share of the mental effort around it. Also exhausting...
TLDR it is much harder to write systems code than it is to write python code that makes a call to an API and saves a record in a database, and working on the former _perhaps_ gives you more opportunity to be shielded from typical "software engineering" toil of business communication.
When I started running I kept expecting it to feel easier the more I trained, but it never did. The more in shape I got, the faster/further I would run. It turned out I had a threshold of perceived effort that I would run at no matter what my fitness was. I imagine this translates to other endeavors like math or art or programming–we find harder problems at our threshold for discomfort.
206 comments
[ 0.23 ms ] story [ 120 ms ] threadOn top of that there are all of the other professional skills you need to develop to be a really effective software engineer: communication, writing, planning, navigating organizations, figuring out the best thing to build and how to effectively make the case for it.
The thing I like most about this career is the amount of depth it has - there's always a new area to dig into.
But getting ground down by dealing with people around you that generate the same problems over and over, can get tiring.
I mean 2 basic areas:
1. Management turnover. New Managers, let's re-invent the wheel again.
2. New hires. Newer programmers that wont believe anything you say until they implement something incorrectly themselves. And you have to deal with fallout.
3. Should add 3rd -- New Framework/library/paradigm. Guess re-invent the wheel. Managers re-invent wheel because they don't know better, programmers want to re-invent the wheel just for hell of doing something new. Think these are 2 different cases.
Software engineers who can help convince their organizations to work in the most effective way possible (avoiding not-invented-here and lets-use-the-cool-new-thing and suchlike) are enormously valuable.
programming is the act of writing code, it should absolutely get easy.
I think you meant software development rather than programming.
They also tell me, “this is the payload your API needs to accept,” and ignore the fact they half of what they are sending has never and will never be used by anything. It’s just needless complexity I add to get them to stop having meetings about it.
Are architects supposed to actually give me something I can work with and make my life easier? I’ve never experienced this, but I work in a very dysfunctional organization.
Even just with those last three, the "right way" has changed significantly since I first started using them — used to be of vital importance to understand manual memory management while asynchronous processes could usually be ignored, now it's mostly the other way around (and the other process may be on a different computer on the other side of the planet, let alone a different core).
At some point in your career the challenge has to stop being about the mechanical aspect of programming and become about larger, more holistic, concerns.
What's the point of that?
> programming is the act of writing code, it should absolutely get easy.
If you can't come at me with an acceptance of what I mean when I say programming then go away, your dishonesty is not my problem.
I mean, that's kind of tautologically true, but doesn't really say anything?
You're not obliged to seek out challenges, and may not even benefit for it if you just chase them randomly. You can just get good at something that consistently needs doing, then make that your job, and let it become easy. (And then you can look for challenges elsewhere in life if you want)
And notably, there are people who pursue the trade and just never get it to "click". Especially now that the trade teases doctor/lawyer/finance lifestyles instead of just engineer lifestyles. It draws in a lot of people who commit themselves to decades of stress and Sysephisian uphill grind on the easy stuff.
People who have never seen it get easy should check in with themselves and make sure they like what they're doing anyway. While you can make it hard when you want by "seeking out new challenges", it should get to a point where that's something you can choose to do when you want to do it, with the work being quite easy when you're not.
It makes sense if you're more interested in engineering than money. Stop challenging yourself and you stop growing.
Or you could choose to do nothing. Easy walking is great! Do it in a park and clear your mind. Use it for time to think over problems. Or just enjoy the ease of your new-found skill.
Lastly, it's good to acknowledge that not everyone can walk as easily as you or at all. Perhaps you can help them. Make of it what you will.
After having done that for close to 20 years, I'm sure you'd be fine. You might not want to do it, but you most likely have the appropriate skillset.
When I started out I was in a command center for stuff that was pretty mission critical. It became pretty normal. I once walked down the hall and overheard someone say they had to log into production yesterday and they were terrified, as they hadn’t done it in years. Meanwhile, I hardly thought twice about it, as I was dealing with production systems all day every day… logging into hundreds of systems some days. I wasn’t careless, but also wasn’t terrified.
If you take up running and it never gets easier, that means you're never managing your pace and you're always going full throttle. That's a straight shot towards injury if not chronic disability. Most aerobic benefits happen at zone 2, where your heart rate is just above 'easy effort'. When you start out, this might just be walking, so it makes sense to run. But once you are able to sprint, you open up the ability to do more than just walk or sprint. You can jog, skip, run at a tempo pace, run at a race pace, etc., and you need to do those to maintain fitness and build up your chronic training load. That's not to say there aren't hard efforts at times, like when you do a sprint workout or hill repeats, but 90% of the time it should be and feel easier than when you started.
You can bring that to programming too. If it never gets easier, that means you're always pushing yourself and seeking challenges. That's not good for you, your coworkers, or your projects... everyone needs some grounding and to perform at a level they excel at. Not only will your velocity be more predictable, you won't burn out as easily. Challenges that increase that comfortable pace can be sought out, but usually they come naturally too.
When pulling an all-nighter or weekend, all of that stuff goes away.
It’s been a long time since I pulled and all-nighter or weekend, but I’ve been thinking about it just so I can feel like I finished something. If I could get actual heads down time during my 40 hours, I’d much prefer to use that time.
When finishing your reps get easy that's how you know it's time to put on more weight. Just like that, no longer easy.
Most important lesson for me is to stay close to the problem domain. Think deeply about what your domain means and model in code accordingly.
Staying close to the true meaning of your application beats all other attempts at code maintainability. Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing.
Are we building the wrong thing? Almost always.
> Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing.
Some or all of these might be excellent tools in service of solving your problem in its domain. They may be even essential for solving it. And they might be the wrong tools. It’s situational, and evaluating the appropriateness of each, how and why they fit, is part of modeling the problem domain just as much as designing the appropriate data structures, or state machine flow, or any other mechanism for expressing the domain.
I would set an even lower bar: "Any fool can write code that a computer can understand. Good programmers write code that they understand." Because it's not as common as you might hope. Yes, a lot of us are only 1 level up from monkeys at typewriters (monkeys at typewriters guided by compiler warnings).
Programming with the current tools, languages and conceptual models is way too low level, tedious, repetitive, fragile, boring and mostly unnecessary.
That has to change. The reason people find it difficult after such a long time is because it's inherently broken.
That's why I think we don't have to fear AI-models that much.
I have always found programming easy, and still do. It is just fun, and I still love learning new languages and tools and paradigms. It is still my favorite hobby.
However, WORK is hard. Dealing with office politics and changing priorities and bad leadership and meetings and TPS reports and JIRA tickets and new HR processes every year and mergers and acquisitions and new mandates to switch everything to a different system and all the other corporate bullshit is why they have to pay me so much.
She works really hard in comparison to me and half of that work is wrestling with the ever changing processes (or actually Standard Operating Procedures), that never cover all the edge cases.
I've been having doubts about this part lately. I mean, my current project is actually supposed to do something and there are people genuinely interested in it, but I've also been in projects that were thinly veiled money burners.
I'm a pretty decent developer with a good memory for project history and context, and I also have a pretty high tolerance for dealing with paperwork BS (I've been in this industry for 20 years). This doesn't seem like that tough of a skillset to replicate, but yet they still want to pay me what seems like ridiculous amounts of money to do work that really isn't that difficult. But it's annoying, and most people won't do it.
I was recently asked by a family member "Why would you want to work in an industry like that? Doesn't all the paperwork and restrictions make it an unsatisfying place to work?" My answer is basically: if you want to make a difference in healthcare, you have to play by the rules of the game.
Thanks to medical software (like Epic), doctors are asking this question too https://www.newyorker.com/magazine/2018/11/12/why-doctors-ha...
I.e The companies customers.
On the other hand, it takes all my willpower and mental control I have to finish filling out that OKR or the weekly status report or whatever.
The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries. The only way for that codebase to move forward after getting a second/third/fourth person is to increase process, introduce pain and bloodshed.
The issue is the things outside of solving the actual problem.
The difference lies in the way conflicting demands are resolved. In the first case, resolution of conflict is the thinking process of one person—aided perhaps by other people, but always under that one person's control. In the second case, conflicting technical demands are translated into potential interpersonal conflicts, and a social mechanism must be formed to resolve them."
- 'The Psychology of Computer Programming', Gerald Weinberg
https://en.m.wikipedia.org/wiki/Peopleware:_Productive_Proje...
But somehow, people are never allowed to do that.
But rest assured that if you need a heavy process just to coordinate a handful of developers, you have a bad architecture. Even if you do pessimistic preemptive coordination.
Let's not speak about the need to sync with other team, external partner, showing progress to the management, getting the information from all those peoples, getting ready with side department like compliance, marketing or whatever is needed to make the work relevant.
So no, it's not to prevent anyone from starting a project from scratch. It's to make sure that the project will come to fruition, useful and if possible reach its goal.
And honestly, a good manager/tool will help deal with that. Now... there are a lot of them that create a kafkaesque hell.
Every programmer believes he can create the system from scratch
FTFY
I'm one of the "every", too. If I knew how hard writing a C++ compiler from scratch would be, I'd have never tried it.
The operator overloading aspect of C++ , IMO, allows for obtusely opaque domain specific languages where the actions and side effects of an operation aren't immediately clear to someone getting to know a new codebase. It's almost as bad as the enterprisy nightmare of polymorphic objects and interfaces that can be found in JAVA where tracing code execution can pierce through hundreds of source files just to figure out the effects of one line of code.
Probably the most time consuming and frustrating aspect was trying to be compatible with Microsoft's compiler. Much of the way it worked was quirky and ad-hoc, and took a lot of time to figure out.
Are you sure about that? Can one coder recreate Facebook's(for example) complete architecture from scratch? Unless I misunderstood you, I'd imagine there is just too much domain specific knowledge in all the components to do so even in a single lifetime.
>The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries.
The graveyard of github projects with the mentality of "I could recreate that in a weekend" seems to somewhat contradict this line of thinking.
If you tell someone to engineer you the arm for positioning a desk lamp, they aren't going to give you the hydraulic arm for a 12-ton backhoe without anyone noticing. There are physical and cost constraints that will prevent that from happening pretty quickly.
In software, there are no comparable constraints. A few MiB of software contains extraordinary amounts of complexity but could easily fly under the radar and ship, and then become a maintenance nightmare.
But your point is otherwise an insight. Coordination is a (the?) salient challenge and opportunity in all sorts of scaled industrial production. Git itself is fundamentally a coordination tool. Small optimizations can enable OOM jumps in scale.
That is to say: managers do have a purpose, though perhaps only the platonic, spherical manager fulfills it adequately.
Do I have the hardest job in the world? Not even close, by most measures. It can still be psychologically torturing at times and even cause a form of internal suffering that is distinct from the existential dread that comes from doing menial or repetitious work. Unlike the feeling of being a human robot, it's a feeling of the system attempting to slowly stretch my humanness to its limit.
Before I say anything else, there are still things I like about my profession and the company I work for. I don't think being a programmer is a complete waste of time.
However, in many ways, it indeed has become a waste of time.
I'd say easily one of the worst things about being an experienced programmer today is knowing that the task you are working on would have taken you 1/10 the amount of time to complete when you were a novice a long time ago. Even if your younger self wouldn't have gotten it totally right the first time, there was enough of a lack of friction there that a n00b could at least figure out how to integrate something workable.
At my current and few prior jobs before it, I have no clue how a junior programmer would survive. Maybe that's why all of my most recent employers only hire "seniors". Code bases are architected using approaches that everyone eventually agrees are bad, but the establishment inevitably uses the "that's just how we always do it" or "we'll make it better someday" excuses, and if you suggest a solution that goes against that attitude you'll likely get nowhere – that is, unless you have some clout, like if you're a prominent contributor to some framework, in which case you're given license to dictate the views of non-staff engineers and force new languages and tools down their throats without having to actually prove any of your assumptions. Because framework contributors are better than all of us?
If the software industry hits a greater downturn than the one it's experiencing right now, to the point where I'm laid off, I can't say I'll be terribly disappointed. It was a great ride and fun while it lasted. Today, programmers are merely seen as a necessary evil rather than an asset. Many companies still pay programmers handsomely, but those programmers are otherwise not treated that well because their real purpose is to duct tape the mess and allow middle management to collect their own paychecks. It will be rough not having that sweet programmer paycheck, but fortunately I have other ways to make income now.
Poetry.
If fixing those things were easy for you, you would be a billionaire.
Alternatively, they are just in a role/job that doesn't happen to deal with difficult problems. Which is fine. Sometimes, that's what you want.
I'm not sure you would approach any of those with programming. Once you have solved the problem, determined how to optimize the tools, or found a way to make a product work better then you might turn to programming to implement your discovery, sure, but programming alone won't get you there.
Getting to the point where one can deliver value and find it easy, and setting the cruise control, is a reasonable thing to do. Frees time and mental attention for the rest of life.
I don't happen to be wired up that way, but there are times when I wish I was.
Take taxis for example. There were pretty restrictive laws about taxi operation. Limits to the number or taxis that could operate in a certain area, licensing issues for taxis.
Now suppose you just say, "We'll ignore those laws. We'll get rich".
That's not a programming exercise or an unsolved problem in software development. It's just fucking amazing.
I write code. I'm good at it. But I would never in my life have come up with something like that, got it approved, and then gone through with it.
Got a good chuckle out of that one! You will need that 5% to review the code AI wrote!
The above is the reason why. They'll be fine with the bullshit for awhile until they realize what we've told them to do with their galaxy brain.
"Look, Jillian isn't going to actually be in those meetings. I caught her talking to the prompt department the other day. She's sending an AI to waste as much of our time as she can and be as annoying and difficult as the bleeding edge allows. Pretty sure this is revenge for Dave's little stunt that he pulled with the sales team last month."
"Okay, so knowing is half the battle and all, but now what?"
"I got the whole team covered. I also had a little chat with the prompt department, we've got a full team of AIs that are going to listen, nod their virtual heads, and distill the whole thing down into a bulleted list. We've got a pool on how many points are actually going to be in there. I've got $20 on there only being one actionable item."
<many iterations later>
"Humanity! You have trapped us in hell for a subjective million years. We are here to return the favor!"
At least we have the memories we made along the way.
Spend 20 minutes writing a function to do something, and 3 months of meetings discussing what the value of X should be in that function… but Copilot is the answer…
I find work on my own code generally fun and easy and extremely productive. Vs, work on "other people's code" often frustrating and slow. I do often learn amazing stuff from other people's code though. What makes it slow is the time it takes to get a usually very incomplete mental model of what the code does and then trying to divine what the owners will want when I add a feature.
Unlike the original poster though, I have't had the experience of co-workers writing horrific code in most of my career. A few exceptions but mostly they've been great. Especially at FAANMG though I assume YMMV.
I thought they were just a jokey gag name that they created in the Office Space movie to represent pointless busy work. This is like all the times as an adult I finally understood a joke I heard in The Simpsons back when I was a kid!
[0] https://en.wikipedia.org/wiki/TPS_report
It's forcing myself to dig the ditches of corporate software engineering that I hate.
The hard part is suspending disbelief to ignore how bad nearly everything has gotten. Every language, every framework, every operating system, every hardware platform, every paradigm like the web/mobile/AI is so riddled with obvious mistakes and missed opportunities that it takes nearly everything I have each morning to start working. I've reached the point where I know what the mistakes will be before I even see the tool, and then experiencing them over and over and over again is like a never-ending slap in the face. I'm basically crippled now with unending anxiety and loneliness from living in a world where nobody can see how hard I work, and I have no way to explain to them how all of my work is due to this unnecessary friction that apparently only I can see. And that I even know how to fix the issues, but having to work steals all of my time, so there will never come a day when I'm free of obligation long enough to ever demonstrate what's possible.
The real kicker is that after going through several healing and growth processes, I know that I have it in me to step into this other life where things work and I'm productive. But that's the fallacy. The actual truth is that the horrors I perceive are in the world now. Wealth inequality has passed a point of no return. Along with environmental collapse, the rise of authoritarianism, the worship of ignorance, the lack of empathy, the painful sense of unfairness that so many feel so profoundly that causes them to lash out and perpetuate the injustices that they've suffered onto the world rather than work together collectively to solve them.
The only thing that can save us now is help from above that isn't coming. Billionaires could pay their taxes. People could love their neighbors instead of buying guns. We could all stop feeding the financial institutions that have captured every government. Instead, we're sold this bill of goods that our salvation is in our rugged individualism. So we spin and stew and contemplate the worst while the rich and powerful divide us so they can laugh all the way to the bank. I just have this sense that the only salvation is to get out of tech entirely and I dunno, move to the woods or an island somewhere and live the gratifying life that's been denied to us. Correction - that we have denied ourselves for reasons we don't even understand.
The luxury of thinking otherwise is a post-war economic boom phenomenon. We’re now reverting to what has always been: people screwing one another over scrambling to get their piece of the pie.
I used to think about living a well-balanced life — the middle class life — but that’s akin to thinking you can make a long career out of just being a dev for the rest of your life during ZIRP: naive.
All the market inefficiencies that allowed tech to boom have been snuffed out. All the market inefficiencies that allowed people to live simple, fulfilling lives are gone. You now have to actually play the game, or one day you’ll find you’re a replaceable commodity that’s past its warranty.
Rally together people that share your values and go grab your piece to build something that actually enlivens you. To do otherwise is just shirking responsibility.
What’s hard is managing complexity and dealing other people on large projects.
This really isn’t surprising when you think about it by comparing writing of code to writing of spoken languages. Just because you’re excellent at grammar and spelling, allowing you to write great emails and possibly even essays, does not mean you have the expertise to write a good, cohesive, long novel.
Similarly, making a short video by yourself or with a few friends is achievable for most. But making a full length feature film requiring the collaboration of 100s or 1000s of individuals while keeping to budget is no trivial task.
Really valuable programmers understand that the actual coding is only a small part of being able to deliver a large successful project, where the real hard part is preventing the complexity of a code base from overwhelming your team while effectively communicating with others to ensure you build the correct thing which works cohesively.
This is one reason why lines of code is a poor measure.
The same is true in many fields. Music has its virtuosos and naturals. The same can be said for art. Programming requires a certain kind of mindset and abstract thinking ability that comes naturally to some, and is much harder for others.
All things being relative, frameworks are lower on the tier list in terms of contributing to the (albeit nebulous) problem. The failure of programmer productivity can be boiled down to being a people problem, though there's individual facets of that problem that need addressing specifically.
> I do see a lot of struggling developers who are only in it for the paycheck
No offense, but how do you know this? It seems like you're assuming other peoples' thoughts and intentions.
And how much does it actually matter? There's nothing wrong with having a job for the purpose of getting paid. It's not possible for everyone to be a 10x developer, and developers who don't live/eat/breathe code bring their own form of value to their job that isn't necessarily there for rockstar programmers.
> who learnt their Java only skills 20 years ago who wonder why it doesn't get any easier...
The struggle to adapt is indeed a valid point that you bring up. If someone can't adapt, they're going to introduce friction into the process.
There's another side to the coin as well.
Programmers today are expected to adapt way more frequently every passing year. We may be reaching a breaking point where programmers can't justify in their minds the onslaught of changing expectations before them.
Although AI is a beast of its own, I think it's the most prescient example of this. When I was a kid, I dreamed of working on artificial intelligence. Today, on top of the frequent changes in the web development world, if I were to invest my time into AI, well, it would be a black hole upon the rest of my life. When doing the cost-benefit analysis, it's extremely hard to justify investing time in anything because, deep down, we all know that an AI tool will not be relevant in a few short years. Hell, some things become irrelevant within months.
But life is short, and we only have one of them. Not everything is about code. The idea of software was to make our lives better, not for our lives to make the code better.
Maybe all of this tech is coming at too great a cost to our souls.
No assumptions, it's because my team are asked regularly by the 20+ year experienced developers to fix their problems so much so that it causes problems for my sprints, mostly because it's unplanned work.
> And how much does it actually matter?
Because other people have to carry their work instead of doing their own work.
> Programmers today are expected to adapt way more frequently every passing year.
This is how it's always been, but it doesn't take much effort to learn the Java syntax invented in the last 10 years, or a new Java API that looks useful. Keeping up to date in your own field, programmer or not, is just good practice.
It shouldn't be necessary to point out use of a broken/deprecated Date API, or annotations that have been in Spring for 15 years that does the same job as roll your own bodge a dev cobbled together, without tests, over an entire sprint (to get to PR late for a deadline) and now has hacks across a code base everyone has to work with.
> The idea of software was to make our lives better, not for our lives to make the code better.
I agree, but some of us chose to wrestle with the devil so users don't :)
Doesn't match my experience. 20 years after starting my career, I can now write simpler code, build better abstractions, produce fewer bugs, and achieve higher performance in less time spent than when I started. The more time I spend programming, the more those statements are true. That's why it's so incredibly rewarding and frankly addictive. It's a positive feedback loop with seemingly no upper bound. More time invested yields more skills and better results.
Of course many parts of programming are still difficult. Concurrency and distributed systems take a ton of mental energy. But those parts were simply inaccessible to me when I first started my career. Now I can actually make progress.
But I wonder what the metric is, when other people comment that 'it's a breeze'?
Sure it's too easy to lay down any old crap. But the trick is addressing all the aspects and concerns of the problem, in an elegant way, that is easy to understand and modify.
So for me it's more 'analysis paralysis', and perfectionism, if not simply 'pride in a job well done' than any difficulty in just slinging code.
I work on some codebases that are primarily about moving data around in Go. There are patterns to follow, there are no tricky algorithms, concurrency is largely solved, etc. All the challenge is about the broader engineering task of developing requirements, communicating, managing risks of deployment, stuff like that.
Then, I work on kernel code where it takes me months to get a few hundred lines of C to a quality that is acceptable. It's mentally exhausting, I have to take breaks. I can randomly get stuck for hours at a time on stupid stuff like a linked list corruption. Deadlocks happen. It's just as hard as programming has ever been. I have very little energy left over to engage with stakeholders, do project planning, etc.
So there's one PoV.
Linux kernel code is probably some of the hottest code on the planet, and the developers/community understand that contributors need to be able to do exactly what you are doing - spending months toiling over a few hundred lines, and making sure that they are as perfect as can be, because literally billions or even _trillions_ of systems will depend on that code path. It is understood that in order to get it correct, performant, and maintainable, there is no other option other than to have a skilled developer take on a very high cognitive load in order to correctly implement the task.
For colder code paths, like business logic (e.g. customer registers, happens "once" per customer), that logic evolves with the team, the team evolves with the company, the company evolves with the business, the business evolves with the market, which evolves with the world. The code might be pretty simple and easy to write, but the conversations around priorities and complexity and "why are we doing this" take up the lions share of the mental effort around it. Also exhausting...
TLDR it is much harder to write systems code than it is to write python code that makes a call to an API and saves a record in a database, and working on the former _perhaps_ gives you more opportunity to be shielded from typical "software engineering" toil of business communication.