What I’ve learned from other dxw developers
I’ve felt able to ask questions and be vulnerable from day one
Developing new skills and knowledge doesn’t just happen on courses and at conferences. We asked our some of developers what they’ve learned from their colleagues. Here are their reflections.
Laura Porter, Senior Developer
One of the main things I’ve learned from being a developer at dxw is that it’s actually okay to ask questions. You would think that was a basic part of any job, but being a non-man in tech – and one who’s worked in tech for a long time – means you know it’s not always the case.
For many years I worked at companies where it was simply not safe to ask questions or reveal you didn’t know something. Unfortunately this isn’t uncommon in tech – this classic strip from xkcd sums in up perfectly. I spent years holding myself back from asking questions or showing a lack of knowledge, for the (very real) fear of ridicule.
So one aspect of working at dxw is that we don’t subscribe to that culture here. Asking questions is fine, encouraged. The idea of “there are no stupid questions” is more than just a platitude, delivered with a wry wink-wink nudge-nudge. There’s no one developer to single out for this – it’s an integral part of our culture and I’ve felt able to ask questions and be vulnerable from day one.
Nick Jackson, Senior Developer
I’ve learned loads of stuff from other developers at dxw, both technical and soft skills. Since joining dxw I’ve learned an entire language framework – Rails – which I’ve never worked in before, along with finding better ways to structure my code. I’ve met new ways of testing things and approaches which make the work easier and more reliable. I’ve learned to do things in git which I didn’t even know were possible before.
The technical skills are great, but I think it’s the soft skills where I’ve learned the most. How to tease a feature request apart into the actual work that needs doing, how to manage expectations, and how to say “no” in the nicest way possible are things I’ve improved on by watching other developers at work. I’ve learned how to more clearly explain my thoughts and how to use that to better mentor people, and how to give (and take) feedback people can actually use.
Matthew Passmore, Projects Lead Developer
Do the smallest amount of good work
I’ve always been diligent in breaking down my code into manageable, related units of work. After joining dxw, it didn’t take long to realise that I was still some distance from my dxw peers on this front. My instinct was to encapsulate an entire feature in a single pull request regardless of its size, demonstrating a lack of empathy for those reviewing my code. Long lists of commits, multiple languages, and a big chunk of code to parse.
I’ve learned to redefine how I conceptualise a ‘feature’ and understand that a feature may well consist of multiple atomic features, each deserving of their own tightly scoped pull request. If I’m asking myself, “what’s next?“ that’s usually an indication that the code is ready for review. Less overhead for the code reviewer is kinder, improves the quality of the review and brings a faster cadence of changes deployed. This visibility of progress is invaluable in giving the client peace of mind. There’s also the less tangible benefit that it’s sharpened how I understand and think about what I’m building. I’m a better developer for this.
Be generous with time for others
It can be overwhelming when you join a new place of work. The battle to get up to speed across multiple contexts can quickly lead to a sense of imposter syndrome. A natural response to the sheer amount of things that you now don’t know. Through conversations with peers and seeing how they interact, I’ve learnt to embrace vulnerability and cultivate empathy as a team member. Sometimes this is asking for help, hours before I would have previously.
Time-blocking the struggle can be a powerful motivator to reach a breakthrough moment. Sometimes it’s saying to the client, “I don’t know, but I’ll come back to you on it”. It’s okay not to have all the answers, all of the time.
The list goes on, but essentially I’m mirroring behaviour I see from the team day in, day out. A culture where there’s a generosity of time for each other. It helps you to thrive and is a great enabler for team wellbeing and development. It can feel like a big ask to pull someone out of their day’s focus, but these bids for attention have been met with nothing other than willingness and openness. It’s infectious.
Being helped without judgment inspires you to do the same and helps foster a positive work environment that helps counter any tendencies we may have to hold ourselves back.
George Eaton, Senior Developer
I’ve struggled with imposter syndrome as a developer at all stages of my career. Hearing people with more experience saying “I don’t know” or asking questions when they weren’t sure about something was a real eye-opener for me. It fosters a culture of openness and makes others feel safe asking questions without fear of ridicule or feeling they should know the answer. If someone that senior is admitting to not knowing something, then I can too.
Asking questions also encourages other people to explain the rationale behind a certain feature request, or why they’ve written a piece of code in a specific way. Explaining something is a great way of reinforcing your knowledge of it, but can also highlight gaps in your own knowledge to show where you might be able to improve your understanding. I’ve lost count of the number of times someone’s asked me “how does x work?” or “why have you written it like this?” and I’ve had to go and read up on a software package, a technical concept, or have even gone away and completely rewritten a feature in a clearer way.