I'll make one comment here, that I can see is a HUGE problem.
I'm a computer consultant. I own my own company, although it's only me at this point (It's been as high as three people). I know a number of programmers, and I know good programming style.
You don't have it.
Here are the rules.
1) Document your code. 2) Document your code. 3) Document your code.
It doesn't matter HOW wonderful and bug free your code is, unless you are ONLY writing it for your own use, in your house, on your own personal PC. If it's anywhere ELSE, someone else may end up having to use it, modify it, or support it. If you're part of a community effort, then your attitude of "I don't want you even trying to fix anything I write" is not only stupid, it's unethical. Part of the reason I'm _not_ doing anything with Keen is because I was left in a vaccum - fixing problems and answering questions is impossible without at least some information.
Thus, documentation.
What happens if you get hit by a truck tomorrow, and someone else _does_ have to modify your code, support it, or otherwise? What if you have to take a two month leave of absence, and don't remember what you did? (Don't even TRY to pull the "I know my code" bullshit.)
I can hand you several hundred pieces of code written for a MUD that are well written, with zero documentation. I'd bet you'd have just as much problem as I would figuring out what the person was supposed to be doing with it - and you can't debug it properly because it's depending on something that was modified in another portion of the base code - which has no documentation either.
If you aren't willing to write documentation - even after you've finished the code - you should get out of programming completely, unless you hire a technical writer to go behind you and document.
However, that brings us back to communication. If you aren't willing to tell other people what you're doing, why you're doing it, and how it's going to affect things, you're obviously not communicating well enough to have someone else put documentation in.
You figure out what I'm saying here. It's pretty obvious.
no subject
Date: 2006-01-24 05:36 pm (UTC)I'm a computer consultant. I own my own company, although it's only me at this point (It's been as high as three people). I know a number of programmers, and I know good programming style.
You don't have it.
Here are the rules.
1) Document your code.
2) Document your code.
3) Document your code.
It doesn't matter HOW wonderful and bug free your code is, unless you are ONLY writing it for your own use, in your house, on your own personal PC. If it's anywhere ELSE, someone else may end up having to use it, modify it, or support it. If you're part of a community effort, then your attitude of "I don't want you even trying to fix anything I write" is not only stupid, it's unethical. Part of the reason I'm _not_ doing anything with Keen is because I was left in a vaccum - fixing problems and answering questions is impossible without at least some information.
Thus, documentation.
What happens if you get hit by a truck tomorrow, and someone else _does_ have to modify your code, support it, or otherwise? What if you have to take a two month leave of absence, and don't remember what you did? (Don't even TRY to pull the "I know my code" bullshit.)
I can hand you several hundred pieces of code written for a MUD that are well written, with zero documentation. I'd bet you'd have just as much problem as I would figuring out what the person was supposed to be doing with it - and you can't debug it properly because it's depending on something that was modified in another portion of the base code - which has no documentation either.
If you aren't willing to write documentation - even after you've finished the code - you should get out of programming completely, unless you hire a technical writer to go behind you and document.
However, that brings us back to communication. If you aren't willing to tell other people what you're doing, why you're doing it, and how it's going to affect things, you're obviously not communicating well enough to have someone else put documentation in.
You figure out what I'm saying here. It's pretty obvious.
Bookworm