This is definitely a very useful heuristic and one I follow. I might put "Is it supported?" in the first questions group though, especially if the project is for work and you need to be able to get support/troubleshooting questions answered quickly, as opposed to a "just for fun" side project where deadlines are less prevalent.

"Keeping the heuristic as simple and concise as possible" -> this is really the crux of it. In this post I listed out pre-researched modules and use cases for them, but still basically a heuristic nonetheless.

I've found being able to migrate from coffee shop to coffee shop is very effective in helping me get unstuck from problems. Not sure if it's the 15 minute break that comes with traveling to another shop or if it's the change of scenery and atmosphere, but it really does the trick.

I do the same and it really helps my productivity. I have no clue why it actually works, but I've been using the strategy successfully for a few years now. I always suggest the idea to a coworker if they're stuck on a problem or find themselves unmotivated.

Nice, have you been working remotely the last few years?

Yes, I work remotely a few days a week.

For pair programming you might try using Screenhero. Or screenshare using Skype or whatever IM tool you use (lag can be an issue if you have a slow network connection)

I'd rather just not interview at companies that have these kinds of interviews and save myself the hassle.

Are you a remote worker yourself? It's probably going to be hard to understand the problems if you haven't experienced them yourself.

These are good ones. Also: Meetups, going to coffee shops, and joining online remote worker communities/Slack channels (although this is just online, not in person). I wfh and go to coffee shops like twice a day.

Agreed - I've often thought that having to learn these new frameworks will ultimately lead to terminal juniority. I get that each framework does things differently, and you can learn new patterns from each one, but ultimately you're just re-learning the wheel. Not advancing your skillset.

Good point. Wonder how much more frequently we're going to start seeing issues like this.

Many people do not understand UX and its role, but in my experience UX teams do not really understand how to operate within organizations and adapt to processes either.

How do you integrate UX in the agile process? People think that UX is UI. Unless you work one or two sprints ahead, it's challenging to integrate design thinking or the users in the process.

Processes are a shared responsibility. It's not on a given team to adapt to existing processes, but it's on both teams to adjust the process to incorporate all the concerns.

Any IT/Software job where human contact is minimal is on the chopping block, ripe for automation... I think interacting with people is unavoidable.