Atlassian Stride

Stride is a new product from Atlassian.  It is a re-branded and, hopefully, improved HipChat.  I haven’t tried it yet, but our team account will be upgraded soon enough.

To be honest, I’m not that excited about this move, but I’ll give it a benefit of a doubt.  I know there was a lot of hype about Slack recently, but I was really happy with HipChat.   I tried Slack for three days, and ran away.  But HipChat I can’t leave without.  It’s a much simpler and cleaner user interface, and it just works – completely out of your way.

Judging by the screenshots, Stride is a user interface upgrade to HipChat.  Atlassian has been moving to the new design recently with BitBucket and possibly other tools, so this part makes sense from at least their perspective.  Stride also brings free video calls, voice calls, and screen sharing.  HipChat had this option for the premium accounts (2$/month/user).  We tried it for a month and reverted, as the quality of calls and video was horrible.  And there were constant crashes and disconnections. Hopefully, Atlassian has put some work into these issues for the Stride release.

The most annoying thing about the upgrade from HipChat to Stride will be all the integrations.  Atlassian is promising to migrate all the data – history, files, custom smileys, etc.  But the best part about HipChat are the integrations.  We have a whole lot of them – GitHub, BitBucket, TravisCI, Twitter, WordPress,  Zabbix, and even our own custom ones, that we use for project deployments.  All these will have to be reconfigured and setup for Stride separately.  That’ll take a few hours here and there to get things back to where they were.

As far as the new features go, I don’t see too much yet.  Apart from the already mentioned voice calls, video calls, and screen sharing, there are just a couple.  Focus Mode is not really a big feature.  HipChat, much like any other messaging application, already had the status (Online, Away, Do Not Disturb, etc).  So Focus Mode is pretty much the same thing, with an extra time setting, so that you don’t forget to change you status back after a couple of hours.

Actions and Decisions is a nice addition.  You’ll be able to mark any message as an action or decision so that its easier to find and follow up on later.  But for us that’s not going to do much as we are already using Redmine for the project management.  Actions go into Redmine as tickets, and can later be referenced in commit messages, linked to each other, etc.  Having actions in Stride will probably work for very small teams with very few projects.  For us, we have a separate room for every project, every team, every office, and then some.  So searching for actions in a hundred-something rooms is far from perfect.  But maybe Stride’s search will be more powerful than that one of HipChat.  We’ll see.

Oh, and I’m guessing all the users will have to downloading and install new apps – for mobile, desktop, etc.  That’s yet another thing to do.

As I said, I haven’t tried Stride yet, and I hope it’ll be a huge improvement over HipChat, even though I HipChat worked great for me.  As I see it now, I think re-branding and the new design could have happened on the HipChat infrastructure.  Moving people to the new application altogether has to be justified by some major improvements.  And I’m not seeing anything major just yet.

Three years at Qobo

Today is my third birthday as the Qobo CTO.  Here are the summary posts for the first and second years, if you are interested.

I haven’t had a boring year at Qobo yet.  And this last one was the most eventful and interesting, both business and technology wise.  Let’s have a quick look at the business side of things first.

Since last August, here are some of the things that happened:

  • In October 2016 we opened the Limassol office.  It’s mostly used by developers and for developers.  But we had a few client meetings in there too.  If things go as fast an good as they are going, we’ll need to either expand it soon, or move to the new premises.
  • In December 2016 we closed the deal with our first angel investors.  That was quite a lengthy and tedious process, during which we spoke to a lot of organizations and individuals, went through a variety of checks and audits, and figured out answers to many questions that we’ve never asked ourselves.  As a result, we found partners who not only brought the money in for the company growth, but a wide range of business expertise.  Personally, I’ve learned a lot during and after this process, and hopefully will boost my understanding of the business world.
  • In March 2017 we received the confirmation that our application for the Research and Development grant from the Cyprus government and European Union was approved.  This process also took quite a bit of effort and time and is far from over.  This money will help Qobo to grow even further and once the tender is complete we’ll have quit a thing to show for it.  That’s about as much as I can say now.
  • In May 2017 we opened the London office.  This one is mostly for our sales force and the expansion of business into the UK market.
  • Over the course of the whole year, we have grown our team quite a bit as well.  We are now about 15 people, but it’s not the quantity that matters, but eh quality.   We manage to bring in some people that I worked with in many previous jobs (Easy Forex, FXCC, Tototheo Group, FxPro, and even as far back as PrimeTel).  And by the looks of it, the team will continue to grow.
  • And much like in previous years, we have signed more clients, did more projects, and delivered more solutions, both locally, here in Cyprus and abroad (primarily United Kingdom).

Now let’s have a look at technology a bit more.  Last year I mentioned Qobrix, but I could give you any more details.  Today, Qobrix is a real thing.  It’s our own platform for building business applications rapidly.  We developed it to a very usable state, and built quite a few applications with it, anything from custom processes, Intranets, and all the way up to the CRMs.  The platform is being actively developed and is maturing every day.  We have also started building a new website that provides plenty of information for it.

Big chunks of our development effort are being released as Open Source software – have a look at our ever-growing GitHub profile.  We have also contributed to a number of Open Source projects in both CakePHP and WordPress ecosystems.

We are also getting much better at this whole cloud computing thing.  Our knowledge of Amazon Web Services (AWS) is growing and improving.  We have more servers now, use more services, and planning to expand even further.

Overall, as you can see, this was quite an intensive year, and it doesn’t look like things are slowing down.  Quite the opposite.  After three years at Qobo, I have to say that this is hands down the best job I ever had (and I had some pretty amazing jobs in the last couple of decades).  I’m learning a lot every single day.  I see the impact of my effort on the company as a whole, on the team, and on our clients.  And I am still humbled by the expertise and virtues of people around me.

