Hi folks, my name’s Iain, and I’m one of the few interns you haven’t yet heard from this summer.

In my last three months on the intern team I’ve embarked on a whistle stop tour around the FreeAgent application, from user facing emails to developer only APIs. In that time, I’ve learnt a few softer skills that I never would have had the opportunity to whilst I was at university, and I’d like to take this opportunity to share them with you.

Some of these I wish I learned before coming to FreeAgent, whilst others are simply skills I don’t think it’s possible to learn in a university environment – of course, your mileage and experience may vary.

Without further ado:

1. Who is your customer?

AKA: Remember your audience

The software you write is intended for somebody, so it’s important that you keep them in mind as you work. The requirements set out to you may not always capture the full extent of the effects your code will have (though you can always hope that they get close).

There may also be more than one person you’re developing for. If you implement a customer facing feature, how easy will it be to support the users using it in the long run? How easy will it to be fix, or upgrade, by the engineers who come after you?

When you’re at university, the audience of your software is often limited. Rarely will the output of something you write for marks ever be seen by anyone other than you and your marker. There is no ongoing support burden for your submission. There is no ongoing engineering burden for what you have written. This can lead to a style of development that doesn’t lend itself to maintainable, useable code. That doesn’t necessarily mean you need to change your entire perspective on how you work at university (or that I’m any better when it comes to practicals), but it’s definitely a sentiment to keep in mind when graduating to writing software professionally.

2. Cool tricks aren’t always that cool

AKA: Maintainability and readability are what’s really hip kids

This one is another comment on how you might end up writing code at university. Outside of a few group projects (which often arrive later in a CompSci student’s time at university), the grand majority of what you’ve written will have been written alone, and with little expectation of ever looking at it again once you’re finished with it.

Consciously or not, the code quality of what you write can suffer because of this. Even with a well enforced style guide at your university, practicals often aren’t designed or marked with maintainability in mind. 

Another thing to consider when coding professionally is the balance between performance and readability. What is the maintainability or readability cost of optimizing that piece of code? Especially when considered in the context of exactly how much performance you’ll gain. 

That’s not to say that performance isn’t worth considering. Understanding the complexity of what you’re writing is important, and sometimes there isn’t a simple answer to what you’re trying to solve. Similarly, there can and will be times where those extra few seconds, or milliseconds, count. Just don’t get hung up on showing off the latest piece of coding trickery you’ve learned at every opportunity.

3. Take a step back every now and then

AKA: No, running it again won’t magically fix it

This one applies no matter where you are or what you’re working on: sometimes you reach the point of diminishing returns, where applying more effort to a problem isn’t going to get it solved anytime soon.

Whether it’s stress, frustration at yourself, frustration at your code, tiredness, or all of the above, digging deeper and throwing yourself at the problem again and again isn’t going to fix things. I won’t pretend to know what works for you, there’s no magic bullet for de-stressing – but I can say that stopping and giving yourself time to think about something that isn’t the problem will save you a hell of a lot of time in the long run.

One problem with this advice is that it’s very difficult to tell when you’ve fallen into this situation. This is part of the problem itself, in that your focus is so dedicated to one thing you tend to lose sight of everything else. Unfortunately, everyone’s ‘tells’ are different, so they’re something you’ll have to figure out for yourself. For me, I usually know I’ve reached this point when I re-run or re-compile something without changing anything, hoping this time it’ll work.

4. Talk to people

AKA: Listen to people

Conversations are the best way to improve everyone’s understanding. They provide the opportunity for you to also take a minute, and take stock of what you know, what you’re doing and what you plan to do.

Talking with others, and more importantly listening to others, also lets you see things from a perspective you may not have. Most everyone you meet will be happy to share their experiences, whether they be colleagues or fellow students, and their insights can provide helpful warnings or new ideas.

Similarly, remember to ask questions! In university, the people to ask are your lecturers and tutors, and in work those people are your managers and colleagues. Everyone’s there to help, your lecturers and tutors in particular.

One last tip in this regard: not every conversation has to be about work. This comes back to the idea of taking a step back every now and then. Remember to make time for yourself, and the people around you. I’m willing to guarantee good results.

Finishing up

Hopefully you find some of the above helpful. I could write a big long list of all the things that I’ve learned in my time at FreeAgent, but I wanted to take the opportunity to cover some things you don’t see all that often. 

For the sake of completeness though, here are some technical suggestions: learn version control; write tests; try web-dev; git commit titles are 50 characters, and every line after is 72; just pick an editor theme, it really doesn’t matter that much.

I’ve had a blast at FreeAgent, hope to see you all again!