I wrote a blog post about my experience with Elm through the last year. It went on Hacker News which I don't mind and also the feedback has been really nice. It feels pretty good to hear that people who are Elm die-hards consider it a fair and nuanced description. I wasn't gushing and I wasn't trashing because my takeaways are mixed.

A brand new video has landed where I try to explain what Elixir is. Please give it a watch, the point of it is to introduce new people to the language and its possibilities. Let me know how you like it. If you think it makes a good case, share it to people who you believe are interested.

I also published a video last week on how to set up a server (VPS, in this case Linode, but pretty general). If you or someone you know want to dip their toes into the server skillset I think this provides the very first steps. Let me know what you think. It follows on the explanation of servers video.

Working through signing with the first companies that will be trying my new service around hiring and reaching Elixir developers. If you think your company should get in before I revise pricing, have your technical decision maker reach out at lars@underjord.io.

Software Practices

I'm pretty great at getting excited about things. I'm also pretty crap at keeping my interest up when things turn into a nuanced gray mess with no particular clarity or direction. Sometimes I feel that software industry practices for development end up becoming this sludge-fest.

What am I talking about more specifically? Things we do because we believe it will produce better software. Testing practices, QA practices, pairing, mobbing, project methods like Scrum, Kanban, SAFe, CI/CD, DevOps, trunk-based development, git flow, feature branches, code review.

Since this is a wide space where values meet taste meet profit motives meet convenience meet statistics there is no clear truths. I enjoyed reading the Accelerate book because whether or not it is correct at least it is built on some kind of analysis and can base the claims made on something.

Let's unpack a few of these. Testing practices for example. Everyone should do TDD right? Unless you are one of the many people who don't really believe it provides much value. Or if you are a person that doesn't really care to write tests at all. Or maybe you've found a nice niche of testing your much prefer and want everyone to get into. Maybe you have a business selling a visual browser testing editor and want everyone to use that.

Okay, so dial it back. We all agree on unit tests right? That they are important? No. Okay, can we agree on what unit tests are? No. Okay. Anything we can agree on. Unit? Integration? Acceptance? End-to-End? We couldn't possibly have contentious discussion on all of these right? Right.

QA practices. Well, we need to have a QA step. Well, actually we have UAT (User Acceptance Testing). Well, actually these are all anti-patterns and gates that slow down velocity of iteration and we should really ..

Pairing and mobbing, definitely best practice. Except for the people that consider it an efficient way of halving productivity. And then we have the people that can't quite stand it or find it exhausting.

Scrum is great and works for all teams always. Except for the more than 70% of scrum implementations that fail to reach their goals. But those are of course failures to implement Scrum correctly not an issue with the method itself. It is an agile practice, adapting is the name of the game and if you don't implement it exactly to specification you are definitely not doing Scrum. No true Scrum Master. Brand-name Kanban is supposedly the same. SAFe is the only ready-made option for large organizations. It is also the worse than nothing from what I hear.

CI/CD and DevOps are critical improvements in how we build software and minimizing time to deployment, making sure we get things out in prod to find out if they truly work is the best way to build software. Except in organizations where you really do need to run it past QA, lock down an approved version and time to production is really a matter of days or weeks.

Trunk-based development is the best. Or Git flow is. Or just feature-branches. Or short-lived branches.

Code review is good. Actually it is bad. Real bad. You're not using Pull Requests right? Those really aren't good in a team setting.

...

I'm pretty opinionated though I try to be nice about it. I roughly know where I land on most of this stuff. But the space is a mess and open discussions often get dragged into the morass of people coming from entirely opposite spaces with opposing world-views and driving factors and trying to make assumptions about the other's world.

I can't apply all my ideas of how to do things with any particular client. Because I also have to step into the client's world to some extent.

Some practices require a fair bit of autonomy from all participants. Some practices require experience to make good judgement calls. Some require fastidious gatekeeping to obviate the need for experience.

If you discover something that is new to you and it feels exciting. Be excited about it, try it out. But also be aware that it is usually just one piece of this very large, sprawling space. If people don't share your viewpoint on what is good, try not to assume that they are wrong. Try to understand why they hold their position and if you don't like it, work to steer clear of ending up in their shoes.

I see so many developers speak with certainty about things that are highly contested things. And if you are speaking to your people about the thing you gather around, that's fine. Assumptions have their moments. But if you think everyone that disagrees is missing the point, you are also probably missing theirs.

What are the practices you would choose to implement in your ideal team? Let me know at lars@underjord.io or on Twitter where I'm @lawik.

Thank you for reading as always. I appreciate your time and attention.

- Lars Wikman