Jonathan's profileJonathan Chayce Dickinso...Blog Tools Help

Blog


    20 February

    Developer Vision

    One of the things I have started seeing in the industry is the importance of developer vision. You actually get to factors influencing developer vision: the actual developer's vision and the box that you place them in.

    Developer Vision

    I have started noticing that some developers write much better code than others. There are several influencing factors but the most important one is pride. I am proud of my code, 'ugly' code (read Hungarian notation) annoys the hell out of me because it just shows lack of commitment to the public interface. If a developer can't take the time to try and understand code they should seek another job or hobby.

    Which brings me to my second point: public interface. You could write code that would take other developers (and potentially yourself) a very long time to program against, or you could bite the bullet and make a masterpiece in the first place. It will save you time down the line and you may find that you can reuse your code.

    But that isn't really the point of this article. The point is that some developers can just see further than others, one developer may go and write the code as per the spec, and the next will write it as per the spec with neat extras. They may even sit at home late at night and code you your next big thing.

    Boxes

    Put a developer in a box and they will never be able to write you something new, something that you never even conceived. Developers have a vast amount of knowledge about the power and capability of the systems that they use: much more than any technical writer, manager or customer. They can solve all your problems: if you only allow them to.

    I am fortunate that the company I work for supports innovation: and I have seen some amazing stuff come from the developers here (especially one in particular who really knows about the larger picture). We are treated well and rewarded for our efforts.

    Software Lifecycle

    Currently the general layout of the software cycle dictates that you first spec the product and then write the code. This is very well intentioned and is meant to keep everyone happy. Why not try this for your next product: tell the developers what you want, let them go off and see what they come up with, write the spec and then write the final code. You may just find you get more than you expect, and has stuff you never knew you needed.