What I learned (non-technical) at CodeMash

I learned quite a bit from chatting with different people while hanging out between sessions at CodeMash.  In addition to all the great technical discussions, there were quite a few non-technical business discussions. (Yes, technical people do discuss business, just from a different perspective).

The discussions got me to thinking, and here's some thoughts:

First item: Money is important, but not the way you think.

If you find yourself making a decision because "you need the money", you're making the wrong decision. This is not to say that making money is bad, or that businesses should be doing everything for free. But rather, if you make a decision because you need to make money now, it's the wrong decision. This came up in a couple different discussions at CodeMash.

One developer at one of the Open Spaces discussions asked for some advice on how to convince his management that some of their decisions were not in the company's best interest. In fact, he felt that some of the company's decisions were downright dangerous to the company's future health. All the other folks around the table gave a variety of recommendations: bring up the issue, make alternative recommendations, suggest a pilot, etc.  He said he did all those things.  One of us (may have been me) said that at some point, you need to vote with your feet: if you really believe that the company is going in the wrong direction, it's time to leave.  The individual's face showed real fear. Leaving a job is a frightening proposition. It can be the right choice for you. But, if you can't go very long without income, thinking about voting with your feet is an empty threat. And, staying when you don't agree with the direction is not good either: you're de-motivated, you're not helping, and you'll likely harm the current direction, whether it's right or wrong.

Another person was quitting his job to start a new company. He needed to look ahead, examine his current budget, and make a calculated risk.  There's no doubt that starting a company is a risky venture. A combination of knowledge and forethought means that you are aware of the risk, and you take it knowingly. The point is to create a budget, know where you sit, and take calculated risks.  If starting a business (that might fail) means delaying an important home improvement project, it's probably a good bet. if it means losing the house, the car, and the laptop you used to write your business plan, it's probably a bad risk. The corrollary is that having a current source of income buys you time: time to save, time to plan, and time to make a calculated leap.
 
People make bad decisions because they think they need the money. People make good decisions for a variety of reasons. Any way you look at it, your work should produce an income. The way to ensure that you make intelligent decisions is to carefully assess your risk, and take steps to decrease your pain should a risk go badly. Then, you can decide to manage your career around what you want to do, then figure out how to make money while doing it.

To be honest, I've been trying to do just that since the mid 90's. There are certainly people that make more money than I do, but I make enough, and I'm happy to go to work every day.

Second Item:  Some companies view software people as an investment. Some view it as a cost.

You (if you're like me) want to work where it's an investment.  This one came up with a number of discussions with Jim Holmes.  Jim's a great developer with a very strong drive to grow his skills, and the skills of those around him. That's a fantastic trait. And, it's why Jim will be productive member of the development community for a long time. It's also why he was so excited about CodeMash.  But, not everyone shares that idea. Some folks want to view software developers as a cost center to be minimized: choose the lowest cost developers, and continue to push downward.

There are serious career implications of both strategies. I beleive our company is one of the former companies. We sent all of our people to CodeMash, because we believe it was a great opportunity to learn about software development. I firmly believe we can take great software development minds and they will be productive on any technology (given a little time): .NET, Java, Python, Ruby, etc.  And, those great minds will grow over time. I don't believe I know what specific skills will be needed in 2009. I can guess, but I'm probably not quite right. But, I know that everyone of our folks (me included) will see it coming, learn it, and we will be productive before our customers ask for it. 

I worry about companies that say "You're a Java developer. You work with Java". Well, when the sun sets on Java, you're done. Note: I'm using Java as an example. The sun will set on .NET, C#, VB.NET, Python, and everything else we do today. The software people that have long careers are the ones that can adapt to the next big thing. The only way to do that is to keep your eyes on the future, continue to sharpen your skills, and stay relevent.

• The difficulty is often getting companies to see the benefit of investing in staff development. The costs are easy to measure: lost time on tasks, the cost of training classes and conferences, books, etc. But, the benefits are harder to see immediately. I like to use the following ideas:
• Decreased time to market. By seeing more about upcoming technologies, developers make better decisions. More tools means more knowledge, and an increased likelihood of picking the best choice.
• Increased productivity: Businesses lose time because there is 'one person' that knows a given technology (say WPF). Because of that, when that one person is on vacation, sick, or dedicated to a particular customer. You can't grow the WPF practice because you've only got one WPF expert. (Note: WPF is a placeholder for any technology). Unless you invest in your developers, you can't expect them to pick up new and different technologies when needed.
• Turnover: (Both voluntary and involuntary). I know of few companies that don't change technology eventually. When you do, will your staff adapt? Or will you be searching for staff that already knows the new big thing?  If you have to find new staff, what cultural and application knowledge leaves?
• Silos: If your staff has one expert on a given technology, it's equally likely that this expert views every problem through the prism of that one expertise, While you want people to be experts in certain areas, you will have serious problems if they are ignorant of everything else. A serious committment to training is your best way to avoid that.
• And, the one argument I don't use: what if your key developer gets hit by a bus?  Sure, it's a risk, but it's a low probability risk, and easily ignored if you aren't receptive. And, there are so many more likely risks to having a single expert for a particular topic on staff.

Final Item: Mentioning the phrase "Web 2.0 business plan" to a bunch of nerds discussing the differences between static and dynamic languages is a great way to end a conversation.

I think there is a corrollary that mentioning Web 2.0 can probably kill any conversation.