As many people out there that have fun in their jobs, I really love helping people. I do my best to get done what needs to be done to make sure someone gets what they need.
That said; As someone in the IT industry, I’m trusted with one of the most complex pieces of work out there. I don’t always know everything, hell, in most cases, I don’t, and I have to look it up. And that can get in your way when someone asks something from you, or a manager wants to know where you are at in your current assignment.
Taking on the perspective of a programmer, developing a new piece of software is a great way to help people out. However, since I don’t know everything, it isn’t always easy to say how or when something’s gonna get done.
I came across a great analogy to the software development process today, here’s the quote:
I assume you know how to put together a jigsaw puzzle, for nearly any 3 year old can put together the most basic ones.
So let me ask you a question. If I went out and bought 5 jigsaw puzzles, each with say 2,500 interlocking pieces, how long would it take you to put together anyone of them?
Can you tell me within 25% of the actual time how long it will take you? After all, you DO know how to put together a puzzle, right? And it you can do that, can you tell me what day you’ll have all 5 of them finished?
I want to know! And can you have your reply ready for me by 3pm today?
This is exactly why it’s very important to tell the person who’s asking that you simply don’t know how long it’ll take if you don’t know. Give them the information you do know, write down what you’re going to do in steps, so you can at least give them an indication of where you’re at in the development process, and still be honest about it.
The more strictly you keep yourself to a protocol when working on something that complex, the more predictable and honest you can be about the dev process to your colleagues, superiors, and so forth. They want a change? Make a ticket, don’t just slap it in there, because do you really know how much time it’s gonna add? Don’t just start coding from the moment you have the idea, either. Write down what it’s going to do, then worry about the technical part, because if you don’t, feature creep is right around the corner.
In the end, all that the people care about is that it gets done within the deadline. If you’re honest with the people you work with, you allow them to help you out just as much as you can help them out. Your job isn’t to predict the future, it’s to write code! So keep yourself to your scope 🙂