Hi there! This weekly series, published on Thursdays, summarizes what I’ve been up to each week and also (sometimes) feature interesting quotes, links, book recommendations, etc. It’s basically a newsletter, in blog form.
This week I’ll keep things on the short side, because I am trying to stick to a strict bedtime. And because why the hell not, let’s make that the theme of this newsletter’s personal note for the week. Yes, it does tie back into software development, in a few different ways.
For starters, I figured out a bedtime that works through deep over-engineering. I used a Fitbit to track my sleep, and then realized a few things about that. Things like “If I want to get 7.5 hours of actual sleep, I need to be in bed for 8.5 hours” and also “Because I have small kids, the idea of ‘sleeping in’ is a lie, even if I’m not having to take care of them as soon as I wake up”.
Those two things combined made me realize that in order to get 7.5 hrs of sleep on average, I need to be in bed by 10:45pm. This gives me 8.5 hrs before 7:15am, which is usually around the time that doors get kicked in and children burst onto the scene.
But in order to get to myself bed by that time, the kids also need to be to bed by a certain time. So I started working backwards from my night-time routine, eventually winding me up to the point where I got to “Kids need to brush teeth at 7:45pm” in order for me to get to sleep on time, so that I can sleep enough and wake up at the right time.
Related to this all, I’ve been tracking my daily routines using a Rails app I’ve been building 30 minutes at a time over the last couple weeks. So this helps me keep an eye on things like “In bed before 10:45pm” and “Kids start bedtime routine at 7:45pm”, and emails me my whole list of items a few times a day (which are not yet in a meaningful sort order, but… meh… I’ll fix that soon enough).
Here’s what it looks like for today, as of right now:
There is an interesting side effect of showing the full list of activities like this, throughout the whole day. Right now it’s 10:30pm. I started this post a little after 10:15pm. So that means I won’t be spending 30 minutes on my software project tonight, or doing my “Right View” Buddhism homework. But I can still get ten minutes of meditation in, if I ship this post in the next two minutes. 🙂
Where this ties into software development is that even if we ignore the various urgent issues and unplanned activities we have day to day, our most basic set of routines all still compete with one another, pulling us in many directions at once.
So say for example you want to start practicing Test-driven development. It may be helpful to first of all, work backwards from your goal to figure out what conditions would be needed to support that practice in your daily work. And then from there, track what your current set of practices are, so you can see how the different daily responsibilities and routines you have may support or interfere with your ability to develop a TDD habit.
I wish I had more time to expand on this tonight, but now I need to get to bed. Maybe more to come soon.
New stuff since last week
July 26 #CodeNewbie Chat — I learned from this week’s chat that DevBootcamp and The Iron Yard are both shutting down, and so that sort of deals a painful blow to the whole “code bootcamps are the future” idea. Personally I’ve always had very mixed feelings on short term intensive programs for developer education, even though I’m one of the first people to have run a school based on that idea.
Read the post for more of my thoughts on that topic, which essentially boil down to “We need real trade schools and that’s a much harder problem to solve.”
Using Prototypes to Explore Project Ideas, Part II — If you already read the first part of this excerpt from Chapter 1 of Programming Beyond Practices, this picks up where the last one left off. If you haven’t seen the first part yet, you can check it out here. This chapter of the book is great if you’re curious about how to very quickly put together working prototypes to drive conversations in the early stages of a new project.
Context-smashing mistakes — In which you can watch a short clip of me messing up while playing Ukulele, and then read some reflections on how the patterns of over-practice and sequential practice are probably to blame… and how it might be worthwhile to look for similar examples when studying and practicing software development, too.
Gotta head to bed um…. now. Next week I will try to do this earlier so that it doesn’t have that “We’ll do it live” feel to it.