Armed with a maths degree and some self-taught Python, I was hired as a graduate developer at Scott Logic almost two years ago. In that time I’ve had a lot of experiences, including being on my first ever project with fellow graduates, joining my first client engagement, learning programming languages and technologies, participating in skills workshops, mentoring both new graduates and experienced team members, attending conferences and panel discussions, writing blog posts, and losing a large number of table football matches.
I’ve been reflecting on my time as a software developer and the things I’ve learned (sometimes the hard way).
1. You will get stuck…
… and I don’t think this changes with experience; the thing that changes is how you unstick yourself. As a graduate developer I’d often get stuck, want to give up, and probably ask for help a little too often. As I’ve progressed through the grad programme and on to my first client project, I’ve learned that getting stuck is normal, and that the way forward is usually a lot of googling, experimenting, and just trying things without being scared of failing.
2. The best way to get unstuck is to take a break
Almost every developer will be able to tell you a similar story of being stuck on a problem, going home furious about it, getting in the shower, and having a moment of realisation of how to solve it. It’s pretty common knowledge that a break is probably the best way of getting unstuck - making a cup of tea or having a short walk is far more productive than staring at a screen, and I’d guess that 99% of the time, you’ll get the problem solved faster.
3. You will (probably) get over your fear of failure
As a bit of a perfectionist with an unhealthy fear of failure, I hated being wrong. I hated getting answers wrong in tests at school, I was always striving to get 100% on coursework, and would beat myself up for not being perfect. Becoming a software developer has completely changed my outlook on this. Failure is good, and gives you opportunities to learn.
I recently undertook a piece of work which involved investigating multiple different ways of deploying an application; the brief was open-ended, and it was down to the team to decide on the best course of action. We developed multiple Proof-Of-Concepts, and it turned out that some of those were more like Proof-of-“Looks-Like-We-Can’t-Do-That-After-All” - and that was fine! We learned about the technology and we better understood what would and wouldn’t work for our use case. Failure doesn’t need to be scary, as long as you’re ready to learn from it.
4. You shouldn’t compare yourself to others
Our graduate programme starts with learning front-end development, guided by experienced mentors, which is designed for all levels of programming experience. I spent the first few weeks comparing myself, and my progress, to the other graduates on my intake. I started the grad programme with only a small amount of self-taught Python, so all of the training material was completely new to me - I took longer than some of the other grads on my intake to learn these things simply because I didn’t have the same experience as a computer science student.
5. You won’t realise how much you’ve learned
I recently looked back at my graduate training repo and couldn’t help but laugh in disgust. If statements nested five levels deep, everything all in one file, more spaghetti than in the whole of Italy if I’m honest!
It can be hard to see our progress as developers because we don’t often see the big picture of how far we’ve come from our first
Hello World!. Mentoring can help you see how much you’ve learned - you go from looking at someone else’s code and thinking “what on earth is this doing?” to quickly being able to see where they may have tripped up and done something incorrectly. I can vividly remember being amazed at how fast my grad mentors found what was wrong with my code, and thinking I’d never get to that point.
6. It’s not enough to just be good at coding
It might be easy to think a software developer just needs to be good at tech - coding, investigating, testing. But as consultants, we need to be multi-talented and can’t just rely on our technical skills. So called ‘soft’ skills are just as needed as the technical ones.
Cheesy as it sounds, communication, teamwork, active listening, and many more of these soft skills are probably harder for some of us techies to learn than the programming languages that we use, but they’re equally if not more important. There’s no point in having a team who can build a solution but can’t engage with the client to find out if they’re building the right thing!
7. It’s often about who you know, not what you know
It’s a simple fact that we can’t all be good at everything, but with over 400 technologists at Scott Logic, there’s a large chance that there’s someone who knows something about the thing you’re interested in!
It is good to go and research areas that you aren’t sure about, but you also shouldn’t be afraid of sending someone a message asking if they have time to talk about it - a half hour chat with someone who has the right knowledge is probably going to be more fruitful than spending half an hour down a Google rabbit hole.
Making connections as a graduate and talking to your colleagues outside of your immediate circle is a really great way to learn and gives yourself a catalogue of people you can talk to about certain technologies - I think we’re quite a friendly bunch at Scott Logic and most people are more than willing to have a chat. We also have Communities of Practice which focus on areas such as testing and cloud, and give you the opportunity to make these connections.
All in all, I’ve thoroughly enjoyed my first two years being a software developer and I can’t wait to see where the next two (and beyond) take me.