Wednesday, September 29, 2004

Rush, Rush, Code, Code

I've been reading Joel Spolsky's book Joel On Software based on his blog, http://www.joelonsoftware.com. It's quite a compelling book, because it has a lot more details to help get us to a higher level of productivity, efficiency and organization....

In most of my recent jobs, I've been in the position of having to clean up code, SQL for both performance and easy to understand, read and use.

This book is great, because I can learn what else I need to know.

After having read Rand's post on Incrementalists & Completionists, this helped me understand, why I am so driven to reach such a high level organization/productivity.

Each of us is shaped by the tasks, paths, and choices we make, and I have no less been shaped by mine.

The point of this, is that unless we get a better understanding, we'll end up being burned out and frustrated.

Because in my experiences, I was so driven to get to this high plateau that and if we didn't all work together to get there, in a short period of time, I'd get frustrated and burned out.

So I have realized I have to pick and choose, and incrementally over time, improve the quality of the site, code.

Joel On Software is a really great written book and blog.

The book covers topics from Writing Specs, Bug Tracking, Managing Developers, and as they say, much much more.

I think I'd love to learn about other people's experiences, about cleaning up after other people's code.

Then there's my additional experience of being the one to introduce Project Management, Source Control, Scalable Code to each company.

As Joel Spolsky says, for our industry there is no developer/software management/project management bible, that helps companies start out on top, in stead of having to spend too much time cleaning up code.

For me the goals, most in my mind are:

1. How can I make sure that the site never goes down anymore.
2. That bugs are recorded and assigned to be fixed, instead of always creating new features/fixes that may introduce it's own set of bugs.
3. How can I help the creation of a project mgmt process that will be easy to learn and manage, and yet still make sure we make no communication/project mistakes.
4. How can I encourage my fellow developers to stick to using our project mgmt intranet etc...

Now that I am working on a coding team, I see how important a good methodology is. It's half fadish psychology and half setting standards that will actually be followed.

I mean no offense to fusebox, mach-2 users, I do approve of anyone that uses a standards and works to release quality products.

It does help not having to re-invent the wheel all the time. Or making sure that I bring all the stuff from the previous job to the next one, to help them learn project management, bug tracking, best practices...

I think what'd be nice if we as an industry can create a best practice repository, that can be reviewed, approved, and then made available...

That's it for now...