This is a brief guide about what I am like to work with intended to help with determining if I fit in culturally, for interviewing and talking to references. It complements my resume and note to recruiters.
I get very passionate about what I work on. I usually end up bragging about it, and am always happy to discuss with others (partners, customers, sales, marketing, support etc) about what is going on.
It is an effective strategy to have products and processes that are just good enough. I however prefer the strategy of having the best - best product, best website, best support, best sales, best marketing, best processes etc. I like to participate in the planning process to ensure we head in this direction making best use of the available people, time and money.
I constantly read. The goal is to at least know what I don't know. I am always seeking out what is missing, potential solutions to problems that may occur later, new techiques and approaches, stories that provide new viewpoints, ways to increase productivity, anything posted by (potential) customers. I also look for internal information, code updates, bug updates, support calls, meeting minutes, marketing and sales materials, wiki changes etc.
Ultimately what makes things best is the sum of all the parts compromising it. A tiny defect or poor decision can have unexpectedly large consequences at a large scale. There could be extra documentation burden (both in writing it and expecting customers to read it), testing it or modifying it in later versions. Conversely a small detail can have a large positive effect so I seek those out too.
I strongly believe in visibility - anyone with a web browser should be able to easily see what is going on everywhere, and contribute if appropriate. This significantly speeds up the organization, using people to their best without having to distract people by pushing out endless emails, meetings and similar "friction". An example I really like is the timeline view in Trac which shows updates to code, tickets, the wiki and project management.
I try to ensure full visibility of all my work, typically via wikis. Ideally a simple report via the web browser should show my queue of work to be done. My goal is to get those things done, in priority order. Additionally I seek out other work items ensuring nothing falls between the cracks.
With a technical audience I am direct and to the point, being bottom up and/or top down as appropriate, and communicating best with a whiteboard. With marketing and sales audiences it is all about visible customer benefits, advantages over the competition and simplicity with clarity in written materials.
I detest stupid software. It is stupid asking administrators and users to answer questions that the computer with billions of processor cycles per second and gigabytes of memory should just figure out. It is insane asking the administrator to make detailed choices involving performance and security trade offs - if the developers with full knowledge of every little detail can't make a sensible choice, then why would the customer be able to? Just doing the "right thing" is important to me. Alan Cooper's article on Goal Directed Design is a good example of distinguishing between goals and tasks. Far too much software ignores the user's goals (typically to use the software as little as possible!) for the minutae of endless tasks and settings.
My preferred programming language is Python using C extensions as necessary. It is very
productive, has many useful libraries and is very easy to write tests for and with. I prefer
having tests since it is an early warning system for later code or interactions that break
earlier efforts. I generally find Linux to be the most productive environment due to the
quality of the developer tools and their reliability - for example
valgrind/ltrace/gdb/strace/gcc -Wall pretty much always work. I usually ensure
anything I produce also works under Windows due to the prevalence of those systems, but its
history and numerous back-doors (eg ways of injecting DLLs, starting programs, hooks,
versioning) can produce unexpected results that are time consuming to discover and work
around.
I am reluctant to do drive-by programming such as diving in as a project nears deadlines. This is because my experience has been that developers doing so just make a project even later. Digging into the internals usually requires being very aware of all the interacting pieces and writing straight forward code is often wrong or incomplete, requiring the existing taxed developers to have to go in, find the problems and rewrite a lot of that drive-by code. (I have had to do that cleanup many times!)
I believe it is better to get the existing team more productive working on what they do best, and focussing my efforts on work that is distracting to them, or will be less used - for example the more obscure code paths, error handling, testing, configuration setting and validation, documentation, code reviews etc.