elanning

That was a fun read. Especially the funny bit at the end. Did you consider making this a progressive web app?

Imagine you're a senior developer with over 10 years experience. You're happily employed and make good money. You're contacted by a recruiter for an interview. Perhaps the company even uses some software you wrote.

"Ok this problem is called fizzbuzz. We just need to see if you can really code."

It sounds like the situation was of course different, but situations like above have happened.

A lot of senior engineers would refuse to do a fizzbuzz. I'm really not seeing the problem here.

I believe most programmers know a lot of this stuff, they're simply not trying to build a system that captures reality perfectly. They know Prince's name was a symbol at one point, but force Prince to confirm to their system with a nickname or some other workaround, and that feels OK to me.

I think it does its job perfectly; gives them candidates who are willing to put up with 10 hour study sessions for weeks OR people who are naturally brilliant (and don't break under pressure while being watched). It filters out a lot of insanely good candidates by doing so, but who cares when you have 100,000+ job applications?

Couldn't agree more. If you care enough to nit, you should care enough to add an linter rule for it. I do realize sometimes that's simply not possible, but a lot of times, it is.

I even wrote a custom vscode plugin to encourage devs to do just that: https://marketplace.visualstudio.com/items?itemName=checkr.c...

Now it only takes me 10-30 minutes to whip up a new lint check.

Sorry to hear. I hope you find something that works for you. I wish I could help, but like me, I'm sure you've already researched most solutions.

I have suffered from fairly bad RSI/tendonitis issues since my early 20s. Now a days I have a split keyboard and use wasd keys for my mouse, which is slower, but causes less pain. I would not wish this kind of pain on anyone. It has greatly negatively impacted my life. Hopefully future treatments will give some help, the current treatments are very lackluster.

https://marketplace.visualstudio.com/items?itemName=checkr.c... - Checkr: write simple code checks with regex for vscode.

I strongly believe big libraries will come with their own easy to plugin static analysis rules as the norm (a lot already do). I also believe writing static analysis rules needs to be easier. And that devs will write their own static analysis rules more regularly in the future. I wrote checkr as a small rope bridge towards this. Clearly we need something better than simple regex, yet less daunting than abstract syntax trees. But regex gets us a lot of the way there.

Related to the article: I noticed a lot of style like nits that ESLint didn't cover, but also weren't necessarily worth pausing and writing an entire ESLint rule for.

So I wrote checkr: https://github.com/ELanning/checkr which lets people plugin simple ad-hoc regex check lints (and underlines them in VS Code + git pre-commit check).

Hopefully to help break the endless cycle of code review nits that may be specific to your project.

Will do, that's on the TODO list.

During code review, I noticed many nits could be caught by static analysis. I also noticed many bugs I've run into could also be caught by static analysis. I looked into writing custom ESLint rules, but often they required more ceremony and boilerplate than I had time for.

A friend who worked on a mobile project at Google said he had written dozens of regex checks to ensure code quality and catch various bugs. I was incredulous and asked why he wouldn't use a more "proper" AST static analyzer. The fact was, he had bigger fish to fry and sometimes a simple regex check is all you need. I tried writing some regex checks like this, and found it to be quick, yet yielding good returns.

Thus I wrote checkr, a VS Code extension that allows devs to plugin simple regex checks right away.