Good responses to me asking for interest in helping with the CMS stuff. I will be pinning down some of the specifications as I think they should work, then I'll put that in the hands of those who've offered to commit time and we should poke all the necessary holes in it and then we can start hacking away. We have me and my assistant dev contributing from Underjord and I have another company contributing staff hours that I'll tell you about as we get rolling. Good folks all around. Thrilled to get a good response on this stuff. Thank you all.

Today at 15.00 CET / 9 AM EST I will be running my first live stream where I intend to work on lawik/noted. You can subscribe to be notified about it going live by going to my thing on Twitch where I'm lawikman. Expect LiveView, PETAL stack and potentially some pairing, we'll see who shows up.

New blog post showing you how to do Hello World in Lumen with statically compiled Erlang on x86. Along that I was also told that WebAssembly output is quite close. If you have Rust skills and care about Elixir, do consider contributing. There's a lot of cool Erlang/OTP things to implement still.

And a new podcast episode we have hit my second episode as topic lead on BEAM Radio with episode 7. I take the opportunity to gush about Elixir, Erlang and the community and ecosystem being focused on building thoroughly, well and with good designs. I find it to be a culture thing. I don't think Elixir is unique in this but I think it has to be celebrated.

And just to follow up on last week. I finished up the feature work I was struggling with. Bound to be some polish and after-care but the extra hours I put in got me where I intended to go and I look forward to going to be early like a real parent next week. I'm a bit tired but very pleased with myself.

We all have hesitation, still we must do things

The finished clock is resplendent. At first glance it is simply a clock, a rather large black clock with a white face and a silver pendulum. Well crafted, obviously, with intricately carved woodwork edges and a perfectly painted face, but just a clock.
But that is before it is wound.
- Erin Morgenstern, Night Circus

One of the most important points of progress for me as a developer has been to press past my inhibition about reading the code in libraries I'm using. This dovetails with a popular piece of advice "read other people's code" which as a piece of advice didn't ever speak to me. But knowing Python quite well and encountering a bunch of issues with a Python library I was using is probably when I really broke that ice. Before then I think I assumed it wasn't understandable or that I shouldn't have to look at it. And I mostly didn't need to. But it would have helped way earlier.

It isn't about reading code for learning necessarily, though you learn a lot doing it. I think it is about knowing that you can go further than you might instinctively estimate. I've had things I wanted to do in Elixir that lead me to read the C code of a NIF just to figure out where something was handled. I don't read C well, I don't know the language properly. But it looks enough like everything else that I can figure some of it out.

Starting out in tech you have to lean on the work of everyone else. You never start out knowing enough and you simply have to take it as read that the database saves your data, that disks can store files and that generally speaking your variables will successfully get stored in memory. Most of these assumptions remain in most of the work. But as you go your knowledge of the nuances expands and you can consider more and more things as you build. You are aware of the pitfalls and must balance them with the trade-offs. Otherwise you will attempt to put highly available Kubernetes setups everywhere. Or write everything in meticulous C. The only* way* to be sure*. Asterisks indicating entire fields of study, full of nuance.

As you grow in experience you still lean on the work of everyone else but you have the capability to look further, consider further and better heuristics for determining trade-offs. You might look into a library and go "huh, this doesn't really do much and I'd rather just have my own variant of what it does" or look at a library and think "I wonder if this actually solves my particular need, it says on the tin but I've spent my last few days fighting this quirk of this problem and .." which leads to reading some code to resolve your hunch.

The sooner you get comfortable reading and understanding other people's code in a language the quicker you will be productive in it. I say this with certainty because very few jobs are green field development, most mean that you need to get familiar with a code base. That means getting an idea of how it works at a broad level and for whatever you are doing to it, at the specifics level.

And this is where I think we can ask a bit more of ourselves. Because I think the apprehension about diving into more code is mostly a brain ghost. Certainly you should be kind to yourself. Be aware that you will be lost the first few times you do it. But you can make it make sense by keeping at it.

Understanding more is the key to doing better. Being willing to take one more mindful step or think one step further is key to creating something that's noticeably better. The things you already know probably seem obvious to you and you are mostly concerned with what you don't know. Well, the things you know well are way out of bounds for someone else. Think back and consider what you were capable of and aware of when you started and compare it to now.

Imagination can let you see what you would be able to do if you learned even more. The outer bound. Essentially, strive to know more things. Don't accept arbitrary barriers. Try things that seem challenging. That is the only way I know of that builds wisdom. And wisdom is the only way I know of for avoiding past mistakes.

The more you know.

As always, you can reply to this message using email lars@underjord.io or you can cast a sending spell on Twitter where I'm @lawik.

I appreciate your attention. Thanks for reading.

- Lars Wikman