996.ICU

There has been some noise in the mass media about the 996.ICU (official website) recently. That’s good, but I think we can do better. So, spread the word!

Here are a few bits to get you started:

The name 996.ICU refers to “Work by ‘996’, sick in ICU”, an ironic saying among Chinese developers, which means that by following the “996” work schedule, you are risking yourself getting into the ICU (Intensive Care Unit).

What is 996?
A “996” work schedule refers to an unofficial work schedule (9 a.m.–9 p.m., 6 days per week) that has been gaining popularity. Serving a company that encourages the “996” work schedule usually means working for at least 60 hours per week. Visit 996 working hour system on Wikipedia for more details.

GitHub and Microsoft works support the 996.ICU initiative, as well as many other companies and teams.

Cyprus Tax Calculator

Cyprus Tax Calculator is probably the best implementation of the tax calculator that I’ve seen around. It’s dead simple to use, and allows all kinds of calculations – monthly or annually, with or without 13th salary, and reporting overalls, income tax, social insurance deductions, as well as providing tax breakdowns.

Very handy tool for anyone in the job market. ;)

Time for a new adventure

This week I’ve handed in my resignation letter, marking my last working day as February 28, 2019. After 4.5 years as a Chief Technology Officer at Qobo, I feel it’s time for a new adventure.

Looking back at the last 4.5 years, it feels like there is enough to fill several lifetimes – so much has been done, so much has changed, so many people met, so many ideas tried, and so many things accomplished!

Have a look at my annual posts summarizing just the most noticeable changes:

Or, if you feel like it, take a deeper dive into more blog posts, varying from Instagram pictures to some deep technical brainstorming and solutions.

Obviously, I can go on and on for hours, but here are a few high-level points just to keep things in context:

  • Offices. We’ve opened a new office, or moved to a new office, pretty much every year. First, Nicosia office was moved and expanded. Then Limassol office opened. Then London office opened. Then Limassol office moved and expanded.
  • People. From a small team of 7 when I joined, we’ve expanded to over 20 now. But it wasn’t only about the headcount. We’ve grown the number of roles in the company as well – sales, support, QA, etc.
  • Clients. We’ve built an impressive portfolio, with many large, medium, and small clients, across a variety of industries from a several countries.
  • Technology. We’ve built an impressive set of technology, both internally and externally. Our Amazon AWS cloud infrastructure nearly doubles every year. We have integrated a number of excellent tools to help with project management, quality assurance, development cycle and continuous delivery. And we’ve made Qobrix from scratch into a recognizable brand and force to be reckoned with.
  • Open Source. True to our Open Source believes, we have made significant contributions to Open Source, both via our own repositories, and through the tools and libraries that we use and build on top.

I have met and worked with some really amazing people and teams, true professionals, and inspiring individuals. I have learned a great deal over the years, and have grown both personally and professionally.

So, why am I leaving then? I feel it’s time. It’s time for a change both the company and for myself.

When I joined Qobo, it was a tiny startup, like many others, trying to find its identity, develop, and grasp some luck. It was also still trying to survive the catastrophic consequences of the “Cyprus haircut“, which killed many stronger, more mature businesses. Gladly, we managed to pull through all of that. It wasn’t easy by any means, but we’ve done that. The company has survived, grown, and matured.

It is now well on the way to success, with a clear vision, great products, strong client portfolio, good reputation, and an amazing team.

I think I have done enough to help Qobo to get here. There are now many new people, ideas, and approaches, which will take it forward in a smoother, faster, and more efficient way.

As for myself, it’s also been quite a ride. There has been countless nights and weekends of tight deadlines, non-stop work, lack of sleep, nervous breakdowns, alcohol abuse, emotional highs and lows, and so on. (All kind of expected in a startup.) But I need to step back and recover a bit. On top of that, over the last few month, my focus was mostly needed in non-technical areas. I want to get back to my routes for a bit, and dive into the hands-on technology – things that I like the most: writing code and administrating infrastructure.

