Just as many other software developers, I like video games. I've spent countless hours grinding and leveling my characters in RPG games like Diablo. As your character grows in levels, you choose their skills and put points into attributes. Perhaps the most classical attribute set is: strength, dexterity, vitality and magic. They define whether your character is a wise mage, a strong fighter, or an agile sharpshooter.

I decided to take this approach and develop a similar role-playing character system for software developers. For me as a manager, my direct responsibility is to give feedback and provide guidance to developers. So if you don't have a good system, it can be very hard to come up with crucial points, which your developers colleagues need to work on to get to the next level.


For productive work software teams need a version control system (VCS) flow. A set of rules, that describes how code changes will be integrated into the existing code and delivered to testing and production. Obviously the VCS itself is the first factor that affects the flow, what you can do with git may not work with svn. At the moment of writing git has become the industry standard, so the ideas are based on that premise.

There already exist frameworks like Gitflow (I suppose this is where the popularity of the word flow comes), but as with any framework, it brings a lot of tools you might never need in your project. So lets consider the leanest flow, that is still organized and effective.


Takeouts from a talk from GOTO 2019 conference "'Good Enough' Architecture" by Stefan Tilkov. Found on youtube.


Theory: "Architecture represents the significant design decisions that shape a system, where significant is measure by cost of change". (Grady Booch)

Practice: "Whatever the architect considers important enough to merit their attention"

There can be lots of things that really don't matter, that should be left to the developer. At the same time there are many important things are not being considered.


One plus one


A little funny quiz I've came up with. Guess programming language:

  1. '1' + 1 = 11
  2. '1' + 1 = 2
  3. '1' + 1 = 50
  4. '1' + 1 = TypeError

Answers below More...

One of common tasks in software development is building a client library for some service API. Over the years I've come up with a way of structuring these libraries, which has served me well. The evolution of my approach went all the way from 2 layer (Business - Client) to now 4 layers. In some specific cases you might need more than these 4, but in usual case it enough. So the layers are:

  1. Business/Domain Layer
  2. Service Layer
  3. Client Layer
  4. Transport Layer

Business/Domain layer

Business layer doesn't really belong to the library itself, it is application specific. This layer contains business logic, which operates in business terms. For example, your use case requires you to create a Google Analystics visitor statistics widget for your backend panel. It is important to note, that use case does not define which protocol do you need to use or which request you need to make. All because it's irrelevant, the use case is still valid regardless of technical details. We can use some pseudocode to describe usage of the client library in the use case: gaService.getVisitorStatistics(). Actually, the real code shouldn't look much different. As we see, business layer makes use of a service class, which belongs to a service layer.


Some time ago I wrote a post on my hate towards static methods and helper classes. It was more of an emotional rant than anything else and didn't serve the educational purpose. So this is a rewrite of the original post, which I hope can provide more insight.

To begin with, a static method is a method, that can be invoked without instantiating an object of that class. The most common usage of static methods I've seen are helper classes and singleton pattern. A helper class is a collection of static methods, which hopefully has some common topic. So it may look like:

// /helpers/FormatHelper.php
class FormatHelper
    public static function formatXml($xmlString) {...}
    public static function formatJson($jsonString) {...}

and the usage would be:

// /lib/ServiceClient.php

I hope you get the idea. So here is where I see the problem. More...