Grammarly, why no trial?

I’ve been a Grammarly user for a few months now and it’s been immensely helpful. I don’t think I made another typo since I start using it. It’s the best spellchecker on the market.

It also has a premium version which promises tasty features like advanced checks for grammar, context and sentence structure, vocabulary enhancement suggestions, genre-specific writing style checks, and even a plagiarism detector.

All great things worth paying for. But something doesn’t feel right when looking at their pricing table. There’s too much of a difference between the monthly and the annual plan.

Grammarly premium pricing plans

I get the idea of enticing people to buy the yearly plan by offering a great deal, but pricing the monthly plan so high makes it look suspicious. Like you really don’t want people to go and try it for 30 days.

A premium trial of even one day, or one document, would go a long way in helping people decide if they want to upgrade or not.

One trick to make your web application feel smoother

It’s 2018 and we all want things to work, or at least, feel smoother.

Sometimes slowing some things down helps us improve the overall user experience of our applications.

One example of things we can slow down to make the app feel smoother is the loading/working state of buttons.

Whenever we click on something we expect some kind of feedback, but sometimes that action can be so fast that the working state, our feedback, will go unnoticed – leaving us guessing if our action was processed or not.

What we could do is to throttle the promise. Make it so it takes at least n milliseconds to resolve, giving us enough time to notice the loading state.

