Redo Websites Less Often (to Become a Better Developer)

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.

Ultimately, developers regularly redoing websites forego learning and implementing their lessons by constantly implementing others’ 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—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, not on somebody else’s (at least, not a third party’s).

2. You learn how to implement things yourself, likely allowing you to appreciate both the underlying technology and the challenges of providing tooling based on that technology.

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

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 get to understand the whole website development lifecycle a lot better.

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 website and your own professional growth; what do you choose for your employer’s or client’s website and its development?

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 meiert.com, 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.