{"id":16,"date":"2005-11-01T22:52:00","date_gmt":"2005-11-02T03:52:00","guid":{"rendered":"http:\/\/www.toomik.net\/helen\/wordpress\/?p=16"},"modified":"2005-11-01T22:52:00","modified_gmt":"2005-11-02T03:52:00","slug":"good-programmers-think-differently","status":"publish","type":"post","link":"https:\/\/www.toomik.net\/helen\/blog\/2005\/11\/01\/good-programmers-think-differently\/","title":{"rendered":"(Good) programmers think differently"},"content":{"rendered":"

\nMy job description doesn’t say (that is, if I actually had a job description then it wouldn’t say) a word about software development. It would probably say a fair bit about modelling, data management and data analysis, though. And once those pass a certain level in terms of complexity, you really end up in the realm of programming anyway. So while Excel is the main tool for me and my colleagues, we spend a fair amount of our time developing small applications in VBA, using VBA to augment our Excel models, and now also coding in SAS<\/a>.\n<\/p>\n

\nBut we’re not programmers. And that shows.\n<\/p>\n

\nIn my case, programming has been my main hobby for the past 2 years or so, so I consider myself fairly proficient. I don’t have the level of experience that a professional developer does, but I have come to think like a developer. The other two “modellers” in our group don’t. They are very intelligent people, but when it comes to programming, they just don’t think the right way. In fact I think their general intelligence is making the problem worse, because it makes them too confident: they assume<\/b> that they know what they’re doing.\n<\/p>\n

\nCase in point:
\nThis past Friday, I found a small but very important bug in code that colleague A had written, in a project that we are working on together. A number had been hard-coded as a constant, and in order to get the right results, that number needs to be changed manually once a month. Turns out that this number had been off by one for the last 3 months. And the output from this model is used to make million-dollar decisions.\n<\/p>\n

\n(To make things more interesting, colleague A happened to be travelling on Friday, so I couldn’t take this up with him, but had take this directly to our manager, because he was about to use the output. The rest of the day was spent in a state of moderate panic, estimating the effects of the bug, and trying to minimise the effects.)\n<\/p>\n

\nThe bug was in no way subtle or hard to find. The report output wasn’t behaving the way I expected, and once I’d noticed that, it took less than 10 minutes to find the error.\n<\/p>\n

\nHard-coding a number that needs to change is dangerous and stupid in itself. But I think it’s only a symptom of a larger problem.
\nThis really comes down to looking at code with the right mindset – and a big part of “right” is “defensive”.\n<\/p>\n

    \n

    \n1) Don’t assume that your code is correct.<\/b>\n<\/p>\n

    \nThe starting point should be that your code may be broken. Even if it runs, assume that it is not doing the right thing.\n<\/p>\n

    \nEvery time I finish a piece of code, I ask myself – where could this go wrong? How might this output, which looks OK at first glance, be wrong? How can I check it? In the case of financial models, I usually track at least one data point in each result set all the way back to the input data, manually, using pen and paper and a calculator.\n<\/p>\n

    \nColleague A would have found the problem if he had looked, but he didn’t – because he assumed that if it doesn’t look obviously wrong, it must be right. (It’s not the first time I find such problems in his work, either.)\n<\/p>\n

    \nIt helps that I know what can go wrong. I know to look for edge cases, off-by-one errors, misaligned data, mismatched units \/ currencies. But these are less obvious to those who have little programming experience.\n<\/p>\n<\/ol>\n

      \n

      \n2) Failures should be visible.<\/b>\n<\/p>\n

      \nChecks and double-checks and triple-checks. In environments that support it, tests and checks should be automatic. If there are two routes that should get you to the same point, take both and show both results. If there are conditions that the results should satisfy, those should be checked automatically, and very loud bells should start ringing if they don’t match.
      \n
      \nProduce far more output than needed. Display your assumptions, and save intermediate results. Show inputs side by side with the output.\n<\/p>\n

      \nIn this case, showing the key inputs would have made the problem very visible and we’d have discovered it immediately.\n<\/p>\n<\/ol>\n

      \nAll of this doesn’t mean that my code is bug-free. It will never be. But it will have fewer bugs than code written by someone who doesn’t approach things this way.\n<\/p>\n

      \nThings will improve as my colleagues gain experience – but in the meantime, mistakes like this might cost us a lot of money. So I think I need to start taking more responsibility for what they do in their code.\n<\/p>\n

      \nThe question is, how? How do you teach someone to think the right way – especially if they don’t even think of their job as programming?\n<\/p>\n

      \n“Leading by example” will help somewhat, but so much of this is quiet and invisible… It’s hard to make my assumptions visible. Thinking out loud while discussing our code (his and mine) might be one way. Politely adding checks and balances to the parts of his code that I review is another. But it doesn’t seem quite sufficient.\n<\/p>\n

      \nAnd that’s assuming that this is even “learnable” – which it might not be, it might just be a more general mindset that you either have and value, or don’t…<\/p>\n","protected":false},"excerpt":{"rendered":"

      Programming has been my main hobby for the past 2 years or so, so I have come to think like a developer. The other two “modellers” in our group don’t. They are very intelligent people, but when it comes to programming, they just don’t think the right way.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"class_list":["post-16","post","type-post","status-publish","format-standard","hentry","category-geeky_things"],"_links":{"self":[{"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/posts\/16","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/comments?post=16"}],"version-history":[{"count":0,"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/posts\/16\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/media?parent=16"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/categories?post=16"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.toomik.net\/helen\/blog\/wp-json\/wp\/v2\/tags?post=16"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}