The biggest mistake I've seen people make when taking a new software development job is to stay quiet when they really should be asking a ton of questions. This applies to people fresh out of college just as much as it does to people with decades of experience.
Many companies like to give their new developers some kind of maintenance task -- perhaps cleaning up some code, or adding a relatively small feature to an existing code base. This gives the new person the chance to get familiar with the existing code and development practices, without risking any of the more important projects.
When this happens, some people (especially people with very little experience) think that their goal should be to produce bug-free code while asking as for as little help as possible. I think this is a bad habit that many people develop while in school. Maybe you think that by not asking questions, you're giving the impression that you're already competent at this. Maybe you think that the people with more experience than you are working on more important tasks, and you don't want to bother them or waste their time.
That's not the way it works in industry. We expect people to work together to get stuff done quickly. In school if you tried to help someone, it was usually called "cheating". In industry, it's called being a good member of the team.
When you get a new job in industry, you're working with some of the people who invented the system you're working on. Each software system is unique, and you aren't expected to already be familiar with it. There isn't a structured curriculum designed to help you learn it in an efficient way. Usually the best way to prove you're a kick-ass developer is to ask as many questions as you need in order to get your task done as quickly as possible, with a reasonably low bug count.
Don't worry about annoying people. Sure, sometimes someone will have bad days and they'll snap at you. But most of the time they won't, and even if they do, they usually won't think anything of it the next day.
Don't think you're wasting people's time. Don't think they have better, more important things to be doing. The reason they hired you is to train you to the point where you can help them get their job done -- or maybe take over some of the tasks that they're no longer interested in doing. In order for that to happen, you need to learn as fast as you can. By asking them questions, you are helping them be more productive in the long run -- and they know it.
Don't try to produce absolutely bug-free code before sharing it with anyone. The fact that you're unfamiliar with the bigger picture means that you'll probably get something wrong that you would never realize until someone else pointed it out. Do keep your code neat and tidy at all times (if you have to clean it up before you feel comfortable sharing it, that's not good), but don't worry about getting it perfect.
Finally, a warning. If you don't work closely with people at the beginning, it will either slow you down, or cause you to build something that isn't quite what people wanted. And if that happens, then people will start underestimating your abilities. You'll be given boring tasks that are irrelevant to the success of the company. You won't be invited to meetings where the future of the product is discussed. Your opinion about how to design things will be discounted. If you allow people's impression of you sink to this level, the easiest solution is to leave for a different company, and hope you don't repeat the experience.
So go ahead and be a pest. Your coworkers will appreciate it after a few short months. Just be sure to never ask the same question twice.
Posted on August 27, 2006 08:33 PM
More management articles
Why not use pair programming? Wouldn't that make this explicit?
Posted by: Shae Erisson at August 28, 2006 04:13 AMI think that "asking questions" is a large part of the _teacher's_ responsibility as well. In school, the teacher pushes out the information and hopes the student catches on; if not, oh well, it is the student's money being wasted. However, just like the student's role changes when moving to industry, so does the teacher's. It is the teacher's _responsibility_ to ensure that the student is progressing. Otherwise, it is the _company's_ money being wasted. Both the student and the teacher need to take on new responsibilities once school is past.
Posted by: Tanton Gibbs at August 28, 2006 09:15 AMShae, that's a very good suggestion. Unfortunately I've never worked anywhere where pair programming was the norm. Have you?
Tanton, I agree that it's the responsibility of the mentor to solicit questions. I also think it's the responsibility of the manager to make sure that the mentor is doing this, and to check in with new hires frequently. I always encourage new people to ask questions, but they don't always believe me. I'm kind of hoping that by writing this down, I'll at least be able to help others -- some people believe what they read more than what they hear.
Posted by: Kim at August 28, 2006 05:35 PMKim,
I work at ThoughtWorks and most of our projects tend to use pair programming most of the time. It works quite well in ensuring new team-members have at least one person who is always available to answer their questions. It also gives them someone who can introduce them to the rest of the team/organisation in a informal manner. The other big advantage is that effective pair programming relies on good and constant communication which means that there's less chance of the new team-member getting stuck on a problem and keeping quiet for several days.
If you're in interested in applying apprenticeship and related ideas to software then you should take a look at a book I'm working on with Dave Hoover. It's, currently, called "From Apprentice to Journeyman" and some of it is online at: http://redsquirrel.com/dave/work/a2j/
Feel free to ask us questions or chip in with your own suggestions.
--ade
Posted by: ade at August 29, 2006 02:15 PMAde, I fully believe that pair-programming helps with getting new team members up to speed. But I'm less convinced that it works as a general policy for all developers. I also wonder how well it works for developers who end up paired with new developers.
How has pair-programming worked out for you in the rest of development? Or do you only do it with new members? If so, how long is someone considered "new"?
Posted by: Kim at August 30, 2006 09:57 PMI agree that pair programming isn't the best approach in all situations for all developers. However it is a useful tool to have in situations where you need improved knowledge transfer and continuous code/design review. On my current project we've tended to work alone for most things with a casual transition to pairing when dealing with difficult/far-reaching design decisions or bringing in new people. That's because the team is very small so we can't afford to have one person be the only one who knows a particular sub-system.
Developers who get paired with new team members do end up losing some productivity as a result but it's up to the project's management to make sure that the new team member delivers enough additional value to make up for that loss in the long run. Sometimes there have been occasions though when the new team member has been able to start making significant contributions straight away because they've had the assistance of someone who already knows the business domain and existing codebase. So it usually balances out.
When pairing has worked well it's helped us ensure that everybody owns the entire codebase and can change any part of it. It's helped us create systems that were better than any one team member could have achieved on their own. It's helped achieve lower defect rates and increased quality (although I can't prove it was the only cause). It's helped spread (both business and technical) knowledge around teams which has meant that we've been able to have more consistent codebases. This has helped us with both long-term maintenance of projects and scaling teams up.
When pairing hasn't worked well then time has been wasted as people who don't work well together have achieved less than either could have done alone. Since it's just another tool we've usually adapted to that situation by doing less pairing or by rotating pairs more frequently.
The effectiveness of pairing depends on what kind of people you have on your team and the nature of the project. There are lots of developers who find the very concept of pairing painful. This is either because they're not used to explaining what they do as they do it or simply because they prefer to spend more time thinking deeply before doing anything or because they don't like working closely with other people or because they think that pairing with someone less knowledgeable slows them down or because they've never learned what it takes to make pairing work well. Sometimes this changes when they're shown how to use pairing effectively and sometimes this doesn't change.
Personally I just try to make sure our use of pairing takes into account the attitudes of people on the team as well as the cost/benefit of pairing in any given situation.
--ade
Posted by: ade at September 1, 2006 01:48 AMhuman robot transformation fresh meadow movie theater mounted phone reproduction vintage wall tick bite and lyme disease dog in pet puppy sale toronto international memphis paper advance cash cash loan loan payday quick apex tv code universal remote chronicle midland amtrak california
Posted by: Rktkcjk at October 13, 2007 01:21 PM