<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Learning to Think Like A Programmer</title>
	<atom:link href="http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/feed/" rel="self" type="application/rss+xml" />
	<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/</link>
	<description>a weblog by Tom Armitage</description>
	<lastBuildDate>Mon, 06 Feb 2012 22:42:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: davee</title>
		<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/comment-page-1/#comment-151555</link>
		<dc:creator>davee</dc:creator>
		<pubDate>Thu, 09 Jul 2009 03:05:07 +0000</pubDate>
		<guid isPermaLink="false">http://infovore.org/?p=2258#comment-151555</guid>
		<description>I am a &#039;career&#039; programmer. I &#039;ve been a professional programmer for 34 years now and in all that time, I&#039;ve only ever run into a couple of programmers that &#039;think like a programmer&#039;.

Most programmers seldom spend more than a few years before moving into management, their original goal. unfortunately, the vast majority of these &#039;stepping stone&#039; programmers is that they don&#039;t have their heart in it and subsequently never really learn enough about programming to ever become a &#039;good&#039; programmer. This is evident by the incredible number of bugs in their code.  One could write a book about the bad practices they employ.

Another problem is that every time we change jobs, we usually have to start from scratch. It takes time to learn new applications, languages, operating systems, frameworks, libraries. It&#039;s not like we can often take anything other than our programming skills themselves from job to job. This is fairly unique in the business world. Most other professions do not incur such an extreme burden on jobs. This is, I think, mainly because most of the other professions have been around for a lot longer and have standardized the way they do things to a large degree. Imagine someone coming n board and having on real expectations for a couple of months. On the Job Training at its best.


The problem that I see is that programming needs to be elevated to the same status as reading, writing, and arithmetic. It needs to be an essential skill set for anyone who uses a computer.

The reasoning behind this is the whole history of the computer world has been focused on programmers and not on the people that actually know the tasks being requested of the person programming the computer. Historically, a user goes to a programmer and asks for a program. What he gets is largely based on the communication skills of both the user and the programmer, in their ability to make sense out of two entirely unrelated languages, the language of the application, and the language of computer programming.

This was essential in the early decades of the IT world in order to build a reasonable infrastructure to move forward.

Today, we need regular knowledge workers that can build applications at least at the primitive prototype level that can be created with minimum skills and passed off to &#039;career&#039; programmers to do the major back-end and UI methods needed to make the application robust.

It becomes a numbers game; it&#039;s easier to teach everyone the fundamentals of programming than it is to teach programmers every application. Wouldn&#039;t it be nice to have a programmer come on staff that already knows how to do most things?

Thinking like a programmer is easy for some of us, impossible for others. I tend to express it more like, &#039;think like a computer&#039;. A computer is an extremely literal device and being able to think in literal terms makes programming easy. Computers see only in black or white, a good programmer does the same. The only other real skill &#039;real&#039; programmers have is that we&#039;re pretty darn good at learning things on our own. We have to be to survive in the kind of pressure cooker that is the &#039;real computer programmer&#039;.

In the end, we need two types of programmers, system programmers who have a deep understanding of the platform, and user-programmers, people who know what they want and can build a shell. The user and the programmer would be a team of sorts. 

