Process Oriented vs Product Driven
Note: This article was originally published at Planet PHP
on 19 May 3100.
Advice I like from 101 Things I Learned in Architecture School (Matthew Frederick):
Being Process Oriented, not Product Driven, is the most important and difficult skill for a designer to develop.
Being process oriented means:
- seeking to understand a design problem before chasing after decisions
- not force fitting solutions to old problems onto new problems
- removing yourself from prideful investment in your projects and being slow to fall in love with your ideas
- making design investigations and decisions holistically (that address several aspects of a design problem at once) rather than sequentially (that finalize one aspect of a solution before investigating the next);
- making design decisions conditionally - that is, with the awareness that they may or may not work out as you continue toward a final solution;
- knowing when to change and when to stick with previous decisions
- accepting as normal the anxiety that comes from not knowing what to do;
- working fluidly between concept-scale and detail-scale to see how each informs the other;
- Always asking a€oWhat ifa€¦?a€¯ regardless of how satisfied you are with your solution.
Not a far stretch to make to software engineering. I especially love the a€obe slow to fall in love with your ideasa€¯ line. It's easy to be seduced by how sexy something is and be blind to the fact that it sticks out like a sore thumb. Admit it, you've done it too. Above all, be flexible, consider more than just what you see right now and remember that software is constantly evolving - you should too.
Even if you have no intentions of learning anything more about architecture, 101 Things I Learned in Architecture School is a nice read with lots of good parallels, I highly suggest it.