Sponsored Content
Full Discussion: UNIX career path for Admin
The Lounge What is on Your Mind? UNIX career path for Admin Post 302882017 by Neo on Friday 3rd of January 2014 02:36:35 PM
Old 01-03-2014
In my view, it is not a good idea to follow buzzwords and trendy tech words like "Big Data" or pie-in-the-sky governance models such as TOGAF.

It is better to be comfortable programming, which means have the creative talent to direct computers what to do.

When you can program, you can create. When you can program, you can take your ideas and concepts and implement them yourself. When you can program, you understand programmers and developers.

I started my career in unix writing C client-server code to control production HP-UX machines used in a RF radio factory to test and document the test results of these products on the production floor.

Since that time, I have worked "up in the clouds" with enterprise architecture models and "down in the weeds" programming.

To me, a techie person who cannot create an idea or concept and write code in at least one programing language is disadvantaged. The ability to create an idea and write the code to realize the idea is an important skill to have.

The guy who created Facebook was a programmer... the Google founders were programmers.... the early Apple and MS guys were programmers.....

You must be able to work in at least one programming language and write applications, even if only small ones, to be "the best you can be" in the IT world.

As a side note, I know a lot of people who work as "IT Security Consultants" and call themselves "experts". SO, I ask them "what production web site do you manage?" "what hacker attack have you defended against in real time?" ... "what is your actual experience writing any code at all?".... almost all reply "none".. "none" and "none"... in other words, they call themselves "experts" in computer security but never write code, never actually defend a server against an attack... and basically just blah. blah. blah.... about it all.

My advise is not to just be someone who "talks the big talk and uses the big words and concepts".. but be someone "who can actually develop something when needed"......

Big words and concepts are mostly marketing fluff.... the stuff of sales people who could not write a simple app in any programming language.

To be the best IT person you can be.. you must be comfortable programming in at least one programming language, in my view.

As a final note: I am inside "PHP code" sometimes every day of the week... I am not a great PHP programmer, but I really like it... It's fun to have a idea and to build it.. and see the results. To me, programming is a creative license to explore and enjoy the world of IT.
 

10 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

career as a unix admin and new graduate

Hello all, Im about to graduate with a degree in computer science. I think i've found my 'niche' in unix and would like to take it up as a career. I hope you dont mind answering a few questions. How hard is it to get the foot in the door? Whats the best way to get the foot in the door? ... (5 Replies)
Discussion started by: stride6
5 Replies

2. What is on Your Mind?

Unix Career Path

Hi, I've been in the IT field for a few years now, less than 10. I've done a little of everything from database administration, development, systems administration, and unix administration. Although, I wouldnt say I'm a senior level in any of those. Unix definitely stands out in my preferences... (5 Replies)
Discussion started by: NycUnxer
5 Replies

3. What is on Your Mind?

Unix Admin, need a bit of career advise

I posted a request for suggestions on my career, but there was no response. Can anyone please guide me if it was posted in the right forum or thread? Hi Dear, I am in my early thirties and going through a phase of career confusion. Since I am HPUX, Tru64 administrator I need some councelling... (4 Replies)
Discussion started by: mukherj
4 Replies

4. Programming

Unix Career path

Hi, I am having experience on Perl and C# and worked as Windows Sytem Admin and now iam planning to become a UNIX developer. I am having knowledge on basic UNIX.. can any one suggest me any good material for c/c++ UNIX programming. on what all things a UNIX Programmer needs to... (0 Replies)
Discussion started by: chandrareddy1
0 Replies

5. UNIX for Dummies Questions & Answers

Career path help

I am working in a company in which my work includes working on Linux nodes. The "uname -arv" command outputs - "Linux clx28ap01 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux". I generally use various command to stop/start the servers, checking space,... (7 Replies)
Discussion started by: csrohit
7 Replies

6. What is on Your Mind?

Career path help forum

Hi Admins and Moderators, I am already in job for more than 2 years. I need some guidance in deciding the career path. Please suggest what should be the correct forum to post this to ? Rgrds, Rohit Moved thread to appropriate forum. (0 Replies)
Discussion started by: csrohit
0 Replies

