Write More Code
At the moment, it’s a great time to be looking for a job in the software industry. Provided you’re willing to move to where the work is, there is no shortage of firms who are hiring. But according to data gathered by the UK’s Higher Education Careers Service Unit, less than half your class will get jobs in the software industry, and six months after graduating, more of your class will be unemployed than the students of any other degree discipline in the UK.
Why is that?
Many people will tell you that you need to focus on your soft skills - and indeed, they are very important. You need to have personal discipline, personal hygiene, good timekeeping, and the ability to work well with others. You also need the ability to understand a problem, model it, break it down into deliverable chunks, and be able to deliver it to deadlines.
But you can’t deliver anything unless you can turn your ideas into code - and you understand what that code actually does.
Can You Express What You’ve Learned Through Code?
If your course was anything like mine (I graduated in 1994, back when there weren’t any web developers, or Java, or the scripting languages you will have learned on your course), then your time has been spent on a mixture of lectures, lab sessions, assignments, and a group project or two. You’ll have been exposed to a lot of concepts and ideas. Your level of attainment will have been assessed partially through handing in homework, but mostly on paper-based final exams at the end of each year. (In your final year, you’ll also have a large final-year project to complete).
Think about how often you’ve been asked to demonstrate everything you’ve learned by turning it into working code. Depending on your course, you’ll have been asked to do this some of the time, but probably not all of the time.
I don’t mean to diminish the importance of end-of-year exams, because they play an important role in demonstrating how much information you’ve absorbed from your lectures, but there’s no getting away from the fact that when you start working, you are not going to be asked to submit written answers to the problems that you’re given. You’re going to be asked to submit working, commented, tested, packaged code.
Can you turn your ideas into code? Can you turn other people’s ideas into code? Is that code going to stick, and last as long as I need it to? If the answer isn’t yes, then I can’t hire you for the job, because you can’t do the job that I need done.
How Much Code Did You Write For Your Group Project?
If you’ve participated in a group project during your course, I’m willing to bet that the tasks got broken down like this:
- One or two people did the organising
- One or two people wrote the documentation
- Some of the group made no meaningful contribution, other than adding their names to the final write-up
- … and only one or two people wrote the actual code
Which did you do?
If you didn’t write a substantial chunk of the code for your group project, ask yourself this: why would I hire you, if you can’t (or won’t) contribute to the software that I need to ship?
How Much Code Have You Written To Date?
Let’s take it a step further. Answer these questions to yourself:
- How many hours have you spent writing code during your course?
- How many hours have you spent writing code in your entire life?
It’s perfectly possible to graduate with first class honours, and have spent less than 100 hours in your entire life writing code, especially if you never got to write software before starting your degree course. Do you know what 100 hours is? That’s about two and a half weeks of working in industry. Two and a half weeks. That’s about a fifth of your likely initial probation period.
A couple of weeks of time tends so close to zero that it might as well be zero.
Some people believe in innate talent, that you’re either naturally good or something or you’re not. I don’t subscribe to that. In my experience over the last 20 years, there’s no substitute for putting in the hours, and the hard work of learning, experimenting, and yes failing too.
When you turn up for your first interview, and your interviewer sits you down in front of a PC and asks you to write some working code, you’ll feel so much more confident and prepared if you’ve spent your university years practicing your programming skills. You’ll be in the right mindset to show your interviewer what you can do, and you’ll have the practiced skills to back it up and deliver.
Practice, practice, practice.
What Can You Do That Your Classmates Cannot?
Imagine that I’m interviewing yourself and four of your classmates for the same job. There’s five of you, but only one vacancy. Four of you won’t be successful. But will you be?
If I ask each of you in turn what skills you’ve got to offer, what will your answer be? Are you going to give me a list of the programming languages you’ve learned on your course? And when I ask you about your experience in each language, will you be telling me all about the projects and assignments you’ve done on your course?
Why should I hire you if your answers are the same as your classmates?
It isn’t just your classmates on your course that you’re competing against. Take the number of students on your course, and multiply that by the number of universities in your country who also teach Computer Science or Software Engineering. And then add in all of the graduates from other countries who would like to land the same job.
While you might not be competing against your classmates for that first job, chances are that you will be competing against people who have the same generic education and skillset. Unless the role is specifically limited to new graduates, you’ll also be competing against people who have already worked in industry.
What are you going to do about it?
Well, all that practice of writing code is a good start, and you’ll do even better if you use that practice time to deliver software that other people actually use. There are few better endorsements than having actual end-users.
Imagine how that would change your answer in that interview. You’d be able to talk about what you’ve delivered, how people are using your software, and what you’ve learned from their feedback in order to improve your software. Suddenly, you’re having a completely different conversation with your interviewer, and it’s one where you’re demonstrating key skills of designing, delivering and maintaining software.
Your Course Is Not Enough
Even if you graduate with first class honours, the programming that you do as part of your course is not enough to get you to the level required for an entry-level position in industry today. You probably haven’t done enough programming on your course alone, and there are many thousands of other graduates with exactly the same experience who also want the job.
There’s a massive shortage of software engineers right now, but that doesn’t mean that employers are going to hire anyone who applies. Many of the open vacancies have been open for months, simply because the people who are applying aren’t able to convince the employer that they’ll be able to do the job. It’s much harder for new graduates, because they have no track record to demonstrate their abilities and successes in computing. In this economy, there are few firms who can afford to take entry-level people and train them to become productive enough to cover the cost of their wages. The bar has seldom been higher.
Does this mean that your degree has been a waste of time? Absolutely not. Your degree course gives you several years to learn more about who you are, and how to survive as an autonomous adult. It exposes you to fundamentals and concepts that give you a vital platform to build on. It gives you access to essential experience during your industrial year. And your final degree award speaks volumes about the kind of person you are to your first employer. (No-one really looks at your degree after your first or second job).
Ours is an industry where change is the only constant. It’s highly driven by trends and fashion. Most people stay with one firm for less than four years at a time. Not only are you expected to keep up with the latest tools and techniques simply to keep doing the job you get, if you don’t, you’ll find it difficult to move jobs for better pay and more interesting work.
Self-directed learning and practice has to become a habit for you. You have to supplement your course with your own additional, directed learning. You have to get used to setting aside what you consider to be your own time for this learning and practice. It’s an investment in your future, whether you’re 20 and looking forward to graduating, or you’ve been in the industry for 20 years.
How To Write More Code
If the situation was reversed, and it was you interviewing me about how I went beyond my course, here’s the answer I’d reply with:
- Before I went to university in 1991, I’d spent every hour that I could writing software for the ZX Spectrum and the BBC Micro. Most of it was utter junk (especially the games that I wrote), but I found the most progress came from writing software that was actually used by people, such as an Econet network management system I wrote before I was 16. Much of this programming experience was in machine code - directly programming CPUs. This started to teach me how to make software that others would enjoy using, and how to organise software.
- During my time at university, I built a four-man development team. Together, we created a social network including discussion forums, chat rooms, IM, email, and remote help. Every user could set their own preferences. It remembered what a user had read. Users could search for discussions that interested them. It was completely peer-to-peer, with no central server, and no central database server. This was in the days before widespread use of TCP/IP, Linux, or the World-Wide Web. That system was called Arafel. This taught me a lot about disassembling software, network programming, basic security, data storage and retrieval, and about structuring and scaling software. It also taught me to write code on very slow computers, because fast computers can hide your terrible choice / implementation of algorithms. It also taught me about working in a team with others.
- Around it we built a university society of nearly 1,800 members, making it the largest non-faculty society in the university. We also branched out into running peer-based training to help any student to learn how to use a computer, which allowed us to develop our soft skills at the same time.
- I also started to get into free software (open-source software didn’t exist back then), making small contributions to software used in leading Linux distributions of the time. They were a mixture of bug fixes and minor new features, but they solved big problems that people had at the time, and I still smile every time that I see my work being used on a Linux machine even today. They taught me the importance of identifying and solving the problems that matter to people right now.
- As a result, after graduating in 1994 I got hired to work on free software originally written for NASA - the Network Queueing System (NQS), which at the time was the de-facto standard for UNIX batch processing systems. My job was mostly to fix it (it had to run for months at a time with no crashing or errors), and port it to many different versions of UNIX (over twenty different platforms before we finished). This taught me how to create zero-defect software, practical modularity and abstraction layers for software portability, and a hell of a lot about why operating systems work the way they do. It also taught me just how hard it is to produce great work if you’re writing software that you don’t use yourself.
Since those times, the software world has completely changed. Back then we didn’t have anything like the opportunities that you have today to write more code. We didn’t have open-source software, or easy access to developer tools - or even computers at home (I didn’t get my first computer at home until part-way through my final year). We didn’t have mobile phones at all, never mind cheap smartphones, tablets or Raspberry Pis to write code for. We didn’t have the World-Wide Web, with its abundance of manuals, documentation, and places to go and ask questions. If we wanted to know how something worked, we had to take it apart. We didn’t have meetups, or conferences where we could go and meet like-minded people. Heck, very few of us had industrial years.
In short, today you have a wealth of opportunity that my generation never had. I’m urging you to make the most of it, so that you have a fulfilling and long-lasting career in one of the best-paid and stable professions today. And yes, so that hopefully one day I’ll be able to hire you for my team.
You have only one excuse for not writing mode code: that you would rather be doing something else. If that’s the case, I’d rather hire someone else.
About Me
Stuart Herbert is a software engineer and operational manager, with nearly 20 years of commercial experience in software design, implementation, support, and in technical leadership, operational and senior management. His career to date includes projects and/or roles with household names including Eurostar, Hewlett-Packard, Orange, Vodafone, and the Ordnance Survey. He has written for php|architect magazine, and has spoken at PHP conferences on both sides of the Atlantic. He is a co-author of the official Study Guide for the Zend PHP Certification Exam for PHP 4. He is also a qualified and practicing teacher of adults for lifelong learning.
Tweet