You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !
In theory there is no difference between theory and practice. But, in practice, there is.
We’ve come a long way in the last year in the way we operate our sites. We’ve stabilized our applications, improved their response time, and increased their availability.
To accomplish these improvements we’ve done a series of database maintenances that varied from upgraded hardware, to new database servers, to configuration changes that required restart. In each of these operations we had one common goal: minimize the interruption to our customers.
Today we are releasing a small script that has made our lives, and our customer’s lives a whole lot better. We use this script to change the roles of our databases from replication masters to slaves, and vice versa. The fact that the script does all the steps previously performed by a human in a more timely and perfect manner is where we achieve all the gain.
Without this script we used to spend minutes accomplishing these maintenance tasks. With the script we’ve swapped databases under production load with no user noticeable interruption!
The script has lots of hard coded paths and users and other assumptions. But this is too good to keep to ourselves. We’re sharing it with you with the hope that it will improve your operations experience, and that you will contribute back changes that make it even better.
This fall I’ve been taking the Rails for Designers class at The Starter League here in Chicago.
My classmates come from as far as South America and as close as a few desks down (fellow 37signals designers Jamie, Mig, Jonas, John, and Shaun are also taking the class). One student, not in our class, came over from Hong Kong.
My classmates also come from a variety of backgrounds. Some are designers with no programming experience. Others are programmers who work in languages other than Ruby. There’s also a lawyer and a couple Chicago Public School teachers, too. There’s a good 30 year age range spread as well. It’s a diverse and dedicated group. They’re inspiring people.
Class ends in a few weeks, and applications for the next quarter close in a few days, so I thought it would be a good time to reflect on the experience.
Was it worth it? Absolutely. Would I do it again? Absolutely. Would I recommend it to someone else? Absolutely.
I’ve been around Rails since the beginning. At 37signals, designers and programmers work together on the same codebase, so every 37signals designer has seen plenty of Rails in their time. And I’ve tried to pick it up on my own over the years by reading books or getting a few crash courses from co-workers. But it never clicked like it does now after taking this Starter League class.
I think the magic is in how Jeff and Raghu, the two teachers, understand how to teach absolute beginners. Teaching beginners is a unique skill. It requires a ton of patience and a truckload of empathy. You really have to start right at the beginning and assume nothing about what people may or may not know. You have to think like a beginner again. That’s really hard.
Am I a fantastic programmer now? No way. Would I hire myself as a programmer at 37signals? No, I wouldn’t. But that wasn’t my personal goal.
However, after just a few months I have a solid basic understanding of Ruby, Rails, and what programming is all about. I can build a database-backed web app on my own. I can pull in data from external APIs, manipulate it, and return it formatted the way I want. I can read and understand a bunch of code in the Basecamp code base that was complete greek to me before. I know what this code does, why it is where it is, how to manipulate it enough not to break the basics, and how to make changes without having to ask for help. That’s a huge leap forward for me, and it means fewer “hey, can you do this for me?” questions for my co-workers.
I can’t tell you how liberating it is to be able to find my way around our codebase now. It makes me a better designer, too. I can quickly prototype new ideas without having to get someone else involved. Big win. Further, I know where to go from here if I want to dedicate myself to getting better.
And on top of all of this, I feel like I’ve gained an invaluable skill: The ability to see problems from a new angle. Learning how to program has introduced me to a new perspective on problem solving, a new way of thinking. That doesn’t come around often and I’m thrilled to have found it at The Starter League.
If you’re interested in learning Rails – even if you don’t have a single bit of experience – check out The Starter League’s Web Development Class. Just want to learn HTML/CSS? Check out the HTML/CSS class (and there’s an advanced HTML/CSS class, too). There’s even a User Experience Design class. Want to learn visual design or how to improve your current design skills? Our very own Mig Reyes is teaching the Visual Design class.
Applications for The Starter League Winter session are due by Sunday. If you’re on the fence, hop off and apply. You will not regret it.
(Disclosure: 37signals is a minority investor in The Starter League)
There are plenty of books that will teach you to be a better writer, but I’ve never found one so immediately useful as Revising Prose by Richard A. Lanham. Following along as Lanham revises example upon example of real world writing is like exercise for your writing muscles.
My favorite takeaway is this tip for improving the rhythm and cadence of your writing. Many of us have learned to read text out loud as a method to reveal awkward transitions or generally dull passages, but you can also spot poor rhythm visually. A red flag for dull cadence is a run of sentences that are all of similar length. Try adding a carriage return after every sentence or phrase, the rhythm is evident:
While other books have increased my knowledge of writing, Revising Prose changed the way I write and how I think about writing. Buy a copy at Amazon.
Design and programming patterns are wonderful ways of disseminating knowledge. It’s immensely satisfying to bring solution to a tough problem by applying a perfect-fit pattern.
But success with pattern applications is like taking that first innocent bump. You quickly want more of what made you feel this good. And buoyed by the high of a perfect fit, it’s easy to develop pattern vision where code, like Tetris shapes, become mere blocks for fitting into the pattern holes.
With this infliction, you will invariably drift away from the original intent of making specific and immediate pain go away. Where the perfect and legitimate fit will remove a thorn that’s obviously hurting the code right now, the speculative fit pretends to do the same for future hurts.
Now that’s an honorable intention. A pinch of prevention over a pound of cure, right? Only, it rarely works out like that. Speculative pattern applications to avoid future, possible ails is a form of fortune telling. It’s the reason YAGNI was coined.
The further down this rabbit hole you go, the farther away from practical improvement you’ll end up. Go deep enough and the pattern vision turns into articles of faith. Inheritance is always bad, only composition can be our true savior! Only standalone command objects can give us the reusability this application needs!
Turning patterns into articles of faith takes them out of the realm of rational discussion. Code either adheres to the holy patterns or it doesn’t. If it does not, the programmer must first repent, say his 25 rose-delegations, and then swear never to let an opportunity for a policy object extraction pass by him again!
The naming of many design principles supports this theological world view that patterns also at times inhibit. It’s obvious that you’re a sinner if you break The Law of Demeter and of weak will if you forgo the Single Responsibility Principle.
Patterns are best thought of like helpful guidelines and suggestions, not laws, not imperatives. It’s a written account of “hey, if you have this problem, you can try this thing to make it better”. Their core value is transforming some code to better code in a way that’s immediately obvious to the writer.
Evaluating such improvement is easy. You look at the code you had before applying the pattern and after it. Did it make the code simpler to understand? Clearer? Prettier? If you can’t easily see whether that’s so, you’ve been sold.
About two years ago I was approached by Jason to make some art on the 37signals office walls. Around that time I was also beginning to delve into the notion of cityscapes. The first wall I did was an extension of an idea I doodled on a pizza box with a Sharpie marker.
In the time since I have been back to update the blackboards at the office several times and I have explored the cityscape idea further on my own. I have drawn and painted imaginary cities as cross-sections, from above, from every direction at the same time, quick and dirty, slow and precise, cloudy, vacant, abstracted, cartoonized, covered in streets that are like noodles, blanketed in billboards, brightly colored, monochromatic, big, small, and on and on. Each city is a new discovery to explore from whichever vantage I choose, and I’ve only just begun.
One of the things I love about being a “fine” artist is the freedom. When I’m starting a new painting or drawing, I am free to push the idea wherever it takes me. The onus is on me to take the ideas further, and venture out of my comfort zone. There have been so many times that I’ve gotten halfway done with a piece and thought to myself that this particular piece was a failure and amounted to nothing more than a bunch of wasted time and supplies, but then somehow, as if by magic, that work turns a corner and becomes my new all-time favorite. This transformation amazes me every time and it bolsters my often fragile confidence.
I have been an artist for a long time and I have gone through many phases. For years I exclusively did large abstract oil paintings, and there were times when I would draw nothing but cartoons. These past lives would seem to have very little to do with my current work, but the lessons learned from past experiences are not wasted. Instead, the skills and knowledge gained from being an abstract expressionist and in-class doodler will inform a new drawing. These are the tools I can use to build a brand new city, one that I never could have imagined before my hand began making the marks.
The 36 people of 37signals have lived and worked from the following cities during their time at the company:
If we had limited ourselves to only looking within a commuter’s distance of the Chicago office, we would have missed out on a lot of great people.
Remember the web before Movable Type? If you wanted a blog you had to program one. You had to know databases and webhosts and PHP or Perl. If you were “just” a web designer, or a writer with ideas, you had to hire an in-demand web programmer to make it happen. Publishing was expensive and hard.
Apps like Marco Arment’s The Magazine give me flashbacks to that time. Wouldn’t it be awesome to publish my own magazine on the iOS Newsstand? People could read my articles on their iPad Mini, pay without typing in a credit card, and automatically receive new issues as they come.
Sounds great. But here’s the thing. To be on the Newsstand you have to program an iOS app. The tech hurdle is high, and hiring isn’t cheap. iOS programmers are in extremely high demand.
Now is a great time for another Movable Type. Writers would love a way to push serialized content straight to tablets, and the experience would be a boon to readers. Tablets are the best way to read, and Newsstand is the equivalent of RSS for non-geeks. Hopefully apps like The Magazine inspire somebody to make this happen.
—
(Inspired by Craig Mod’s Subcompact Publishing.)
The ease with which you can write software for the web is an anomaly. It’s an incredibly forgiving medium and the barriers to entry are unnaturally low. It hardly takes any craftsmanship at all to connect a web form to a database and have it work well enough to publish content.
Outside of this anomaly, software development is generally hard. Magazine and newspaper publishers around the world are finding out just how hard as they all rush to bring their wares to native apps on iOS, Android.
These magazine apps completely suck, generally speaking. They suck in the same ways that the CD-ROM rush of the 90s sucked. They suck for all the reasons poorly written native software sucks: They’re slow, they crash, they get stuck.
It’s like every magazine is reinventing HTML and programming their own browser for it. Of course that’s going to end badly!
The solution when it hurts to hit yourself is to stop hitting yourself. Custom app development to publish a magazine is just nonsense.
Apple should save its customers from these cruddy experiences by either putting out something like iMagazine Creator (ala iBooks Creator) or find a better way to get existing HTML magazines on the iPad.
Reading magazines on the iPad is too good of a use case to have it screwed up by this rash of crappy native apps.
