He replied "Eight hours."
"Eight hours?"
"Yep, eight hours, every day. It's pretty much just like driving a bus. The hard part is keeping your ass in the seat."
Fifteen years and a master's degree later, his advice remains remarkably accurate.
He replied "Eight hours."
"Eight hours?"
"Yep, eight hours, every day. It's pretty much just like driving a bus. The hard part is keeping your ass in the seat."
Fifteen years and a master's degree later, his advice remains remarkably accurate.
We seem to focus on the poles: no coding skills vs. expert coding skills. You can teach yourself to code in less than 10 years, you just might not be an expert.
The "learn to code" debate might be more productive if we allowed for definitions of competency at the stages leading up to expert. The post does a good job of defining the characteristics of expert competency. What does it mean to be an intermediate? How many hours should you expect to invest to get there?
In most domains, the learning curve ramps up sharply for the first few years and then plains off for a longer period. For example, you might move up 80% of the learning curve in 3 years with an intense effort, but the remaining 20% of the journey might take 7 additional years ... or a life time.
I tend to call myself a 121 programmer: I try to improve the total value of my knowledge base by 1% every 21 days. That's realistic, and those 1%'s add up over time.
MacLeod Sociopaths: 121 programmers who optimize for learning. MacLeod Clueless: 911 programmers who deal with hideous emergencies and compensate for bad management. (9-1-1 is the US emergency telephone number.) MacLeod Losers: 501 programmers who are out the door as soon as they can go home.