May 24, 2016

Reaching the Next Level

When a new programmer starts writing code, s/he requires detailed specifications and clear requirements. The understanding is on a level "I need to get this piece of code working". There's not very much thought given on what happens outside this routine or how things are connected.


On the next level, the coder understands that the piece of code s/he's writing is a piece of a larger system. This system exists for some purpose, but the purpose isn't necessarily clear for the person. But generally s/he understands the system is important for the company and probably generates financial benefits (i.e. is sold).


Reaching the next level is already quite challenging. At this point the developer starts to think about the customers' business. How do the customers make their money? (...that can be then invested. Maybe in software. Maybe even on the solution you are developing...) And when you understand how the customers make money, you understand their priorities and needs. What is important for them and critical for their business.


There might be intermediate levels between the ones I mentioned, but I think this covers the basic steps. I'd encourage all developers to try to advance on these steps. The higher you are, the better you can fill your customers' needs and thus the more valuable you become. I'm not saying that code writing is easy. I'm simply saying that being able to write code AND understand the business is a tad harder and rare. Development on this path starts from understanding the user. 


(Sometimes the decision maker for software purchase is not the same as the user. Users might be only influencers in a complex network. But let's leave this out of scope for now. )

2 comments:

  1. The steps you write about describe one dimension of progress. Another possible and important dimension of progress for the developer is more technical: the dimension of code and architectural understanding and quality. In this dimension the starting level is also represented simply "I need to get this working" but the things that are lacking are different: understanding of the architectural context, desire and skills to avoid code duplication and clarity and robustness of resulting implementation. Further steps in this "code quality" dimension increase tremendously the long-term productivity of the developer by allowing him to make his changes in a away that improve robustness, simplicity and clarity of the codebase. This all can happen with or without increased understanding of customer needs and business and is rather independent from such development. There are probably even more dimensions in which developer can progress to be more valuable, for example related to skills and sttitude regarding automated testing.

    ReplyDelete
    Replies
    1. Thanks for the comment Robert. Sometimes I try to be intentionally a bit provocative. It's surprisingly difficult to create any kind of dialog.
      But I admit that in this case it was just one dimensional. And of course my posts are mostly subjective and biased, because they reflect my own view without taking too much into account other alternatives. I guess they can be considered more as stories than scientific analysis. ;)

      Delete