Forgot your password?
typodupeerror
Businesses Programming

Ask Slashdot: How Do You Deal With Programmers Who Have Not Stayed Current? 509

Posted by Soulskill
from the twinkie-on-a-stick dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Do You Deal With Programmers Who Have Not Stayed Current?

Comments Filter:
  • Can't offer much (Score:4, Insightful)

    by Anonymous Coward on Saturday May 11, 2013 @04:54PM (#43697281)

    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.

    • by Jimbookis (517778) on Saturday May 11, 2013 @05:06PM (#43697343)
      Oh I dunno, maybe outside of work he has plenty of other crap to think about like raise a family. Once the kids come you can forget the countless hours hacking away learning new things yourself for the sake of it like you used to.
      • by Anrego (830717) * on Saturday May 11, 2013 @05:20PM (#43697445)

        In my (admittedly limited) experience, that's exactly why people get out of the trenches and go for jobs that rely more on them knowing what the customer wants than knowing how the latest toolstack/middlewhere/design style.

        • Re: (Score:2, Insightful)

          If you don't know what the customer wants you have no business taking their money.

          • Re: (Score:3, Insightful)

            by Dunbal (464142) *
            Money is given, not taken. Unless of course you're a bank or the government.
          • by Anrego (830717) *

            Obviously everyone on a team should have a decent understanding of what the guy paying the bills wants, but keeping track of the exact details, maintaining the relationship, and pushing new business is a whole different job description.

            Maybe in a small shop the programmers can just do everything, in any reasonably sized venture things like accounting, marketting, and dealing directly with the customer are probably filled best by people who are specifically dedicated to those roles.

            At minimum, having someone

      • by DuckDodgers (541817) <keeper_of_the_wo ... m ['yah' in gap]> on Saturday May 11, 2013 @05:23PM (#43697471)
        I have several young kids, so I do most of my extra learning on the job and by listening to tech podcasts during my commute. There's http://twit.tv/show/floss-weekly [twit.tv] and http://se-radio.net/ [se-radio.net] and dozens of others. Instead of switching browser windows to Facebook while I'm waiting for a large file to move between servers, I switch to my RSS feed reader that subscribes to tech sites. And yes, maybe once or twice a year I'll buy a book on a new language and technology and force myself to read through it and toy with the examples. Figure I'm sacrificing maybe 10-20 hours of my free time for that every six months.

        But more importantly, someone that's not keeping up with the latest trends in software development is screwing themselves. I can build the Javascript for a web page without using jQuery - but it would take me three times as long, so why would I want to? I can write the server-side of a REST application in Java and Struts 1 instead of dozens of newer options, but why would I do that? I can set up a test environment or two on individual physical servers instead of having six different test environments running in virtual machines, but that just means testing runs three times slower, so what have I gained?

        In this industry, deciding you don't need to learn new things just means you're content to waste your time and the time of your colleagues.
      • Re:Can't offer much (Score:4, Informative)

        by Xest (935314) on Saturday May 11, 2013 @05:38PM (#43697563)

        That's fine and I fully agree that's a legitimate reason as to why many older developers do struggle to stay current.

        But said older developers must also recognise that that's also why they're having problems staying employed and finding jobs, they then blame ageism when in reality the problem is a life choice they have made which they do not wish to suffer the consequences of.

        The fact is you cannot give up staying current and remain a developer, the field moves too fast so you either need to jump into something like management, or accept that the inevitable result of unemployment has nothing to do with ageism and everything to do with the fact that refusing to stay current in the software development field, whilst also refusing to change career.

        It's like the underskilled Westerner who threw away all the benefits and advantages the Western education system offered him only to then blame harder working immigrants that are superior employees to him because they actually want to succeed when he can't get a job. It's a blame game, but you make your choices and have to live with them, you can't blame ageism, immigrants, or whatever for the inevitable consequences of your own choices.

        There's nothing wrong with raising a family instead of staying current as a developer, it's a perfectly fair choice, just don't then be surprised when the real world will let you no longer be a developer as a result of you opting to do other things than stay current. The world doesn't owe you the job you want to do in the way you want to do it, it's up to you to figure out what the world wants and what you feel you can and are willing to offer it that it needs.

        • by Intrepid imaginaut (1970940) on Saturday May 11, 2013 @06:03PM (#43697721)

          There's nothing wrong with raising a family instead of staying current as a developer, it's a perfectly fair choice, just don't then be surprised when the real world will let you no longer be a developer as a result of you opting to do other things than stay current. The world doesn't owe you the job you want to do in the way you want to do it, it's up to you to figure out what the world wants and what you feel you can and are willing to offer it that it needs.

          It's perfectly doable to raise a family while staying current on programming languages. It's not as though the underlying principles ever really change, which is why experienced programmers can pick up new languages with consummate ease once they grok the underlying concepts. What you're talking about are idiots who think 'the world' is middle managers who will strip mine your life to get the project done a week earlier. Newsflash, older programmers aren't less capable, just less willing to be fed a shit sandwich than younger programmers.

        • 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;

        • Re:Can't offer much (Score:4, Informative)

          by sdsucks (1161899) on Saturday May 11, 2013 @07:13PM (#43698149)

          Spoken like someone who doesn't have much of a fucking clue... Seriously, son, you don't think ageism is a big problem? Let me assure you that it is - and it applies to far more occupations than programmers.

          Also, your thoughts on immigration and "underskilled Westerner" are not very developed... I have North Americans and foreigners working for me, both in North America and outside of it. Sometimes, it's about western workers being incompetent - but just as often, it's about companies simply cheaping out.

        • by Antique Geekmeister (740220) on Saturday May 11, 2013 @07:24PM (#43698245)

          Some of we older workers try to stay current. It can be awkward and expensive in productive time and energy. In fact, as an older programmer, I've often used age and treachery to defeat youth and skill in the kind of "my new tool is better than your old tool" challenge so common in the workplace. Thee are few moments as pleasant for an older engineer as when a younger engineer says they've found an exciting way to do something, and you can not only prove the old way is better, but, but you can point out your own signature on the documentation where it says why you rejected that approach.

          Fortunately, it's often easy for us to stay abreast of new software fads by tying the new technology to its ancestor and bringing that experience to bear. But if this programmer is not interested in evolving their skills to meet the project or the company's needs, then let that employee know personally. Please don't just insult them behind their backs, or ask Slashdot advice about them. Let them know, to their face, that their difficulties with code review or source control make it harder for their work to be accepted or their work to be useful. If you have to, bring it to their manager.

          And if you can, help them find a new role or a new job that is better suited to their skillsets. I've certainly worked with, and even once managed, someone whose core computer language skills were about to be phased out at our company. I let him know we'd have a problem, offered some access to retraining, and was generous with time of for him to do interviews elsewhere and with recommendations. He was quite good with the older skillsets, just not that excited about abandoning almost 20 years of experience and knowledge to start over. The last thing I heard was that he'd retired from the new role he found, and he still does related open source projects for the challenge.

      • I don't know, I found that having kids gave me far more time to keep my skills up to date. Though, after having user CVS, Subversion, Mercury, GIT and more, sometimes the issue is that having gone through so many stages of evolution, it's hard to unscramble the different tools. In my case, it often is a lack of patience with the new tools with watching the same damn mistakes being made over and over. I really like GIT, but when I was forced to work with bazaar, the tool of choice from the 22 year old tool h
    • by penix1 (722987) on Saturday May 11, 2013 @05:08PM (#43697363) Homepage

      The alternative is to offer him the training he is supposedly lacking. If he refuses then that is grounds for dismissal. This is my biggest beef with the corporate world. They want you current but do nothing to provide you the necessary tools or the time to stay current.

      • by Jimbookis (517778)
        > They want you current but do nothing to provide you the necessary tools or the time to stay current. Every single damned company I have worked for (all engineering and IT) have all insisted any new learning is to be done on your own time and expense, even if it benefits the organisation in the long run. Oh, but they still expect you to keep on top of the latest and greatest and contribute to the bottom line at all times.
        • by Musc (10581)

          Seriously? How is this even legal? If you are working for your employer, whether in an actively productive role or in training, it is part of the job and should be considered as such. Now if you are on a salary they might have the legal right to ask to work more than 40 hours a week to make this happen, but then it isn't really on your own time, they just want your workday to be longer. And what do you mean by "at your own expense"? Can't these kinds of skills be learned for free from any computer with

        • 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.
    • by wmelnick (411371)
      There is a not a single language used in the last 30 years that is not still being used somewhere. There are many businesses out there still running on RPG, COBOL and FORTRAN. If that person is good at what he knows, he will always be able to find a job. It may not be a "sexy" job to the 20-something crowd, but if he had a family, a job where his coding skills are appreciated, that only demands 9-5, is probably far more attractive to him anyway. I have seen many people throughout my career move into com
    • The answer is simple. Hire older programmers who are still at the top of the game. You will pay a bit more, and it's not fool proof, but at least you are hiring programmers who have demonstrated that they continue to remain at the top over time. Hiring younger programmers who are recently out of college and know the latest technology buzz is fairly easy. Most of them stop their learning there once they get out into the real world and have to decide their priorities.

      • If you ever reach the top of your game as a programmer before the day you retire, you're either very unlucky in some part of your life that is probably unrelated to work or you're just doing it wrong...

        Also, those younger programmers who are recently out of college probably think they know a lot of clever technologies, but mostly only because they're so inexperienced that they don't even realise how much they still have to learn yet. The kind of place where ageism is a serious problem for professional devel

    • by sycodon (149926)

      So...you want me to work a ten hour day AND learn the latest bullshit fade language after hours.

      Fuck You sonny boy.

  • Not current... (Score:5, Insightful)

    by Joce640k (829181) on Saturday May 11, 2013 @04:58PM (#43697295) Homepage

    ...cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up

    One has to wonder what sort of code he's capable of producing if he can't even do that.

  • perspective (Score:5, Insightful)

    by buddyglass (925859) on Saturday May 11, 2013 @05:02PM (#43697317)

    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.

    • Concurrent code isn't new.

      Are universities teaching communicating sequential processes to undergraduates yet?

    • Re:perspective (Score:5, Insightful)

      by mysidia (191772) on Saturday May 11, 2013 @05:06PM (#43697351)

      Concurrent code isn't new. If this guy doesn't understand it then his problem isn't that he has neglected to stay current, but that he was never very skilled to begin with.

      Maybe it's just that writing concurrent code is hard, annoying, prone to buggy results, and should be avoided, except in special circumstances where there is a great advantage.

      • Maybe it's just that writing concurrent code is hard, annoying, prone to buggy results, and should be avoided, except in special circumstances where there is a great advantage.

        MacOS X or iOS with Grand Central Dispatch, and concurrent computing is a doodle. And basically anything that does an http request is "special circumstances" where concurrent computing is a great advantage :-)

        • Re:perspective (Score:5, Insightful)

          by gweihir (88907) on Saturday May 11, 2013 @06:13PM (#43697779)

          "Concurrent code" and "multi-activity code" is not the same. In concurrent code, you actually have algorithmic interdependencies, which makes it hard. And no, there is no technology that can make it easy, because understanding what it does or is supposed to do is hard. On the other hand, multi-process/thread code and event handling code for not interdependent events is very easy with the right tools, but does not qualify as "concurrent".

      • 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.

        • by Lumpy (12016)

          Amen!

          notice how all these "ask slashdot" stories whining about an old programmer is some snot nosed punk that thinks he knows more?

          Most of these kids wouldn't last a DAY programming an embedded system where you have 10K for your entire OS and program, let alone a high pressure place like financial programming.

      • Re:perspective (Score:4, Interesting)

        by bfandreas (603438) on Saturday May 11, 2013 @07:12PM (#43698145)
        In 15 years I only had to write proper concurrent code once. At the core of an application. Spent a week mostly thinking about how to test it. I covered the whiteboard in my office with diagrams. All for about 200 lines of code which by now I would consider boilerplate code. Concurrent code is all about experience and defensive programming.

        Most code we write is concurrent by default since we do a lot of web applications. I tell my team to keep that in mind when creating mutable shared resources.

        I remember back in the day when client-side Java was considered a thing. You had to write concurrent code or you would lock up your render thread(the famous gray pane while the application did something). You could easily spot code written by a newbie. Who would then subsequently say that Java sucked for all the wrong reasons while missing the real bugbears.

        Do stuff sequentially when in doubt and know when you absolutely have to go concurrent. If it is complex and complicated it is also wrong by design. Never go full retard.
        • by mysidia (191772)

          Most code we write is concurrent by default since we do a lot of web applications.

          I can see why some people might say that web applications are concurrent, but usually they are not. The ability to open up two copies of notepad.exe does not make notepad a concurrent program, and the same goes for web applications.

          This is just the fact that concurrent independent instances can occur, as a result of an operating system with concurrent code. Normally the instances of a web application will be independent

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      If the guy's job description doesn't require "Concurrent code" then STFU and keep your petty issues to yourself, if it does then hes unable to perform the job and needs training or reassignment.

      • Re:perspective (Score:5, Insightful)

        by pla (258480) on Saturday May 11, 2013 @06:20PM (#43697819) Journal
        If the guy's job description doesn't require "Concurrent code" then STFU and keep your petty issues to yourself, if it does then hes unable to perform the job and needs training or reassignment.

        I don't often respond to ACs (and even less often positively), but you've hit the nail on the head here.

        My current job requires absolutely no explicitly concurrent programming. I do mostly SQL, which has a high degree of implicit parallelism (arguably the highest possible, if you religiously avoid RBAR); I've also played around with OpenCL just for kicks. But even such fundamentals as semaphores and IPC matter not one whit to my continued employment.

        I can appreciate the FP's problem, having worked with programmers who just don't have passion for the art anymore (and age has nothing to do with it, I've worked with a 60YO that made me look like a neophobe, and a 30YO that honestly would have liked his job better if he could do nothing but sharpen pencils all day). But most programming jobs don't require high-level cutting edge skills. Quite the opposite, I've more often found myself suffering for want of familiarity with ancient big-iron scripting languages than for the latest and greatest set of buzzwords.

        Put bluntly, most programming jobs involve getting an ancient GL database to talk to an ancient POS system; converting 20 years worth of Excel VBA scripts (or god help you if someone's nephew actually knew Access) to "real" code; Hacking together a driver that lets a $2M instrument talk to a Win7 x64 box, when the most recent driver from the (now defunct) manufacturer runs on a German version of Windows ME (and FWIW, I didn't exactly pull that example out of my ass).

        I'd love to see an actual breakdown of the numbers, but make no mistake, the number of programmers working on Real Software(tm) falls into a small minority of the total.
    • Re:perspective (Score:5, Interesting)

      by charnov (183495) on Saturday May 11, 2013 @05:15PM (#43697425) Homepage Journal

      It's not that new if you came up in the HPC world working with something like Erlang, but I didn't see it until 15 years after my first CS class when I went back to school to learn C++ (When I started, it was C that I learned and then I ended up working in Eiffel later on). I have never seen nastier harder to track down bugs than when we shifted to a concurrent model while chasing lower latencies in GUI's... I will give it to the young guys who came in after me though; they seem to live and breath this stuff. I got out of the way and became management. I drove them crazy with forcing UML and unit tests and strong code review (they wanted to move FAST), but they are all much better coders than I ever was. I can still kick their butts designing algorithms, though. Different skills for different targets. I hope the fellow grey beard in the OP realizes the change like I did and find a different role where his skills make more sense. Good luck.

      • by loufoque (1400831)

        HPC is about parallelism, not concurrency. It's a different thing, even though they're related.

        • by KGIII (973947)

          Sorry to bug you but Wikipedia (and my own thinking) indicate that the terms are interchangeable.

          http://en.wikipedia.org/wiki/Concurrent_(programming) [wikipedia.org]

          Could you take the time to explain the difference for me? If you don't have the time then don't worry about it. If you do have the time it would be greatly appreciated. Thanks in advance, either way.

          • by loufoque (1400831)

            Concurrency is when you write an application which uses multiple threads for different tasks (GUI, networking, processing, whatever) so that they run independently, and you need to synchronize them.
            Parallelism is when you write an application where you use threads to split one algorithm on several computation units so as to speed it up.

            The distinction exists and is recognized by quite a few people; last month at a meeting of the Concurrency Working Group of the C++ Standards Committee, it was used to remind

    • by bfandreas (603438)
      Writing concurrent code is not a skill set you need that often. But there are exceptions where you need at least a modicum of understanding.

      We once had used a contractor for a minor web application. nothing fancy. The guy used static variables for session values achieving something nobody had ever done before: the single-user web application. He was not on my team otherwise I would have caught him since I usually review each check-in of people I do not know. He agreed to forfeit half his pay and the other
    • by loufoque (1400831)

      People that deal with concurrency well are rarer than you think.

      In the industry I've seen people use volatile to deal with concurrency, or that only locked mutexes when writing to some data, not when reading it.

  • by ljw1004 (764174) on Saturday May 11, 2013 @05:06PM (#43697347)

    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. :)

    • by Anonymous Coward on Saturday May 11, 2013 @05:41PM (#43697589)

      I don't think multithreaded code can be written correctly. At the very least you need to say your prayers and cross your fingers.

      The most dangerous coders are those who don't have a healthy fear of concurrency. Unfortunately, those seem to be in the majority.

      Not only is concurrent code full of surprising pitfalls, but you can't abstract the problems away. You can't enclose the tough parts in some key classes and be done with them. It's like with inverting a matrix: divide and conquer doesn't work. The larger the system, the more complex the interactions to consider.

      Debugging is hell. Symptoms cannot be reproduced. Performance bottlenecks are difficult to analyze.

      • by countach74 (2484150) on Saturday May 11, 2013 @06:15PM (#43697789)
        I'm really glad i'm not the only one who thinks this.
      • by cytg.net (912690)
        +1
  • 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 eff

  • ... 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;

    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?

    • Re:Current? (Score:5, Insightful)

      by petes_PoV (912422) on Saturday May 11, 2013 @05:51PM (#43697651)
      I'm guessing what we have here is a junior programmer who's acting up because he is in the presence of senior staff, who are better paid than him, but don't have his spread of buzzwords. It's a sign of inexperience to assume that you're better, simply because you have been taught all the trendy buzzwords. I doubt that the older guys transgressions are anything really significant - maybe he cocked up a RCS entry once and maybe he doesn't know some of the stuff that the new kid does.

      However I would not be at all surprised to learn that Old Guy is more than pulling his weight where it counts: producing reliable stuff that is efficient, well documented, properly tested and on time. What New Kid fails to recognise is that in a short time, some other New Kid will be sniping at HIM for the same reason he's whining on now.

  • by istartedi (132515) on Saturday May 11, 2013 @05:15PM (#43697417) Journal

    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.

    • by sylvandb (308927)

      Duh! That seems like management 101 to me.

      How come I never have mod points when I need them? Absolutely, positively, yes. If you are the guy's manager, he needs to hear feedback from you on his skills, job performance, and future relevance. If you are not his manager, in your next 1-on-1 with your manager, you need to express your concerns with concrete examples (specific defects, specific commits causing the mess in revision control, etc).

      And now, perhaps it is your time to shine -- figure out how to become a trusted resource so the problem emp

    • by Sipper (462582)

      I think you've got the right idea.

      Performance reviews are a good feedback mechanism for both the worker and the manager. It sounds to me like this particular programmer is feeling disconnected and as such doesn't seem to be taking account of the reporcussions for the way in which he's doing his work. Likewise this is bad for morale for everybody else, because they're having to clean up the mess. Nobody wins in this scenario -- the lone programmer is unhappy and the people he works with that want to work

  • by Anonymous Coward on Saturday May 11, 2013 @05:16PM (#43697429)

    I'm 35 and in the management chain now.. No more needing to know how to do anything. It's pretty awesome.

  • 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.
  • 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.

  • Knowledge and competency are the values an employee brings to the company and in return gets paid for.

    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

  • by jc42 (318812) on Saturday May 11, 2013 @05:28PM (#43697513) Homepage Journal

    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. ;-)

    • by sylvandb (308927)

      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.

      True. However multiple processes is simply one form of concurrency where the OS handles your isolation. If you can divide into separate processes then you can also do it multi-threaded with minimal if any "interlocks needed to make it work."

      Further, multiple threads has less overhead than multiple processes (especially on one particular prominent platform) and may be preferable. Or if the problem does easily lend itself to multiple processes, that may be good enough or sometimes even better (e.g. python

  • 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
  • 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."
  • by mpthompson (457482) on Saturday May 11, 2013 @05:39PM (#43697569)

    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.

    • by msobkow (48369)

      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 fac

  • by whizbang77045 (1342005) on Saturday May 11, 2013 @05:43PM (#43697599)
    It's simple. You promote them to management.
  • 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.
  • Training classes (Score:4, Insightful)

    by Animats (122034) on Saturday May 11, 2013 @05:48PM (#43697633) Homepage

    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."

  • 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 [wikipedia.org].

    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

  • 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 A
  • 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 ne

    • by gbjbaanb (229885)

      in fact, who came up with the summary "you're old so you can't be a coder no more"-type nonsense is what I see on the web from immature kids who don't know the old and good ways of working, all they know is the new let-intellisense-do-it-for-you way of coding and think they're the greatest.

      I wonder if I should post to /. saying "what do do with young brogrammers who can't code or design properly and rely on the tools to do all the work for them?"

      ho well, anyway, another non-story for /. - in this case it so

  • Really? (Score:4, Interesting)

    by Jack9 (11421) on Saturday May 11, 2013 @06:30PM (#43697887)

    > 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.

  • by Darinbob (1142669) on Saturday May 11, 2013 @06:37PM (#43697925)

    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.

  • Why NOT Hire Them? (Score:5, Insightful)

    by CrankyFool (680025) on Saturday May 11, 2013 @06:55PM (#43698035)

    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.

  • by segfault_0 (181690) on Saturday May 11, 2013 @07:40PM (#43698385)

    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.

IF I HAD A MINE SHAFT, I don't think I would just abandon it. There's got to be a better way. -- Jack Handley, The New Mexican, 1988.

Working...