7. Red Hat

i want to enjoy and rock my career as linux admin

hello i want to build my career as linux admin.I have completed my Engineering and had one month training on LINUX ADMIN course.I am doing well now in basics.Kindly provide suggetions or advice or books etc etc so that it will enhance my knowledge in linux Redhat. (1 Reply)
Discussion started by: dillipkmrpadhy
1 Replies

8. What is on Your Mind?

Career Path

First I like to say hi to all the people in this community. The reason I am here is because I am lost and looking for advice on my career path. Here is a short history. I worked in the IT industry for about 10 yrs, sys admin, QA, and developer. During 911 I lost my job. Since then I have... (4 Replies)
Discussion started by: navy
4 Replies

9. What is on Your Mind?

UNIX career path

Hi All, This question is regarding career path. I was not sure about which forum I should drop it, so putting it here. I have 12 years of experience on UNIX i.e. majority of Solaris and some of Linux (Suse & Red Hat). Since starting I have been working on 100% administration side and I am not... (0 Replies)
Discussion started by: solaris_1977
0 Replies

10. UNIX for Dummies Questions & Answers

Need advice for my career growth being solaris/linux admin

Hi All, I am having 5+ years total unix admin exp in india (5years solarisadminand 2+ years on linuxadmin).Please advice me which technology I need to learn for my career growth and salary growth. Is it good to go for EMC SAN storage or vmware for higher packages. Please advice me or I... (4 Replies)
Discussion started by: SolarisLinux123
4 Replies
Module::Install::Philosophy(3pm)			User Contributed Perl Documentation			  Module::Install::Philosophy(3pm)

