Deliberate practice
Deliberate practice involves focusing on a specific task to make directed improvements (e.g. how high your fingers lay at rest on a guitar neck or how we form loops while writing cursive.) It relies on:
- understanding what the best do
- break down large goal into small steps
- regular focused practice
- immediate feedback
Most people put in the absolute minimum even when they care, so it is easy to excel by thinking about what we’re doing and emulating the masters. We can break down their virtuosity into small steps, each taking us slightly outside of our comfort zone. With immediate feedback, we can gain confidence to stay on the right path until we have conquered this area and can begin working on a new technique or optimization.
You must avoid at all cost the idea that you can manage learning several skills at a time. You need to develop your powers of concentration, and understand that trying to multitask will be the death of the process. - Robert Greene
For Developers
Aggregators like HN, Reddit etc. submit us to a constant stream of distractions. Following the herd with the latest API, library or language clogs our mental bandwidth/mindshare, preventing us from perceiving the deeper, durable structures underlying our field. A historical perspective helps us appreciate the problems and solutions which arose in the past and led us to where we are today (often showing us how new solutions and trends repeat past approaches with the same pitfalls.)
To improve, refactoring (changing the code representation of behavior between representations) and adding new features/behavior is our bread and butter of leaning. Inspired by the Quora post linked below Interview type questions/leetcode/katas lead us away from this truth, teaching us to quickly produce (unexamined) rough drafts and nothing more. (For certain problem subsets (e.g. interviews) imprinting CRUD best practices into rote memory may work, but only undergirded by introspection and deep experience.)
Although we have little physical component, some minor mental parts are equivalent (touch typing, hotkeys (be they Emacs, VSC etc.), knowing our languages' core libraries to obviate referring to documentation…) and can be drilled or integrated into our flashcard regimen.
Keep these in mind:
- selfdiscipline (run through barriers)
- selfconfidence (we create solutions, so we should believe in them and our ability to overcome them)
- break problems down/abstract: just as with deliberate practice itself, we should do this for our problem space, our ticket requirements etc.
- analogies: e.g. if we think of x like a tree, we can use so and so algorithm
Practice Ideas:
it’s more valuable to do the same exercise six times with variations than to do everything once
To get better at logging, start with a working program, then introduce a logging component. Then on a second until you’ve added it to 10, accounting for differences in their architecture and purpose. After you’ve gained some insights, add it again to each of them, profitably appreciating the trade offs and approaches needed. Now do logging in a different paradigm, instead of Go do it in clojure!
Batch research and programming; instead of stopping to google, write down your question and why, then continue programming. Only after we can’t go further address the group of questions together, noting their answers down and incorporate them into your code (narrowing the scope of practice.) Gradually you’ll learn ways to use placeholders or code around unknowns, particularly helpful when we can’t simply research the answer!
Many aspects of engineering don’t provide immediate feedback, which is needed to modify your approach. But the Mikado refactoring method could work for architecture, where you code until hitting a roadblock, then reset it and instead code to fix the roadblock, perhaps hitting another until you start fresh targeting the core problem. This can help you implicitly grok the sources of future problems.
Katas for algorithms etc. Pick a data structure of algorithm. Each day for a week, find a different implementation look at it, then without looking try to implement it, only looking when you get stuck. At the end of the week, you’ll have really learned it and its different varieties.
algorithms drill the skill of bug-free coding. Algorithms are hard and frustrating! Subtle off-by-one might not matter for simple tests, but breaks corner cases. But if you practice algorithms, you get better at this particular skill of writing correct small programs, and I think this probably generalizes. - Alex Kladov
Just slowly working through SICP, Domain Modeling Made Functional or such and doing a half an hour of an exercise per day.
Go through leetcode problems and sort them e.g. by array or dynamic programming and explain the approach in words (e.g. use a hash map to check for difference value, add index of last occurrence; make two passes, first in order, then in reverse, to compute products) so you memorize the pattern of how to solve it (at a higher level! See this spreadsheet)
Track bugs, build exercises around avoiding them (like Knuth’s error log.) If off-by-one mistakes abound, solve many binary search, parity and boundary-related problems. Is there something that you notice when writing these programs? Do you pay closer attention to boundaries, or reason about them differently?
More commonly, a codebase will clearly outline holes in its maintainers' knowledge. What eggshells do you walk on while closing tickets? Was the team using an ORM as a crutch out of fear of SQL? Learning a bit of SQL, every relevant ticket becomes a drill of migrating from ORM to straight SQL!
An Openended Question:
Showcasing competence is difficult. While designers and frontend devs can make portfolios of beautiful or evocative UIs, their architectural decisions and concrete user friendliness aren’t obvious. Other developers face this everywhere. While software design skills are universally applicable, how do we display mastery honed through thousands of exercises?
(Currently we meekly hope to find someone of equal intelligence, taste and skill to vouch for us.)
Further reading:
- Peak - Anders Ericsson
- Mastery - Robert Greene: Interprets Ericsson’s mental representations and directed focus as key to mastery
- http://calnewport.com/blog/2010/01/06/the-grandmaster-in-the-corner-office-what-the-study-of-chess-experts-teaches-us-about-building-a-remarkable-life/
- http://calnewport.com/blog/2012/11/27/some-notes-on-deep-working/
- https://www.quora.com/What-are-some-tips-for-advanced-writers/answer/Venkatesh-Rao?srid=P99r Paraphrasing: Normal writers spend 10-20% of time rewriting, serious writers spend 50-90% rewriting. Editing both improves the piece and you as a writer.
- Why Greatness Cannot Be Planned: The Myth of the Objective - Kenneth Stanley: Argues for novelty searching surpassing objective driven learning, but poorly written, too wordy, half academic book, half self help book
- https://www.youtube.com/watch?v=SVvr3ZjtjI8