Posts tagged: SOFTWARE ENGINEERING

(I recently posted this on Quora in response to a question along the lines of “Engineers, when did you decide to study Computer Science?”)

I have been a full-time software engineer for the last 7 years, and a part-time one for ten years before that.

I have never formally studied computer science.

It wasn’t an option before college (small high school in rural Vermont). And at the otherwise excellent small liberal arts college I attended, it wasn’t one of the available majors.

(Note: This is a writeup I did a few years ago when evaluating Riak KV as a possible data store for a high-traffic CMS. At the time, the product was called simply “Riak”. Naturally, other details may be out of date as well.)

Riak is a distributed, key/value store written in Erlang. It is open source but supported by a commercial company, Basho.

Its design is based on an Amazon creation called Dynamo, which is described in a 200-page paper published by Amazon. The engineers at Basho used this paper to guide the design of Riak.

Non-engineers want to know: what happens when a big bug is found in your software, and the bug is causing real users real problems, and you’re the one who wrote the code?

Engineers do sometimes write bad code, and sometimes it makes it into production, it’s true.

But shipping production software involves a lot more than writing code. It goes beyond that one engineer. That engineer is not the only person who saw or ran that code.

When we were growing our team of Python devs at CMG, I was involved in a lot of interviews. I really enjoyed it, meeting and hiring interesting and talented engineers.

I’m not a big fan of quizzing people on technical minutiae in interviews. I do think that asking some questions about technical likes and dislikes can be very illuminating though.

For example, “What’s your favorite standard library module?” (My favorite answers are itertools or functools, but anything that shows they have hands-on appreciation for the depth of the standard library is good.)

I’ve been working as a remote software developer for over five years now. I gather that some outfits do this better than others. In case they’re useful/inspirational for anyone else, I want to highlight the key things that have made this workable for so long. The key idea: Treat your remote workers as first-class, full-fledged members of the team.

• Have a chat server which everyone is connected to whenever they are working. IRC, Slack, whatever. Logging into this server is effectively showing up at work. If your group is big, give each small team its own channel, but have a common one too. Make it OK to have random chitchat there, just like people do in the break room or hallway.
• Ask of every meeting or group event: How do remote workers participate? Encourage this mindset in all managers and anybody who arranges meetings of any sort. Stream video for presentations. Solicit questions from remotes.
• Don’t keep critical information on a tackboard, whiteboard, fridge, or other physical thing that only in-office employees can see (and change).
• If you do something fun for in-office employees, match it for the remotes. (My employer took on-site employees to see the new Star Wars when it came out; they sent $50 Fandango cards to us remotes.)
• If you can afford it, fly everybody to work together at the same location for one week a year. (If your main office is suitable, great. If not, rent, or take everybody to Hawaii or something.) My employer has done this and I consider it a crucial part of my long-term enjoyment of the job. I know the people I work with not just as nicks and avatars and work product, but as people I’ve hung out with (and worked next to) also.

This evening, the Western Mass. Developers Group was treated to a talk by Ben Fry of Processing fame. It was excellent and inspiring. Having not much prior exposure to Processing or his work, I left hungry for more. (The title of this post is taken from the name of the group at the MIT Media Lab where Fry did his PhD work.)

I liked the graphical-REPL flavor of his live demos. Surprisingly, the feeling reminded me of being a kid flipping through Alan Kay’s article about the Xerox Alto in Scientific American 30 years ago.

I just came across this list in an old “should blog about this someday” file. It’s from a 1983 interview of legendary racing motorcycle tuner Rob Muzzy, speaking to legendary motorcycle journalist Kevin Cameron. It’s about how to be smart about going fast.

I don’t do a lot of work that’s extremely performance-critical, but most of what Muzzy says rings true for me when applied to software systems. The engineering mindset looks remarkably similar across disciplines.