Time well spent

As developers we touch a lot of different topics during a project and some are more valuable than others.

This is an incomplete list of things we should and should not spend our time on.

☠️ Wasted time

  • Code formatting
  • Waiting for the build process
  • Fixing build problems

How?

Code formatting is highly subjective and there is no point in arguing about it. We avoid wasting this time by using code formatters like prettier or elm-format. Configure your editor, so that it formats code automatically on save.

To avoid waiting or fixing a build process, we started using ES modules natively and without minification during development. This means a simple reload does the job and source maps are not an issue. Additionally we have ditched preprocessors like Sass and use native CSS custom properties instead.

Bundling and minification etc. is added at the end of a project with as simple tools as possible: no webpack, gulp or grunt. npm and yarn have scripts support and for bundling we use rollup or parcel.

⚠️ Can be prevented

  • Fixing runtime exceptions
  • Reproducing bugs
  • Fixing CSS regressions
  • Updating copy

How?

We started using Elm on some projects to eliminate spending time fixing runtime exceptions. In our experience and from other companies’ experience using it in production, we have seen how it improves the speed, quality and correctness of our software.

Reproducing bugs can also be improved a lot with Elm. Elm’s debugger can record user sessions and export them as a file. This can be imported in the project and replayed to reproduce bugs.

Most often CSS bugs and regressions are caused by having too much coupling between components. To prevent this we’ve come up with our CSS architecture, which does not require any tooling.

When setting up projects, we make sure that our clients or users are able to update copy themselves via a CMS or we make it as easy as possible for us to update copy by having copy in structured JSON files for example.

💪 Necessary stuff

  • Fixing browser inconsistencies
  • Writing tests

How?

This depends a bit on the project, but usually we only support the last two versions of modern evergreen browsers. This means a lot of browser inconsistencies are fixed automatically over time. For JS we have had a good experience with polyfill.io. We usually write CSS for modern browsers and don’t fix it in older ones, if it doesn’t completely break the experience.

Modern type systems are really good at eliminating a whole category of bugs. Nonetheless even good type systems cannot catch all of them. Most modern type systems cannot limit function arguments to a certain range of numbers for example. Therefore we write tests to cover these cases. If correctness is critical, the software needs both: a good type systems and tests.

💖 Most Valuable Time

  • Solving the actual problem
  • Teaching colleagues
  • Writing good pull requests
  • Reviewing code
  • Refactoring
  • Finding the right types

These are things we should spend most of our time on.

Our main goal should always be to solve the client’s problem. This means we should create value for the client as fast as possible. What value means varies greatly from building a playable game to setting up a website with a complicated content hierarchy.

We enjoy teaching our colleagues and working on problems together. A single developer is limited in the amount of work she can do. Teaching peers is what improves our productivity as a team.

Writing good pull requests is another form of sharing knowledge and discussing problems. We make sure to spend enough time on this and don’t accept code blindly.

Reviewing code can take a lot of time, but the better we get at writing readable code and partitioning our work in chunks, the easier it will get. Additionally this is another opportunity to learn from each other.

Refactoring means changing the code without changing its behaviour. The reason for changing it should mainly be too make it easier to understand or to make specific decisions more explicit.

In languages with good type systems we strive to communicate solutions as closely as possible with the types we define. This way our colleagues can jump into a project they have never seen before and don’t have to fear breaking important features, since they get nice error messages that already convey the domain problem/the solution.