This has been a crazy week. I’m tech leading a huge project with a crazy hard deadline, and to be perfectly honest, most of the stuff I’ve tech lead, while large projects, have had fairly small teams and dealt with systems I knew inside and out (it was all in the AOL Search days). This is a pretty large team, and we have to deal with systems I’ve never even heard of before. What does all this mean? It means that I haven’t worked less than a 12 hour day this week, and one day, I actually worked a 20 hour day.\
In the midst of the 20 hour day, I realized that we have a bunch of new folks on the team, and I came up with a list of some of the hard non-technical lessons it took failing a couple (OK, several) times to learn. These are painful lessons, and I figured I would do my best to save them the trouble. The whole e-mail got a little maudlin at the end (I think I sent it in hour 18 of the 20 hour marathon), but I figured the list might be worth sharing with the world. Enjoy. I’d love to hear your tips for surviving in development (web or otherwise) too, because I know this isn’t all of them.
- If the process is slowing you down and isn’t helping you, throw it out. (one small condition here… under normal circumstances, reasonable process is a good thing. under a crunch, process should be curtailed where possible)
- If you’re stuck, scream until someone comes to help. And if that person can’t help you, scream until you get the help you need.
- If you get stuck, start screaming early. We don’t have time to spin our wheels. It’s most likely not your fault that you’re stuck. Asking questions earlier is better than asking questions after it’s already too late. Also, ask questions until it makes sense. If you don’t get it, it’s probably because the person explaining is doing something wrong. Make them explain it till they get it right.
- If you don’t know, don’t guess. Disinformation is poison, and confusion leads to bad decisions. There’s nothing wrong with telling someone that you’ll get back to them when you know the answer.
- If you commit to a date, don’t miss it. If you think you might miss it, tell everyone and tell them as soon as you think you’ll miss the date.
- Over-communicate. I’d rather get more mail and know what’s going on with everything than have no idea and have to track people down. Scrum is a good start… oh yeah… think about what you’re going to say at scrum before you get there. Write it down and bring it with you, and then take notes if you think of something else.
- Get out of your chair and go talk to people, or pick up the phone. E-mail and IM are great, but you can resolve stuff face to face faster, even if you’re shy.\
I know, you’d think that this stuff is pretty self-evident – but it’s not. Geeks are proud. We don’t like admitting we don’t know the answers, and most of us don’t like asking for help. If you have a geek in your life, you know this. It’s something we have to get over. It takes time – be patient with us.\
Got more? What else belongs on the list?
+ Question authority. Don’t assume your boss/lead/manager always knows the best way. If you have a better idea, speak up. But don’t take it personally if your idea isn’t used.
+ Don’t start until you understand how your task/role/code fits in the big picture. All too often, I have seen developers build something that isn’t quite right because they didn’t make the effort to understand the world around them.
+ Your code is broken until proven working. Don’t submit untested code even when you are in a hurry. It will slow down QA, who has to find and document your bug. It slows you down because you have to go through your bug reports, open your code, remember what is going on in there, fix the bug, test the bug, and resubmit your code. It will make your project later than if you had taken the time to do it right the first time. If you need more time, talk to your boss/lead/manager.
P.S. submitting bugs is bad for your reputation too.
BTW – great post, Kevin.
“P.S. submitting bugs is bad for your reputation too.”
I think you mean, getting bugs submitted against your code is bad for your reputation, right?
I think finding bugs is good for your reputation, especially when you find the super-secret edge cases.
Point 1 could be shortened to – Process is not an excuse.
Point 2.5. Getting stuck doesn’t mean you stop. Sometimes you are the first to discover a problem – innovate, explore, try!
Point 6, I retch every time I hear “scrum” or “agile” proposed as a solution to poor product management or shortsighted resource management. Good software development is not defined by following a process and we are not all Google.
Point 6.5. Use multiple forms of communication.
I like Alan’s comments too. I would add to the first one that at some point you are part of the team or working against it.
“I think you mean, getting bugs submitted against your code is bad for your reputation, right?”
Yes, of course. 🙂
Comments are closed.