Indie Belette Blog

Developer, gardener, which one is it again?

· 1827 words · 9 minutes to read
Categories Engineering
Tags web garden

Hi folks! My name is Marine, and I have a problem: I struggle with allocating my life time to all the things I like to do, because I like very different things. Unless… I like these things because they’re not that different? For instance, my official job is “senior software engineer” — which basically means I’ve been building web apps for a while. But I also like to sit behind my window and watching birds in my garden — which implies birds visit my garden. At first glance, these activities are entirely different. However, I’ve been doing both for years, and I can tell they’re just the indoor version and outdoor version of the same kind of endless work.

Our work is never over #

Being a gardener never ends. Gardening is about repeating cycles. Prepare your seeds, feed the birds, make your plants grow, collect your vegetables, cut the trees, again and again… Each cycle is a bit different, though. Here is a year with a lot of snails, too much rain, not enough rain, a lot of tomatoes but the beans are not great this time… It’s a living and complex ecosystem that requires constant care and respect to let you influence it in a way that benefits both you and wildlife. And once you start, you can’t stop, otherwise all your efforts will be wasted.

A web product is never done either. That’s the trap of web development: having to deal with an endless to-do list. There’s always a new thing to do that is more important than the previous thing you had planned to do later because it was less important than the thing you’ve done first, and it never ever ends. It never ends because a product evolves. The purpose of a product is to provide a service to users. Users change, trends change, habits change, new technologies and new ideas emerge and reshuffle the deck. And this ecosystem continues to grow and evolve constantly. Just like a garden.

Keep learning, you’re doing great #

You can make mistakes in web development, as in any other field. One reason I prefer being a frontend developer is that the mistakes I can possibly make are usually not that dramatic. How could you blame me when the data base suddenly vanishes? The worst thing I did is when I was a lonely junior forced to do fullstack stuff I didn’t know how to do, is when the video game studio I was working for released and promoted a game which quickly became unavailable because I didn’t realise our free plan on the Kongregate platform was limiting the number of players.

Mistakes in a garden can be a little more upsetting depending on the context, because unlike pixels, plants are living things. A plant dying is a sadder event than a button not doing anything when you click on it. To become a better gardener, you need to learn how to care for your plants better. But growing one specific plant is only a small part of the job; gardening is about maintaining an entire ecosystem: balancing biodiversity in the long term, planting the right species in the right place, pruning a tree at the right time, etc. The impact of your mistakes is more complex to analyze than the condition of a single plant, and when you make mistakes, your ecosystem is simply not as good as it could be—which means fewer different plants, fewer animals, fewer vegetables, less balance, less enjoyment when sitting and observing. On the other hand, the more resilient the ecosystem is overall, the less impact a single mistake will have.

The “usual errors” in frontend development are a poor UI that your users won’t understand, features that don’t work on certain browsers, accessibility issues that make your app difficult for some people to use, loading data using an underperforming approach, structuring your project without considering long-term maintenance, causing you to waste a lot of time fixing bugs… In short, a series of problems affecting different aspects—product, design, implementation, task organization, communication within the team, etc.—which, taken together, compromise the overall effectiveness of your ecosystem, which is not as good as it could be.

If you got your first job more than ten years ago, then you’re better at this game than if you just bought your first pair of pruning shears, and that’s normal. Whether in your garden or in front of your screen, doing better is usually a matter of experience. Make lots of mistakes, learn from them, and everything will be fine.

Don’t pay the silly price #

So, ready to get started with gardening? Of course, there will be some initial costs that you only pay once. For example, you buy a spade, a pickaxe, pruning shears, and a few other tools, and once you have the tools, you have them. You could compare this to your work computer, and perhaps also to the time spent creating a shared repository for a new code base. But there are also annual costs because — remember? — garden works in cycles. Every year you need seeds or seedlings to plant, every year you need soil to plant them in, every year you need to use water to water your crops, and every year some people who don’t fully understand how nature works feel like they have to buy other harmful chemicals so they haven’t spent all that money only to feed slugs and other critters.

