I've talked before about how I don't like corporate jobs. OK, I've whined before about how I don't like corporate jobs. I'd say I was justified. Corporations usually make stupid decisions, hire unqualified people who get promoted to managers, stifle innovation and productivity, and seem to find every way possible to prevent their employees from doing actual, fulfilling work.

But complaining is easy. Learning lessons from their mistakes, though, is where the real insight lies. So, what can I learn from my current, corporate job?

Have Your Best People Support the Rest

The following will pertain more to programmers, but I think the lesson is universal. Say that you have a team of five programmers and you need two of them to build your architecture and common code, provide training and define standards. The other three to do the grunt work of building applications based on that common code. Now, which two programmers do you put in the support roles; your best two or your worst two?

I think an argument could be made for both, although I see now that there's only one right answer.

Let's take the case of the two best programmers in the support role. If you put the best two in the support role, you will get a solid, well thought out framework that the others can base their code on, making sure that it all works together. You'll get good documentation for the application programmers and a support structure in place that will help them get their jobs done. It won't matter that the other three are less experienced because the two support programmers will be able to help them out and bring their skill level up to where it needs to be.

Now, let's look at putting the two worst in the support role. If you put the two worst in the support role, you can keep them out of the way of your other programmers, who should be able to bang out the applications in no time at all. Any good programmer can figure out problems on their own and really don't need a support structure. As long as the two support people stay out of your programmers' ways, everything will be just fine.

Which is where the problem comes in.

If you want your support people to stay out of the way, then why do you even have support people? If you put the two worst in there, building up the infrastructure that the three best need to build on, all your applications will be relying on the crap work of the support programmers. If you have a couple of programmers that are building servlets and Struts Action classes that don't know that servlets need to be thread-safe (true story, sadly), then all of your company's applications are going to be affected. And when a support programmer that doesn't know what they're doing has a problem they can't figure out, they will go to the best programmer to solve it. That means your support people need support people and your application developers won't have time to get their jobs done.

But you need support programmers to keep a big corporation on track. Otherwise, you get a hodge podge of "flavor of the day" applications that don't work together and can't be maintained by future programmers. Not having a support staff will cause more problems than having a bad support staff!

So I guess you know my lesson number one: Have Your Best Support the Rest.

Trust me, your life will be better.

Quality Programmers Know What They Need

One big problem I've seen with corporations is that they are very picky about what you put on their computer. If you want to install a new application, you have to run it by security and then supply chain and fill out a requisition form, and on and on. But when I need an application, I usually need it now I know what I need to get my job done because you hired me to know that. What's with the hassle?

True story. We got in a couple of contractors and needed to get them set up with some software, mainly Visio to look at some technical specifications we had written up. It took the company a week, five whole days, to get this software installed on their machines. In that time, we had to print the stuff out or have them sit idle while we waited for the software. We were paying them $80 an hour and the Visio license cost $500. They eventually got the licenses. They took them from some other developers. They were too cheap to buy any extra licenses.

Another true story. I'm a web developer and I like to check my pages in more than one browser. When I got to my current company, all anyone used was Internet Explorer. I needed Firefox to test my applications with more than one browser, because that's what good developers do. So, I decided to install it on my machine.

Within an hour, a message box popped up on my machine from Network Security saying that I was running an unauthorized application and needed to uninstall it immediatly. After much campaining, three months worth, I was eventually able to get Firefox installed on every developer's machine. The catch? We weren't allowed to use it outside of the firewall, we could only use it to view internal applications. Wow, thanks.

How do you get around this in your company? Give your developers a budget for new applications. They're the ones keeping up with the latest tools and they're the ones you want to look to when you plan on purchasing a new tool. These are tools we're talking about and every developer I know has his own tool belt that he knows like the back of his hand. This doesn't have to be total anarchy, but everyone has a special tool that they can't live without (mine is the web developer toolbar in Firefox) and you better let them have it. Developers will be happier and more efficient, and who can argue with that?

Don't Get It Perfect, Just Get It Out There

AKA: Ready, Fire, Aim

You always hear about projects that have trouble getting requirements done and projects in on time. I'm here to tell you exactly why that is. Are you ready?

Because they try to get requirements perfect

The project I'm on now is slated to go live at the end of October. Requirements are still changing. That's right, the project started at the beginning of the year, it's two and a half months to go and requirements for that application are still changing.

And that's because they're trying to make it perfect. They're trying to get ever scenario handled, every eventuality covered, everything a user might want to do in there on day one. Let me tell you; that's a recipe for disaster. Even if you do plan for two years, you still won't have everything covered. You'll still need to change something once it's out there. So, you know what?

Get it out there.

Then tweak it. This is a web app, is malleable (when programmed properly), it's flexible and you don't know how people are going to use it until they use it.

But then again, this is a corporation. I'm willing to bet that once this thing goes live, they won't touch it again for another five years. The program we're replacing right now was written in 1998 and hasn't had any major functionality changes since it was released.

Anyone whose seen the rapid development happening in our industry already knows this to be a proven fact. But, corporations being corporations, they have yet to catch on. If you want to beat the big corporation, don't be slow to catch on.

Conclusion

Well, there's three "lessons from the trenches". Most of these could be handled by having mutual respect between employees and management (another thing sorely missing in today's corporations). I think Joel on Software had the best article I've read in a while on managing developers and I stand by his recommendations.

What lessons have you learned out in the corporate world, or just as a developer?