Hi, I'm Josh Symonds

I blog about Ruby on Rails, coding, and servers

Your Job Is to Code

Reading time 2 minutes

I don’t usually call out articles on Hacker News for being exceptionally silly — if I did I wouldn’t have the time to write about anything else — but I saw one in particular tonight that bugged me, titled Your Job Is Not To Code. It was filled with the sort of engineering platitudes that one can reliably expect from HN: you must be an engineering ambassador to your company from the strange and incomprehensible Codingverse. It’s up to you to interpret and reinterpret the requirements of your project, hopefully better than its stakeholders, and tell them what they’re doing wrong. Your technical skills must be married to the sort of interpersonal skills that would make ambassadors and diplomats blush.

This is all bunk.

If you’re an engineer, then your job is to code. Your job is to be good at it. No, more than that: your job is to be great at it. Anything less is a disservice to the people who’ve hired you and a disservice to yourself. You should work constantly to succeed at your job. Working towards anything else is a distraction.

Shell Awesomeness With Prezto

Reading time 5 minutes

As developers, we spend a lot of time in our shells: making them fast and responsive improves our productivity. I play around with a lot of development tools (as I mentioned in a previous post) trying to find the best combination of intelligence, responsiveness, and fun. Recently I was investigating alternatives to oh-my-zsh, which is a wonderful set of Zsh packages but suffers from weird slowdowns and, unfortunately, requires a lot of configuration. I stumbled upon prezto and I love it — originally an optimized fork of oh-my-zsh, it’s now its own project, and it is fast, beautiful, and leverages the full power of Zsh. It looks like this:


You should get it. And when you do, use these configuration settings to make your experience even better.

Getting Started With AWS OpsWorks

Reading time 6 minutes

I’ve been creating a complicated OpsWorks server setup for a client, as I mentioned in my last post, and I’ve been really enjoying the process. OpsWorks, while still a beta service, has a lot to recommend itself: it couples the best parts of chef to the power of the impressive AWS APIs. Using OpsWorks, it’s easy to make processes that seem almost magical.

How magical? Well, imagine super-fast command line deploys, seamless cookbook updates, great chatbot and application integration, then marry all those things to AWS autoscaling via elastic load balancing. One use case for my client: TravisCI automatically creating servers, running remote acceptance tests on them, then destroying them afterwards — all while notifying chatrooms of its progress. Now that’s assurance your code will work in production! Really, the sky’s the limit here for awesome integrations.

I’ve learned a lot in the process of implementing this setup. If you’re looking to give OpsWorks a go for your next project, here’s some hints and tips to make get started on the right path.

Creating an AWS OpsWorks Instance Store AMI

Reading time 4 minutes

I’ve been doing a fair amount of work in Amazon’s OpsWorks, in many ways an elegant service. Once you have a set of chef recipes provisioning properly, you’ll want to create an AMI for the layer in question so that you don’t have to wait through a long setup process again. Unfortunately, doing this in OpsWorks can be frustrating since the instructions for making it happen are scattered across four entirely different documents. For my own sanity I made a checklist of all the steps necessary to create an AMI on an instance store EC2 server: this is that checklist for anyone else who might find it useful.

Interviewing Symonds & Son

Reading time 6 minutes

I’ve had a rash of posts recently about Symonds & Son, and I was intending to write a piece more pertinent to Rails or programming rather than the business side of things… but recently I was approached to do an interview about working with my family. In answering the interviewer’s questions, I thought the results were interesting enough to post on my blog — hopefully I’ll also be able to post the interview itself when it’s completed!

Supercharge Your Rails Development Environment

Reading time 7 minutes

I love trying to improve my development environment. Efficiency is important to me: I spend hours and hours a day programming, and even a 1% or 2% productivity boost would provide a massive time savings over the course of a year. Or, as xkcd so pithily put it:

Is It Worth The Time?

Of course, I’ve probably obliterated any potential savings by spending so much time experimenting, but now that I’ve done it you don’t have to! Listed here is everything important to me to get my development environment zipping along. Hopefully you’ll be able to find something useful here too that makes your programming experiences a little bit faster.

Programming the New Family Business

Reading time 7 minutes

In my previous post, I told the story of how I accidentally fell into consulting and turned it into a successful business. But what does a successful consulting business — specifically, my successful consulting business — actually look like?

Symonds & Son isn’t named to sound cute and hipstery. I’m the son; I’m in business with my father, and I recently hired my mother to be my assistant and bookkeeper. The company’s name is intended to evoke images of traditional, reliable family businesses, where trust, excellence, and a reputation for quality products are their cornerstones. These companies, traditionally centered around carpentry and other hand-made professions, are my models for how to run Symonds & Son. We are, if you’ll forgive me using the phrase, a bespoke development shop, where our great output and superb relationship with our clients are our highest priorities.

But building my profession into a company — and a company with my parents, no less — hasn’t been an easy road. There have been a lot of compromises we’ve had to make to get this ship sailing straight. Here, I’ll speak to how I made this new parent/child relationship work… and how I hope to continue making it work for years to come.

Rails Consulting for Fun and Profit

Reading time 6 minutes

2013 was a great year for me specifically, and my web development shop (Symonds & Son) in general. Though I initially fell into consulting accidentally, I’ve aggressively parlayed it into a successful business — and my only regret has not been doing so sooner! A lot of developers I know are on the fence about striking out on their own. I’m going to lay out how 2013 changed me from a full-time employee to owner of my own business, and in doing so hopefully persuade a few people that the benefits to being in business for yourself far outweigh the risks.

Cryptolalia, for Creating Cicada 3301 Ciphertext Puzzles

Reading time 4 minutes

After reading yet another article on Cicada 3301 on Hacker News a few weeks ago, I was struck by inspiration. If I wanted a whole gaggle of people on the Internet to compete for — well, for some unknown goal — apparently all I needed was ciphertexts of arbitrary complexity and arcane places to hide them. Arcane places I had, but what I didn’t was a good way to generate all the sorts of codes that Cicada 3301 employed.

So I decided to make it.

Don’t Code Defensively

Reading time 4 minutes

As an engineer, we’re responsible for creating things that people care about deeply. Whether you’re programming something as important as a car’s operating system or as silly as an iPhone game, our code touches lives. It’s no wonder, then, that the people who interact with our products feel strongly about them — and possibly about us, as well.

This can sometimes be a good thing. It’s always touching to receive a heartfelt letter of thanks and admiration from a customer. But much more commonly, you’ll hear complaints, demands, and anger.

Under a deluge like that, it’s easy to become disillusioned and bitter. I see it all the time: programmers who hide in their shells at the slightest provocation. They make excuses, shift blame, and refuse to own their actions. I think this attitude is ultimately cowardly — if you’re willing to take credit for the good things you’ve done, you have to “take credit” for the bad stuff too. And cowardice of this sort contributes to making bad code, since your goal is no longer to to solve your organization’s problems, but to shirk responsibility.

That’s what I call coding defensively — an entirely separate subject from defensive programming. Coding defensively mires you in your codebase. It’s hard to go forward because you don’t want more responsibility, and you can’t go back because it would be admitting error. And it’s a self-reinforcing cycle: once you start becoming defensive, it’s difficult to stop.

I was a defensive coder too. I struggled to own the results of my actions: I would refuse to discuss solutions in a sensible, level-headed way. It took me a long time to change my approach, and as part of doing so I wrote a list of maxims summarizing how I wanted to think and act. When I feel myself slipping I go over them to refresh my resolve. I’m publishing them here in the hope that they’ll help someone else as much as they’ve helped me.