Starting a new web project from scratch is not easy either, and it comes at a cost. The cost is somewhat higher when you do things right because there are so many fundamentals that you don’t have to worry about when you do things wrong. What I mean by right versus wrong in this specific context is finding the right balance between user experience (UX) and developer experience (DX) as soon as possible, and keep it going over time. It’s important to come up with an initial prototype with a few features, but you can’t just add new features at the top of it without any solid — though invisible — foundation. If you don’t invest in dependencies upgrade, your project could end up with security flaws. If you don’t invest in maintaining the structure and cleaning-up dead code, you’ll end up with a plate of spaghetti where every new feature breaks two other previous ones. If you don’t invest in writing tests, you won’t even notice these features breaking and developers will be pressured to implement quick fixes — and potentially more bugs — that they will have to deploy urgently. If you don’t invest in automating build and deployment pipelines, each deployment, urgent or not, will take a significant time and will be more error prone. This is why quickly enough, you need to shift your focus to the developer experience to continue developing your growing product at a reasonable cost. If you don’t, at some point, the cost will become silly, and your users will have to pay for it too.

Whether in engineering or gardening, there is a good way to reduce costs: invest in a more robust and autonomous ecosystem. In web development, this means investing in DX: everything that makes the team more efficient by allowing them to spend less time writing code or performing repetitive tasks, less time on maintenance, less time debugging, less time making the latest version of the application available online, etc. DX is also part of UX, because the development team will have more bandwidth to focus on what really matters: thinking about how each new feature will be learned, perceived, and used, and delivering higher quality features faster.

Invest in building the future #

Remember the every year, every year, every year… thing? In a garden that you don’t invest in, these costs literally represent a sum of money you pay again with each new cycle: paying for seeds, paying for potting soil, paying for water, etc. Investing is about building at the top of what you have to reduce the costs year after year. For instance, instead of buying hybrid plants, find associations that sell reproducible seeds and make sure to grow a few vegetables so you can harvest seeds for the following year. Instead of buying more and more potting soil, aerate the soil, compost your peelings, and use surface compost to nourish the soil in the long term. Year after year, the soil will become richer and more fertile, so you will have more vegetables with less soil and your free compost. Invest once in a rainwater collector, and you will be able to use free rainwater to water your plants. If you buy and use chemicals, many living organisms will die and the balance will be disrupted. You will then have to rely on new chemicals to protect your plants, as nature will no longer be able to regulate itself. Instead, accept pests and accept losing a large portion of your harvest in the early years, and create a biodiversity-friendly garden. Nature will regulate itself, and you will have better harvests once pest predators have settled in your garden.

Investing in the developer experience (DX) works the same: accept initial costs for a better future. Build a test suite. It detects regressions and ensures code changes don’t impact previously implemented features. Setting up such a suite will reduce the number of bugs and therefore the time developers spend debugging throughout the project lifecycle. A few features share similar behaviors? Refactor them so they use literally the same code: if a new feature also needs that code, it will be way faster to develop. Configure a continuous integration (CI). It will avoid manual and repetitive tasks that can be overlooked, like running the tests and verifying they pass before merging something. CI can also manage automated deployment and many other things, imagination is the only limit. Sharing good practices to write maintenable code is not easy; implementing a linter can help with that. Linters define rules regarding syntaxes that can or cannot be written beyond what the language allows. There are many other known DX items in that list, and many other to invent depending on your project and team. But to set all this up and maintain it, you must accept the initial cost and admit the math: After several years — even several months — the overall cost of the product is much lower than it would be without a proper DX.

I’m a web developer: I take care of my garden. Unless I’m a gardener: I develop web apps? I can’t remember which one it is, but what I do know is that the work is never finished, and it tends to evolve over time. It’s hard to build solid foundations, but once you have them and you build on them, you can start looking at the whole thing and say, “Hey, I’m doing a really good job here.”