All posts tagged with writing:
I registered for Out of Office Hours in July, then was invited to the August cohort, so I’ve been in the mentoring cohort for the last four months. I plan on mentoring there for as long as I’m useful - the commitment is so easy and I have an opportunity to have really uplifting conversations a few times a month.
Recently, I was reading Marc Booker’s post about the need for documentation outside of the codebase. A thoughtful comment on the post led me to Peter Naur’s paper on Programming as Theory Building, which I recommend reading1. In it, Naur argues that the act of programming is not a practice of writing code but the work of creating a theory of the problem at hand and a theory of the system to address it. As a team exercise, we practiced documenting our theories of the OfficeLuv system and found it very rewarding.
If you find it repetitive, I recommend skipping to the final couple pages where Naur talks about how best to actually apply “Theory Building” on your own. It comes after the actual paper. ↩︎
AppSignal asked me to write for their blog. My first post is about some techniques we’ve been using at OfficeLuv to responsively scale our queueing systems based on usage. From the introduction:
TLDR: email me at josh at joshbeckman.org
If you release software, you’ll need to communicate new features and bug-fixes to your users. Eleni has written about how OfficeLuv practices writing our customer-facing blog posts announcing features before we build, but we don’t announce every feature in our customer-facing changelog. We do, however, put out an internal product release email every week. It has remained a constant pulse over our 4 years, but we’ve improved the structure and content over time.
At OfficeLuv, we track our individual tasks into epics, like most other product teams. Also like most others, we’ve had one ongoing group called ‘Tech Debt’ since day 2. Recently, I went grooming through a bunch of the stories in there and decided to break that topic into two separate ideas, one for Tech Debt and one for Tech Investment.
Recently, we had an opportunity to trivially parallelize some ActiveRecord queries in our Ruby server. In a common response structure, we needed to both query for the actual data requested along with some meta-information about pagination, etc.
This morning, Eleni and I were reflecting on how our queueing system has evolved at OfficeLuv over the past year.
After interviewing all Summer and Fall, we’ve found the next member of our OfficeLuv Product Team, a talented and thoughtful software engineer.
After interviewing all Summer and Fall, we’ve found the next member of our OfficeLuv Product Team, a talented and thoughtful software engineer.
In June, I applied for Narro’s entry into the Stripe Atlas beta program. Since building Narro incrementally, the worry of financial separation crept up on me a bit. Between the end of one job and the start of another, I had a perfect time to formalize the structure of Narro into a real entity. I thought I could provide a review of Stripe Atlas for anyone considering the program.
I wrote a while ago about a methodology for daily code reviews, one which we implemented originally at ThreadMeUp. Now that I’m building a new team at OfficeLuv, I’ve been excited to start them again. Recently, I was talking to a very good friend of mine and found myself reasoning through the importance of team code reviews. I think it boils down to four main skills for individual team members.
