Leadership

Hire learners, not people with specialized skills

When hiring, should you go for the person who has a lifetime acquiring an insanely deep knowledge of a small subset of tools or someone who can rapidly pick up any new tool?

One of the disturbing long-term trends about careers in IT, and perhaps in the business world in general, is a preference for deeply-specialized individuals covering an extremely narrow body of knowledge. In IT, this is usually characterized by demands for myriad esoteric certificates, and job descriptions that demand ten years of expertise in a programming language that's existed for seven or rattle off technical bullet points that look more like the specifications sticker on a new car than a list of talents any normal human would possess. In short, our bias seems more toward niche specialties than a competent learner.

The source of this "nicheification" seems to come from the increasing complexity of technology. How can our hiring shortcuts like keyword searches and résumé categorization tools work if we don't build the process around "features" rather than true experience? Furthermore, if our immediate need is an experienced Java developer, shouldn't we demand years of experience slinging Java code? Not necessarily.

Hire learners, not niche players

True niche players can be some of the worst hires. If they've spent a lifetime acquiring an insanely deep knowledge of a small subset of tools they are innately biased toward those tools. They see every problem through the lens of that tool, and are resistant to adopting other technologies or practices since they are a threat to that hard-fought knowledge rather than a potential better way. Furthermore, when your entire career has been structured around nicheification, there's little potential for leadership or management, skills that are learned rather than innate, and generally ignored when your search targets a niche player.

Contrast that with the lifelong learner. I have the occasional pleasure of working with a lifelong learner (usually reverently described as a technical "wizard") who can rapidly learn new development tools, and is always interested in exploring what's new. This person has no allegiance to a particular tool beyond wielding what seems best for a particular job. Rather than jealously guarding esoteric knowledge about a favorite programming language, this person hits the manuals and gets the job done, learning as he or she goes.

Usually the lifelong learner applies this same knowledge to the company where he or she works, gaining a working understanding of the company and applying that knowledge to his or her work rather than considering that knowledge outside their purview. The upshot is that someone who understands the business problem being considered will likely produce a far more effective answer to the business problem, even when it's not the most technically elegant solution.

Lifelong learners also have the benefit of changing with the times. Today's Objective-C could very well be tomorrow's Fortran, and as the lifelong learner has no particular allegiance to the technical tools, they evolve technically while their knowledge of your business grows deeper. The lifelong learner can also evolve away from their technical roots, growing into project management or a leadership role, usually with great success, since leadership is simply another tool to be learned and applied.

Sounds great, why doesn't everyone do this?

Like most good advice, this is conceptually simple but difficult to implement. I often draw the analogy to weight loss, where eating less and exercising more is nearly 100% effective, but difficult to successfully apply-as evidenced by the barrage of weight-loss shortcuts that befall us each January in time for New Year's resolutions. To acquire lifelong learners necessitates more diligence in your hiring process. Rather than looking for deep niche experience, look for a variety of experience. Look for someone who has worked with a number of different technical tools, or been successful in a variety of industries. Base your interviews around demonstrated ability to go into an unfamiliar situation or understand a new business problem, then learn and apply the right tools rather than asking technical trivia.

Identifying lifelong learners will take diligent effort during the hiring process, but will provide you with a flexible and capable technology team that will last far beyond the "next big thing" in IT.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

72 comments
RMSx32767
RMSx32767

How old is a life-long-learner? Probably a wee bit longer in the tooth than the wiz-bang wunderkind who knows Java and perhaps not much else that does not orbit around MS.

minstrelmike
minstrelmike

Steve Jobs said A companies hire A people (lifelong learners). If you hire B people, they end up hiring C people and then the bozofication of the company starts. It doesn't matter how hard it is to discover that in the interview. Hire several and fire the ones who don't work out after 6 months. I think another aspect of the problem is that companies try to find the perfect fit during the hiring process instead of VALIDLY viewing it as a 6-month or year-long process. Sure, there is always a stated probationary period, but is there really one in fact?

fhrivers
fhrivers

