Living in the digital, hyper-connected world we do, it would be hard not to have heard of Software Engineering. The people who create the tech we use every day are constantly in the news, the companies they've founded are high and rising up the Fortune 500 List, and as an exploding sector of the workforce it's likely you maybe know one of two, as well.
But what is software engineering? What are these people doing all day? And is it something you might be interested in doing?
Firstly, I'd like to clear up a misconception straight up front, a misconception that stock image such as the below aid in perpetuating! Software engineering is not about sitting at a computer all day at a clacky mechanical keyboard typing unreadable and obscure looking code that no normal human being could expect to understand.
Nor does it take a particular mindset, stroke of genius or natural "gift". It can be hard to learn, but that's just because most people who are adults today weren't taught how to think programmatically at school, so they've got to learn a new way of thinking as well as a collection of new tools and languages.
It is quite simply the process of building out a software application. At one level, this involves writing instructions that a computer can understand, which comprise the logic of your application. However, the instructions we write don't look like the above image - we write nice code that is easy to read for humans, and then possibly strip out any unnecessary characters (such as whitespace) so our files are smaller and more efficient for computers.
Writing instructions for computers is a complicated process and can take a long time and be extremely costly if it goes wrong. As such, developers and the wider teams involved in creating software are very invested not only in what they build but the process they use to build it. They are very keen on optimising their development process, cross-team collaboration and experimenting with new practices to improve the speed and quality with which they can create software.
The day-to-day life of a software engineer will involve the following activities:
Problem Solving 🧠
Software engineers will be tasked with finding the technical solutions to problems on a daily basis. For example, a team which maintains a Notetaking application might be tasked with building a new feature which allows users to tag each note with keywords. They'll have to figure out how things such as how to store this data about tags, how the tag data should relate to other data, the most efficient way of searching this data, and how to build an intuitive interface for letting users add tags. There are usually many ways to solve a single problem, so they'll be plenty of discussion until one solution is settled on.
If the problem is too big to tackle all at once, someone will pipe up with the suggestion of breaking down the scope of the feature so that the team isn't changing too much at once, and can release part of the benefit of the feature sooner.
For example, searching the tags could be shelved until later - at a minimum, the team could decide to show a list of tags in the App and worry about searching later.
Software engineers know that their industry is a fast-changing one so they are continually learning. Being a software engineer involves making sure you're up to date with the latest technologies and continually developing yourself, not because you need to know everything, but just so that you are aware of tools and technologies and therefore can make more informed suggestions when it comes to solving problems with the right tool for the job.
For example, the Notetaking App team might be planning to build a full-text search functionality for a user's notes, and they know they're going to need a new database solution to achieve this since full-text search in their current database is too slow. One team member might suggest ElasticSearch, knowing that it's a database designed for search, but not much more than that. They might volunteer, with a colleague, to explore this new technology and learn as much as they can about it, to decide whether it's right for the team.
Because software engineering is complex, it has to be collaborative. Engineers can often be found working through problems together, breaking tasks down into smaller parts, pairing up to transfer knowledge or work on a tricky problem together. Engineers will often also work closely with other parts of the company, such as business owners and product managers. Together, they ensure they are building the right thing, are prioritising work correctly, are breaking big changes into manageable chunks, and are able to make continual, small changes to the software to nudge it day by day in the right direction.
Of course, at some point you do actually have to build the software you've spent all this time prioritising and planning! So a large part of an engineer's job is, well, engineering. This involves actually writing the instructions which tell the computer what to do, or provisioning the infrastructure (in other words, setting up the necessary hardware) for the instructions to run on.
Although the code we write is intended for the computer at end of the day, we actually write our instructions in languages which are easy for humans to understand (humans who know a bit about code, anyway). We're not writing 1s and 0s these days - we've managed to build languages ontop of other languages which eventually compile (output) 1s and 0s, but thankfully the languages we work on are much friendlier to human brains.
Because software engineering is hard, and because there's a lot to learn, an experienced software engineer will (or should, at least) spend a good chunk of their time mentoring less experienced developers so that the team as a whole can grow in effectiveness.
Because software engineering as a practice teaches you to always seek the root of a problem, and often to become interested in optimization (in other words, doing things faster or more smartly with the same resources), it is common for software engineers to apply a similar thought process to other areas of their work. As such, teams regularly regroup to discuss what they could do to improve efficiency in the way the team works and how the software is being built.