People that have known me for a few years will know that I never planned to be a web developer, but rather to go into graphic and print design. In fact, until about six months ago the header on this site still read ‘portfolio of web and graphic designer James Shakespeare’. It was always my dream to design great logos, books, magazines and typefaces, one day having my own graphic design studio and being the next Alan Fletcher. I only began designing web pages as a means of making money while I was still at school, and by the time I started my BSc I realised I was more interested in the implementation of good websites than I was in simply how they looked.
As my time at university progressed I moved from being a sketchbook-carrying art student to sandal and sock-wearing, monitor-propped-up-with-O’Reilly-books developer, covering a lot of ground in between. When I moved into the ‘real world’ I was worried that I’d spread myself too thinly across the web design spectrum and would only be valuable to small, under-skilled businesses requiring a full-stack developer. I was scared of specialising because I felt I would be wasting the skills I had learned in other areas of the web design process.
What I didn’t realise was that having this broad, jack of all trades background is probably the best way to become good at what you do. Having a good grasp of what other people in your team are doing makes you much better at your job. By taking an active and ongoing interest in the entire process of your company’s output you not only become better aware of the factors that affect how you do your job, but you also stay hungry and excited for the new ways in which the industry is moving. It also ensures that as a person you don’t stagnate. If you aren’t constantly pushing at the edges of what is considered to be the remit of your job you will trap yourself in a bubble that prevents career development and will soon leave you behind the times.
Yesterday I sat down and talked to one of our senior developers for about an hour on how AWS works, what services they offer, and how to set up new instances and databases. I’m not a sysadmin, and that was an hour I could have spent swotting up on ways to better deliver projects I was working on, or just hacking out more code. Instead I now have a better grasp of the machines my code runs on, how much that costs us and how I could (but hope never to have to) move data around or restore machines. I’ve increased the number and breadth of potential conversations I can have with other developers, clients, maybe even sysadmins.
Perhaps the best thing about taking this approach to your career: you become more aware of the challenges and pressures facing your coworkers, and what is required of them to produce the assets for you to do your job and vice versa. That’s not a career thing per se, it just makes you a nicer person to work with.