It's very obviously not "the easy part", it's definitely hard. It's just not the only hard part. And there may be other parts that are harder in some sense.
It's very obviously not "the easy part", it's definitely hard. It's just not the only hard part. And there may be other parts that are harder in some sense.
Something can be hard and also be the easy part. Imagine you got to see into the future and use a popular app before it was released, and you decided to make it yourself and reap the profits. Would be an absolute cinch to copy it compared to trying to make a successful app from a blank page.
Some code is hard. Most business logic (in the sense of pushing data around databases) isn't. The value is in analysis and action, which the system enablrs, not the machine itself.
Creating a high performance general purpose database is hard, but once it exists and is properly configured, the SQL queries are much easier. They'd better be or we wasted a lot of time building that database.
Also totally depends on what kind of coding you are doing.
Yeah building a web app can become somewhat easy, but is distributed machine learning? What about low level kernel code?
Still easy. You just have to learned different concepts. Someone in web needs to be familiar with databases, some protocols like HTTP, DNS, some basic Unix admin,.. Someone in low level kernel code will need to know about hardware architecture, operating system concepts, assembly,... But the coding skill stays the same mostly. You're still typing code, organizing files, and fiddling with build systems.
Different type of "coding skills" and different type of complexities make these two impossible to put into the same bucket of "still easy". You've probably never done the latter so you're under impression that it is easy. I assure you it is not. Grasping the concept of a new framework vs doing algorithmic and state of the art improvements are two totally different and incomparable things. In 30M population of software engineers around the globe there is only handful of those doing the latter, and there's a reason for it - it's much much more complicated.
You are conflating problem solving and the ability to write code. Web Dev has its own challenge, especially at scale. There’s not a lot of people writing web servers, designing distributed protocols and resolving sandboxing issues either.
I'm not conflating one with each other, I am saying that "coding skill" when dealing with difficult topics at hand is not just a "coding skill" anymore. It's part of the problem.
Not knowing C after a course on operating systems will block you from working on FreeBSD. Knowing C without a grasp on operating systems will prevent you from understanding the problem the code is solving.
Both are needed to do practical work, but they are orthogonal.
Exactly but they are not orthogonal as you try to make them to be. That's just trivializing things too much, ignoring all the nuance. You sound like my uncle who has spent a career in the IT but never really touched the programming but he nevertheless has a strong opinion how easy and trivial the programming really is, and how this was not super interesting to him because this is work done by some other unimportant folks. In reality you know, he just cannot admit that he was not committed enough, or shall I say likely not capable enough, to end up in that domain, and instead he ended up writing test specifications or whatnot. A classic example of Dunning-Kruger effect.
There is a nuance in what you say. You say it is "still easy" but it is not. It is not enough to take a course on operating systems and learn C to start contributing to the operating system kernel in impactful way. Apart from other software "courses" that you need to take such as algorithms, advanced data structures, concurrency, lock-free algorithms, probably compilers etc. the one which is really significant and is not purely software domain is the understanding of the hardware. And this is a big one.
You cannot write efficient algorithms if you don't know the intricacies of the hardware, and if you don't know how to make the best out of your compiler. This cannot be taught out of the context as you suggest so in reality all of these skills are actually interwhined and not quite orthogonal to each other.
I do agree with you that there's a skill tree for any practical work to be done. And nodes can be simple or hard. But even if there are dependencies between them, the nodes are clearly separated from each other and some are shared between some skill sets.
If you take the skill tree you need to be a kernel contributor, it does not take much to jump over to database systems development, or writing GUI. You may argue that the barrier entry for web dev is lower, but that's because of all the foundational work that has been done to add guardrails. In kernel work, they are too expensive so there's no hand holding there. But in webdev, often enough, you'll have to go past the secure boundary of those guardrails and the same skill node like advanced data structures and concurrency will be helpful there.
Kernel dev is not some mythical land full of dragons. A lot of the required knowledge can be learned while working in another domain (or if you're curious enough).
No, it's not mythical but it is vastly more difficult and more complex than the majority of other software engineering roles. Entry barrier being lower elsewhere is not something I would argue at all. It's a common sense. Unless you're completely delusional. While there's a lot of skills you can translate from system programming domain elsewhere there are not a lot of skills you can translate vice-versa.
The easy part and hard are not mutually exclusive.
Honestly, it really is the easy part of the job. Really truly.
It's difficult when you're first learning but there are definitely much harder skills to learn.
99.9% of the code i write is easy, but that's just because of the sort of work i do. Its not far from basic CRUD. Maybe with pubsubs and caching thrown in for fun.
But that doesn't mean there isn't some tricksy stuff. All the linear algebra in graphics programming takes awhile to wrap your head around. Actually, game programming in general i find a bit hard. Physics, state management, multi threading, networking...
For most of the tricky stuff the hard part is thinking clearly. Deciding how to approach the problem, what to prioritize, etc
Translating that into whatever language you chose is not that hard.
Right, the actual engineering part is hard. Typing out the code without botching syntax usually isn't very hard. Unless it's a C++ type with a dozen modifiers.
What's easy for some might be truly hard for others.
Sure; but I'm not humblebragging at how talented at coding I am. I'm good at it because I have a lot of practice and experience, but I'm hardly the best.
It's the easiest part because the hard parts of the job are everything else -- you're a knowledge worker so people look to you to make decisions and figure it out. You figure it out and make it work for whatever "it" happens to be.
> It's the easiest part because the hard parts of the job are everything else -- you're a knowledge worker so people look to you to make decisions and figure it out. You figure it out and make it work for whatever "it" happens to be.
If you thought coding was easy, wait till you see the competition for knowledge workers. You're in a spot now where the part that made you valuable (implementing business rules in software) can now be done by virtually anyone.
Doing all the non-coding parts (or, as you put it, "the hard parts") can now be done by almost any white collar worker.
Sure, anyone with the knowledge and experience lol
"Knowledge worker" isn't a cutesy phrase, it means I don't get paid for my time, I get paid for what I know. Contrast that to, say, working retail where you are paid to staff the store from 8-6. It's not a value judgement (retail is hard work) it's a description.
We've already had years and years of predicting the death of software engineering to offshoring and that didn't happen for the same reason. India turns out plenty of fantastic engineers who can do my job. Those people also have better options than staffing some cut rate code factory, and you can't substitute the latter if you need the former. But nice try lol
> "Knowledge worker" isn't a cutesy phrase, it means I don't get paid for my time, I get paid for what I know.
What you appear to be missing is that (if AI coding is as good as we are told) there will considerably more people with the business knowledge to drive an AI to create their solutions.
The bit that made developers valuable was the ability to actually implement those business rules in software. You will be competing with all those laid off devs as well as those non-developers who have all that business knowledge.
In simple terms, there are two groups of people:
1. Developers, who have some business knowledge, and
2. White collar workers who have no development knowledge.
Previously (or currently, say) the supply of solutions providers came only from group 1. Now they come from both group 1 and group 2.
The supply of solutions providers just exploded, you can expect the same sort of salary that the people in group 2 get, which is nowhere close to what the people in group 1 used to get.
Yeah, nah, that's just a complete misunderstanding of what SWEs actually do lol
I'm not a code factory who occasionally talks to the suits. That isn't the job lol
> I'm not a code factory who occasionally talks to the suits. That isn't the job lol
The problem you are facing is that "person who talks to business" is a huge pool of talent, and now you have to compete with them. Previously your only competition was "person who talks to business and can code".
Nope, those people are not competition lol. I get that you want that to be true for some reason, but it's not.
I do not get paid to write code. No software engineer does. The more senior the engineer, the less code they write.
I don't even really talk to the business folks, that's what a PM is for.
I already told you what I actually do, you're free to read it and learn. Or not, I ain't the boss of you
"I already told you what I actually do, you're free to read it and learn. Or not, I ain't the boss of you"
Nobody listens to someone who talks like this. Nobody learns from someone who talks like this. You're not a leader and you're not a very good software engineer and likely if you boss anyone around, they think you're a clown.
The people for whom I've seen "coding is the hard part" are typically promoted out of the way or fired. They never entered a flow like those who considered it easy and addictive. The latter are the pillars of the eng team.
I'm curious which skills you think are much harder than programming.
It depends on whether you mean programming (typing your solution into your text editor) or programming (formalizing your solution to a problem in a way that can be programmed).
Honestly? Anything that requires a lot of manual dexterity because that takes a long time to master, like a trade or art.
People love to lionize it, but honestly I can teach the basics of coding to anyone in a weekend. I love teaching people to code. It can be frustrating to learn but it's just not that difficult. I've mostly written Python and Ruby and Node for my career. They're not super hardcore languages lol.
What is hard is learning the engineering side. I don't get paid for the code I write, I get paid because I get handed a business wishlist and it's my job to figure out how to make that business reality and execute it, from start to finish.
I tell my boss what I'm going to be working on, not the other way around, and that's true pretty early in your career. At my current level of seniority, I can personally cost the company millions of dollars. That's not even a flex, most software engineers can do that. Learning to make good decisions like that takes a long time and a lot of experience, and that's just not something you can hand off.
Totally. I would add that code that "works" it's easy to do. Code that it's efficient, easy to maintain and safe... That it's another story.
But the sad truth is that most software can be or it's done with shitty code that "kinda works" as long as the CPU it's fast enough.
And if you're in one of those jobs, you don't get paid the big bucks.