NAME
Module::Install::Philosophy - The concepts behind Module::Install SYNOPSIS
This document describes the personal philosophy behind the creation of CPAN::MakeMaker (the predecessor of Module::Install). The views expressed here belong to Brian Ingerson; if they are not of interest to you, you can safely ignore this document. I HAVE A DREAM
I say to you today, my friends, that in spite of the difficulties and frustrations of the moment, I still have a dream. It is a dream deeply rooted in the Perl Module dream. I have a dream that one day this community will rise up and live out the true meaning of its creed: "We hold these truths to be self- evident: that all Perl authors are created equal." I have a dream that one day even the state of the "CGI::" namespace, a desert state, sweltering with the heat of injustice and oppression, will be transformed into an oasis of freedom and justice. I have a dream that my four modules will one day live in an archive where they will not be judged by the number of their prerequisites but by the content of their source code. I have a dream today. DESCRIPTION
The above is obviously a mutation of the monumental speech by great Martin Luther King (<http://web66.coled.umn.edu/new/MLK/MLK.html>). While the contexts are vastly different, I feel that there are some serious parallelisms. The CPAN has become a place that is not free of injustice. This situation has arisen not out of directed oppression, but from a failure of our community to keep its tools sharp. It is the culmination of many small decisions made in the name of practicality. This is a sad state for an institution that was created to allow all interested people to contribute equally to the best of their ability. This assertion is rooted in my personal experience as an author. When I created my first Perl module, Inline.pm, I knew that I had done something important. But how was I to make a dent in vast Perl community? As a complete unknown in the Perl community, my voice did not travel far. I repeatedly tried to get even an acknowledgment from the gurus familiar with XS. No success. I resorted to sending messages with ridiculous subjects to "modules@perl.org". (http://www.xray.mpe.mpg.de/mailing-lists/modules/2000-08/msg00078.html <http://www.xray.mpe.mpg.de/mailing- lists/modules/2000-08/msg00078.html>) No response. Through sheer determination and shameless self-promotion I eventually got the word out, and I hope the world is a slightly better place for it. Since then, Inline has won awards and I have had the privilege to meet almost all of Perl's finest. But I still remember the pain of starting out, and want to help invite more people into this wonderful world. One thing I have learned from experience is that the Perl community (and throw in the Python and Ruby people as well) is a small drop in the vast ocean of programming. It's a giant pot of Java out there; and a sea of C. Perl may not be the biggest fish, but with some care and cunning we could become a much bigger school. These are the current problems that I see with CPAN and the core modules: o New Modules don't help Older Perls If I were to guess what percent of all Perl5 installations were at the current release level (5.8.0 in October 2002) I would say 3-5%. That may even be generous. I'd say that over 40% of installations might still be at 5.005 or earlier. The biggest problem with adding a module to the core is that it only helps a small subset of Perl users for a long long time. Worse yet, a good module author will still probably avoid using the core additions as prerequisites, because they want their new module to work as well on 5.005 as on 5.8. CPAN::MakeMaker should be able to help in this regard. For example, instead of putting Inline.pm into the core for 5.9, I can now effectively get it into the core for every version of Perl that Inline supports. o Author Exclusiveness Not just anybody can get a module into the core. It seems you have to know people in high places. If I were a brilliant new talent with a great new module, it would have a harder time getting the ear of the pumpking, then if I were, say, Damian Conway. In fact, I probably wouldn't even know where to start. o Reduced Competition One comment I've heard from some very good Perl programmers is "Everything important has already been done". Their feeling is that even though a module is suboptimal, it would be a waste of time to write a competing module. Who would use it instead of the one already in the core? When I write a competing module, I know that I have to make it at least twice as good as the existing one to even get noticed. That's not a bad thing, but should everybody be forced into that situation? For example, let's say that you have created a really useful CGI script. Let's also say that it makes use of your own CGI::Special module, because CGI.pm doesn't meet your needs. Even though your script might be generally useful and worth sharing, the fact that it requires a non-standard module can only negatively affect its acceptance. Trying to get general acceptance for the superior CGI::Special module will be harder still. Core modules are assumed by the general public to be "Best of Breed". While this may be true for some modules at some point in time, it keeps talented people from attempting to "breed" something better. o Core Bloat Every time we add a module to the core it gets bigger and bigger. And we can't ever remove modules from the core, once they've been added. If I had my druthers, we'd remove all modules from the core that weren't necessary for either running Perl or installing modules. Of course, we'd need to set things up so that installing modules was so easy, that it could be done on the fly if necessary. Is this easily accomplishable? Nope. Is it impossible? Nope. We have the best language in the world to help us do it! o Maintenance Bitrot Believe it or not, Perl authors can sometimes acquire a "Life Beyond Perl". They get families or new hobbies or even hit by a bus. (This would be a "Death Beyond Perl".) The fact is, that once somebody writes a piece of code and shares it with the world, they are expected to maintain it for all time. That is being generous. There are others that think that once their module has become popular or made it into the core, they don't need to keep fixing and improving it. I have personally been guilty of this sin. And then there's the Damian Conway Effect. This plagues the exceptional authors who are so innovative and prolific they simply don't have time to maintain everything they have written. I initially formalized these opinions at the YAPC (Yet Another Perl Conference) in June 2001. Since then I have been trying to think of technological solutions to fix these social problems. One idea was dubbed NAPC. NAPC is CPAN backwards. It is a large system of precompiled modules that can be installed on the fly, with the goal of reducing the number of modules in the core. NAPC hasn't got started yet. I'd still like to do it someday, but it's a big problem with a lot of issues. CPAN::MakeMaker (and now Module::Install) on the other hand, is simple and ultimately flexible. It should work with all of the existing CPAN processes without requiring any changes from them. And new features can be continuously added. Even though it doesn't scratch all of my philosophical CPAN itches, it's a good start. CONCLUSION
This is all just food for thought. Take it with a pinch of salt. AUTHOR
Brian Ingerson <INGY@cpan.org> COPYRIGHT
Copyright (c) 2002. Brian Ingerson. This document is free documentation; you can redistribute it and/or modify it under the same terms as Perl itself. See <http://www.perl.com/perl/misc/Artistic.html> perl v5.14.2 2012-03-01 Module::Install::Philosophy(3pm)
All times are GMT -4. The time now is 01:17 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy