A version of this post was given as a talk to students from the University of Auckland Women in Computer Science group in August 2016.
I was so excited when I got my first job as a software engineer. I was going to write so much code! It was going to be great! Every day would look like this:
Then the reality set in. My days were more like this:
I sat there, wondering what on earth I’d gotten myself into. University hadn’t prepared me for any of this. What was I going to do?! And then as I sat there, it dawned on me.
Think of it this way: if building software is like building a house, university had taught me how to lay bricks in a straight line. I’d built a brick wall or two in my time. But some houses are made of wood. And in order to build a complete house, I’d need blueprints. Houses need electricity, and plumbing. And what about landscaping, and interior design, and…
For loops and variables and exceptions and so on are your bricks. But you need more than that.
Writing code is important, but it’s not the only part of being an engineer.
This blog post is about learning to:
- Read code
- Talk about code
- Collaborate on code
Reading Code
If your school was anything like mine, there was a routine. You’d get an assignment, forget about it, then a few days before the due date you’d hammer out as much code as possible. You’d submit it, and then it was done, and you could forget it ever existed. And then the next assignment would arrive.
Re-reading old assignment code is like trying to decipher an ancient tablet. What were those people (err, Past Me) thinking? What are those unfamiliar symbols?
Production code is different. Production code is worked on by many people and is constantly changing. It’s more like a machine. If you’re lucky, it’s a machine that looks like this:
This is an efficient, well maintained, mesmerising piece of functional engineering. Most of the time however, it’ll look a bit more like this:
What does this even do? Is it actually working? How on earth do I add something to it? How do I replace something in it? I hope someone left some documentation somewhere…
Figuring out what something does by looking at the code is a vital skill for your career as a developer.
You’ll need this skill to:
- Learn new frameworks or languages from examples in books or online
- Debug unfamiliar areas of code
- Review other peoples’ code
The best way to learn this is to practice! Blog posts, open source projects on Github, even Chrome View Source. While you’re studying though, it can be hard to get other peoples’ code to look at. One way you can do this is to dust off your old assignments and try and decipher their strange carvings.
Talking About Code
As a student, you’re told never to share your code. It belongs to you, and if you show it to someone else, that’s plagiarism and it’s bad! As a result, you work on your code in secret and guard it with your life. And it’s really embarrassing if someone else finds a mistake in it.
Unfortunately, it’s the exact opposite of what it’s like in the real world. In a company, you’ll be working together with other developers in a large codebase, so you need to be able to talk about what you’re working on to them. This will help you when you get stuck — you can ask for help far more easily if you can explain the problem you’re having. And don’t worry, everyone has problems. The only way you can get better is to learn, and often the quickest way to do that is to ask.
Code Review
If you work at a software company, you’ll often have a code review system in place, where someone reads your code to make sure it’s good enough to be merged in with the rest of the code. If you’ve written your code a particular way for a reason, you may have to explain why, and it’s much easier when you know how to talk about your code.
Interview Practice
A good way to learn how to talk about your code is to practice interviewing. A good interview candidate isn’t just someone who gets the question right, but one who can talk about the different approaches to the problem and communicate their thought process while solving it. So naturally, you’ll be talking about the code you write. Therefore, by practicing interview questions (with a friend, or even just by talking to yourself), you not only make it easier for you to find a job, but you also set yourself up to be a better developer once you have the job!
Collaborating On Code
I don’t usually like to recommend tools, because every company uses different ones and they quickly fall in and out of fashion. But this is where I’ll make an exception.
You should learn how to use Git. Or some other kind of version control system, but Git is a really good place to start. Version control is what helps developers all work on the same project without messing up each others’ code, and lets you recover from mistakes by saving your work.
There are some great tutorials online that you can try:
- Github https://try.github.io/
- Codecademy https://www.codecademy.com/learn/learn-git
But when you create a software product, you’re not just collaborating with other developers. You might be working with other roles, like:
- QAs
- UX/Designers
- Business Analysts
- Product Managers
- Data Analysts
These people will all have valuable input on the code you’re writing — they might even save you from having to write the code in the first place! If you can communicate well with them, the end product will be better and you’ll all be able to work faster and better, together. So make friends outside of engineering, and tell them about what you study in ways that they’ll understand. Being able to communicate with non-engineers is a crucial skill for being a good professional developer.
So there we have it!
- Reading code
- Talking about code
- Collaborating on code
Go out there and practice, and become more awesome at code!
