Redo Websites Less Often (to Become a Better Developer)

Published on October 18, 2022 (↻ October 20, 2024), filed under Development (RSS feed for all categories).

A typical conversation with a motivated frontend developer running their own website can easily yield the following observation: The developer keeps redoing their website. They try Bootstrap, Bulma, Tailwind. They try Vue, React, Remix. They try Jekyll, Gatsby, Eleventy. They try Azure, GCP, AWS.

The Pros and Cons of Redoing

This is great: A developer redoing their and their employers’ websites like this is getting familiar with a large number of different frameworks, systems, and platforms. They optimize their learning towards familiarity with as many of these as possible.

But this is also an issue: They can only get to know these frameworks, systems, and platforms so much. They may never reach the limits of them, or learn how to overcome these limits. And by not doing that, they never get to push their projects beyond what these tools offer them, on the surface.

By constantly applying others’ lessons, developers who regularly redo websites forego learning and implementing their own lessons.

This difference is profound.

It’s an issue amplified by the way our employers and their Marketing departments run websites: fire and forget, much of the time. Marketing ❤️ redos. ^*

Become a Better Developer by Iterating

What do you want to do?

You do want to redo websites: The advantages of getting to know a healthy number of solutions and tools are great, and the ability to put a website on a new foundation is a useful one to acquire.

But you also want to iterate, which means to constantly make small improvements over long periods of time. (Web design is a process.)

Iterating, and learning to iterate, comes with advantages that make you a better developer:

1. You get to improve your websites based on your priorities and preferences.

2. You learn how to implement things yourself, allowing you to better understand the underlying technologies and tooling.

3. You learn how to keep a website fresh and relevant in a manner that is light and sustainable, as opposed to disruptive and costly.

4. You feel more of the pain of technical debt, and learn better how to manage technical debt. Overall, you learn how to develop so that the output is maintainable. ^†

5. You acquire a better understanding of the whole website development lifecycle.

6. You spread your work more evenly and healthily.

A Spectrum and a Choice

Now, there’s a spectrum here ranging from solely redoing every project and only ever iterating. But from my experience ^‡, you want to make a choice, and you can make it a smart one:

Remain aware of the two distinct options of brute-force maintenance by redos, and soft and subtle maintenance through iterations.

Learn, and that’s something well worth exploring, what project merits what approach. (We may not always get it right—sometimes a site should be redone; and sometimes we want to hang tight and iterate on it; and sometimes we want to defer the redo, to first get a better understanding of what we’re actually tasked to maintain.)

Make it a conscious choice, then, when to redo: What do you choose for your employer’s or client’s website and its development; what do you choose for your own website and your professional growth?

But—stay clear of the extremes. If all you do is iterate, you will not get the value that exploring new frameworks, systems, and platforms offers you. And if all you do is redo, you will cut yourself off invaluable lessons that make for a seasoned and balanced developer.

Which is, again, why it’s useful to redo websites less often.

^* When I ran Jimdo’s Marketing Tooling team, responsible for jimdo.com, we created a museum showing the various designs Jimdo used over the years—because in many years, and under every CMO, Jimdo had redone their design, often changing their systems, too. It’s a popular pattern.

^† Maintenance and maintainability are sorely underrepresented in coverage in our field. You find tons of best practices on everything—except for maintainability and maintenance. (I once wrote two guides on maintainability, but I can’t comment on their quality, and we need much more than this.) I believe the reason for this lack lies in our field’s said prevalence of redoing, rather than iterating.

^‡ Don’t get me started. Personally, I believe in and practice making my developer life difficult so as to learn more; and I believe in and practice iterating on projects. Just take this site, which is still based on a 2005 redo. The lessons you learn when iterating on projects are invaluable; and they are distinctly different from redoing.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)