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.
> 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.
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.
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.
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.
A lot of these points are why I still enjoy programming as a hobby, but less so enjoy it as a profession. It is much easier to program something where you are the only customer. No project manager alternates between asking me increase and decrease the number of story points per task. No one comes with a last minute request to create a throw away demo for some executive who can only understand pointy-clicks things.
Directly addressing the title, one thing I still find difficult in programming is implementing an informal parser. Think calling read(2) and parsing an HTTP request. Making something work with partial reads and multiple buffers is tricky. I really should reach for a real parser sooner in these situations is the actual answer and stop trying to work at such a low level of abstraction.
What you describe as annoying about your experience sounds like a case of stakeholder management rather than frustration with programming. But I totally agree with you too.
This kind of task is a great fit for a parsing expression grammar. Unfortunately most implementations are awkward to use and suboptimal in execution, but if you can find one which is neither of these things (they exist) it's ideal.
Here's a little secret: everyone finds programming difficult. Sure, programming itself is easy. But in the real world you can't just program, you need to work as part of a team with people who have definitely, definitely, definitely never read (nor will ever read) Hacker News. Even if you beg them. Even if you pay them 200k/year. And they will write bad, undocumented code that you need to deal with, or worse, they're managers and will penalize you for trying to write good code the first time and promote those who write horrible code quickly (but need to fix it five times, finally getting it right after many months).
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.
> The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.
- Brooks, Mythical Man Month
I always take inspiration from this quote, both when times are good and when times are bad. When programming is easy, ah how just like glorious poetry it can feel. Natural and easy. When programming is hard, boy what exertion it can take to wrangle thoughts and ideas. Writing poetry when the creativity isn’t there, whatever it is, is just torturous.
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.
I feel quite a lot of people on HN simply react to the titles and that's it. Many people on HN also only read the comments. I know I do. I also sometimes read the post, it really depends.
I also do that most of the time but the title was so off I just had to take a look. I was pleasantly surprised, very thoughtful and fully recommend reading it in its entirety.
I remember reading analysis showing that there is a high correlation between the order that comments are posted and how many votes they get, i.e. early comments tend to get most voted. I guess people are gaming the system by commenting quickly. Who has time to read a 10 min article and comment when you can not read it and post a platitude?
I don’t think that’s it. When I comment early, it is not to game the system. It’s to kick start a discussion around the title. Or I am intrigued about something by the title and then it’s fun to go on a bit of a tangent.
I also appreciate it that a submission with a small amount of upvotes has a discussion going.
I also disagree. Sure, there are still hard problems, but for the most part, I think it's pretty easy. People from past jobs tell me my work is super straightforward so I don't think I'm tripping.
Even the other things like writing documentation or being in meetings is fun. I got into this field (well, I got an EE degree) because I like engineering and building things, not specifically programming, and meeting with people to figure out what the hell we want is at least half of engineering.
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.
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.
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.
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.
“ 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.
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.
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.
>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.
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.
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
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.
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.
"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!"
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.
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.
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?
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.
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.
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.
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 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!
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.
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.
> 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.
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.
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.
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.
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.
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 really enjoyed this and it has lots of great lessons.
One small point though. I noticed this paragraph:
“From a certain perspective, software is inherently designed to be modified (why else would it be called "software"?). This makes developing software fundamentally different from building houses. After all, nobody would say after constructing a building, "Let's knock it down and rebuild it! The same structure but with 30% less steel and concrete!"”
It’s odd to me the author doesn’t see the connection from the instance of the software and the code. In this example, the instance is the house and the code is the blueprint. Code and blueprints change ALL the time. So I think it is false to suggest software engineering is somehow different from other engineering disciplines. I’d say it’s exactly the same but with a whole lot less ethical considerations, largely due to reasoning like above.
Programming languages are also becoming more user-friendly. Classic languages like C and Java are no longer the first choice for most beginners, and many simpler, more accessible dynamic languages are now popular. The IDEs and other tools have also improved. Together, these factors lower the learning curve for programming.
I doubt it. Nowadays to start programming you need to set up complicated run environments and other setups even before you begin to code something. Programs are more complicated, such as apps which involve front-end and back-end. These games that claim to help with programming only hide the actual programming or abstraction . People think they are coding but are not really coding. Moving boxes around is not coding.
"But wait, you have more experience and we have better tools!"
Yes, but programming stacks used to be simple and well-defined.
HTML/CSS/jQuery + a LAMP stack or ROR could get you a long way. Baring IE bugs, it was possible to 1) develop without constantly using Google 2) understand what every line of code does 3) be quickly productive, which was very satisfactory.
These days, starting and deploying a new project involves a kitchen sink with a bazillion tools, languages and 3rd-party dependencies. And when something doesn't work the way you expect it to, it's a ton of work to find the needle in the haystack, with so many layers to understand, especially since they don't share any consistency whatsoever.
Programming is a grossly general concept that doesn't really have a precise meaning anymore, if it ever did. Especially these days, programming is associated with developing CRUD or web applications, which make it sound like an easy thing to do and which is relatively easy, at least conceptually.
However, programming will be hard if the thing that you are programming for has enough (essential) complexity and there is no way around it, even if you are experienced. Some examples where I found programming to be very hard include
- Programming a microcontroller that has a 1400-page reference manual and many conceptually difficult things that you would have to manage.
- Taking pseudocode of an algorithm from a research article and turning it into professional, commercial code while handling all the edge cases that were never considered in the article. I believe it was Donald Knuth who claimed that the correct implementation of some 50-line sort algorithm took 30 years to get it finally right.
- Constructing the state machine of a complex-enough system and implementing it in code. Take David Harel's Statechart paper, for example, where he builds the state chart of a "simple" Casio wristwatch. Building such a state machine and implementing it in code will always be hard, even if you have more modern tools.
So, to reiterate, programming does not just mean downloading some npm library and making API calls to it. When I see comments like "Programming now for 30 years and it's a breeze to pick up new frameworks and ideas", I wonder if people have a very narrow definition of what programming is.
I'm happy to say that my company writes "good" code, at least on the production side, and I have genuinely learned a ton and become a better engineer while working here. The experimental, test, and sometimes CI code is shit. Test code makes sense, it's immature prototype. CI should be much better than it is, it's extremely fail-safe and its false-positive rate is a major headache for the entire software org. But our production code is genuinely very good. You won't get a PR merged with literals in code or custom functions that could be replaced by STD functions or unnecessary copy operations, or without thorough design documentation and comprehensive unit tests and CPU load test results and a review of the effects of your change on near and distant stakeholders. (Our code could literally kill large numbers of people, so it's a good idea to maintain these standards.)
Previously I worked for half a dozen early-stage startups that wrote super-janky demo code that would have to be power-cycled multiple times to get to a fully operational state and no one at the company had more than a year experience outside academia so founders didn't see a problem with that level of reliability. In those roles I learned a lot about math and dealing with giant egos, but not much about software engineering.
Point is, there are companies who rigorously enforce good code requirements, where you can learn from others and improve your skills, where "good code" is the norm.
Great points, and I'd like to call out one section in particular:
> What is good code?
Missed one that really needs to be articulated: Correctness.
Poor correctness is one of the most harmful and widespread problems in software today.
Even one of the most wealthy and best-paying companies cannot manage to deliver an acceptable level of correctness for some of the most widely-deployed Internet-facing software: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome
And that company is arguably better at software engineering than the majority of companies.
The takehome isn't "even Google makes software littered with critical defects, so I guess that excuses everyone else, lol". But rather, that most of our engineering field hasn't been held responsible for correctness, and now we routinely knowingly deliver engineering work that we assume has critical defects. And we show no remorse: even when some software is routinely shipping multiple security vulnerability patches per week, we keep doing the same shoddy engineering, sustaining the gushing pipeline of vulnerabilities needing patching.
> As "wordsmiths," programmers often neglect reading. However, reading is an essential part of quickly improving your programming skills.
I'm always surprised to hear that most programmers dislike code reviews. I've found code reviews to be one of the most useful ways to learn new design patterns and language features. I personally believe that adopting a mindset of curiosity helps make code reviews enjoyable rather than tedious.
The biggest thing is people have bad experiences with reviewers, and people have a lot of insecurity when their work is scrutinized.
The biggest issue with code reviews as a process is it's always positioned as being adversarial. Often, you set up a pull/merge request, and someone later does a review, but it's not personal, it's cold and blunt data. Even with a reviewer who has the best intentions, it's tough.
Pair programming and review can _help_ with this. Sit with the person who wrote the code, and review together.
I'm with you, code reviews are great for learning, but like you said, you need to see it as a tool to help you succeed and learn, and not as a tool to show you how you're wrong.
At a previous place our code reviews just turned into a quick glance at the code without a real understanding of anything. On one hand I'd like to say it was built on trust in the engineer and test suite, on the other, there was just so much complication and tediousness in some things we did that it was hard to know what was going on in the first place.
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.
23 years of solid experience in programming. The hardest parts for me have been:
- integrating with other systems, often APIs. The difficult part is the constantly changing API contracts, which break integrations in often unpredictable ways
- Leaning new libraries or frameworks that often reinvent the wheel for no good reason
- Understanding the deep layers of abstraction in some systems (be it a DSL, a transpiled language, pipelines, etc.)
- Training or mentoring incompetent engineers who probably choose the wrong profession. This can be exhausting and time-consuming.
- Learning the soft skills required in some types of environments or contracts. Programmers often don’t have the best skills for interacting with stakeholders or leadership, and I have learned this the hard way on many occasions. I have worked very hard on developing my soft skills and it has paid off, but it took a lot of time and effort.
- Context switching. I can context switch like a boss now, but it took me about 10 years to master this.
If I had a few hours to spare I could come up with much more.
Painfully aware that my soft skills need improving but I'm not sure where to even start. I've started prepping more before important meetings but I'm easily so lost in code that I forget meetings are even happening sometimes.
The simple answer is that you need to ask yourself why somebody would pay for what you create. This leads to thinking about market demands, user experience, etc., and you will learn to argue from the customer’s and user’s POV. Then again you’ll ask yourself why you’re not self-employed because you’ll realize most of your managers aren’t good at this stuff either.
I read (listened to) a book on soft skills for developers[1] years ago. It was a pretty quick and easy read (listen). It might be helpful to call out some areas where you might be lacking, to make you aware, and then give you some ideas how to tackle them.
For me, I ended up in the business school when I went to college. That probably did more for my soft skills than anything else. It forced me to learn out to write things that were more than 2 sentences long… not through a class or direct teaching, but by necessity. I always try to think about my audience when I do anything. Who is a presentation for, who is an email to, what am I trying to convey? In sprint demos to those who will consume things I make, I don’t get technical at all, I focus on the value it will provide to them. How will it save them time and toil? How can they consume it? That’s what they care about. It doesn’t matter how technically impressive something is if people can’t consume it, don’t know how to use it, and it doesn’t help them in some way. Some of my team members didn’t like when I tried to sweep their tech talks under the rug, but our stakeholders said we had some of the best presentations in the company as a result. We didn’t bog them down and lose them in jargon, and instead we focused on what mattered to them. We saved the tech talks for internal presentations with people who would get value from them.
The same goes for your boss. Your job is to make your bosses life easier. Do that and you’re golden. Make their life harder and it will probably be reflected in reviews. Always try to put yourself in the other person’s shoes.
If I need to prep something for a future meeting, I try to do it right when I hear about it and it’s fresh in my mind, before I get distracted and it becomes an item on my backlog. Then I stick it somewhere I know I can find it when it’s time for the meeting (or send it out before the meeting so people have a chance to review it). In terms of image within the company, I think this stuff matters a lot, so I raise it high up on my priority list. Plus, if I’m not prepared for the meeting, it means I’m wasting other people’s time, which isn’t good. Even worse if it means we have to have yet another meeting.
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...
> 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 :)
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.
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).
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.
I think the hard part of programming, or programming related things, is environment setup.
Even with things like Docker, you can still run into SO many issues.
Programming by myself is always easy.
Programming within a company can be difficult because of this. There are definitely places out there that make environment setup super simple. Even then, you can still run into something that hasn't been encountered before.
Also just slow, fragile environments once they are set up.
At a previous place I worked, tests would be slow, builds would frequently break and you had to recite the correct incantation of commands to fix them again.
We had a common saying: whenever someone would say their build process is broken, we'd say "ah you must have pulled master".
Environments that are fast, stable and get out of your way are a godsend. Unfortunately when working in a monolith, everyone's special build changes are shared with everyone else. Then those build changes break things.
It's worse when you get heavily invested in 3rd party APIs or some forms of "serverless." If you don't think about having a local environment ahead of time, you may never have one. Productivity drops like a rock. I've seen guys editing AWS Lambdas in the console. It's incredibly unproductive.
The more you know the harder it becomes. An inexperienced programmer will dash off thousands of lines of toxic waste "code" in a day. An experienced programmer knows that every line is a burden. The goal should not be to return to the false illusion of productivity, but to embrace the true nature of the task.
> 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.
On the topic of good code, yes it should be understandable to the reader. I used to think about good code in terms of various principles and maxims, but with more experience I feel like the story of requirements is overlooked. When requirements were static from the beginning and easy to understand for all parties you can get good code. It kind of exists in a bubble of stability. And when you reach for it again the stableness is unchanged so you just forget about it and it becomes part of the background noise. Much of the time the tech debt and weirdness of codebases I encountered in the wild is a reflection of an untold story of how requirements changed and miscommunication between the parties involved
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.
Generally, I think of programming as about managing complexity. Simplifying and ranging the tangled objectives, tying loose ends and integrating with even more complex systems.
So, naturally, as one progresses in the field, the level of complexity often increases with experience. Sure, some tasks become easier, but those are getting assigned to 'juniors' or just are no longer interesting...
Here it is, more experience, yet still uphill with complexity. It does get tiring at some point.
I like the comparison to writing. In order to be a better writer, you must read works that are well written. The most common way that I read code are by traversing my source tree into the code I depend on (stdlib/third-party). When dependencies are compiled in some way, reading the code is not possible. It makes learning different code patterns impossible and causes a lot of "reinventing of the wheel"
I also have been programming for 14 years, whole career is spent on Android and iOS development, with a sprinkle of small web and API projects in between experiences. The difficult part is the annual deprecation and introduction of new features, APIs, phone, tablet, and OS versions. The early years this might be exciting but in my 14 years of Google IO and WWDC, it’s just hard to keep up with all the shiny stuffs.
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.
This is the problem as old as time. For one thing as you gain more experience your experience is deployed on gnarlier, more poorly defined tasks, which are naturally more difficult. For another, as yoy get exposure to higher level concerns you begin to care about them more. So no wonder it doesn’t get easier - hopefully the paycheck gets fatter over time
'difficult' is relatively meaningless, or I guess only meaningful relatively. Basically once you know something (e.g., a particular leetcode problem, or how to paginate an API) it's easy all of a sudden, but it was hard before you knew it.
The more interesting endeavor is to make the complicated simple.
I really, really agree. I learned programming on leetcode and took the short feedback loops and automated tests for granted. Then working on legacy software on legacy hardware without automated tests and lots of interactions with other programs and databases, that was a shocking reality check.
Well programming IS difficult. And a senior developer knows it. It’s easy enough to master C++ in a year, but ten years are not enough. So zen. What I mean is if you know your language enough, you will sometime realize you never know everything.
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.
The context width required for programming exceeds that of normal human beings. There is just A LOT of stuff to keep track of, it's not logic that's difficult that's the easy part.
Do you have any methods for keeping track of all the context? I usually go for a flowchart app and flowchart all the things and systems in order to better understand what's happening. I find the act of writing the flowchart actually helps me more than having a completed one.
I use Joplin/Typora and text only and I play detective few hours before I even have a clue what on earth is even going on. We run like 7 or so docker containers and the code is undocumented. So it's basically like descending into those maze like underground tunnels.
Keep in mind I'm juniorish so others may have much better ideas about this.
It's the never-ending complexity. Also sometimes the system just isn't documented sufficiently. You end up not knowing what a fix should be, for something related to what you're fixing, because nobody's touched that code in 20+ years.
> "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).
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.