By Adam Bystran on Thu 20 May 2021 in Placement Blog
Hear from Adam to find out the key things he’s learnt as a Development Placement at ProspectSoft.
Hey there, my name’s Adam and I study Software Engineering at the University of Glasgow and it’s safe to say I'm pretty passionate about software engineering, AI, and UX design.
Why do a placement year? When I was thinking about whether I should do one, the number one reason I came across was that you would gain invaluable experience. Six months into my placement, I thought I would look back and reflect on some of the lessons I've learned and share them with you.
Quality Over Quantity
I came from a background where speed was more valuable than quality. Many of the projects I worked on were on tight budgets. Quality mattered, of course, but time and saving money came first.
Thinking back to some of my University assignments, I think they were promoting the same “quantity over quality” approach. They would often group deadlines together and were quite lenient with the marking. You could pretty much get an A, even with flaws in your code - you just had to do a lot in a short time.
However, things are different in a production environment. Quality matters a lot more than quantity. Shipping a broken product is not an option. In my six months of being on placement, I’ve learnt to slow down and focus more on quality.
When I first started at ProspectSoft, I’d get through a task quickly, briefly tested it, and moved on. The result? Most of these failed to meet the strict quality targets we have here at ProspectSoft. Fortunately, most of the flaws were picked up during our testing period, and I got a second chance to polish up my work before it ever reached our customers. At one point, I realised it probably takes more time to have several rounds of tests and fixes than spending more time to iron out all of the issues at the beginning.
I suppose it boils down to the same old "it's cheaper to prevent a bug than to fix one." More interestingly, I've heard people say that higher quality work leads to higher productivity. And in my mind, it makes sense. High-quality products equals happy customers. Happy customers helps make a business successful, and a happier Developer. That, in turn, leads to high morale, which then promotes higher productivity – and it becomes a cycle.
Importance of Clean Code
Clean code. It's one of those things you learn about, you understand, but don't fully appreciate until you start working in a real software Development team.
Working at ProspectSoft, I realised what a difference clean code makes. Seeing code that is beautifully architected, easy to understand, and has descriptive variable and method names made many of my day-to-day activities so much easier. Debugging, extending, and adding new features is a breeze on a clean codebase.
On the other hand, when I don't name my variables sensibly and don't refactor my code, I’m just making the job for my teammates and my future self much more difficult.
Asking for Help
Yes, you need to know how to write efficient code. It's also good to have solid CS foundations and be familiar with the latest frameworks and tools. But that's only half of the story. The other half is working and communicating with people. One of the things I struggled with at the beginning was knowing how, when, and what questions to ask.
When I started, I’d rarely ask for help and struggle my way through to a solution. My reasoning: I was hired to solve challenging issues. I didn’t think it made sense to pester my more senior colleagues. After all, their time is super valuable.
I still stand by those views, but spending too much time on a task instead of just asking for directions, opinions, and general thoughts from colleagues is just silly. The other day I spent hours writing a neat function, only to realise there was one line I could have changed to get things done in a fraction of the time.
I still struggle knowing when and what to ask, but a good rule of thumb seems to be to spend some time on the issue yourself, maybe “Google it”, and then formulate an easy-to-answer question. After all, I'm here to learn, so I might as well take the opportunity to learn from the more skilled.
I think we software engineers are optimists at heart - anyone in tech has to be. We endeavour to create new things that haven't been done before in hopes of improving other people's lives. Like with creating anything new, there’s a lot of uncertainty.
Being an optimist myself, I’d always struggle to give an accurate estimate of how long a task was going to take. "Hey, Adam, how long do you think it will take you to finish the new search UI?" - to which I'd reply: "Two days max!" - but then proceed to take another two days on top of that.
After a couple of botched, overly optimistic time estimates, I talked to my mentor. He gave me this advice: "Take whatever time you think it's going to take and double it." He pointed out that people care more about whether something gets delivered on time than a wishful estimation that's one or two days earlier.
I still struggle with this sometimes. It's one thing to get something working just OK, but it takes way longer to get the product to meet strict quality requirements. Plus, Software Development is inherently abstract and creative, which makes it tricky to estimate. Even so, my mentors' advice has served me well so far.
All of the Cool Tech
Finally, I've been exposed to so much cool tech here at ProspectSoft. Anything from legacy code in VB and Azure DevOps' deployment pipelines, all the way to Cosmos DB and Azure Functions. But the neatest technical skill I’ve picked up so far is debugging. I'm not the biggest fan of Visual Studio IDE, but some of the debugging technology is pure magic. For those uninitiated, you can hook up your IDE running locally to a remote cloud service, set break-points, and carefully step through your code. All the while, the code is running on the server.
Having seen my senior colleagues debug their code, I've decided to bid my final farewell to console.log() -- I'm never looking back.
Overall, I’d say that doing a placement really is a great way to gain invaluable knowledge you otherwise wouldn't at the University - you really do learn something new every day!
If you’re on the lookout for a highly Software Development-focused role, and have a desire to learn about new technologies, be sure to check out our Software Development role now.
Want to create the perfect application? Then make sure you check out Beth’s article on Balancing Uni Work & Placement Applications.