Avoiding rabbit holes

What if you don't know what you don't know - and you make mistakes because of it. E.g. HW vendor says this router resolves the sticky session problem - if you don't know how complicated the problem is, you might just believe the vendor. Then it turns out that the problem is not resolved (the solution on the router is experimental) - a few months later you realize you need to go to a stateless session direction. If you knew this beforehand, the whole thing could have been avoided.

There are methods to resolve these on a larger scale, like SW architecture, but how can you scale it down to the day-to-day job, like choosing which library to use for a particular problem?

E.g. A test fails. You're a developer familiar with the code, so you have a preconception about what the cause is, but after a lot of debugging, it turns out you were wrong.

In some cases, specific roles / dedicated people can help. E.g. in larger firms, you can have a senior architect for overcoming a lot of the issues: it's his job to ensure that the what the customer needs can be done, what the developer commits to makes sense, etc.

Another example: something is wrong with your car - the mechanic will be able to explain a lot of things, but you'll have no in-depth knowledge. You understand on a large scale, but won't be able to fix the problem yourself.

Architects should oversee the system, but doesn't have to understand it in depth. He knows how a feature fits into the architecture, but cannot implement it. Two critical aspects:

• He should be able to ask the right questions.
• He should have the connections, he should know who to ask.

This assumes that you know that you're in a state when you need to ask. And even if you ask, you can be misled (e.g. if you ask the vendor if the router is capable of X, you'll be told it is).

When to step back? When should you stop debugging/diving into the code? Maybe Pomodoro (short iteration cycles) is one solution?

Bug hunting - try to remember if the issue happened before. Gather data. If you don't have any reliable data, you have to trust your sixth sense.

If you have a proposed solution, wear two hats. First: try to prove your solution works, second: try to break your solution (because if you can make it fail quickly, you can avoid wasting time).

Time boxing vs snooze button: it's very easy to say at the end of a pomodoro/iteration that I'll just spend 5 more minutes on the problem. Rule of thumb: if you'd hit the snooze the second time, it's time to step back.

This is easier to realise if you have no idea about the problem at all, but what if you had a wrong idea ("I'm so close!"). You have to set a deadline for yourself - if you have been 'close' to the solution for two days, you're probably wrong.

Sometimes it's good to go down rabbit holes, because you can learn a lot. Whether or not it's worth diving in is a function of what other tasks you have, how complex the problem at hand is, etc.

Multitasking doesn't work for development. E.g. on a project that doesn't have deadlines - it's even harder to focus on one particular task. Plus, if you don't have a deadline, you won't declare your code to be done ever. People were doing work on a lot of things - so limit to 1 task / developer.

Don't personalize your mistakes. I made a mistake != I'm stupid. Especially if it's the first time you're doing stuff (e.g. renovating your home), you can't expect yourself to be perfect. But if you're a newbie, you need supervision. Also, if you practice in a different environment, sometimes you need to unlearn (like learning flipping a kayak upright in a pool vs. doing the same thing in a river).

Ideas within the team vs external ideas: is it a question of appealing to authority (a guy said it on a conference, so it must be cool) or signal to noise ratio (there are a lot of ideas internally, whereas there are only a few coming from an external source). E.g. "we should do pre-commit code reviews" - if I say it, it's dismissed, if I go to a conference and a guy there says it, it's accepted.

Insufficient information during development: e.g. from initial info it was clear that the solution is going to be a web app. Then: "oh, it needs to be able to print across workstations." (plus, this feature is essential) This is the kind of stuff that you don't think about asking.

If you're new to a code, it's easier - you know less, there are less assumptions, you feel more urge to ask questions.

Conclusion: ask, talk to people as much as possible. Smoke a lot and drink a lot of coffee - as those are the best opportunities to discuss stuff. :) It also depends on the company culture: are questions encuraged?

Rubber chicken is a good tool to: something to whom you can explain your understanding