Cats seemingly have no purpose. They just lounge all day, doing nothing. They have little impact on their surroundings. All they seem to do is entertain us and make our lives a little better.

I prefer small projects. They tend to be more technically challenging, and also require working with fewer people. This seems like a contradiction to my preference to focus on the people instead of the machines, but actually, it's not. In large projects, you are a cog, and you get to fit into the processes. Whereas in small projects, you have more freedom to do what you deem right. And you can communicate more liberally.

I've seen many beginners struggling to learn an imperative programming language. CSS and HTML are usually easier to grasp, because of their declarative nature and they are easy to visualize. But JS is entirely different. Why it's so hard to get the basic concepts of a "real" programming language?

When I learned how to code, I was young. I had the time to tinker with the basics, try out things and see them fail. But I got back to it over and over again, and could finally make it work. After enormous effort, I could figure out how to write code.

Have you ever looked at a piece of code and thought how awful it is? Codebases tend to get messy with time. And don't have illusions: this is true for your code too.

The pursuit to reach 100 percent is one of the most demanding tasks. It's not endogenous only to software development, but as I see, it's more prevalent here.

The what-if fatigue is when you try to understand a piece of code, but it's a convoluted mess, and you get tired just by looking at it. I'm sure you've seen such code, and chances are, you wrote some too.

Never underestimate the power of small changes over a longer period of time. This perseverance has the power to make you reach just about any goal. Daunting tasks can usually be broken into small actionable pieces. And from then, it's just a matter of persistence.

The Pomodoro technique is a simple system that potentially helps you to focus during your workday. It is a time management system that chunks the work into 25 minute focused periods followed by 5 minute breaks.

I often see that developers are only interested in what directly affects their work, and they don't look beyond that to see the big picture. They don't ask the questions why the client is asking for a particular feature. They just get the task and deliver it. This often results in features that are hard to maintain yet useless to the client.

As an employee, freelancer, or an entrepreneur, you need to manage client expectations. This is often a neglected field, but it is one of the main differentiators of professionals.

In every business situation -- which an employee - employer one certainly is -- trust is your #1 asset. You build it over time, with consistency, by always doing a great job. After some time, people will start to notice, and begin to trust you.

Most project I worked on didn't have automated tests, even though all involved agreed they would bring significant benefits. But the cost of writing them was too high, and it couldn't happen. But why so many projects are left in a sad state like this?

You might have already noticed on yourself that the mindset during testing is entirely different than the one during coding. This causes problems with testing your own code and ensuring quality. But if you accept this fact and work around it, you'll produce better code with better self-QA. Not testing the code you wrote every so often is a lack of professionalism. Company QA does not count; if they push bugs back to you, there is room for improvement in catching them. This is one of the differentiators between people who you'd like to work with and those you wouldn't.

Working with feature requests coming from users is a difficult challenge in itself. They tend to wreak havoc to developer sanity. They often contradict a previous feature or don't fit into the current architecture. You might start wondering if they really need the software you've built or an entirely different one.

In the daily grind, while tackling down algorithmic and architectural challenges, people tend to forget that the software they are building is just a tool, created by humans, for humans. Usually, the result is arrogance and unhappy development. But you can choose to look at it the other way, and do your best to prevent it from happening.