The fact of the matter is that alot of IT Departments should be more involved in the hiring process. And I'm not talking about the Hiring Manager. More often than not, the Hiring Manager is just as clueless. I've seen large software companies screw this up with the "Laundry List" A to Z job descriptions that look like an IT inventory list than a job description. HR should get input from the hiring manager and the hiring manager needs to get input from the people in the trenches. More often than not, however, HR uses a compensation tool from an HR software vendor which has canned job descriptions and titles that line up with a specific salary. Anything outside of this point and click system is outside of HR's scope and they have no way of determining what the salary should be. Oftentimes the only correspondence between HR and IT is "Please tell me what needs to be added to this list". Then the time-constrained Hiring Manager simply adds a list of skills that the previous or other person in that position has and returns it to HR. One of the most annoying aspects of this is the "years of experience" with a certain technology. Technology changes so rapidly that this is a useless indicator of skill level. For example, you cannot assume that someone working with Exchange 2000 for 10 years and can claim "10 years of Microsoft Exchange experience" can just jump into Exchange 2010. The architectures between the two are completely different. I've seen senior engineers struggle with it, but then I took a Microsoft online course to update my skills and I was running full speed on Exchange 2010 within weeks (I had previous experience). This one example shows how HR laziness is a huge problem that can be remedied by simpler job descriptions and an intelligent interview process. Why is a job description for a brain surgeon smaller than a job description for a systems administrator? Something's wrong here...

jsargent
jsargent

Why do people have to believe that someone with specialist knowledge cannot learn more things? Learning new things is about character and doesn't depend on the employees previous experience. However, if you need that experience then you can't expect everybody to be able to learn it on the job. You choose these people to avoid delays. If you think that they are no worth it then offer less.

sboverie
sboverie

I used to work as a computer field customer engineer, I worked on a variety of computers with a mix of software. As a field tech, you have to learn a broad but shallow range since equipment is different from site to site. I have also worked as on onsite technical support and found the difference to be that most sites have a more limited variety of equipment. As onsite support you learn a narrow range but very deep range. In respect to the article, I would look for someone who has a broad range of experience over someone who has a narrow range. I would look for someone who does understand how the hardware works and not just how to program it or install applications over someone who can program on a multiplateform but couldn't tell which is the processor and which is bus master. A person with broad but shallow experience has the basics for more things than perhaps a narrow but deep tech. The broad but shallow would be able to expand from any of those basics to get to the narrow but deep learning without getting stuck in the first narrow but deep rut.

Professor8
Professor8

