The key difference between experts and beginners is the quality of their abstractions. Masters of a field mentally organize information in a way that's relevant to the tasks at hand. Amateurs may know as many facts and details as experts but group them in haphazard or irrelevant ways.
For example, experienced Bridge players group cards by suit, then number. They place the most importance on the face cards and work down. Bridge amateurs group solely by number and place equal importance on all numbers. Professional firemen group fires by how the fire was started and how fast it’s spreading-features they use to contain the fire. Novices group fires by brightness and color. Both have the same information, but the firemen hone in on the useful details faster.1
Learn abstractions from masters. If you ask a Software Architect which database technology you should use, circumstances will eventually change and you'll need to ask them again and pay them again. But if you ask the Architect to teach you how to choose a database then you can adapt to changing circumstances. Ideally you should emerge with a clear set of rules-something like a flow-chart for that decision. A good example is this article on whether you should use hadoop. Clear criteria let you make a high-quality decision by focusing on the relevant details.
After talking to the expert you can write up the flow-chart or criteria and send it to them to get their opinion. This ensures you understood what the expert was trying to say, and lets you get additional details they might add. Most importantly it gives them something valuable to share with people seeking similar advice, so you're able to add value to their lives as a thank you for their advice.
Caveats to this method:
- In some domains there are details only professionals know. Academic research has a secret paper-passing network with ideas known to top researchers 1-2 years before they’re published. So you need to be in constant contact with these experts and hear the details from them. However, this typically only matters if you’re aiming to become a top-class expert yourself.
- Experts aren’t always conscious of the abstractions they use. They’ll say one thing and do another. So you should ask them to guide you through a specific situation and ask them several questions about how their decision would change if some conditions are different.
- You may not have a specific question you want answered-you might want to find “unknown unknowns.” In that case ask the expert for stories-things they did that made a big difference. Then analyze those situations to figure out what criteria they used.
= 27d567bc2d48d9f40e9ccc20ea370b15)
= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
= f037147d6e6c911a85753b9abdedda8d){kind=logo}
Well, it depends on the architect, I suppose. I would say "write your application in a modular way so that it doesn't rely on specific features of the underlying database, and if you need to make exceptions to this principle, make sure the relevant code sections and dependencies are well highlighted and documented."
Good call. This is a great example of how sometimes experts can even point out that you're thinking at the wrong level of abstraction, and provide a better one.