Udostępnij za pośrednictwem

Developer vs “the others”

  • Artykuł

[UPDATED 25th - check out https://blogs.msdn.com/ericnel/archive/2008/07/25/the-reddit-effect.aspx as well] 

Software companies have (broadly)

  • Managers
  • Marketeers
  • Sales people
  • Technical people who don’t code
  • Technical people who do code (much as you do) -  henceforth I will refer to these folks as developers. Managers, Marketeers and Sales People will be know as “the others”

What I find interesting is the dynamics of many companies and their approach to developers. The following all bother me…

  • “why can’t you just do my job as well?” – “ the others” will often try to offload some of their role/tasks onto a developer.
    • Interestingly I have never seen a developer ask “the others” to write 50 lines of C++ before the end of the day. Hmmmm…
  • “why don’t you understand?” – “the others” will get frustrated that a developer does not understand the “bigger picture”, the “end goal”, the “spreadsheet of numbers that proves it”.
    • Interestingly I have never seen a developer get frustrated with “the others” when they don’t understand generics, delegates or JIT compilation. Hmmmm…
  • “why don’t you agree?” - “the others” will get frustrated that a developer does not agree when they present a reason for the developer to do something – admittedly based on pretty much no facts, hearsay or a whim.
    • Interestingly developers also get very frustrated with “the others” when they do not agree – although typically the developer will have a huge bunch of facts that prove why they are correct. Hmmm….
  • “why do you need it?” - “the others” get confused that a developer needs 2 screens or a fast machine or a technical book or wishes to attend some training. By default “the others” prefer to resist any such extravagance.
    • Interestingly a developer never gets asked if “the others” should attend conferences, take customers on expensive hospitality trips, huddle up together in offsite planning sessions or get the latest tiny notebook or phone. Hmmmm…

Underlying this is the simple truth

  • A developer can do the job of “the others” – maybe (and often) not very well, but they can do it.
  • “the others” can not do the job of a developer – not even badly.

I spotted Mike T had posted something similar – and Joel gives a good insight into how to make a developer feel valued.

Comments

  • Anonymous
    July 23, 2008
    You missed out a couple <b>My bother/friend/lover/ works in IT:</b> You are then given a second hand rant on how you are not doing your job right and how you should being doing this or that. <b>Is there someone else I can ask?</b> What you just told them was not good enough and they're now looking for a real expert; you're not a real expert it seems.

  • Anonymous
    July 23, 2008
    PingBack from http://blog.a-foton.ru/2008/07/developer-vs-%e2%80%9cthe-others%e2%80%9d/

  • Anonymous
    July 23, 2008
    Never mind the brother/friend/lover...   what about the bloke I met in the pub last night, he reckons... Of course this bloke who is a plumber evidently knows more than me about IT. And how about the manager who does not want to know the detail because he does not understand all that "geeky" stuff then immediately gets interested in the fine detail when you tell him something he does not want to hear.

  • Anonymous
    July 24, 2008
    > “the others” can not do the job of a developer – not even badly. Yes they can. SQL, VB, insanely complex Excel files. Where I work we are constantly fighting with "the others" to get them to stop trying to do it themselves and stay out of our systems.

  • Anonymous
    July 24, 2008
    My favorite trick that the others will pull on you is to question your estimates, and ask why something can't be done sooner.   I always tell people:  sure, I can change an estimate, but that won't change the time it takes me to complete the work.  

  • Anonymous
    July 24, 2008
    You guys should look for a different company. Where I work, developers are "highest" in rank... the other roles do everything to support development. Managers and project leads make sure developers can develop as much as possible and that they dont have to pick up the phone, write manuals, run some dailly sql script, etc... Those things can be done by "anyone".

  • Anonymous
    July 24, 2008
    And and engineer can do it all.

  • Anonymous
    July 24, 2008
    That's why, probably, most of the successful start ups are done by developer. At start-up, when everyone does everything, the coder takes on other tasks, who takes on coding?

  • Anonymous
    July 24, 2008
    Quite an ego you have. Maybe in a few years you will understand why you're wrong.

  • Anonymous
    July 24, 2008
    Ahhhh..... I wondered why this post was getting so much interest. I see it ended up over on reddit http://www.reddit.com/r/programming/comments/6taan/developer_vs_the_others/ A couple of folks on there thought I somehow meant users when I referred to "the others". Nope - absolutely not. The focus here is about the internal relationship within companies I meet and work with. I feel sorry for many of the developers I meet. They are not valued. They are not supported. They are not given the resources they need to get the job done. They are hired because of their code skills and then asked to be accountants, admins or presenters. Its a blooming shame.

  • Anonymous
    July 24, 2008
    Yesterday I posted on Developer vs “the others” .I started to notice lots of comments coming in and then

  • Anonymous
    July 24, 2008
    Hi Eric I agree with what you say here, and there are many frustrating hours spent where 'management knows best'. I'd humby suggest that the way forward would be more concrete definition and mapping of requirements. That way, agreement is reached between developer and manager, and any changes can be quantified in terms of numbers (which even managers understand!). The difficulty these days is that many projects feel that agile development precludes definition of requirements, which is nonsense because Agile was developed only for the purpose of managing requirements. More detail is here: http://blog.searyblog.com/blog/_archives/2008/7/25/3809348.html and some discussion about misconception of Agile with regard to requirements is here: http://blog.searyblog.com/blog/_archives/2007/7/17/3100634.html

  • Anonymous
    July 24, 2008
    The comment has been removed

  • Anonymous
    July 25, 2008
    In case you've somehow missed this: "Sales Guy vs Web Dude" http://www.thewebsiteisdown.com/ ;)