Where am I going then? To tell you the truth, right this moment – I don’t know yet. The decision to step down as a CTO and to leave Qobo took quite a bit of thinking, consideration, and preparation. I haven’t looked at my new options or opportunities yet. But given the state of the IT industry in Cyprus and a growing deficit of developers, devops and system administrators, I’m sure I’ll find my next adventure soon enough. (If you have any suggestions or recommendations, please do ping me either here or via LinkedIn).

I would like to take this opportunity to say a huge thank to you to everyone I’ve met and worked with while my years in Qobo. I am truly humbled and honored to have had the opportunity to work with you and to learn from you! I’m sure our paths will cross again.

You Only Need 50% of Job “Requirements”

The Science of the Job Search, Part VII: You Only Need 50% of Job “Requirements” – is a nice article in the series, with a few interesting numbers. The one that stands out the most is:

You’re as likely to get a job interview meeting 50% of job requirements as meeting 90% of them.

This sounds about right. And it also explains how the recruiting is still around, with all those ridiculous requirements in every other vacancy.

HipChat to Slack migration


Back in July, Slack acquired Hipchat with the intent of migrating all the users and shutting down the service.  For us at work, these were very sad news.  We’ve been using HipChat for years, and relied on it heavily.  We have also evaluated Slack in its early days and didn’t quite like it at the time.

Once it was clear that the HipChat is going away, we had a couple of options to consider.  One was to move to Slack.  Another – to migrate to a different solution, preferably to a self-hosted one, like Rocket.Chat.

So, first thing we did, was another test trial of Slack.  We were glad to see that it matured and improved a lot over the last few years, and that it would be faster and easier for us to move to Slack rather than to roll out our own self-hosted solution.

Here are a few things that we had to keep in mind for this migration:

  • We have a rather small team – about 15-20 people altogether, but with a very mixed backgrounds.  Some are very technical, some are not.  Some are on Windows, some on Linux, and some on MacOS.  Mobile use is also heavy across the board.
  • We are working with a lot of rooms/channels.  We have a few generic ones, like Support, Sales, Management, etc.  And we have a separate channel for every project.  And those we have over a hundred of.
  • We have a number of integrations connected – GitHub and BitBucket repositories, Zabbix monitoring system, RSS feeds, deployment automation, etc.
  • HipChat would only be around for the next month.  Not a tight deadline by our means, but the timeline is important here.

Since the time was limited from the beginning, we decided to start with the migration pretty much immediately, rather than waiting until the last moment.  In case something wasn’t working, we’d have some space to maneuver.

Instead of a once off switch, we also decided to do a gradual migration, shifting from HipChat to Slack bit by bit, using both services in parallel.

Creating the new workspace and registering all the users was, as you can imagine, the easiest part.  After all we do have only a small team, and that many accounts can be done manually, without any automation what so ever.

That was an option for the rooms/channels though, as we have hundreds of those.  Gladly, both Slack and HipChat provide an API which helps with automation, and we have awesome DevOps who handle things like that.

Here comes the first issue that we came across.  HipChat allows for much more when it comes to room names, than Slack.  Slack channels are limited to 21 characters (which is not a lot), and the selection of the characters is much less also (dashes are in, but slashes and other special characters are out).

That meant that we had to come up with the new naming convention, which we did.  We also used this opportunity to consolidate some of the HipChat rooms into fewer Slack channels.   In HipChat, as I mentioned, we had a separate room for each project.  Which was handy for busy projects, but somewhat confusing for smaller projects that belonged to the same client.  For example, it’s not a rare occurrence for us to have two, three or more projects for a single client.  And while they are all different, often they overlap a lot (websites for a group of company, or a website integrated with the CRM, etc).

Once we decided on the adjustments to the naming convention and consolidation of some rooms, the migration wasn’t too difficult, given the API of the both services.

Next came the integrations.  This is where, I have to say, Slack shines.  While HipChat integrates with both BitBucket and GitHub too, the functionality provided by Slack is a lot better and easier.  Both GitHub and BitBucket are available out of the box, so we quickly connected all the project channels to their appropriate repositories.

