The Era of Building Things Because You Could
Updated: 1 day ago
Between the mid-1990s and the mid-2000s, a lot of people learned to build software by making things nobody asked for: personal homepages with visitor counters, fan sites about one band or one television series, web rings, forums, guestbooks. Many of them became the engineers who built the professional web that replaced it.
The usual explanation is motive. People built for the joy of it, nobody asked about a business model, and that purity made them good. It's a nice story, and it gets the cause wrong. Plenty of people today build for joy and learn slowly. What the early web gave its builders was a set of conditions that made every hobby project a working lesson. Those conditions can be recreated deliberately, and that is more useful than nostalgia.
What the era actually had
Four conditions did most of the teaching.
Condition | What it taught | What is different today | How to recreate it |
Visible source | Every page was a worked example. "View source" showed you exactly how someone made the thing you admired. | Minified bundles and framework output are hard to read. | Read the source of small, hand-written sites and libraries; write your own project without a build step at first |
The whole stack | You wrote the words, the markup, the scripts, and put the files on the server yourself. Nothing was someone else's job. | Frameworks, hosting platforms and templates make most decisions for you. | Build one project where you choose and deploy every layer, however simple |
A feedback loop of seconds | Edit a file, upload it, refresh. Every change was visible at once. | Build pipelines, containers and review queues add minutes or days. | Keep the learning project small enough to change and see the result in under a minute |
Real strangers | Anyone could find your page and use it, including the people who abused it. | Hobby projects often never leave localhost. | Put the project on the public internet, with at least one feature that takes input from people you don't know |
None of these depended on anyone's motives. A curious builder working inside a large framework, on a private repository nobody else touches, gets none of the four.
The test: take the project you're learning from right now and score it against the four conditions. Most learning projects are missing the last two: they never leave your laptop, and nobody but you ever sends them input.
The guestbook: one feature, a whole education
The fourth condition did the most teaching, and the guestbook is the best example. A guestbook was a form where visitors left a name and a message, shown to every later visitor. It looked like the simplest feature on the page, and it taught input handling the hard way. OWASP's page on cross-site scripting notes that stored XSS "got its start" on websites that offered a guestbook: a visitor would leave a message containing a script, and it ran in the browser of everyone who viewed the page afterwards.
A running example (composite). A test engineer has spent eight years inside a large web framework. She wants to understand what that framework does for her, so she builds a personal site with no framework at all, and adds a guestbook. Her first version renders entries like this:
// Version 1: renders whatever the visitor typed, as HTML
entries.forEach((entry) => {
list.innerHTML += `<li><b>${entry.name}</b>: ${entry.message}</li>`;
});
Week one, friends leave kind messages. Week two, the guestbook gets 300 spam entries in a night. Week three, someone leaves a message that contains a <script> tag, and it runs for every visitor. Her framework had been escaping output for eight years, and she had never had to think about it. The fix is one idea, applied consistently: treat visitor input as text, not markup.
// Version 2: visitor input is treated as text, never as HTML
entries.forEach((entry) => {
const item = document.createElement("li");
const name = document.createElement("b");
name.textContent = entry.name;
item.append(name, `: ${entry.message}`);
list.append(item);
});
By the end of the month the guestbook has taught her output escaping, input length limits, rate limiting by address, a moderation queue, and the decision to store the raw message and escape it when displaying, rather than storing an "already cleaned" version. Every one of those is something her framework did for her, and something she couldn't have explained in an interview before.
That's the discovery move this kind of project offers: find out what your tools are deciding on your behalf. It's also the fastest way to understand the security testing fundamentals from the inside, as someone whose own page got broken.
The test: pick one thing your framework does for you every day (escaping output, routing, sessions, form validation). Could you build a minimal version without it? If not, that's your next curiosity project, and a feature with a public input will teach it fastest.
Why projects you own teach more
Professional work divides decisions. A product manager decides what to build, an architect decides the structure, a platform team decides how it's deployed, and a reviewer catches what you missed. That division is efficient, and it means most engineers rarely make the whole chain of decisions or live with all of their consequences.
A project you own reverses that. You make every decision from "what should this do?" to "how do I put it online?", and when something breaks there's nobody else's choice to blame. Both halves matter. Making the decision teaches the options. Living with the consequence teaches which option was right, and that lesson tends to stick.
The test: list the decisions in your last project, and mark which ones you made and which ones you inherited from a template, a framework default or a colleague. If you inherited nearly all of them, the project taught you the framework, not the craft.
What the motivation research actually says
The old version of this post claimed that money motivation "burns out" and curiosity doesn't. The research is more specific than that, and more useful.
A 1999 meta-analysis of 128 experiments by Edward Deci, Richard Koestner and Richard Ryan found that expected tangible rewards undermined free-choice intrinsic motivation: whether people kept doing an activity on their own time once the reward was gone. That held whether the reward was for taking part, for finishing or for performing well. Positive feedback did the opposite: it increased both free-choice behaviour and self-reported interest.
A 2014 meta-analysis by Christopher Cerasoli, Jessica Nicklin and Michael Ford covered 183 studies and more than 212,000 people across school, work and physical activity. It found that intrinsic motivation predicted performance whether or not incentives were present. Intrinsic motivation was the better predictor of the quality of performance, and incentives the better predictor of quantity. The authors' conclusion is that the two are "not necessarily antagonistic" and are best considered together.
Two practical rules follow for a curiosity project.
Keep expected rewards away from the doing, at least at first. Attaching a revenue target, a follower count or a portfolio deadline to a hobby project in its first months turns it into the kind of rewarded task the 1999 study describes. If it becomes a business later, that's a separate decision, made on evidence (knowing when to pivot and when to persist covers it).
Share it for feedback, not metrics. Showing the project to people who'll tell you what they liked, and what broke, is the kind of reward the research found helps.
The test: if a hobby project already has a metric attached (stars, subscribers, revenue), notice whether you still open it in a week when the number doesn't move. If you don't, the metric has become the reason, and the project has turned into work.
What professionalisation got right, and the risk it didn't fix
The professional web brought real improvements: accessibility, security, performance, and products no hobbyist could build. Nostalgia that ignores that is just taste.
But one loss is concrete. When personal sites moved onto platforms, people stopped owning the place their work lived. GeoCities is the clearest case. Yahoo bought it in 1999, announced in April 2009 that it would close, and shut it down in late October 2009. A large share of a decade's personal web survives only because volunteers, including Archive Team, mirrored as much as they could before the deadline.
The lesson isn't to avoid platforms. It's to keep a copy you control: your own domain if the work matters to you, and your content in a format you can move.
The test: if the platform hosting your writing or your project closed next month, what would you still have by the end of the day? If the answer is "nothing", export it this week.
Making room for it on a team
For engineering leaders, the four conditions are a practical design for learning time, more effective than "go learn something".
Scope it to one person and a whole slice. One person, building something small from end to end, with every layer theirs.
Put it in front of real users, even if the users are colleagues: an internal tool, a team page, a bot. Real input is the fourth condition.
Attach no delivery metric. Learning time judged by output becomes delivery time with a different name.
End with a demo and feedback, focused on what the person found out, especially what their usual tools had been hiding.
The signal that it's working is not the projects. It's people coming back able to explain what a framework, a platform or a library does for them, and choosing differently because of it. Building engineering culture, not just process covers the wider habits this fits into.
The test: after a learning cycle, ask each person what they now understand that their tools used to do silently. If nobody has an answer, the projects were too comfortable.
Choosing a project that will teach you something
A good curiosity project has four properties: it takes input from people you don't know, you deploy it yourself, it avoids a framework for the part you want to understand, and you can get a first version online in a weekend.
Project | What it will teach you |
Personal site with a guestbook or comment form | Output escaping, spam, rate limits, moderation |
A feed reader for sites you follow | HTTP caching headers, conditional requests, parsing messy real-world XML |
A tiny link shortener | Database design, redirect status codes, abuse handling |
A status page for something you run | Monitoring, timeouts, what "up" actually means |
A webring or blogroll for friends' sites | Coordination, broken links, what happens when other people's sites change |
Pick the one closest to something your tools do for you at work. If it starts solving a real problem you have, building for yourself first covers how to take it further without losing what made it useful.
The test: before you start, write down the one thing you expect to learn. When you're done, compare. If the answer matches exactly, the project was too safe; the best ones teach you something you didn't plan for.
What to do this week
Pick one project from the table, or your own, that meets the four conditions. Build the first version without a framework for the part you want to learn, and put it on the public internet with one feature that accepts input from strangers. Keep a short list of everything that breaks and what fixed it. That list is the education the early web gave people, and it's still available.
Final takeaway
The early web's builders became good because their projects had visible source, the whole stack, instant feedback and real strangers, not because their motives were purer than ours. Curiosity makes the work better, as the research shows, and expected rewards attached too early can crowd it out. Recreate the four conditions on purpose, keep the metrics off the hobby, and let a guestbook teach you what your framework has been doing for you.
Sources
Deci, E. L., Koestner, R. and Ryan, R. M., "A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation", Psychological Bulletin 125(6), 627–668 (1999): 128 studies; engagement-, completion- and performance-contingent rewards undermined free-choice intrinsic motivation; positive feedback enhanced free-choice behaviour and self-reported interest. https://doi.org/10.1037/0033-2909.125.6.627
Cerasoli, C. P., Nicklin, J. M. and Ford, M. T., "Intrinsic motivation and extrinsic incentives jointly predict performance: A 40-year meta-analysis", Psychological Bulletin 140(4), 980–1008 (2014): k = 183, N = 212,468; intrinsic motivation predicted more unique variance in quality of performance, incentives in quantity; "not necessarily antagonistic". https://doi.org/10.1037/a0035661
OWASP Foundation, "Cross Site Scripting (XSS)": stored XSS, and its origins in website guestbooks. https://owasp.org/www-community/attacks/xss/
Archive Team, "GeoCities": bought by Yahoo in 1999; closure announced April 2009 and set for 26 October 2009; mirroring by Archive Team and other projects. https://wiki.archiveteam.org/index.php/GeoCities