Most people who make good software developers have a background in music -- vocal, instrumental, composition (not just listening to their iPod or the radio). They tend to be most satisfied in programming and the most consistently productive. (This isn't just coming from me, but from some studies and anecdotal reports in the media going back 2-4 decades that old pros pointed out to me.) I've also worked with a few great software and hardware people with backgrounds in chemistry or classical languages & literature or psychology or physics. Those are a bit more hit or miss. Many in these fields who pick up programming from one or two elective classes or on their own tend not to write very good software. Some write terrible code, amorphous, buggy, fragile, but can work well with others. Some can learn how to develop reliable, maintanable software through additional class-work or on-the-job work with other software developers. Med school and law school grads are hit or miss. Anthropologists seem about evenly split; some take to it, and some just flat do not, while many physical anthropologists have the makings of respectable or even super-users. Once in a very long while you'll run across a B-school person who is good with hardware or software, but it's extremely rare. The vast majority, with significant investments in intensive training and vocational rehab, might make halfway decent garbage collectors or janitors, and the best of the lot just might be able to develop the skills to do a decent job bagging groceries. But, again, there are rare exceptions. Most "liberal arts" people don't pretend to know anything about software development. They know their limitations and their knowledge is miles wide and only a little deeper than the B-school and education/normal school grads, but because of that, they can often work to extend their abilities more than the more in-between people. Data-base work is a little different, and there is a wider range of backgrounds and subject-area knowledge that they can sometimes bring to bear.

cdasso45
cdasso45

Being an IT professional for over 25 years as an independent consultant for most of those years, I have been a "life time learner" both in technology and industry; the life of an independent consultant, correct? Now as a manager, I only hire learners; it works to make a very good team.

bobc47
bobc47

When push comes to shove the chances are the learners will come up with the answer because they learn how to leverage past experiences. The ones with deep specialty knowledge are not usually flexible enough to look at related disciplines. My old boss would wander into my office and ask how can we do this? I'd sat that I really don't know and he would say find out! This was before the internet so I'd call some colleagues in related fields and then head to the library or the book store to find out. He knew I'd find it if he lit a hot enough fire under me. The key is i was taught to take existing knowledge and use it to find out about things outside of that sphere. That was the era that saw us go to the moon using little more than a slide rule and a pad of paper.

pbvprasad
pbvprasad

How can any one become skilled unless they are learned ? Hence once they are learners they will continue to do so. THe fast you learn at the sape speed you may loose also. Hence try to maintain balance by continual approach of ISO 9001-2000 style. People feel they are going to reach high & high if they learn learn & learn. In reality there is a limit for speed wrt to time. After all one has to live life and earning and learning is not the real goal.

ssplate
ssplate

I wholeheartedly agree with this. My experience goes back to Fortran IV and punched cards. I managed to keep fairly current changing with the times and can write Java, a couple of strains of C, know about Oracle and SQL Server and a lot of other stuff. Then I was laid off at age 60. It was anguishing to have a 30 year old tell me that I was probably slow and might have difficulty learning new tools. I suppose this guy didn't realize that I had been learning new tools for longer than he had been on the earth! I'm again employed but I'm sure not doing what I could be doing. Oh, no, there is no age discrimination! Oh, not in that hot field of IT!

cmrpm
cmrpm

Weather or not to select specialists for short-term contracts or investing in long-term hires that can grow into their roles is a risk-return equation. Culturally speaking, some organizations will prefere to make longer term committments to their IT staff so as to capitalize on what that might bring to the organization over the long-haul. I would suspect these environments experience slower paces of change. At the opposite end, organizations that are rapidly and frequently experiencing change, using a hired-gun short-term can get the desired major results and then later, a longer-term, less (initially) skilled and lower-paid technician can inherit the operations after all the hard work is done and most major kinks worked out. Also too, I think it depends on the upper management of IT and perhaps the organization that favors keeping budgets low (i.e. not taking on too many FT employees) as well as what kinds of staff they work best with. Back in the mid-to-late 90s I recall a number of now defunct IT behemoths jokingly referred to as training/certification farms where relative newbies were hired and given access to near limitless training budgets. They'd get their 1yr experience and a handful of 100% company-funded certs and then leave for a higher paying gig. The companies would just repeat the cycle and never maximize on those human capital investments.

blarman
blarman

It would be nice if companies were interested more in someone they could train than someone who already knew things, but here are some of the nuances: 1) How do you know they can learn quickly? 2) What documentation and people can you provide them access to to facilitate this learning? (Please note that the people involved will take a hit to their productivity - including management.) 3) How long are you willing to wait to find out if this person will end up being productive, ie how much money can you afford to blow on a bet (and what do you do if it doesn't pan out)? 4) How long do you foresee the systems this person works on being in production? I'm not against the idea, only those devilish details that frequently get in the way. This is a strictly a risk v reward scenario with a very high risk and reward. Most businesses I know of are low risk and therefore don't choose this road. One more thing: If they really are learners, what is to say they won't get bored with your job and move on?

jsargent
jsargent

If I need someone who is experienced in EFT banking transactions software engineering, 24/7 embedded solutions software engineering or a medical physics Engineering can I take the risk that he will "pick it up" while on the job?

Mansuro
Mansuro

That's the problem with people who do the hiring. They expect a candidate to be excellent in some fields, and ask them about details in those fields, a very minor detail that someone wouldn't know it unless they saw it before. They don't take in consideration how brilliant a candidate could be just because he had not the occasion to work on some particular aspect of a particular technology.

jsargent
jsargent

Older professionals have gone through more changes than younger professionals. Why suddenly assume after 20 years or more of learning that they don't still update their skills?

Tony Hopkinson
Tony Hopkinson

How do you know a specialist is required. The narrower the discipline the more likely you'll be right, but the less useful that person will be if they want or need to maintain their speciality. Capable is irrelevant, staying current and working in our game requires a considerable effort. As soon as you step outside "knows everything about Acme Corp's router" or some such, domain knowledge becomes more and more valuable. I'd take a decent programmer in a language we didn't use if they had domain knowledge over a better one in one we did with none anyday. Any decent programer can figure out a loop, knowing say tax, or insurance or trading, and the mindsets of businesses that do them takes much longer.

dogknees
dogknees

You do not forget one set of skills when you learn a new set. You retain both. Most people will never even get close to the point where they are simply incapable for learning anything without losing something else. I would also disagree with the statement that learning is not the real goal. It's the primary goal for most of us, though we might not recognise it. It keeps us going and makes life interesting and worthwhile. Without learning, there is no change, no progress.

Tony Hopkinson
Tony Hopkinson

most others must too. Not true I'm afraid. We have a huge population of jobsworths, with no real interest in IT's disciplines, who at best force themselves through the absolute minimum of learning in order to get paid lots of money. :p They can walk in with a shiny bit of paper, talk a good game fool incompetent hirers, better still they are cheap.... Learning is my goal, always has been, people prepared to pay me for it, or to do it, are the icing on the cake.

Professor8
Professor8

You can be skilled without being learned, and you can be learned (knowledgeable) without being skilled. You can be knowledgeable without having academic credentials. You can also be experienced without having academic credentials. And you can be productive without necessarily being extremely knowledgeable, experienced, or having academic credentials. There's also a matter of being in work situations where you can make use of your best learning mode and other work situations where you cannot. I've seen people who seemed to be dead weight, didn't seem to be very bright or industrious... right up to the time when we needed to do something that put their optimal learning- and work-modes and knowledge and talents to best advantage. It was like a light switch turned on and they shone. Before that, they were being wasted to both their own and our detriment.

blarman
blarman

My father worked at a Fortune 50 company for 22 years before getting laid off. Now he can't buy a job due to his age and two successful rounds of cancer treatment. Instead, he has to settle for teaching high school algebra and other assigned topics for one of those college-substitute schools because noone wants to hire a software engineer/project manager over 50.

jsargent
jsargent

If you have to put up with that then start out on your own. Your grey hair will give the customers confidence that you know the business.

Professor8
Professor8

Because they have in the past. But you open another question. Should you focus only on how quickly they have learned, or should you do some balancing of how well AND how quickly they learn? If they really are learners, what is to say they won't get bored with your job and move on? So, you never do anything new, never add new features to your software product, never develop new software products that do something a little differently from your old ones? Maybe you don't deserve to have bright, talented, creative, industrious Americans working for you, because their abilities can be better applied elsewhere.

Neon Samurai
Neon Samurai

If they learn the job and improve it to the point where they are bored, it may make sense to premote them if they can then learn how the team works and refine it's processes and so on. "bored" also has to do with the management above them; are they given time to learn other things or work on there own projects when time does not impact the company's current projects? Are insentives provided which keep them from leaving your employ?

Professor8
Professor8

That used to be the rule. You would build a team. Depending on the specific product-set, it might consist of medical people, mathematicians, engineers, hardware, and software specialists; SCADA, engineers, hardware and software specialists (e.g. power systems control); bankers, accountants, security, hardware, and software specialists; economists, statisticians and software specialists (e.g. when I did economic modeling and accounting); engineers, mathematicians and software specialists (e.g. when I worked on CAD/CAM/CAE software and nuclear weapons systems); architects, mechanical engineers, and software specialists (e.g. when I worked porting structural analysis software); rocket scientists and engineers, hardware and software specialists (e.g. when I worked at a NASA research center); statisticians, mathematicians and software specialists (e.g. when I did development and porting of statistical analysis software product); criminologists and software specialists (e.g. when we were developing data-mining tools for tracking patterns and spotting crime hot-spots; well, OK, our CEO was a nuclear physicist); criminologists, statisticians and software specialists; biologists and software specialists (e.g. a room-mate's EPA contract to develop water quality index)... They might not all know your hyper-specific niche, but together they have what it takes to get the job done well. And, besides, you should invest in 2-12 weeks of new-hire training (with some substance to it), and 2-4 weeks of retained employee training each year. These used to be the norm... before the bodyshopping scourge.

Tony Hopkinson
Tony Hopkinson

is the common denominator. Domain knowledge, depends on what sort of support you give your people. We use Domain specialists and software engineering specialists, finding people with both is a bit difficult.... The risk isn't that you employ someone who can't now, it's can't ever, or much more likely thinks they can now....

trenawynn
trenawynn

I just graduate from college with a BS in Information System. It seems as if you do not show any type of skill that you have done at a previous job. The door stay close, how can I learn any skill that you are hiring for if you don't give me a chance to show how fast I can learn that new tool or skill. It has been so hard to find something in this field. I am really eager to learn, if you do not know any one to get your foot in the door, it seems as though you are out of luck. But overall I will just keep trying until someone will give me a chance. With any business you have to think outside the box. I agree with you guys. Hire the learners and see how you can expand to greater levels. Someone told me a great analogy to this concept, " we all had to learn how to ride a bike at one time in our life". If someone did not take the time to teach us would have never learn how to ride a bike.

jsargent
jsargent

If you don't know then you shouldn't be hiring. Everyone from a banking manager to programmers and doctors have a duty to stay current in their profession. If they are not current then they are not professional. Any decent programmer can...? No it takes experience to understand how to handle critical problems that customers face on a daily basis. If it doesn't get solved in a hurry your company can face financial penalties. That's customer centric and company centric. The problem is that managers both in HR and the hiring manager are not capable of either communicating correct requirements or cannot tell if the CV meets the requirements. Sometimes it's laziness, sometimes incompetence and sometimes it's lack of time and resources.

blarman
blarman

"You do not forget one set of skills when you learn a new set. You retain both." This goes contrary to the human brain. "Use it or lose it" is very applicable. It isn't as if you lose it all and you lose it immediately, but if you haven't programmed in Cobol in 10 years, its not like you're going to be able to jump into a project and write perfect code like you could 10 years ago. The longer away from any given technology, the less recall you will actually have.

tbmay
tbmay

...we have to eat to. The way business wants to list a bajillion specific versions of specific software..and languages...as job requirements for a 3 month (or less) gig made me discover that "learning" the way they envision it is simply not possible for me. And I'm not playing that game any more. They're idea of a good hire is someone who can spout off the exact mouse clicks in a menu of software X version 2009, off the top of his head. My mind doesn't even work in the manner of memorizing menu locations, and I'm not going to try to force a square peg in a round hole. That target market doesn't work for me.

jsargent
jsargent

Unlucky, I'm sorry about the cancer and I hope that it doesn't come back. I think that teaching in high school is an excellent and worthy calling. Although the money might not be what he wanted, I think this is something that many people wish they could do.

blarman
blarman

"So, you never do anything new, never add new features to your software product, never develop new software products that do something a little differently from your old ones?" Precisely. Most programs have a maintenance period. It is during the maintenance period (generally) that the ROI for the project is to be had. It is during this maintenance period where you are trying not to change a lot that these adventure-seeking learners get bored. If you choose to go this route when hiring, you would do well to keep these learners occupied during the maintenance period or risk losing them to a more exciting project. Of course, that may be okay, too.

jsargent
jsargent

If I have someone who will get bored rather than completing the last 5% of a project then I don't need that person and he is not worth promoting. If you get all the job done well then you get promoted. That's why I like employees with families. They don't get bored no matter how good they are. In most companies you learn at home. That's not good but its just the way it is. I never had time to think about being bored even when the last 5% of the work took 20% of the time. 20 years ago I used to think the same way but it's not like that in reality. ps. when I was a student I was a PDP11 system hacker. You've never seen wire-wrap like that in a mini. It was fun but it was only so we could find out how it worked and we did club together to buy the machine second hand.

spawnywhippet
spawnywhippet

"you should invest in 2-12 weeks of new-hire training (with some substance to it), and 2-4 weeks of retained employee training each year." I was recently hired by one of the largest IT corps in the world. I got a 3 hour induction course 1 month after I started. And now I am supposed to know everything about how this mammoth company works, how to file expenses, bill my time, login to various systems, etc etc. I am also expected to learn new technologies on the fly, eg I am the country's 'cloud expert' because I spent a few evenings watching canned powerpoints online.

Professor8
Professor8

I've known HS students working on commercial products. A degree is mostly beside the point. The terms you are seeking are "internship" and "co-op". An internship may be paid or unpaid, last just a month or several years. Co-op programs usually involve alternating terms -- you work one term and take classes the next, then back to work. One of the first -- in aeronautical engineering, including both the work and the academic curriculum -- was co-developed by Orville Wright. Of course, another traditional way to get experience is to work for the university -- under a federally-funded "work-study" program, or other arrangement -- as one of the staffers who does tech support (hardware or software), makes mods to the operating systems, sys admin, network admin, applications porting and development (hw & sw), giving lectures on specifics of how to use the apps and systems at the U, etc. There are lots of students employed both on the U admin side and the academic research side, and they always need lots of tech support people now that nearly every student and faculty member is a computer (or mobile device) user. Many people have learned how to ride a bike without being taught. Another path is to develop your own program(s) and use that (them) as the basis of a portfolio, just as an art student has to develop a portfolio of works, and a music student has to have a repertoir. Which path is best for you depends on your own best development path; it requires some introspection. How do you best learn a new "skill"? Do you do best with others coming up with challenges and then going off to meet them on your own (or collaborating)? Are you an auto-didact (self-learner) or should you go back to school or to specific training classes? Do you have the money to take such classes?...

blarman
blarman

Agreed. There is much to be said for business familiarity. Every business does things just a little bit different. In addition to the technical skills (which were the focus of this article), there are also the processes the business employs to get things done. Every business has its quirks, its red tape, and its own ways of doing even the most routine things. It is made simpler to navigate these when the business takes time to document them, but there simply is no substitute for time and experience in these matters, and they aren't something anyone from the outside will know. This is the primary reason why outsourcing can be such a nightmare even when dealing with technically astute people - there is still a significant learning curve that is non-technical relating to how the business does business that must be reflected in the software designs. I think that the most successful hires are going to be those who can learn not only the technical but learn it as it applies to the business, which can be a wholly different beast entirely.

RMSx32767
RMSx32767

"Staying current" is not always as helpful as having useful knowledge within the environment. More than once my so-called legacy knowledge made the difference between meeting the needs of a client, or telling them "Sorry, we can't process that data. Could you send it in a format our "current" folk recognize?" Even so, there was amazement when I debugged "current" despite being viewed as not knowing the current.

Tony Hopkinson
Tony Hopkinson

I never said soft skills weren't important, the less of a specialist you are, the more important they are. Domain knowledge is an obvious aid to communication, there's enough difficulty surmounting the technical barrier, without not knowing the bloom they are talking about is a big lump of metal.... I got the distinct impression you were talking java or IIS 7, or SQL Server 2008 R2, as specialist, as oposed to OO programmer, web master, or DBA, feel free to correct such a misunderstanding. HR and management are incapable of discerning requirements for people. The concept of tool = skill is rtheir way of saying not me guv, when they employ the wrong person. If they concentrated more on employing professional as oposed to some twit with a piece of paper, they'd have a chance

Tony Hopkinson
Tony Hopkinson

Delphi , back to Fortran, I struggled a lot. Not so much losing the OO add ons to procedural as all the extras that come with it. Like rembering to intialise variables and such. The real problem nowadays is they are teaching kids from OO, so they don't know that it is procedural. Academia has bought into the tool = skill fallacy as well.

Tony Hopkinson
Tony Hopkinson

Can get OO, and vice versa, they should get functional also. Some of the head switches particularly if you've never done it can be a bit of stumble, but if you can't, you aren't. Some of us are more comfortable with some tools, some of use have more experience with some tools, but skill is how we use the tool, not which tool we use. Donb't get me wrong, familiarity with the tools in use is an obvious +, but if you accept the tool = skill fallacy you get to be the HR type,who won't take a .net3.5 coder on for a .net 4 job. It's that sort of ignorance we need to combat, my way of doing so is to keep tool and skill separate. I'm not picking on you, I pull my boss who is / was a programmer up for it as well. :(

blarman
blarman

I agree. I just wish that those doing the hiring understood the difference between the tool and the methodology. The other part that comes up is how few businesses are willing to train without really understanding that it takes time for people to even acclimatize (read LEARN) to the business itself and how things get done. I think a lot of businesses delude themselves into thinking that anyone off the street can magically insert themselves int a new job like interchangeable parts. Studies have shown that it is typically at least one month and that hiring a new person costs about $10,000.

RMSx32767
RMSx32767

I dare say, and have been told, 'tis easier for the person familiar with procedural to migrate to OOP, rather than the other direction. Besides, OOP is not a new concept.

blarman
blarman

There is a huge difference, however, between an object-oriented language and a procedural language. They require different mindsets - the skill you are referring to - to be able to use. The difference between a method and a package is substantial, if subtle. So while I agree that "programming" is a generic skill, it is more properly broken down into a type of programming. And so for those who have never programmed, they skip to the end and list the actual tool and say "Have you ever used a 3/4" socket wrench" and don't know that someone who has used a 3/4" open-end wrench can also get the job done.

Tony Hopkinson
Tony Hopkinson

The idea that a tool is a skill is a lie perpetrated by the training and certification boyos, to promote the idea we are usless everytime some vendor rearranges a menu and renames Find to Search or some such bollocks

RMSx32767
RMSx32767

True, that. The skill is "programming". Sometimes the proper tool is CoBOL; sometimes it isn't.

Tony Hopkinson
Tony Hopkinson

It's a tool. If you can program, you'll be more competent within two weeks, than some jobsworth who's been doing it for ten years. There's no such thing as perfect code, even if there was there's no desire for it in business. We are programmers not parsers...

Tony Hopkinson
Tony Hopkinson

Unfortunately business has headed down the path that being able to tighten a nut, makes you a mechanic, or even an engineer. :( I don't operate in that market either, where the option is has changed too many times over my career, whether to use it or not never has.

jsargent
jsargent

Those people need to start up their own businesses. (Although in my experience they tend to be prima donnas who think they know.) When they start a business they will have all the satisfaction and dissatisfaction that goes with the life that they dream of.

Neon Samurai
Neon Samurai

The post I replied to suggested the risk in hiring life long learners is that they get bored and leave the job or company rather than those you suggest get bored with the work but stay in the possition collecting a paycheque while becoming less and less productive. Given the context of life long learners, I was thinking more of the person who becomes bored because they have automated there job processes already or otherwise consistantly complete tasks with time to spare. They have learned all they can in the job possition and refined all they can in the work flow. Neglecting them pushes them to find a new employer with new learning opertunities. Recognizing and premoting them provides new learning opertunities and benefits the company if they can refine the team in the same way they have refined there job within it. If they are not management types, a latteral movement to a different job can provide new learning opertunities leaving someone to learn from what they've done in the old possition potentially starting a cascade of learning. In short, descriminating against life long learners because of the risk that they will leave the company shows a problem with the company itself. Now, if you have someone not completing work because they get bored with it then yeah, that's a problem for management and HR that won't be solved with a premotion. Well, except in companies governend by "premoted to the level of one's incompetence".

Editor's Picks