On more than one occasion, while struggling with some squirrelly SCSS I went a-lookin’ for a SASS REPL, and I came up empty. So I decided to write my own.
Here’s the thing though: a SASS REPL is an obvious thing. It’s something anyone who uses SASS (or SCSS. I use SASS to mean both.) would need at some point. Of course there’d be one online somewhere. I was bemused and befuddled as to why I couldn’t find such a beast online.
SPOILER ALERT: It does exist. And you can find it at https://sass.js.org/. Except for some unfathomable reason, the creators of that site decided to call it a Sass Playground, instead.
So I’m hoping this post, the very one you’re reading right now, will help shepherd those lost souls to the inappropriately-named Sass Playground.
In the meantime, I’ve started looking into developing my own SASS REPL, and I’ve learned more about how to convert SASS to CSS than I ever thought I’d want to.
So, why exactly am I spending a bunch of my idle hours – hours I’ll never get back – on this project? Well, a bunch of reasons, really.
- The world needs a SASS REPL. (Yes, we’ve already established the world has a SASS REPL; but it doesn’t have my SASS REPL.)
- Anytime you engage in a project, no matter the scope or breadth, you’re inevitably going to learn a thing or two. In this case, as I’ve already noted, I’ve already started learning about converting SASS. Plus I’m planning on throwing in a Material Design module in there.
- I’ll make it open source. That’ll help get my name out there. Good for business, as well as good for the front-end eco-system.
- I’ll be able to point prospective employers to this code-base if they want to see what my work looks like.
This last point is probably the most important. There’s been a disturbing trend in the last few years; companies looking to hire developers ask them to develop a sample project. They call them technical assessments, or take home projects, or tests. They say it should only take a couple of hours.
But it doesn’t. It takes many hours; often many days. Without pay. And you sweat over every detail, and second guess every decision. It’s agony.
And in the end, they may not even look at your code, or run your project. Much less grant you an interview, never mind the job.
This has happened to me many times. And I know it’s happened to colleagues of mine as well.
So, no: I am not going to spend any more time working on other peoples’ projects, unless I’m being paid to do it. In fact, one of my first questions to prospective employers is now “What is your interview process?”
If the answer includes some sort of take home test, then it’s a hard pass.
However, I do see the need to show some code. Which is why I’ve decided to take some time off from my favourite project, and develop a couple of other projects I’d been thinking about for some time. This is the first.
In the meantime, I encourage other developers to decline take home projects.
#noTechAssessments