Back in1973 a mathematician named George Polya wrote a book called How to Solve It. Within the book he defined the Inventors Paradox for the first time stating, “The more ambitious plan may have more chances of success”. This is commonly paraphrased as, “Its often easier (paradoxically) to solve a more general problem than a specific one”.

Polya’s book was about solving maths problems. The principle however applies to many things including, as you may expect, software. Years later those involved with Adaptive Programming and subsequently the Aspect-oriented programming movement, sighted the Inventors Paradox as a foundational pattern. Both are techniques primarily concerned with decomposing and the abstraction of programming problems.

Programmers expend a lot of effort decomposing problems. Their success at doing so defines them. How developers think about abstractions is another key differentiator of skill and experience. Cleaver abstraction is an art not a science. It’s one of the places where design and engineering meet.

As a programmer I’m a professional problem solver, practiced at decomposing and thinking in abstractions. Teasing out the essence of the problem is, for me, the fun part of any project. Collaborating on a design within a well gelled team can be very satisfying. Finding and joining such a team is not straightforward however. You need to choose carefully, and that means having choice in the first place. The whole purpose of this dialogue is to explain why I’ve started this blog. In Inventors Paradox parlance my specific problem is consistently landing great jobs. My general problem is communication. With a three page resume, half filled with keyword soup, it’s a challenge to convey my accumulated skills effectively. I hope this blog builds into something that may help.

Job seeking developers traditionally attend an interview, often sitting a programming test. They typically have no portfolio, as a graphic designer might have. Solving a coding puzzle does require intelligence and language knowledge, but some skills like design are difficult to measure. Looking through a graphic designers portfolio is a view on thinking, style and execution. Would sitting a Photoshop quiz be as insightful?

I’m not alone believing design is everywhere within development however, in my experience, developers’ are rarely judged by their design skills during the recruitment process.

The recent launch of Geoff Atwood’s StackOverflow Careers could be the start of a new direction, I hope so.

I don’t know what form a developers portfolio might take. I’m exploring a few ideas and a blog is obviously a popular choice. Writing is a different skill set and despite a new copy of Strunk and White failure is very possible.