I find I solve the trickiest problems in one of three places: Walking my dog, taking a shower, and laying in bed trying to fall asleep. I find that stepping away from the keyboard, and my programming environment entirely, allows me to let go of all the basic assumptions I hadn't even realized I'd been making.
At one of my old jobs, some of the other employees jokingly referred to me as "the master of the arcane."
Any time they had a problem they couldn't figure out, they'd come to me and ask me to help with it.
My trick was to listen to their problem and then go take a walk. Our office was in a nice area with plenty of sidewalks. So, I'd get the details of the problem and then go take a walk for about a half hour while I thought about the issue.
After the walk I was able to sit down and my computer and implement whatever weird thing it was.
These days I do work from home (freelance) so I find myself pacing around my house while trying to figure out something odd. I think I've worn a groove in the grass at this point.
This is often repeated by a lot of people, but I think it might be affected by a bias. Perhaps we notice more when we solve problems away from the keyboard because we are not supposed to be working then. Perhaps we selectively label those the trickiest even though we solve many more problems staring at the monitor trying really hard.
There is certainly some confirmation bias going on in these reports, but I must say I sometimes find walking away from the problem for a short while (looking at something else, taking a relaxed lunch instead of eating at desk, just nipping out for a few minutes of fresh air, or just chatting to a colleague about something related or otherwise) can work wonders.
Sometimes a relevant idea will just come to me while I'm away (I carry a pencil and bit of paper for such occurrences, as it is very annoying to get back to my desk and forget the beneficial train of thought!), sometimes I'll hit the problem from a slightly different angle when I get back and find success that way.
I think mainly the difference is usually stress. Forcing your mind to think about a particular problem can drive you into a mental rut in which you think the same things over and over and get nowhere, getting more irritated at your lack of getting anywhere as time goes on which creates more stress and makes matters worse. At times like that inspiration is less likely to strike (or be recognised when it does). Having time to ponder a problem, consciously or otherwise, can be very fruitful.
This fits in quite nicely with the idea that the sleep pattern we've evolved is as much about rearranging what we've learnt and experienced while awake as it is about anything else (like the brain's DBA taking time to run DBCC REINDEX on everything so our thinking is more efficient the next day). It also tallies with the fact that some of the most successful people I know are generally more relaxed (and not just because they are more comfortable due to earlier success) than myself!
This. Circa 2002, I debugged a mutli-threaded Java server, by taking a hard copy of source and walking through it on paper.
A developer sitting in another office had written it; I was roped in at the moment the nasty bug was discovered, basically to have a look from a fresh set of eyes. It had to be shipped in a couple of days time.
The neat thing about writing code on paper is the amazing gain in clarity. Of course, like all approaches, it has to be taken with a grain of salt.
It seems to me that the necessity of scrolling on a Laptop screen somehow creates additional cognitive overhead, especially when we want to rapidly jump across sections of code. Perhaps, it forces us being physically away from the machine to reflect more deeply on the problem.
Same here... Just a week ago, I spent the whole night looking at code trying to find out how some mysterious data loss had occurred. Needless to say, I had been to bed half an hour before it hit me what had happened. I instantly got up and fetched my laptop to confirm that was indeed the case.
I think you are right, about letting go of all assumptions, and that helps you find the edge cases.
I'm the same way, and I know a lot of people like this. Many times I've been working on a project with friends and we'll get stuck on something and we'll joke that someone is going to have to go take a shower, so we can get past the hurdle.
Also, I may have, on one or two occasions, written code on the tile walls with tub crayons.... after all, you get a brilliant idea, you don't want to lose it in the time it takes to dry of.
I'd say that in addition to letting go of assumptions, it's just as much about breaking patterns.
I often find that once I start trying to fix a problem, my brain gets stuck in that way of fixing it and if that doesn't work, it then becomes a matter of fixing the fix, etc. It all just kind of builds up. If I'm standing in the shower with hot water pouring over my head, I can free my mind of whatever I was concentrating on and then new ideas emerge.
I agree and yes I do sometimes bill my shower time. That's where the best work gets done after all
But I think it's much deeper than that. It's the basic truth that creativity emerges from a still mind. First you spend hours obsessing in front of the screen seemingly achieving nothing. Later you seemingly do nothing and solve the hardest problems.
It's an excellent practice to take breaks where you do nothing. Pretend to be a smoker and step out for a smoking break every hour or so.
One of the best lessons I learnt from my first boss was: “when your code doesn’t behave as expected, don’t use the debugger, think.”
Can't entirely agree. I'm not a grizzled programmer, so sometimes when I'm coding for microcontrollers the debugger winds up teaching me about some new quirk in architecture. It's often something I was aware of (endianness, some of the finer details of addressing) but had not yet actually dealt with in person.
A poor developer uses his tools to cover up the symptoms. A good developer fixes the root cause. The ability of the good developer to fix the root cause quickly and efficiently is bounded by the quality of their tools. If you want to claim that a good developer will find it no matter what, fine, but don't tell me the developer with better tools won't be able to do it faster; it's almost the definition of "better tool". I find it very strange how people just write off using a debugger, ever, for any purpose, and think it labels them as a better developer, as if a carpenter who refuses to use a plane under any circumstances is thus a better carpenter for resisting the temptation to easily-smoothed wood. (The fact that a plane is good for more than that is deliberately part of my point.) It isn't the best solution for every problem and I certainly don't reach for it directly, but when you need it, you need it.
The root cause of every problem is that I don't fully understand my code. A debugger can only show you what the code happens to do in one particular scenario. The fear is that people are doing that and fixing only obvious mistakes as a substitute for static analysis and diligent review of the code leading to a correct model in their head of how it would handle any scenario. It's like declaring a bridge to be sound because you could successfully send one truck across.
"Doctor, it hurts when I do this." "Don't do that."
That fact that other people can misuse a tool is a really stupid reason to not use it yourself. I've had great success in using debuggers to identify which assumption I was wrong about when the code did something unexpected. If you're so awesome that you never make bad assumptions about your code... you're probably not pushing yourself hard enough. Perhaps that's your job's fault. I'm pushing myself to my limits in my job, and I'll take all the help I can get.
The problem isn't using a debugger, it's being overconfident in how much you can infer from any given debugging run. The solution is to have realistic levels of confidence, not to swear off the use of debuggers. Obviously, if you're trying to understand how the code works, having one empirical sample is better than having zero empirical samples.
If said developer can match his peers without using a debugger, then he'd do even better with a debugger. A tool is just that, it can only assist you in performing a task.
I don't agree 100% but I think debuggers are for code that you didn't write yourself and has insufficient documentation.
When it comes to a dynamic language, knowing how and what lead to a particular function being called is important and all that information isn't exactly saved on the stack trace---you have to step through to find it.
The debugger vs no debugger "problem" has been discussed through and through countless times with little result. I don't think we'll reach new insight this time. People just work differently.
I agree. There's times where you need a debugger and there's times where you don't. Learning to recognize those situations are valuable, in my opinion.
Sometimes good old pen and paper is the best solution when you find yourself getting into a bind. Other times, stepping through the code and watching what happens to the data/memory is the way to go.
It depends on the type of bug, sometimes its just simple quirks or something you've done incorrectly like the wrong pointer arthimetic or trying to write to a null pointer or something along those lines.
However, a lot of the biggest headaches are conceptual and in which case taking a break from the computer almost always helps I find.
This is good mostly for algorithms but for system software (drivers, a lot of different technologies involved) is impossible because issues are outside of your control, without debugging you'll lose 100x of time.
In many ways the responsiveness of the machine can work against you. Back when the Amiga was a hot machine to work on there were two compilers Lattice C and Manx C, Lattice was the one sanctioned for development and it took a long time to compile and link, Manx on the other hand compiled really really fast. A number of developers discovered that the fast compiler had a weird effect of making it easy to try lots of things quickly, rather than contemplating what you needed to do next.
Then recently Randal Munroe published an XKCD cartoon on attention deficit management [1] which when I saw it, it really resonated with this same experience. Basically by slowing things down, quality improved. Clearly there is a fundamental principle here somewhere, something along that lines that there is an ideal pace for development (perhaps unique to each individual) where going faster or slower than that ideal negatively impacts quality.
I find that fast compile turnaround helps me stay engaged with the problem. Even a 30 second delay gives me time to get distracted by one of the temptations that surround us all. The ironic result is that I sometimes actually think less about what I'm doing when I have to tolerate these delays. Ideally, when I catch myself doing this, I make myself stop and think, but sometimes I'm tired and lack the patience.
On the other hand, in a fast-turnaround environment like Lisp, I can make three stupid mistakes in about a minute, and when I realize I'm thrashing, I still have all the context in my head to figure out what I should really do.
There's a rich history of research into the nature and methods of problem solving (Polya et. al), the role of unconscious (e.g. walk away from the lab/tools) and so on. The more intractable the problem, the more it required being able to walk away from the tools (see anecdotal history about discovery of the structure of benzene for example).
The experience of "coding", with its quick feedback loop hypnotizes people into an unproductive leash. The nature of the problem, the language and tools either help or exacerbate.
My experience is that most hard problem solving needs at least three approaches - I paraphrase them as 1. Zoom Out, 2. Zoom In 3. Zoom away. Debuggers aside, I found that program construction in interpreted languages (my work was in Lisp) supported with a good toolset and modularity in design, allowed productive zoom-in, zoom-out whereas programming in "edit/compile/debug" languages even with the toolset and modularity required "zooming away" more often. Could be that the context switching cycle of edit/compile/debug is a cognitive tax that really hampers hard problem solving or when things are not working as expected.
Marvin Minsky said in his influential paper Steps Toward Artificial Intelligence that "everyone should know the work of George Pólya on how to solve problems." - Wikipedia
Hardly news for anyone who's been a developer for a long time. I generally solve my dev problems wandering around London. This has the added bonus of when I've sorted out the problem in my head, I'm at a location I've never been before and have the chance to find a new restaurant/pub. Win/win.
While you can get the benefit of clarity by stepping away from the keyboard for a while, I've found the best return is from test-driven development. TDD forces you to think about what you're trying to achieve before you try to solve the it. The thing I took exception to in the post was:
> 5. Make small change to the code on the off-chance that it might solve the problem
Whether practising TDD or trying to formalise the problem on paper (or in your head), this is not the way to write code. Programming is not a random search problem.
These days, I tend to only step away from the keyboard when I'm losing my bearings for where I am in the big picture. Usually, that's when I'm "making small changes to the code on the off-chance that it might solve the problem"… this means I don't really know what the problem is.
> 5. Make small change to the code on the off-chance that it might solve the problem
Guess and check, supported by a scaffolding of tests is not the path to being a better or more professional programmer and this is precisely what he's advocating against.
Maybe someone could make paper based IDEs, like notebooks that have columns to trace variables, rows for declarations at the top... Edit: terrible idea, just look for a suitable jotter in the stationary sections.
I have a personal project I've been working on for years, mostly in pen and paper.
Every once in a while I'll get motivated and start coding it up. I'll start to think "I didn't think I could do it that way when planning it on paper, but I can't remember the reason...I'll just see what happens."
A few hours later I get to the "oh yeah..." part.
Funny thing is, that works both ways. Sometimes no matter how much you plan, if you just start coding you get the positive "Oh yeah!" moments that wouldn't have happened on paper.
+1. I've found that thinking hard and long about most problems before coding them results in less buggy (sometimes even no bugs!) code. I remember my friend telling me that his dad had to stand in line and wait literally days to execute code on a computer (using punch cards) and they had all the time in the world to write the code, but very little to execute it. One mistake during execution and they would have to wait a few days for their turn, delaying the results that they were seeking.
I try to emulate this environment (by not compiling/running code) and trying to tell myself that I really should get a large chunk of thought (followed by relatively bug-free code) down before I let the compiler/interpreter in. This discipline has helped me a lot imho.
Yeah my Dad has told me similar stories. In fact, I'm finding a similar thing now when I'm using the university supercomputer. I don't have to submit using punched cards anymore (thank goodness) but I do have to submit jobs to the batch queue and give them an estimated time the job will take to complete. This impacts the scheduling of the jobs, so if I submit a job and say it'll take 12 hours to run, then it is unlikely to start for a while. This gives me another reason to check the code very carefully, or I wait overnight and find that my code crashed after 2 seconds with a silly error!
Why is the write test -> code -> run test -> code -> run test -> etc. circle being derided? Given that your test cases are stringent enough, it should be fine.
If you did indeed write good test cases, then that's a prime indicator that you understand the problem you're solving well. Try test first programming, it's trickier than it sounds at first. In my opinion, it is too easy to get caught up into coding something (especially with languages that have large amounts of boilerplate, such as Java) and lose perspective of what you're actually trying to do. Writing test cases beforehand forces you into thinking about what you're actually doing.
Having a baby caused me to transition to this style for personal projects. I spend a lot less time in front of the computer now and when I do it's for shorter times.
I've found this approach does give a better result and eliminates false starts. When I'm at the computer now I have already thought through what I'm going to do completely and writing the code is just a minor detail.
While I do agree that stepping away from the computer helps for getting started or when you're stuck, I am more in line with people using CSS rather than Photoshop for prototyping. As the author wrote, converting thought to code is fairly easy, so by writing as I think, I free my mind from containing all the stuff I thought out already.
I have always had one or more musical keyboards by my desk, and I agree that there is a correlation between musical and software inspiration. However, I think in my case both forms of inspiration are derived from the same cause, rather than one causing the other. I'm still working on discovering that common cause.
Agree. Some of my best coding and problem solving was done when I was pacing around my office while playing with a stress ball. Sitting in front of the computer is my least productive spot for solving problems. I code best when pacing around, in the shower, or driving...
Is it really true that many real-world programming tasks require this level of thought and dedication?
Honest question, I'm a student and none of my school/pet projects have been difficult enough that stepping away from the computer was beneficial. Only puzzles have been hard enough.
For myself it goes one of two ways, I can actually write the layout on a text editor or I like to go to the park when hardly anyone is there and just walk around. It takes my mind off the problem, thus leading to a solution I never thought I would have gotten.
