Sometimes I will have a have a big problem that I will decide not to fix immediately, even if it's more "important" than other things I'm working on. Then, when I come back and rapidly write a simple solution, the question of course is "Why didn't you do this a week ago if the solution was so simple?".
The answer is that the answer wasn't simple at first. Understandings of a problem and solution often live and die many times over in a mental background thread, before they ever reach a keyboard.
Sometimes, when under pressure, I am forced to ignore this fact and start writing the moment I reached the "Yeah, I think that would probably work, let's git 'er done!" phase. In almost every such case, it takes longer overall as I iterate through incomplete solutions and rewrites.
A lot of times I’ve found the amount of time it takes me to solve a problem is about the same whether I’m actively working on it or not. Once a problem has been percolating in my head for a while things eventually “click” and it just becomes a matter of typing out the code. This looks like procrastination from the outside, but I’m still working even if it looks like I’m taking it easy. At least my brain is, somehow. I have come to trust this process after many years.
Alternatively if I start tackling the problem immediately and really put my nose to the grindstone there’s often a lot of moments where I realize I didn’t understand the problem fully, and waste a ton of time backtracking. So it ends up taking the exact same amount of time, only difference is how many times I banged my head against the wall in frustration.
sometimes I work on a problem way too late. Get stuck and try all kinds of things. Then I go home, eat, spend time with my family. The next day I open up my computer and immediately find and solve he issue.
It's very hard for me to put a problem down and simply not think about it for a period of time, but as I've matured I've realized how important that skill is.
It depends. If it's an interesting problem I have to work on, but I can't right away, I think about it as I'm going about my day. Driving, cooking dinner, rotting in a meeting. Then by the time I get to finally do it, it's close to a fully-formed solution.
If it's a problem that I have to address right now, it's more like prototyping the first idea that comes to mind and then debugging and refining and being more critical.
>This past week I was faced with a difficult problem. A really difficult problem... I kept going and in another hour or two, I was getting epiphany. I had the solution to my really difficult problem.
I am happy that he solved his problem, but was it really that difficult if it could be solved in just a few hours? How long would it take him to solve the most difficult problem in his domain?
In my experience it might take as much as a week even to identify the relative difficulty level of hard problems, which tend to be refined, restated in a simplified context, expanded out to boundary cases etc. To me it seems like "just looking at it" is the very first step in a longer process.
Yes. If your problems are essentially trivial and you are just trying to gauge customer moods, shipping and shipping again quickly is the way to go...and thinking about the problem will probably not help.
However, while quick iterations converge rapidly on a local maximum, they really, really suck at getting you out of that local maximum.
I notice this with trying to create a new and different programming language (http://objective.st): for almost all the problems I am tackling, there are quick and obvious answers...that get me stuck in the same mess we are already in. So I've found it necessary to deliberately delay implementing stuff, going slower than I can and make sure I leave the time for my not-quite-conscious thought processes to work out the problem and present the results during a relaxing shower.
I've observed this as well. It's very satisfying to finally realize you don't need to solve it in the first place, because your assumptions created a problem where there was none.
E.g. mulling for weeks over optimizing some code until you realize to measure it as-is and it isn't even slow!
Or maybe there's room in the underlying design to shift the weight off the problem, thus "solving" it laterally (by solving some other, easier, problem instead).
Yes! Exactly! I had a issue that I wasn't sure how to start, and didn't understand too well, and it was killing my productivity.
I ended up just doing something, anything, even if it's wrong. Then I could correct it and do it properly. But sitting there fretting about it being hard and vague wasn't making any progress
Personally, I love finding solutions to problems that are new to me. I will work for 20 hours straight on a coding problem, but once I actually solve the problem I lose all interest. If, in the course of finding the solution, I didn't fully implement it, there's a solid chance that if I'm not given a deadline for finishing that implementation it will never be done; I'll have already moved on to the next interesting puzzle.
OP here. Well, it just worked out that I found my "solution" to my problem that afternoon. But I was thinking/researching the problem for many weeks at different levels. And I was finally coming to a deadline.
I agree though, it takes a long time sometimes to solve really difficult problems.
I've spent hours looking at simple statics problems that I know I should be able to solve in fifteen minutes, but just can't for whatever reason. It's like I've gotten on the wrong mental track early on and can only move further along that track or backwards. I'll give up for the moment to go eat or see some friends or just make contact with the outside world for an hour or so and during that time, the answer presents itself without much effort. I can then come back and redo the problem within 20 minutes.
I wonder, though, if these epiphanies could have happened without the hour long struggle preceding it. Leaving a problem, it feels as if my mind is untangling itself and organizing this mess of thoughts.
What I would really like to see some research on is the mental barrier between myself and starting the work in the first place. I'm looking at it right now... :|
Neither. I tend to stare down a problem until I can solve it. I want to have the whole solution, or at least the critical parts of it, in my head before typing it out.
One of my bosses described my technique as "do nothing all day and get stuff done."
There were three similar projects assigned to our division, each assigned to a sub group of three people (typically a programmer, a psychologist/researcher, and a designer). My sub group was the only one to successfully create and deploy their application before the three month deadline.
(I also moved them over to Pivotal Tracker since putting stuff into their regular system was abandoned long ago and the white board was becoming an organizational nightmare.)
On the other hand it can be helpful, in my experience, to stop right in the middle of a very hard problem, where you are still searching for a good solution. Come the next morning I often know at least a possible solution, without having worked on it consciously.
People get stuck solving problems for various reasons. For me, I think more clearly when I write. The primary benefit is that it stops having to mentally re-establish my logical premises to make sure my conclusions are sound.
Anyway, the hardest part of writing code is starting. Why is that? A lot of times it's overwhelm, you see the task, it appears large and you don't know what to start.
My solution is simple, I start writing the steps I need to take. This will be easier with an example. To not get stuck in weird debates let's pretend the ask is that I need to build a house extension for someone.
I will start breaking that down, in bullet points.
* Figure out location of the extension
* Find out dimensions of the extension
* Order wood and nails
* Bring hammer on Monday to start
At this point I might know what kind of wood I need, hell I might even need to buy bricks. But I have a semblance of steps. I can talk to the client and ask specific questions.
As I go through my list I expand it or make it more focused as I go. Out of habit I also tend to mix thoughts and realizations in my bullet points.
Then as I am going through the solution the following days I can see my thoughts expanding and increasing in specificity.
There is another thing this does. If I find it hard to come up with a few bullet points it means the problem is too vague or I don't understand it well enough. Instinctually you will know if it's lack of knowledge or vague problems. If I lack knowledge I read about it or talk to an SME. Vague problems can be solved by talk to the Product Owner, Business Analyst or a client if it makes sense.
Once I grasp the problem, get basic questions answered I go through my bullet list and refine it. That's when I try to design things. After I have a design I try to see if I'm making any assumptions. Personally I prefer to test any assumptions I have.
I rather find out my assumption is false at the design phase than later. Granted sometimes things can get still trip me up, or give me a false positive.
I don't spend a ton of time designing. If I can I will pitch my design to someone I consider smarter than me to see if they find holes. I prefer people that think more breadth first, because I think depth first. Their strengths is my weakness.
Most of the time in the act of my pitch I will find assumptions I have made or I will realize that what I am saying is overly complex so it probably means I didn't design it well. So I iterate.
Designing doesn't take me long most of the time. I have learned that I think better when I code than when I design.
When I start coding I use a dirty version of TDD. Instead of write test, write code to pass test I follow a different pattern
I write small parts of code that satisfy the most likely case and I write the first step of the most likely case.
For example if I was writing a rock paper scissors game, the first part would be to to right the main method framework and print "welcome to rock paper scissors game". Then I run the code to see it's good.
Next step would be to accept input. Test that. Then write the logic for determining what the CPU will throw. Test that. Then how to determine the winner. Test that. Then create the "you win/lose" message. Test that.
Once that's working I'll start to worry about things such as, what happens is they press enter without any input. What if they miss type a word. I might decide that I would be easier to make it multiple choice, where a = rock.
This is a simplified and contrived example. Sometimes I'll write things I consider easy in one go, but if I have doubts or I am starting to touch complex objects or logic I start testing more frequently.
When I test I don't sit, I keep writing code while the test is running. I test excessively but it helps me to see unintended consequences quickly since my code to test cycle is short it's really easy to identify the source of my woes.
Either you have a solution, and that's a great thing, or you are close to a solution and one will be found more quickly and that too is a great thing, or you don't have a solution. That's not such a great thing, but it's a contribution to the set of cases not known to be solutions, potentially hinting at where the solution may lie.
This assumes you have done the thought work and want to know. Don't you?
Yep, a solution that you rewrote a thousand times as you understood more, is still better than one perfect solution that occupied your head for several days along with the stress of having not implemented anything yet
There's something you might have missed. When I approach a problem like this I notice I solve it only after I give up.
It's not spending 15 minutes to go over all assumptions that makes me solve it. It's telling someone I can't solve it. It's the act of saying I can't do it.
I often start writing an email telling someone I can't solve a problem, and while writing I realize something I haven't tried. Then I stop, go try it, and it turns out to solve the problem. But if I don't start writing that email, and instead try to work on the problem for 15 more minutes, I don't solve it.
It's as if I don't take the problem seriously otherwise.
This is very similar to the 15 minute rule, only it's more efficient, since it takes less than 15 minutes to write that email.
So I would argue solving the problem has more to do with admitting you can't solve it than it has with going over assumptions. It triggers something in your brain that frees it to look at options it hasn't looked at before.
I thought it was the possibility you might embarrass yourself to the person you are emailing that helps solve it. But the strange thing is I also solve problems only after I send that email. My mind refuses to look at the problem from a different angle otherwise.
I often think a particular problem is a day's task. Then a week later I'm still working on it. For sure, it might be me being lazy, but I suspect I've also underestimated the complexity of the task. Other factors play in as well, like if I'm tired my ability to solve tricky problems goes waay down.
Perhaps I should always be not tired, but sometimes life has a habit of getting in the way.
Strongly agree, I know there is some literature on that, but just wanted to add that for me the process of solving problems is very asynchronous and usually the a-ha comes out in the most unexpected times.
Sometimes I will have a have a big problem that I will decide not to fix immediately, even if it's more "important" than other things I'm working on. Then, when I come back and rapidly write a simple solution, the question of course is "Why didn't you do this a week ago if the solution was so simple?".
The answer is that the answer wasn't simple at first. Understandings of a problem and solution often live and die many times over in a mental background thread, before they ever reach a keyboard.
Sometimes, when under pressure, I am forced to ignore this fact and start writing the moment I reached the "Yeah, I think that would probably work, let's git 'er done!" phase. In almost every such case, it takes longer overall as I iterate through incomplete solutions and rewrites.
reply