Justin, Peop-le who work in IT and only know 1 or two languages are doing themselves and their users a disservice. Not every language is a best fit for all jobs and using the right tool for the job is always the best Idea.
Figure out what you need to do and then pick the language that best suits that job. Yes I'm actually writing end user applications for Windows, the web. *nix and othes so I'm not just writing apps to monitor and manage a network. But that said even then knowing more langs will help you.
The more langs you know the better you will be in all of them. Each language is different and there are some that have different ways to do things but that shouldn't make you not use it. If don't know any langs then buy one of the 'learn X in 24 hours' or 2 weeks books. If you are working on Windows and decide to use one of the Visual X langs buy a copy of visual studio with MSDN. MSDN has lots of info and downloads for you to use in your development. But pay attention to the license so that you don't end up having to pay more for using something out of your development environment.
If you are working in any other language and now Visual studio an IDE like Eclipse works. Eclipse is not just for Java but anything from php, python fortran etc works goos and it integrates with your scm solution. Use scm, and some type of change workflow system.
And then once you get good at the lang of your choice, learn another one. Use them both, see the similarities and differences and contrast them. get good at both and then learn a third. Each new one will become easier to learn. I do at least 1 new lang a year.
Then learn how to use them together. Do your gui in a visual language and the back-end in a lang that handles what you are doing more efficiently. We use a lot of FORTRAN for scientific apps, the conversion of formulas to code is so much easier and the formulas get complex at times, too complex even for c sharp.
Find the parts of each lang that works best for you in each sphere of development you need and use them.
Having the tools in your tool chest to handle whatever is thrown at you makes the job easier and more fun and the on-going learning keeps you sharp and flexible so that curve ball that gets thrown at you can be a hit every time.
Discussion on:
View:
Show:
I find it shocking that Aaron could be become an IT manager without knowing a programming language. How'd he do that?
In some operations the managers are often expected to do as much of the same work as the team, so being able to "do" is essential.
In other IT outfits, the manager is often expected to mostly "manage" and "doing" may be considered a luxury. In these situations the "do-ers" among the staff may not always be considered suitable of management, and replacement managers be brought in from elsewhere. It isn't important that they couldn't find their own backside with a torch and a map, as long as they are adept at hiring those who can do it for them.
It is what it is.
Which one do you think will be of the most value if the company suddenly decided to outsource most of IT?
In other IT outfits, the manager is often expected to mostly "manage" and "doing" may be considered a luxury. In these situations the "do-ers" among the staff may not always be considered suitable of management, and replacement managers be brought in from elsewhere. It isn't important that they couldn't find their own backside with a torch and a map, as long as they are adept at hiring those who can do it for them.
It is what it is.
Which one do you think will be of the most value if the company suddenly decided to outsource most of IT?
So I'm not seeing your point.
Remeber not knowing is much less of a problem than thinking you do.
You want a bad experience as a programmer have a manager who did program but isn't very good at it...
Total nightmare, I can assure you.
Remeber not knowing is much less of a problem than thinking you do.
You want a bad experience as a programmer have a manager who did program but isn't very good at it...
Total nightmare, I can assure you.
I've had a manager who knew almost as much as me, so we understood each other, which was great. He also knew how to manage, which I thought important. It was a small shop, so just like J.Ja's point.
I've had a manager who was technically brilliant, promoted from the floor, but never taught how to manage. Absolute nightmare!
I've had a manager who knew what she didn't know, trusted that I did, and was an excellent manager. Possibly the best job I ever had.
I've had career managers, or "seagull" managers as they were known, because of their habit of pooping on everything and flying on.
And of course the manager who thinks he knows but doesn't, who can't understand why I won't try his solution or listen to my reasons why his solution won't work. Time to update my CV...
I've had a manager who was technically brilliant, promoted from the floor, but never taught how to manage. Absolute nightmare!
I've had a manager who knew what she didn't know, trusted that I did, and was an excellent manager. Possibly the best job I ever had.
I've had career managers, or "seagull" managers as they were known, because of their habit of pooping on everything and flying on.
And of course the manager who thinks he knows but doesn't, who can't understand why I won't try his solution or listen to my reasons why his solution won't work. Time to update my CV...
My favorite is probably the Businessweek manager -- the guy who doesn't know crap about the technical side of things, but uses full-page ads he sees in Businessweek for some major vendor's "products" and starts trying to put his two cents into the technology evaluation process based on the bullet points from the ads. This guy differs from the seagull manager by being a permanent fixture, and from "The Little Engine That Could" (that is, "I think I can!") in that he considers actual technical skills beneath his dignity and thinks of technical experts as interchangeable cogs.
I.T Managers are business analysts who will help the company leaders and managers make good technology decisions. They will gather business requirements and communicate with stakeholders about the technology solutions they need, and will also be proactive in looking for new technologies that can transform the business. These I.T managers can also serve as the companys point of contact with technology vendors and consultants.
u guys can shed more light...
u guys can shed more light...
Well may be.
They could be programmers as well, or may be exotic dancers...
Neither has anything more to do with managing than being a business analyst...
Managing IT people should be about setting goals and providing an environment in which they can be achieved.
Would it help if you knew something about it, yes.
Can you substitute knowing somthing about IT for managings skills. No.
If I was choosing a boss I'd always rather have one who was better at managing than ITing.
Good technology decisions?
You must be new...
They could be programmers as well, or may be exotic dancers...
Neither has anything more to do with managing than being a business analyst...
Managing IT people should be about setting goals and providing an environment in which they can be achieved.
Would it help if you knew something about it, yes.
Can you substitute knowing somthing about IT for managings skills. No.
If I was choosing a boss I'd always rather have one who was better at managing than ITing.
Good technology decisions?
You must be new...
> Good technology decisions?
> You must be new...
. . . or a pointy-haired middle manager.
> You must be new...
. . . or a pointy-haired middle manager.
good, given the earlier statement though I suspect it's going to be ever so slightly different from mine....
There are actually a bunch of IT professionals -- not managers, but in-the-trenches workers -- who don't know any programming languages, either. Of course, while they may be professionals, most of these people will never really be experts. They're mostly glorified button pushers with MS certs.
Are you are talking about the people I rely on to keep the servers running, the email flowing, the backups happening, the databases online, the new computers imaged, the dodgy hardware replaced, the intranet running and indexed, and maintain the infrastructure so that I can get on with my programming?
Speak with respect about them, for without them I could not do my job.
Speak with respect about them, for without them I could not do my job.
> Are you are talking about the people I rely on to . . .
I sure as heck hope not. I'm talking about people that a lot of programmers rely on so they can get on with their programming, but not the people on whom they should be relying.
I have MS certifications. I've been a network administrator. I've been a datacenter technician. I've done IT consulting in a number of different areas, including network architecture and deployment services, integration, disaster recovery, migration planning, and a bunch of other stuff. I've been the kind of guy on whom you might find yourself relying so you can get on with programming. What I was not was a glorified button pusher -- because I cared about my skills, my job, and the services I offered others. I took an interest in the knowledge and skills related to the job, and took an interest in the needs of the people I supported.
The fact that you can't do your job as well as you do without the help of IT professionals does not mean that all IT professionals are worthy of respect, y'know -- just as the fact that programmers provide the software that enables what IT professionals of the non-coder variety need to accomplish at their jobs does not mean that all programmers are genius rockstars. Some programmers are just blub-language daycoders who spend more time trying to look busy while doing as little as possible than actually trying to do their jobs, just as some network and system administrators are glorified button pushers who would have no idea how to deal with a real IT crisis on their own -- and don't care.
I have never met an IT pro who was or could be worth anything who did not either know at least one programming language to a level of admin scripting competence or work at entry level with learning a programming language in the near future. Most IT "professionals" I've met outside of Linux User Group meetings don't know any programming languages and consider learning a programming language beneath their dignity -- and, of course, they refuse to learn how the systems they support work under the hood, too. They learn interfaces, and consider themselves "experts".
If you think that kind of IT "professional" is worthy of respect, I'm afraid there's no getting through to you.
I sure as heck hope not. I'm talking about people that a lot of programmers rely on so they can get on with their programming, but not the people on whom they should be relying.
I have MS certifications. I've been a network administrator. I've been a datacenter technician. I've done IT consulting in a number of different areas, including network architecture and deployment services, integration, disaster recovery, migration planning, and a bunch of other stuff. I've been the kind of guy on whom you might find yourself relying so you can get on with programming. What I was not was a glorified button pusher -- because I cared about my skills, my job, and the services I offered others. I took an interest in the knowledge and skills related to the job, and took an interest in the needs of the people I supported.
The fact that you can't do your job as well as you do without the help of IT professionals does not mean that all IT professionals are worthy of respect, y'know -- just as the fact that programmers provide the software that enables what IT professionals of the non-coder variety need to accomplish at their jobs does not mean that all programmers are genius rockstars. Some programmers are just blub-language daycoders who spend more time trying to look busy while doing as little as possible than actually trying to do their jobs, just as some network and system administrators are glorified button pushers who would have no idea how to deal with a real IT crisis on their own -- and don't care.
I have never met an IT pro who was or could be worth anything who did not either know at least one programming language to a level of admin scripting competence or work at entry level with learning a programming language in the near future. Most IT "professionals" I've met outside of Linux User Group meetings don't know any programming languages and consider learning a programming language beneath their dignity -- and, of course, they refuse to learn how the systems they support work under the hood, too. They learn interfaces, and consider themselves "experts".
If you think that kind of IT "professional" is worthy of respect, I'm afraid there's no getting through to you.
There are no perfect languages, or perfect use cases. If you get into programming at whatever level, you will be learning new languages for the rest of your time in IT.
Justin's choices are good for a network admin. If you are going to be developing for a
c-level (CIO/COO/CFO/CEO) audience, you will probably need to go a different route. I would tell you to look at SQL and SSRS for that.
If you are going into Web development, look at HTML5. Notice the 5 on that moniker. You will build upon your languages as long as you stay in IT. Never quit learning.
If you are designing control systems, pic or C is indicated. If you are designing appliances, *NIx in some version. If you are going to be developing apps for phones, android seems to currently be on top. If you want to develop for IOS, then Leopard X. Will any of these be around in 5 years? Nobody knows for sure. All of these things are changing daily.
The point is, you will never learn enough, know enough to quit digging, learning, growing. If you want stability, you have to get into something else.
Justin's choices are good for a network admin. If you are going to be developing for a
c-level (CIO/COO/CFO/CEO) audience, you will probably need to go a different route. I would tell you to look at SQL and SSRS for that.
If you are going into Web development, look at HTML5. Notice the 5 on that moniker. You will build upon your languages as long as you stay in IT. Never quit learning.
If you are designing control systems, pic or C is indicated. If you are designing appliances, *NIx in some version. If you are going to be developing apps for phones, android seems to currently be on top. If you want to develop for IOS, then Leopard X. Will any of these be around in 5 years? Nobody knows for sure. All of these things are changing daily.
The point is, you will never learn enough, know enough to quit digging, learning, growing. If you want stability, you have to get into something else.
how much it would help.
If you have to manage programmers, internally or externally, then learning the development process and how it affects us would be a great boon, but I'm afraid much of that learning is actually doing it and you've got stuff to manage.
My advice would be to map what you are doing now to prgramming.
Breaking a complex task in to simpler steps. Knowing which must be executed in sequence which must be in parallel. What's the most efficient order toe xecute them, what would be the cost of ignoring that.
There's a lot of arcane bollocks surrounding programming and languages.
Here a simple household chore that an effective housewife and programmer can understand.
Spring cleaning a cupboard with more than one shelf and a fair bit of clean stuff in it.
Empty it from the bottom shelf up.
Clean it from the top shelf down.
If you can figure that out without geting a teacup full of rubbish, and or cleaning a shelf twice, you have the makings of a programmer, and then choice of language, is like choice of cloth and cleaning fluid.
Pick a task you wish to program, choose a suitable tool, learn and do, rinse and repeat.
If you have to manage programmers, internally or externally, then learning the development process and how it affects us would be a great boon, but I'm afraid much of that learning is actually doing it and you've got stuff to manage.
My advice would be to map what you are doing now to prgramming.
Breaking a complex task in to simpler steps. Knowing which must be executed in sequence which must be in parallel. What's the most efficient order toe xecute them, what would be the cost of ignoring that.
There's a lot of arcane bollocks surrounding programming and languages.
Here a simple household chore that an effective housewife and programmer can understand.
Spring cleaning a cupboard with more than one shelf and a fair bit of clean stuff in it.
Empty it from the bottom shelf up.
Clean it from the top shelf down.
If you can figure that out without geting a teacup full of rubbish, and or cleaning a shelf twice, you have the makings of a programmer, and then choice of language, is like choice of cloth and cleaning fluid.
Pick a task you wish to program, choose a suitable tool, learn and do, rinse and repeat.
The best coders are those who write code for fun.
The best managers of coders should, I think, also probably be people who do something job-related for fun. If it involves learning about the development processes and languages used by the coders they manage, that might be great.
The best managers of coders should, I think, also probably be people who do something job-related for fun. If it involves learning about the development processes and languages used by the coders they manage, that might be great.
Talk about code Rot as another TechRepublic article mentioned!
I'm sorry to say this but this article is full of horrible suggestions for any IT manager to follow. An IT manager's task is to manage, not code. Period. Unless he/she is not really a manager but merely a programmer in charge of a couple of other programmers in a small shop. In that case he should already know whatever he needs to know!
A manager needs to be a) ensuring that his staff is performing efficiently and productively at the approriate tasks for the given time and b) making sure that his staff is getting their training needs satisfied - NOT learning to program in languages such as the ones mentioned herein. Personally I never heard of any of them, but if the manager is in a shop where these things are not already in use, then he certainly should not be bringing them in for his own personal use. How silly - a manager programming in something that nobody else in the unit understands! What a legacy to leave behind should he/she leave for greener pastures.
If the manager's role is clearly management, then learning to program is the Least of his worries. In today's IT shop there are so many more concerns than coding, I don't see how a manager could even consider devoting one second to learning anything more about coding than he/she already knows. Stick to what you are supposed to be doing and let your programming staff do the coding - in languages that facilitate the kind of work being done and that others are going to understand.
BTW - I'm a retired IT manager myself so I know of what I write.
I'm sorry to say this but this article is full of horrible suggestions for any IT manager to follow. An IT manager's task is to manage, not code. Period. Unless he/she is not really a manager but merely a programmer in charge of a couple of other programmers in a small shop. In that case he should already know whatever he needs to know!
A manager needs to be a) ensuring that his staff is performing efficiently and productively at the approriate tasks for the given time and b) making sure that his staff is getting their training needs satisfied - NOT learning to program in languages such as the ones mentioned herein. Personally I never heard of any of them, but if the manager is in a shop where these things are not already in use, then he certainly should not be bringing them in for his own personal use. How silly - a manager programming in something that nobody else in the unit understands! What a legacy to leave behind should he/she leave for greener pastures.
If the manager's role is clearly management, then learning to program is the Least of his worries. In today's IT shop there are so many more concerns than coding, I don't see how a manager could even consider devoting one second to learning anything more about coding than he/she already knows. Stick to what you are supposed to be doing and let your programming staff do the coding - in languages that facilitate the kind of work being done and that others are going to understand.
BTW - I'm a retired IT manager myself so I know of what I write.
Did you go to business school? There seems to be a culture of considering technical skills too lowly to touch amongst business school graduates. Y'know what the technically proficient people doing the work call those guys?
Well . . . most of the names would be censored by TR's language policing code, so I won't repeat them here. One of them is pretty tame, though: "out of touch".
These are the kinds of managers for whom every person they "manage" feels contempt -- people who not only don't know anything about the people they manage, but don't want to know.
I'm glad I never had the displeasure of working for you. The fact you've never heard of the languages mentioned (Really? Where have you been hiding that you've never heard of C?) is a great big red warning light, with sirens going off. Unbelievable.
I'm not sure whether you're the actual person who inspired the Pointy-Haired Boss in Dilbert or a troll.
Well . . . most of the names would be censored by TR's language policing code, so I won't repeat them here. One of them is pretty tame, though: "out of touch".
These are the kinds of managers for whom every person they "manage" feels contempt -- people who not only don't know anything about the people they manage, but don't want to know.
I'm glad I never had the displeasure of working for you. The fact you've never heard of the languages mentioned (Really? Where have you been hiding that you've never heard of C?) is a great big red warning light, with sirens going off. Unbelievable.
I'm not sure whether you're the actual person who inspired the Pointy-Haired Boss in Dilbert or a troll.
I have been doing this a very long time in computer terms. I have worked for both clued and clueless managers. Been one or the other a few times. But the end all and be all of IT managment is getting the work done. I don't know how anyone successfully does that unless they know what their primary resource is capable of and what the problems and limitations of their chosen tools are.
Managers who are not the absolute best worker on a team, in my experience, are only sucessful when surrounded by superstars and have the maturity to be an enabler, not a manager. These people basically are super gofers, providing support for a team, and then getting out of the way. The problem comes in when the team hits a wall and needs guidance. Without indepth knowledge, the team has nowhere to go except outside. Very expensive, and time consuming.
Managers who are not the absolute best worker on a team, in my experience, are only sucessful when surrounded by superstars and have the maturity to be an enabler, not a manager. These people basically are super gofers, providing support for a team, and then getting out of the way. The problem comes in when the team hits a wall and needs guidance. Without indepth knowledge, the team has nowhere to go except outside. Very expensive, and time consuming.
If I'd thought of it at the time, I would have mentioned the "super gofer" option as well -- which also seems to stand in stark contrast to the kind of manager ginerjm must have been. In fact, I think your description of that managerial style was better presented than mine would have been, so thanks for picking up the slack. The guy claims to be a retired IT manager that has never even heard of Perl, after all -- probably amongst the worst IT managers who ever lived.
As a long-time development manager (the most fun job for me) and VP of IT in large corporate worlds, you describe what I think makes a good IT manager. IT managers are stewards of good people. YOU are not responsible for designing elegant solutions or writing good code...but you are responsible for the people who are paid to do that. YOUR job as an IT manager is to be there for those people (who make your job easier) and make sure they have the things they need to accomplish their mission. Whether that is having budget for another team member, access to a decision maker or even a good dinner while they work late at night.
Long ago when I was coding CICS Assembler late at night, I wondered why my boss stayed late with us every night even though he couldn't code one line of Assembler, C or COBOL. But he would leave about 6:30 every night and come back in less than an hour with pizza, chicken, tacos or whatever. He made sure he did his job by giving us the resources we needed WHEN we needed them. This was the 80's and he even went and bought a 12-pack of beer or more to end our night. And when we delivered our code to the client on time, he looked good. And he should have! Cheers to you, Gary! You taught me well.
I have always taken this approach to managing teams and departments and it has always been rewarding. Treat people well and they will treat you well. Give them what they need to do the job and get out of their way.
Long ago when I was coding CICS Assembler late at night, I wondered why my boss stayed late with us every night even though he couldn't code one line of Assembler, C or COBOL. But he would leave about 6:30 every night and come back in less than an hour with pizza, chicken, tacos or whatever. He made sure he did his job by giving us the resources we needed WHEN we needed them. This was the 80's and he even went and bought a 12-pack of beer or more to end our night. And when we delivered our code to the client on time, he looked good. And he should have! Cheers to you, Gary! You taught me well.
I have always taken this approach to managing teams and departments and it has always been rewarding. Treat people well and they will treat you well. Give them what they need to do the job and get out of their way.
The reader is the manager of a *small* IT department, where it is not uncommon for people to have to wear "many hats". I manage a small (two person) IT organization myself, and while I don't *have to* know how to program, it's certainly been handy, and it's allowed my employer to use me to write internal systems that we'd either do without or have to bring in an expensive consultant to do. Furthermore, having someone in the role who understands both sides of the fence makes it much easier to get things done, especially troubleshooting.
I also agree with apotheon's sentiments, in that being able to understand the work allows you to better work with your employees. What kind of manager are you if most of what your people say flies over your head? It's up to the IT manager to translate the tech to the business, not the tech folks to explain the tech to the IT manager...
J.Ja
I also agree with apotheon's sentiments, in that being able to understand the work allows you to better work with your employees. What kind of manager are you if most of what your people say flies over your head? It's up to the IT manager to translate the tech to the business, not the tech folks to explain the tech to the IT manager...
J.Ja
Judging by what I've read about this joker's managerial advice, I suspect he didn't bother even asking his people to explain anything to him. He probably just tried to pretend he understood everything.
You are just casting flame bait by saying you've never heard of 'C'...
http://dilbert.com/strips/comic/1994-02-04/
I wouldn't be so certain in what a manager needs to know and then make that exclusive to the universe of what is 'knowable.' Based on your rant one could be led to the conclusion that spreadsheet and word-processing software should not be in a managers repertoire.
http://dilbert.com/strips/comic/1994-02-04/
I wouldn't be so certain in what a manager needs to know and then make that exclusive to the universe of what is 'knowable.' Based on your rant one could be led to the conclusion that spreadsheet and word-processing software should not be in a managers repertoire.
My next language is going to be Perl. Have C++, Basic, Assembler, Pascal, Atlas, PHP, SQL. I am a network admin (Novell, MS, Linux) ( MCSE, CNE, Linux +) and have had the unfortunate title of IT Manager. Start Perl next semester. Hve been in the game for 25 years. Would there be any way I can get out of this game and still make a living? I am tired of chasing the next cert, language, etc. Doctors don't keep having to go back through medical school every 3 years to be able to practice medicine. This is insane.
If you don't love information technologies, you should be doing something else. Figure out what you would love to do, then start working on getting qualified to work in that field. Don't be afraid to take a pay cut when you make the transition (unless you're in debt to a murderous loan shark, I suppose).
People are better at their jobs when those jobs match their passions.
People are better at their jobs when those jobs match their passions.
will pay reasonable sums of money for you to do it instead.
If you don't like it, do something else, there's loads of people who want to do it, currently out of a job..
If you don't like it, do something else, there's loads of people who want to do it, currently out of a job..
In fact, it looks like I'll be starting a new job specifically because it offers opportunity to learn a couple of programming languages beyond the meager extent to which I've already experienced them. Learning is addictive, and programming is interesting. Anyone who disagrees with this should probably not be working as a software developer.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
