My Work Philosophy

by Simon. Average Reading Time: about 2 minutes.

Okay, so many of the points below aren’t purely my philosophy, but ideas and principles I have picked up along the way throughout my [development] career. Some relate to the UNIX philosophy, or even the Zen of Python, but wherever they’re from, they can be applied to many other domains.

  • Don’t reinvent the wheel unless you really have to. Borrow code and ideas from elsewhere whenever it makes sense. The web community it great at sharing, just look at the various JavaScript libraries, the huge quantities of APIs or indeed the major players’ developer areas: Google Code, Yahoo! Developer Network, Mozilla Developer Center, Adobe Developer Connection and Dev Opera to name five I regularly refer to.
  • Things should be as simple as possible, but no simpler (Einstein). This idea is really born out of and emphasised by 37Signals’ Getting Real book. Commonly, 90% of people using an application only use 10% of it’s functionality. The key therefore is to find what people use most often and only build that functionality. If there is a requirement to add more, then sobeit. This can also apply to the code-level, the essence here being a balance between over- and under-engineering something.
  • Do one thing well (The UNIX philosophy). It is better to do one thing well, than several second-rate. This could be at the code level — think encapsulation, coupling and cohesion — or indeed at the application level — you’re never going to beat Microsoft Word, but Google and Zoho have developed compelling alternatives, but with far less features.
  • Don’t fret too much about performance — understand how to write efficient code and plan to optimise later if or when needed.
  • Don’t try for perfection because good enough is often just that. This of course is a matter for conjecture. If I were working on a personal project, I may be more stringent on perfection than say, for a client’s application. This doesn’t mean to say the client’s application would be any worse, but rather it is a question of dotting-the-is and crossing-the-ts. It also depends on your perspective and what gains can be made by aiming for perfection.
  • (Hence) it’s okay to cut corners sometimes, only if you can do it right later. I rarely adhere to this! It makes sense to do it right the first time, since bodge-jobs often come back to haunt you and result in double the effort!
  • Don’t fight it; go with the flow. This is somewhat clichéd, but the essence behind this is try to avoid getting stressed out. This isn’t always easy to achieve, but taking a step back from a situation and avoiding politics is important.

I often strive for perfection, which isn’t an entirely clever pursuit since it is almost impossible to achieve. However, in a realm of imperfection, the principles above have helped me to achieve a modicum of decent code throughout the years. They may also resonate and provide inspiration for you.

This article has been tagged

, , , , , , , , , , , , , , , , , ,

Other articles I recommend

Design Principles: The Philosophy of UX

The visual principles of harmony, unity, contrast, emphasis, variety, balance, proportion, pattern and direction (and others) are widely recognised and practiced, even when they aren’t formally articulated. But creating a good design doesn’t automatically mean creating a good experience. In order for us to cultivate positive experiences for our users, we need to establish a set of guiding principles for experience design.

Google's Philosophy – Ten Things

One of Google’s mantras is to never settle for the best. The perfect search engine, says Google co-founder Larry Page, would understand exactly what you mean and give back exactly what you want. Given the state of search technology today, that’s a far-reaching vision requiring research, development and innovation to realize. Google is committed to blazing that trail. Though acknowledged as the world’s leading search technology company, Google’s goal is to provide a much higher level of service to all those who seek information, whether they’re at a desk in Boston, driving through Bonn, or strolling in Bangkok.

The Cathedral and the Bizarre

The Cathedral and the Bazaar is an essay by Eric S. Raymond on software engineering methods, based on his observations of the Linux kernel development process and his experiences managing an open source project, fetchmail. It examines the struggle between top-down and bottom-up design.