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).
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?
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.
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 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.
Readit News
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).
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 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.
Deleted Comment
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.
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.