All of my public writing, in descending chronological order.
I first heard about this book from my custom GPT, Reading Companion (a mentor for book discovery). Try it yourself and you might discover an amazing book!
This year, one intention I have is to reboot my public writing practice.
This year I realized I am now 10 years into a career in making software. As I reflected on my experience thus far I began to see certain themes that continue to resonate with me in my work. The writing below is an attempt to explore those themes in the hope of better understanding my motivations and what I should seek in the next phase of the journey.
I came across an interesting article over at the Doist blog. It seems their front-end team highly values Deep Work, but was having trouble balancing this with production support demands that would arise. They arrived at a solution that looks a lot like my One-Hand Approach to Production Support where each month, a “hero” is set aside from the team to focus on handling urgent issues. Here’s a bit from the article:
In software development, there is a key success factor that often goes unnamed. It lies below many debates that software teams have and is at the root of many failure and success stories. Kent Beck aptly described this factor in the early chapters of the first edition of his Extreme Programming Explained book. In my experience developers and managers are unlikely to have read this book so I’m here doing my best to accurately convey them. This thinking is not original to me.
Do you have a habit of updating your team’s dependencies? Congratulations, you’ve got fresh dependencies.
In the the time that I’ve spent developing software so far in my life, I’ve seen a tendency for folks to create a false dichotomy – a dualism – between accomplishing goals (“pragmatism”) and desiring to accomplish them in the theoretical ‘best way’ (“idealism”). Alas, logic abhors a dualism and it’s my experience that as soon as you begin creating such a dichotomy, you’ve fallen into a trap. In fact, I’m about to tell you that who you are (the way you do things and your motivation) is inextricably connected to the things you produce (goals you achieve).
Have you ever worked with someone who was seemed able to know the right thing to do in almost all situations? This person wasn’t only very good at solving technical problems but knew how to handle people, systems, and situations too. This was a person that possesed wisdom. In this blog post I will set out to define wisdom and then present the way that I think about how someone becomes wise in a given domain.
Disclaimer: “Best practices” are less like objective truths and more like pragmatic successes in the software engineering field. This is not to say that the correct way or even best way of doing something doesn’t exist, but rather given our finiteness and the external forces of the worlds we inhabit, one should expect some variability here. While I state these in the indicative sense (“X shall be Y”) at the end of the day, the best way to write and ship software will differ from context to context and will (hopefully!) look different in coming years.
Learning something like React takes time. For every excellent react resource that exists on the internet, there are several poorly written tutorials showing you how to make a todo list app. This ‘atlas’ serves as a guide for myself and others. It will probably be updated over time. Information found in the glossary of terms is largely indebted to the various resources mentioned here.
Recently while debugging a performance issue with a JRuby application, I learned that the JVM defaults to /dev/random as its randomness source. This default resulted in a performance problem in the application. This post will cover the purpose of /dev/random and /dev/urandom in general, the cause of the performance problem that I experienced, and the solution that I landed on.
I came across this great GeePaw Hill thread on twitter about refactoring and domain knowledge. The final tweet in the thread sums it up well:
I’ve already written about why you should step away from your IDE and how I’ve benefited from doing so. Now let’s take a look at how this can be accomplished. As always these steps are based on my experience as a finite human being and thus your mileage may vary. The five steps are:
Gary Bernhardt had a great thread on twitter recently.
Across the industry, as the teams trend away from being project-focused toward being product-focused, an increasing number of software developers find themselves being responsible for ‘support duties’. These responsibilities may include answering user questions, attempting to recreate reported bugs, and trying to recover from a system outage in production. There are reasons why it is good (this is the spirit of DevOps in my opinion) that developers will increasingly participate in these duties, but for teams that are taking these responsibilities on for the first time, confusion abounds.
If you haven’t yet, you may want to refer to part 1 of this series where I present a reasoned argument against using an IDE. Now let me try to explain why it was so beneficial for me.
Whether you realize it or not, DNS is a workhorse of the internet ecosystem. It provides the glue that allows someone like your grandma, (who knows that you want a pair of Adidas Ultraboost from footlocker.com for Christmas) to talk TCP with a server on the other side of the world.
I’ve found over the years that there is some music that is well-suited for listening while doing software-development related work and some music is not. Rather than try to derive a special formula for “coding music” I’m going to tell you about some music that works for me. One group I’ve been listening to for awhile that works particularly well is The Bad Plus.
I read a great article at InfoQ this week called The Serverless Sea Change. Generally, the argument made is that code leads to technical debt, therefore the solution with the least amount of code wins. For example: