Slashdot Mirror
Ask Slashdot: How Do You Deal With Programmers Who Have Not Stayed Current?
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?"
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.
...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.
No sig today...
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.
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. :)
Where are you from that these are that these are "current" concepts that you wouldn't know about unless you've been keeping up? How old is this guy? When he programs, is he plugging/unplugging vacuum tubes?
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I'm 35 and in the management chain now.. No more needing to know how to do anything. It's pretty awesome.
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. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Since when is it not the companies responsibility to train their employees to do their job? If the job changes while you are there why should you be expected to keep current with the technologies on your own time? If you want him to do things differently then train him on it, if he's not willing to adapt to the new methods then fire him. I do resent the idea that younger, faster, more curious people automatically assume that the level of effort THEY put in is the standard. Some people jobs are simply a means to a paycheck and nothing more. Others its more important than their hobbies so they care more. Each company has a culture that exists and if a person doesn't fit that culture then its time to move on. Some people are content with Operation Enduring Paycheck. Its not hard to keep a job once you have it.
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.
It's simple. You promote them to management.
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?
This.
And also...
There is nothing like business experience on a development team. The knowledge about the arcane workings and interactions of the company and it's departments and sometimes even individual staff members, all of whom are part of the "big picture" of a real system. There is far more to coding than slinging code, and it's not until new developers have been kicked in the 'nads a few times by company "gotchas" that they realize this fact.
And some arrogant little snots never learn that fact, and end up job hopping all the time because no place is "challenging" enough for their "elite coding skills."
I do not fail; I succeed at finding out what does not work.
I graduated from a large state university 10 years ago and there was an entire course on concurrent programming. It wasn't required at the time for CS, but I believe it is now.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
> 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'd get ready to leave the company for a better job since it's clear there's no accountability at your company. This situation cannot end well for one of you. Either you are pulled down/leg go or he is let go/quits. Without accountability you can't be promoted at an organization. This is because there's no criteria (I mean there are edge cases, but don't bet decades of your career on it). This is the business of software development and you don't get to make decisions about appropriate quality levels at your position, nor do you get to judge other people's value, nor can anyone without some progress gauge at a granular level.
You indicate you use a process where code is accepted without code reviews. You work at a shitty company. You have a process where engineers don't all use revision control. You work at a shitty company. You have peers who act out politically to avoid working/accountability. You work at a shitty company. See the pattern?
In my experience, there have been cases where we just ignore the lame duck till some accountability gets implemented and it becomes obvious, but that's not the norm. Usually some nasty argument where you're trying to rehash the issue causes a serious consequence over an irrelevant detail (made up reason) to push one of you out the door. Usually you. Start looking for a new job, bring up performance metrics in meetings, ignore him. That's all you can do. Don't try to help him, he can do that himself and has chosen not to try.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Seriously, if you have a disagreement with a coworker then bring it up with your boss or HR department, don't drag dirty laundry and office politics to slashdot.
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.
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.
... or you don't work in the same field. There are plenty of specific programming areas and industries that need programmers where one, or even none, of those would be relevant. Yet at the same time, they have their own new techs, laws, practices, and other tools that need to be kept up on. I work in computational modeling, and have plenty of places I have previously worked and could apply for a job at that would at most need the C background, and maybe Python. Although where I am now, it is all Fortran and C, and whatever scripting language you want to use to handle small things (Python in my case, but not for many of my coworkers). In my case, I need to keep current instead on papers for various new numeric techniques and optimizations for different platforms. And for friends that do more hardware related stuff, about the only thin on there they need to know is C.
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.
I was crazy back when being crazy really meant something. (Charles Manson)
Amen!
notice how all these "ask slashdot" stories whining about an old programmer is some snot nosed punk that thinks he knows more?
Most of these kids wouldn't last a DAY programming an embedded system where you have 10K for your entire OS and program, let alone a high pressure place like financial programming.
Do not look at laser with remaining good eye.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
That adds up to 50 years, so I'd call them retired.
Although Android 4.1 has only been out for a year, so perhaps liar would be more accurate.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Effectively you are saying that (when applied to my current field) if I don't have experience of Forefront IDM, I need to catch up. No, I don't have experience with Forefront IDM, but I have experience with various other IDM systems as well as various Microsoft technologies. But lack of working with it really doesn't matter. If you want me to work with Forefront, I can. I may need a bit of extra time to find the things compared to guy who has worked with Forefront, but that's just when starting out (I have countless examples of time when I need to implement something with something I have never worked with and it has always had a good ending).
Do you look for carpenter who has 2 years of experience working with black walnut or carpenter who has no experience with black walnut, but has been carpenter for 10 years and has worked with various other woods (there just didn't happen to be a project that involved black walnut)?
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.
Are you joking? Or are you using a loose meaning of the word "know".
People need to start being realistic with this "keeping up" stuff.
Let's take a look at the stuff you listed and where they are typically used:
1) web - Java; Python; Javascript; HTML; .NET
2) mobile - Objective-C & iOs for iPhone; Java for Android
3) desktop - C#/WPF; Java; Objective-C & iOS; C/C#/C++
You just described three different development roles (although there may be some intersection of technologies).
Let's say I'm working as a full time as a "desktop developer" in a company product where I work with a Java development stack. Do you think I should spend my free time doing web development and mobile development , in order to be considered "current"?
Which other professions have these kinds of expectations?
Nonsense. Leaving is not an option for most, "always" is a disingenuous exaggeration. Furthermore, there may well be nowhere to go that resolves the problems you have with where you are. Please leave that old saw in the trash, where it belongs.
I've fallen off your lawn, and I can't get up.
We keep saying it because they're radically different from one another.
A Democracy directly implements the will of the majority. 51 out of 100 want something? They get it. Simple. Appealing until you realize that often, the 51 want slavery, religion in government, control over your sex life, retarded limits on contracts such as marriage, to deny health care to you because you're not wealthy, etc. Best not to go there. The old saw "Democracy is two wolves and a lamb deciding what's for dinner" about covers it.
Whereas a republic doesn't implement the will of the majority at all; it implements the will of the representatives. The idea being that the representatives are honorable, thoughtful people guided by principles more sophisticated than the masses, if for no other reason than because they actually have the time to think things through, as this is their day job, as it were. The concept of a working republic depends utterly on the consistent selection of a majority of honorable, thoughtful representatives who are able to gather sufficient truths about the matters they must create legal structures for (if you're thinking "uh-oh..." then you get a gold star.)
In the specific case of the USA, which is a constitutional republic, by design it implements the will of the representatives, moderated by the constitution's fundamental limits and enumerated powers. Furthermore, the US constitution insists (in article 4, section 4) that each state government is also implemented as a republic. The limits and enumerated powers of the constitution were intended to prevent abuses such as those I outlined as typical for a democracy.
Design aside, the actual function of the US federal government is implementation of the will of the representatives as dictated to them by moneyed and powerful special interests, very rarely moderated by the constitution, then further (as a matter of fiat power grab) moderated according to the whim of SCOTUS, which, thus far, has often been quite at odds with the plain and obvious requirements of the constitution. Technically, this actually turns out to be an oligarchy, something quite prone to abuses, as we see demonstrated in a most concrete manner on a daily basis.
The difference between a democracy and a constitutional republic is immense enough. But the difference between a democracy and the oligarchy we actually have is almost incomprehensible.
What is most likely confusing you about our (nominal) republic is that small portions of the process appear to be somewhat democratic in nature. For instance, once the power brokers in the political parties pre-select the special-interest-compliant figureheads we get to vote for, we can, quite democratically, select either one from column A or one from column B. Most other portions of the process are not democratic. For instance, the FCC, the FDA, the DEA, the CIA, the FBI, the reserve banking system, SCOTUS... these are not democratic institutions, they exist in forms almost completely insulated from the democratic process. For instance, many functionaries persist across voting cycles for representatives; some, like SCOTUS, are effectively impossible to dislodge; some entities, like the federal reserve system, exist outside effective control of anyone at all.
The bottom line, though, is perfectly clear: The USA is not a democracy, and has never been one.
If nothing else, take your hint from the pledge to the flag: "...and to the republic, for which it stands..."
I've fallen off your lawn, and I can't get up.
You're quite wrong. This is a forceful act, undertaken against my will. You're very confused. Violence is not the only form of force, you know.
No. This old canard incorrectly presumes that there is somewhere to go that resolves the issues you have with where you are; it also incorrectly presumes that such mobility is practical or even possible. All of these are disingenuous presumptions.
I've fallen off your lawn, and I can't get up.
You're changing the subject from that of whether governments 'take' money to that of whether the taking of money is justified.
There hasn't been a direct democracy since Athens, or possibly the French revolution. A representative democracy is still a democracy. Even Switzerland only has referenda on large scale issues, day to day government is still conducted by representatives.
The voters elect people to represent their interests in government. These representatives are accountable via the means of regular elections, by which unpopular actions on their part will result in their not being re-elected.
This of course requires an informed, educated electorate. But the same is true of a direct democracy.
Here's the thing. It happens quite a bit right here on slashdot. The rationale "most people want this, so we should have it" is constantly trotted out. That's because people have an extremely simplistic (and foolish) view of how things "ought" to go. We're not a democracy. We have tiny, diseased democratic process segments. No more than that. Everything else is managed in a decidedly non-majoritarian manner. Oligarchy. Say it, believe it. It's what we have today.
I've fallen off your lawn, and I can't get up.