I would like to talk about two personal pet peeves that pop up in the world of writing software and relate to developer experience. They are code quality and not invented here syndrome (NIHS). Focusing on the developer experience is like focusing on the experience of people who work in airports. They aren't the core customer but improving their quality of life will improve your customer's experience and the quality of work they deliver. Airports do this by providing expedited paths through security, designated parking, or discounted meals. You can help the people who work on your product to improve their experience when building tools.

When I say code quality, I'm referring to the style in which people write code together. If you can, I highly recommend defining a team style guide for each language you write in. This lets you set a base line so that people can develop in the same style. In the journalism world, there is a house style, which is a style guide published by the organization that determines how staff deal with common things, such as how they refer to people throughout an article or how they deal with stories about mental illness. For coding, a code style guide describes how the team deals with unusual language features. It often describes what type of whitespace is used, how loops and conditionals are dealt with, and answers to common questions about style. The benefit of this is that, when people move between projects, they do not have to get used to a new style if using the same language. It also means that people who often jump between code bases, such as SREs, feel comfortable writing code, and it fits in with the rest of the code in a file or directory.

NIHS is when people want to only use software that was written by people at their organization and have a lack of trust of anything built by software developers who do not work there. This is incredibly dangerous, because it can lead to you writing more software than your organization can afford to maintain. The classic advice is that the software you should build is the thing that is your core competency and you should have other people build things that are not your number one priority. For example, if you are a media company, it makes a lot of sense to write your own content management system (CMS) so that you can be very specific about how you create and serve your content, which is the core job of your business. On the other hand, you probably do not need to invent a new monitoring service or load balancer, because there are many out there. If you can't find something that meets your exact needs, try looking into adding the functionality to an existing project and then merging it upstream, so you are giving back to the world, and also not making your team the new sole maintainer of something that is important to you but not your number one priority.

NIHS is also dangerous because it can cause a sense of elitism within your development team. This can often lead down a road to the team thinking that no one else can build as well as they can and that they are invincible. This is a toxic culture and will prevent other people from joining your team, and will also often cause burnout, as team members will try to perform at the level of their inflated egos.

This is not to say that you shouldn't build software; just make sure that you evaluate everything available before deciding to take on building and maintaining another piece of software.