Current curiosity: Developer Experience

A term that has been gaining popularity in the past few years is “developer experience.” It’s like “user experience” but for APIs. Meaning how easy it is for a developer to navigate a specific coding platform.

But we’re of the opinion that “developer experience” can encompass more than that. But maybe just for the purposes of this Curiosity, what if it could express all aspects of what it feels like to be a coder? What if it could refer to the methods that dial down the frustration and dial up the bliss of creative problem-solving?

This is an ongoing pursuit of ours. We’re looking to make our “developer experience” at Fully as close to blissful as it can get. For two reasons:

  1. It makes our work lives happy.
  2. It makes the code way better.

Here are some of the methods we’ve been testing:

MODULARITY

Code can often end up spaghetti-like, with separate functions intermingling in a long sequence of code. When an issue arises, you need to sift through a whole lot of code to identify the problem.

The consequences of spaghetti code are frustrating: fixes take a long time, it’s hard to incorporate new functionalities, and you can’t use the same function in a new project.

So we are working to make our code less like spaghetti and more like lego blocks.

Greater modularity makes for a happier developer experience. On top of all the other benefits, it makes the code more immediately understandable to one another so we can more seamlessly work as a team.

Mostly is just takes discipline. To finish what you set out to do rather than skipping around or making quick patches.

Progress on modularity thus far

50%

Martina

50%

Mikael

40%

Jonathan

85%

Jonas

Goal

97%

Martina

90%

Mikael

95%

Jonathan

95%

Jonas

TEST-DRIVEN DEVELOPMENT

We initially started with writing tests when implementing fixes. This proved to be an awesome way of working, so now we’re on a path to using tests not just for fixes, but as a method of actually building websites and services.

Test-driven development is technique that many developers swear by, as the advantages are massive. They include 1) faster code execution, 2) higher-quality code, 3) better documentation, 4) easier fixes.

It does take a bit more time initially, but the time saved further down the road makes up for it in spades. As Frodo says, “shortcuts make for very long delays.” So where back-end coding is concerned, we’re on the path to making test-driven development our standard method.

The frontend is a different story. It’s less suited to this method for a variety of reasons, but primarily because the look and feel of a website can’t be broken down into such technical parts.

So in the statistics here, you’ll see a pretty wide gap between Fully’s those focused on back-end (Mikael, Martina) and front-end (Jonathan, Jonas).

Progress on test-driven development

20%

Martina

80%

Mikael

10%

Jonathan

2%

Jonas

Goal

70%

Martina

100%

Mikael

20%

Jonathan

50%

Jonas

PAIR PROGRAMMING

Another technique we’ve been experimenting with is pair programming, where two developers work side-by-side, with one at the keyboard typing (the driver) and the other steering the overall direction of the code (the navigator).

Not only does it look adorable, we’ve found it to be really effective. The quality of the code skyrockets. And it makes the more challenging tasks way more fun.

We would like to do more of it, but we’re a small agency handling several projects in once. Effectively cutting our coding team in half to pair-program 100% isn’t feasible at the moment. So we’re trying to make smart use of it – pairing up to code difficult transitions – but we would still like to expand the practice.

Again, this method is more suited to the problem-solving of back-end code, rather than the taste-based decisions of front-end.

Progress on pair programming

15%

Martina

30%

Mikael

25%

Jonathan

0%

Jonas

Goal

80%

Martina

80%

Mikael

25%

Jonathan

20%

Jonas

COMMON STANDARDS

No two coders are completely alike in their preferences with regards to tools, styles, organizational methods, etc.

But it is important to “speak with one voice” – to have the code in a certain project consistent throughout. So we’re working towards creating a full set of coding standards (mutually agreed upon, of course.) We’re currently looking at PSR2 standards and adapting them according to what we like best.

Having clear expectations about how something should be written allows us to stop sweating over small details and focus on the bigger stuff. Though the general thought is to leave some breathing room, especially where the artsy front-end is concerned. And because we’re not robots.

Progress on common standards

40%

Martina

50%

Mikael

50%

Jonathan

50%

Jonas

Goal

96%

Martina

100%

Mikael

90%

Jonathan

75%

Jonas

As coders, our happiness index is pretty simple:


/User/fullystudios
└─┬ We’re happy:
  └─┬ When stuff works
    ├ When it keeps working
    └ When it’s easy to fix
----------------------------------------------

Generated in 0.20ms

If this is all happening we feel like wizards, cathedral architects, code samurais. But the trick is to keep the creative spirit very much alive, rather than letting it become squashed by the techniques/standards mentioned above.

Like learning to cut vegetables properly, at first you have to unlearn how you’ve been cutting vegetables your whole life and the new techniques feel heavy and unnecessary. But once you master them, once they become second-nature, your speed and stamina increases and your creativity can be fully unleashed.