But, this was one of those not-so-rare occasions where the task at hand would have taken you only a few minutes longer, or in some cases less time to accomplish than writing the code to make it work. You were torn for a moment, "Should I just do it? I'll never have to do this ever again and scripting it will take just as long as doing it manually". To script, or not to script?
If you're reading this blog, you're most likely in the demographic that would answer that question easily. Script it! Even though this is a specific case and the actual code will most likely never get used again verbatim, you still gain a lot from scripting tasks like this. Here is why:
Within every task given us is a problem to solve. Some are easier than others, some are difficult, and some may not seem like problems at all. The fact is though that as simple or as direct as a task may seem there is always some level of problem solving involved with it and as it is with any other skill, practice and repetition always make you better. If you approach every task like a challenge and use it to level up in some way, it makes even the simplest script worth writing!
What can you do to make a simple, easy-to-write script more challenging? Some ideas:
- Write it in another language or application
- Use commands or functions you've never used before
- Make it more robust, so that is becomes useful in other situations
- Write it in as few lines of code as possible (don't count comments or white space lines)
In our line of work, the ones who stop learning are the ones that are left behind. Always seek out new ways to improve your skill-set and keep getting better!
Posts
In your line of work I suppose it is irrelevant, but for web-based coding it's a much harder decision and you need to take into account various factors like CPU, filesize, etc. For example, should I hard code some php functionality into a page or should I make a class to organize it all? A class = more RAM used and a bit more processing, but it's cleaner code and much more reusable. On the other hand maybe I'd rather keep it as client-side as possible and utilize javascript with ajax calls only when I need them and spare my server as much load as possible - but the next thing you know you have a 200k js file (cacheable of course) that you would only ever want to implement into a site with a high percentage of repeat visitors. One-time visitors on a slow connection like a 3g phone will hate you.
ReplyDeleteSo, yea I remember you saying for Maya that the cpu/ram/etc aren't even factors in scripting, but for other languages/applications it's definitely something to consider.
//2cents.
It's not that hardware isn't a factor, because really all the scripts are doing is performing a task or job within the application. If that particular job uses a lot of resources (i.e. rendering) than the script will use the same amount of CPU/RAM as if you were to run it manually.
ReplyDeleteInteresting points though about web-dev vs. CG-scripting. I suppose the difference would be that the type of 'small task scripts' I'm referring to above are largely not going to be used by anyone but the author, so we don't have to worry about user-feedback. An example of a web-task like this might be something like backing up your server in a special way to prepare for moving it to a new box or something like that. Stuff you're not going to repeat often, if at all, and could be done manually using web-tools, but is all scriptable if you have the know-how.
Ah i like your analogy about the server backup - yea that definitely makes sense now, and I agree, script it :) My #1 reason for scripting it would be that I fear the manual job would be a pain in the ass and scripting it sort of gives me that reassurance like "script it only once and it'll be there to save your ass in 2 years when you forget how to back up your server cuz you never do it"
ReplyDeleteMy one argument (to play devil's advocate) is that my scripting ability/style changes/improves constantly so something I script now for a rare job I will probably laugh at and re-code anyway in 2 years so in the end it's all just practice.
That's another good point too, haha. Or, even if you don't want to do it a "better" way you'd probably end up re-scripting it differently anyway just to make it interesting.
ReplyDelete