Vinted Engineering

After being a PHP developer for 10+ years, I’ve switched programming languages twice in the past two years. During all of my years of web development, I assumed I knew many programming languages. I used JavaScript relatively often. I knew jQuery (it was cool at the time). Obviously, Java, C++, and Pascal were always in my portfolio.

I always assumed I had a broad view and was absolutely fine…

Learning/trying is not the same as using daily

At some point during my PHP career, I started to notice that I couldn’t contribute much to some technical discussions. People would share their experiences from other languages, explaining how some things were better or worse. At the same time, one of my JavaScript pull requests was heavily criticized by my front-end colleague. The code was fine from the functional point of view. But it was old-school and certainly not cool enough to be accepted by the front-end guild. This is the exact image that was used to decorate my pull request:

At that point, I realized my actual level in other programming languages. And the fact that learning/trying something is incomparable to real-life day-to-day use.

The switch to Node.js (TypeScript)

An opportunity presented itself to switch to Node.js. I took it. And within six months, I felt good and productive again. Fast/slow, good/bad – this isn’t the topic of this article. But the fact is that now I know what all that fancy asynchronous programming feels like in daily life. With all its benefits and drawbacks. Now there is no way back. A clear understanding of the asynchronous world and document databases changed the way I look at every new problem I face. Obviously, I knew about the existence of asynchronous programming before. I even faced it relatively often in the browser. But I didn’t use it on a daily basis. And that’s a HUGE difference.

Node.js broadened my tooling portfolio significantly. Here are my main findings about NodeJS + MongoDB:

• Given the fact that a single Node.js instance can process multiple requests simultaneously makes you realize something straight away – that a bug or memory leak in an unimportant part of the code can interrupt several extremely important operations being carried out on the same thread.
• Node.js can easily kill third-party services! Given the asynchronous nature of Node.js, it’s easy to initiate thousands of requests to third-party services with a single instance from your application.
• Zero requests being processed doesn’t mean it’s safe to restart. It’s easy to leave the asynchronous method running in the background even after the response has already been sent back to the client.
• It’s cool to store the document’s state history and other related data in the document itself without creating separate tables. So many basic things can be achieved more easily without the normalization overhead of SQL.

The switch to Node.js was scary and exciting and worth it.

The switch to Ruby

1.5 years spent on Node.js and here I am reading a Ruby manual because I’ve joined Vinted. And so far Ruby feels more like going back to PHP rather than something extremely new. No Ruby developers will agree with me! But for me, it is what it is.

Ruby has a different syntax. But the rest is all the same: synchronous, dynamically typed, interpreted language.

So I feel back home in that sense. All the old patterns work the same as 10 years back.

And here are my findings from Ruby world:

• The philosophy of no types requires high unit test coverage.
• Unit testing is easy. The same loose typing philosophy makes test writing/mocking the best experience ever.
• You can have 30 processes running and not be able to serve 30 requests per second if every request takes more than 1s to complete. And that limit is easy to hit if third-party calls take more than one second to complete. In PHP world, Apache hid these cases from me. And in Node.js, that just wasn’t a problem due to asynchronous nature.
• You can get the fifth element of an array by writing array_name.fifth!
• You start getting angry when your pet project written in Dart complains about a missing semicolon.
• Blocks are interesting in both aspects – syntax and functionality.
• Memoization (@xxx ||= …) can significantly reduce the complexity of some methods.
• Keyword arguments are great!

Conclusion

Getting familiar with different languages is good. Getting professional experience and actually using different languages in practice is much better. Every language/tool hides some complexity from you. Trying out different things exposes gaps in your knowledge and stimulates your professional growth. Applying for a job based on a new programming language can turn out to be an incredibly eye-opening experience – even if that new language doesn’t turn out to be your technology forever.