2 Responses

  1. Lis
    Lis at |

    Great feedback indeed. Definitely some interesting views that you touch on. I love the dichotomy you mention between the two. This gives me some great information to reflect on.
    Thanks Chris!

    Reply
  2. Chris Murphy
    Chris Murphy at |

    I’ve had the benefit of working with, training, and being trained by many developers over the course of my career as a designer/developer — I can honestly say that I have met some of the best and worst developers out there.

    There are two types of developers in my opinion: good devs, and lazy devs.

    Developers in the first category invest themselves in the conceptualization of a solution; plan their efforts complimentary to the strategy; and execute the final product as efficiently as time and budget allow — even going a few steps further to future proof or optimize their work. That is a mark of an excellent developer.

    On the other hand, developers who fall into the second category tend not to contribute to the solution; tend to assume they already know the solution to the problem before hand, and dismiss the concepts/fundamentals of the project out of hand; and execute their personal vision of the solution independently (and often poorly). These are the characteristics of a developer who prefers to be a roadblock to successful project.

    The most effective means to differentiate good from lazy is in how the developer(s) in question handle change (which is indicative of their investment in the project).

    Let’s face it, change is work — especially in the middle of a project, and it affects everyone involved to some degree (some more so than others); however, change can be a good thing. Where developers are concerned, change can mean the difference between creating a solution that is more efficient and ultimately reduces later work, or it can result in more work depending on how invested the developer is in the approach.

    If you’re dealing with the latter of the two types, you may find a high level of resistance to change. It either means that the developer has created a solution to the problem independent of the strategy (roughly translated: “my way is the right way…”), and any changes render their solution obsolete; or it could mean that they simply don’t have the desire to invest time into an effective/efficient solution (roughly translated: “don’t make me work…”).

    The bottom line here is that if your developer “hates” you, it is either because they haven’t been invested in the conceptualization of a solution, or that they don’t care to be invested in the solution.
    As for myself, I would rather work with a developer who wants to be invested in a solution, than one who I have to lose sleep over.

    Reply

Leave a Reply

nineteen − ten =