Investigating programmer productivity. Learning about the history of the programming profession in general, of the “software engineering” meme in particular, and detailed history of the “agile” meme. Learning some R and stats on the side.
Why—because there is a lot of leverage in looking at the question of why programming skills are what they are, and how they could generally be better, compared to just improving my own. There seem to be some low-hanging fruit, such as encouraging programmers to be more aware of cognitive biases affecting their work, or of the nature of probability and tools for working with it.
Thanks! I have a longer follow-up (6K words), which I’m not publishing yet because it might end up as one part of a point-counterpoint feature in IEEE Software’s column “Voice of Evidence”. If you message me your email I’ll be glad to send you a draft.
Investigating programmer productivity. Learning about the history of the programming profession in general, of the “software engineering” meme in particular, and detailed history of the “agile” meme. Learning some R and stats on the side.
Why—because there is a lot of leverage in looking at the question of why programming skills are what they are, and how they could generally be better, compared to just improving my own. There seem to be some low-hanging fruit, such as encouraging programmers to be more aware of cognitive biases affecting their work, or of the nature of probability and tools for working with it.
I enjoyed this article when I saw it on HN. This is an area which really needs more/better research, so thanks for looking into it.
Thanks! I have a longer follow-up (6K words), which I’m not publishing yet because it might end up as one part of a point-counterpoint feature in IEEE Software’s column “Voice of Evidence”. If you message me your email I’ll be glad to send you a draft.