Fog Creek Software
Discussion Board

Thinking outside the box

I'm a junior developer that has had several code walk-throughs with a more senior (and brilliant) staff member over the two years I've spent at this company. Oftentimes, he comes up with an alternate algorithm that is simple, elegant, and, well, better than mine. Does anyone have suggestions on how I can train myself to 'think outside the box' when creating an algorithm? For example, are there specific questions you ask yourself while in the process?

Friday, July 23, 2004

There are many resources (online and books) that discuss algorithms and design patterns.

However, be careful to avoid the trap of "premature optimization", however tempting it may seem.

Friday, July 23, 2004

He's not "thinking outside the box".  It's just that his box is way bigger than yours because he has more experience and skills.

One thing you can do is get some mentoring time with him.  Ask him questions or pick his brain over lunch, go through design sessions with him, sit down with him and do some pair programming.  Whatever it takes.  The idea being to learn to think more like he does and to absorb some of the wisdom he's accumulated over the years.

Should be working
Friday, July 23, 2004

Practice, Practice, Practice!

If I look at code I wrote 2 years ago (or even six months ago), I'm often appalled.  On more than one occasion, I've even stood up and said, "Who wrote method XYZ? It's complete crap."  Only to sheepishly slink away when I found out that the moron who wrote it was an unenlightend me.

Friday, July 23, 2004

A lot of it is attitude. Some people look at a problem, try to think how they've solved a similar problem before, and charge forward (the old, "we've always done it this way").

Tom H
Friday, July 23, 2004

I also tend to find that when working on (personal) project n, project n-2 and earlier suddenly appear to have egregious architecture problems.  I don't have a problem with that though... it just means that I'm still picking things up.  When my projects start to plateau in their level of quality, then I'll start to worry.

Greg Hurlman
Friday, July 23, 2004

Greg, I do the same thing except halfway through personal project n, I look back at the early portions of my code and see egregious architectural problems, so I go back and fix them.  Then, the second half appears to have egregious problems relative to the now corrected first half.  I continue this cycle for years, getting nothing done.  :)

It's only recently that I finally decided to write something first that 'just works' and then modularly replace bits of the code at a time with better, more solid code.

Friday, July 23, 2004

One of the big tricks is to perform your own code reviews. Look at bits of code and try to think of ways to do it better.  You can't usually do it right away, but when a little time is past you can look at the code with fresh eyes and see better ways.

Clay Dowling
Friday, July 23, 2004

+1 to looking at your old code and cringing. My old code suffers from wanting to look 'scientific' with lots of inappropriate abstraction and patterns going on. I guess I wanted it to look like other people's code, without grasping the reasons for their design choices (or stupidly copying their bad ideas).

Friday, July 23, 2004

"Oftentimes, he comes up with an alternate algorithm that is simple, elegant, and, well, better than mine."

He's just a better programmer than you. He acts polite about it, but at night he comes to these boards and rants about the idiots he has to work with...

Senior Staff Member
Friday, July 23, 2004

Phew, it's not just me then.

Mike G
Friday, July 23, 2004

First, I think it's very positive and encouraging that a) the senior developer can suggest alternatives with an attitude that helps (rather than the "what were you thinking?" attitude that is all too common in these situations) and b) that you want to learn from these experiences.

In addition to the previous advice (ignoring the comment about ranting about idiots), I would suggest that you ask the senior developer's advice earlier in the process (rather than when the code is all written) - such as when you are starting to write a new block of code and you have thought about how you will do it or you have written an outline of the code or the first 20% of the code (depending on your individual approach), then explain to the developer the approach you are taking and ask for suggestions for alternatives. Also, when you do a code walk-through (or earlier in the process), ask the senior developer not to completely explain or propose any new algorithms to you, but to ask you some questions and give you a few hints towards finding the new algorithms partially on your own - this will help you to learn more and help you to find new ways of thinking about these issues. Note that this may take a little more time, and not every mentor is comfortable with this less directed approach.

Philip Dickerson
Friday, July 23, 2004

"""He's just a better programmer than you. He acts polite about it, but at night he comes to these boards and rants about the idiots he has to work with..."""

Nonsense.  An idiot wouldn't be able to recognize that his solutions was *better*.  Ergo, the OP is not an idiot, he's a sharp programmer who's looking to improve his skills.

Now to answer the OP's question, by proposing some *specific* strategies for algorithm development:

1) Loop invariants.  This is a concept that helped me learn to write simpler algorithms.  A loop invariant is a condition that should be applicable at the end of each iteration of the loop.  For example, "Each floobnitz in the output list has been thingamajigged".  You then write code to ensure that this condition is trivially met when the loop starts (e.g. by setting up a zero-length output list), and then write the loop to maintain the condition.

Now, that may sound kind of obvious, but I know that I personally kind of floundered around figuring out how to write algorithms for things before I learned that concept about 15 years ago.  And, it *is* obvious, but only for simple algorithms.  In complicated algorithms, you may have half a dozen loop invariants in one loop, and that's where thinking about them explicitly will help you.

