The software engineer
Why are you here? This one should be pretty obvious - it's a DEV community website, so you are here probably because you are a software engineer, right? At least that's why I am here! But lets go a bit deeper - maybe not all five whys deep, but at least one for now. Why are you a software engineer?
Now that question might already be answered in a number of ways. You might have well-established reasons to start coding, but sometimes it's not that sophisticated. I went to college to study IT without writing a single line of code before that happened. I definitely was not a geek, but I was pretty good at math in high school, and good result on a math exam was enough to start studying IT, so I went that route. But to keep things simple and quite technical at this point - we are developers today, because we became developers in the past and didn't quit so far.
This is quite interesting if you think of it - do you know any people that actually quit? I know a lot of developers that became ones after switching from a completely different business into IT, starting their careers as testers or customer support, becoming developers after couple of years. I know some developers that went into different roles within IT industry - scrum masters, project managers, sometimes testers, though generally the switch in the other direction seems to be more frequent. But it's quite rare to see people quitting IT to do something else.
I know a few people though, that plan to quit at some point. These are usually folks which are at their current position to earn enough money to start doing the thing they are really passionate about. It doesn't mean they aren't passionate about software engineering - although that also happens - but they just have bigger passions.
But in general the big picture from my point of view is that there is a lot of migration into IT, a lot of inside IT and pretty little out from IT. With more and more people needed, more positions being opened and good wages on average, I think it's a safe thing to say, that being a software engineer nowadays is a pretty comfortable occupation. This however does not mean that the job itself is easy to do.
Engineering the software
Because I think it really is not that easy. First of all, a software engineer has a lot of stuff to do. It's not only about writing code. It's designing, planning, estimating, writing documentation, discussing in meetings, preparing presentations etc., not even mentioning all the soft skills valuable when working in a team. Not all of these activities are something, that people with technical knowledge, after studying computer science, are the best in or feel most comfortable with. To be honest, the variety of these activities makes it really hard to find people which excel in all of them.
But that's not the most important thing. The responsibilities of a software engineer vary from company to company, or even from team to team, but still the main thing we do is writing code. So, as said above, it's not only about writing code, but it's still the most important activity - if you take out writing code from the list of activities a software engineer does, it's not a software engineer job description anymore!
And quite similarly, writing code is not an "atomic operation" as well - meaning that there are some aspects of writing code, that people might be better or worse at. The code we write should work and should be readable, to make it easy for the next person that comes to change it. And these two things need different mindset - while writing stuff that works is the domain of people with engineering skills, writing stuff that's readable is usually something in the toolset of the more humanities-minded people.
As developers we need to join these two abilities, to be good at what we do. We need to solve problems according to sometimes complex specifications, while implementing it in an easy to understand way. If it'd be easy, the specification would be written like that as well. It's not always easy to find good abstractions - the ones that will seem so logical for the reader, that he wouldn't even notice this design work someone put here, and the ones that he will flawlessly follow. It's not always easy to find good names - the ones that will fit so good, that it'll be obvious for the reader, what he's reading about. Actually, I'd say these things most of the time are really hard!
So it's not always easy to make it work and it's even harder to make it easy to rework. There are different abilities needed for both of these. I see this everyday - including myself - people good at one thing, but struggle with the other. That's why I think people with so many backgrounds - even if they didn't study IT or didn't do any other technical studies - can become pretty decent software engineers. But that's why I also think programming is hard, or at least it's hard to do it the right way.
Post Scriptum
This is my opening blog post, therefore I wanted to keep it more general, introductory. No worries, things will get more technical in the next ones. Although definitely from time to time I plan to write something similar to this one - lets call it an editorial - because writing about code without code is also possible.
Top comments (2)
Good post, totally agree :) It's also hard because "the right way" is different depending on the project architecture, style, technology... The right way for the web application written in .net as a modular monolith will be quite different to the right way of developing a desktop app or set of microservices, etc. On the other hand, it's never boring because of that :)
Coding without writing a code sounds good to me :). What I want say is that in many cases I am missing proper care and thinking. Today we Dev mainly care how fast we can build app, integrate w azure, set up new DB. Stuff like proper problem/domain identification, choicing right option, testability and maintability are less important. Maybe because they are boring maybe because it is hard to build your CV with them, I am not sure. From my point of view I wish to see in your next posts more coding without code, more generic problem consideration, which based on your experience.
Cheers,
JM.