Re: You’re not your code

This post is a reply to Scott Hanselman’s post: "You’re not your code"

There are no two programmers in the world who like each others code, there's always criticism: "I would have done this differently" or worse "Whoa, dude, never heard of SOLID? Where are the tests for this?". IMHO, criticism is OK, as long as it's based on well founded arguments and they make the original programmer of the criticized code learn new things. I don't think Scott's post is about that.

I think Scott refers to this: simply bitching about someone else's code because you'd have implemented the same program much better, as you see yourself as a great developer is stupid.

I'd like to make an addition to that: if you think you're a great developer and express yourself in that fashion, and your professional code is not code one can expect from a professional (i.e. code which is maintainable, without (most of the) bugs, it's well documented etc.), you're a fraud and it's a little bit different: you tried to sell the idea that your hack, your hobby code is professional code. 

However, not all code is professional code. Sometimes we simply hack something together to make something happen 1 time, or only for a single user (ourselves). For example internally here I use a change log system in where I log changes made to the various parts of the tools we produce. This is a very rudimentary piece of software, with a tremendously ugly UI, buggy event handlers and the databinding sometimes gets confused. This is because I wrote it in one afternoon, no tests, no design thoughts, just started hammering in code and when it compiled without errors I said "Done!".

But it works, it gets the job done of what I want to do: log the change made into a database so I can sync it with the online change log on our website so users can browse the change log online. Every time I run into a bug (which isn't often, as I know what to click and do) in this marvelous piece of code (ahum) I say to myself "it might be better if I fix this some day", but as the only time I use this software is when I have to do a push of a new build, this 'some day' is not today.

If this software would ever be released somewhere in source-code form, it will likely be bashed to pieces. If I would release it as source-code with the remark 'great system to log your changes and sync with online database', the bashing would IMHO be justified. But as it's a tool which is only for myself, and if I would release it as 'Dunno if this helps anyone, it works for me, have fun' and a bigwig would bash it to pieces because he's holier than me, that bashing IMHO wouldn't be justified: it's a hack, not professional software.

Bashing a hack released as a hack is stupid. Bashing a hack released as professional code isn't, as it exposes the hack as what it truly is: a hack.

Question of course is: when is a piece of code a hack / hobby code and when does it become professional code? IMHO the variety of answers to that question will tell you why the bashing of other people's code will continue no matter what and why there will never be two programmers in the world who like each others code without criticism.

Though we can do something. As it's difficult to determine when a piece of software is a hack if it's not described as such (not by one person but as a general qualification: if piece of software A is declared a hack, everyone will agree it is in fact crap), we as developers could keep that in mind when we use our bash-hammer on some piece of code we found online somewhere: what is truly gained from our criticism? Will the world be a better place? Will the software magically become better? Or is it just about our own ego that by declaring piece of software A a true example of crapcode, our own code must be much better?

The main reason we have to take that in mind is because we are our code. Well, not entirely, but we did write it. An outsider won't know whether we poured our soul into it and that we invested precious time in it. Bashing it to pieces because the fruits of our hard work is seen as a hack while it's not is going to hurt. If it doesn't hurt, you're not caring enough about the quality of your work, or they might have been right: your work was a hack after all, it didn't exceed the hobby code bar.

1 Comment

  • I try and leave code that has robust error handling, decent performance and easy to read as someone else will inevitably pick it up and change it....sadly that doesn't seem to happen that often.

    Have to maintain a piece of software that has stuff like this all to often:

    Public Sub HandleException(ByRef EX As System.Exception, ByVal Horrible As Boolean)
    My.Application.Log.WriteException(EX)
    MessageUser(EX, Horrible)
    End Sub

    MessageUser calls the variable Critical rather than Horrible.

    The horrible variable sums it up :)

    People will always find fault, when it begins to cause serious problems to maintain and debug I think the criticism is justified.

Comments have been disabled for this content.