I saw a great talk by Corey Haines where he made the distinction between test-first and test-driven development:
Test-first: pain makes you change your tests
Test-driven: pain makes you change your code
This really got me thinking – how you handle pain in your codebase makes a huge difference in the progress you can make. Pain shows up in many ways in your codebase, but often it’s not listened to. Often a band-aid is added or only the symptoms get addressed. That will fix the problem – at least temporarily – but it doesn’t make much sense as a long-term solution.
Better to listen to what the pain is telling you and make changes to address the cause rather than the symptoms.
At the Golden Gate Ruby Conference this past weekend, one of the main themes I got from the talks (and conversations between them) was a notion of how important it is to get back to basics in order to cure major issues.
It’s a good point. The shiny new things make for sexier conference talks, but solid fundamentals applied over the long term is usually the path to happiness for a given codebase or system.
I’ve found this true in music and sports as well. Working on “low-level” fundamentals is often the best way to improve. Usually you don’t need something fancy or new to come along and improve things – you just need to learn to correctly use the tools you already have.
Creative work is hard. Whether it’s writing, drawing, programming – it’s taxing in a way that work that allows you to turn off your brain isn’t. To keep doing your best work, you need stuff that will help keep you inspired.
My dad’s a painter/digital artist and for a long time he’s had this quote by Charlie Parker on the wall of his studio:
Don’t be scared – just play the music
I love the simplicity of that quote. It makes it seem possible and even easy to do what you need to do. It also forces you to abandon any excuses you have and just get on with it.
I found a quote I liked so much I’ve had it in block letters on the huge-ass dry erase board in my home office. I found it in this great slide deck from Netflix and it goes:
Mediocre colleagues or unchallenging work is what kills progress of a person’s skills
Cuts through the bullshit and makes you ask some uncomfortable questions, exactly what inspiration is supposed to do.
I’m still getting up-to-speed using Rails (4 months in and counting) and I’ve found some great resources which have helped me kick-start the process and tackle the steep learning curve of using a totally new development language/environment:
1) Ruby on Rails Tutorial (RailsTutorial.org) – I spent the week before starting my current (and first) job using Rails by literally consuming all I could from this site. It’s great for learning Rails 3 from scratch. I love the approach of having both a book and screencasts which cover the same basic material but with a slightly different approach. The author Michael Hartl really knows his shit and has put a lot of thought and effort into the material. By working through the tutorial to the end, you will have built a fully-functional Twitter clone (you can view mine here).
2) Ruby Koans (RubyKoans.com) – A great resource for learning Ruby from the ground up. On top of helping clarify a large number of areas in the language, the Koans are really fun to run through. They take the form of a bunch of unit tests that are broken, which you need to go through and fix, learning some piece of Ruby functionality with each one. A lot of RoR sites/books focus more on the Rails side, but the Ruby side is equally important. I really got a lot out of running through all the koans and it helped me look at elements of the language in a different way.
3) Various projects on GitHub – There’s no better way to get proficient at something than to have a ton of good (and bad) real-world examples to look through and that’s exactly what GitHub provides. You can check out code for all the gems you use everyday – looking at every commit and letting the code tell the story of how it came to be in its current shape. One of my coworkers suggested this approach and it has been awesome.
I recently started a new job at a media/tech start-up called Sharethrough. It’s been great so far – I really like the people and the work. Before that I worked for about a year doing consulting and really missed working on a product as part of a permanent team, so the switch back has been awesome. I don’t regret trying out consulting but I can tell after 2 months out of it that my heart is really in creating a product that me and my team have ownership over.
"Formal Friday"
Some things that I’ve found interesting along the way:
1. The Incredible “Start-up”-iness of Sharethrough
Sure, I’ve worked at small companies before, but this one feels different. We’ve got a ping-pong table, a beer fridge, investors, a board, a young CEO, a rapidly-growing staff, a liberal “dogs at work” policy… all the trappings of your typical modern start-up. It’s cool, and makes for a very pleasant environment. Sometimes it’s weird that my office is cooler than my house, but I’m getting used to it.
2. Pair Programming
Our engineering team works in pairs pretty much all of the time, which is fairly new to me. And when I say “works in pairs”, I mean literally working on the same task on the same computer with the same person for 8 hours or so. It’s intense and it takes some getting used to, but I now prefer it to working alone (or “soloing”).
3. The move from .NET to Rails
For the past bunch of years I’ve been working almost exclusively with the .NET platform. I really liked it (and still do) but I wanted to branch out and try working professionally in a different language. I noticed that all the companies I found interesting were using Rails, as well as a lot of my friends, so I decided that my next position would be at a company using it.
It’s been a real trip – it feels very close to learning a foreign language. I’m working hard to get up to speed but I still have a ways to go. Overall Ruby is a pleasure to work with, and I like that the community is young and vibrant.
As with every other tech company in the Bay Area right now, we’re hiring. Life’s too short not to love what you do, so check out our website, find a job that interests you, and join us.
I’ve come to what may seem like a strange realization: I really love being a software engineer. It dawned on me sometime in 2007 when I was working at my first job in San Francisco at a small software company called Lenos. I remember being pretty surprised by the fact of how much I enjoyed going to work. It seemed slightly unnatural – almost like I was getting away with something or cheating my job by actually enjoying it. It was a very different experience than what I was used to.
It’s funny – now that I’ve had a few years to get used to it and think about it, I take it as a given that work can be fun and fulfilling. It still shocks me how many people view their job as something to put up with, get through, tolerate, etc, rather than something that can be creative and wonderful.
Now that software geeks are getting mad paid and occasionally even respect, there’s a bunch of attention being paid to the job that wasn’t there before. It’s topped a lot of “Best Jobs 2011″ lists, but of course that’s a lot of horseshit: the best job is any one that you actually enjoy. That’s why I was so glad when the 2000 tech bubble burst: it got rid of all the people who were only in software because their parents told them it would be a good career. Their hearts weren’t in it, they wrote shitty code, and I’m glad they’re gone. ; )
I’ve heard of a lot of people who burn out on technical jobs and lose their taste for it – but so far for me it’s still a real pleasure. I feel extremely grateful to be able to be part of such an awesome profession.
I’m still getting up-to-speed using Rails (4 months in and counting) and I’ve found some great resources which have helped me kick-start the process and tackle the steep learning curve of using a totally new development language/environment:
Peter Kinmond 