I've been thinking some about the idea of coding fast, or coming up to speed on new languages quickly.
From that viewpoint, I'm wondering about what the minimal set of language features you need to have committed to memory to enable you to code fast. These are the pieces of code that without which you can't make even a passing claim of competency in a language. I'm thinking about the crib sheet of functions/definitions/language features you have to have ready to go in your toolbox so you can code fast. It's the stuff you'd want candidates to demonstrate knowledge of in an interview as well and be able to apply at least in conversation to a new problem.
I'm interested in figuring this out for a multitude of reasons, not least of which is retention of knowledge related. Years ago, I hacked in C for performance reasons in the ___domain I was working in Lots of pointer junk, tiling of data (interleaving of row and column data to blow up memory bottlenecks), and a healthy dose of bit twiddling to make it all work nicely. I realized not too long ago that most of these skills had faded due to lack of use.
I'm playing some with spaced repetition software for memory training (think SuperMemo and Mnemosyne) and thinking about plugging in those pieces of programming languages that you have to be ready to throw out to code fast in a language. I'm just testing for now, but I think I might even try throwing something like the question/answer pieces from The Little Lisper in there for fun. Kind of a daily brain teaser.
Since I spend most of my time at work hacking SQL, it's pretty easy for me to stay fresh and also identify the minimum set of concepts and ideas you need to even think you can write halfway decent SQL: SELECT,INSERT,UPDATE,DELETE,JOINS - all types, ansi sql functions - including analytic functions, nulls, subqueries, boolean logic,etc. It's a non-trivial set of stuff to have in your head so you can think correctly about problems.
To make it even more fun, you need to have a meta-sense of when to apply what tools and languages? When do you want a RDBMS versus rolling out hadoop? What data do you want to send to your web app so your users can muck around with it - which means understanding enough Javascript to be able to provide them with some intuitive tools to munge data there.
I'm pushing towards the idea of internalizing not only the specifics of a language, but the idea of what programming language and tool fits a problem best at any given time.
Software folks get all the best toys to think about . . .
"I'm pushing towards the idea of internalizing not only the specifics of a language, but the idea of what programming language and tool fits a problem best at any given time."
I've found that anytime something seems crufty, or perhaps like I'm twisting too many rules, or just plain inelegant, I think "there has to be a better way to do this" and its off to the google/documentation/greybeards. If you don't get that feeling yet (it will come) any time something seems hard, explore other people's solutions -- that is more than one, and compare/contrast them on a detailed level. Eventually you'll either start just understanding what the best tool is, or more likely, intuitively knowing that you don't know a good solution and that its time to search. (It's a big field, knowing when you don't know is a good place to be).
Yeah, I have a lot of "there has to be a better way to do this" thoughts . . .
One of the aspects of software development I'm really interested in is finding drills and ideas that more rapidly build the intuitive response you can trust. The tools of the craft, so to speak.
There is some type of balance to be found in this space, some combination of declarative knowledge (memorization and simple application of different programming languages) and procedural knowledge (experience building up the greater piece of software from that low-level mix).
Thanks for the crufty test idea - nicely sums up what I'm talking about.
From that viewpoint, I'm wondering about what the minimal set of language features you need to have committed to memory to enable you to code fast. These are the pieces of code that without which you can't make even a passing claim of competency in a language. I'm thinking about the crib sheet of functions/definitions/language features you have to have ready to go in your toolbox so you can code fast. It's the stuff you'd want candidates to demonstrate knowledge of in an interview as well and be able to apply at least in conversation to a new problem.
I'm interested in figuring this out for a multitude of reasons, not least of which is retention of knowledge related. Years ago, I hacked in C for performance reasons in the ___domain I was working in Lots of pointer junk, tiling of data (interleaving of row and column data to blow up memory bottlenecks), and a healthy dose of bit twiddling to make it all work nicely. I realized not too long ago that most of these skills had faded due to lack of use.
I'm playing some with spaced repetition software for memory training (think SuperMemo and Mnemosyne) and thinking about plugging in those pieces of programming languages that you have to be ready to throw out to code fast in a language. I'm just testing for now, but I think I might even try throwing something like the question/answer pieces from The Little Lisper in there for fun. Kind of a daily brain teaser.
Since I spend most of my time at work hacking SQL, it's pretty easy for me to stay fresh and also identify the minimum set of concepts and ideas you need to even think you can write halfway decent SQL: SELECT,INSERT,UPDATE,DELETE,JOINS - all types, ansi sql functions - including analytic functions, nulls, subqueries, boolean logic,etc. It's a non-trivial set of stuff to have in your head so you can think correctly about problems.
To make it even more fun, you need to have a meta-sense of when to apply what tools and languages? When do you want a RDBMS versus rolling out hadoop? What data do you want to send to your web app so your users can muck around with it - which means understanding enough Javascript to be able to provide them with some intuitive tools to munge data there.
I'm pushing towards the idea of internalizing not only the specifics of a language, but the idea of what programming language and tool fits a problem best at any given time.
Software folks get all the best toys to think about . . .