How to Improve the Quality of Your Developer Life
Making everyday development more enjoyable for you and your team
Recently I’ve begun working with my development team on fixing or improving all the little things we do every day that we find irksome or just flat annoying. Some of these initiatives don’t waste that much time, or prove all that difficult, but they’re the last thing many of us want to spend brainpower on during a normal day of development. Referring to these improvements as “Quality of Dev Life” improvements, I’m starting to become convinced that these types of improvements are essential to keeping a team happy and productive, not to mention sane. As someone responsible for 15–20 developers on a program, I’ve found it’s amazing how far small improvements can go.
What do you mean, quality of dev life (QODL)?
In case it’s not immediately obvious, when I use this term, I’m referring to how easy it is for someone to do a normal day’s development work. This includes everything from project setup, writing code, and troubleshooting, to being able to pair with other developers. Does your build process involve 8 steps, 1 of which always breaks? Do you dread trying to build that legacy product because no one understands how it works? Are you able to debug your application actively, without having to dig through vague logs? We could go on, but if these are sounding like pain points you or your team experiences frequently, it’s likely the quality of dev life is on the lower end of the spectrum.
The prospect of solving problems and building cool things is what gets most developers excited, so if you bog them down with a bunch of annoying tasks they must do just to write a single line of code, you won’t have a motivated team that gives you their best effort. If you’re a team lead, make sure you are allowing your team to focus on delivering value instead of fighting your processes or infrastructure and you’ll get the best out of them.
As a developer, this could be many different things — learning how to interact with source control easily and quickly, understanding how to swap between different branches, improving build times, running your application locally, etc. Part of this is learning, and part of it is effort.
With that, here’s some steps you can take to improve your own quality of dev life.
In general:
- Focus on the things you do multiple times a day
- Start with those things that take the most time
- Pay close attention to the things that annoy you
What are some indications my day to day can be improved?
Well, answer the following questions:
- Do you (or your team) dread working on a feature that requires you to build a specific project?
- Does it take you (or your team) longer to set up a local environment to test a feature, then it does to actually test the feature?
- Can you (or your team) switch between features or tasks without a substantial amount of effort?
These are the types of indicators that show you may need to invest some time in improving your development processes. Some of this is devops related, but a lot of it is just being a disciplined developer and working smarter, not harder. If you or the members of your team aren’t comfortable with the basic workflow of development, it is essential to invest some time to improve those areas. This type of investment will pay back in dividends over and over again.
An opportunity for learning or teaching
Often when I see a young developer who dreads performing certain tasks, it’s because they don’t know a better way to do it. These are opportunities to improve skills, whether it’s you or a team member. There are two reasons that something is painful for you to do:
- You don’t understand how it works
- It’s a bad process
You have complete control over taking the time to understand and learn new things. So, if the first reason above applies to you, fix it. Take the time to thoroughly understand the process.
If the second one applies to you and you have the ability to improve a process, then do it. For the rest of you though, start advocating for change. Improvements you can make yourself, do it! For those you cannot, start comparing the bad processes with a better one, and justify the work by quantifying how much you will improve both the quality and quantity of work you’ll get done.
How to improve your own quality of dev life
Here are some times in my own career that I or a team member did something that substantially improved the team’s quality of dev life.
Speeding up Unit Tests
One team I worked on for almost 4 years had a huge suite of integration tests. Each test would bootstrap our web application, initialize a connection to the database and then set up and tear down a tremendous amount of data in each test. Over time, these tests started taking increasingly long times to run, which increased every deployment, every PR, and had a cascade effect of increasing the time we all twiddle our thumbs and a build processed. Originally our tests ran in seconds, but they were getting to the point where they were taking upwards of ten minutes to run. One of our developers saw this as a really bad thing, and decided to see how we could optimize these. He made some changes to run these tests in parallel, which cut down the testing time from minutes to seconds, and made everyone happier all around. This improvement had a noticeable uptick in productivity, but also just made everyone’s lives easier. QODL.
Publishing Locally with a Bash Script
Just recently I started working with an Angular library that served as a dependency of another Angular project served as a UI. To do this, you have to publish the dependency, have it linked in your UI, and then serve the UI to be able to test. Juggling dependencies like this is a real pain, and one of our devops engineers decided to create a docker container for us to run a local NPM repository that we could publish changes to and manage dependencies easier. This, by itself, was a huge improvement over building, and either manually linking the library or copying a dist folder, but it still had some steps that were tricky to remember. For example, in order to publish to a local NPM repository, you have to update your .npmrc file, and I kept forgetting to do this. So… to save my own sanity and help the team, I created a bash script that would do this for me. It was all of 8 lines long, but it resulted in me never having to think about it again.
Creating a Local Knowledge Share
One of the first projects I worked on used the latest in web technologies (at the time), which meant that we encountered a ton of bugs that hadn’t been worked out in established libraries. We were developing back in 2016, which means that Angular 2 was just being released and we wanted to use it along with TypeScript and Gulp. There were so many nuances to dependency management we kept hitting that we found ourselves googling the same problems over and over again a few weeks (or months) apart. One of our developers decided to create a local database of error messages and step by step guides we used to solve each problem. Not only was it a fun collaborative tool we could all contribute to, but it was a great way for us to avoid wasting tons of time solving the same problems multiple times. You may ask why we didn’t just google it or use StackOverflow? This was reserved for problems that took a lot of research and multiple steps to solve. We had plenty.
Learning to Debug
Web languages have been historically harder to debug than other compiled languages. When the first tools that let you set breakpoints in web code were introduced, we all rejoiced because we didn’t have to continue putting alerts and console.log statements. Just recently a co-worker showed me how easy VSCode makes it to debug NodeJS projects, and I was sold. If I had to quantify how much time this has saved me in troubleshooting issues with team members, it’s on the scale of hours, not minutes. Learn to debug. Learn what your tools are capable of.
Learning to navigate your IDE
Early in my development career, I thought I was pretty savvy at navigating code. My WPM is pretty high, I can navigate a computer with comfort, and I had a good foundation in programming principles. But the first time I met a developer who was REALLY comfortable using the tips and tricks of a powerful IDE, I was blown aware. Here was someone using multiple cursors, click to find a class definition, file searching, custom syntax highlighting, and saved code snippets all with relative ease. I’ve used Sublime Text, Visual Studio, PhpStorm, Webstorm, VSCode, Electron, and Notepad++ as a development environment, and can tell you right now that the developers who bother to both learn and use a powerful IDE will have an edge on those who don’t.
Summary
Programming is fun. You get to learn new things, solve complex problems, and build incredible things. If you are a developer who doesn’t wake up excited to do your job, then you could be in the wrong line of work. Or you could use some quality of dev life improvements.
Hopefully this was enjoyable, if you have your own examples of times where you’ve improved development for yourself or your team, share them below!
