Recent publications:

• Regular Programming: About Proprietary things (podcast episode)
  You can't get a good non-proprietary camera. Can we expect that from a phone?
• My perfect stack, currently (video)
  This one has been well received. Some humor, lots of pragmatic technical choices.
• BEAM Radio: eqWAlizer with Ilya Klyuchnikov (podcast episode)
  Ilya spills the beans on Whatsapp's work on type-checking Erlang. Fantastic guest, super interesting topic.

Don't aim for perfection

I've had a number of mentorship conversations with developers and many of them want to publish. They recognize that if they want to go indie they would benefit from putting themselves out there. Every single one has held back due to some high-minded aspiration that is a death-trap for actually publishing.

First of all. You can go indie as a freelance programmer and do no marketing. Brokers, recruiters or a professional network can keep you in business pretty much indefinitely. The path I'm talking about assumes you see some potential upside in audience and building some authority. It is not a necessity for a good living but it can be a significant safety in diversifying your sources.

To the hang-ups. I spoke to someone yesterday who wanted to unpack the way I've found my niche in Elixir as he wanted something similar in another language environment. We discussed publishing a blog as that was a big part of how I was recognized in, and contributed to me getting work in, Elixir. To his credit he straight up asked a positioning question. "Should the blog be purely about Fortran?"

I'm not an expert at this but I think generally the answer is no. You don't have to limit yourself if you have multiple interests. If you want to write the daily-fortran.org blog, yes, constrain yourself. If you want to establish the ideas of who you are and what your are trying to bring to the world, let that be deeper and more nuanced. I actually told him I'd have no reservations about writing or recording something entirely about building the greenhouse we're planning and just putting it out there as "Self-Hosting: Tomatoes". The variety paints the bigger picture and the bigger picture eventually gets the point across.

Hold up. Experiment time.
I kept the preface of this newsletter brief due to some recent feedback. So the sponsors and get their moment here instead. Let me know how you like it.

West Arete is still a steady supporter and I suggest that if you want to do Ruby on Rails that you read up on them and reach out to me.

Beyond that I'm helping a client find a replacement for me as they want to transition me into a more advisory role. That means a senior with tech lead chops, preferrably UK, otherwise Sweden. It is product development, straight up. The tech stack is Elixir, Phoenix and Elm. And the goal is to transform the world of software development and Agile. If you want to disrupt the brand-name scaled agile framework out there, this could be your jam. Email me directly about this one.

I also find that variety helps me hone in on what I care about as I try things. Some things are dead ends creatively or turn out practically unfeasible. And I get more clear on my message, on my values and what I want to provide as I do a variety of things.

Most of my readers are Elixir folks, or at least interested in it. But I also have a ton of people who found my stuff interesting, resonated with an opinion peace or whatever. If I went for purity I'd be sending a lot less useful signal for people to lock on to. And I'd get incredibly bored.

Purity is a common hang-up. "I have to decide what it is about first". Or "I just have to get a bit better at this thing". Publish first, get good later. Publishing is a habit and a practice. Some people do want to just do a single thing and if you know that's you and it doesn't stop you publishing, go for it. Otherwise, don't be precious about that.

Perfection is another one: "I have to come up with something good to write"
No-one that we should compare ourselves to starts out with fantastic novel ideas and just goes up from there. Publish first, improve later. Creativity is a skill and you need to practice it if you want to publish creatively. Write something that would have been interesting to you 3 months ago that feels normal now. There are plenty of people who are where you were 3 months ago.

Buffering and operations is also common "I just need the site set up, a 2 week buffer and then I'll go". Don't start with a buffer. Just grab the live wire and live with the deadline. If you manage to achieve a buffer, great. Otherwise just publish as often as you can and try to be somewhat consistent. Consistency, also a skill, also needs practice.

We can see it as a development loop. First do the worst thing to get a prototype out the door. Make sure it is even something you enjoy and get some feedback from friends and ideally some strangers. This was our 0.1. Then you can improve it.

The 0.2 release is not a big 2.0 where you hide in your office for 2 years reimagining it from the ground up. That rarely goes well. You put new stuff in, fix some things. Ship it. 0.3 should feel like a natural follow-up, new topics that have emerged, considering some feedback. Ship again. You are a one-person publishing process. You can't have QA-gates, timelines, release management. You're not doing SAFe, not even Scrum. You can just ship. Over and over again.

Over time you can have some CI to make sure you don't screw up your grammar if you like. Maybe you schedule publishing. Maybe you just have a checklist to make sure you didn't screw anything up. Don't build everything up front. Start by shipping and then continue shipping. Continuous improvement generally beats strict process and up-front design in building software. Doing a mass of actual publishing beats doing a ton of polishing in getting your words into the world.

Are you looking to put your words into the world? What benefit do you think it would bring? Let me know at lars@underjord.io or on Twitter where I'm @lawik.

Thank you for taking the time to read this. I appreciate it.

- Lars Wikman