Code & People

This is a portfolio piece to explain a bit about me as a developer, where I’m coming from. It’s part self-promotion, part food for thought. For more about specific projects I’ve done, start with my Portfolio Intro post.

Let me get philosophical for a moment here. To me, software is a tool for solving human problems. Don’t get me wrong; I care about the craft of what I do. I’m passionate about well-designed, cleanly-written code; but it’s a means to an end. I’ve worked with plenty of programmers who would be happier if nobody actually used their code. That’s not me. I need to feel that at the end of the day that I’m doing something useful, that someone cares about my work. And I think this attitude has a big impact on how I do my job.

I like people. I like working with clients to translate their needs into a design. I like learning about how their world works, and what matters to them. I like the emphasis on collaboration that you find in agile methodologies. It’s critical because that translation—from needs to design to implementation—is tricky. There are details and subtleties that really matter. Until the users have a chance to work with the software, it’s hard for them to tell whether it actually meets their needs or not. The quicker you can put something in front of them and get feedback on it, the better.

I also like working in teams of developers, sharing ideas and hammering out problems together. You get more good ideas if there’s more than one of you doing the brainstorming. I like pair programming and code reviews. I can move a lot faster if I’ve got someone to sanity-check my work; I’ll have more confidence in it. Even having someone junior go through it and ask a bunch of dumb questions is helpful. It at least forces me to be clear about my thinking, and it often turns up something that could be improved. It’s tough on my ego sometimes, but it makes the code better.

Writing high-quality code isn’t a matter of abstract elegance or pedantic fussiness. It’s important because people will have to maintain it. While it has to function—it has to do what the users want—that’s not the end of it. Code is about capturing knowledge and expressing it in a clear and concise manner. It’s not just a set of instructions for the computer; it embodies an understanding of how this little part of the world works. It’s like any other writing: The more thought you put into it, the easier it will be to understand. In practical terms, that makes it easier to maintain and extend. The time-consuming part of that sort of work is understanding the code, figuring out what you need to change or where to hook in new features. The easier that is, the longer you can keep it running, and the more new features you can add. That creates more lasting value for the people using it.

I’ve worked with a bunch of different languages and tools over the years, and I have my preferences. There are some that I like, and some that I have no intention of going near again. There are others that I’ve tinkered with on my own that I wish I had the chance to try out professionally. But they’re tools, and I don’t believe in using the wrong tool for the job. I’ve seen too much software with technology-driven features; which used frameworks that the programmers thought were cool, but didn’t actually add any value for the customer. That makes me cranky. People come first; you don’t start with the solution and try to map it onto their problem.

Lastly, and perhaps most unusually, I like working with the non-technical (or less-technical) people at my company: Finance, sales, training, tech support, etc. It’s fascinating in its own right, because they look at the world in a very different way. I’ve also found it useful because it broadens the way I think about solving problems. There have been times when technical problems can be avoided with better training, or tech support issues avoided with a small change to the code. Having that communications channel can open a lot of possibilities.

Ultimately, software is all about people, in both its design and construction. If you look at my portfolio stories, those successes came from understanding people and working with them effectively. The technology is just the medium I work in, how I make stuff happen. The hard part, and the interesting part, is figuring out what needs doing.