Skip to main content

Tech in Minsk

Over the past year I have been working on setting up an R&D center in Minsk, Belarus.  Belarus, like Russia has a strong STEM education and produces a good amount of talented software engineers.  It is clear that Belarus recognizes the importance of the technology in their economy but still needs some economic reforms to become a serious technical hub.

I stumbled across Minsk by accident.  While being of Russian heritage, I never had any friends or family in Minsk and have never been there before my visit last year.  The FinTech company I joined last year (Ethos) had a few contractors there who were working on one of the products.  My first goal was to figure out if committing to an engineering center in Minsk was worth the trouble.  The short answer is: yes.

Minsk has a number of universities that produce software, electrical and mechanical engineers.  There have been a number of companies like Viber who have large offices in Minsk and there seems to be a community of software enthusiasts.  During one of my visits I went to an event at place called SPACE ( and it was very similar to the events we have in San Francisco: a lot of passionate developers talking about latest technologies, drinking beer and cracking sarcastic jokes.  The funny thing about SPACE is that it’s located in an old Soviet factory and makes you feel like the technology is sprouting from the ruins of the old ruins.

The team we have assembled in Minsk has been doing well: they write good code, they are focused on quality, they work well with their counterparts in California and they speak fairly good English.  While there has been some brain drain from Eastern Europe to the West there are plenty of engineers who want to stay in Belarus.  The major reasons for that are purchasing power, family and familiarity.

The days where former USSR had a deficit and restricted travel are gone.  Today you can buy anything you want from BMWs, Nike to Nestle.  An average Belarussian earns about $500 a month, while experienced software engineers who speak English average around $3,500.  With that kind of salary your spouse can stay at home, you can pay off a condo in 2-3 years and travel abroad a couple of times a year.

The trouble for Belarus continues to be the law:

  1. The banking system is required hand written signatures and physical presence for even the smallest transactions in dollars.
  2. Running a company requires someone to take personal responsibility and can result in jail time for the person who signs off on documents. 
  3. Taxes end up being over 40% and are mostly paid by the employer.

There is a new generation of officials in their 20s and 30s who have grown up with open borders to the West and their reforms are making a difference.  One of such reforms is the creation of High Tech Park where companies get a more manageable 10-13% tax rate instead of 40-45%.  Our subsidiary ended up getting accepted into High Tech Park, but it was a much harder process than anyone anticipated with over $10,000 going to law firms with no guarantee of admission.

I think Belarus is on the right track. Unlike Russia, who can rely on their vast energy reserves, Belarus needs to get knowledge economy going.  I have met many people in Minsk and I know that they are excited about being a part of the global economy because they have a lot to offer.  I hope that the government keeps working on the reforms that open up the country to the foreign investment and eases the regulatory burden.



Popular posts from this blog

SDET / QA Engineer Interview Checklist

After interviewing and hiring hundreds of engineers over the past 12+  years I have come up with a few checklists.  I wanted to share one of those with you so you could conduct comprehensive interviews of QA Engineers for your team. I use this checklist when I review incoming resumes and during the interview.  It keeps me from missing areas that ensure a good team and technology fit.  I hope you make good use of them.  If you think there are good questions or topics that I have missed - get in touch with me! SDE/T or QA Engineer interview checklist from Mike Borozdin If you like this checklist you might want to check out these posts: Emotional Intelligence in Software Teams   and  Good-bye manual tester, hello crowdsourcing!

Code versus Configuration

At Ethos we are building a distributed mortgage origination system and in mortgage there is a lot of different user types with processes that vary depending on geography.  One of our ongoing discussions is about how much of the logic resides in code vs. being in a workflow system or configuration.  After researching this topic for a bit, I have arrived at a conclusion that the logic should live outside of code very infrequently, which might come as a surprise to a lot of enterprise software engineers. Costs of configuration files and workflow engines First thing that I assume is true is that having any logic outside of the code has costs associated with it.  Debugging highly configurable system involves not only getting the appropriate branch from source control, you also need to make sure that the right configuration values or the database.  In most cases this is harder for programmers to deal with.  In many FinTech companies where the production data is not made readily acce

Intuitive Programming - Comments

Comments are a topic of vibrant discussion.  Ever since programmers could leave some text in the program that was ignored by the machine the debate started: “what’s a good comment, what’s a bad comment, why comment?” There are endless instructions to programmers that say many of the following things: 1) Describe your function! 2) Don’t write in the comment what you wrote in the code. 3) Tell people why you are doing what you are doing. What I think has been missing from this discourse is the audience for comments and through those audiences there is intent.  The code is being read, skimmed or analyzed by people and tools.  So what are the audiences and reading modes? 1) Maintaining and enhancing the code 2) Skimming through the entire module or file to figure out what the overall structure is 3) Reviewing the test files to check out the test coverage and edge cases 4) Seeing the docstrings of functions while being in a separate file altogether 5) Reviewi