October 30, 2017

Lessons for a New Developer #1: Know your role

For a new developer, starting your journey in the workplace can be quite a daunting experience: you’re expected to get to grips with unique workflows, understand complex mental models, gain competency with a variety of technologies, and find familiarity with the working styles of multiple other people.

A natural place to turn for help and assistance is the internet, and there’s a whole plethora of helpful looking articles covering the technical aspects. Many of them give conflicting advice, but at least it’s some advice, right?

Unfortunately one of the most underappreciated areas of starting a career in Software Development is.. well, what are you actually here to do?

You’re there to understand what people want.

This often comes as a shock to junior developers, just as it comes as a shock to those who find themselves working with developers, but the job of a software developer isn’t solely to write code.

First and foremost, your role as a software developer is to understand what the end-user wants, and more importantly, why they want it. In this respect, it can be quite a sociable role that involves a level of consulting - or at least it should if you’re working in a good environment.

There are two advantages to this:

  1. You gain a deeper understanding of the problem you’re solving, and can begin to grasp the associated edge-cases.
  2. You can begin to see potential pitfalls, and raise issues before any work has really been conducted.

I had my first taste of mentoring in a SaaS environment, and I can remember asking one new developer why they were working on a specific task - the rationale was simply “Sales have requested the ability to do that.”. This soon became quite a familiar expression to hear.

It was quite apparent that the interactions between the Engineering team (Product and Development) and Sales could be improved, so subsequently we implemented a system which increased inter-team communications - via a rotated point of contact.

This increase in communications led to saving a lot of development time because we could devise better solutions that still achieved what the client wanted: not what they thought they wanted. This increase in development turnaround soon led to happier salespeople who hit their targets easier, happier developers who got to write better designed code, and happier clients who got functionality quicker.

The Barkeeper

My favourite analogy to explain this revolves around a little club that I often go to with an old colleague; it’s quiet, plays relaxing jazz in the background, and has a wide variety of different cocktails and spirits.

One evening whilst relaxing, I began talking about whisky to the barkeeper - specifically that I’d been treated to a tasting session whilst working for a drinks company, and that I’d tried a brilliant whisky that I couldn’t seem to find anywhere else.

The barkeeper explained that he knew that particular drink, and explained exactly how the flavour was influenced both by the cask and the presence of peat. He later returned with a sample of another drink he felt I’d like, and I did - it had a very similar taste, a taste that I originally thought was unique!

See, the barkeeper was able to listen to what I wanted (the whisky) and why I wanted it (the specific flavour elements), and was subsequently able to provide me with something I wouldn’t have been able to request myself.

Yet if I were to ask “What does a barkeeper do?”, then the obvious answer would be “They tend the bar by serving drinks”; but this would be an oversimplification much like saying a Software Developer “writes code”.

More to the point, that little club became one of my favourite spots because of how knowledgable the staff were.

How this applies to you, the new developer.

Whilst this can serve as a useful lesson for anyone involved in delivering software, whether they’re a product manager, a business analyst, or a salesperson, for a new developer this lesson can really be condensed in to two key points:

  1. Never be afraid of asking questions, even if you feel like there’s enough information to actually begin development with.
  2. Never be worried about suggesting alternatives.

© Fergus In London 2019

Powered by Hugo & Kiss. Source available on Github.