Presently:

• Some kind of video about ElixirConf EU is in the works
• I recorded a ton of my trip to Code BEAM Stockholm Lite so that should also turn into a video
• Recorded what might turn into a more local vlog episode
• Started experimenting with the video format, if you couldn't tell

Engineering?

Most of the hard things in software are hard because they are people things. Cache invalidation is tricky because it has a lot of weird corner cases and taken in the most dry perspective possible it can be considered a fully technical problem. The next one in the meme is "naming things".  Naming things is only hard because of people.

I don't find naming particularly difficult. I have pretty strong opinions, I generate ideas easily and I'm happy to just slap a name on there that sounds good to me. The challenge shows up when people disagree about my choice of name. They may find naming difficult because they apply a different rigor to the process. They may be trying to cover more bases, consider more angles or just be well aware that they aren't seeing all the angles.

Often I've seen this cause a type of paralysis that I have no patience for, personally. I have a strong bias towards action. This is not inherently a good thing. My opinionated approach is not inherently a good thing. It is often useful to me because the world is soaking in short-term thinking and appreciates opinion, direction and drive.

Time and time again I hear people say "this is good engineering" or "this is the right way to build software" or something very close to that sentiment. Maybe they push TDD, maybe DDD, maybe Scrum, maybe Kanban, maybe going back to the core agile manifesto bullets. To some you can't build a good thing until you have specified requirements and to some you can't build a good thing if you specify requirements.

No-one knows how to build software. One big reason the book Accelerate is so popular is that it at least leans on some scientific basis in its push for why tight iteration and DevOpsy stuff is good. I haven't checked their work and I am not qualified to. But they did try to science it. so that gives us something we can gesticulate towards and go "see, facts supporting my opinion!" when we have an argument.

There has been good, bad, successful and failed software built in every way imaginable. More bad and failed probably than good and successful.

But the field is a mess and we all lean on our reckons. The field is muddy, messy and utterly full of human factors. So we take our preferences, we form opinions and then we argue them as fact-ish.

Some will say that their strict FP eliminates entire classes of problems. Some will say that there is no evidence of that and that their dynamic and loose language is more productive. Some say 100% code coverage, unit tests and quality control gates. Some argue for a minimum of tests or none at all. Many argue somewhere inbetween. Some argue for estimates and some against, both sides vehemently.

Because the facts are so unclear we lean on taste and preference. We pattern match our monkey minds to find a tribe we feel like we can work with. Overall I think that works. We have a few different camps and styles in software that do things their particular ways. The middle of the bell curve will mix, match and do a bit of everything.

We have limited facts and a complicated problem space. An opinion expressed with confidence that lines up with what you long for or have invested in, that's the answer. It may not actually be a better answer than anything else, it might even turn out to be factually bad. But who could say for certain?

Last few days I've spoken to a lot of developers for the recruiting I do and it reminds me that we are all at very different moments in our journeys. We are all looking at the software world and needing different things at that moment. Some are looking for their best solution, striving towards an ideal. Some are looking for things to chill out, striving for a pragmatic middle-of-the-road. Some are frustrated by the lack of rigor and just want people to do engineering to this whole mess of a space.

I am very glad I can still find many different angles interesting and worthwhile. I certainly have my opinions and preferences. I express my confident opinion. But I also see how others operate and still go "hmm... what if that is the right way?"

Am I wrong. Can we just do science and engineering? Should opinions be ditched entirely? I enjoy getting your input via email or federated at me through lars@underjord.io or as @lawik@fosstodon.org.

Thanks for languaging with me. Your time investment is appreciated.