Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about a year and a half ago | from the twinkie-on-a-stick dept.

Businesses 509

skaffen42 writes "The recent Ask Slashdot about becoming a programmer later in life got me thinking about a related question. How do you deal with programmers who have not stayed current with new technologies? In the hiring process, this is easy; you simply don't hire them. However, at most companies where I've worked, there are usually a few programmers who have been employed long enough that the skill-set they were originally hired for has become irrelevant. At the same time, they have not bothered to stay current with newer technologies. They usually have enough business knowledge that they provide some value to the company, but from a technical perspective they are a slowly-increasing liability. As an example: I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up. On top of that, he is really resistant to the idea of code reviews; I suspect he dislikes people he considers junior to him making suggestions about how to improve his code. So, how do my fellow Slashdotters handle situations like this? How do you help somebody like this to improve their skill-sets? And, most importantly, how do you do so without stepping on anybody's feelings?"

Sorry! There are no comments related to the filter you selected.

Can't offer much (4, Insightful)

Anonymous Coward | about a year and a half ago | (#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.

Re:Can't offer much (5, Insightful)

Jimbookis (517778) | about a year and a half ago | (#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.

Re:Can't offer much (5, Insightful)

Anrego (830717) | about a year and a half ago | (#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:Can't offer much (1, Insightful)

Intrepid imaginaut (1970940) | about a year and a half ago | (#43697693)

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

Re:Can't offer much (2, Insightful)

Dunbal (464142) | about a year and a half ago | (#43697707)

Money is given, not taken. Unless of course you're a bank or the government.

Re:Can't offer much (0)

Intrepid imaginaut (1970940) | about a year and a half ago | (#43697759)

The entire sales and marketing industry is built around taking money. Maybe people don't think it's being taken but that's what's happening.

Re:Can't offer much (1)

Anrego (830717) | about a year and a half ago | (#43697739)

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 who has a lot of experience dealing within a particular industry, and while not knowing the absolute latest tech, has enough tech background to know whats possible is usually a good fit for that kind of role.

Re:Can't offer much (5, Insightful)

DuckDodgers (541817) | about a year and a half ago | (#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 (3, Informative)

Xest (935314) | about a year and a half ago | (#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.

Re:Can't offer much (5, Insightful)

Intrepid imaginaut (1970940) | about a year and a half ago | (#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.

Re:Can't offer much (1)

Anonymous Coward | about a year and a half ago | (#43697359)

Depends on the size of the company. I know that where I work, some of these people are considered the best in the company due to long-ago successes. Similarly, there are numerous terrible developers that get credit for some simple, immediate issue being fixed even though their fix breaks a lot of other things in hidden ways, which they see none of the fallout for because it usually appears later.

If the company is big enough, then they will eventually promote him to the other role that you described. That's what large, bureaucratic organizations do: they promote stupidity because it's easier/safer than firing (or laying off) people.

Now, I do know plenty of developers that cannot write concurrent code, but _some_ of them have other decent qualities. As long as people understand other people's boundaries, then they should be able to give appropriate tasks. Seeing as the other person is the senior developer, it may be the case that he is also assigning the tasks, which really could mean doom until he is somehow removed.

Re:Can't offer much (5, Insightful)

penix1 (722987) | about a year and a half ago | (#43697363)

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

Re:Can't offer much (2)

Jimbookis (517778) | about a year and a half ago | (#43697385)

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

Re:Can't offer much (2)

Musc (10581) | about a year and a half ago | (#43697427)

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 an Internet connection?

My company insists on paying for training (1)

raymorris (2726007) | about a year and a half ago | (#43697575)

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.

Re:My company insists on paying for training (0)

Anonymous Coward | about a year and a half ago | (#43697621)

The company I work for insists on training as a high priority, has yearly periods where everyone meets with their manager to discuss things (including what kind of training they think would benifit them), even has a specific "ongoing training form" that is manditory.

In my 6 years working there, I've only seen maybe a handful of people actually get sent on any training. I got turned down for something I was willing to pay for (it would have cost them a week of my time). It's kind of a sad joke around the company.

Re:Can't offer much (2)

wmelnick (411371) | about a year and a half ago | (#43697433)

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 companies like that and be perfectly happy when I switched over to management instead.

Re:Can't offer much (2)

KingMotley (944240) | about a year and a half ago | (#43697711)

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.

Not current... (5, Insightful)

Joce640k (829181) | about a year and a half ago | (#43697295)

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

Re:Not current... (1)

Threni (635302) | about a year and a half ago | (#43697483)

Depends - is he using a Microsoft product, such as the self corrupting VSS which comes with a tool (Analyze) which you're supposed to run regularly to clean up the mess VSS gets into, but which itself corrupts the source?

Re:Not current... (5, Insightful)

loufoque (1400831) | about a year and a half ago | (#43697557)

I've worked with a lot of people who couldn't use revision control or bug tracking systems well at all, or that cannot follow coding standards consistently.
They were good scientists, just bad engineers.

Re:Not current... (0)

Anonymous Coward | about a year and a half ago | (#43697695)

...heck, I work in a company with hundreds of IT folks that setup Subversion the wrong way! The whole concept of branches/trunk is reversed (e.g. there's no prod drop branch; prod drops are always done from top of the tree...).

So now you have hundreds of folks using subversion, and everyone just makes up execuses to go along with the broken setup. (e.g. sure you can work around everything; but it creates extra stuff to think about everytime you want to add stuff to dev thing or fix a prod issue).

You know what they do to engineers who turn 40? (-1)

Anonymous Coward | about a year and a half ago | (#43697313)

They take them out and shoot them.

perspective (4, Insightful)

buddyglass (925859) | about a year and a half ago | (#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.

Are universities teaching concurrency? (1)

tepples (727027) | about a year and a half ago | (#43697339)

Concurrent code isn't new.

Are universities teaching communicating sequential processes to undergraduates yet?

Re:Are universities teaching concurrency? (1)

Anonymous Coward | about a year and a half ago | (#43697415)

I have briefly touched upon it, but haven't had real formal education in concurrent programming. I've basically had to teach myself as I go in situations where it is necessary.

Re:Are universities teaching concurrency? (1)

Anonymous Coward | about a year and a half ago | (#43697593)

I only have anecdotal evidence, but yes. I'm at a small school with a proportionally small CS program, and we learn concurrency here. There are no dedicated classes for it, most of the theory behind concurrency is in the Operating Systems course, and they don't go into it enough to teach "best practices" moreso than basic locks and offhand advice to eliminate shared resources as much as possible.

This seems to be the case amongst my friends as well, but a few of the bigger schools do teach more about concurrency.

Re:perspective (5, Insightful)

mysidia (191772) | about a year and a half ago | (#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.

Re:perspective (1)

gnasher719 (869701) | about a year and a half ago | (#43697521)

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 (1)

Anonymous Coward | about a year and a half ago | (#43697741)

MacOS X or iOS with Grand Central Dispatch, and concurrent computing is a doodle

Yes, that's why StackOverflow is filled with questions about how to use those...

Re:perspective (2, Insightful)

Anonymous Coward | about a year and a half ago | (#43697381)

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 (4, Interesting)

charnov (183495) | about a year and a half ago | (#43697425)

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.

Re:perspective (1)

loufoque (1400831) | about a year and a half ago | (#43697605)

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

Re:perspective (2)

bfandreas (603438) | about a year and a half ago | (#43697493)

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 team leader cleaned up his mess.

Concurrency isn't tied to a particular technology. Nor is version control something super fancy. The guy in the blurb doesn't seem to have a technological problem. He simply is scared and needs serious calming down so he understands that admitting he needs to improve in some areas doesn't automatically mean his immediate termination. It all comes down to if he has a sane manager. Nearly everybody can be salvaged. And nearly everybody should. As we all know the hiring process wil be a PITA. And it takes a long time until you can actually use a new guy. That's why when in doubt I will stick with my people.

This guy has a serious case of what Micheal Lopp calls "The Fez". It is a management failing and should be dealt with at that level. His termination would be the ultimate management defeat. YOU DO NOT FIRE YOUR MOST EXPERIENCED PEOPLE!

Re:perspective (1)

cherry-blossom (1863326) | about a year and a half ago | (#43697753)

I agree with the part about being scared. There may be a management issue where he doesn't feel comfortable about being honest about his own skill set. I just went through a manager change. I couldn't have an honest conversation with my old sup without being punished in some way. It got to the point where I just didn't tell him anything. Especially when it came to admitting and fixing my own short comings.
With my new supervisor its a night and day difference. Evaluate, identify, and fix. No punishment and no problems at all with giving and receiving honest feedback.

Re:perspective (0)

Anonymous Coward | about a year and a half ago | (#43697531)

Concurrency wasn't really important in old applications, except for systems development and stuff. He could be a great business programmer with zero knowledge of concurrency.

Re:perspective (1)

loufoque (1400831) | about a year and a half ago | (#43697585)

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.

Refactor or Rewrite (0)

Anonymous Coward | about a year and a half ago | (#43697329)

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.

I'm the senior (1)

X10 (186866) | about a year and a half ago | (#43697345)

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.

Re:I'm the senior (0)

Anonymous Coward | about a year and a half ago | (#43697629)

I'm probably older than you. I agree.

Can't write concurrent code? (5, Insightful)

ljw1004 (764174) | about a year and a half ago | (#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. :)

Re:Can't write concurrent code? (5, Insightful)

Anonymous Coward | about a year and a half ago | (#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.

How do you deal with dentists who haven't? (0)

roman_mir (125474) | about a year and a half ago | (#43697355)

So how do you deal with anybody who haven't stayed 'current'? What do you mean by 'dealing'? What do you need 'current' for and what degrees of 'current' are we talking about?

How about hiring people for the job when you need the job done and if you don't need a person, then let him go. Doesn't that answer any and all questions?

Evaluations, training programs, and if needed... (1)

tnk1 (899206) | about a year and a half ago | (#43697361)

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.

make him keep up (1)

Musc (10581) | about a year and a half ago | (#43697367)

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?

Re:make him keep up (0)

Anonymous Coward | about a year and a half ago | (#43697767)

"Keeping up" seems to be one of those things that expected of people to do outside of working hours. For a constructive dismissal, evidence would probably need to be given that the employee was given opportunity to improve his skills, which means his company actually has to pay for training/give him the time off to do it, which seems to be a dying trend.

Whereas I'm at the other end (1)

Anonymous Coward | about a year and a half ago | (#43697371)

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.

I have to agree.. (1)

Junta (36770) | about a year and a half ago | (#43697543)

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.

Midlife (0)

Anonymous Coward | about a year and a half ago | (#43697395)

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

fix it. (0)

Anonymous Coward | about a year and a half ago | (#43697397)

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.

Current? (2)

charlieo88 (658362) | about a year and a half ago | (#43697399)

... 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? (5, Insightful)

petes_PoV (912422) | about a year and a half ago | (#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.

Possible reasons (1)

Cesare Ferrari (667973) | about a year and a half ago | (#43697407)

Maybe he doesn't like concurrent code because he's been bitten by nasty bugs enough times to shy away from it. Maybe he doesn't like your source control system as he has lost heaps of work in the past trusting it to a dodgy system. Maybe he has found code reviews a waste of time, or had bad experiences with pitched battles in a meeting room. Why don't you try asking him rather than speculating? 'Hey bob, it looks to me like you aren't keen on code reviews - why is that?' would be a good start.

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.

what's (0)

Anonymous Coward | about a year and a half ago | (#43697409)

concurrent code?

you nuke them (0)

Anonymous Coward | about a year and a half ago | (#43697411)

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

Its easy! (1)

MacOSXHead (201757) | about a year and a half ago | (#43697413)

Make him or her a Scrum Master! He will never touch code again!

This is what performance reviews are for (5, Insightful)

istartedi (132515) | about a year and a half ago | (#43697417)

You know, the manager takes everybody aside quaterly, or perhaps semi-annually and privately discusses strengths and weaknesses. If it's urgent there's a "see-me" meeting; but this is a slow leak, so it should be coming up in the guy's PRs. If it isn't, or there is no PR at all, management shares the blame. After having this mentioned in 2 or 3 PRs, and getting no bonuses or raises, it's shape up or ship out. Duh! That seems like management 101 to me.

Re:This is what performance reviews are for (2)

sylvandb (308927) | about a year and a half ago | (#43697579)

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 employee will value your assistance and feedback. Then help, not by doing his work, but by being willing and able to teach when the opportunity presents. Not just the "how to do" but the "why it is better for you if you do" until the "how do I" question comes.

Re:This is what performance reviews are for (1)

Sipper (462582) | about a year and a half ago | (#43697697)

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 collaboratively are unhappy.

So the recommendation I have is to at least try to have a conversation with the programmer about these things and try to help him reconnect with his fellow employees. This is not a "blame session", it's an attempt to get the team reconnected so that they can work as a team. It sounds like the programmer isn't able to say "I don't understand this" and as such can't learn from his fellow employees because of perceived judgment or a sense of insecurity. This is common, and can lead to all kinds of bullying behavior -- but it's the underlying disconnection that's the biggest part of the problem, IMHO.

Hopefully this works. If not, hopefully the effort wil bring to light what needs to be done.

Promote to management (4, Funny)

Anonymous Coward | about a year and a half ago | (#43697429)

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

leave (0)

Anonymous Coward | about a year and a half ago | (#43697431)

if your company is keeping old farts with no motivation to excel, you obviously have no business there (assuming you are pursuing success)

Investment in Employees (1)

loxfinger (571135) | about a year and a half ago | (#43697449)

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.

Create a new process for programming (1)

Murdoch5 (1563847) | about a year and a half ago | (#43697451)

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.

Fire them, it's quite simple. (0)

Anonymous Coward | about a year and a half ago | (#43697457)

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.

its not a matter of feelings (1)

ILongForDarkness (1134931) | about a year and a half ago | (#43697459)

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.

Meh (1)

Anonymous Coward | about a year and a half ago | (#43697461)

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

Re: Meh (0)

Anonymous Coward | about a year and a half ago | (#43697699)

What he/she said!

Knowledge and competency (1)

Teun (17872) | about a year and a half ago | (#43697463)

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

easy (0)

Anonymous Coward | about a year and a half ago | (#43697487)

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 )

Wait a minute... (0)

Anonymous Coward | about a year and a half ago | (#43697511)

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'm also somewhat resistant to code reviews (4, Insightful)

jc42 (318812) | about a year and a half ago | (#43697513)

I've often found that this describes me, because in the many code reviews I've sat through, I've yet to hear any point that I hadn't already thought of myself, and could provide the appropriate test code (if they'd accept it). So, in my experience, all code reviews have been a total waste of my time, and there was never any way to get past the trivial "newbie" stuff to the things that I thought were outstanding questions that needed answering.

And, unlike many developers, I've often found myself on very good terms with the QA people, because when I give them my stuff, I include a pile of test routines that they are welcome to use as they wish (thus saving them a lot of time).

So I consider at least one of the points here somewhat dubious. Yea, code reviews sound like a good idea. But if they don't produce any new questions that the developers haven't already dealt with, they're a big waste of everyone's time.

I wonder how many readers have similar reactions to the other points in the summary? For instance, concurrent code can be fun to develop, but in practice, all the interlocks required to make it work can reduce many tasks to near-serial performance. Sometimes, though, a better approach is to look for ways to split the task into subtasks that can run in separate processes that rarely interact. I've done this on occasion to produce huge increases in speed. Of course, this isn't really a question of programming, but rather a question of reanalyzing the task and finding a way to handle it with minimal coupling of a set of independent subtasks. But doing this could easily be interpreted as not understanding how to write concurrent code, rather than understanding when concurrency is an advantage and when it's not. ;-)

Re:I'm also somewhat resistant to code reviews (1)

Anonymous Coward | about a year and a half ago | (#43697617)

Code reviews aren't just about finding bugs in your code. They're also about teaching other people.

Re:I'm also somewhat resistant to code reviews (1)

sylvandb (308927) | about a year and a half ago | (#43697631)

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 with the GIL).

So the problem really could be the guy has a problem with concurrent code of any variety.

uh (1)

bahaa elaila (2920349) | about a year and a half ago | (#43697523)

kill and re-spawn.. no hard feelings

How about train him? (2)

Joreallean (969424) | about a year and a half ago | (#43697529)

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.

Re:How about train him? (0)

Anonymous Coward | about a year and a half ago | (#43697619)

"Its not hard to keep a job once you have it."

I've had 37 jobs in the last 7 years. I want to know what makes you say something like that.

Re:How about train him? (0)

Anonymous Coward | about a year and a half ago | (#43697747)

>> Its not hard to keep a job once you have it.

I haven't managed to keep a job for more than 2 years in the 12 years I've worked professionally. Admittedly, these were almost all government contractor positions; but I worked with some people who still, 12 years later, managed to keep to the same government contracting company. I have a slew of ex-coworkers perfectly happy to give me an excellent reference because they thought I did an excellent job. Yet I still haven't managed more than 2 years, and a number of them even less than that. I don't know if it's because I'm always the low man on the totem pole in terms of seniority or what, but when funding is cut I'm always in the group out the door. Heck, I was even dumped about 6 weeks after finally getting my top secret clearance, which is an arduous process lasting over a year and costing the company thousands of dollars.

If they refuse to adapt... (-1)

Anonymous Coward | about a year and a half ago | (#43697535)

Fire their worthless fucking asses.

Cry me a fucking river about people who are younger, have more skills, are more intelligent, and are willing to work for less money. If you can't do what they can do, why the fucking hell are you still employed?

Same as a young guy who doesn't have skills (1)

phantomfive (622387) | about a year and a half ago | (#43697541)

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

Switch to a bazaar model (0)

Anonymous Coward | about a year and a half ago | (#43697549)

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.

Fire them. (0)

Anonymous Coward | about a year and a half ago | (#43697547)

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.

Lol slshdot (0)

Anonymous Coward | about a year and a half ago | (#43697561)

http://qubemod.com/ [qubemod.com]

For starters, you can get off your high horse... (5, Insightful)

mpthompson (457482) | about a year and a half ago | (#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.

Re:For starters, you can get off your high horse.. (2)

msobkow (48369) | about a year and a half ago | (#43697733)

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

Older employee HowTo (1)

Sla$hPot (1189603) | about a year and a half ago | (#43697583)

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

There's a time honored solution .... (3, Funny)

whizbang77045 (1342005) | about a year and a half ago | (#43697599)

It's simple. You promote them to management.

put them on side-track assigments (1)

4wdloop (1031398) | about a year and a half ago | (#43697603)

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.

You don't. (0)

Anonymous Coward | about a year and a half ago | (#43697607)

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.

"Stay current" and "no source control"? (1)

gnasher719 (869701) | about a year and a half ago | (#43697615)

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 (3, Insightful)

Animats (122034) | about a year and a half ago | (#43697633)

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?

Teamwork and targets (1)

Fuzzums (250400) | about a year and a half ago | (#43697639)

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

Not current (2)

ozduo (2043408) | about a year and a half ago | (#43697671)

Raisin with them!

Ask Slashdot (1)

R3d M3rcury (871886) | about a year and a half ago | (#43697673)

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

Shut up and suck it (0)

Anonymous Coward | about a year and a half ago | (#43697675)

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.

offer them training (0)

Anonymous Coward | about a year and a half ago | (#43697681)

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.

Ol' timer's advice (1)

R3d Jack (1107235) | about a year and a half ago | (#43697685)

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.

Terminology differences? (1)

Fencepost (107992) | about a year and a half ago | (#43697713)

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.

Immature know-it-all who needs more experience? (1)

Malc (1751) | about a year and a half ago | (#43697731)

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.

You have 2 options... (1)

Hauke (170754) | about a year and a half ago | (#43697735)

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

Age has nothin' to do with it (1)

bio_end_io_t (2771123) | about a year and a half ago | (#43697765)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?