Dominic Fraser, developer at Skyscanner, takes us through his top tips and advice for CodeClan graduates who are starting their first role as developers.
My path to being a developer was unusual, though getting less so as more and more people re-train to enter the tech world. I originally graduated in Film Production in 2010, wandered the world for a while, then in my late 20s, decided to study Professional Software Development at CodeClan and see what that life was all about.
With no CS degree, no work experience, and only a four-month bootcamp to start me off, joining a well established tech company was fairly intimidating. I initially joined as a product manager, then a year later re-interviewed to move over to being a developer, wanting to build things first hand for a while.
Accept it’s impossible to do all the things, all the time
This is a hard one to learn. There are so many interesting things going on, so many things to learn, and so many things that are just a tiny bit broken that it would be satisfying to fix — but it is impossible to do them all. Sure, you can for short periods of time, and sometimes bursts of intensity and putting work first can be rewarding, but it isn’t sustainable or healthy long term. This is hard mainly as the pressure tends to be self imposed — whether through passion, fear, or dedication — which are all hard to step back from and recognise when you are spinning too many plates before you drop one, especially when the easy answer is just to work another extra hour.
Here though, all paths lead to burn out — which achieves the opposite of what you want. So, set your limits early, pace yourself, and prioritise within those limits. Don’t try to be a hero.
Specialise, while developing systems thinking
When narrowing down what to focus on, I’ve learned to value two things — deep specialisation alongside systems thinking.
Paraphrasing Charity Majors (from the panel talk ‘Developing software engineers to catalyze the world’s tech ecosystems’), juniors should go deep in something as ‘once you’ve gone deep in one thing you can go deep in anything, given the time’. The skills learned in the process of mastering one skill, and in managing being the go-to person for something, are transferrable. As you progress it’s easier to ramp up in any new domain you are required to know, while still retaining core value as a domain specialist.
And systems thinking? This is thinking outside of a certain technology or framework — rather when considering work thinking ‘about the problems that it solves and the system around it’ (Scott Hanselman). The first practical step is getting a high level overview of the systems up and downstream of you, and understanding how and why they’re architected in that way. I agree with Kishau Rogers when she says that ‘Systems thinking is more important than coding’, and so starting to develop that skill as early on as possible being the second focus alongside initial specialisation.
Write, write, write
Whether blogs, documentation, or a learning log — write down everything you know. Nothing is too small; someone will always be glad you wrote it.
Writing things down is a great way to test you actually understand something, in a way that also helps others to learn. You’re also doing yourself a favour twice over, deepening your learning now, while helping your future forgetful self by providing personally tailored learning material to refer back to.
Close your laptop, put away your phone
In meetings, at lunch, in any situation when you could be focussing on another person, put away distractions.
No one can really multi-task — you almost may as well not be there. Choose one thing and do it well, rather than do two things poorly.
Actively give yourself space to develop and value relationships with those around you. Outside of work this is common practice, so why is it different here?
In Simon Sinek’s talk on ‘Leadership, Communication and Our Addiction to our Cell Phones’, he points out that by doing things like filling in time at the start of meetings on your device you miss out on all the trivial little interactions with people that by themselves mean nothing, but are the foundations all relationships are built on. It can be hard, after all not only are we all busy but initial small talk with new people can feel awkward, but wouldn’t you prefer to have more connection to the people around you?
Why not look up, say hi, and see what happens?
Find, and give, mentorship
Reasons for finding someone to act as a mentor are fairly self explanatory — though I would recommend reading Ryan Holiday’s thoughts in Ego is the Enemy around what to look for when picking a mentor depending on if you are at a stage of ‘aspiring, succeeding, or failing’. Doing this decisively gives you a greater hand in setting your own direction.
A very recent term I related to strongly was of ‘mentors-of-the-moment’. Among other points this reinforced ‘the value of positive micro-exchanges in the workplace’ and that ‘even relatively brief interactions can lead to increasingly transformative developmental relationships … in aggregate, these momentary interactions bolster self-efficacy, belonging, and excitement regarding career possibilities’.
It is obvious to encourage this sort of mentorship from those in leadership positions, but no matter what your level, or how new you are, you can impact those around you by being a ‘mentor-of-the-moment’ to them.
Look, and provide, stretch opportunities
Mekka Okereke had some interesting thoughts about how managers can increase representation of underestimated people, and increase retention, by thinking more deliberately about how they allocate stretch opportunities — but don’t just leave it up to your manager. While it’s good to be thoughtful about ‘if that stretch job is right for you’, still look for your own opportunities, and don’t be afraid to speak up.
Equally, you don’t have to be a manager to help those around you develop. Lift each other up and challenge each other — yes this certain piece of work might be fun, but could it be the perfect learning opportunity for someone else in your squad?
You are not your level
You were hired more for your ability to think than for specific things you know. Yes, it is important to know your limits, and please, never be someone who speaks for the sake of speaking, but your input and insights are valuable from day one. Even simply questioning why something is being done is impactful — after all, if it can not be explained to you, should it really be being done? In return listen, learn, and develop.
Starting as a developer as a career switcher, with a variety of life experience behind me, getting involved in discussions was never intimidating to me — and I encourage it not to be for you either.
Consider rotating teams
If your company allows for internal rotation I would suggest considering it. Rotating teams is not for everyone, but considering rotating is something for everyone, as it comes with many upsides.
This may be greater technical experience, greater understanding of how the company works, greater empathy for how other teams function, but the largest takeaway for me would be how you become more well rounded in your fundamental thinking by working with different people.
I learnt from great and very talented people in my first team, and definitely had my world view shaped by them. The people in my second, and third, have been equally great and talented — but exceptionally different each time. Being exposed this early to so many different ways of thinking fundamentally impacts how you yourself think, you are a culmination of all the people you have met, and are better for it — not simply mimicking the first person you are alongside, but selecting what you individually see as the best from multiple people.
Rotating does come with a cost, repeated ramp ups are intense and can be draining, so consider what else you have on in your life and what your priorities are before doing so, but it can be well worth it.
Nothing is successful without glue
Technical leadership relies on more than just writing code, as Tanya Reilly says ‘engineering teams success is not just about showing up and churning out code’ but relies on a lot of ‘glue work’ that is expected from senior hires, but not necessarily taught to juniors.
Glue work could include:
- Asking why work is being done
- Noticing patterns of when people are blocked
- Mentoring and onboarding
- Setting up meetings
- Wider level communication, alignment, and knowledge sharing
- Documentation
- Detailed reviews
- Establishing coding standards, and ways to maintain them
- Improving team processes
Depending on where you sit on the scale from ‘that’s really natural and fun’, ‘completely out of my element’, ‘hate it’, or ‘but when will I get any better at actually writing code’ she has some great suggestions, and I recommend starting with the linked talk, as without this work being done no team, or organisation, can be successful.
Be deliberate with your time
Building on thoughts from multiple of the above sections a common thread is to be deliberate in everything you do. Time is a resource you cannot get back, so don’t waste it. After all, ‘This is your life, and it’s ending one minute at a time’.
One further example I would give, if your company culture allows, is to feel free to not attend any meeting that you don’t actually need to be at. Do multiple people really need to be there? Could one not summarise for some of the others? Communicate, but make your own judgement calls.
Invest in your relationship with your manager
I see this in two parts; making sure you and your manager are a good fit, and trusting in them once you have found them.
We should acknowledge that not all managers will suit all direct reports. While ‘managing up’ is a valuable skill to learn, and it is important to always provide empathetic feedback first and give chances to develop a relationship, take advantage of being in a company where internal rotations are possible. What is it you need, and were will you get it? It’s true that ‘people don’t leave jobs, they leave managers’, but here you have power not to get close to that situation, use it.
Secondly, once you have found one, allow yourself to trust in them. Share your thoughts, listen to theirs, and work together. Like any relationship this is a risk, but in the same way it can be paid back in spades. Lean in and see where it takes you.
Everything is possible
I’ll end on something that a colleague said to me before my developer days when I was a Product Manager that is deceptively simple — ‘everything is possible’. At the time it was in answer to if we had the ability to build something, but it has stuck with me at a far more fundamental level, and still stays with me today.
That’s all folks
And that’s a wrap, for now! I hope some of the above can be useful in shaping what you think a good developer is, whether because you agree or dispute any points made hopefully it provides some interesting thoughts of your own.