2) Test-driven Development.  Learn it, use it.  Specifically, TDD lets you design an algorithm incrementally, starting with trivial special cases like an empty list, then generalizing to other cases.  I've found that when I do TDD, I often end up with even cleaner algorithms than I would have guessed existed.  Get Kent Beck's book, "Test-Driven Development by Example".

3) Unrolling.  If you have a loop invariant like "foo==i*bar" where 'i' is a loop counter, you can simplify this by adding 'bar' to 'foo' on each iteration, after setting an initial value for 'foo' at the beginning of the loop.  Even if you have something like "foo==i*bar-12", you can handle that by taking the constant part and applying it to the initial pre-loop value (e.g. -12).  This is basically like differentiation in calculus.  Anyway, it usually speeds up the execution as well as simplifying the algorithm.

Phillip J. Eby
Friday, July 23, 2004


Depending on what kind of projects you are working on I would suggest that you not worry about how elegant your individual algorithms are.  You should be concerned with an over-all more elegant design.  Only after you have things working and you can profile your application should you worry about how elegant individual blocks of code are.  It is possibl that the changes you make are a waste of time - with respect to the quality of the final product, not your education, obviously.

name withheld out of cowardice
Friday, July 23, 2004


If possible take the senior guy out to lunch or something. Ask him where he thinks you might want to look or what you might want to do to build up your skills in the areas you are concerned about. Ask him about his career and how he got to where he is now, that may help the two of you talk about what things brought him to a higher mastery. If he has two years of experiance at looking at your code he might have some ideas on what you can do.

Friday, July 23, 2004

In general, it is much easier to tweak an existing solution than to create the solution out of whole cloth in the first place.  Thus, your 'smart developer' is finding the 'low-hanging fruit' that can be improved by small local tweaks.  His experience of algorithm development helps, of course.

I second the suggestion about being careful of pre-mature optimization.  Often a relatively simple, brute-force approach toward solving a problem is much more easily maintained than an intricately crafted approach.

And, what you are going through is HOW you gain the experience needed, so next time you'll apply the clever approach the first time.

I also recommend the works of P.J.Plauger.  He has a collection of articles from Software Development that go in to how to develop clever algorithms at a very detailed level.

Friday, July 23, 2004

"He's just a better programmer than you. He acts polite about it, but at night he comes to these boards and rants about the idiots he has to work with..."


Friday, July 23, 2004

Don't bother trying to think outside the box, just get a bigger box.  English comp. teachers stress rewriting as a road to improvement.  So, why be satified with the first barely-working version of some piece of code?  Practice rewriting a function.  Consider it as a puzzle...  try to write the fastest possible version, the smallest, the minimal data, using the fewest "if" statements, etc.  Challenge yourself.

Friday, July 23, 2004

Knuth: The Art of Computer Programming, Volume 1: Fundamental Algorithms Addison Wesley 1972

Kernighan & Plauger:Software Tools - Addison Wesley 1976

Aho, HopCroft & Ullman: The Design and Analysis of Computer Algorithms - Addison Wesley 1974

(Funny, I'd not noticed the publishing congruence before)

These books tackle algorithms from different directions - if pressed I'd recommend Knuth to come to grips with stacks, lists,  queues and impressively efficient data structures; K+J to appreciate how to lay a code foundation and AHC to recognize complexity.

Let's face it, these days a lot of this stuff is wrapped up behind APIs and none of the above address network issues but we are simply trying to develop your commonsense.

Isaac Newton said that if he had seen further, it was because he had stood on the shoulders of those who had preceded him. I think that in order to do so he still had to climb up there for himself like an Aussie Rules football player to take the mark.

So as always, watch and learn, practice, practice, practice, and if you are given the opportunity, teach the young.

Saturday, July 24, 2004

>> He's not "thinking outside the box".  It's just that his box is way bigger than yours because he has more experience and skills.

Excellent points made, but when I was much younger and saw highly experienced people leap tall buildings at a single bound (intellectually speaking) I was never able to train myself to see what they saw in a design. All I could do each time something like this occurred was to understand the shortcut or optimization they suggested.

My point being that what are commonly called "design patterns" are generally learned by dint of working on many different projects across a broad array of technologies. And that "just" takes --- years and years of experience.

There is no way to force this kind of insight.

Bored Bystander
Saturday, July 24, 2004

Isaac Newton said: "If I have seen further it is by standing on the shoulders of giants" in a letter he wrote to a "rival" scientist Robert Hooke. BTW, Hooke was a short man, so even back then hackers wanted to outdo each other, sarcastically speaking.

James Thomas
Saturday, July 24, 2004

Check out information on the web about Edward Debono who has been teaching ways to think outside the box for a long time.

Norm Wain
Tuesday, July 27, 2004

*  Recent Topics

*  Fog Creek Home