Tony Ennis
April 16, 2024
How We Do...

  • Context: This is an internal document which serves as a jump-off point for our developers, but I'm also publishing it to my site as a blog post, for sharing with clients and other interested parties.

  • Overarching Themes

    • We optimise for Momentum (without sacrificing security & stability).

    • We optimise for Contributor Friendliness, which is downstream of optimising for ease-of-hiring, ease-of-handoff, and controlling costs.

    • We optimise for "Your codebase should look like one person wrote it".

  • How We Write HTML

  • Several of these are taken directly from HTML First.

    • "Write code. not too much. Mainly HTML"

    • We favour using html attributes to co-locate styling and behaviour alongside structure. We use separate .css and .js files in some cases, but we prefer the attribute-first approach, with static tailwind for styling and mini js for behaviour.

    • We avoid using rigid component libraries that are difficult to debug and modify.

    • We Disfavour build steps.

  • How We Write CSS

    • For most matters, we default to using Tailwind classes, specifically the ones available in Static Tailwind.

    • We're happy to write a small amount of inline CSS for times when a specific element needs them and they're not available through Tailwind.

    • We write custom CSS for anything that relates to the crossover of colors and states (active, hover, focus, dark mode). This article outlines our approach to naming colors and creating color groups.

    • We use default styling for forms, which can be removed by adding .no-style to the form or input element.

  • How We Write Rails

    • We use Rails a little differently to most people.

    • We don't use most of the Rails defaults and conventions around the frontend - we don't use the asset pipeline, we avoid view helpers, and we don't use Stimulus, Turbo, or Strada.

    • We view Rails as an HTML Container.

    • We start new Rails codebases from Tonic-Rails, our boilerplate that contains examples of most of the patterns described.

  • How We Write Javascript

    • We don't write a lot of javascript. For things like multi-step forms, we prefer using the server for state, and for moderate frontend interactivity, we use Mini Js.

    • If we want to use an external javascript library, we add it to our /public/vendors directory and load it in with a simple <script> tag

  • How We Use HTMX

    • We use htmx to let us fetch data asynchronously - this makes links and forms feel much smoother than they would with a vanilla html approach.

    • HTMX is very full featured. We only use a small slice of it.

    • We use the approach of applying the hx-boost attribute on the page body.

  • How We Build Mobile Apps

    • We use the approach of sending HTML over the wire, using a native "shell" for the login screens, top bar, bottom bar, and side menus. "HTML over the wire" just means sending html instead of json from your server, and using some kind of ajax fetching to swap it out on the client. Two notable companies using this approach are Amazon and Basecamp.

    • We've built a React Native boilerplate for doing this - Tonic Expo.

    • There's more information on how this works at How We Do Hybrid Mobile Apps

  • How We Do Version Control

    • We use a simplified two-branch setup which allows us to retain the benefits of remote development.

    • See Our Git Branching Strategy

  • How We Get Work Done

    • We don't follow a specific project management methodology (scrum, agile, waterfall etc) - we've tried most of them and found they tend to remove critical thinking and turn people into ticket-completers.

    • We are closest philosophically to the approach followed by 37 Signals, outlined in Getting Real, although we disagree on some finer points.

    • We don't over-emphasise fully complete specifications up-front. We start with static designs, get them built, and let the details and interactions fall out of subsequent sessions. We recognise that people will always have more feedback and maximise for number of feedback loops, by sharing early and often, and working with the garage door open.

    • We don't use multi-channel internal chat apps. We use Slack to communicate with clients, and a single Telegram channel internally. We try to limit interruptions and let people put their heads down and get their work done.

    • We do a daily check-in call at the same time each morning. We've written about this (seemingly paradoxical) approach of long uninterrupted spells paired with regular high-bandwidth communication at Long Haul, Short call.

  • How We Collaborate

    • We favour small teams with overlapping skillsets - we've found that the smallest a team can be is two people - one developer, and one non-developer.

    • We do as much of our coding as possible on an always-on live server. This reduces the friction and waiting burden of constantly pushing & merging, and allows our non-developer team members to stay abreast of work in progress and test continuously. We wrote about it here.

  • References

  • Website Page