Developer experience for the motivation
I watched this YouTube video a few months ago that really stuck with me. It was about how to organize your kitchen. The video went through 10 tips, but before getting in to those tips it talked about the why. Why is organizing your kitchen important in the first place?
Well, the standard and obvious answer is that it makes the process of cooking smoother and more efficient. No digging around for those tongs as your chicken threatens to burn. But here's another answer that is perhaps less obvious and more important: motivation.
That's right, motivation. The desire to even be in the kitchen in the first place. If you have to dig through a chaotic cabinet under the sink to find the right pan, in practice you're just gonna end up ordering takeout. And that's a problem that compounds upon itself. If you cooked instead of ordering takeout you'd be building up your skill, making things easier for next time. Instead, your failures and bad experiences make you averse to wanting to cook in the future.
I think something similar is true in programming.
One simple example of this is with Vite vs Webpack. I recently was working on a side project that used Webpack.
npm run start would take a good ten seconds or so. And I restart my dev server a lot, imposing this annoying ten second cost on myself because... well, I'm not sure. I'm paranoid about hot reloading not working? Because I suck?
Anyway, I ended up switching to Vite which is more like one second instead of ten (don't quote me though). Soooo much nicer. I notice myself smiling inside whenever I restart my dev server. It's like reaching for a knife resting neatly on a wall mounted magnetic strip instead of having to dig through a messy drawer.
Another example that comes to my mind is with flaky tests. When I was working on Premium Poker Tools, my end-to-end tests got out of control. I'd make a small code change, random tests would fail, it didn't make sense, I'd have to spend hours debugging. Ugh. It definitely made me feel unmotivated.
But as a sort of counterexample, for a side project called Calibration Training, I didn't have any tests. At first it was fine, but at some point I started feeling nervous that a code change here would introduce a bug there. It's a little bit like the feeling of being in one of those antique shops: you don't want to accidentally bump into something and then hear the sound of glass shattering. Except even more scary because with programming I was especially worried about things failing silently. Anyway, this too was a bad developer experience. As a developer you want to write code, run tests, see them pass, feel confident that things are pretty stable, and move on.
Complexity itself is perhaps the worst. Well, when it gets out of control. No one wants to deal with the 13,000 line module in the legacy app. But everyone is motivated when starting a new project! When starting a new project, oh man, you can just crank out feature after feature after feature. It's almost addicting.
Complexity can be wrangled though. For Premium Poker Tools it grew pretty fast. As it grew I'd slowly start becoming overwhelmed. I'd hit a point of being sufficiently overwhelmed where I'd spend some time refactoring. Then I'd feel good and motivated again. But then the complexity would creep back up. So on and so forth, for however many cycles.
Because I worked for myself, I was actually able to take the time to refactor. But at almost all jobs I've had, that wouldn't have been the case. Complexity never gets wrangled. It just sits there and rots. Developers can smell hot rotten it is too, and they try to avoid touching it. "Maybe Alice could work on that feature instead." And when they can't avoid touching it, it's weeks of work for like a two line pull request that leaves everyone feeling demoralized at the end. Like those nights when you look up at the clock, see it's 9:30pm, and realize that it somehow took you three hours to cook chicken and broccoli for dinner even though the recipe said 45 mins. Or is taht just me?
Another thing that contributes to developer experience (DX): working with technologies where you like the humans behind em. For example, Chakra UI seems to have really awesome people behind it, and that makes me happy as I use Chakra. OTOH, Java feels like it has a faceless, blood sucking corporation behind it.
Pointy Haired Boss is confused by all of this though, so let's take a moment to address his confusion. He doesn't see what the big deal is. Motivation? Morale? This isn't summer camp. It's business.
Developers are getting paid to write code, and paid extremely handsomely. Isn't that enough? Isn't that what being a professional is about? Putting in a good 9-to-5 regardless? Working on whatever tasks are of highest business value to the stakeholders, regardless of how "smelly" the corresponding parts of the codebase are? Sure, some people might drag their feet a little if the code is smelly. They might hang out at the water cooler a little longer, take a longer lunch, play an extra game of ping pong. But these are all just marginal things. Maybe 7 hours of work instead of 8, but not 3. Right?
I'm afraid not, Pointy Haired Boss. I'd guess that motivation can be the difference between something like a 2-4x improvement in productivity. It's a little sad to say, but the idea that we're all professionals who will work equally as hard regardless of the conditions is just untrue.
And hey, maybe that's not sad. Maybe that's not something to be ashamed of. Maybe we should embrace our humanity.
To be clear, I'm not proposing that our codebases need to spark little nuggets of joy in every corner. No. I think we should, as always, be pragmatic. Look at the pros and cons, find the right balance, and do what makes sense. But realize that DX often has quite the large impact on motivation, and motivation often has quite the large impact on productivity. Incorporate that into your cost-benefit calculus as you may.
If you have any thoughts, I'd love to discuss them over email: email@example.com.