Ah, Mr. Spolsky, I don't think I'll ever understand why so many people link to his articles. Quoth the Joel:
Get better people into the team. Get involved in hiring and interviewing, and recruit good candidates to join the team.
Okay, if you're involved in hiring people, you probably aren't a grunt. If your grunts are doing your hiring, your company has major problems.
At some point, one of these geniuses will spend two weeks writing a bit of code that is so unbelievably bad that it can never work. You're tempted to spend the fifteen minutes that it takes to rewrite the thing correctly from scratch. Resist the temptation. You've got a perfect opportunity to neutralize this moron for several months. Just keep reporting bugs against their code. They will have no choice but to keep slogging away at it for months until you can't find any more bugs.
Does that seem like a bad idea to anyone else? It wouldn't exactly create a good team environment would it? If somebody's code sucks, help them improve it. This can easily be done in a non-threatening way. Don't forget to look at their side of the issue as well, who knows, you might be the "Bozo" programmer.
Look for ways to get out of this environment. Take a laptop to the company cafeteria, where there are lots of tables that are empty most of the day (and nobody can find you). Book a conference room for the whole day and write code there
Okay, so if you're new to a company make it very difficult for anyone to find you? Again, great way to build a good environment and get people to listen to you. Not to mention wasting valuable conference room time that could be needed for useless meetings.
Mind you, his first point wasn't so bad "Just Do It" but I guess Nike wouldn't like it if that was his entire article. Too bad, it would have been far better advice.
| [reply] |
Okay, if you're involved in hiring people, you probably aren't a grunt. If your grunts are doing your hiring, your
company has major problems.
Not necessarily. I've worked with a couple different
companies that have their programmers chat for a while with
applicants before hiring them. Company gets more data about
what the applicant knows, applicant gets a more realistic
view of the company, and both sides get more of a sense for
personal fit. Everybody wins.
| [reply] |
Good points ++.
Ah, Mr. Spolsky, I don't think I'll ever understand why so many people link to his articles
Just for the record I am not a card carrying Joel fan. I had merely read the article a while back and thought it might have provided some food for thought.
Mind you, his first point wasn't so bad "Just Do It"
Some of his other points weren't so bad either. The main reason I linked to the article was because I remembered that it addressed the issue in the main post of: - Lack of sensible development environment (no testing/staging area, no version control, etc)
This hadn't been discussed much in the thread (The article mentions bug tracking, specs, cvs). I also think he redeems himself on some of your points in this paragraph. None of these strategies work if you're not really an excellent contributor. If you don't write good code, and lots of it, you're just going to be resented for messing around with bug databases when you "should be" writing code. There's nothing more deadly to your career than having a reputation of being so concerned with process that you don't accomplish anything.
-dwiz
| [reply] |
