I've been thinking about the things that make it easier for me to approach new codebases. I'm going to try and list down a few. I have titled this post as a pt. 1 because I imagine I'll come back with new ideas as I get to spend more and more time working on new codebases as a consultant (at least, much more frequently than when I was working as an in-house engineer).

I get to write Elixir at my new job! This is my first time writing it in a professional setting. I have written Clojure for work and while Clojure and Elixir share quite a few similarities, I am learning lots of new things. Most of my learnings are around Elixir idioms and growing my knowledge of the concepts that the syntax of the language wraps around.

In a sense, this post is sort of a follow up to my post on side projects vs work for learning. The previous post is pretty... vague and hand-wavey, but this one will be a bit more concrete on some of the things I've learned. Let's jump into it.

Today I'm writing a small post to thank my blog (and circuitously myself, I suppose) for helping me find work I'm interested in doing.

I started a new job last week at a software consultancy. The consultancy places consultants at different clients in pairs or small groups. The clients could have any range of challenges or technical problems, using any variety of languages/tech stacks. And so, when joining, the consultancy tries to find a best fit between the consultant and client based on technology and interest.