.jpeg)
With a wealth of experience as a mobile app, web and digital platform specialist, we bring a flexible and scalable approach to all of our projects. Driven by purpose, as a project team we are pioneering, humble and assured. We champion a human-centric approach to help both our clients and our own people succeed and thrive, and central to that is a good developer experience. So, we hung out with three of our devs to dig a little deeper into what that means, and how we ensure there’s a good one at ASquared.
Cal: Developer experience is the lived experience of being a developer. So the points of joy, and happiness, and also friction and unhappiness that we experience in all parts of our working lives.
Alex: It can definitely help improve your output and efficiency, because it helps remove any issues you’re having and speeds up your development, which makes you more effective.
Cal: It’s important because it affects the entire team, not just the developer themselves. It's ensuring that the whole team really is happy at work. So if you extend this thinking to any person in any job, if they're getting great satisfaction from that job and they're happy and healthy then they're going to be more effective at what they do because they have the tools, systems and relationships they need to deliver quality work. Then they’re spending less time sorting the things that are stopping them from doing that.
When they're in that good state of mind, they're probably going to reach their flow states more often because they’re more focused. And of course, the happier you are in a job, the more likely you are to stay in that job.
James: It encompasses everything really, it's critical to cultivating a successful and motivating working environment. It covers the people you interact with, the tools that we use, the documentation for everything you use; like APIs, tools and libraries. Being able to land on a website and knowing quickly exactly what it is and how you use it as a developer is very important.
For example, in a project I’m working on right now I just put in a toast library (a little pop up message you get on most websites). There are about 9,000 toast libraries that exist - I don’t know all 9,000 of them obviously, I know about 3 of them because they’re the ones that have the best developer experience. If one of them became worse, for example if the owner stopped supporting it, that would depreciate my developer experience with that library. A very famous example of this was with a date library quite a while ago, called Momentum, and Google kind of killed it and stopped updating it. Obviously using outdated technologies can ruin developer experience.
Alex: Certainly an example of good developer experience would be well written documentation on a library: one that’s really well laid out with good code examples. Which surprisingly can be really hit and miss!
James: And even briefs or specs you get given have an impact on which libraries we use, what tools we’re going to use, what design decisions we’re going to make or how things are going to work. Certain projects progress very quickly so we need to work asynchronously with our designers for example, and it’s so important that there’s agreement and alignment, easy communication and project management.
Cal: Ultimately what we want to do is deliver work of value, which could be fixing bugs or making high quality features or having productive meetings, and I'd say a bad developer experience is essentially anything that stops that stuff from happening smoothly.
Bad documentation is such a good example because that means that we're spending time having to figure out how something works when what we want to be doing is using the thing. I'd also say that a massive bad experience is context switching; you're trying to get into something and then you're pulled on to another task. It saps energy, but there are plenty of ways to avoid that happening with good scheduling and effective team communication.
Alex: Yes definitely: good project management is super important, like well written task tickets that are broken down into small sections are really helpful. They give you a sense of achievement for completing work and you can see the overall project progress which is really motivating. Timeboxing and removing distractions to enable flow state work is really important too.
James: Another aspect is how well the design and development teams work collaboratively. The ability to offer each other solutions and share feedback and critique honestly and smoothly ultimately maintains the focus on making the product as good as possible for the end user.
Cal: We also select tools and programmes which help smooth out production, or speed up deployments or improve quality checking. An example of this is Expo, our tool of choice for developing the latest React Native apps. As a development team, we have a healthy level of freedom in defining how we work and what tech we choose to use, which is really empowering for us. Factors in selecting tools could include their support, whether it’s recommended by other developers and if it has a good community and the ability to talk to other people who use it.
James: For example, for us we find Next.js documentation very clear and because it's so good, other people who are building solutions always have examples of Next.js best practices, and are prioritising integration with it. As much as possible we prioritise the things that motivate and excite us, like speeding up mundane tasks and focusing on more complex work.
Cal: And aside from tools, the way we work as a team really lends itself to a good developer experience. James is our lead, but it feels like a very flat structure and we consistently review each other's work. We can always communicate with each other, enabling full team cooperation regardless of being on the same project.
Cal: 100%. They’ll experience faster time to value, a better quality of work, and an overall elevated experience. They can speak to the technical team directly, which establishes a fast feedback loop and ultimately they’ll have a better documented product which they can update fast…the list just goes on and on really.
James: Exactly, it’ll also produce a stronger alignment and appreciation of what their problem is and how we are going to solve it. It encourages an open and symbiotic relationship throughout the whole process of prototypes, workshops, reviews, feedback loops…etc. Ultimately we’ll produce better stuff.
Cal: Because of the nature of how we work at ASquared, we’re never not in touch with the client, so we can directly see the value that we’re delivering and truly understand the product we're trying to build through having direct conversations with them. It really means that we're thinking more about the product and end-user, rather than just writing code. There are a million ways to do the same thing in code, but if you understand exactly why you're building something then you’re going to be making better decisions about how to best go about it.
Alex: Working in an agency is great as you get so many opportunities to work with different tools and libraries, and the opportunity to find new products and solutions to different challenges.
Cal: You definitely need to be on the ball and know enough about what’s new and what's interesting, and you need to stay curious. But there’s only so much time you can invest in trying new things. Sometimes it's good to experiment with new things in advance of a specific client project when you’re confident it could deliver something valuable, but you need to make smart decisions about what new tech is worth the time investment.
James: You don't want to take on a bunch of new shiny things all at the same time, it’s better to pick one or two and work out how they integrate into your current tech stack, by leaning on your existing experience to inform where it’s best to spend your energy and use bleeding tech responsibly. If you’re adding a new element it’s great if you can build on something you’ve already got, with something that’s low risk to test.
.jpg)
Cal: Ultimately it's about enjoying our experience at work and being a high performance contributor. But high performance doesn’t always mean more work. For example, some developers could spend all of their time only helping other developers, but if you were to measure that you could say that they've not written any code and they're not getting any work done. From a developer experience point of view, they are enabling a good team experience, and more quality work results. Yet on paper alone it’s difficult to put a value on how important that person is in a team, so taking a reading of developer experience can be a useful indicator of team success.
If you’re in a supportive, nurturing and collaborative environment, every person within that team can realise their potential.
—
Our experienced team builds advanced React Native mobile apps, progressive web apps and platforms, with analytics, at pace, working with agile principles. We're a unique mix of collaborators, entrepreneurs and creators who care about what we do, who we do it for, and why we're doing it. Brought together by true design-thinking, we work as a unified team with ambitious, purpose-led companies.
Let's see what we can make together.
From startups to scaleups and enterprise, we're always happy to talk to impact-focussed and ambitious organisations. Use our quote creator to get a better idea of scope, timescales and next steps.
