Imagine that - whenever you need to add a new developer to your team, you can send a few pre-written emails, and within 2 to 3 days have 5 to 10 candidates who are 1. Extremely smart, 2. Extremely motivated, 3. Capable of building real, high-quality production-grade software within 4 to 6 weeks of onboarding, 4. Very affordable, and 5. Don't require paying a recruiter fee.

HTML First is an approach to building web applications that centers plain old html. There are several reasons to build in an HTML first way, and one is that it makes hiring and onboarding new developers substantially easier.

Knowing that...

• Hiring is likely one of the most time and energy-consuming duties a CTO has.

• Team dynamics (personalities, preferences, skills) are on of the biggest constraints to structuring and re-organizing teams around business priorities.

The basic premise is...

• There are orders of magnitude more people out there who know basic HTML than who know {insert library here}.

• HTML's conceptual simplicity (everything is an element with properties) makes the learning curve much lower than pretty much anything else.

• HTML (with a few super-simple utilities "sprinkled" on top) is more than capable of producing interfaces that meet the expectations of modern web software users.

• If we design our codebases to be built with plain html as much as possible, we unlock the ability to hire and onboard developers whose only hiring requirement is knowledge of html basics.

• Coupling that with a knowledge of how to utilise coding bootcamps, we end up with an extremely efficient method of hiring and building teams.

What this means

• When a new developer onboards to your codebase and opens up a view file, what they see is familiar (assuming they have some experience with HTML) - it's mostly just html, with small amounts of ruby and a few unfamiliar html properties. The parts that are unfamiliar (route helpers, template partials, hx- and _ properties) are conceptually easy to grasp and can be learned in a few days with a simple cheat sheet and some examples.

• Provided the expectations are clear, the right people are hired, and designs are provided, developers can within weeks get to an extremely high level of output.

What this enables

• Hiring developers for problem solving capability, communication skills, and work ethic, rather than hiring for their existing skillsets ("He's a react expert").

• Hiring developers directly from bootcamps, where 1. Cost is low, and 2. Supply is high. The value of this is difficult to overstate - I had a better experience with two bootcamps than I had with a recruiter that we were paying for.

What it means from a technical perspective:

• No more using js or css libraries with a build step.

• No more using the Rails asset pipeline.

• Using tailwind (without the build step) for css. We created litewind for this.

• Using HTMX for async UI

• Use mini js for interactivity

• No more using Rails form helpers

• No more using stimulus.js, turbo, or Hotwire

• No more hiring "I only do backend" people

Results

Tonic

• Step 1: Build out standards, research & try html-sprinkles libraries with optimum leverage-vs-learning-curve. Create standards documents. Monitor existing developers, evolve standards based on feedback.

• Step 2: Prepare 5 minute Loom video describing Tonic. Send this video to Bootcamp co-ordinators.

• Step 3: Get video responses from qualified candidates. Example

• Step 4: Set up a 30 minute culture fit interview.

• Step 5: Group call with people we want to progress - onboard them on to a VM and have them undertake a rails exercise - provide directions and a design but leave things out intentionally - part of the appraisal is for creative problem solving, so we want to see how much candidates can think on their feet. The server they're working on is live by default so they can see each other's work in progress.

• Step 6: If candidates do a good job with the exercise, make an offer.

Candidates

• Candidate 1: Hospitality background, very customer focused, great communication skills, very eager to learn. Provided them with standards doc and cheat sheet. Paired them with more senior developer on day one. Add them to codebase that already follows html-first principles. Daily group check in calls and sporadic 1:1 calls to unblock, set expectations and explain anything not covered in standards doc. After 2 months was working solo on cient projects, following standards and shipping large MVRs on a weekly basis

• Candidate 2: No previous work experience (but his cousin was already one of our senior devs). Only experience was bootcamp plus doing a little bit of learning through Jen. Followed an almost identical path to candidate 1 in terms of onboarding, learning, output.

• Candidate 3: Hospitality background also. Followed similar path to C1 & C2. Probably our most conscientious team member. Remarkably reliable.

Additional Notes

• An HTML-first approach is well-paired with one that focuses equally on ruthlessly removing potholes - common places that novice developers get stuck in the early days i.e. local development environment, package managers, version control. The most high impact thing that can be done here is having a live shared staging server. More info here.