Deliberate Programming

https://medium.com/on-coding/2204cfa35233

by nbashaw • 13 years ago

42 6 13 years ago

medium.com

nbashaw• 13 years ago

OP here. In the spirit of the post, I'd love if anyone has any critical feedback on the ideas here :)

davethespider• 13 years ago

A great tip I have been using recently is to avoid using cut and paste and IDE completions.

rpmcb• 13 years ago

I learned a while back that even if I'm going to use the exact code snippet I found on StackOverflow character for character, it's best to type it myself into my editor.

Copy and paste is faster, but manually typing it in forces me to really evaluate what exactly the snippet is doing.

sivers• 13 years ago

Hey Nathan. Great article. Thanks for writing this. Loved your three points. It's a subject I've been thinking a lot about lately, but I hadn't thought about feature re-writing for repetition practice. Good stuff.

The only thing I'd add is setting up quizzes for yourself. See http://sivers.org/srs

If most day-to-day programming we do is 95% stuff we know, and 5% stuff we haven't committed to memory ("how do I sort an array of JavaScript objects by one of their properties, again?") - then I've found huge deliberate-practice-style benefits from taking each thing I don't know, as I run across it, and putting it into an Anki flashcard.

Then each morning as I start my day, I open up Anki to let it quiz me. I've seen massive improvements in my vim, JavaScript, AngularJS, Ruby, and Sinatra skills from this approach of practicing just what I don't know.

Email me if you want to geek out about this. Deliberate programming is one of my favorite subjects.

notaddicted• 13 years ago

I'm not a grandmaster by any means, but these are things that I focus on:

1. Aggressively avoid techniques and abstractions that have produced bugs in the past. The "backwards conditional" is an example of this, in languages like C that will accept x = 0 as a conditional, it is safer to do 0 == x in an if statement in case you mistype. Mutability trips me up sometimes, so I try to never re-assign a variable. I keep links to the source code of key libraries in my bookmarks bar so I never have the guess how something actually works. Static analysis tools, and bug prediction tools [1] are two steps I haven't taken.

2. Seek out code written by experts and inspect it [2]. If I'm considering using a new language or library one of the first things I do is to search for large scale OSS projects. For a new language looking at some of the popular 3rd party libraries can be really illuminating. Especially if you're already familiar with the problem space.

3. two words: learn to fuckin' type.

4. Get familiar with what the history researchers call the Primary Sources. Not just the actual source code but the proposals, the specifications, and the research reports that are written by the people who conceived the tools that you are using.

[1] http://google-engtools.blogspot.ca/2011/12/bug-prediction-at...

[2] (EDIT) According to Paul Allen, in high school Bill Gates actually went dumpster diving for source code: http://www.businessinsider.com/10-things-you-didnt-know-abou...

isxek• 13 years ago

Try a new library, or language, or feature of a language as often as possible. Experts become experts by mastering a ton of tiny things.

Personally, I'd rather go deeper in what I'm learning on at the moment and finish something substantial before diving into some other topic. It probably depends on how much of a multi-tasker the person is, but I find it difficult not to concentrate on one topic at a time.

I do understand what you're trying to say, though.

Deliberate Programming

Related Stories