I’d like to thank everybody around me for all the wisdom, tips, hard work, and joyful moments during the last year.  I’ll be raising my glass tonight for many more years like this one.  Cheers!

Fedora 26 Update

Fedora 26 has been release about a month and a half ago.  But I didn’t have the time to update my laptop until today.  There was also nothing particularly exciting for me in this release, so there was no rush.

Here’s what I had to do today to update my laptop from Fedora 25 to Fedora 26:

# Let's get into root to save a few keystrokes
sudo su -
# Install all updates for Fedora 25
dnf update
# Install dnf system upgrade plugin
dnf install dnf-plugin-system-upgrade
# Download upgrade packages for Fedora 26
dnf system-upgrade download --refresh --releasever=26
# Reboot and install Fedora 26
dnf system-upgrade reboot

If you need more help, have a look at DNF system upgrade wiki page.

The whole process took less an hour, but your mileage may vary.  For me, the download itself was the slowest part.  I had to pull down about 2.5 GBytes worth of packages, and given my office connection, it took about 35-40 minutes.

The installation itself took about 10-15 minutes, for which, I think, the solid-state disk (SSD) helped a lot.

One more reboot later, everything was up and running.  Of all the changes pushed into this version, I think, the upgrade to PHP 7.1 is the one that affects me the most.

Fire and Motion

Joel Spolsky wrote “Fire and Motion” blog post back in 2002, but it is as relevant today as it was 15 years ago. It’s a good read on the subject of both personal and organizational productivity.

What drives me crazy is that ever since my first job I’ve realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I’ve found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I’ve always been one of the most productive members of the team. That’s probably why when Peopleware and XP insist on eliminating overtime and working strictly 40 hour weeks, they do so secure in the knowledge that this won’t reduce a team’s output.

London Trip

Swan Pub, London, UK

As some of you already know, I’ve spent most of this week in London, UK.  My first and only time in London was back in 2009, when I went there for a PHP conference (see this post, and this post).

This trip was very different.  I stayed longer than the last time.  I was mostly for business.  I had much less time to explore the city as a tourist.  So I thought I’d write it up, in case I case I need to remember some of it later.

Continue reading “London Trip”

The Engineer/Manager Pendulum

The Engineer/Manager Pendulum” is a great article about a career shift from engineering to management.  Anybody who’s in engineering now and plans or even just wants to become a manager should read this.  Anybody responsible for “promoting” engineers to managers must read this too.

Eight Rules for Effective Software Production

Timofey Nevolin wrote an excellent article “Eight Rules for Effective Software Production” over at Toptal.com.  The whole thing is well worth a read, but here are the 8 rules to get you started:

  1. Understand the IT Mentality
  2. Do Not Mix Software Production and Development Methodologies
  3. Use Persistent Storage as an Extension to Human Memory
  4. Stop Wasting Time on Formal Time Estimation
  5. Understand the Cost of Switching Tasks and Juggling Priorities
  6. Use Architecture Reviews as a Way to Improve System Design
  7. Value Team Players
  8. Focus on Teamwork Organization

All of these are good and true, but if I had to pick one, I’d say that rule 4 is my personal favorite.  Sometimes I feel like I’ve spent a good quarter of my life in meetings, discussions, and other estimation sessions.  And looking back at all of them, I have to honestly say that they all of them were a waste of time.  The only useful part of an estimation session is a high-level project plan, but that can be achieved with a project planning session – much narrower goal, much more measurable, and much easier to achieve.

Is group chat making you sweat?

Jason Fried has an excellent write-up on the pros and cons of using group chat for the team communications, and some of the ways to make it better. We use HipChat in the company and while it’s vital to our operations and I can’t even begin to think how we could do what we do without it, it does have some negative side effects – exactly as James describes them.

The most valuable advice out of that long article is this one (I’ve heard it before a few times, but it’s worth repeating):

Think about it like sleep. If someone was interrupted every 15 minutes while they were trying to sleep, you wouldn’t think they’d be getting a good night’s sleep. So how can getting interrupted all day long lead to a good day’s work?

 

A Million Words Published at Work in a Remote Company

Sara Rosso shares some thoughts on what to document and share, after publishing over a 1,000,000 words while working at Automattic.  Here’s the gist of it:

  • If you’re the go-to person for something in your company, consider how much of it is just gatekeeper information you could document properly to help someone else learn/grow from or work on independently.
  • Separate out processes and historical background from your strategic expertise. Processes and backstory are not really ‘what you know.’ It’s much better to be a person someone asks ‘why’ or ‘when’ to do something vs. the logistics of a ‘how.’ How can and should be documented for others to build off of regardless of your involvement. This should free you up to be more involved in the why, the new, and the next of your work.
  • If you’re repeating yourself in private chats or (gasp!) email on a specific topic, document it. That’s also what drove me to create this blog – being able to answer someone’s question with an answer you’ve already carefully crafted for someone else is a great feeling (and a great use of your time)!
  • Will someone want to know why you decided or executed something a specific way later? Share as much background as possible so colleagues are brought up to speed immediately. Share the setup & thought process you went through, where to find more information, and even the facts, ideas, or information you considered but deemed outside of scope for the particular project. My goal is to hopefully never have someone ask “where did this come from?” or “what’s your source?” or “did you consider this?” (when I had) and instead focus on enriching the discussion or challenging my ideas vs. asking me for information I should have provided in the original post.
  • Gather the best, most complete, or authoritative things you’ve authored and submit them as potential onboarding materials for new team members. Challenge them to ask questions and to find something you need to document.
  • If important progress is made, be sure to update your documentation, or retire in favor of something newer or more complete. We do this by linking from old posts to new ones, and all it takes is a quick comment and a link on an old post.