Ask Slashdot: How Do You Deal With Programmers Who Have Not Stayed Current? 509
skaffen42 writes "The recent Ask Slashdot about becoming a programmer later in life got me thinking about a related question. How do you deal with programmers who have not stayed current with new technologies? In the hiring process, this is easy; you simply don't hire them. However, at most companies where I've worked, there are usually a few programmers who have been employed long enough that the skill-set they were originally hired for has become irrelevant. At the same time, they have not bothered to stay current with newer technologies. They usually have enough business knowledge that they provide some value to the company, but from a technical perspective they are a slowly-increasing liability. As an example: I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up. On top of that, he is really resistant to the idea of code reviews; I suspect he dislikes people he considers junior to him making suggestions about how to improve his code. So, how do my fellow Slashdotters handle situations like this? How do you help somebody like this to improve their skill-sets? And, most importantly, how do you do so without stepping on anybody's feelings?"
Can't offer much (Score:4, Insightful)
They usually have enough business knowledge that they provide some value to the company
Normally at this point where technical skills have faded and the desire to "keep up" is gone, people move more into a non-technical role where their experience and lessons learnt can be put to better use than their fading coding skills. Obviously though if he has allowed himself to become a poor programmer with no interest in improving, he might be just as shitty in a new role. Obviously a paragraph is very little to judge a guy on, but he sounds like the kinda person that barring a major attitude change, is probably going to be looking (unsuccessfully) for a job in 5 years or so when his lack of current skills can no longer be covered up.
Not current... (Score:5, Insightful)
...cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up
One has to wonder what sort of code he's capable of producing if he can't even do that.
perspective (Score:5, Insightful)
I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code
Concurrent code isn't new. If this guy doesn't understand it then his problem isn't that he has neglected to stay current, but that he was never very skilled to begin with.
Re:Can't offer much (Score:5, Insightful)
Can't write concurrent code? (Score:5, Insightful)
He doesn't understand how to write concurrent code? ...
I know only four people who can write concurrent code correctly. Although, come to think of it, one of them can't write concurrent code correctly and two others I don't actually know. :)
Re:perspective (Score:5, Insightful)
Concurrent code isn't new. If this guy doesn't understand it then his problem isn't that he has neglected to stay current, but that he was never very skilled to begin with.
Maybe it's just that writing concurrent code is hard, annoying, prone to buggy results, and should be avoided, except in special circumstances where there is a great advantage.
Re:Can't offer much (Score:5, Insightful)
The alternative is to offer him the training he is supposedly lacking. If he refuses then that is grounds for dismissal. This is my biggest beef with the corporate world. They want you current but do nothing to provide you the necessary tools or the time to stay current.
Re:perspective (Score:2, Insightful)
If the guy's job description doesn't require "Concurrent code" then STFU and keep your petty issues to yourself, if it does then hes unable to perform the job and needs training or reassignment.
This is what performance reviews are for (Score:5, Insightful)
You know, the manager takes everybody aside quaterly, or perhaps semi-annually and privately discusses strengths and weaknesses. If it's urgent there's a "see-me" meeting; but this is a slow leak, so it should be coming up in the guy's PRs. If it isn't, or there is no PR at all, management shares the blame. After having this mentioned in 2 or 3 PRs, and getting no bonuses or raises, it's shape up or ship out. Duh! That seems like management 101 to me.
Re:Can't offer much (Score:5, Insightful)
In my (admittedly limited) experience, that's exactly why people get out of the trenches and go for jobs that rely more on them knowing what the customer wants than knowing how the latest toolstack/middlewhere/design style.
Re:Can't offer much (Score:5, Insightful)
But more importantly, someone that's not keeping up with the latest trends in software development is screwing themselves. I can build the Javascript for a web page without using jQuery - but it would take me three times as long, so why would I want to? I can write the server-side of a REST application in Java and Struts 1 instead of dozens of newer options, but why would I do that? I can set up a test environment or two on individual physical servers instead of having six different test environments running in virtual machines, but that just means testing runs three times slower, so what have I gained?
In this industry, deciding you don't need to learn new things just means you're content to waste your time and the time of your colleagues.
I'm also somewhat resistant to code reviews (Score:5, Insightful)
I've often found that this describes me, because in the many code reviews I've sat through, I've yet to hear any point that I hadn't already thought of myself, and could provide the appropriate test code (if they'd accept it). So, in my experience, all code reviews have been a total waste of my time, and there was never any way to get past the trivial "newbie" stuff to the things that I thought were outstanding questions that needed answering.
And, unlike many developers, I've often found myself on very good terms with the QA people, because when I give them my stuff, I include a pile of test routines that they are welcome to use as they wish (thus saving them a lot of time).
So I consider at least one of the points here somewhat dubious. Yea, code reviews sound like a good idea. But if they don't produce any new questions that the developers haven't already dealt with, they're a big waste of everyone's time.
I wonder how many readers have similar reactions to the other points in the summary? For instance, concurrent code can be fun to develop, but in practice, all the interlocks required to make it work can reduce many tasks to near-serial performance. Sometimes, though, a better approach is to look for ways to split the task into subtasks that can run in separate processes that rarely interact. I've done this on occasion to produce huge increases in speed. Of course, this isn't really a question of programming, but rather a question of reanalyzing the task and finding a way to handle it with minimal coupling of a set of independent subtasks. But doing this could easily be interpreted as not understanding how to write concurrent code, rather than understanding when concurrency is an advantage and when it's not. ;-)
Re:Not current... (Score:5, Insightful)
I've worked with a lot of people who couldn't use revision control or bug tracking systems well at all, or that cannot follow coding standards consistently.
They were good scientists, just bad engineers.
For starters, you can get off your high horse... (Score:5, Insightful)
It's really up to the management at your company to determine whether someone is pulling their weight or if their skills are up to snuff. You may have an opinion, but it's best to keep it to yourself. Many people provide value to an organization in ways that aren't always easily visible to co-workers. It's entirely possible the coders who doesn't seem to be "as up to date" in his skills may be providing benefits to the organization in ways you don't yet have the experience or perspective to appreciate.
I once kept what others might consider to be a sub-par programmer on my team because he was a good friend of my best programmer -- the type of programmer who provided 10x the value of any of his peers who complained about the sub-par programmer. Besides, the sub-par programmer had a great personality, broad work experience and helped round out the team and make the overall workplace a much more enjoyable place to be. We had to work through some of the coding skill issues, but as a manager it was a tradeoff I was happy to make considering the other ancillary benefits the person brought.
As a manager, one of my toughest jobs was dealing with the handful of younger programmers who felt it was their duty to judge the value of everyone else on the team -- usually on very narrowly defined terms. Most often it was a case of "the pot calling the kettle black" and the energy invested in pointing out the flaws of others would be much better spent on reflecting upon their own shortcomings and improving their own skills -- which were usually overrated. I can say that because I once was one of those overly self-confident younger programmers myself, but I have since gained some experience and perspective.
Re:Can't write concurrent code? (Score:5, Insightful)
I don't think multithreaded code can be written correctly. At the very least you need to say your prayers and cross your fingers.
The most dangerous coders are those who don't have a healthy fear of concurrency. Unfortunately, those seem to be in the majority.
Not only is concurrent code full of surprising pitfalls, but you can't abstract the problems away. You can't enclose the tough parts in some key classes and be done with them. It's like with inverting a matrix: divide and conquer doesn't work. The larger the system, the more complex the interactions to consider.
Debugging is hell. Symptoms cannot be reproduced. Performance bottlenecks are difficult to analyze.
Training classes (Score:4, Insightful)
Your company probably doesn't send people out for training classes. That used to be common. Today, there's such a programmer glut that few companies bother.
Revision control is mostly a by-the-numbers process. In-house, you should have a short document that tells people how projects are set up, and where everything goes. Has someone written that document?
Concurrency is hard for most programmers. Lately, I've been observing people screwing it up in Go. (Go has thread fork and bounded buffers built into the language, but still has shared data, so all the usual race condition bugs are possible.) What language are you using, why do you need concurrency, and do you need thread-level concurrency?
Re:Current? (Score:5, Insightful)
However I would not be at all surprised to learn that Old Guy is more than pulling his weight where it counts: producing reliable stuff that is efficient, well documented, properly tested and on time. What New Kid fails to recognise is that in a short time, some other New Kid will be sniping at HIM for the same reason he's whining on now.
Re:Can't offer much (Score:2, Insightful)
If you don't know what the customer wants you have no business taking their money.
Re:Can't offer much (Score:3, Insightful)
Re:Can't offer much (Score:5, Insightful)
There's nothing wrong with raising a family instead of staying current as a developer, it's a perfectly fair choice, just don't then be surprised when the real world will let you no longer be a developer as a result of you opting to do other things than stay current. The world doesn't owe you the job you want to do in the way you want to do it, it's up to you to figure out what the world wants and what you feel you can and are willing to offer it that it needs.
It's perfectly doable to raise a family while staying current on programming languages. It's not as though the underlying principles ever really change, which is why experienced programmers can pick up new languages with consummate ease once they grok the underlying concepts. What you're talking about are idiots who think 'the world' is middle managers who will strip mine your life to get the project done a week earlier. Newsflash, older programmers aren't less capable, just less willing to be fed a shit sandwich than younger programmers.
Re:perspective (Score:5, Insightful)
"Concurrent code" and "multi-activity code" is not the same. In concurrent code, you actually have algorithmic interdependencies, which makes it hard. And no, there is no technology that can make it easy, because understanding what it does or is supposed to do is hard. On the other hand, multi-process/thread code and event handling code for not interdependent events is very easy with the right tools, but does not qualify as "concurrent".
Re:Can't write concurrent code? (Score:4, Insightful)
Re:perspective (Score:5, Insightful)
I don't often respond to ACs (and even less often positively), but you've hit the nail on the head here.
My current job requires absolutely no explicitly concurrent programming. I do mostly SQL, which has a high degree of implicit parallelism (arguably the highest possible, if you religiously avoid RBAR); I've also played around with OpenCL just for kicks. But even such fundamentals as semaphores and IPC matter not one whit to my continued employment.
I can appreciate the FP's problem, having worked with programmers who just don't have passion for the art anymore (and age has nothing to do with it, I've worked with a 60YO that made me look like a neophobe, and a 30YO that honestly would have liked his job better if he could do nothing but sharpen pencils all day). But most programming jobs don't require high-level cutting edge skills. Quite the opposite, I've more often found myself suffering for want of familiarity with ancient big-iron scripting languages than for the latest and greatest set of buzzwords.
Put bluntly, most programming jobs involve getting an ancient GL database to talk to an ancient POS system; converting 20 years worth of Excel VBA scripts (or god help you if someone's nephew actually knew Access) to "real" code; Hacking together a driver that lets a $2M instrument talk to a Win7 x64 box, when the most recent driver from the (now defunct) manufacturer runs on a German version of Windows ME (and FWIW, I didn't exactly pull that example out of my ass).
I'd love to see an actual breakdown of the numbers, but make no mistake, the number of programmers working on Real Software(tm) falls into a small minority of the total.
Re:Whereas I'm at the other end (Score:4, Insightful)
There are two types of people that create software: Those who care about being good at it and those who do not. Age does not really play a role. Although I admit that what universities do these days is insane. I recently taught a last-year OS class to BA EE students, only to find out that they never had any C, all Java only. Java is unsuitable to tech programming in so many respects, it is staggering. One is that you do not get to understand the machine anymore. Another is that many students have this notion that gluing together library calls is "programming" and they never do anything else. As soon as they have to make something themselves that actually does something, they are lost. Fortunately, there are still people that want to know more and teach it to themselves. But that they are not treated any better when it comes to finding a job does not help, and quite a few of the smart ones do not bother anymore because they see becoming a really good engineer as a loosing game.
Re:Can't offer much (Score:5, Insightful)
Re: Can't offer much (Score:2, Insightful)
He probably writes concurrent code as well as the new kid, but recognizes he can't debug it well enough to stand behind it.
Young kids get stuff done.
Why NOT Hire Them? (Score:5, Insightful)
This craze for the most modern stuff -- and believing people can't pick it up -- drives me crazy.
I'm the hiring manager for a small (5 people) software engineering group. We use Scala. Nobody in my team used Scala before they joined the company -- they learned (hell, we use Scala because THEY decided they wanted to use Scala). One of these developers didn't even know Java before he joined the company -- he was a Perl guy, through and through. He's one of my best.
We're looking at a candidate now who actually retired from the workforce after being an architect for a while; her last time writing code was 15 years ago. We like her because she has a fantastic fundamental grasp on computer science principles and the passion to learn quickly -- we think. So we showed her the code base for one of our open source projects, asked her to implement a feature that had been requested, and let her loose. She came back with the first version Friday; we'll see how it goes.
Concurrency isn't Olympic Gymnastics where if you haven't been doing it from the time you were six years old and if you're older than 20 years old you have no chance. It's just something to learn. Smart people can learn pretty much anything you put in front of them.
Hire smart people.
Comment removed (Score:5, Insightful)
Re:Can't offer much (Score:5, Insightful)
Some of we older workers try to stay current. It can be awkward and expensive in productive time and energy. In fact, as an older programmer, I've often used age and treachery to defeat youth and skill in the kind of "my new tool is better than your old tool" challenge so common in the workplace. Thee are few moments as pleasant for an older engineer as when a younger engineer says they've found an exciting way to do something, and you can not only prove the old way is better, but, but you can point out your own signature on the documentation where it says why you rejected that approach.
Fortunately, it's often easy for us to stay abreast of new software fads by tying the new technology to its ancestor and bringing that experience to bear. But if this programmer is not interested in evolving their skills to meet the project or the company's needs, then let that employee know personally. Please don't just insult them behind their backs, or ask Slashdot advice about them. Let them know, to their face, that their difficulties with code review or source control make it harder for their work to be accepted or their work to be useful. If you have to, bring it to their manager.
And if you can, help them find a new role or a new job that is better suited to their skillsets. I've certainly worked with, and even once managed, someone whose core computer language skills were about to be phased out at our company. I let him know we'd have a problem, offered some access to retraining, and was generous with time of for him to do interviews elsewhere and with recommendations. He was quite good with the older skillsets, just not that excited about abandoning almost 20 years of experience and knowledge to start over. The last thing I heard was that he'd retired from the new role he found, and he still does related open source projects for the challenge.
The average engineer (Score:5, Insightful)
The real problem is that there is an idealized picture of an average, competent engineer.
The reality is that the average engineer is barely competent and average companies will be full of them. Any team you end up on in such a company will almost certainly contain a handful of them, and worse will likely contain at least 1 sub-par engineer to boot. This is just a fact of life.
The problem is not being unhappy with crappy help -- the problem is the stupid idea that you should never have to deal with crappy help. I think any good engineer should be prepared to absorb some adversity, whether it comes in the form of a tough problem, a bad team member, a bad market, or bad management.
It's called life.
Re:Can't offer much (Score:5, Insightful)
Normal banks do not take money from anyone who doesn't want their money taken. They lend out money and you pay it back with interest. No one forces you to take out a loan.
Some commercial banks [bloomberg.com] will charge huge fees for services that you don't need and don't make you any money.
Governments do not take your money. You vote them in and they collect taxes to do the stuff you elected them to do. If your guy didn't win, well that can suck, but its part of the whole "democracy is the worse form of government except for all the rest".
Re:Can't write concurrent code? (Score:5, Insightful)
You seem to not know how those work. There is no single monolithic program running. you have about 20 programs running and they all interact and communicate. No concurrent code needed.
Navigation runs on it's own. GPS is a service/daemon running that others get their information from ,etc... Targeting is separate as well. Control communication is separate and then you have the failsafe daemons running to take control if anything fails.
IT is far easier to have separate subsystems all running on their own and talking than trying to write a single program that is concurrent. Plus your chances of failure go way down. You can have the GPS system fail and restart without taking down the whole system.
Yes I have written Drone code before.
Takings (Score:2, Insightful)
No. Taking money involves force or the threat of force. Businesses very, very rarely engage in such things, and when they do, they're usually acting as an agent of the government one way or another.
For instance, RIM has never gotten any of my money, nor do I expect to ever hand any over to them, because they make nothing of interest to me. You see? It's my interest, however aroused, that instigates the transaction. So slick pitch or not, they get nothing. My choice. Not theirs.
Likewise, cable television providers: They get nothing. They have absolutely nothing I want; no transaction ensues. They cannot take; they can only accept what I offer freely -- and I don't.
The government, however, tells me I owe them X, there's absolutely no choice or option about this for me, and in fact, if I don't hand it over, they will take it from me. Furthermore, if I don't have the money they want to take, they can and will escalate and take other things like real estate, etc., perhaps incarcerate me, ruin my working life, interfere with my family... this is what taking means. It's about use of force.
A mugger takes. The decision is not yours. There's the force.
A beggar does not take. No matter how hard he begs, no matter how smooth his "sales pitch" or heart-rending his circumstance; the decision is yours. There is no force involved.
You and I differ sharply on what "current" is (Score:5, Insightful)
I'd call someone current who has 5 years of all of these: Objective-C & MAC/iOS experience, C#/WPF, Android 4.1, SQL/SQLite/Oracle, C/C#/C++, Java, Python, Javascript, HTML, .NET and everything else the Microsoft has. If you don't known all of those things then you need to catch up.
And yet in a heartbeat I would drop your buzzword-driven developer and hire a developer who had a solid knowledge of data structures and algorithms, operating systems and related topics, networking and distributed systems, concurrent systems, testing and strategies for error detection/recovery, requirements capture and modelling and other high-level functions, different programming styles and software architectures, and other similarly general foundations. I'd even do it without even asking which programming language(s) the developer with the solid foundations used lately.
Your buzzword guy might have 5 years with those technologies on paper, but if there are so many of them then probably there's not much real depth there. Sounds like someone who blindly follows trends, and who's mostly "up to their neck in code" in the sense that they copy and paste a whole bunch of examples but never really get into any tool long enough to use it idiomatically and play to its strengths/avoid its weaknesses. I don't buy the theory that a good programmer can sit down and learn any new language in a week -- that's a load of nonsense unless the new language happens to be little more than a search-and-replace away from one they already know -- but I'd rather take someone with solid foundations and have them get up to speed with whatever tools we need on a project than take someone who shaky foundations who happens to have used those tools before for about ten minutes. They'll still be current enough to do useful work with the tools, but their basic quality of work will be much greater.
Just to be clear, I'm not saying that having a general awareness and knowledge of recent language/tool/library developments in your field isn't useful from time to time. But trying to get coding time in with every new buzzword is a fool's game, and the mark of someone too inexperienced to realise the treadmill never stops.
No democracy here, I'm afraid (Score:2, Insightful)
No. The majority votes them in, and they do whatever they want; and there is little to no certain connection between what they do, and and what I in particular would have them do. I would not have them go to war outside our borders; provide subsidies to the oil companies; prosecute the drug war; impose rules on personal choice; interfere with the sex lives of those capable of informed consent; etc.
They collect taxes to do all of this anyway, and they do it over my complete disagreement that it is legitimate that they do so. What happened there is that other people have decided to use force against me to make me support their will. That's force. Period. I have no other feasible option whatsoever or I will get hammered.
In the USA, we don't have a democracy. We have a republic. It isn't even the will of the people we are bound by; it's indirected one very effective level away from that. Which would probably have been fine if the legislators so chosen were the people of honor envisioned by the founders; but unfortunately, they are the puppets of the rich and powerful, and so it is their bidding, not the public's, and not that of responsible, honorable legislators, that we are made to do.
Re:Can't offer much (Score:3, Insightful)
No one made you hand over your money to any bank. You made a free choice, there was no taking; you're just screaming about the consequences of that choice because it turned out to be a poor one, for whatever reason.
You are responsible for making the best choices possible. If you don't, your results will not be optimal. That's life. At the next level, you're responsible for learning from poor choices you made. If you don't, likely your results will continue to be less than optimal.
That's what freedom brings to the table: Opportunity and risk. Don't want a particular risk? Fine, in the specific instance you mention, simply don't put your money in a bank. Of course, now there are other risks. Or, perhaps, research the venue before you put your money anywhere. Imagine that!
Re:Can't offer much (Score:5, Insightful)