I’ve decided to return to blogging in 2015 with something I wrote in May 2012. This was written for a publication of one of my former colleagues, “Light Bulb Bites”.

Light Bulb (or “Globe”, as we say in Australia) Bites call on us to be more creative and more innovative. Oft-times, a developer’s first instinct when faced with a technical problem is to reach for an editor and start putting a script together to automate a solution. Jerome demonstrated this with Days!

In his ‘EWD’, “On the cruelty of really teaching computing science”, Edsger Dijkstra wrote:

[…] if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

This is a real challenge: is my first instinct counter-productive?

In his 2012 Q1 post-earnings address to the firm our President and CEO highlighted that each of us has to be more productive and that we’ll all be measured on this productivity.

Are calls for us to innovate and create in opposition with the mandate from the top to be productive? Thankfully not. In Jeff Atwood’s recent blog post “Please Don’t Learn to Code” he reminds us:

Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.

When we write code, particularly code for an already-solved problem, we are not really contributing a solution but adding to the problem! Now we have more code that needs to be tested and maintained. Furthermore it must be understood by the next developer who has to solve an adjacent problem.

By creatively reusing an existing solution, not only are we not adding to our colossal codebase, we’re actually saving our company time and effort in testing and maintaining it for years to come. That is real productivity!

We need to look around us and identify the obstacles that stand between us productivity. And not just in development or QA: talk to a member of the trading team or technical support and find out what really slows them down: solve that problem and award yourself an extra pat on the back if you didn’t write a single line of code to do it.

Solutions are more valuable the more people that they help. If you’ve come up with an innovative solution to a problem you or a colleague faced please share it. In a global company if one person faces a problem it’s highly likely that their counterpart in another office is facing the same problem and would welcome your solution. This value is multiplied when you consider that your counterpart in the other office may be working a solution when they could be working on something else.

You can be part of the problem, or part of the solution.

Phil Dunphy and I happen to believe you can be both. The trick is in being just the latter.