Such a programmer could spend all of their time building and integrating libraries that the rest could use, making it more a program by numbers exercise.</description>
		<content:encoded><![CDATA[<p>I am a &#8216;career&#8217; programmer. I &#8216;ve been a professional programmer for 34 years now and in all that time, I&#8217;ve only ever run into a couple of programmers that &#8216;think like a programmer&#8217;.</p>
<p>Most programmers seldom spend more than a few years before moving into management, their original goal. unfortunately, the vast majority of these &#8216;stepping stone&#8217; programmers is that they don&#8217;t have their heart in it and subsequently never really learn enough about programming to ever become a &#8216;good&#8217; programmer. This is evident by the incredible number of bugs in their code.  One could write a book about the bad practices they employ.</p>
<p>Another problem is that every time we change jobs, we usually have to start from scratch. It takes time to learn new applications, languages, operating systems, frameworks, libraries. It&#8217;s not like we can often take anything other than our programming skills themselves from job to job. This is fairly unique in the business world. Most other professions do not incur such an extreme burden on jobs. This is, I think, mainly because most of the other professions have been around for a lot longer and have standardized the way they do things to a large degree. Imagine someone coming n board and having on real expectations for a couple of months. On the Job Training at its best.</p>
<p>The problem that I see is that programming needs to be elevated to the same status as reading, writing, and arithmetic. It needs to be an essential skill set for anyone who uses a computer.</p>
<p>The reasoning behind this is the whole history of the computer world has been focused on programmers and not on the people that actually know the tasks being requested of the person programming the computer. Historically, a user goes to a programmer and asks for a program. What he gets is largely based on the communication skills of both the user and the programmer, in their ability to make sense out of two entirely unrelated languages, the language of the application, and the language of computer programming.</p>
<p>This was essential in the early decades of the IT world in order to build a reasonable infrastructure to move forward.</p>
<p>Today, we need regular knowledge workers that can build applications at least at the primitive prototype level that can be created with minimum skills and passed off to &#8216;career&#8217; programmers to do the major back-end and UI methods needed to make the application robust.</p>
<p>It becomes a numbers game; it&#8217;s easier to teach everyone the fundamentals of programming than it is to teach programmers every application. Wouldn&#8217;t it be nice to have a programmer come on staff that already knows how to do most things?</p>
<p>Thinking like a programmer is easy for some of us, impossible for others. I tend to express it more like, &#8216;think like a computer&#8217;. A computer is an extremely literal device and being able to think in literal terms makes programming easy. Computers see only in black or white, a good programmer does the same. The only other real skill &#8216;real&#8217; programmers have is that we&#8217;re pretty darn good at learning things on our own. We have to be to survive in the kind of pressure cooker that is the &#8216;real computer programmer&#8217;.</p>
<p>In the end, we need two types of programmers, system programmers who have a deep understanding of the platform, and user-programmers, people who know what they want and can build a shell. The user and the programmer would be a team of sorts. </p>
<p>Such a programmer could spend all of their time building and integrating libraries that the rest could use, making it more a program by numbers exercise.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Val</title>
		<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/comment-page-1/#comment-134667</link>
		<dc:creator>Val</dc:creator>
		<pubDate>Sat, 24 Jan 2009 00:01:26 +0000</pubDate>
		<guid isPermaLink="false">http://infovore.org/?p=2258#comment-134667</guid>
		<description>@Jonathan: huh? Seems to me like the burden is on those whose livelihood is at risk. To be clear, that would be journalists, even the best of whom are in jeopardy from all angles, rather than programmers, who continue to be in high demand. (I&#039;ve been on both sides, working in newsrooms for ~15 years, and as a coder of some sort for ~10.)

You won&#039;t find a more ardent defender of usability and human factors in program design than myself, but that&#039;s not relevant to the issue. We&#039;re not going to see another revolution in programming paradigms in time to save modern journalism -- in fact, that revolution has already played out in the last decade or so with the rise of dynamic languages like PHP and Python. They&#039;re no walk in the park, but they&#039;re an order of magnitude easier than the languages they replace, C, C++, Java, C#, etc. Getting another order of magnitude of usability from the basic computing platform is going to take a lot of time. 

In the meantime, Tom&#039;s point is well-considered. Regardless of language or environment, computing has been and will be for some time to come inherently deterministic. So, all of Tom&#039;s advice is spot-on: try to arrange things in such a way that takes advantage of that determinism, and avoid things that obstruct it. 

That&#039;s not to say that fuzzy areas aren&#039;t important -- rather, those are areas best left to wetware (the stuff between your ears). The mundane, repetitive, rote stuff -- the stuff that makes your brain ache with boredom -- there, computers excel, and you should try to shovel as much as you can in that direction. In order to do so, you need to understand a bit about how they see the world. 

To make good use of a car, you don&#039;t have to be able to rebuild the engine -- but being conversant with how it works can help you make better decisions about how to operate it, when not to, when to look for a different approach, and even let you make minor changes quickly and cheaply without having to get outside, expensive help. 

And, yes, theoretically it should be the burden of the manufacturer to design the car so it can automatically drive you home, open the garage door and pour you a drink. But lots of other people will be driving while you wait for that to happen.

Same with computers.

If you go and report on a subject area that has a lot of data, and you have a sense of how to organize the data so they can be analyzed, summarized, visualized programatically, then you can get your story out faster, or with greater depth, or find some non-obvious aspect buried deep in the data. If you can&#039;t program it, and you make it hard for you programmer to make use of the data because you didn&#039;t heed Tom&#039;s advice, then your story will be late, or lack the depth your competition brings.

Technical people can indeed understand how non-technical people work. That&#039;s not of much use if you give them a pretty-looking but horribly-structured spreadsheet that makes sense to you but can&#039;t be programatically interrogated. They&#039;re going to have to work extra hard to make up for the things you couldn&#039;t be bothered with -- and generally on the short end of the deadline. 

Give them good stuff to begin with and you&#039;ll both succeed. Or not -- chances are there&#039;s another journo behind you who can grok what needs to be done and would be more than happy to take your place.</description>
		<content:encoded><![CDATA[<p>@Jonathan: huh? Seems to me like the burden is on those whose livelihood is at risk. To be clear, that would be journalists, even the best of whom are in jeopardy from all angles, rather than programmers, who continue to be in high demand. (I&#8217;ve been on both sides, working in newsrooms for ~15 years, and as a coder of some sort for ~10.)</p>
<p>You won&#8217;t find a more ardent defender of usability and human factors in program design than myself, but that&#8217;s not relevant to the issue. We&#8217;re not going to see another revolution in programming paradigms in time to save modern journalism &#8212; in fact, that revolution has already played out in the last decade or so with the rise of dynamic languages like PHP and Python. They&#8217;re no walk in the park, but they&#8217;re an order of magnitude easier than the languages they replace, C, C++, Java, C#, etc. Getting another order of magnitude of usability from the basic computing platform is going to take a lot of time. </p>
<p>In the meantime, Tom&#8217;s point is well-considered. Regardless of language or environment, computing has been and will be for some time to come inherently deterministic. So, all of Tom&#8217;s advice is spot-on: try to arrange things in such a way that takes advantage of that determinism, and avoid things that obstruct it. </p>
<p>That&#8217;s not to say that fuzzy areas aren&#8217;t important &#8212; rather, those are areas best left to wetware (the stuff between your ears). The mundane, repetitive, rote stuff &#8212; the stuff that makes your brain ache with boredom &#8212; there, computers excel, and you should try to shovel as much as you can in that direction. In order to do so, you need to understand a bit about how they see the world. </p>
<p>To make good use of a car, you don&#8217;t have to be able to rebuild the engine &#8212; but being conversant with how it works can help you make better decisions about how to operate it, when not to, when to look for a different approach, and even let you make minor changes quickly and cheaply without having to get outside, expensive help. </p>
<p>And, yes, theoretically it should be the burden of the manufacturer to design the car so it can automatically drive you home, open the garage door and pour you a drink. But lots of other people will be driving while you wait for that to happen.</p>
<p>Same with computers.</p>
<p>If you go and report on a subject area that has a lot of data, and you have a sense of how to organize the data so they can be analyzed, summarized, visualized programatically, then you can get your story out faster, or with greater depth, or find some non-obvious aspect buried deep in the data. If you can&#8217;t program it, and you make it hard for you programmer to make use of the data because you didn&#8217;t heed Tom&#8217;s advice, then your story will be late, or lack the depth your competition brings.</p>
<p>Technical people can indeed understand how non-technical people work. That&#8217;s not of much use if you give them a pretty-looking but horribly-structured spreadsheet that makes sense to you but can&#8217;t be programatically interrogated. They&#8217;re going to have to work extra hard to make up for the things you couldn&#8217;t be bothered with &#8212; and generally on the short end of the deadline. </p>
<p>Give them good stuff to begin with and you&#8217;ll both succeed. Or not &#8212; chances are there&#8217;s another journo behind you who can grok what needs to be done and would be more than happy to take your place.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tony Hirst</title>
		<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/comment-page-1/#comment-134655</link>
		<dc:creator>Tony Hirst</dc:creator>
		<pubDate>Fri, 23 Jan 2009 18:34:24 +0000</pubDate>
		<guid isPermaLink="false">http://infovore.org/?p=2258#comment-134655</guid>
		<description>I&#039;ve been thinking for some time about trying to run a mashup w/s for journalists using things like Yahoo pipes, Google and Zoho spreadsheets (which double up as webpage screenscrapers for lists and tables) and Google maps.

So if you can think of some example case studies of the sort of thing it might be good for a jounralist to &quot;programme&quot;, let me know, and I&#039;ll try and post some demos.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been thinking for some time about trying to run a mashup w/s for journalists using things like Yahoo pipes, Google and Zoho spreadsheets (which double up as webpage screenscrapers for lists and tables) and Google maps.</p>
<p>So if you can think of some example case studies of the sort of thing it might be good for a jounralist to &#8220;programme&#8221;, let me know, and I&#8217;ll try and post some demos.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alistair</title>
		<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/comment-page-1/#comment-134638</link>
		<dc:creator>Alistair</dc:creator>
		<pubDate>Fri, 23 Jan 2009 12:29:02 +0000</pubDate>
		<guid isPermaLink="false">http://infovore.org/?p=2258#comment-134638</guid>
		<description>A sibling suggestion would be &#039;Learn to explore inquisitively&#039;.  One of the reasons only 20% of an application&#039;s functionality is used by the majority of users is that their major motivation when they start using an application is &#039;How do I do [x] in [y]?&#039;, as opposed &#039;What [x]s can [y] do for me?&#039;  Taking a few minutes in the beginning to explore the menus and toolbars of an application - even if you understand none of it - is priceless in the longer term, as it gives you an understanding of how the application might help you solve future problems.</description>
		<content:encoded><![CDATA[<p>A sibling suggestion would be &#8216;Learn to explore inquisitively&#8217;.  One of the reasons only 20% of an application&#8217;s functionality is used by the majority of users is that their major motivation when they start using an application is &#8216;How do I do [x] in [y]?&#8217;, as opposed &#8216;What [x]s can [y] do for me?&#8217;  Taking a few minutes in the beginning to explore the menus and toolbars of an application &#8211; even if you understand none of it &#8211; is priceless in the longer term, as it gives you an understanding of how the application might help you solve future problems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ethan</title>
		<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/comment-page-1/#comment-134580</link>
		<dc:creator>Ethan</dc:creator>
		<pubDate>Thu, 22 Jan 2009 19:33:55 +0000</pubDate>
		<guid isPermaLink="false">http://infovore.org/?p=2258#comment-134580</guid>
		<description>I agree with you that we could all benefit from learning to think like a programmer. But just saying that isn&#039;t very helpful. What I need from you coders out there is to take the next step and teach me. Explain what you know, in accessible English. I&#039;d like to get handy with a shell. What is a shell? How do I get handy with it? What is the command line? What are grep, sed and awk? &quot;Not user-friendly&quot; is a tremendous understatement. It falls to you guys to make them user-friendly through humane explanation.</description>
		<content:encoded><![CDATA[<p>I agree with you that we could all benefit from learning to think like a programmer. But just saying that isn&#8217;t very helpful. What I need from you coders out there is to take the next step and teach me. Explain what you know, in accessible English. I&#8217;d like to get handy with a shell. What is a shell? How do I get handy with it? What is the command line? What are grep, sed and awk? &#8220;Not user-friendly&#8221; is a tremendous understatement. It falls to you guys to make them user-friendly through humane explanation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Hayward</title>
		<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/comment-page-1/#comment-134577</link>
		<dc:creator>Jonathan Hayward</dc:creator>
		<pubDate>Thu, 22 Jan 2009 19:00:42 +0000</pubDate>
		<guid isPermaLink="false">http://infovore.org/?p=2258#comment-134577</guid>
		<description>The burden of proof, it appears, is on the non-programmer to meet the programmer.

What if the core insight of usability is that programmers have forgotten how to think about the rest of the world? In other words, what if programmers who have not re-learned how to think like a non-programmer have trouble seeing how to view an application apart from what follows from its mechanical innards?

Usability is high ROI because good things happen when IT shifts the burden to technical people understanding how non-technical people work.

I can&#039;t deny that journalists might benefit from learning to think like a programmer, as from learning another language, or learning to think about culture like an anthropologist, or any other of a number of skills by which a journalist&#039;s vista could be expanded. But it seems strange to me to wax poetic about how much better things are for everyone involved when we shift the burden of responsibility on to journalists to think like a programmer.</description>
		<content:encoded><![CDATA[<p>The burden of proof, it appears, is on the non-programmer to meet the programmer.</p>
<p>What if the core insight of usability is that programmers have forgotten how to think about the rest of the world? In other words, what if programmers who have not re-learned how to think like a non-programmer have trouble seeing how to view an application apart from what follows from its mechanical innards?</p>
<p>Usability is high ROI because good things happen when IT shifts the burden to technical people understanding how non-technical people work.</p>
<p>I can&#8217;t deny that journalists might benefit from learning to think like a programmer, as from learning another language, or learning to think about culture like an anthropologist, or any other of a number of skills by which a journalist&#8217;s vista could be expanded. But it seems strange to me to wax poetic about how much better things are for everyone involved when we shift the burden of responsibility on to journalists to think like a programmer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Emmet Connolly</title>
		<link>http://infovore.org/archives/2009/01/22/learning-to-think-like-a-programmer/comment-page-1/#comment-134571</link>
		<dc:creator>Emmet Connolly</dc:creator>
		<pubDate>Thu, 22 Jan 2009 18:12:59 +0000</pubDate>
		<guid isPermaLink="false">http://infovore.org/?p=2258#comment-134571</guid>
		<description>Where I work we call this being lazy, and it&#039;s considered a good thing. A good programmer will never be bothered to do something manually that could be scripted in roughly the same time. If you&#039;re grafting too hard, it means there might be a smarter way of doing things. Surely the same goes for journalists. And just like a programmer, a good journalist should also be able to see things within his field that would not be doable without computers.

Also, the approach you&#039;re describing plays to professional journalism&#039;s strengths in it&#039;s rivalry with &quot;citizen&quot; journalism. Investigative work must be where it&#039;s at for real journalists from now on, but traditionally it&#039;s really time-consuming work, especially when the subjects to be interrogated are massive impenetrable things. I listened to an episode of On The Media a while ago about the financial meltdown, and the failure of journalists to pick up on anything being wrong before it was too late. Apparently one of the problems was simply that nobody had the skills to crunch the numbers, even though all the the necessary raw data was publicly available.

I think waxy.org has done some creative work that illustrates this path well: analyzing data, shelling work out to Mechanical Turk, etc.</description>
		<content:encoded><![CDATA[<p>Where I work we call this being lazy, and it&#8217;s considered a good thing. A good programmer will never be bothered to do something manually that could be scripted in roughly the same time. If you&#8217;re grafting too hard, it means there might be a smarter way of doing things. Surely the same goes for journalists. And just like a programmer, a good journalist should also be able to see things within his field that would not be doable without computers.</p>
<p>Also, the approach you&#8217;re describing plays to professional journalism&#8217;s strengths in it&#8217;s rivalry with &#8220;citizen&#8221; journalism. Investigative work must be where it&#8217;s at for real journalists from now on, but traditionally it&#8217;s really time-consuming work, especially when the subjects to be interrogated are massive impenetrable things. I listened to an episode of On The Media a while ago about the financial meltdown, and the failure of journalists to pick up on anything being wrong before it was too late. Apparently one of the problems was simply that nobody had the skills to crunch the numbers, even though all the the necessary raw data was publicly available.</p>
<p>I think waxy.org has done some creative work that illustrates this path well: analyzing data, shelling work out to Mechanical Turk, etc.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

