|There's more than one way to do things|
Re: Right tool for the job?by Tanktalus (Canon)
|on Sep 24, 2005 at 20:14 UTC||Need Help??|
It's all a matter of priorities. Thus, I'll respond from my own priority list.
Top of my priority list is family and friends. Generally in that order. Programming, though a very fun hobby, and a reasonably lucrative way to earn a living, is not at the top of the list.
Now that I've established that I have other very important things to do with my time, now I need to allocate what time is left for career purposes. Top of this list is to know what tools are available to me. Note that I did not say "know the tools" but "know what tools are available." I don't need to be a Java expert. I do, however, need to know what Java's strengths and weaknesses are. Ada, as powerful of a language though it may be, doesn't make the list because in my work environment, Ada isn't available. Nor would any Ada software be maintainable because there probably is very little Ada knowledge where I work. Better to use a language that we can find others to come in and work with.
From there, I've decided (or, in some cases, someone had decided for me) to learn certain languages. C/C++ I knew before graduating. Shell, awk, sed, (including as little C shell as I could get away with) perl, and even to some degree Java, I learned after joining my current employer. Perl is what I've mostly stuck with simply because it's the most enjoyable way to gain the most productivity.
That said, I highly encourage you to learn more shell. It's an awful language. But there are some really cool utilities, such as awk, sed, grep, from which you can learn other ways of approaching a problem which you can take into perl to get something that runs inside the same process as the rest of your code. Also, there are some things that just are useful to know - quoting rules for running perl one-liners, other shell keywords and special characters, all of which are important to know when using system. I've found that knowing shell way better than I wanted to has helped me take advantage of perl - and learning perl has greatly helped me in the way I approach shell problems.
Other languages, such as C/C++, Java, C#, BASIC, ... these are primarily for other areas of programming from this. The above is helpful for system administration. C, C++ have strengths in bare-metal computing speed, but are relatively weak on TCP and GUI programming. Java is good for TCP and GUI programming, but not so good at setup costs (i.e., bringing up the JVM is expensive) which is one of the reasons why Java is used for servlets - where they aren't taken down. C#, BASIC - I'm not so familiar with these as I've managed to mostly avoid Windows (and our team doesn't use C#, and uses just tiny bits of Visual BASIC). So, knowing what is best for each aspect of our project, I am in a reasonable position to parcel out the requirements to the teammembers who actually are most proficient in the respective tools. (Although I think I'm still the most proficient in C++, I don't actually get any of those assignments.)
I think one issue for you may be one of timing. Technical management is supposed to have a handle on many things below them, but need not be deep knowledge of any area. So, if that's the career path you want, you need to prove yourself as a master of your area, and then, as you work your way up the chain, you gain a broader knowledge of more things, but don't actually need a deep knowledge of anything, all while getting paid more and more. Theoretically ;-) You just need to become the master of one thing in particular until you get those promotions.
But don't sacrafice anything that's actually important over this. And I'm not talking about the lip-service that most people give, "Oh, of course my wife/husband is important to me. Of course my kid(s) are important to me." Based on your actual actions, what is actually important - are you living up to your priorities? If family is important, are you spending more time with them than your career? Sometimes quantity is more important than quality.