Code, Picasso, and Simplicity

I coded all day yesterday, focusing on a new feature for Hirelite: Speed Dating for Software Jobs. I implemented ~300 lines, added tons of functionality, and was feeling crazy productive. After this surge of productivity, though, the familiar pangs of technical debt anxiety came. I prescribed a hearty dose of refactoring.

I looked for commonalities to refactor among the eight paths of the feature. In particular, two paths stuck out as having more in common with the rest of the feature than the other six. Coincidentally, these two paths were far more commonly used than the others. Additionally, these two paths could effectively cover the scenarios implied by the other six.

Interestingly, these commonalities emerged through implementation. As I implemented the eight paths, the data structures backing each path generally fell in to two buckets. Each of the two more commonly used paths took advantage of different data structures, allowing the less common paths to be covered by one or a combination of the two.

These things weren't obvious from the user experience or product perspective. It took a deep, code-level understanding of the details of the problem and multiple potential solutions to surface this insight.

By the time I actually finished the feature, it was down to 50 lines. Though the simplified solution now seems obvious, I'm sure I would not have found this shortcut without working through the initial cases and writing the 300 lines. 

It always astounds me how much work it takes to understand something well enough to truly simplify it. Sometimes I feel bad, like I've wasted a bunch of time building something that should have been easy from the start. Or maybe I shouldn't have done it at all - I should have hired a rockstarguru who doesn't need to write rough drafts of anything, ever. And then I remember those people don't actually exist.

The same seems to be true for art. Picasso said:

... pictures went forward toward completion by stages. Every day brought something new. A picture used to be a sum of additions. In my case a picture is a sum of destructions. I do a picture - then I destroy it. In the end, though, nothing is lost: the red I took away from one place turns up somewhere else.

Picasso simplified masterfully. In 45 days, he drew 11 bulls, eventually boiling a bull down to just 9 lines.

Pablo Picasso - The Bull. Dec. 5th 1945 - Jan. 17, 1946. Image source and further reading: Pablo Picasso - Bull: a master class on abstract art

Despite all this, I still have this gut feeling that I should have known.

  • Do you run in to situations like this?
  • Any tips on how to shortcut early iterations that take so much time?
  • Is this the type of thing that more experience helps you get around or is it purely a creative process?

After we launch the feature, I'll try to follow up with a deeper dive in to the specifics of the implementation.

12 responses
Man this is so true. Id love to find one myself id turn all my work over to him

"It always astounds me how much work it takes to understand something well enough to truly simplify it. Sometimes I feel bad, like I've wasted a bunch of time building something that should have been easy from the start. Or maybe I shouldn't have done it at all - I should have hired a rockstarguru who doesn't need to write rough drafts of anything, ever. And then I remember those people don't actually exist.

Your post is spot on! And I love the Picasso bull-analogy. It is very apt here.

Your gut feeling is wrong, however (imho).

The only shortcut is experience, which brings us to a paradox, because experience takes time. Picasso's 9 lines are not simply 9 lines. They are the sum of all the previous bulls, his total previous painting and sketching experience, and in fact, if you really want to be holistic about it, the sum of everything that has ever been before.

So, the first time you solve a problem, you'll do it in a few hard ways, after which you can simplify it. The joy comes from knowing that, when in future you get a similar problem, you'll know (at least partly) how to solve it simply. And it never stops - every time you do it, it becomes simpler.

For this reason, I often don't just re-use my own code. I try and quote a bit on top for the fact that I've written it before, and use the time I gain in that way to refactor it a bit, making it a bit better.

Interesting... I stopped reading after your mention of "Hirelite". The hiring process is turning into a 3 ring circus.
@phpguy - definitely. at the bare minimum he'd have to be a ninjarockstar though

@adriaan_pelzer - love your point about experience. Thanks for sharing!

@richard bucker - sorry to turn you off enough to leave a comment about it. There are certainly a lot of hiring sites popping up these days. we're focused on making hiring more personal, reducing the number of recruitment agencies involved, and advocating for job seekers.

pictures went forward toward completion by stages. Every day brought something new. A picture used to be a sum of additions. In my case a picture is a sum of destruction....
I like how you contrast Picasso's attitude to our normal programmer's attitude:

We feel guilty when we spend time improving a program and achieve a clearer understanding that is difficult to appreciate by an outsider. We try to get away from this 'refactoring'; ask for tips how to cut short this time --- and happily forget exactly what we did to achieve at this shorter solution.

Picasso appreciated the quality difference between his first attempt and the final picture --- and knew that it was worthwhile to spend a month and a half to achieve it. He knew that a thrown away sketch is not a loss of time or paper --- but again of insight and experience; making him a greater artist. He paid enough attention to understand what was the new insight of that sketch --- to become a part of all his future work and what should be improved in the following sketches.

With this positive attitude to trial and improvement he became a master at it.

@Yaakov - Awesome point. I wish I knew more about what his goals or external pressures were while painting. His focus on overall quality is amazing, but I often wonder how it relates to development where you have so many different competing concerns. Ex: performance, mantainability, time to develop, features included, etc. I feel like there are probably similar concerns with this painting and art in general that I'd love to understand better.
great blog

keep up the good work

4 visitors upvoted this post.