Time well spent

722 Ee524 5 Dbc 4352 80 F2 6303 Ea55 Dfaf

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
  • Fixing build process problems

How?

Code formatting is highly subjective and there is no point in arguing about it. We avoid wasting time doing this 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 anymore. Additionally we have ditched preprocessors like Sass and only use native CSS custom properties instead.

Bundling and minification etc. is then 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 often use rollup.


⚠️ Can be prevented

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

How?

We are currently learning Elm to eliminate spending time on fixing runtime exceptions. Based on the experience from other companies using it in production, we are certain this will greatly improve the speed, quality and correctness of our software.

Reproducing bugs can also be made easier 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 many dependencies 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 all text in structured JSON files.


💪 Necessary stuff

  • Fixing browser inconsistencies
  • Writing tests

How?

This depends a bit on the project, but usually we only support the latest two versions of 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 bugs yet, e.g. only allowing a certain range of numbers. Therefore we write tests to cover these cases. Meaning correct software = good type systems + some 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 love 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 makes developers highly effective.

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 is extremely important. It 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.