Aspirations

There are a few things I’m looking for in my career.

Autonomy

This implies freedom: I need to be able to make decisions about my own work, and be involved in the decision-making process on projects in general. It therefore also implies trust and co-operation, which is hard to get from paranoid managers and organisations. I’m not a control freak, but I am allergic to inbox-driven development. I can come up with creative solutions to problems when I have the freedom to do so.

Growth

I have a persistent thirst for challenge, and get bored soon if I’m not improving myself. This means constantly evaluating the latest techniques and technologies to see if I can save time, money or effort—and sometimes just for the entertainment value. I actively seek opportunities to increase my impact through more significant roles and responsibilities.

Interaction

I believe people are the most important aspect of software development—not only users, who drive the business requirements, but colleagues, who share the codebase and with whom it’s important to have a good working relationship. In open-source software, a strong community is essential, since it is composed of both users and colleagues. Collaborating with stakeholders on a daily basis is how I stay focused and motivated.

Style

My coding style is quite idiosyncratic. I try, when I can, to adopt the idioms of the language I’m programming in, which is a valuable strategy to reduce a project’s ‘bus factor’. However, when solving a difficult problem, that sometimes isn’t an option. The solution to this must be clear documentation and comprehensive tests. I call what I do considerate programming: always keeping the other team members in mind (even if there aren’t any yet).

I am also an outspoken practitioner of the UNIX philosophy. Wherever possible, I write small, modular components, with focused responsibilities, which operate to standard and universal interfaces. This is a battle-tested method of producing quality software which has worked for 30 years; the same principles still apply today, and I attempt to exercise them whenever I sit at a computer terminal.

Process-wise, I adhere to the principles of Agile development in most cases. This means human-centric design, working software at every step, daily interaction with involved parties, and willingness to adapt. I believe that code without tests is essentially broken, as tests are the first port of call for quality assurance. I agree with Abelson & Sussman on the value of semantics in code: Programs must be written for people to read, and only incidentally for machines to execute.

Technologies

I’m usually very quick to adapt to different technologies and paradigms, but these are the ones I’m most comfortable with at the moment:

References

In the interest of my clients’ confidentiality, I ask that you contact me directly for specific information and a list of references.