naildrivin5.com

Website of David Bryant Copeland

☞ An Introvert Goes to Dinner

September 27, 2013

I’m trying out Medium as a place to do non-technical writing, mostly to keep this blog’s topic focused on technology. I won’t cross-post everything here, but this is my first one, An Introvert Goes to Dinner. Excerpt:

I actually enjoy solo trips like this. It’s a chance to be as alone as possible: I’m in a city were I don’t know anyone, typically with a lot of free time outside of whatever reason brings me to said city. I know I won’t have to talk to anyone.

Chromebook Keyboard Slightly Innovative

September 06, 2013

Brief follow up to my A real keyboard for programmers post, I got a Chromebook yesterday and the keyboard, while sporting the same layout as most other computers, actually is better designed for what the Chromebook does.

Namely, it has no function keys, instead using them for browser navigation, window management, and hardware controls. Most amazingly, though, it has no Caps Lock, instead making it a Search key, which makes sense. It’s a big key in a very prominent spot and Search is what Google wants you to do.

image

A real keyboard for programmers?

August 29, 2013

Jeff Atwood (AKA codinghorror), introduced a new computer keyboard, produced by WASD, called the CODE keyboard:

I told him that the state of keyboards was unacceptable to me as a geek, and I proposed a partnership wherein I was willing to work with him to do whatever it takes to produce a truly great mechanical keyboard.

Jeff is heralding this as a “truly great mechanical keyboard”. I was very eager to see what such a beast looked like. Here it is:

image

Oh wait, sorry, that’s the original 101-key version of the IBM PC Keyboard, introduced in 1985. How’d that get there? It’s been almost thirty years, so the CODE keyboard must be awesome, right?

Inconsistent Architecture

August 21, 2013

Quick, which is better: MiniTest or RSpec? HAML or ERB? SASS or LESS?

If you are building your first Rails app at your company, it doesn’t matter. They all work more or less the same, so just pick one and go. Take a vote or declare by fiat, but get on with your life. No project ever failed because they picked HAML over ERB.

If, on the other hand, you are building a new Rails application that runs in an existing technical infrastructure (which is far more likely), then these are the absolute wrong questions to be asking. Use what your team already uses unless there’s a good technical reason not to. Why?

Because consistency is far more important than most other factors.

Responsible Refactoring

August 08, 2013

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.

Manual vs Automatic Continuous Deployment

August 07, 2013

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.

☞ Stitch Fix Git Workflow

July 30, 2013

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/production always 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.

Agile Email Management

July 23, 2013

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

The Senior Software Engineer - My New Book

July 15, 2013

Last November, I did my own private PragProWriMo, writing every day that month to produce a non-fiction technology book:

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.