Fortunately, I've been able to get employers to pay for my special chairs and keyboards. But even if work wouldn't pay for these, one thing I can say for certain is that a lifetime of lost income is a lot more expensive than BodyBilt chairs and Kineses Advantage keyboards. Though if you can find solutions that work for you that are cheaper, then I can see the advantage in that.

I just tried doing what you suggested. It hurts my fingers like hell.

I think I'll stick to my linear tracking arms. They've worked for me for decades now.

No. But I've been using these linear tracking arms for like 25 years now. Maybe it took a little while to get used to them, but if it did, I don't remember. My recollection is that it was just an instant win.

I imagine that I use a combination of both. The important thing is to eliminate (or greatly reduce) any usage of one's wrists.

I did!

I'm glad that you found something that has worked for you. Personally, I recommend to everyone I know that they get a Kinesis Contour Keyboard (now called "Advantage" rather than "Contour"):

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fkinesis-ergo.com%2Fshop%2F...

This is not just a small change to the keyboard: it's a complete rethinking of how a keyboard should be designed. It's different from a normal keyboard in a myriad of large and small ways that all act synergistically to hugely decrease RSI issues. Without this keyboard, I am quite sure that I would have had to have given up being a software engineer.

Everyone I know that has switched to one originally hates it due to a steep learning curve, but then eventually they can't live without one and they always ultimately end up thanking me profusely for saving their hands.

My experience is different from what you describe. The linear tracking arms have been a godsend to me!

I've have two BodyBilt chairs with linear tracking arms, both of which I used every day for more than a decade. (I've been using BodyBilt chairs for a long time now!) Eventually the cups that hold your wrists wear out, but you can buy replacements for those. As for the arms themselves, I haven't seen any significant wear on them, or loss of function, in a decade of use. This is good, since the linear tracking arms just by themselves costs more than many premium office chairs!

Other things on the chairs eventually start to go. E.g., the inflatable lumbar supports break after some number of years. You can buy individual chair parts for BodyBilt chairs. You don't have to replace the whole chair when something eventually breaks.

I forgot to mention that BodyBilt chairs are very adjustable. A chair that you can adjust to your particular body is a huge benefit. A chair that forces your body to conform to it, is going to hurt you in the long run.

I've suffered with carpal tunnel syndrome and back problems for more than 25 years now. I credit being able to continue to work without further degradation to two things:

(1) A Kinesis Contour keyboard.

(2) A BodyBilt chair with "linear tracking arms".

BodyBilt chairs are not cheap! But they're worth every penny ten times over. Here is a video of the linear tracking arms in use:

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3F...

BodyBilt chairs can be ordered with a zillion different options and configurations, so if you go this route, be sure to check out all the different options they offer. But for me, the linear tracking arms have been invaluable.

Instance dungeons in Destiny 2? After thousands of hours of playing have I missed something?

Do you mean Lost Sectors? Or the Infinite Forest? I suppose they could be considered "instance dungeons". I agree that Lost Sectors and the Infinite Forest are not terribly exciting. But they are also fortuntely not particularly central to the Destiny 2 gameplay experience.

They're offering an entire Windows remote desktop, not just Flash and Office. I guess it remains to be seen as to whether there's a big enough market for this, but you really don't know the answer to this.

|>ouglas

Who cares about "supposed to"? I'm talking the actual reality of the matter.

It's true though that if too many people started doing this, they might stop allowing it. I doubt that this is much of a risk, however. You'd have to live near the campus and have enough free time during the day to do this, so there are not going to be teaming masses.

|>ouglas

Most professors I've met seem perfectly happy to actually have someone in the class who really wants to be there. They'd probably change their minds about this if there started to be crowds of people doing this, or if the people doing this asked a lot of stupid questions, though.

|>ouglas

I've worked at a few top-tier universities, and they've always allowed people to sit in for free on nearly any class they might want to. It's not an official policy, but I've yet to see a professor turn down anyone who asks. Or in a large class, they'd never notice that you're there anyway.

