It seems to me that you're advocating

Post #69,377 by lincoln 12/17/02 3:37:44 PM Reply	It seems to me that you're advocating a career path that leads away from programming and getting into networking and security administration. While those are both well and good, they can be major pains in the posterior when something undesirable happens and your back gets painted with a bulls-eye (Code Red, Nimda, etc. anyone?) I enjoy programming and wish to retain that as my primary function, but it's frustrating to see other langauges favored in the job ads, knowing that I will not learn them in my current position. You stress learning on my own. No disagreement there. But we've debated the point ad nauseum about how your resume needs all of the right buzzwords and TLAs to get past the HR drones or the resume-scanning software. First and foremost is showing that you've learned AND USED what the future employer wants on the job at your current employer. Today's economy doesn't allow a potential employer to take a chance on you just because you've learned something on your own and need the opportunity to show him/her that you actually know it. They want a proven track record. (Unless you're a fantastic BSer in an interview, which I'm not.) And that's where the "Catch-22" hits you big time. lincoln "Four score and seven years ago, I had a better sig"
Post #69,450 by tuberculosis 12/17/02 6:27:38 PM Reply	RE OJT "But we've debated the point ad nauseum about how your resume needs all of the right buzzwords and TLAs to get past the HR drones or the resume-scanning software." Yeah - so put them all on your resume - like in skills section. That matches the scanners. Really. Skills: Java, C/C++, Fortran 77, Hypercard, Space Lauch Systems Engineering, Ear Wiggling, Nose Twitching.... Notice I don't say where I learned them here. But this resume will make the first cut. "First and foremost is showing that you've learned AND USED what the future employer wants on the job at your current employer." No, thats the second cut on the resume thing. Its where they dig through your experience listings of job descriptions to try to determine the actual depth of the skills you mentioned. I often run across candidates that list a skill and don't show where they used it on the resume - so I end up dragging that out of them at the interview. Thats cool - note that they GOT THE INTERVIEW. Often its just an omission or they have minor experience with something that didn't rate exposition in detail. "Today's economy doesn't allow a potential employer to take a chance on you just because you've learned something on your own and need the opportunity to show him/her that you actually know it." True enough - and yet - the average interviewer will just ask you a few questions about the technology to try to draw out whether you're BS-ing them or not. If you say XWindows programming with C++, I'll likely ask you how action callbacks on buttons were implemented. You'd need to know the toolkit well enough to have completed a tutorial at least to answer that question. If you do - I'm satisfied you know what we're talking about. The other trick is to get OJT thats not strictly sanctioned. When Java first came out, I was working on a C++ program that needed to send commands to a 5ESS telephone switch. Only the switch was down most of the time. To facilitate testing the program I needed something that would at least accept network connections and echo the commands to somwhere while issuing expected responses. For the heck of it my dev partner wrote it in Java - he fixed it so each session ran in its own thread. Did it need to be Java? No. He just wanted to get some experience with it so he could be knowledgeable about Java threading and sockets. No part of our job called for the use of Java. I did the same thing when I was an engineering programmer for the Department of Energy. All development was in Fortran (powerflow simulation programs). But we had lots of tools and I had one tool that needed to extract reports from the simulation logs. Problem was, the logs could be arbitrarily sized and Fortran doesn't have dynamic memory allocation - so I asked if I could write it in C since it has malloc. They said sure - and I taught myself C at the expense of the DOE (and switched jobs right after). Point is, you probably need tools from time to time. So write them in something you want to learn. I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns.
Post #69,466 by kmself 12/17/02 7:42:22 PM Reply	Programming, Systems, Network: seperate worlds? \r\n [It seems that you're advocating] a career path that leads away from\r\nprogramming and getting into networking and security administration.\r\n \r\n \r\n\r\n No, I'm advocating filling in skills you feel you're deficient with,\r\non your own (answering the second part of your post). There are plenty\r\nof projects to get involved if you'd like, and having your name listed\r\namong the credits of a free software project is a real and\r\nreferenceable accomplishment. Hell, I've had people contact me\r\nover two-line patches I hardly consider to be "programming" \r\n\r\n That said, there's a lot of interconnectivity between systems\r\nadministration, networking, programming, and data management. If you do\r\nlearn enough of the areas you're weak in to strengthen your creds,\r\nyou're ahead of the game. \r\n\r\n When I did SAS work, I considered a major part (> 50%) of my\r\nproductivity to be tied to familiarity with my preferred environment\r\n(Unix). I strongly advocate getting to know your neighborhood, wherever\r\nit may be. \r\n\r\n \r\n While those are both well and good, they can be major pains in the\r\nposterior when something undesirable happens and your back gets painted\r\nwith a bulls-eye (Code Red, Nimda, etc. anyone?) I enjoy programming\r\nand wish to retain that as my primary function, but it's frustrating to\r\nsee other langauges favored in the job ads, knowing that I will not\r\nlearn them in my current position. \r\n \r\n\r\n There are solutions you can turn to to minimize security issues. And\r\nprogrammers should be specifically aware of the security\r\nenvironment in which they operated. I see opportunity here,\r\nLincoln. \r\n --\r\n Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com]\r\n [link\|http://kmself.home.netcom.com/\|http://kmself.home.netcom.com/]\r\n What part of "gestalt" don't you understand?\r\n [link\|http://twiki.iwethey.org/twiki/bin/view/Main/\|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n \r\n Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
Post #70,248 by broomberg 12/21/02 1:16:27 PM Reply	Agreed, esp systems stuff. I've noticed a 2 tier value system for programmers. Code monkees know a language and may be expert in it, but they lack an understanding of the environment in which it runs. So they make insane assumptions about the performance, network lag time, nfs disk availability, file size restrictions, permission issue, database dependencies, uptime requirements, etc, etc, etc. They code in a perfect world, and try to run in the real world. No matter how good they are in their given language, lack of awareness of the tools and environmnet kills them. Make them look like idiots. Even worse, since they DO know a large amount about the specific language, they tend to ponticifate about it. They initially seem bright to management, which then give them some trust. They blow the project and then go into hiding while someone else reimplements in a tenth of the time. Career killer when you screw your boss. A C programmer that spends a week crafting a utility that I can do with 3 Perl scripts piped together in 10 minutes is worthless. Might has well have a profession hand tooling buggy whips. On the other hand, a Perl programmer that knows C and lots of Unix utilities is a gold mine. They can whip out the easy Perl stuff in seconds, and hand tool the CPU intensive stuff in C as needed, and use neither when a 'cat \| sort \| awk' script is all that is really needed.
Post #70,249 by ben_tilly 12/21/02 1:52:13 PM Reply	That reminds me of a comment about CPAN... A comment about the story at [link\|http://use.perl.org/article.pl?sid=02/11/12/1616209\|http://use.perl.org/...=02/11/12/1616209] in particular. I forget who said it, or where, but a summary I saw said: A large part of the reason why Perl has CPAN and other languages do not is that a lot of sysadmins use Perl. Therefore some are willing to cobble together systems to support Perl, and others are willing to donate resources to make those systems work. It is quick, it is dirty, but it is there, works, and grows. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #70,291 by tonytib 12/21/02 9:01:33 PM Reply	What about wrench monkeys? This week...let's see, getting our combined C++/VB/Python system to blow cold air. Then, today, start off with replacing a crappy French worm gear rotary stage with a US direct drive rotary stage. At least the ME did an excellent job -- everything fit together perfectly. Now, I'm figuring out how to wire the stage in electrically with the least hassle. Then, when that's done, I have to get the motion controller and overall software configured properly for the new motor. Hopefully, we'll be hiring another software developer in Q1, but it'll be someone who can learn rapidly on the job and whose idea of a system knowledge includes mechanical & electrical systems. Tony

Welcome to IWETHEY!