Learn from the mistakes of others

Therefore, I'm looking at PHP, and may stray into XHTML, XML, and perhaps later some Java. I've already had a start on SQL, with more to come.

Yeah, I know. If I was really serious about getting a real hobby, I'd be picking up C++ ... but it's been a few years since I did any serious coding. I probably should get the hang of Object Oriented Programming at some point.

Ah hell, to quote Joel Spolsky:

Watching non-programmers trying to run software companies is like watching someone who doesn't know how to surf trying to surf.

"It's ok! I have great advisors standing on the shore telling me what to do!" they say, and then fall off the board, again and again. The standard cry of the MBA who believes that management is a generic function. Is Ballmer going to be another John Sculley, who nearly drove Apple into extinction because the board of directors thought that selling Pepsi was good preparation for running a computer company? The cult of the MBA likes to believe that you can run organizations that do things that you don't understand.

Therefore, I'm looking at PHP, and may stray into XHTML, XML, and perhaps later some Java. I've already had a start on SQL, with more to come.

Yeah, I know. If I was really serious about getting a real hobby, I'd be picking up C++ ... but it's been a few years since I did any serious coding. I probably should get the hang of Object Oriented Programming at some point.

Ah hell, to quote Joel Spolsky:

Watching non-programmers trying to run software companies is like watching someone who doesn't know how to surf trying to surf.

"It's ok! I have great advisors standing on the shore telling me what to do!" they say, and then fall off the board, again and again. The standard cry of the MBA who believes that management is a generic function. Is Ballmer going to be another John Sculley, who nearly drove Apple into extinction because the board of directors thought that selling Pepsi was good preparation for running a computer company? The cult of the MBA likes to believe that you can run organizations that do things that you don't understand.

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market. Which gets me to the most important point of this essay:

Your first priority as the manager of a software team is building the development abstraction layer.

The Development Abstraction Layer, Joel Spolsky, Joel on Software, April 11, 2006

Having done both jobs, I agree with Joel. Most programmers work best when they can just get on with the job of programming.

That's one reason why promoting good programmers into management positions is not always such a great idea. Management and programming are very different activities.

Good managers, like good coders, are hard to find. They ought to be nurtured and looked after - the managers and the coders.

Again, having done both jobs, I find myself wondering if I wasn't a better manager than coder. Whether I was/am a good manager, I leave that for others to answer. I do, however, feel pretty confident about my flexibility, and my ability to help get things done/fixed.

Anyway, back to the point of this post: when a team works well, everyone does their job well, with their colleagues in mind. Things begin to happen like magic. A magic that is hard to replicate without the whole team. Even harder to "make" happen without the cooperation of every team member.

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market. Which gets me to the most important point of this essay:

Your first priority as the manager of a software team is building the development abstraction layer.

The Development Abstraction Layer, Joel Spolsky, Joel on Software, April 11, 2006

Having done both jobs, I agree with Joel. Most programmers work best when they can just get on with the job of programming.

That's one reason why promoting good programmers into management positions is not always such a great idea. Management and programming are very different activities.

Good managers, like good coders, are hard to find. They ought to be nurtured and looked after - the managers and the coders.

Again, having done both jobs, I find myself wondering if I wasn't a better manager than coder. Whether I was/am a good manager, I leave that for others to answer. I do, however, feel pretty confident about my flexibility, and my ability to help get things done/fixed.

Anyway, back to the point of this post: when a team works well, everyone does their job well, with their colleagues in mind. Things begin to happen like magic. A magic that is hard to replicate without the whole team. Even harder to "make" happen without the cooperation of every team member.