Brian Marick shares insight into how one can remain a programmer throughout his career.
Brian Marick was a Lisp and C programmer in the 80's, a testing consultant in the 90's, and an Agile consultant in the 00's. This decade he's a Clojure and Ruby programmer. He was one of the authors of the Manifesto for Agile Software Development and is the author of four books, including The Craft of Software Testing and Functional Programming for the Object-Oriented Programmer.
ACCU is an organisation for anyone interested in developing and improving programming skills. ACCU welcomes everyone who is interested in any programming language. ACCU supports its members by hosting mailing lists, running a yearly conference, publishing journals and organising online study groups.
There is obviously room for improvement, for example: after 7-8 minutes of discussing about how Crickets hear and mate, you admit this has nothing to do with the subject of the talk.
We might be doing things differently here in Europe, but I learned how we estimate distance and how we hear from my math and my biology teachers in school. This was when I learned in biology class why vultures have front facing eyes and hens have eyes on the opposite side (hint: some animals are hunters and some are prey) and also when I learned what sin()/cos() functions are. All these examples bring nothing new in general and, especially, nothing to the subject you are adressing.
The talk is, perhaps, just a basic introduction to evolutionary biology and natural selection and has little to do with IT in general, except for the two buzzword-compliant slides about TDD and Refactorings.
I rather found this talk refreshing, honest and interesting.
I would not object so much to how interesting the presented facts are, as to how they can be applied to the subject being adressed. I was expecting to get some insight on how one can still work as a developer when he/she is 50-60 years old. Perhaps you could share a short list of practical advice you got from this talk.
...or "How to automatically manage complexity"
Brian uses crickets, baseball, tango, valet parking, chess, medical diagnosis, and XP to explore the appeal of automatic, complex behavior. He alludes to Daniel Kahneman's Thinking Fast and Slow in discussing the effortful vs. the automatic systems in the brain.
The implication is that, to the extent that you can make aspects of your job as a programmer automatic, you can use less energy to accomplish a task than those who have not. Effortful activity is tiring and error prone. Automatic activity is not tiring and is mostly accurate.
Brian offers some principles to help manage complexity:
* Constrain possible perceptions
* Make perceptions one-to-one with actions
* Convert goals to achieve into invariants to maintain
* Convert effortful calculation into automatic perception
* Make changes to simplify perception
For those of you interested in these topics, I think you'll enjoy spending an hour of your time here to get a glimpse of the neuroscience behind expert performance, whether those 'experts' are crickets, doctors, or programmers. If these ideas are new to you, good...the science of complex systems is full of examples of patterns in many seemingly unrelated fields operating off of similar principles and mathematics.
My advice: Get used to it. The complexity of the world is increasing. It's your job as a programmer to manage that complexity. Enjoy the ride!