Adapting to life as a graduate developer
As a graduate, starting a career as a developer presents some challenges not taught in university. Here are four skills that could help along the way.
There are thousands of languages, dialects and pronunciations but being able to speak one language is enough to see you through life. Coding is similar, there are many different languages, each with its own peculiars and syntax. However, knowing just one language limits your potential as a developer; here at Equator there are at least seven languages that are used every day.
Learning C#, a language designed by Microsoft, was a challenge. It’s similar to programming languages taught in university but looks and behaves completely differently. As a comparison, let’s say you spend four years studying the intricacies of the English language to a point where you can write award-winning books in your sleep. Now imagine you move to a remote village in Scotland, where English is rarely spoken and all books are written in Gaelic. Could you cope? This is a skill graduate developers require in order to adapt to an industry that is constantly evolving.
Estimation is a life skill - taught in schools from an early age and used every day to estimate journey times, shopping expenses and development task lengths. Developers are asked to determine how much time will be needed to finish a task. Can you estimate how long it will take to finish building a house; a house that you’ve never seen before, that you don’t know how well the foundations have been laid, or the internal structure of?
As any graduate will have experienced, university courses are focussed on providing a deadline for projects; you don’t provide a time scale of when you think you’ll be finished.
As a graduate developer, you need to estimate how long it will take to finish a task. The task could be as simple as changing one line of code, to completely restructuring a section of the project - and it’s likely that the task will change to some degree. It’s kind of the equivalent to building what could be a conservatory...but more than likely will be a two-story extension.
However, it becomes easier with experience and is a lot simpler when the task is broken down in to smaller parts. For the example above, the conservatory would need a foundation, a certain number of bricks, cement, doors, etc. Summing these smaller tasks then provides an overall estimate for the task. But, this could still be completely wrong if the conservatory is, in fact, a two-story extension.
Developers have their own vocabulary- from APIs to URLs and USBs, it’s just a load of nonsensical jibber jabber to the non-technical. But there are times when these concepts need to be explained in a less technical manner.
If you’ve ever tried explaining selfies to your grandmother, you might have some understanding of the difficulties in explaining familiar terms in a simple way.
This comes with experience, but relating the technical terms or phrases to common day scenarios can be effective.
“Buzzwords” are also frequently thrown around conversations between developers, in the ever-morphing technical world, these “buzzwords” don’t hang around for long; quickly being replaced by the next big thing. There are so many sites and blogs that can keep you updated - a quick read once in a while could stop you having to Grunt whilst being bashed in a conversation involving DOM.
As a student, long summers were spent developing personal projects. It provided an explorative break from the challenging, yet often tedious projects provided as coursework by university lecturers. As a graduate developer, those long summers of having nothing but time to spare are gone, but you still need to find time to explore side projects. Finding time may not be the only obstacle to overcome; motivation can sometimes be lacking after a full day spent coding.
However, side projects are what keep developers engaged, they provide a sandbox where anything is possible and you get to sculpt the outcome of the project. As a graduate developer, side projects can offer something to talk about, and possibly present new technologies and ideas to other developers.
By Mark McDonald, Graduate Web Developer