RSS feeds weren’t a problem either.  So the next one that we had to do was the Zabbix monitoring system.  Again, Zabbix is pretty good with integrating to other systems, Slack API is flexible, and our DevOps are amazing.  So that took no time at all. In fact, we even made it better, since Slack allows for richer and better notifications.

The last, but the most important one, was our deployment automation.  It wasn’t painful, but it did require us to do some adjustments.  Some of these we wanted to make for a while now anyway.  The biggest change was that HipChat didn’t care about the long running tasks, while Slack expects an answer from your webhook within 5 seconds.  Many of out deployments take longer than that (some are up to 20 minutes), so we had to do some changes.

When the chat webhook request for deployment is received, we couldn’t wait for the deployment to finish anymore to send the response back.  We had to respond within 5 seconds.  That meant that we had to disconnect the actual deployment run from the chat communications.  As I said, we wanted to do that for a while anyway.  A quick proof of concept with the Linux “at” command worked quite well, so stayed with that for the time being.  Now when the request is received, the deployment is scheduled with the “at” command for the next minute, and the response is sent to the chat within a second.

That was about it.  Since we didn’t care about migrating the actual chat histories or uploaded files or anything like that (we use Redmine for anything that needs persistence), the migration overall was smooth.

Once all the users were registered, channels created, and integrations configured, we started to phase out HipChat rooms one-by-one, archiving and disabling them on HipChat and pushing users more and more towards Slack.

Overall, the setup and configuration took us about three weeks.  The rest of the migration with the users and phasing out of HipChat took approximately another two weeks.

So, now that we’ve been using Slack exclusively for about a month and a half, how do we find it?  I think overall it’s a lot better now that it was with HipChat.  Here are some of the benefits:

  • The mobile app is amazing.  It supports multiple workspaces (some of our clients are also using Slack and we need to be in multiple places at the same time), has a great user interface, and, most importantly, the push notifications are working A LOT BETTER.  HipChat had a tendency of going offline after about 10 minutes and being completely silenced until the next manual check.  Slack even provides a Snooze option for 20 minutes, 1 hours, etc, which makes it easy to silence it during a meeting.
  • Slack desktop and web applications seem to be better enjoyed by non-technical users, than their HipChat alternatives were.  For me personally, HipChat was easier on the eye, but Slack provides a lot of functionality which wasn’t in HipChat.
  • Threads!  I think this is one of the greatest features that HipChat was missing.  Project rooms especially can get quite noisy.  It’s often difficult to follow up with all the chatter.  Threads make it a lot easier.  With threads there can be multiple concurrent conversations in the same channel without any confusion or overlap.
  • Reminders!  Again, for those of us who are busy with a million things, reminders in Slack are a killer feature.  They help to find that message that needs a response, half an our later, in a hundred rooms with dozens of conversations going on at the same time.
  • Slash commands.  While both HipChat and Slack have them, Slack allows to send the same slash command from any room (handy for deployments).  With HipChat we were a lot more limited, which pushed us into a separate room for all deployments.
  • Emojis.  Usually, I’m the last person to use emojis.  I’m the old school smiley guy.  But in this particular context, I find emojis to be very useful.  They often save a lot of typing and help keep the atmosphere nice and friendly.  HipChat had a very weird approach to emojis.  While they were there, they were very few, and very custom to the HipChat team.  We did upload a lot of our own over time, but with Slack that wasn’t necessary.
  • Stats and analytics.  Slack provides a great insight into how the workspace is being used.  Stats are available both as an admin menu item, and as a quick weekly email.
  • Integrations and API.  Slack provides a much more flexible API and integration options.  While we were doing fine with HipChat, I think all of our integrations are much better now because of the move to Slack.  (slash commands, updated messages, message replies, file attachments, rich messages, etc).

As I said, overall the migration went quite smooth and we are in a much better place now.  This is quite surprising and refreshing, especially after us considering the news of HipChat acquisition as a sad story.  In fact, I can’t remember, from the top of my head, when a sad story like this turned out to be such an improvement.

Thank you HipChat team for all the effort – you’ve been great for the last few years.  Thank you Slack for making things even better!