Why University Does Not Prepare You For A Job In Software

There’s an assumption as you go through school (in the UK where I am from, at least) that if you go to university you will be more successful. There is a grain of truth to this statement; especially if you pick a subject that has a demand in the economy. In this article I speak from my experience about the pros and cons of university and why I believe that what universities teach is not sufficient to prepare you for a role as a software engineer.


University Does Have A Purpose!

First thing’s first, I do wholeheartedly believe that university has a place as a stepping stone on the pathway to becoming an engineer.

Whether you come into it cold turkey with little real software development experience (like myself) or as a hobbyist developer, there is a place for university. Being educated by academics is a great thing, as the academics have absolute unwavering passion for the subject they teach. You go through Programming 1, possibly an arithmetic class to brush up on your vector maths and formulae to model complex things (especially if you are doing a games course). In my course I learned C# as a starter language, completely different from everybody else I knew at different universities, who mainly studied Java, Python or some other scripting language.

Studying Computer Science is truthful, as to learn the science of computers you need to know how to manipulate them to your will with code. There are modules about the theory of how computers work on a hardware level, how data is transmitted between components. Also what effect hardware latency on components will have one your code. For example, the time it takes to issue a command to load a file from disk, allocate time on the hard drive to find the file, find it (which if the drive is mechanical can take some time as physical components have to move) read it in to memory and access it from memory. This can gear you up for more academic pursuits in Computer Science and research, which of course the university really wants you to pursue!

You learn great concepts at university and it’s a great springboard for new developers to rapidly increase their skillset. And for hobbyists with a repertoire of skills already it will introduce you to other people’s ideas and project planning methods that you will need to accustom yourself to. Because of course, not everyone writes programs like you do, the way you do it might not be the best way, even for you. Being able to function as part of a team during group assignments is critical in the professional world. Delegation of responsibility, handling that one person that never does anything until the last moment (if at all), and managing your process, not just the end deliverable.

The concepts you learn at university give you a great education into being a programmer, who can work with other programmers, but therein lies the rub.


Knowing Software Programming Isn’t Being An Engineer

The defintion of engineer according to Google is:

a person who designs, builds, or maintains engines, machines, or structures.

So therefore a Software Engineer is by definition a whole lot more than just a programmer. The classic introversion of software engineers is a stereotype that is wholly outdated, as we are more than programmers now. DevOps of ‘Developer Operations’ is a mantra of modern software development that echoes through tech giants these days.

Now you as an engineer are expected to define your process, be it Scrum, Lean, Kanban or even Waterfall if you’d like. You are expected to define your tasks as part of the story (unit of work) at hand and estimate the time or complexity of them. You are expected to identify your blockers and dependencies for other services in the business and the impact your chosen solution will have on customers and business partners.

All before touching any code.

In many universities you’d be hard pressed to find a course that identifies a realistic customer. Your tasks/assignments are usually pretty well-defined for you and ready to go. Most importantly, you’re allowed to fail. You are allowed to not deliver everything that was asked of you and call it a day. You’ll just get a lower mark for it.

There is no such flexibility in the working world. If you fail to deliver, your team or worse you individually (depending on the culture of your company) will be held accountable for not delivering if you have no mitigating circumstances.

The key to being a great engineer flies in the face of the stereotype. Talk to people, gather opinions and come to a consensus as a team. Work as a pair on the keyboard. Find an issue with another system you’re utilising? Go and talk to someone about who would know more. The days of being a lone keyboard warrior are coming to an end. True collaboration requires a level of social skills, thus is an integral part of being a good engineer.

You get the core, now grow the apple.

In university you focus on the core, the code. I see now so many people fresh out of university, high on a fresh degree with many ideas to bring to the table. That’s fantastic, we as a community need to circulate new ideas and develop our knowledge. But in some cases you see a level of arrogance, that they somehow know better than the seasoned engineer who’s been at it for years.

When you leave university, I highly recommend ‘bedding in’. Get your bearings, do the dance and get the lay of the land as it were. Make people aware of your observations, and learn how to be part of a business. Work with and understand your testers, business analysts, database administrators, platform engineers, project managers and of course your fellow software engineers. Then you can appreciate the entire software lifecycle, of which development is only one part.

With time, collaboration and hard work you too can go from a fresh out of uni developer to an engineer that can work end-to-end with the people required across your company to create a solution that’s got your engineer ‘DNA’ running through it.

This is my first article, so give me some constructive feedback!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.