Following the "great success" of my blog post REST: The Good Parts – it had over four hits last month – I decided to sit down and write an article about its most popular alternative – GraphQL. I ain't going for yet another tutorial on GraphQL. I am going to make you think before you jump. I want you to take a walk with me and see through my joys and miseries using that new technology.

What is REST? That is one of my favorite questions when conducting a technical interview. You can learn so much about one's practical experience with web services and applications by simply chatting casually about REST. I've heard so many definitions over the years. Even people who have built many web services do not always agree on what is and isn't REST.

How many times have you searched for project documentation only to find that it is either non-existent or out of date? Documenting a project is hard. Someone has to spend hour after hour to keep up the documentation in sync with the codebase. When you are rushing to meet a deadline, the first thing you cut off is the time to write good documentation – to document what design decision you have taken, why you have taken them, to update the architectural diagrams, and so on.

Do you remember the first time you read the "Design Patterns" book? I remember mine. I can never forget that feeling – every problem has to be solved using an existing pattern from the book. Patterns quickly overrun my projects, turning simple concepts into monstrous aberrations. In my early days as a developer, I had a similar experience, but at that time, it was inheritance, not design patterns.

Statically versus dynamically typed programming languages – that controversial topic is old as the world but still pops up at almost every developer gathering. Everyone has a preference. Everyone is zealously defending their side. And that's great – developers who care about their tools care about their work. Sit with me, and I'll tell you how I feel about this controversial matter.

I see utility classes in nearly every bit of Java code I review. Even core libraries like Guava and Apache Commons aggressively promote them. But Java is class-based. The language has no support for a function living outside a class. What force pulls developers toward creating utility classes?

Many preach that it's a good practice to comment your code so that your buddies will know what the heck that code does and why it was written. There are many reasons why developers write code comments. One or two sound legit. Most of them don’t. Sit with me, and I'll show you why code comments are bad and how to write self-explaining code.

I often advise Rails developers to pull domain concepts out of their controllers into plain old Ruby objects. But not everyone is convinced that a controller should be thin. If you fall into that group, stay with me while I reveal the problems of fat controllers. On the other hand, not everyone who believes in thin controllers succeeds in that pilgrimage. If you fall into that group, stay with me while I share my thoughts on how I design my controllers.

I often feel a black mood surrounding JavaScript promises. Some people don't get them. Others think they have a good grasp of that concept but cannot explain it. Many have been using them for years but don't quite understand why. Do promises bring complexity or clarity to their JavaScript soup? What problem do they solve? Why should we care?