XSW's post and the computer engineering career path
I came across XSW's post (Computer science tumbling down) recently, and it's worth commenting on that because his/her thoughts do mirror those I had when I was a computer science undergraduate. Many of us chose it as a career path, because we enjoyed solving problems and expressing ourselves by creating software. Some of us liked experimenting with Linux internals, running our own servers and even making things with hardware. We were hackers, bascially.
But how did the proud traditions of computer science, and computer engineering, become conflated with Scrum development in a Silicon Valley 'startup culture' that continually enshittifies apps and uses JavaScript for virtually everything?
I'm inclined to agree with XSW that modern software engineering, for the most part, has very little to do with actual computer engineering, and the two shouldn't be synonymous. Thats not entirely the case, though. Early computer scientists spent their careers finding ways to apply computation to everyday problems, and their methods got formalised into programming languages. Over time, programming evolved into something increasingly abstract, and, unfortunately 95% of modern software engineering is about the abstractions.
At the same time, programming occasionally does involve an element of computer engineering, because the nuances of how a development framework uses system memory can have a major cumulative impact on a business. Habitually using List<> instead of IEnumerable<>, or not knowing about thread-safety, could crash a VM under load, for example. Also, being able to think in terms of algorithms and data structures has been a core skill throughout my career, so there's that.
People don't graduate as software engineers. They'll start out as software developers. Software engineering is a craft that can only be learned through years of experience and knowledge passed on by others who'd been doing it much longer. Sure, one could know about SOLID principles and rattle off their textbook definitions in a job interview, but knowing when and how to apply them is a craft. A former colleague of mine termed it 'codemanship'.
The next problem is that an engineer, at that point, would already be thinking about career progression, and career progression doesn't happen on Scrum teams. Scrum, probably by design, railroads developers into a very narrow skillset. The only way around that is to jump ship to a job that involves working with people across multiple teams, taking on responsibility for entire projects and getting an insight into the politics between senior engineers and executives.
That means there'll be meetings. Lots and lots of meetings.
'Moving up, the workplace bureaucracy creeps into your day, and eventually fills it. Meetings, meetings, meetings. [...] Project management. Agile Scrum whatever. How ironic is it that, to me, the career becomes less appealing the more senior one rises.'
Buraucracy is probably the wrong term, because the meetings are largely necessary. If you're a Scrum developer, you're going to be handed a definite set of requirements and produce software accordingly. Outside of that, it's a very different story.
An executive will have a vague idea for a product or service, usually as part of some strategy. She might want a legacy system replaced by something more efficient and cheaper to maintain. She might want a system migrated to AWS or Azure. She might have been persuaded to buy a vendor-specific platform that somehow needs to work with existing systems. Decisions like these will be disruptive in an organisation where everything's a dependency.
Someone will need to work out the finer details of what that's going to look like, and precisely what the requirements are. Systems architects will be debating which technologies can and should be used. By the time it gets to someone like me, there'll be a myriad of questions: How long would it take, with the resources we have? How is the service going to be hosted? How much would it cost? What other systems and projects might be impacted? What happens when the project runs past its deadline? These are all very important questions, and usually we don't know the answers well enough until the project's in its later stages, hence the continual meetings.
Reading the latter half of XSW's post, his/her perception of software engineering appear to have been influenced by the Silicon Valley 'startup culture' thing, which isn't reflective of the industry. Most of us earn modest salaries, working in lesser-known cities, developing integrations or software for a relatively small number of clients. Very few of us were under any illusions about it being a 'six-figures golden job' - we were simply attracted to the idea of building software and seeing projects some to life. I don't think many of us see a career in finance as particularly appealing.
Can one earn a six-figure salary as a software developer, though? I'm extremely skeptical of any developer, or senior developer who claims they're earning are. I know four people who started out as developers and earn roughly £100K: All of them have about thirty years' experience. Three of them are executives, and one is a company director.
I should end this post, though, by saying it's not good for a computer science/engineering undergraduate to be cynical about this as a career path. You could end up in any number of places, and even find yourself in your dream job, as I did. Your career's going to be what you make it, and it's entirely possible to make it a highly rewarding one.