|Perl: the Markov chain saw|
Re: How not to codeby pg (Canon)
|on Oct 22, 2004 at 03:35 UTC||Need Help??|
"Do something else"
I personally prefer design, which I found, gives me much more oppotunity to explore different technologies. And you actually got a group of people to try out different things for you. You are learning what a group of people learnt, not as detail as they do, but you do get a better chance to understand what technology is right for what, unless you are lazy, and do want to spend the effort. But from time to time, I have to code to satisfy my itch fingers ;-)
"Of course, with proper supervision, interns and junior coders can do a lot of good work, too."
Supervision is important, but it is probably more important to understand the person you are supervising. Each person is different and their skill set is different. I had the experience where junior was given tasks that exceeded her ability too much, and I ended up with coding for them the last minute. Challenge them, but make sure the tension is at the right level.
"Don't rush to code"
100 agreed! Even with a tight schedule, don't rush. If you rush, the schedule ends up more tight, as therr is a increased chance that you have to go back to revisit some of your requirements and design, and trash some of your code. If that happens towrads the end of your project ...
"Business processes develop over time through the hands of many people, some of which may have become a faded memory."
IT people should be involved in redefining business processes, together with business users. Computer is not only a tool to automate things, but also to redefine things. If all what you do is to make stupid things happen faster and quicker in a automated way, rethink!