Emboldened by tests, and with the words “ruthless refactoring” in my head, I used to “improve” the codebase I was maintaining at a previous job. One day, my “cleanup” caused production to break. How could this be? I was being Agile. I was Testing. I was Merciless in my Refactoring. I had found Code Smells, dammit!
I was being irresponsible.
My ex-colleague from LivingSocial, Dan Mayer posted a great read about continuous deployment, and the tradeoffs when doing an automatic deploy:
After considering some of the real world implications of automated continuous deployment, I didn’t feel it was right for our team on most of our projects at the moment. Both because we would need a bit of additional tooling around deployment and dashboards, and because our tests are far to slow.
It’s a good (and quick) read. Having worked on at least one of the apps that Dan’s talking about, I would agree he’s making the right call and that if your test suite is slow, automatic deployment can be a killer. I also think there’s a relationship between the size of the contributor group and the speed of the test suite - the more devs pushing stuff in, the faster it has to be.
In my book, there’s a chapter on bootstrapping new applications, and my recommendation is to set up automatic continuous deployment from the start. I stand by that, because it basically turns the problem Dan identifies around: slow tests slow your deployment which should thus motivate keeping tests slow (and applications lean). We’ll see how it works out at Stitch Fix. We have one app with a somewhat slow test suite, and three with relatively fast ones. Automatic deploys work really well so far.
The Stitch Fix tech blog is up, and I just posted how we use Git and Hubot to automate deployment, without having a complex series of branches and tags.
This is fairly simple - new code goes on branches, master is always deployable (when clean), and
deploy/productionalways contains whatever’s on production.
My book talks about bootstrapping new applications, and my recommendation is to set up continuous deployment. If you’ve ever worked on a release schedule, you’ll know that continuous deployment is a pure joy. It’s also a boon to the users, who get the features and fixes as fast as possible.
Email is a fact of life. It’s the primary conduit through which all information in our work life flows. Clients email us. Users email us. Project managers email us. Our issue management systems email us. Heck, even our apps email us when things are going wrong.
Managing email can be tricky - if you spend too much time on it, you don’t get any other work done, and if you don’t spend enough time on it, you appear flaky at best and incompetent at worst. Over the past several years, I’ve developed a system for managing email as a developer that maximizes my responsiveness without creating an undue burden on my workload. In short, I’m a lot more agile in how I deliver results by allowing emails to occasionally “overrule” my otherwise prioritized backlog.
I’m going to share it with you to see if you like it
Last November, I did my own private PragProWriMo, writing every day that month to produce a non-fiction technology book:
And that's IT! 671 words today for a total of 46,611 words. Now what? Editing hell I guess :) #digwrimo #PragProWriMo
— ❺➠ David Copeland (@davetron5000) November 30, 2012
Between Dec 1, 2012 and today, I’ve been editing it, and it’s finally complete!
The Senior Software Engineer is a 200-page e-book on everything a developer needs to know to be a truly senior engineer…except for how program.
The book’s subtitle is “A Guide for Making the Most of Your Career” and that’s exactly what it is. I realized over the past few years that the best and most successful developers I’ve come across aren’t just good at writing code. They can communicate effectively with others. They can launch a greenfield project without incident. They can write documentation. They can lead others without becoming managers who have to give up coding.
In short, these developers prioritize the delivery of results above all else. They often (though not always) use software to deliver those results.
This is the subject of the book. It’s designed to get you thinking about the big picture, of which computer programs are only a small part. It’s a roadmap for advancing in your career without giving up writing code.
It’s also prescriptive. You’ll learn how to give a code review as well as receive one. You’ll learn how to keep organized while implementing complex features. You’ll learn how to create a convincing technical argument by understanding others’ priorities. You’ll learn how to interview potential team members, and then lead them to successful product delivery. Check out the website, where you’ll find a full table of contents as well as some excerpts.
The lessons in this book have taken me a long time to learn, and I still struggle every day with many of them. My hope is that if we all start thinking about this stuff earlier in our careers (at least as much as we think about the next great language or framework) we can do better work and make software better.
It’s available now for $25, in PDF, EPUB, MOBI, and Markdown. I hope you enjoy it.
This is important. It has to do with your treatment and reaction to how your software runs in production. How your software runs in production is all that matters. The most amazing abstractions, cleanest code, or beautiful algorithms are meaningless if your code doesn’t run well on production.
If you have no way to understand how your code runs in production, you are more typist than engineer. It’s not necessarily your fault - many organizations don’t allow developers any real access to production - but you need to do something about it, and I’m gonna show you how.
What’s the one thing we, as developers, do with source code more than anything else? We read it. Sure, we change it, and even occasionally we write new source code, but, by and large, we read source code. We read it to know how to use it. We read it to know where to change it. We read it to understand what it does.
But, it’s not just the content - the code itself - that affects readability. How it’s presented matters and if we’re going to talk about presentation, we have to talk about typography.
At Stitch Fix, we outsource pretty much all of our hosting and technical needs to Heroku or their add-ons. Given where we are now as a company, it makes total sense: we don’t need to hire an admin, we don’t need to adminster actual boxes, and we can easily add/remove/change our technical infrastructure. If you are a small startup and you are messing with Linode slices, you are probably wasting time.
One thing Heroku doesn’t provide out of the box is a login system for “internal” users. The vast majority of the software at Stitch Fix is targeted at Stitch Fix employees - to operate the warehouse, choose what goes into a fix, etc. The natural way to allow them to login is via Google Apps. We can use everyone’s existing username/password, and employees can be added during onboarding and removed when they leave the company, all in one place.
Getting it to work with our Rails apps seemed easy enough with OmniAuth, but it turned out to be a lot trickier, resulting in random failures with the oh-so-helpful error “invalid_credentials”. Here’s how to fix that, and why you can’t just use the out-of-box configurations recommend by OmniAuth.
From time to time, I see people in my twitter stream attempting to switch to Vim. This is a good thing. The problem is that they appear to be viewing the switch as swapping out one tool for another.
This is not what switching to Vim means, nor is it a good reason to switch.
The reason to switch to Vim is to work better. I realize “better” is subjective, but whatever way you define it is what it means - code faster, edit text more easily, automate your workflow, whatever.
As such, switching to Vim is to throw out your old editor (or plan to) and replace it with a different tool that works differently and is, hopefully, better. Stop asking for “a plugin that does XXX like Sublime Text does things”. If Sublime Text has a plugin for what you want, you don’t need Vim. Vim might very well have a plugin that does whatever XXX is, but it’s more likely that you don’t need a plugin, or that Vim provides a way to accomplish your real goal much more efficiently.
Here’s how to make the move.
One of the main reasons I like working test-first is because I’m lazy. I don’t want to fire up a browser, log in as the right person, navigate to just the right piece of data (which I had to set up manually in the database), and click around to see if things are working.
Don’t get me wrong, I do do that, but only when the code is working according to my tests. Or, when I have to write JavaScript.
At my current job, I’m doing a lot more front-end than I had been, and so more JavaScript. The app I’m working on is a Rails app, and so I looked into the current state of the art with testing JavaScript.
In can be done, and it’s painful.