Why are you coding?
There is a good article here about the need to explain why you are coding. I've often found that with most projects or tasks people are reluctant to give you the high level picture - it wastes too much time and, "you don't need to know".
It reminded me of several situations where someone comes to me and says - "I want you to write a program that does this...". I say "sure", expecting that they have done the due diligence and arrived at the conclusion that this is the correct thing to do. (I've even had my knuckles wrapped several times for second-guessing these requests).
So, you proceed with development and somewhere along the line (at the watercooler, elevator or kitchen) you mention what you are doing, and they hit you with "There's no need to do that because system XYZ is being replaced with ABC" or some other equally jaw-dropping statement.
I like to know the bigger picture of where a piece of work fits in, because then I can do a much better job. After all, I'm not just a monkey. And it's not my job to just code. I am supposed to be building solutions. And without the bigger picture this is a lot harder.
Note: I am a advocate for 'project induction' where new team members are taken aside and explained how everything fits together, and how they fit in to the picture. For programmers, this is a technical session (NOT an HR or project management session) and should be run by the architects of the system. This is a good way to discover the talents of your team, and to make them feel involved. I've not had much buy-in though, anyone out there seen it being done effectively?
It reminded me of several situations where someone comes to me and says - "I want you to write a program that does this...". I say "sure", expecting that they have done the due diligence and arrived at the conclusion that this is the correct thing to do. (I've even had my knuckles wrapped several times for second-guessing these requests).
So, you proceed with development and somewhere along the line (at the watercooler, elevator or kitchen) you mention what you are doing, and they hit you with "There's no need to do that because system XYZ is being replaced with ABC" or some other equally jaw-dropping statement.
I like to know the bigger picture of where a piece of work fits in, because then I can do a much better job. After all, I'm not just a monkey. And it's not my job to just code. I am supposed to be building solutions. And without the bigger picture this is a lot harder.
Note: I am a advocate for 'project induction' where new team members are taken aside and explained how everything fits together, and how they fit in to the picture. For programmers, this is a technical session (NOT an HR or project management session) and should be run by the architects of the system. This is a good way to discover the talents of your team, and to make them feel involved. I've not had much buy-in though, anyone out there seen it being done effectively?