Things have been good recently. Client schedule filled up. I can still do some mentorship engagements and have made it possible to book mentorship calls directly. Curious to see if that proves popular. Similarly if you have some leadership that you think need some of my influence or you are a decision maker that wants to pick my brain, that goes here.

My daughter is growing and hitting important milestones such as rolling over and constantly inventing new noises to make. The summer is cooling down and the view from my office window remains peaceful, I just sometimes need to turn the heating element on in the morning. I hope you are doing okay. I'm feeling pretty good.

Blog posts since last time:

• The Strong Technologies
• Beam Bloggers Webring
• Simple Solutions: UI choices without JS
• Nerves-keyboard - Running a mechanical keyboard with Elixir

Podcast recommendation: JS Party

It is fair to say that I'm skeptical of Node JS and the Javascript ecosystem. I don't love it. What I do like is people that are helpful, nice and enthusiastic about something. I'm also a sucker for a live stream I can hit around making dinner CET. So JS Party is definitely that. Very friendly, quite fun and a good live listen as well.

Whether or not you care about Javascript, odds are you need to work with it to some extent. I don't listen to every episode, some episodes I drop in the middle, just because the subject matter isn't relevant to my interests. But I do care about the web a lot. They recently covered WebRTC. They've also covered writing/editing for writing developers which I obviously found relevant. Javascript is intimately tied to the Web and I think JS Party keeps things light, fun and represent it well overall.

You can find JS Party on Changelog.com.

So about Conway's Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Melvin E. Conway, quoted on Wikipedia

Doing consulting means going into new organizations on a regular basis. This means tackling whatever you encounter there. You are hired on for specific work and that can be your north star but the tools you have are whatever you bring with you and the organization that you just met.

It isn't entirely a surprise when you meet the real organization. You've had talks with decision makers, probably with some techies and generally gotten some info on the place and how they work. That'll give you the surface layer of ideas and also what the organization thinks it is. What you get when you wade into the work is what the organization actually is.

Most organizations will tell you fairly quickly because you will need to be onboarded and that's a vastly varying experience. And sometimes you need to grasp their arcane Jira-process but first you need to be given access which requires a security questionnaire and a drop of blood or you find that there is no process and no time for anyone to onboard you really.

I've walked into small companies that were mostly on fire and under intense pressure and I've walked into companies that were building up protective bureaucracy all around their processes in the hope that things would stop being scary. Both are workable if you squint at them and tackle them in an adaptive way. I've come in, gotten the GitHub credentials and a basic setup guide and just gotten set up and to work on the same day. And I've had processes where me and whoever is helping will spend days head to head on setting my environment up and getting me oriented.

I try not to make any value judgement from this. The way an organization is can certainly  matter to how fun it is to work in but it is also like a personality, it isn't easy to change and it is usually not the fault of any given person. But so far I think Conway gets it right. I can tell a lot about what to expect from the code from how the organization structures and communicates. If it somewhat bureaucratic, or very systematic, or very loose I'm likely to find that reflected in the onboarding, the tooling and the software.

I've also seen a lot of developers apologize for the state of their code bases around this point. That's a credit to them for being concerned for me and having some mix of pride and shame in what they do. But honestly, no organization runs everything perfectly and smoothly. Systems always evolve over time and have their messy bits. I think it is important to not let the shame for not being perfect take over. If you like the org you are in and you think the work is good, the team is trying to do good work, then you are probably in a good spot.

I could always come in and find something to criticize but I tend to always commiserate on the failures in being perfect. I want the devs I work with to relax, feel proud about what they've built and not think the outside world is full of super-professional orgs that do things right. Because I've never seen a perfect system and I've never seen a perfect organization. Yet it all keeps turning.

As always, if you have questions, thoughts or anything in particular to say, just reply or send an email to lars@underjord.io.

Thank you for reading, I appreciate it.

- Lars Wikman