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.
By constantly applying others’ lessons, developers who regularly redo websites forego learning and implementing their own lessons.
This difference is profound.
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:
You get to improve your websites based on your priorities and preferences.
You learn how to implement things yourself, allowing you to better understand the underlying technologies and tooling.
You learn how to keep a website fresh and relevant in a manner that is light and sustainable, as opposed to disruptive and costly.
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 †.
You acquire a better understanding of the whole website development lifecycle.
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.
Figure: I’m not sure how this relates to redoing and iterating, either. (Copyright King Features Syndicate, Inc., distr. Bulls.)
* 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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe of interest to you, too:
- Next: Vegan Web Developers
- Previous: HTML 2022: 20 Additional Observations from Analyzing the Web Almanac Data
- More under Web Development, or from 2022
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.