// Creates a new promise that automatically resolves after some timeout:
Promise.delay = function (time) {
    return new Promise((resolve, reject) => {
        setTimeout(resolve, time)

// Throttle this promise to resolve no faster than the specified time:
Promise.prototype.takeAtLeast = function (time) {
    return new Promise((resolve, reject) => {
        Promise.all([this, Promise.delay(time)]).then(([result]) => {
        }, reject)

// Make sure this doesn't resolve for at least 300ms, useful for things like
// keeping a loading spinner on screen just long enough to not look janky:'/published-products', payload)
    .then(response => {
        this.loading = false
        // ...
    .catch(response => {
        this.loading = false
        // ...

via @adamwathan

Dust off your inner designer with tailwindcss

Designing UIs is hard, especially if you’re a backend developer. When bootstrap came along everybody was cheering. And so did I.

No more wasted hours on fiddling out the interface. Look up the documentation, copy&paste the examples and adjust to your needs. It simplified everything for the non-designers.

But it also crippled our already modest design skills. It made us lazy.

Before bootstrap, we were at least trying to make things look nice. Now we’re just changing a few variables here and there pretending it’s different. Only it’s not.

Because bootstrap is a component-based framework, everything that comes out of it looks and feels the same. Forms, buttons, alert screens, proportions, modals, everything.

Tailwind doesn’t have pre-built components. You have to unleash your inner designer everytime you want to build something new.

Prototyping with tailwind is slow. Painfully slow in the first days. You have to always have the documentation by your side to look stuff up. There are so many utility classes! But fear not.

Once those few days have passed, everything gets easier. I would even argue that tailwind has a shorter learning curve than bootstrap. Because you type in every class on your own, rather than copying&pasting full blocks of code from one place to another. All those tiny utility classes get ingrained in your memory real quick.

About the clones you end up with by using bootstrap, yes, you might say that it comes down to laziness and lack of creativity. That you can choose to use as much or as little from the framework.

And I agree.

But I, for one, do not mind being pushed towards becoming more creative. By not having a full blow set of components, tailwind does just that.

Frontend vs Backend. What goes first?

It doesn’t matter if you’re building a mobile, desktop, or a web app – nowadays pretty much everyone breaks their applications into a frontend that uses the latest, hottest javascript framework and a backend responsible for answering ajax requests.

Arguments on what should go first, the frontend or the backend, are always there.

In my experience, doing either one first will only lead to conflicts and feelings of resentment between the two camps. Front devs will be annoyed because “the APIs are always changing” and the backend guys will be like “why can’t you understand that we had to change x thing?”.

In the software industry, everything is a subject of change. Trying to agree on the API structure and creating dummy JSON files to substitute for the real thing while the backend devs figure out their stuff isn’t a solution.

Even more so, agreeing on such a contract will harm the project in the long term. Each part will try (and fail) to hold on to their part of the deal rather than reaching out to the best solution and approach for the problem at hand.

Next time, keep the team as small as possible (2-3 people), break the application into medium sized components, and start working “as one”. Agreeing on a pre-defined structure never worked in my case. We made great progress when we focused on the same component at once – with the front dev leading the way.

A book for your ssh connections

Tired of spending time searching ssh connection details through your projects and wikis?

Search no more.

sshls is a small command line app acting as an address book for your ssh accounts.

Once installed, you can start adding records and list them in your terminal.

Business now, details later

Three minutes into a meeting discussing a new feature and we already have a list with tables, columns, flags, objects and methods in our head. It’s involuntary. Whenever we talk about a new feature we jump into programmer mode as soon as we get the chance. We need a model for this, a controller for that, and then we render this component and sync with that API.

Going into too much detail when discussing features makes us lose focus. Programming and figuring out how things should work are hard enough on their own. There’s no need to mix them together.

It’s not only harder for us to reason about the system we’re building. It also creates some kind of lock-in. Decisions taken during that meeting are harder to reverse – because multiple persons gave their OK on them. Because “we discussed and decided that this is how we’re going to do things”.

We act like those initial thoughts are set in stone. Instead of going back to the drawing board and come up with a better idea, we build around or on top of whatever we initially agreed, making an even bigger mess.

Refrain from including implementation details whenever you’re trying to figure out how a new feature should work. Get your business rules spot on. Then figure out the implementation.

The programmer’s gut feeling

Whenever you feel like an object isn’t really what the name says it is, or that it shouldn’t exist, or that it should exist but in a different shape, you are most likely right.

Stop and reconsider. Maybe what you find is that you don’t need that object. Or maybe what you’re trying to accomplish needs two, or more objects, or one that already exists.

That gut feeling telling you something isn’t what it should be is always right.

Naming things is hard…

Coming up with clear, expressive and precise names can be challenging and sometimes even infuriating. Why can’t I name this damn thing!? 

In search for a proper name, we grab our best friend, the thesaurus, and start digging, jumping from one result to another. And we do that until we find the best word for the thing we’re trying to name.

But finding good names takes time, so I made something the other day that will make you faster. It’s an app for the other programmer’s best friend, the command line. It’s called sini and you can find it here.

About those “would be nice if…”s

New project. We have our meetings, we come up with a plan, we somehow agree to a budget and then we get the ball rolling, coding our way to the finish line.

As we build stuff, fresh requirements are sent in. “We need this new feature”, “we haven’t thought of that”, “it would be nice if…”, etc. And it’s ok. We saw this coming.

Displaying that list on two columns, making those elements editable, changing that color, size, font, whatever — they seem to have such a low value that are often neglected. But they pile up and affect the system in ways you wouldn’t expect, burning an even bigger chunk from the budget.

We are bad estimators. But that’s not the worst part. The worst part is that we rarely, if ever, say no to a client.  One reason, apart from the customer is always right and make the client happy, is that saying no would make us feel incapable. Unworthy of our profession. We take saying no as something to be embarrassed of.

It’s not. Saying no leaves fewer things to focus on, making you more productive. It’s far easier to stay focused when you don’t have to worry about the “would be nice if”s.

The devil is in the details. Control the scope.
Focus on what is essential now and worry about the rest later.

Work at the smallest scale possible

You know that feeling when you found an elegant solution to a problem you’ve been having? When you discover that pattern you’ve been missing and you’re like “yeah! now I get it!”.

The excitement gets the worst of us and we start acting like the thing we found is the holy grail of programming. Like yes, this looks way better! If I apply this here, there, and there, all my problems go away. But problems rarely go away forever.

A few days go by and we’re like “wait a minute…this solves my problem but complicates this other thing I’m working on. Fuck..”.

We fiddle around with it for a few hours, sometimes days, and then we either find a way to patch things up or we hit the undo button and start from scratch.

The thing you found has its use case, but sprinkling it all over the project is a mistake you’ll end up regretting.

© 2019 cdruc

Theme by Anders NorénUp ↑