Artist or Scientist?

  • Comments posted to this topic are about the item Artist or Scientist?

  • Whilst I imagine that most of us are not all one or the other, I find that like most I fit more into one category than the other. I am a scientist.

    Over my time programming some people have derided me for taking the fun out of programming by expecting, nay, demanding that tests be written, that comments are made appropriately, that documentation is completed, that builds are not broken, that scripts are treated as code (commented, documented, tested, source controlled). I have a different perspective.

    If we behave as scientists then that allows us room for flare, innovation and, yes, artistry. I imagine that this is exactly the same in other scientific fields as well. By following best practices and standards we allow our mental focus to shift to the challenges which fall outside of "the norm".

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I probably count as both, too, but the distinction with me is that I'll take the "artist" approach for something that I know will only happen a few times--the extra effort of writing the automation doesn't make sense for something that isn't often going to be automated, IMHO!

  • paul.knibbs (8/19/2014)


    I probably count as both, too, but the distinction with me is that I'll take the "artist" approach for something that I know will only happen a few times--the extra effort of writing the automation doesn't make sense for something that isn't often going to be automated, IMHO!

    Makes total sense.

    Experience can indicate when a "one off" will likely become a BAU (Business As Usual) process. We can all make the wrong call and it will happen at times. There must be a recognition, if only internally, that if we cater for BAU that remains a "one off" then we may have wasted effort and if the "one off" becomes BAU then we risk the outcome of technical debt.

    As with most things, it depends.

    Make the call. Deal with the consequences. Move on.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Makes total sense, but I don't visit SSC to be told what I must or must not do. Maybe I'm having a bad day 😎

  • david.wright-948385 (8/19/2014)


    Makes total sense, but I don't visit SSC to be told what I must or must not do. Maybe I'm having a bad day 😎

    Surely advocating something as best practice only makes sense said with a voice of authority. It is up to us as fellow professionals to debate openly, honestly and with confidence. You can treat it as a lecture or just as viewpoint to be debated.

    I hope that your day improves!!! :Whistling:

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I agree with Steve although I would the subject into different words.

    Scientists build maintainable code and do not incorporate the latest technology without considering the ramifications. I know an architect who incorporated Linq to SQL in an enterprise application while Linq was in Beta. When Linq went RTM it had a different set of behaviors than in Beta and the enterprise application blew up.

    Scientists also build secure applications. If security considerations are not foremost in your design of application software regardless of the stated specifications you are asking for trouble.

    My next statement is probably going to get me into trouble. Agile programming is a function of artistry. There is no fixed deadline, no defined specifications, no defined architecture and little consideration for documentation.

    In my mind the only place for artistry is in the prototyping of a solution that will ultimately be documented and thoroughly tested.

  • In my humble opinion the behavior you expect is more like an engineer than a scientist. The latter might be involved in some innovative research project or the exploration of yet unknown possibilities of some new technology. The former works along the lines of standards and best practices to build something that is reliable, maintainable and has predictable behavior in nearly every environment.

    The science behind databases has mostly been developed by mathematics. While I think it is necessary to understand the theory behind the tools you are working with on a daily basis, one does not need to be a scientist to maintain a production environment. Both the artist and the scientist should work in a development environment; even the 'art' of performance tuning should not be conducted within a production environment. As usual, it depends ... in smaller organizations resources may be scarce and the artist, scientist and engineer may be the same person.

    Working as an engineer pays of when your work has to last for a long time and people are willing to pay for all the extra time involved in this approach. In every day life that might not be the case: things must be adapted fast to new technology and new demands of clients at the lowest possible costs. That's the hardest task today in guarding your production environment like an engineer ... convincing your boss.

  • eric.notheisen (8/19/2014)


    ...

    My next statement is probably going to get me into trouble. Agile programming is a function of artistry. There is no fixed deadline, no defined specifications, no defined architecture and little consideration for documentation.

    ...

    That is how NOT to do Agile. This is what a lot of people believe (including many practitioners). When you hear a so-called Agile expert saying that the code is all the documentation you need then please show them the door (without payment).

    BTW Eric my ire is not aimed at you at all!!! 🙂

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • crussell-931424 (8/19/2014)


    What drives me crazy are the programmers that always seem to want to make the code better, improve it, optimize it, when it is running just fine now. I say leave well enough alone. There is plenty of other work to do. If it isn't broke, don't fix it, because when they do fix it they invariably break something. There is usually some obscure logic, written poorly perhaps, that they miss and don't put into their rewritten version.

    I agree. It is amazing how many of these "better" rewrites neglect logging, security, documentation, instrumentation, etc. Like performance improvements, how do they measure the "betterness" (sic)?

    Of course, it is far less glamourous to add logging to existing code or just documenting it. That is if coding can ever truly be called glamourous!!!

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I use a Scientest/Engineer comparison. Scientests are the ones who experiment. Engineers are the ones who implement a scientest's discovery. Scientests are paid to create new things. Engineers are paid to keep things working.

  • I think you need to leave art out of it. Having undergone the rigors of an art major, one thing was made very clear to me by my professors, be consistent. All, and I mean all, the work you produce must meet standards. To reach that level of accomplishment takes discipline and, believe it or not, accuracy. Some of the best work comes by working within very strict rules, like writing in iambic pentameter or composing a minuet. For me, following various standards in programming is similar.

    It's not the artistic nature of people that leads to poor application development. It's just simple ignorance or lack of experience, maybe indifference.

  • astone-1154729 (8/19/2014)


    I think you need to leave art out of it. Having undergone the rigors of an art major, one thing was made very clear to me by my professors, be consistent. All, and I mean all, the work you produce must meet standards. To reach that level of accomplishment takes discipline and, believe it or not, accuracy. Some of the best work comes by working within very strict rules, like writing in iambic pentameter or composing a minuet. For me, following various standards in programming is similar.

    It's not the artistic nature of people that leads to poor application development. It's just simple ignorance or lack of experience, maybe indifference.

    Fair enough. Perhaps craft instead of art? Some might also be tempted to say it is not the artistry but the laziness.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (8/19/2014)Perhaps craft instead of art? Some might also be tempted to say it is not the artistry but the laziness.

    Except it could be argued that the person who sits down and writes the code is the lazy one, because they're attempting to make their job easier in the future. 🙂

  • Thanks for the thought-provoking article Steve.

    Hakim Ali
    www.sqlzen.com

Viewing 15 posts - 1 through 15 (of 39 total)

You must be logged in to reply to this topic. Login to reply