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:
- It makes our work lives happy.
- 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
Martina
Mikael
Jonathan
Jonas
Goal
Martina
Mikael
Jonathan
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
Martina
Mikael
Jonathan
Jonas
Goal
Martina
Mikael
Jonathan
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
Martina
Mikael
Jonathan
Jonas
Goal
Martina
Mikael
Jonathan
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
Martina
Mikael
Jonathan
Jonas
Goal
Martina
Mikael
Jonathan
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.
