I got my start building home-entertainment systems in the early 1970’s.
I then moved on to designing electronics and software—and sometimes both together—in the 1980’s.
Fast forward to 2006, when I quit my last cubicle job, and since then have contracted for a number of companies here in the Boston area, in California, and in between.
…MySQL, HTML, CSS, C++, PHP (though I don’t brag about that), and maybe even a little Java. My LinkedIn profile adds embedded systems, Apache, Agile methodologies, open-source software, and Scrum. All that is fairly boring, because these are all tech skills, and tech skills are relatively easy to acquire. Philosophy and values are more difficult.
I believe in designing systems that are easy to use, easy to understand, and easy to extend. I love software that does what you want, when you want it, without fighting you every step of the way, and I’m willing to invest a little extra effort up front in order to benefit from that good design on the back end.
That said, I prefer to take the easy way out. Much of the time, a software feature can be added without resorting to heavy-duty programming. “Do the Simplest Thing that Can Possibly Work”: get something out there, and then refactor it later, if you need to.
But I’ve had a love-hate relationship with software, eventually plunging me into a deeply dark place. For several years, I took a break from software, contracting on the odd Perl project, just for the money. I wrote and published several books, applying my technical skills to the entire process from conception to final distribution. This gave me a much needed respite, time to think about what I really love about programming. Eventually, I discovered how programming can even be a spiritual journey.
And that’s why I’m back.
Back building software. Serious software.
But not just for the money.
And not just for anyone.
In particular, I tend to automate repetitive tasks, including testing. (So if you’re going to complain about all the extra work it takes to write all those unit tests, I’m probably not your man.) I also have an aversion to dysfunctional design, and tend be overly frank regarding project scope and risks. But I’ve done wonders with legacy code by always leaving it in a better condition than I found it, as well as with new code by providing a well-structured environment in which it can grow.