Re: Prove/Improve your Self/Skills

[Tanalis]

A couple weeks back at work I was given responsibility of a script that's responsible for generating a fairly fundamental report. It ran once a month, and took the best part of two-and-a-half hours to do its' job.

Not great, when all it does is numbercrunch.

A colleague suggested I look into distributing the work over a larger number of processes (the script did the same job, many times, sequentially). This initially put the fear of God into me - I'd never touched distribution before, bar theoretically.

I did much research into how best to distribute using Perl and c-shell. Finding that Perl supported a C-style fork relieved me a little - and I ended up coupling that with a system call to a c-shell script on a remote computer.

Two weeks, and a post or two on here later, I had a working prototype. It looked good, having a quick Tk GUI to make it vaguely user-friendly, and could take in the list of processors our overnight batch used and ship each iteration of the script out to one of them.

I think that I managed to prove myself during the project - alongside learning a hell of a lot about Perl and Unix. That felt good.

I feel, though, that the feeling of "I just did something I didn't think I could pull off" - the feeling everyone has when their first ever program runs and works properly, even if it just prints "Hello" on the screen - gets harder and harder to achieve. As you learn more and more, and get more experienced, I think it gets more difficult to feel good about the outcome of projects, simply because they don't stretch you as much as they once might have. That's a shame, in my opinion, and it's important to try and keep the feeling alive, even years down the line.

*shrug* Just my quick thoughts ..
--Foxcub

[l2kashe]

I agree with Foxcub's statement, in that it can be difficult to continue in leaps and bounds, learning something new with each app written. There are just $x number of ways to process a file.

But I'm finding other ways of improving, that aren't as drastic/exciting as before, but which are much more satisfying. Like optimizations for speed or system efficiency, making use of compression for network transmissions (Thanks Compress::Zlib). I'm no guru. I've taught myself shell scripting, Perl, and C over the last 3 years. But here at work, I truly make a difference. Things which took a long time, now take fractions of the original time due to perl. Things which relied on random notification methods, with no standard across the board, are now centralized as well as standardized. When things come up that are akward or repetetive people come find me.

What I'm attempting to state is that I think I have the basics worked out (code style, modules I use frequently, etc..) and I get statisfaction from the code sometimes, but nowadays the satisfaction I get isn't so much the coding itself, as the ability to scratch other people's itches to their satisfaction (which is key, I've found, as opposed to how I would scratch it for myself).

It's also nice that now it's a fairly frequent occurance that my boss or a co-worker to walk up and start a conversation with "I need a script to....". Peer respect is a Good Thing(TM). This has led to all sorts of new possibilities with the code, and new frustrations :P, but hey ain't that life/code.

/* And the Creator, against his better judgement, wrote man.c */

[John M. Dlugosz]

it can be difficult to continue in leaps and bounds, learning something new with each app written. There are just $x number of ways to process a file.

Hmm, but there are more ways to write that in Perl. So, is that why TIMTOWTDI makes Perl so appealing to so many who feel passionate about it?