After 14 years in the industry, I still find programming difficult
piglei.com
piglei.com
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.
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.
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.
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.
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.
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.
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.
- 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.
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 of the replies I am seeing here seem to have treated the article's title as a writing prompt.
Read the whole article friends - it's got a nice amount of nuance and the author unpacks what they mean by "difficult" very well.
I also appreciate it that a submission with a small amount of upvotes has a discussion going.
I, of course, knew what you meant.
Amusingly, https://www.google.de/search?q=what+does+tfa+mean shows https://news.ycombinator.com/item?id=19781756 as the first hit for me.
btw, I didn’t read TFA. Will do
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.
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.
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.
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.
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 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...
The issue is the things outside of solving the actual problem.
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.
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.
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.
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.
Got a good chuckle out of that one! You will need that 5% to review the code AI wrote!
At least we have the memories we made along the way.
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!"
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.
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.
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...
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.e The companies customers.
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!
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.
It's forcing myself to dig the ditches of corporate software engineering that I hate.
If fixing those things were easy for you, you would be a billionaire.
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.
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.
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.
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.
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.
Great read, I just had to point that out though.
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.
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.
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.
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.
> 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.
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 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.
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.
If I had a few hours to spare I could come up with much more.
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.
[1] https://www.amazon.com/Soft-Skills-software-developers-manua...
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 :)
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.
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.
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.
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.
That's why I think we don't have to fear AI-models that much.
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.
The more interesting endeavor is to make the complicated simple.
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.
Keep in mind I'm juniorish so others may have much better ideas about this.
Programming can be made easier with LLMs. I'm working on this: https://aiconstrux.com.
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).