I noticed that I didn’t have a copy of the Boring Software Manifesto on my own site, so here’s the original version from 2007 (yikes!) and a video version from 2013. Several years ago, I coined the phrase The Boring Software Development Process, in response to a former employer where project management really didn’t think anything was happening unless we were trying to solve seven crises simultaneously. The manifesto goes like this:
These knives all have handles The first time I was in a programming debate that used the argument “I want a sharp knife”, my friend was arguing that real programmers wrote C and accessed memory directly. I was arguing for Java as the easier, if less flexible, solution. One generation’s sharp knife is the next generation’s whirling machete blade. The phrase “sharp knife” has been bouncing through the Rails community the last day or so.
I haven’t written about my writing setup, tools, things like that in a while, and I’ve got some show and tell. Here’s my current mobile writing setup – really, my preferred writing setup if I’m not coding or otherwise doing something that requires a full operating system. That’s an iPad Air 2, the Logitech Keys-To-Go keyboard, and a Kanex plastic stand that you can only kind of see. Why do I like this setup:
This post is about a very small Rails design decision. A Rails design decision that I’ve made over and over without thinking about it. You probably have, too. And then a weird test failure made me think about it. And then it made me overthink it. Let me explain. I like the idea of writing Rails code such that there is minimal logic in ActiveRecord classes, and then writing a lot of tests that don’t need to touch the database, and therefore run fast.
The Week of Me A couple of quick things. The Web Payment book is out for 50% review, which means that the draft is about half complete, and about a dozen or so people, including the publisher, will be the first readers (well, I guess it got an editorial review at the ⅓ mark). This is a little terrifying. I did a quick breakfast talk this week on trust and projects.
After coming back from RailsConf, I have some tips about speaking at conferences. Which isn’t really a comment on the speakers I saw — I think, overall, the quality of the speakers has improved noticeably over the years — but more along the the lines of tips for people getting started. None of this is a hard-and-fast rule, the most important thing is to speak about something that you find important and interesting, and do so in a way that makes your excitement apparent to the audience.
This week’s things are a little late because of thing one. Quick me update: I did post one item to Medium this week, about how I learned to love Rubocop. Read it, won’t you? Thing One: RailsConf RailsConf was this week, and despite what I might have said last week, it really does feel different in 2016 than 2008. I’ll post some specific talk recommendations when the videos are posted. Well, there’s one talk up already Justin Searls posted his own recording, and what was ostensibly a talk about Rails 5 and RSpec becomes something more interesting about maturity in tools and where we go from there.
As you may know, I’m a, shall we say, older programmer, and as such I’ve developed very strong, quasi-rational opinions over details like indentation and parenthesis. I even wrote a Ruby Style Guide once. (I think I even still believe nearly all of it). And while, I’m traditionally a live-and-let live kind of guy, woe unto the person who comes into my codebase and starts moving stuff around. So when a co-worker suggested we add Rubocop to all our projects at Table XI, I was… skeptical.
Five For 4/29 Okay, I really am doing this for a second week in a row, even though it’s a bit late. The week in me: The web payments book is continuing slowly. Currently, I’m writing about how to set up administrative users, which I’m convinced that most people are penny-wise and pound-foolish about. (“It’s the admin users, we can train them”, yeah, I’ve said it too). I also did a medium post about agile, communication, and the like, which doesn’t seem to have gotten out there much, but you should probably read it anyway.
Looking at it very abstractly, the time a software team spends on a project goes into one of three buckets. Actually writing the correct code. Rewriting code, either because of bugs, miscommunication, or changing requirements. “Process”, by which I mean all the other stuff a team does to share the status of the project with each other. The size of the first bucket is dependent only on the size of the problem itself, although the problem is that it’s hard to predict the contents of that bucket in advance.