Hi there! My name is Fiona, and I am an intern at FreeAgent. I got my offer and dodged returning to the monotony of bar work that I endured last summer. However, I was only in my second year of studying Computer Science. How was I chosen from what must have been a sea of applicants? They must have overlooked someone! Had I lucked out? In hindsight, this was a classic case of imposter syndrome. Fortunately, my internship experience here has helped me lose the misconception that I was not a ‘good programmer’. Rather, what I think is a good programmer has changed from what I thought in university.  

Together over alone

University-wise, programming was often a solo venture. The drill was you were given an independent coding problem and a due date to get to the bottom of it. How do you go about solving it? For me, this meant searching everything down to the bare bones, from Stack Overflow threads to the rabbit hole of course readings. I could spend hours twiddling with one line of code only to realise the problem lay elsewhere! Or, after nitpicking the documentation my lecturer recommended, I would realise that I was looking in the wrong place for my answer. That’s why after all the hardship of figuring out the problem, I came away with an answer that felt right. There was, however, the grading step. These grades sometimes felt like a punch to the gut. You could make one minor mistake and that would be a mark off. I would kick myself over small things. “This was so obvious, how could you not notice?” Any pride I once had in my work disappeared. This grade was attached to me, to my worth as a programmer. Could I aspire to go into programming if a handful of people in my class got higher scores? 

My internship is different. Here, my team will look over my code before it can be shipped off. This is what we call code review. Your code is inserted like a brick, seeing if it works in tandem with the rest of the building. And I found this very daunting at first. It was like waiting for a grade. At university, when I got things wrong, I felt less justified in calling myself a programmer. Throughout my internship, I have got things wrong. The difference is that, rather than being pushed onto the next problem, I get to go back. 

I think it’s when you get that wiggle room to ‘fail’ that you start learning. It’s not like returning to an old exam paper and saying, “I still have no idea what this question was asking, but I can’t go back now”. Code review allows me to probe over comments and wonder what is going on with my code. How can I write this in fewer lines? What in the documentation can I use to make this simpler? Is there a function that does this? And when you find the answer, you come away happy that you learned something. 

It is also good to see coding as a style, and everyone tackling the problem differently. In code reviews, it is okay to not understand – or even disagree with the way you are being told to do something. I could try to fix an issue the way I was told, only to find out that there is a better way. It showed me it is okay if some approaches do not work. It is questioning and experimenting that allows you to learn a new and better way of doing things. This felt unlike university, where there would be one agreed way of answering the problem and no debate around it. To solve problems here, I have to uncover that best approach. Would it be one that my team had shown me before, or would I have to solve it with a novel spin? I get to talk to my team about how to approach the problem. Being heard makes me feel validated and capable as a programmer. 

Slack over stack

The image I had of a ‘good programmer’ began to change. In my mind, I saw the ‘better programmers’ in my course as quietly working away, never piping up with a question since they already had that wealth of knowledge in their heads. University is competitive. It can be more daunting to go to people who know more than you as it feels like a resignation. Even if you get over that hurdle, if your classmate gives an explanation you don’t understand, the idea that you ‘Don’t get it’ is reinforced. They are better programmers than you.

One thing a team member said to me that stuck was that a lot of software engineering is not about knowing everything, but rather knowing who to ask for help when you are stuck. At university, having questions could make me feel dumb, especially when there are people who get it, just like that. It made me feel like asking those burning questions in my mind would expose my incompetence to the class, so I would usually let them go and read up on it later. 

The truth is that if it was really that simple for people to just read up on every concept they didn’t get, I would probably not get the chance at this internship! The tech industry knows that with the world of programming constantly expanding, it is unrealistic to think that there will be someone out there who knows it all. That’s why there are teams of programmers. The rock star developer who knows everything does not exist. 

I think that’s the reason why daily standups keep teams all on the same page. Standups are short and snappy. In a way, standups can humble you – they show you that it is okay not to know everything. This invalidates the voice telling me, “If you ask questions, you will sound dumb”. Every one of my team members has asked for help, even the senior engineers. I think this makes sense – my team all had the same goal. We were brought together because these problems did not have an easy solution. We all have different coding styles and while one person’s style might work for one problem, it might not work for another. So, instead of struggling alone, you can ask to work on the problem with someone else whose strengths lie in that area.

When you learn anything, you have to delve into areas that are not your forte. I thought that it wouldn’t be okay to admit to a weakness – as I knew there were people out there who could navigate these areas with no problem. If they could do it quickly, surely it was a ‘me problem’ that I had to work on. However, when I spent so much time on these weaknesses and didn’t get it, I got frustrated. What was I missing? 

What I was missing was realising that it would be okay to go to the people who know more. When you get to hear from someone who’s in the know about your problem, it can show you a new way of thinking. Not only will this new approach help you solve your current problem, but it can also be used as an insight for those future hurdles! 

I also came to realise that my team wanted me to code as much as I did. In my internship, my team gave me a buddy. My buddy is like my mentor, happy to be the first port of call when I need help. My buddy is extremely good at stopping and breaking away from the coding side of a program to focus on what my understanding was. They also know when to bring in someone else for input. This encourages me to ask for help A LOT. I know my team would be there to give me the answer I wanted and not one convoluted with technical jargon or zero lead-ons (sorry, Stack Overflow)! I feel proud of all the code I have shipped off because I had understood what I had done. 

Letting go to learn

Now, if you were in the same situation as me before I started my internship and reading this blog post, you might be thinking, “That’s good and all, but I still don’t know if I can do this!”. I get it. It may sound counterintuitive to say you should put yourself out there – after all, what if you mess up? I won’t deny that possibility. You will mess up – but that is how you will get better. Every time I have messed up, my team has been there to pick me back up. Although it did feel humbling the first few times, I soon realised that I had people around me who wanted me to grow. It was unlike the competition I was used to at university. I was able to let go. The number of messages and Google Meets I’ve been in has gone through the roof! And, it was in that letting go, I was able to learn. That’s how I started to feel like a programmer.