|>ouglas

In other words, you want to hire people who can give you a passable solution in 20 minutes rather than someone who can give you a smartly architected solution tomorrow? No wonder most companies develop crap built on top of crap software, where large projects usually fail. Everything is built out of chewing gum and bailing wax. Companies are selecting for precisely the wrong skills in a field where robust engineering actually is the only sustainable solution to the problems we face in developing and maintaining large programs.

There are many more effective ways not to hire morons. I presented one in my previous message. Very simple O(n) questions will also filter out morons, since I can tell you from reviewing much submitted code, that the typical "moron" programmer has absolutely no clue as to the difference between, for instance, O(n) and O(n**2).

|>ouglas

Your worry is one of those moot worries that people have while sitting in their armchair. In my real world experience, it is not a problem. Where I work, we send the specs for a small program along with some unit tests to an applicant, and give the applicant however long they'd like to complete it. We can tell that most people do not cheat because their solutions typically completely suck. Or if they were cheating, they didn't know how to cheat effectively. The solutions usually all suck in different unique ways too. A few applications submit passable solutions, and so we have them come in, and as part of the interview, we'll have them go over their code a bit and explain why they made certain design decisions, etc.

This process gives us a much better idea of how someone would perform at the real positions we have than any amount of coding on a whiteboard ever could. It's also proven to be effective. We haven't hired any clunkers.

|>ouglas

This is such complete and under nonsense that it always amazes me that it has become the current orthodoxy. And a completely counterproductive orthodoxy at that.

Let me ask you a question: If this was the best way to evaluate whether someone can think critically, then why don't our finest engineering universities (e.g., MIT and Stanford) grade students by having them do all their exams at a whiteboard, while the professor or TA impatiently taps their pen on a desk while waiting for the answer? We should just get rid of problems sets and papers and projects and programming assignments and exams because none of these other things demonstrate, at least if one is to believe the orthodoxy, that someone can think critically or communicate effectively unless they can do so in real time in front of a whiteboard on a problem that they've never seen before.

What unremitting nonsense!

The actual fact of the matter is some of the world's greatest thinkers do their best thinking in the shower or while they're asleep or while cutting their toenails, and if you don't allow people the time and the space to think the way that they think best, you know absolutely NOTHING about them, other than that they're not so great at solving new problems while standing up in front of people in a certain particularly stressful situation. For all you know, Einstein would have failed your interview. And then companies bemoan the fact that there's not enough talent. Bah! They scared 3/4 of the talent away.

|>ouglas

P.S. Yeah, sure Phd qualifying exams are done orally. This no doubt stems from the fact that a PhD is academic training, so if you can't think fast on your toes in front of a classroom, then maybe academia is not where you should be. The current trend in requiring whiteboarding during a job interview is the revenge of the PhDs. Apparently enough of them left academia and got into the real world so that now they think that everyone should have to suffer what they had to.

P.P.S. Where I work now, the interviewing process is much more civilized. We send the specs for a small program along with some unit tests, and give the applicant however long they'd like to complete it. It should take a page or two of code and a couple of hours to complete at most. One might worry that people would cheat, but that hasn't been my experience. Most applicants never submit a solution at all. I suspect this is because they couldn't get their solution to pass the unit tests. (What we ask them to do, is not difficult. Anyone who passed a college course in software engineering with a grade better than a C should have absolutely no problem completing the assignment.)

So, then some fraction of applicants actually complete the assignment. These submissions show that the vast majority of so-called software engineers -- or at least those who are looking for jobs -- can't code their way out of a paper bag. I.e., most of the submissions are grossly inefficient and hugely over-engineered or under-engineered. Finally, a few of the submissions are passable (rarely do we get a truly excellent solution, which is kind of sad), so we have them come in, and as part of the interview, we'll have them go over their code a bit and explain why they made certain design decisions, etc.

If you ask me, this process gives us a much better idea of how someone would perform in the real world of being a software engineer than any amount of coding on a whiteboard ever could.