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.
Seems like a pretty straightforward answer to me. Any programmer has encountered this problem before, should you refactor or rewrite? When the amount of time and work it takes to refactor old code is greater than it is to rewrite it, then you should rewrite it.
Concurrent code isn't new.
Are universities teaching communicating sequential processes to undergraduates yet?
I haven't met a programmer in the last 20 years who's older than me. This makes it very easy for me to make clear to them that if I can keep my knowledge up to date, so can they. If they haven't, they should simply go.
no, I don't have a sig
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. :)
If the business knowledge is useful, or they bring something to the table that you find desirable, create a position for them.
If they don't, and they refuse to upgrade their skills, you review them that way. If they consistently fail to meet expectations, you let them go.
Someone who isn't contributing to the project makes all of the rest of the people who are on the team have to work that much harder and makes their lives more difficult. And at the same time, you're having to pay that guy to have that effect. That makes no sense.
Don't get me wrong, you need to set up training programs *as part of their job* to keep their skills up to date. If you are expecting them to juggle family life outside work with them having to spend time updating their own skills, then you as the employer are firmly in the wrong, and more to the point, you are hurting yourself. All of your employees have some sort of business knowledge that makes them better than hiring someone off the street, unless that current employee refuses to maintain the skills that they need to do their job.
The worst thing you have to do as an employer is lay off people who are able to do their job and are doing a good job, simply because you ran out of money to pay them. Don't put yourself in the position of having to fire someone who does good work later, by maintaining someone on your payroll who refuses to learn new skills, or take on a new role, now.
Why can't his manager simply order him to learn the necessary skills? Learning those skills would become part of his job. If he doesn't learn, he isn't doing his job, and could get fired. Why put up with someone who refuses to do his job?
Hamsters are at least as feathery as penguins. HamLix
I'm a driver writer for a top 10 semiconductor company. I find new guys are more and more clueless about how computers actually work. They're so far removed from the hardware that it might as well be magic. It's not helping that universities are moving instruction in programming away from the fundamentals.
Those old guys whos skill sets you think aren't relavent any more might end up being the only people who actually know how things really work.
From my perspective, programmers today know nearly as much as their predecessors. They are drones contributing poor rewrites(at best) done by the 'old timers', resulting in very bloated and slow software that is only acceptable by the extreme speed of todays computers.
Gotta give people a reason to upgrade I suppose...
You train in version control, require it be used and used correctly. You make code reviews standard practice for all code that is checked in. If he cannot check code in and out and submit to the same reviews as everyone else, he can go elsewhere.
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?
Alternatively, he's a bit of a jerk, or bad at his job, and i'll leave that to you to figure out for yourself.
concurrent code?
if you're responsible for group productivity and you tolerate people with degrading skills
1) you'll be perceived as unfair by people who maintain their skills(and you are unfair) creating pointless tension in the team
2) you're putting your own job at risk
if you want love buy a puppy. this is bidness
Make him or her a Scrum Master! He will never touch code again!
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.
if your company is keeping old farts with no motivation to excel, you obviously have no business there (assuming you are pursuing success)
When I was a programmer in the 1990's, software companies had this idea that if you hired smart problem-solvers, you could teach them the details, like a particular programming language. These people, ideally, were adaptable and interested in expanding their knowledge. If you accidentally hired someone who couldn't cut it, you let them be on their way. For the employees that you valued, training and tuition reimbursement were the norm. For better or worse, that way of thinking has died. Unless you're a true superstar, you can be replaced by someone who has more current skills, is willing to work for less, and is young enough to not to be encumbered by a family. A programmer is no longer a long term investment, someone whom the company hones over the years, but a disposable razor who seemed sharp at the time of hire. You have someone who won't keep up technically and and has less than ideal social skills? They're outta here, baby, even in the old way of thinking.
I can understand not wanting to use revision control, personal I had a really bad perforce experience. However code reviews and all the other common practices are usually really useful. I would send a message up to manage asking for employees / teams to be given books on development practices and made to read them, then if he still doesn't want to listen you can take further action.
As someone regularly called a dinosaur (I'm not that old, really) I say fire the lazy pricks. There's no excuse for people to not keep up with the things their job requires. I'm regularly involved in open source via github, use "cloud" nonsense, write in everything from assembler to C to C# to Java and above, use everything from rcs to cvs to git to hg to bzr, and am signing up for spideroak as I type this.
People who use this as an excuse to be lazy pricks deserve to be treated just like any other lazy prick. Fire them, get someone who can bring knowledge and flexibility to the table. They are out there, it is not a black and white situation.
This guy in particular not only sounds like a lazy prick, but an arrogant prick. I'm a mentor of many programmers currently and they teach me things too. So he can just go straight to hell.
Can you use the tools and techniques needed for the product? Yes/No? Whether you are hiring or determining to retain staff they have to be able to do the work. Only janitors have the luxury of being able to use the same techniques they did 20 years ago when they got their jobs.
"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."
With respect, I'd suggest you start by questioning the assumption that 'the skill-set they were originally hired for has become irrelevant'. Whilst I've occasionally seen this happen it's far more common for pipsqueak young coders/management to show up waving what they consider to be the greatest new technologies since the invention of the battery-powered cordless breadknife, only to turn up to be missing a whole lot of fundamental knowledge that eventually proves to have been actually pretty important. So, review your assumptions first. Have respect and you will get further.
If they're intolerant of your attempts at managing them, then you probably are pissing them off. The second suggestion is, therefore, in trying to improve relations between you, try not to piss them off. A good place to start with that would be to dump the ageism already. Your Ask Slashdot reads like, 'ooh, they're TEN YEARS older than me and they CAN'T EVEN do blah blah'. Don't do this. Have respect. You will get further.
Third, try figuring out what each programmer's strong points actually are. Don't tell me they haven't got any. Coming back to 'they CAN'T EVEN do blah blah', I'm assuming that there are things that they can do, because you seem to imply that they once had useful skillsets. How about starting by listing the things they do know and working from there? Failing to recognise other peoples' skills is just poor technical management. Keep in mind that they may be bored as hell of programming after a decade in the job, so also consider other skills that may be of relevance to the company; technical writing, teaching/training, people skills in general.
You've just written an entire Ask Slashdot that is unrelentingly negative about people who apparently work for you. If you do that in the office it isn't surprising that they don't feel like following your leadership. Find something to be positive about, or save everybody the hassle and just make them redundant straight off. Negativity and leadership don't go together. And yeah, I have been pretty negative about this Ask Slashdot, but I'll tell you why: I was in technical management for many years. I have written a whole lot of emails with 'they CAN'T EVEN blah blah' in them. I have thought the way the submitter thinks about a whole lot of staff members. And eventually I worked out that the fundamental problem was that I was a naive, slightly self-obsessed young technical manager with insufficient leadership skills to figure out that either you let people go or you demonstrate some respect for what they are now, as well as what you want them to be.
Because these values need constant attention a company is well advised to have a system to both develop and check progress of them.
This will obviously involve participation of the employees and I can tell you from first hand experience it pays for both parties to foster such a system of training and competency development.
Where I work it is mandatory to take part, although it's the only way to ever get a pay rise all the engineers I know are especially motivated because it's nice to be part of a system that constantly develops.
When the system was originally rolled out we've seen some old timers leave for companies that did not bother them about development, good for them and us :)
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
YOUR FIRED....and replaced by a canadian foreign temporary worker at min wage - 15%.
YES i will be doing quite well ( makes darth vader sounds )
1.) Absolutely no definitive definition on what defines "current skill set."
2.) Reasons to suspect that the source / version system sucks.
3.) Likely an article submitted by another one of those management types who, instead of improving their scoping skills and or leadership boundaries, would rather nag and nag everyone below his or her station to learn everything the popular companies use--not because some project necessarily requires it, but because, "they're doing it, so we should be, too."
I honestly hate people like you.
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.
kill and re-spawn.. no hard feelings
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.
You give him tasks that use the new technology, but are relatively easy. Then give him something a little harder. Then he catches on.
If you're not his manager, he's probably annoyed that you're telling him what to do. If you are his manager, you can try appealing to his ego and say, "I want to do code reviews. Letting junior developers look at your code will give them an idea of what good code looks like."
"First they came for the slanderers and i said nothing."
I'm not even that old, but have taken a perverse interest in understanding the low level implications of everything I do. Certainly, most of the time I don't have to think too hard about it, but the awareness has been very useful more frequently than one might think.
I think that low level understanding helps me to adapt to higher level language features as they come out. People who don't understand the low level stuff seem to regard their craft as some sort of unfathomable magic where they learned how to apply a particular generation of technologies without truly understanding it. When a new language feature comes out, if you understand the low level well, you have a pretty solid feeling to understand what that feature is doing and how to exploit it.
Unless a curriculum is touching all of this, low level and high level and the nitty gritty of how it comes together, i don't think it is constructing durable skills.
XML is like violence. If it doesn't solve the problem, use more.
Being anti-code review is enough reason alone to fire someone. That is one of the most arrogant and worst qualities imaginable.
Revision control screwups? That just means he's not qualified for any kind of computing job. These things aren't hard to learn. This guy just plain sucks at what he does and isn't willing to improve himself. Hire someone who actually wants a job.
If you have a system that allows any developer to contribute code to any module, subject to group review and approval, he will get feedback on his code and have to make the case for its inclusion without feeling like he's being treated unfairly. Meritocracy wins the day.
http://qubemod.com/
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.
Where I work, it's the opposite. They onsist on training, and on paying (too much) for it.
My natural tendency is to simply RTFM. If it's not covered in the manual, I normally read the code. If the code is unclear, I ask the people who wrote it. (I work with open source, meaning the developers of any product I use are an email away.) Yet, the organization insists that I find a conference or something for them to fly me to every year, and classes to take.
"And, most importantly, how do you do so without stepping on anybody's feelings?"
LOL..ROFL..LMAO..Very funny.
The reason why your older colleague doesn't do more than necessary is because that is what the majority of people do. Plain and simple. :)
As a lead, all you have to do is hand out new assignments and reasonable deadlines based on estimates made together with old bob.
Then watch what happens. You might be surprised how well, old timer adjusts to new challenges
I have been working with old colleagues up to seventy years old that would take up any challenge and work like hell until you got scared and sick watching it.
Your issue is probably more about yourself and how to assert other people, more than other people not being able to take it from you.
It's simple. You promote them to management.
If you have influence on the type of assignments they get, push them into more boring, less desired assignments (also less critical). They usually are aware of their situation and will be happy to grind through the bore and even more happy to be left alone. Also the rest of the team will be grateful for this effort.
4wdloop
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?"
You can't help people that either don't want help, or don't think they need help. Unless the person either asks you for help, or is obviously struggling and would appreciate the help if offered, you just let them be. It's no different with developers than with anyone else.
From your question however it doesn't sound like either of the above are true. It's easy enough to help people who want help where you know what the right path is. When the student is ready the teacher will appear.
I used source control tools in 1991. I used manual source control years before that. If anyone isn't capable of using a source control system today, that isn't "not staying current", that is failing at basic job requirements.
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?
Put him in a team with experienced programmers.
As a team you decide all code will be reviewed. All code. Comply.
As for the technology: a manager has to be very clear about this. Explain he / she is falling behind. Explain what new technologies you want him to learn. Explain that the company needs him to learn this new things. Offer help / courses / whatever.
And finally: "You update your skills (smart targets) or we lower (or don't increase) your salary."
Privacy is terrorism.
Raisin with them!
I got to the chocolate box before you, that's why the hard ones have teeth marks.
I understand it's Slashdot and the department is "Ask Slashdot." Still, why is it when I see whiny little questions like, "What do I do about a co-worker who..." the first answer that comes to mind is "beat them severely." It's sort of a more violent version of Betteridge's Law of Headlines.
Maybe it's just me, but I feel like I'm seeing more and more of these managerial questions. Y'know, if your interpersonal skills are so bad that you need to ask a bunch of slashdotters how to deal with people, you may not be cut out for management.
But here's a hint--perhaps he doesn't see a real advantage to learning the latest buzzword-development paradigm. Perhaps, rather than scoffing at his neanderthal ways, you should consider whether or not you're gaining enough to use these techniques.
If you believe you will--and you may be right--one way to light a fire under his butt may be to show him. Have him write the code. Have you write the code using these glorious techniques. Put the two together and run it. If you can show him the benefits of learning this, he may be more inspired to do so. Similar thing with version control--show him how it benefits him to use it.
If you are his boss and don't thing he widths his salary fire him.
If you are not his boss then shut up and work with him as his boss things that he adds value.
Stop nagging and learn to work with others.
if they are solid programmers, but lack skills with new tech, pay for professional training. if the are good programmers, they should pick it up. let them go If they don't improve in 6 weeks-6 months.
I've been around for quite a while, but I have kept my skills up, with four kids, to boot. I feel your pain. Often, these programmers aren't able to go to the next level. At the same time, I've seldom seen Management do anything about them. Here's my advice. Stay away from these people. You do not want to be associated with or influenced by them. Focus on your own work and doing it as well as you can. Unless you are in charge (meaning you have hire/fire authority,) don't concern yourself with the overall situation. BTW, you'll start feeling much better once you've given up hope.
Is it that he doesn't understand concurrent code, or is it that his knowledge of it is different from yours? If he's my age or even 5-10 years younger he didn't cover much with asynchronous web apps in school (I graduated just before Berners-Lee announced), but he may well be aware of concurrent processing in other contexts.
First off, anyone who did any GUI development even in completely-unthreaded 16-bit VB3 should be able to understand the basic concepts. DoEvents anyone? Throw a timer control on a form AND handle GUI interaction? Congratulations, concurrency if only at a minor level. Hell, anyone who's written GUI apps that trigger long database queries without hanging the app has dealt with concurrency.
Second, anyone who's done much with *nix command-line processing uses concurrency even if they don't know it. Piping anything through multiple stages? Each of those processes is running concurrently, either waiting for input or processing input possibly while the preceding stage is still chugging along providing more.
Finally, has he done any multi-threaded apps (or passed on that approach for scaling reasons)? At this stage I'd expect him to know what you're talking about, but there's still a noticeable difference between multiple threads and thinking the same way about web apps.
fencepost
just a little off
You need to learn some humility and sense of your own limitations. Concurrency and revision control have been around for decades, so it's concerning that you don't know that.
As for your colleague, you're just describing a shit engineer. That's a problem with your company and its processes. That's a management issue. Whinging on /. won't change that, so what are your proposals to your management to improve the team?
Another question for you: what expectations does your employer place on people to learn new technologies and theories? What opportunities do they provide for career path and growth that might encourage somebody to learn new things? Has your colleague been asked to take on new roles and responsibilities that might need him to adapt?
Perhaps you need to express code review in terms of cross-training, effective communication to the wider team and improving the health of the team beyond truck count = 1.
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.
..either you take care if his coding and help him or her, or you leave for a new job...
I personally chose to help and correct the code of a co-worker for almost five years, only to get more and more frustrated. In the end, it was too much to take, as he didn't even care. He had given up learning and caring for his job, but he tried to push me around because he was older... of cause this depends more on personalities than coding, but my advice is to tread carefully. At the end, being right can be patronising and putting the co-worker on the defensive. After all, he might be aware of his short-comings and start playing the politics card... and then it becomes ugly!
I'm twenty-seven years old.
From my limited experiences, "current" has nothing to do with it, nor does age. C has been around since there early '70's; in terms of systems-level programming, there is a huge benefit to being older. The older folk have seen tons of OS's born, raised, reach adolescence, get their first DUI, etc. They know what's it's like to play in a kernel that only has 256 KB of RAM, so they know how to optimize. Lots of youths these days are given higher and higher level languages as intro programming classes. My alma mater, to my dismay, replaced Java with Python for the intro class. I wish I had that insight. We younger generations are missing out on a lot of experience, and as more and more development moves to the web, lots of us are missing out on what really goes on under the hood.
Now, to address some of your statements:
"I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code" This is a symptom of poor programmer quality, and has nothing to do with age. You can be 5, or you can be 65, but if you don't know what a spinlock is, then you don't know what a spinlock is. Multi-threading/multi-programming has been around for a long time.
"and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up." I still have no idea how to use a revision control system. However, it's good practice, at least for me, to befriend someone who does understand them, so he can help you the hard times.
bio->bi_end_io(bio, error);
In this case, "why do you hate America" comes to mind since it describes you completely. You think that US citizens should be knocked down until they kneel before the world even if it is meant to be the other way around. Suggesting sports terminology doesnt make your case stronger - it only confirms your contempt for any citizen of a First World country.
Such people that are better fit for management just need to be promoted away from a technical role. That, and the immigrant isnt better, just desperate; you just want the citizen to be made desperate too.
As for those who are considered long-term unemployed, make them a protected class as long as they dont have a direct-hire job for at least 10 years. Doubly so if over 40 or just entering the job market.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Firstly, you haven't explained the context for which you expect them to keep up to date with existing technology.
If the person you are discussing is a consultant or in pre-sales in an evolving product role then you have a point. Its his duty in those positions to keep up to date on trends related to their particular sphere of influence.
Outside of that though your comments make me want to punch something.
My background is as a developer of over 30 years now with at least 10 years in management and roles including technical architect, system and business analyst and various levels of developer. I have always kept my skills relatively fresh by doing many different types of project for a variety of companies in all range of sizes.
As I always explain to others I would expect members of my team to always improve themselves. That doesn't mean that I expect them to learn new technologies and nothing else. In the world of IT anyone who is capable of displaying human rationale and the ability to understand people will always be head and shoulders over anyone who is purely technical with no soft skills.
Why? Simple, I don't have to waste time explaining to them that the beautiful thing they have constructed is absolutely no use to the user because they haven't bothered to interact and understand.
If you are judging people solely on technical skills then you have sadly misunderstood almost all of what IT is about. It is about making peoples life easier, not about giving a developer a grandstanding opportunity.
If the senior developer really is unproductive then its a management issue as others have said here. Otherwise you really need to sit down and think about what it is that they have that you don't.
You might be able to succeed by disguising his schooling in terms him schooling you. Pick some topic which the guy needs to know (that you already know) and say (for example), "Bob, I'm having trouble understanding outer joins. I found this reference page on the Web but am still confused. Could we get together next Tuesday and maybe you could help me figure it out?". Providing lead time ("next Tuesday") gives him time to figure it out. Asking him for help strokes his ego and motivates him to learn the stuff so he can be helpful to you. There are variants on the theme. Pick some code from your project (or from the Web) that he can help you "understand".
Regarding version control, see if you can find some smallish standalone side-project which is relevant to your job. Express enthusiasm for working with Bob on it. Start it in version control. Do things like sit at his desk with him and say, "Let me show you what I've done". Then pull out a cheat sheet and scan it for how to check out your code, discover an error (or add a comment), then make a show of referring to the cheat sheet for how to commit your change. When you're done showing him your code then "forget" your cheat sheet, leave it on his desk. He'll need it because while you showed him your code you asked him if he could add XYZ to your code.
Code reviews. Have him participate in several reviews of others' code. If he's resistant to even that explain that because of his experience his insight is valued. Once in a review he's an equal participant in debating the merits of various blocks of code. The cordial, social aspect of debating the finer nuances of coding could be enough to warm him to the idea of submitting his own code to a review. Otherwise, when the time comes to review his code motivate it in terms of everyone learning from the code of an experienced engineer.
You get the idea. Be creative in finding ways that he can "help" you.
All that said, the parent is definitely correct. It really is management's job to set expectations including "learn this new technology". If management is amenable to "fixing" the old guy, but is just oblivious, then bring it to their attention, complete with telling management, "I don't want to hurt his feelings, but he can't do XYZ and it's taking time and energy away from the rest of the team for us to work around his limitations."
You comment about keeping a sub-par but useful in other ways programmer around reminded me about something. I would be wary of saying the old fart is bad at his job, because I'm somewhat dubious the the submitter actually knows what the guy really does for the company. It could be a simple as he's very useful to someone higher up on the food chain for a few specific tasks, as a source of information and advice, or they have legacy stuff that they must support come hell or high water. Might be in the submitters interest to not annoy him.
I'm also skeptical. There's a lot of BS out there about "concurrent" code. I'd like to see specific and typical scenarios. Some people seem hellbent to reinvent a RDBMS in their code for some faddish reason.
Table-ized A.I.
I've seen many developers who has fallen behind, and essentially burned out to the point where they were not contributing with anything any longer.
The last thing you want to do with such people is to train them or otherwise try up their skills, because the main cause isn't lack of skills - it's just a symptom.
I work as a consultant, so over the course of my career I've met numerous developers, and every time I ran into a developer who showed signs of burn out, I wondered what caused this. In some management books, the key enabling factors in order to deliver results are people being willing and able. In other words, motivated and skilled. For developers, this isn't really the case. Not being motivated will always - sooner or later - mean not skilled. Developers aren't like factory workers who just do repetetive tasks, it requires a lot of effort to stay current, so not being motivated usually means that you're falling behind.
So I think the key cause is usually lack of motivation. And what caused the lack of motivation can be many things, but thinking that there is a "technical fix" (such as training or other ways of just getting current again) is just not solving the root cause of the problem.
To answer the OP question: check if the motivation is still intact (you may be dealing with plain old incompetence), and if it isn't (which is the category I believe most cases fall into), you can try to figure out what caused it. My experience is that rekindling motivation can be really hard, so the best is to try guiding the coworker to seek out new and more exciting challenges.
Alas, you cannot change other people, it's absolutely impossible !
You can probably manipulate him (it's quite easy), but there will be some unpredictable side-effects (some may be dangerous for you !), so I won't recommend it.
In fact, it's almost impossible to change ourselves, and the change's process is quite mysterious, since it doesn't depend on will power, contrary on what most people believe.
In fact, his problem is that he wants to NOT change, and not changing is already taking all his efforts.
He's probably trying to keep control of his life, even though it's just an illusion, since nobody can control his life. I may die tomorrow, who knows ?
Since you probably want an action, here are a few suggestions:
1) DO NOT HELP HIM, let him suffer from his own incompetence. When he'll reach the bottom (which may happen in a long time), he'll be forced to stop resisting.
That's what most people have to suffer in order to grow.
2) talk to him, and ask him what he fears. Our fears are mostly mental images, without real basis.
Expressing fears by talking or writing helps people realize that. I saw other techniques like EMDR, but you are not a therapist !
3) ask him what he will do once he'll lose his job. People rarely realize that their job doesn't need them.
I call this technique "electroshock", it'll force him to think about his job.
4) change yourself ! Since you cannot change others' perceptions, just change yours.
Realize that you want control in your life, and just abandon this control.
You'll notice that fear appears, but it's not real.
Once you accepted that this fear is not real, you'll notice that most of your efforts become useless.
In fact, change is effortless, and only resistance requires effort.
Once you'll reduce your efforts, you'll notice how much efforts people put in their lives, just to match reality with their dreams.
When you start changing effortlessly, you'll notice that you understand other people's miseries better, then people will try to mimick your natural way of being.
Tell them to be themselves, and you'll notice that they'll start changing, but very slowly.
5) read a good book about NLP, which is full of manipulation's techniques.
I personally don't recommend that, since it will give you a false sense of control, but it works sometimes.
Finally, I'll you ask a few questions:
1) why do you want to help him ? Is this because you are compassionate or do you want to have a better image of yourself ? I'm such a good guy, I can help people at my work.
2) you cannot change other people, why do you believe that you'll be able to achieve something ? If you have the expectation of changing him, you'll be disappointed, since he's probably comfortable in his current life.
3) why can't you accept him as he is ? If you work with him, just show him how to work efficiently. If you don't work with him, why do you care ?
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?"
Promote them to management, they'll fit right in and might even know a bit about the actual process. They won't be your friend anymore though, so it's OK to keep complaining about them on Slashdot. Problem solved.
Q: Where do you see yourself in 10 years?
If you answered anything but 'In a Mirror', then you're fired. Those are the arbitrary requirements I've created for you. I mean, you failed to mention if concurrency and revision control were part of the job -- I know good software engineers that can't operate new revision control, and it's not in their job description.... I really can't say what should be done to help because I don't have all the details. Furthermore, if you have incompetent management then that's the real problem. The best way to fix that issue is with HR. Google something called a "Two Weeks" notice.
> 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.
... they die! They die screaming!
You know what you must do.
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.
Well, what could happen is that such programmer would be sent to help a more "current" programmer in a task.
Because, you know, old programmers can do things like algorithms and can use their experience in problem solving.
Or, as just happened to me, told to wrote the algorithm, given the book where the language is described and figure out how to translate the algorithm.
But that is just me.
I do most of my extra learning on the job and by listening to tech podcasts during my commute
Listening to podcasts and other news sources isn't the same as actually having to code something. Yeah, your a step ahead by knowing what's out there, but I wouldn't call myself current. 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.
I'm currently helping my father-in-law get up to speed on C#. He's a BSME, has been designing, coding hardware test cases in Perl for a decade or so for embedded systems for top secret military hardware.
He's having a hard time with the WPF stuff. He is in no way stupid or unskilled or anything. He thought it would be easy - I kind of thought so too considering his background.
That's the sucky part of this industry - you MUST code. There's no way around it. Just hearing about technology is like watching the news and thinking you know all you need to know about an issue.
tl;dr (ANd I'm tired) You don't know anything until you're up to your neck in code.
Fundamentals of current Languages basically haven't changed since the 90's. Are you saying that new people who don't know whatever silly framework you use?
hire someone with a real Computer Science degree, and can pick the language up trivially.
I suppose there have been changes in platforms, kinda... but how often does this happen? iOS maybe? Everything else is just learning new classes/libraries. /grew up on 6502 assembly, so I GoTz MaD SkIllZ
I haven't been a professional programmer in 10 years ( moved into Infosec ) , and I had not coded one single line of Objective C. After a week with iOS, I pretty much had it down pat. So you have to hit the reference manuals if you don't know how to do something.
Comment removed based on user account deletion
keep stagnant then blame foreigners on h1b for lowering your value.
Grow up, they didn't. Life's a bitch sometimes.
Revision control, code reviews and concurrent programming...oh my. Since when is any of this an example of something new?
I find myself wishing something significant has changed for the better after all this time yet when I look out all I see are lemmings who don't fundementally understand why they are doing what their doing, reality defying memes of the marketeers and constant reinvention.
It seems to me all we are fucking doing lately is repainting load bearing pillars errected by those who came before us while arrogantly claiming to have accomplished something meaningful...our hubris is deafening.
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.
This is very funny in that I usually see the opposite situation in my experience, i.e., the new kids
can't write a "concurrent" application to save their butts.
Maybe it's the MS virus/programming memtality or the lazy way their taught nowadays by their college instructors;
if there isn't a class/method/whatever, then it can't be done. Ask any of them (youngins') to use sscanf, tsearch, snprintf, etc.
(these examples are from libc in the C programming language) in an intelligent way and you'll see the deer in the headlights stare.
How 'bout lex, getopt - these are some of the basics not mentioned any more.
The Fine Article brings nothing of value to the table.
They no longer have the skills to do the job the company requires, so it is reasonable to fire them.
Handling people there's always something that pushes their buttons.. you have to wisely find their's:
-Ultimate Stickman Game Developer Infinite World Puzzler
I am slightly irritated with the stupid barely-graduated Dunning-Kruger dimwits out there, who seem to think that if you're old enough to have accumulated the responsibilities of an adult (as opposed to burning yourself out and wasting your youth working 70-hour weeks for stock options), then you're some kind of shirking cunt.
The Peter Pan syndrome is alive and well, it seems.
The OP quotes a single data point of somebody with a few years under their belt (and a bad attitude), and then with very broad brushstrokes, paints anybody who isn't junior and wet-behind-the-years a waste of space.
Accumulating know-how in pointless brand-new hipster technologies when you're a graduate (and have nothing better to do) is one thing. It's quite another to have the experience to know how to most efficient devote your limited time and energy.
When you say "current," are you sure you don't mean "popular?" Using version control is something every developer should know how to do. Concurrency is very tricky to get right, but is still something developers should at least know the basics of.
In my experience with older developers, they know the basics very well, but aren't familiar with the newer fads. Five years ago it was ruby on rails. Now it's node.js. Who knows what it will be next year, or even next month?
Spray him with tree pruning sealer and then smack him with ripped goosefeather pillows.
> "and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up"
God damn it, I told you to stop using VSS!
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Version control is not new. CVS is over 20 years old and by far isn't the oldest version control system, even following the RCS lineage.
Can't handle version control? That doesn't make him an older programmer; it makes him a BAD programmer with experience.
(This coming from a programmer rapidly nearing forty years old but who started in high school.)
A lot of programmers fall into this track because they have not been given the opporunity to develop or learn new skills. If the company only expects this person to keep grinding out the same old Fortran/Cobol/VisualBasic code and never gives them chances at learning, then the company gets what it deserves: a problem employee.
My suggestion: give the person opportunities and work time to develop. An employee is a long-term investment - if this works, you'll get a better employee. Remember that this person has lots of business knowledge that they bring to the table and some sort of track record better than a new hire.
What if it doesn't work? The dude isn't interested in learning anything new. Well, what you describe is potentially a problem employee. The type of employee that insists on using stinky old technology without justifying it with any sort of valid analysis. The sort of employee that says "If it isn't written in VisualBasic, you'll have to find someone else to run the project." The answer to this is REMOVAL FROM ROLE. If you can't fire them send them off to some dead-end part of the company where they can do less harm: you know, Human Resources, Facilities, Projects...
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.
Yeah, until that single legacy system that the entire company is dependent upon goes down at 2am and the previous days transactions don't get processed until the problem is corrected and the system brought back online. But, oh...where's Bob...the only guy in the company that knows anything about that legacy system? That's right he got let go last month because because some junior programmer thought Bob's skills were irrelevant and bitched to management that Bob wasn't learning the latest fly-by-night buzzword programming language that will be replaced by the next big thing in less than a year.
There's nothing you can do directly if you're not in a position to make management decisions. The only thing you can do is do what you do -- the best you can do it.
I started the transition from HW to SW back at a company that had (for even older projects) a paper tape reader/writer for a two-pass assembler, and I've toggled the bits into UVEPROMs by hand.
For version control, I started with SCCS, through RVS, CVS, and Subversion, and am "gitting" a handle on git. That's not a currency issue. Source code control is a fundamental skill, regardless of languages and other tools.
"Concurrent programming" sounds like, maybe, you can't really explain your stuff either. There are significant differences between a simple uniprocessor microkernel where you have to share some variables between threads but handle your own context switches, a preemptible kernel where you definitely need data protection constructs (mutexes, ...), and a fully multithreaded application on "who knows how many" CPU cores (along with interrupt/signal handling) where there can be literal concurrent execution. With even small embedded systems running multiple core SoCs, knowing how to deal with that is also a fundamental skill.
"Currency" issues are more usually the language/framework/tool set "de jour", and, having seen far too many of them come and go, I no longer get really enthused about them. I use languages and operating systems as tools; if it solves a problem I need to solve, without a lot of silly hoop-jumping to work around missing or awkward behavior, then I can write in any of several languages. OTOH, I'm still an emacs guy, 'cause I've yet to find a better tool for creating source code, and, yes, I've tried a LOT of them.
Don't get in his face, but don't cover for him either. Let your management decide when he's more trouble than he's worth.
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)
This is not a programmer issue. This is an employer issue. If the employer want to embrace new technologies, they would train their employees. If the employer refuse to train their employees, then F U employer, you have nothing to complain about.
... what we did is first give a verbal warning, then a written warning, and then bust them a pay grade. Oh wait, that takes a manager with balls. Maybe you should be looking at your company's management training first? Sounds to me like you have spineless managers that either ignore problems, or can't articulate problems to the underperforming individual, or lack the courage to have difficult conversations.
...they are made managers. And there's not a damn thing you can do about it.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
"More importantly, how do you do so without stepping on anyone's feelings?"
Is that really more important? Because it seems to me that, at the end of the day, engineering has to be about successful design and creation of things, not about feelings.
Being careful about people's feelings is important. If you want to succeed in solving problems, it is pretty much necessary. But you also have to be able to accept that, sometimes, people will be unhappy about things which are true, or hurt by things they need to be informed of.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
that the guy is not in charge. could be worse. he could be a manager because of his seniority and be resentful of any new techniques of solving old problems.
Any guest worker system is indistinguishable from indentured servitude.
If you get paid, do whatever it takes to maintain the cash flow.
I don't care if my bosses drool constantly and shit themselves at random times during the workday so long as I get paid. If they want me to humor them, fine.
If they prefer to be affirmed in their stupidity and will punish dissent, fine, I have zero moral obligation to human obstacles.
I don't care if they crater their company, torch the buildings, then dance around them naked so long as I get paid. (I'd like to capture it on video then monetize it though.)
Businesses are expendable constructs to make money. Pay me and I don't give a shit what happens to their construct.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
> 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
Let me start off by saying I'm assuming you're right out of college and the guy you're talking about is around 10 years in. If I'm wrong, please ignore this.
Are you sure you know how to write concurrent code? Are you locking a read only object? Are you sure you aren't missing something? Someone with 10+ years in the biz survived something called the dot com bust which not many people survived. Everything is web now a days, concurrent code isn't that important unless you are using application objects or something. If you are writing engines, then yes, concurrent code is important. Are you writing engines?
Version control (revision control? WTF is that?) causing a mess is probably up to the version control setup guy. If you're complaining he's checking in his bin directory, he shouldn't have to think about that. How do you make a mess of version control other than just not checking stuff in?
Code reviews are pretty fucking stupid, IMO. No one wants to have to analyze someone else's code when they have a deadline. Test your own shit then send it to QA. If QA bounces it back, learn to test better.
I feel like if you're junior to someone who won't take criticism well, and you can't get the manager to do something about it, then you have a management problem. You should be doing what you should always do in this situation: move to a different position where you are not under this manager or leave your job for a one with a decent boss.
This is not an issue just about his ability to program at this point.
Buy them a Cessna and point them to the nearest IRS building?
Seven puppies were harmed during the making of this post.
You are a wise man, really this sounds like me 3 years ago. Hindsight is 20/20, but looking back I wish I has listened to someone like you, Mr. Miyagi.
I can see it now, a star chamber filled with emotionless shadowy figures. You are summoned and tested by arbitrary standards. You try to object; you are summarily hustled out and told you'll be informed in three days.
The predictable outcome: You're too old. It doesn't matter what your skill set is; we judge simply on age.
What could go wrong? Sounds like a perfect socialist societal model to me.
Pass messages and be done with it. I've never programmed Erlang, but that's the approach there and it has a reputation for being very robust. I always reinvent message passing with I have to do multi-threaded stuff in C. It's not slow at all since you aren't actually copying the message. You're just transferring ownership of the object to the queue while the lock is held by the sender, and taking it away when the lock is held by the receiver. It's been a while since I've done it, but it wasn't that hard. The big leap was to realize that whatever approach that *wasn't* some kind of message passing would lead to exactly the kind of death spaghetti that people tend to run into..
A gentle suggestion that they consider moving up to a Business Analyst or Project Manager role which would use their hopefully wide range of knowledge from past experiences. This would be better than alienating them for sticking to a technology that they know well and seemed to still be required. Sometimes you get given the impression that your skill(s) are still relevant but the reality is that know one has stepped up and said "actually we need you to move on, learn something new". Send them on a technology refresher (there's got to be a business opportunity there).
Education institutions call them the "Untouchables" the best way to deal with them is never surrender an "important" line of business position to them. But promote them with lots of ceremonial promotions to keep them satisfied. Emeritus for example was explicitly invented for addressing egos back east.
They simply get to learn the new technologies: Congrats, you're migrating your app to Gradle next week. And no, your SCRUM team can't say no.
In other words, there is no not staying current, the apps get migrated and they get to do the work.
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.
I've fallen off your lawn, and I can't get up.
It is in the best interest of a person to keep their skills current. It is also in the best interest of the company for a person to keep their skills current. Therefore, regardless of whether the person takes initiative to keep his/her skills current, the company needs to make training, education, seminars, trade shows and other opportunities available to anyone that they value staying and growing with the company.
If you are not allowed to question your government then the government has answered your question.
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.
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.
I've fallen off your lawn, and I can't get up.
For the most part, being a programmer is not a bad job.
Above average pay and many perks usually come with the trade. Work from home for some, other perks for others.
So, if a programmer doesn't keep up with the trends, that's "mea culpa".
We can't be in this business and not try and stay informed. It's just does NOT compute.
This is a business where we must keep learning. So, anybody who doesn't want to upgrade their skills, isn't someone worth hiring in the first place. It should truly be one of the many requirements when hiring a programmer.
And if they don't want to upgrade their skills, then hire someone new.
Just to give a perspective on these new fangled technologies you speak of. I used it on a unix workstation to store my c code at uni 20 years ago - I never assumed either were new then. The 2nd year had a series of lectures devoted to concurrency.
I've had new graduates lecture me "we should use x" then be surprised when not only am I aware of it but know more about it than they do. I want to use new stuff but only where appropriate. Hell its more fun learning/using something new. (well unless it's the metro interface ofc).
I talk to them. Explain that while the skills they have are good, the business requires that they gain addition skills and explain why (e.g the new way is going to enable us to deliver collaborative code faster etc..). Then offer them education and mentoring opportunities. If they don't take them then explain that eventually if the skills that they have are no longer what the business requires then the role may be made redundant as it doesn't make sense for the business to pay people who can't deliver what they need.
you are just another cubicle drone who should mind their own business. Damn busybody.
.There always new technologies in the market.
Normal scenario i heard.
I learn visual studio 2003, i don't know how to code in Visual Studio 2012. So the junior also have to code old code old visual studio 2003 /php is enough.. Client wanted fast................
I don't know mvc thing. So why we need those spring. just write in plain jsp
In reality not all new technologies become hippies in the market.
1.Flash application. in 2001 kinda hot but in the end nobody use except adobe flex developer,Microsoft silverlight developer.
2.Java applet . in 1998 till 2001.Kinda hot and dim..
Multiactivity is a subset of concurrency, and can be solved safely and easily using the actor model. The other concurrent problem is parallelism, which can also be made easy by using one of the loads of libraries that do the dirty work for you. As long as you divide a concurrent problem into a multiactivity part and a parallel computation part and don't try to mix the two, concurrency is a solved problem.
My company has a training program. All relevant and semi relevant educational needs are paid for. Even if you make minimum wage at our company you can go to college as long as you make good grades. The only catch is it has to be either something that is relevant to your position or college, and you can't fuck up and get poor grades. It's sad, but less than 10% of the people of our workplace take advantage of it, even though we go out of our way to let EVERYONE know about it multiple times. Part of being in I.T. is staying up to date. if you don't stay up to date...well enjoy the door hitting you in the ass on the way out.
At first they came for the COBOL programmers ...
and I said nothing because I didn't like whitespace having special meaning.
Then they came for the LISP programmers
and I said nothing because I didn't care for parentheses.
Then they came for the C programmers
and I said nothing because I had C++ and OOP.
All those moments will be lost in time, like tears in rain.
You act as if versioning systems and concurrent programming have only been invented in the last ten years. And that is simply not true, so there must be another problem underlying yours.
Religion is what happens when nature strikes and groupthink goes wrong.
no? then shut the fuck up.
There are always programmers who didn't not bothered to remember their math course. They usually have enough coding knowledge that they provide some value, but from a technical perspective they are a slowly-increasing liability. As an example: I work with a developer who is 10 years younger, but still doesn't understand how to extract rotation matrix from coordinate transformation matrix and cannot be trusted to code gradient descent without causing a mess that somebody else will have to clean up. On top of that, he is really resistant to the idea of refreshing his math skills; I suspect he dislikes people he considers senior to him making suggestions about how to improve his math knowledge. 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?
Here is a really similar situation. Smaller development team working as consultants on code that gets deployed to multiple operating systems and supports a large number of clients. The girl that's been there the longest insists on coding everything in Perl and using CPAN modules that haven't been updated in years. Not to mention that this extends to Windows, not just *nix systems.
New people who have arrived in the last two years can code in Ruby, Python, Scala, JS, and other languages and keep up-to-date with where things are moving, but the first person mentioned is very very resistant to change. It doesn't help that the entire client base uses primarily Python. This girl is really, really bright and can easily pick up new things, so how do you get her out of her comfort zone and trying a bunch of new things?
doesn't understand how to write concurrent code (...)
Somehow this reads to me as the guy doesn't properly appreciate the miracles of the yet another asynchronous, event-loop based, callback-infested, buzz-driven and hipster-promoted "solution" to concurrency problems which in reality is reinventing the concepts from more than 20 years ago.
" On top of that, he is really resistant to the idea of code reviews"
This equals to admitting your code is bad. End of discussion. Subject is probably an attention whore.
I work with a developer who is 10 years my senior, but ... cannot be trusted to use a revision control system
Stop. Right. There.
He cannot even use an RCS?
See $subject.
Il n'y a pas de Planet B.
> 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
This is not a skill set issue. Really it is not.
This is an attitude and competency problem.
Added to which, if you start off with the wrong analysis that it is a skill set issue and mix age in with your analysis as a probable root cause, you are likely to start down the road of making damaging assumptions with adverse implications for other employees and devalue perfectly good software engineers unnecessarily
..they're useful as garden fertilizer.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Firstly you have to be aware of all the stuff you don't knoÅ yourself. Like how the company works, how to get things done there, what is important to the company and what is not (and it ain't knowing how the latest source control system works). Then you have to figure that 'programmer who hasn't stayed current' will probably be you one day. That's a good place to start.
Then you will have to figure out why people don't stay current. Maybe he's lazy or stupid, maybe he's smart enough to understand that just knowing the latest buzz phrase isn't that important getting good systems written.
The arrogance and naÃveté of youth is an asset, and overturning the old guard is an important part of keeping an organisation fresh, but at some time you'll become more aware of what you don't know tan what you do, and the consequent humility will be a great assets to you.
Firstly, I think all three of these issues are not linked in any way. If there is a way to get code working without concurrency, and your programmer is able to get that to work with all your use cases on your platform, you should just be fine. If not, you should give him ways by which he could learn concurrent programming and implement it for your given context/program.. Honestly, how much time will it take to convert his code to concurrent code - if there is no other way to run it. Secondly, for code reviews - if he's the only guy to resist it in your team/company, you have a big problem of teaming. This is a big "NO" in any group that does complex software development, you need really good team players to be in there. Your hiring process needs to be fixed or a reassignment is the only thing that could work. Insisting on a process that's uniform across the board - irrespective of age would make this work. Thirdly, for the age part - you ought to be sensitive enough and mature enough to know how to handle senior talent. It might be hard to remould them, since they are already molded in a particular way, but if you are able to gain their respect - then they could make magic..With age comes maturity - commitment and a lack of fear, but also stubbornness, lack of mold-ability, etc caused due to lack of of RESPECT. People are normally rational beings who upon respect would act in their own self-interests and perform...but you got to have them respect you. If the person you are talking about never respects, you then no matter what you try to do, he/she's going to duck it and continue down the same path, making it hard. The key - earn their respect through action ( and not talk,) and compassion and make them see the point. The ice has got to break, and the faster it is done, the better of a leader you are.
Someone in your company will be responsible for on ensuring on going professional development. If your company doesn't do this, they can hardly complain that their employees don't have the right skills. Recommend training, for everyone if necessary.
Also, allocate some time for people to do personal professional development, and provide suitable materials.
Software engineering is about constantly learning. Anyone who fails to do that, is a waste of space.
If you have a developer who can't handle simple branch/merge workflows in source control, they must have a serious problem. Perhaps this individual just isn't capable of software development, and never has been?
Code Review is at the wrong end of the process. Far more important is a design review. The higher up the chain the better.
In my experience code review is a chance for those of a nit-picker mentality to shine. Those who want everything to be in the right column, but fail to see the "big picture".
Getting some young developer in who is gung ho about the latest buzzwords he reads on blogs
requiers very little effort, especially on the market place today.
Getting a good young developer is harder.
But both tasks are a lot simpler than finding a developer of any age, who has a thorough
and deep understanding the business. Yeah maybe there are fancier new languages,
maybe more efficient patterns, but to the stakeholders who are paying for the effort,
and to the end users, those things dont matter.
A functional system that is built in top of a deep insight into how the business works
is much better, than a fast efficient multi threaded application written in Erlang with
built in scripting support for LUA, coded up by a team of young consultants who spent
2 days to a week analyzing the business.
...or sometimes put into a job they can do - if they are well liked. It is as simple as that.
I am very small, utmostly microscopic.
One of the basic job requirements for my developers is to stay current on new technologies and always to be looking for ways to make our products better. I've never had a developer fail to do that, but if I did notice a developer starting to fall behind, I would do everything i could to save my enormous investment in them.
Really, losing an employee is very costly in terms of lost experience and having to go through the engagement process and bring someone new up to speed. It's the LAST thing I want to do.
A lot of the time, employees will get bored or something and start spinning their wheels. It's important to give employees the opportunity to spend some time on other things. I give employees 1 month out of the year to work on "fun" projects - stuff they're interested in doing, new and interesting technologies, or things that are otherwise off-mission but a break from the routine. I think it has been a success for me, and we as a company have learned a lot of new things from it.
And, most importantly, how do you do so without stepping on anybody's feelings?
"You're living in a world of make-believe with flowers and bells and leprechauns and magic frogs with funny little hats."
- Homer Simpson
You let him crash and burn. You put oil on the fire, everytime gets pissed of at this guy. Later on, you get together and talk to his manager/boss/supervisor.
You do this in a clever way; as in under the radar. This, however, requires knowledge of social mechanics.
If you try to keep that person from crashing and burning; you'll have to deal with it, for as long as you work with this guy.
Version control is realy old, BTW...
Here be signatures
Why has your organisation allowed a senior developer to stagnate? Why has he not been given continuous mentoring, training, qualifications etc?
Sounds like your company has failed to educate and train its' workforce and is now suffering. The answer to this question is not "train him" but "examine your training and career progression policies" as it sounds like they need a massive improvement. If they event exist at all.
Is it the burden of the individual to continually upgrade their skills on their own time at their own cost, or does the company have a responsibility to provide access to training if they need constantly updated skills from their workers?
Also, what is the role of the programmer? For example, if the programmer's job is to design efficient algorithms for the team to implement in code, do they really need to understand a specific language or can they communicate effectively in pseudocode?
Finally, which is more important: knowing three dozen different languages for programming OR knowing three languages that are representative of various styles and being able to generalize programming methodologies and use research to find the specifics of the language. For example, suppose I know JavaScript, C++, and C backwards and forwards but not Java; how hard do you think it would be for me to use the internet or a book to research the Java and apply my knowledge on a per-case basis without crowding my brain full of unused garbage?
As to the example coworker you defined - I don't think the issue is that the programming language knowledge is out of date. It sounds more like the coworker is not a team player and is unable to take constructive criticism - the person could be up to date in every programming language and tool out there and this would still be a problem.
We just upgraded from CVS and SVN to GIT. Strangely enough it was the young programmers at our company who were the slowest to adopt. I've used multiple source code repositories throughout my career, so adopting a new one was just business as usual. But for many of the young programmers at our company this was the first time they have changed from one system to another. As IOS and Android development has picked up and we've asked the programmers to learn this, programmers in their 40's and 50's can rely upon their skills in moving from one system to another previously. We actually have a programmer in his 30's who has refused to work on anything but .NET applications on the desktop. Go figure. Not keeping up doesn't have much to do with age it is mindset. However your question is silly. Just let them go. Jobs aren't gifts; you only keep employing someone as long as their output makes more money than they cost. If that concept is too difficult for your management, maybe it is your managers who aren't keeping up.
We have a huge problem with this in my office. A couple of us are working on a new application that utilizes MVC, and a heavy javascript front end which includes Knockout.js. Since this project started I have re-factored this thing 3 times the first because I was told to keep the JS limited to just pure js and jQuery, so I did. However it got complicated and I got to the point where implementing SPA made sense, my manager seemed supportive so I went about the first re-factor. On one point another developer that has not kept his skills current started pitching a fit, at which point my manager who has also not kept his skills current started taking a deeper look at the project, together they claimed it got too "complicated," and at that point I was asked to revert back to page per view, with simple js, so I spent a couple weeks doing that. This eventually created MORE complications due to the nature of the application, rather than storing data in local variables I had to persist through cookies and all kinds of shenanigans. Short of going back and implementing the entire thing in with razor and persisting in session state, which I could have done but given the work I had done thus far was mostly on the client, this would have basically been a re-write of the entire front end. I talked to my managers boss about my frustrations with the indecision of my manager and she said that she absolutely wanted me to do it in SPA as that best represented the vision that she had for the project. So I went and re-factored it AGAIN using knockout, although to be honest this is the way I wanted to do it in the first place so I am happy with the outcome.
In any case, my point is that just a couple developers that have not kept their skills up to date have caused a lot of frustration for the department. The rest of us are all on board with this new way of doing things, why should we cater to the lowest common denominator? In my opinion if these guys doing want to keep their skills up to date they should be relegated to maintenance and legacy applications. We shouldn't hold the rest of the department back because two guys don't want to learn new things, one of which happens to be my manager unfortunately (but doesn't really have the authority to let me go, more like a team lead I guess). As far as I am concerned, you either get with the program or get out of the way and fortunately for me my bosses boss (the VP of IT) is on board with this so I've at least gotten my way in this case lol.
You realize there is far more to a corporation and the people under its employ than some arbitrary wizz bang tech skill. If the individual is doing their job satisfactorily and their management is happy with them you should go have a fresh cup of STFU. Every year you fucking punks come out of some shitty uni thinking you're hot tits and can do no wrong, posting on here about "how can I tell these omg old ppl how to do their job"
Go fuck yourself with a point pencil for a few minutes. That burning sensation you now feel? That's you. You are a rectal tear on society until you grow out of your annoying post uni phase and realize that guy you're bitching about is you in 10 years. And guess what fuck head, that guy is doing his job. You're not his fucking manager, so stop pretending you could be and sit the fuck down and shut the fuck up. Maybe, just maybe, you'll learn something and stop being such a fucking twat.
Oh, and get the fuck off my lawn you miserable little twat. Come back when you have some real experience beyond writing 5 lines of code for some gay faggot cs101 course in Knuth MMIX assembler.
A good engineer / programmer understands fundamental things that matter far more than the latest language trends, if you are dealing with non-trivial problems.
If you could magically have Knuth, Dijkstra or Hoare look at a hard problem do you think they'd do a lousy job? If you do, you need to go back and read the stuff those guys have written.
Having a soup of buzzwords is fine, but it is worth less than nothing if they don't understand how to look at a problem and determine the dependencies of the problem. The best case for the geewhiz person will be that they by-chance end up using a pattern someone else came up with that maps. The worst case is you get something that looks nice and seems nice but is neither correct or robust.
Concurrency didn't start with cheap desktop mult-icore microprocessors. Dijkstra wrote his stuff about Sempaphores in the mid sixties.
There's a hell of a lot to be said for sitting in a quiet place and thinking through a problem perhaps with a pencil and piece of paper. If you've never worked on a problem that required you to do that, then either your problems have been easy or you're an unsung genius.
Well, give the person an opportunity to learn and USE WHAT HE LEARNS. I've "learned" a lot of so-called relevant skills but never have any chance to use them because people keep paying me to do older stuff. I've gotten to where I am reluctant to invest my time and money learning skills no one will pay me to use. Maybe old == smart in this case.
BTW, anyone who is honest will (1) admit concurrency is difficult, and (2) admit most concurrent implementations are mind-blowing. Every tried to trace Android's over-engineered multimedia framework? It's an absolute nightmare. I think whoever wrote it channeled the ghost of Rube Goldberg.
Most concurrency seems to be constantly checking to see if an object is null or not because the poorly-designed frameworks never know when something has been initialized or not.
This is something that should be handled by his superior. It's his superior's job to slap him on the wrist if he moans about code reviews and doesn't take being up to date seriously. In my experience, management that doesn't have the guts or skills for straightforward communication is one of the worst obstacles to efficiency.
From the question:
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.
What you said:
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.
And if those people moved either up or sideways to continue to provide that benefit, that is great. The problem is when those people are still doing technical work that lead to bad code, bad design, bad practices and bad solutions that they can do by virtue of their seniority. It's very hard to rein in someone who has more experience, longer work history and who has more management clout from making bad decisions even when they really are bad. There's at least three ways to make a senior person butt out like trust, vanity or distraction. The best is of course if they just relinquish control if they trust me, which usually comes along. If that fails, there's always vanity as no senior person really likes to hear he's dealing with the nitty-gritty implementation details and the third is just to run up requirements/business side issues until they leave more of the tech side to you.
Is it a bit cynical and cruel? Perhaps, but I really don't want to have a manager that I feel is holding everyone back, push them towards where they can shine and leave me some room to shine on my own. The best managers seem to have this figured out on their own, they know when to provide direction and guidelines but also when to back off and let the people who know all the details make the right decision. But the world isn't full of great managers and really, you can waste a lot of time and great code writing a flawed system that can't ever really work and perform the way it was supposed to. And nobody cared how great your wall was when the whole house caves in.
Live today, because you never know what tomorrow brings
That's what a training budget is for. Offer them the opportunity to learn something new. Offer it over and over again. If they don't take it and there is no business sense in keeping them around - lay them off. If this happens to you, never turn down training.
"How do you deal with programmers who have not stayed current with new technologies?"
The hiring of anyone is based on applicable skills. The applicable skill for programming is the ability to learn.
It seems odd that companies would not assess skills required for the actual job at hand rather than demand 'The New Skill-Set'.
Our company has gone through a couple fiascos due to programmers due to this myth.
To be clear, just because a programmer 'knows' a language does not necessarily make that programmer any good at programming in that
language or any other.
Also, Just because a programmer doesn't know 'Current Technologies', does not mean they are poor programmers. In fact, it's often
better to hire someone who is willing and able to READ THE MANUAL and get up to speed, which is what most good programmers do
anyway.
Give a new prospect a test to see if they can, and are willing to, learn.
--TEST--
Read and perform the following tasks and questions.
If you cannot complete a task for some reason, write why you cannot, and how you would go about getting enough information to complete the task.
Question/Task #1: Write a small program in C/C++ that opens a file, writes a string to that file, closes the file, opens the file again and reads the data to the screen.
Question/Task #2: Look at the following code. What do you think it does?
Question/Task #3: How would you learn to write a small program in a language like ? How long do you think that would take? Would you require access to the language reference manual after a week of programming in ?
Question/Task #4: Document the following code.
( DELIVER C A =>B )
[
LVAR X #
LVAR Y #
X = ChuckaBlocka(A) #
Y = HumBucket(X B) #
BegaBoards = YodelMax(Y) #
]
)
--End Test--
The point of the test questions may seem obvious at first, but each question has a alterior motives other than the task.
The idea is to get some insight into HOW the programmer thinks and attempts to resolve the problems.
I would rather hire an older programmer who is able to learn and identify patterns, than any programmer with
'the new technology' who has none of those pattern comprehension skills.
Many of the systems and technologies out there are âoelegacy" and require someone with and âoeolder" skill set. Many of those systems are still being sold.
One great way is to promote innovation in a company. As some have noted, some people have families to think about outside of work that hacking on something new outside the office is not always a priority. In the office however you can encourage people to try something new by allowing a certain percentage of innovation time. Then once every 12-14 weeks allow debs to focus on their in ovation projects awarding the winning project.
You get:
Devs trying something new
New skills being bred
New ideas for your workplace
Possibly new productivity tools
A great environment to work in
People encouraged to work as a team
There is a lot of tech out there now and nurturing skills is very important especially if someone needs to decide if they want to stay employed.
That's right, the 2ic of the Linux kernel, Andrew Morton, flatly refuses to work with patches and still sends his revisions to Mr Torvalds in massive tarballs, a cause of merciless jibes from the latter. Linus laughs it off and puts it down to Mr Morton's eccentricities (but he also puts up with it).
Does this anachronistic obstinacy make Andrew Morton a "bad" programmer?
Where I work, they pay for every engineer to attend a conference of their own choosing. This year, I am going to the Cassandra summit in San Francisco. Last year, I went to the Lucene Revolution conference in Boston. The year before that, I attended Velocity. Zoosk is still a start up but has been around for six years. They run R&D projects about twice a year for new hires and conduct a hack days competion every year. They have one project where six engineers are working with new technology to reinvent their whole stack.
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 still don't understand how you consider any of these "new" - they're all decades old...
This has nothing to do with "old guy" senior programmers; my experience has shown that this is a problem with some people regardless of their years of experience.
Fire them all and let unemployment sort them out.
More seriously, if he can't produce the code you need, or maintain older code, whatever, he really does need to be moved out.
Steven
Step on his feelings. This kind of thing needs to show up on their (annual) reviews, and their performance should be derated. That doesn't necessarily mean fired, but their performance evaluation should be penalized. That would generally mean a failure to get COLA increases, to say nothing of merit increases. If they have 10 year old skills, then their wages should be frozen as of 10 years ago. If you don't have annual reviews, your company has a problem. That's what managers are for. If they're not doing their job, that should show up on their reviews as well.
Are they worried about hurting this guy's feelings? This isn't a daycare. Are you worried about this guy leaving for another company and taking valuable information with him? He's not going anywhere, no one else would hire him with skills that old.
If you have a company that mature without either annual reviews or management that feels that they should manage, your company has a dire problem and you should get out of there. The way you phrase this makes it sound like it's actually a government position, and sadly that is more par for the course. Now you know why people don't like paying their taxes.
--
$tar -xvf
I'm in my mid 20's, I do not touch C# or Java. I avoid them like the plague. I code in C/C++ for CLI based applications solely. I have no reason to write "concurrent" code. I write what we call multi-threaded code which is very fun. I write low level system daemons. I typically code solo so no use for a repo except for my own personal desires to branch features and backup code etc.
I will always have a niche because all of you trying to stay "current" run off and obsess over coding a webapp and learning the new buzz word. While you're all competing for work, I'll be fought over for legacy positions when these older gents retire because they'd rather spend time with their families than worry about how to write a new app for their smartphone. I envy and can't wait to join them!
And work it out. It's not hard. McDonalds is a good shelling point for putting away your pride and solving your problems. Only downside is that it's completely disgusting. Sometimes, sacrifices need to be made for the greater good.
Or as a friend says, "I didn't leave programming, it left me".
The goal of most commercial development efforts is, or should be, to solve a business problem in the most permanent and cost effective way. Cost effective is a combination of the initial effort, ongoing maintenance and the cost of hardware required to run the solution.
I haven't seen many shiny *new* tools that do that any better than the *old* tools did. When you have been in this business long enough and you see the same wonderful *new* ideas come around for the third time you get a bit jaded. You realize just how pointless this wonderful new thing is. You will solve the same problem but using MUCH slower development tools and environments and in the end the product itself will be slower.
If this new skill you are hoping they will adopt is as indispensable as you seem to think it is, then lead by example! Show them how quickly you can solve the problem and how easy the new code base will be to maintain. If you can do that and they are still not interested then they are simply in the wrong business. On the other hand don't be surprised if you find out they can do the same but much quicker with their own tools and possibly produce code that runs as much as 1000 times faster. Will you be able to swallow your pride and acknowledge that you are full of BS? I doubt it.
Writing for concurrency is far from a new concept and not being able to do that is not indicative of a faded skill set. That is an essential skill set which was never acquired. Revision control systems have been around for a long time. Most systems can be learned well enough to use properly in just a few hours and they are essential to effective team work. Again not what I would call a faded skill. This is a fundamental lack. As to code reviews those cut both ways. Their pride will recover quite nicely when they review YOUR code.
Are you REALLY interested in how to make this person productive? Team your one of your "old" guys with one of the "young" guys. They will BOTH learn a lot.
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
I think I'd like something like this on a T-shirt.
-x
>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.
The developer in question just isn't competent. Concurrent programming dates to at least 1950 and SCCS came about in 1972.
>So, how do my fellow Slashdotters handle situations like this?
Avoid them where possible and work around the damage. For instance good test automation will limit how long their mistakes go undetected.
>How do you help somebody like this to improve their skill-sets?
You don't. Understanding concurrency is one of the programming aptitudes which can't be taught.
gosgog:
FIRE HIS/HER ASS....if they are in the Hi Tech Industry & don't continue to learn...again FIRE 'EM, they're lazy !
I would probably fit, started working as a programmer 17 years ago. I've always LOVED building stuff, so I never moved up the ladder.
A workplace makes a huge difference to learning new tech. One will be able to learn what one uses the easiest, else it just stays theoretical knowledge that gets rusty quite quickly. If a company insists on using an application server two versions back from current ("its tested, it works, we know its quirks") - well, learning what makes some other AS great will not be very easy in your private capacity as opposed to an enterprise environment.
When I started as a newbie, a lot of emphasis was placed on the "peripheral" stuff (version control, formal testing, modelling, design, documentation, code reviews, project management, etc. etc.) In other words, Software Engineering as opposed to just Coding. As years have progressed (and I have moved between jobs) it seems that the younger folks see the value of these activities less and less, as opposed to what is described in the post. Companies are looking to hire the Crack Cowboy Coders, to pull them through. Of course newfangled buzzwords are bandied about ("Agile" was the last one I paid attention to) but even those don't get done (and I don't even think it's a bad idea - but of course ideas are worth nothing if they don't get implemented).
All of this leaves me with a sense of dread and despair, since I have recently gone through a spate of interviews and eventually change jobs, but NONE of the companies I interviewed seemed to ask the right questions - all where just on about the "right" mix of new-version tech buzzwords. "You know JBoss? No, sorry, we want someone that knows Weblogic..."
At my current employer, a fairly biggish consultancy, I've been on three different projects in 6 months. Every one uses a different database, a different application server, a different version control system, a different app framework, different coding conventions, different customizations to the Eclipse IDE, no discernible SDLC, let alone any of the other Software Engineering concepts mentioned above. I'm one of the few more senior people. I really don't know what they teach people at college these days. It doesn't look as if they will learn it while working...
In the end, a company should be more than just a loose collection of (whipper snapper) coders. It should/could be an ORGANISATION that ORGANISES their resources along the lines of personal strengths and project needs, and can use economies of scale to make the work more efficient than what individuals could do.
On the positive side, they provide free snacks. And financial and time support for courses/learning.
Free, as in your money being freed from the confines of your account.
In a state like Texas, which is a right-to-work state, you tell them to shape up or they lose their job to someone who can do it better (and likely cheaper).
Your post comes off as a just-out-of-college know-it-all who has never been on the other side of the equation. You think you're hot shit because you are up on the latest technologies, having just learned them in school. (Not trying to insult you, but this is how you sound.) If companies want people to have new skills, then need to train them. It's easy for young people with no other obligations to devote much of their spare time to learning new technologies. The guy you speak of may have been like that when he was young. Your attitude seem to reflect a current trend in American business. Everyone wants trained employees but no one want to train. This is a short-sighted approach. Or are programmers like athletes? You have a 10 or 15 year career and have to move on?
Competition Good, Monopoly Bad.
Shoot them first, ask questions later. If they get back up, shoot them in the head, because they're clearly zombie coders.
If that still doesn't work, put them on help desk.
UML was a management and inter-project requirement for coordinating code across hundreds (or even thousands) or projects within the multi-company infrastructure. We had upwards of 3000 developers working on various parts of the ERP at a time and it was a helpful tool to make sure programmers had a pretty good idea of where the project leads wanted them to go. They were never gospel, though, as we wanted creativity and flow first, standards second. Standards were my job along with spec'ing, SDLC, proper process control, HR related stuff, etc. We let programmers program and managers managed. Man, I miss that job...
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
The same way you get businesses to do anything else. Write down everything you want to accomplish and format that list as bullet points. For each item on the list, make a business case that shows why it should be done, what benefits will be realized by doing it, what risks come with not doing it and any other info you feel is pertinent. Then take that list and show it to the person that has the authority to implement the changes.
Unfortunately, many times, people will resist change if they feel it will hurt someone's feelings. This is especially true among small teams. If that's the case, then you just have to weigh the risk of not doing something against the turmoil it would create and figure out which is the lesser of two evils.