How to understand the managers?

All software developers need to corporate with managers and it also helps a lot for you carrier to have a good relationship between you and your managers, since mostly the managers can decide about your promotion, salary, project etc. Quite often the personal goals of a developer and the goals of a manager are going against each other and that means conflicts between managers and developers. To avoid such situation as first step all developers need to understand, responsibilities and goals of managers. By using this knowledge you can get better results from the discussions with your managers.

First see really briefly what are your main goals as a developer: you would like to have enough time to work on your tasks in a comfortable way, you would like to use the most modern technologies and try out all your ideas, you would like to participate on technical trainings, you need a good salary and good work-life balance. Most of these points costs money for your manager, but you can ensure all managers about your needs if they can see that it is beneficial for them as well.

As many companies so many different manager positions with different role description. I would like to focus on two main type of managers: the project manager, who is responsible for a project or subproject and the team manager who is responsible for a developer team. In some cases the two responsibility is owned by the same person. In other cases these roles have a different name. And of course there are other manager roles, like sales manager, but most of the cases they have less connection with the developers.

The team manager

The team manager has a team of developers. Usually the team manager’s responsibilities are the followings:

• Find the right team members (do the interviews etc.)
• Support the integration of new team members to the team
• Monitor their performance and skills
• Let them improve their skills in a defined direction based on project needs (for example sending them to trainings, find a proper mentor for them etc.)
• Provide the right developers with the correct skills and experience to the projects
• Collect feedback from project managers
• Do regular feedback sessions with the team members
• Setup goals for the team
• Organize off-work programs for the team
• Do decisions about salary changes
• Decide about holiday requests
• Remove the members from the team which are not fitting well into the team
• Regular feedback to the high management about the results of the team

That’s a lot, right. And to be able to do that the team manager needs to have a technical overview to identify the needed skills and good interpersonal skills.

There is one more important thing: most team managers has its own budget. That means the team manager is also responsible for some money. Here the incoming is from the projects achieved by the team. For example if the team is finishing with a milestone of the project there’s a predefined fix price coming to the team budget.

The costs are the following: salary of the team members, training costs, costs for equipment (computers etc.), cost for the office (rental fee, coffee etc.), costs for off-work programs etc.

Until the incoming is more than the costs everything is going well, otherwise the team manager will have certain issues. The project prices are usually designed in the way that if the team can achieve the projects within the planned time frame the team has profit and everything is fine. This will happen if well-motivated people with the right skills are working on the project. If you are in such a situation (you are working effectively and successfully on your current project) you will have a good chance to get higher salary. Or for example if you can prove that taking part on training is making you more effective on your project then you have a good chance to be sent to that training. Otherwise not, your manager won’t pay for a training which if not making your daily work on your current (or upcoming) project more effective.

Let think about situations like ramp-up time of a new team member. This is something called overhead, it costs a lot (salary, trainings etc.) but doesn’t earn money directly. Such periods need to be planned as short as possible. That’s why for example changing projects too frequently is not a good idea.

As summary: the goal of your team manager is to keep the budget balance in positive, so what ever you are asking from him need to refer to the fact that you work producing a good money for the team in the past or the investment would make you able to produce more money in the future. Of course it is not the best idea to use these words, but you should keep these thoughts in your mind.

The project manager

The project manager is responsible for one project or subproject. The goal of the project manager is to make the customer satisfied and to make the project beneficial for the company. So the tasks of a project manager are the followings:

• Regular communication with the customer
• Create time planning for the project (including main milestones, etc.)
• Create cost planning
• Create resource planning of the project (how many developers with which skills are needed in the different periods of the project)
• Track all progress in the project
• Regular reporting to the high management
• Organise the project meetings

What is important here: it is not a goal for the project manager to make you happy. His goal the reach the milestones in time. If overhours are needed for that the project manager doesn’t mind. If you are not working well the project manager will send a request to the team manager for an other developer. The goal of the manager is just to keep the plan.

The project manager is also responsible for the project budget. From cost point of view it means: the incoming is the paid price by the customer. The costs are the money paid for team manager for the work of the developers, the costs of the meetings, software licences and the travel costs.

So if a project manager asks you to do overhours he is just trying to achieve his personal goal. On the other hand it is good to have a good relationship with the project manager, because he is giving feedback about your work to the team manager, which can strongly influence your career. To be able to achieve a good relationship try to help him at planning phase with estimations which are as good as possible and then try to achieve them.

As summary it is good to have a good relationship with your managers. Never forget: without them your wouldn’t have a job, they are also part of the big machine, just like you. To be able to have a good relationship always try to understand their goals and try to support them to achieve these goals. That’s the best what you can do.

How to choose the right comapany for you?

To choose the right company for yourself can be really difficult, because each company is different. Of course it makes sense to read the evaluations of companies on websites like glassdoor or ask people who are already working there. But as a first step you need to figure out what kind of company are you looking for.

I tried to set up four main categories of the software companies. Not all the companies are fitting 100% into one category, some of them are overlapping between multiple categories. I tried to cover the four most typical type of company, describe how are they to working, what are the advantages and disadvantages of them. This is mainly written based on my personal experiences and experiences of friends.

Let’s see the four big categories:

1. The multinational company

There are several well-known multinational companies all around the world which are working with software developers. Their main focus is not always just software development. Most of these companies are well-known, so if someone is asking you where are your working you can proudly tell the name of the company and everyone around the world will know it.

These companies are usually to really directed by one person, in a lot of cases the one who established it already died years ago. The same company is usually present on multiple continents and in multiple countries. Some of these companies were either startup or family business at the beginning.

Advantages of at a multinational company:

• Salary over the average
• Connection with people all around the world
• Well-defined processes
• Good opportunity for specialists to go deep into a topic
• Option for travelling
• Good company events (Christmas party etc.)
• High variety of trainings
• Long future at the same company

Disadvantages:

• High bureaucracy
• Quite often it is difficult to change to new technologies and new topics
• Usually the work is done in big open-offices, which can be stressful
• Strict due dates
• To high manager/developer rate
• Often not enough space for new ideas (you need to use what is already done)
• These companies are often stucked to 20 years old code base

2. The startup

A startup is a new company with a new idea. At the beginning it is usually financed by sponsors. The successful startups will either become a multinational company with time or they will be simple bought by an already existing multi. The unsuccessful startups will either just go into dept or they will stay as family business.Working at a startup is in my view a bit more than a normal job. You need to believe in the goal of the company and you need to do everything for that.

Advantages of working for a startup:

• New technologies
• Great technical challenges
• Big freedom
• Interesting product

Disadvantages:

• Uncertain future
• Less focus on work/life balance

3. The consultancy company

A consultancy company is a software house which is overtaking projects of other companies (most of the cases it is a multinational company). If you are working at such a company you will change your projects frequently, you will work with multiple technologies and multiple code bases. Most of the cases communication with the customer also belongs to your tasks. You can learn a lot of technologies, but the constant changes can be stressful after a while. Your freedom on technical topics can be limited by the customer (you won’t be allowed to make bigger decisions).

One of the most difficult issue for the leaders of such companies is to be flexible enough. Just imagine: your customer which was using 10 of your developers for a project just telling you that from next month you need only a team of 4 developers. You need to plan something for the other 6 developers urgently. Or other way around: all of you developers are busy with projects and a good opportunity is coming where 10 developers should start from next week. This is challenging.

Advantages from developer point of view of working at a consultancy company:

• You can learn multiple technologies
• You can get connected with a lot of people
• You have always new challenges
• You can work for multiple companies without changing employer

Disadvantages:

• Frequent changes can be stressful
• It can happen that you are sitting without project for a while
• Most of the cases you can not go deep enough into topics

4. The family business

Not all the companies in this category are really a family business. I mean here the mostly smaller companies which are working on one product or service for long time which has a certain amount of users. The company is not taking big risks and not investing too much into new products, they are just doing the same thing since long. It can be either some web application (like creating really similar webshops) or a mobile application (again nothing really special) or anything else. It is also typical for such companies that they are using some older technology which is working well, so they are not changing it. These companies are usually not really growing. It is ideal for people who doesn’t like stress.

Advantages of working for such a company:

• Less stress
• No needed learning curves
• Good work life balance
• The team is like a family

Disadvantages:

• It can be boring to work there
• Not all of such companies can survive nowadays
• No opportunity to build a real carrier

I hope you could get some info to start to figure out which type of the companies is really for you.

Typical software developer collegaues

As I worked for multiple companies and get known more and more developers, after a while just got the feeling at new colleagues that “hmm, I know his style”. Normally I strongly against categorising people, but I think there are typical software developer characters and they are appearing at almost every company.

1. The workaholic
   The workaholic has no private life, no family, no hobbies. The workaholic is just living for the company. He is the one who is staying long in the evening and who is also working during weekends, even if it is not really needed. The workaholic always reminds you that he’s working a lot, like “yesterday I was in the office until 11”, “oh, I was working all weekend long”. On the other hand the workaholic is always tired and most of the cases he is not working in an effective way at all.
   
2. The antisocial 

   The antisocial is mostly a good programmer, but only in topics to be done individually. Team work is totally not for the antisocial. The antisocial is arriving to the office in a sneaky way and hopes no one will realise him. The antisocial is taking a brake only if no one else and he is just disappearing during lunch time. It is a challenge to work with the antisocial, because he can never tell you clearly what he is working on and what is his status, you are just getting the results randomly.
   
3. The demotivated - type 1

The first type of demotivated is quite often sitting in the kitchen and telling speaking loudly about how much he hates to work for this company and how shitty is his current project. Normally the first type of demotivated is good at programming and instead of his demotivation he is doing his job on the project, he is trying to do his best. But never forgets to tell to the colleagues: “I hate this project”.

4. The demotivated - type 2 

   The second type of demotivated has only one goal: survive the day without any productivity. And survive every day without any productivity. This strategy is working well: he is working so slow that after a while he is not getting any urgent task. After a while he will be moved new projects, but by following the same strategy there he can still avoid all kind of work successfully.
   
5. The bullshitter 

   The bullshitter likes to participate at meetings and talk a lot there. The bullshitter has always ideas and that’s not a problem at all that they are totally not realisable. The bullshitter can talk about any technology and any project, even if he was never working with them. Pay attention: the bullshitter will never work on his own ideas and it has a simple reason: he is not able to work on them.
   
6. The life long junior 

   The life long junior is simple not learning and not getting better. Whatever he is learning he is forgetting it as fast as possible. The life long junior need a long clarification each and every task, even if he already did the same 5 times. And the life long junior is not changing, it is the case after 1 year, 5 year and 10 years.
   
7. The careerist 

   The careerist has a really good relationship with his manager. And not only with his manager: with all manager around. Even with the ones which have nothing to do with him. To build such relationships the careerist is taking the half of each day in the smoking area. After that he is joining all management meetings. The careerist is having only one goal: getting a higher position as soon as possible and usually it is successful. It’s no goal for the careerist to collect any technical knowledge.
   
8. The geek 

   The geek is programming not only at work, but also at home in his free time. The geek has hobby projects at home. The geek knows and uses the newest version of every environment and hardware. Whatever tech support you need just ask the geek, but don’t be surprised if you are not understanding any word from his solution. Furthermore the geek is using only console applications and hates all GUI. The geek is always a good partner to talk about new technologies, but don’t try to talk with the geek about anything else.
   
9. The shy 

   The shy thinks that he’s worse than the others, even if it is not true. So the shy is overtaking all the shitty tasks and is doing them as good as possible. Sometimes no one knows what is the source of the frustration of the shy colleague. But most of the cases he could reach much more if he wouldn’t be shy.
   
10. The faithful 

    The faithful is faithful to the company, he is working there at least for 10 years. Most of the cases it was his only working place in his life. The faithful knows everything about the company and the history of the company. The faithful has a lot of good stories about ex-colleagues known by no one else in the team. The faithful also knows everything about the used technologies at the companies and all about the projects. But the faithful knows nothing about that what happened outside of the company in the last decades, don’t ask him about any technology not used at the company.
    
11. The philosopher 

    The philosopher is reading at least one book before starting any task. Even if it is a Hello world he will find a book about the topic and he can not start the task without reading that book. The philosopher is analysing all possible solutions with it advantages and disadvantages before writing any line of code. Most of the cases the preparation for the task takes ten times more than the implementation.
    
12. The promising one 

    The promising one is just a fresh colleagues from the university. The promising one is not talking too much, but has interest for every topic at the company. He is doing all his task and continuously learning something new. The promising one needs to pay attention: if he is not managing himself well enough in a short time he is going to be someone payed as a junior and working as a senior. It is a win situation for the company and a loose situation for the promising one.

Of course not everyone belongs to any of these categories, some of the people are also a mixture of two or three of them. I still think that it is good if you can identify yourself and your colleagues to be able to handle them better in the future.

Design by contract - Learn something new about OOP

Introduction

As I was studying Computer Science I met with the so called Hoare logic. Its main idea is that for each command/program you can define a precondition and a postcondition. These are logical expressions. Precondition must be true before starting your program. It is mainly checking if all inputs are in the correct range and so on. It can be of course also constant true, that means: there’s no specific precondition for this program. Postcondition must be fulfilled after running your program. Like your precondition is x > 0, your program is doing nothing else then y := x, then your post condition will be: x > 0 and x = y. With some predefined rules you can prove with methods of logic that your program is correct or not. It’s pretty easy in case of simple programs, but in case of complex programs it becomes quite complicated, that’s why it is really not typical to validate a program code in this way. It is a static code validation method anyway.

So I learnt it, passed my exam and forgot about that.

Years later I read about the so called SOLID principles and there was one called Liskov substitution principle. I had a flashback from my studies: “Hmm I have already heard it somewhere”. This principle is the following: “ if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program”. It is clear, but what does it mean in fact? It means the following:

• Preconditions cannot be strengthened in a subtype.
• Postconditions cannot be weakened in a subtype.
• Invariants of the supertype must be preserved in a subtype

Hmm, it sounds like Hoare logic and it sounds like something useful. At this point I read a bit more about Design by contract and what I learnt there gave me a much better understanding about how I should implement my programs in OOP.

I would like to show you the main concept.

Contracts of a class

We can talk about three different kind of contracts: invariant, precondition and post condition. Invariant is belonging to a class, pre- and post conditions are belonging to a method.

An invariant is nothing else than a restriction on the state of your class.  The state of your class is basically the value of your class variables. For example if you have a class for right-angled triangles your class variables can be: the length of a side, the the length of b side and the the length of c side of the triangle. These variables with their current values represent the state of your class. We know the rule: a*a + b*b = c*c in case of a right-angled triangle. That means if our class stands for right-angled triangle all values which are not fulfilling this condition are invalid, they are not representing a right-angled triangle. So this logical expression (a*a + b*b = c*c) can be your class invariant. This should be true in all cases. It will be checked: at the end of your constructor, at starting any of your class methods and at the end of your class methods. Next to that it is a good practise to keep you class variables private and reach them through setter and getter functions, so that your class can never get an invalid state which is not fulfilling the invariant.

The precondition of a method is a condition checked before starting your method. For example if you have a stretch function for your triangle which is having a parameter called factor your precondition can be that this parameter is greater than 0.

The postcondifition of a method. is checked at the end of the function, it is describing what you are expecting from your method. In case of the stretch function in could be something similar: a = old(a) * factor and b = old(b) * factor and c = old(c) * factor, where old means the value at the start of the method. Here it is also important that you need to think about the whole state of your class. So if it has attributes which should not be changed by the method it should be also specified in the post condition. For example if your representation has also a colour attribute than the post condition should be extended with: colour = old(colour).

Until now it is simple: each method has a pre- and a postcondition and the class has an invariant which is checked after construction and at the start and at the end of each function.

Contracts for sub classes

How does it change if your class has a base class?

Your class is holding the invariant of all of its base classes. So in case of one base class the following needs to be always fulfilled: invariant_of_base_class and invariant_of_your_class. So from a child class you can not break the invariant of the base class.

For example if the right-angled triangle class is derived from a triangle class, an invariant for the triangle class can be: a + b >= c (the sum of length of the two shorter side should be at least the length of the longest side). This invariant should be fulfilled also by the right-angled triangles.

Regarding pre- and post condition:

For an overridden function precondition can not be strengthened as the precondition in the base class. So it can be less strength (like instead of (a < 10 and b < 10) just (a < 10)) or the same as in base class.

For an overridden function postcondition can not be weakened as the postcondition in the base class. So it can be the same or more strength.

And this is called Liskov substitution principle, which is part of SOLID principles.

Maybe it is a bit complicated for the first time, but it says nothing else than: your subclass is a special case of your base class, so it should work for all inputs which are working with the base class and it should produce the same results as well.

Support of design by contract in programming languages

Using design by contract for your code is a defensive programming method, your program will have a runtime error in case of the violation of any contract (invariant, precondition or postcondition). That’s also usual that the check for the contracts is only activated in the test versions of your code and deactivate in the release version.

There are some programming languages, like Eiffel which are supporting contracts in a native way, but they are not really popular nowadays. For the today popular OOP languages (C++, C#, Java etc.) you can do your own implementation, it is also not too complicated or reuse an already existing library. For C++ Boost.Contract is a good choice. For Java there are several open-source solutions, like Oval or Contract for Java. For C# you can use Code Contracts. For Python PyContracts.

Summary

Of course I know that design by contract is not an often used way of programming and I think it is totally OK. On the other hand in my view this is a fast and easy way to improve your code quality and make yourself thinking a bit more about “what my code is really doing”. It makes also your code cleaner, because you will double check what should be really the state of your class and your pre- and postconditions are documenting the specification of your function as well.

I think even if you are not developing with this approach it is good to know about this way of programming and think a bit about your invariants, pre- and postconditions at implementing your classes to reach a better code quality.

Top programming languages for year 2018

Introduction

To choose the best programming language for a new project is never an easy task. There are thousands of programming languages and each of them has its own advantages and disadvantages. I often see some discussions at programmer forums like “Java is much better than C++” and “Python is the best programming language ever”. As I can see as a programmer: no programming language is better than an other one. You cannot set an order between them without the real context. And the real context is the project to be done. You can tell that “for this project Java is a much better choice than C++” and to be honest before starting a new project you always need to decide which language is the best choice for the project. To be able to do such a decision you need to analyse the project requirements. So for example if it should run on an Android Phone of course you would never choose PHP or if it is a web service then most likely C is not the best choice. You need also take into account what is the current knowledge level of the team which will work on the project. So if your team has a good experience on Java, but they have never worked with C++ then it makes sense to choose Java even if C++ would be more fitting for the project.

The popularity of the languages is constantly changing. There’s the so called TIOBE index, which is telling the popularity of a programming language at a certain point of time.

I think it is giving a good overview now at the start of the new year to check what were the most popular programming languages of 2018 and getting a brief overview about them.

1. Java

Java became popular at the start of the century and since that it is always taking any of the first two places on the list. It is an object oriented programming language, mainly used for desktop applications, web applications and mobile applications. Thanks for the Java virtual machine you can run the same application under several different operation systems. It is really a good choice for multiplatform applications. An other advantage is that there are millions of Java developers all around the world.

public class HelloWorld {

    public static void main(String[] args) {        
        System.out.println("Hello, World");
    }

}

2. C

C is really an old language from the start of the 70’s. Since that it is keeps on staying very popular, it is usually sharing the first two places on the TIOBE list with Java. C is a lower level programming language, good for direct memory manipulation etc. Nowadays it is mainly used for embedded systems where low level operations are needed and runtime is in focus.

#include

int main() {
 printf("Hello World\n");
 return 0;
}

3. C++

C++ is basically an advanced C. It is already more than 30 years old and it is usually on the 3rd or 4th place of the list. It’s main feature in comparison to C is the support of object oriented programming elements and the huge standard library which is supporting several algorithms, data structures and all other stuff. There were a lot of new features introduced to the last 3 versions (C++11, C++14, C++17) which added all the features which are needed by a modern programming language in 2018. It is a good choice for both low and high level tasks. In my view this is the Swiss knife of programming languages.

#include 
using namespace std;

int main() 
{
    cout << "Hello, World!";
    return 0;
}

4. Python

Python is a script language first released in 1991, but becoming really popular over the last years. Python is the best choice if you would like to reach fast results. Its language elements are making possible to code most of the common issues in several lines. Mainly used for rapid prototyping of algorithms and AI stuff. There’s a high variety of external Python libraries as well.

print("Hello, World!")

5. C#

C# was starting as the "Java of Microsoft". Like Java, it is also working with a virtual machine in the background, but for years it was supported only under Windows systems. Thanks for the Mono project it changed. Nowadays you can use it under almost all of the operating systems. It is a good choice for desktop applications, cross platform mobile applications (Xamarin) or web applications (ASP.NET). It is easy to use and it has a lot of external libraries. But don’t be surprised if the final result will be big and slow.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
                Console.WriteLine("Hello, world!");
                Console.ReadLine();
        }
    }
}

6. Visual Basic .NET

To be honest it was a surprise for me to see this language on the list. This language is also an object-oriented language targeting the .NET framework (just like C#) and it is based on the classical Visual Basic. It became popular during the last 3-4 years, most likely because of the multiplatform support by Mono project.

Module Module1

    Sub Main()
        System.Console.WriteLine("Hello World.")
        System.Console.ReadLine()
        End
    End Sub

End Module

7. PHP

The story of PHP started in the 90’s and it is mainly used for server side web programming. Around ten years ago it was much more popular, but in the meanwhile it got a lot of new concurrences, so it lost its popularity a bit. There are several frameworks based on PHP. On the other hand PHP has quite often a strange behaviour from language mechanism point of view, most of them are coming from the fact that it is weakly typed.

<php
  echo "Hello World!";  
?>

8. JavaScript

If PHP is strange, then JavaScript is stranger. Just imagine a language where (Math.max() < Math.min()) is true. On the other hand JavaScript is mainly used for client side web development. It has the big advantage that all of the popular browser engine are supporting it. That’s why it has no real concurrent. There are several framework built on the top of Java Script like Angular JS or JQuery.

Since some years it is also used server side web development thanks for the Node JS framework.

It is supporting object oriented programming with prototypes.

On more important remark: it has nothing to do with Java.

console.log("Hello, World!");

9. Ruby

Ruby is an object oriented programming language mainly used for web and application development.

puts 'Hello, world!'

10. Delphi/Object Pascal

Object pascal in the main programming language of Delphi. It is an advanced version of Pascal with object orient support. Earlier it was very popular for application development, that’s why a lot of old programmers are still using it, but it’s loosing its popularity constantly.

program ObjectPascalExample;

type
  THelloWorld = class
  public
    procedure Greet;
  end;

procedure THelloWorld.Greet;
begin
  Writeln('Hello, World!');
end;

var
  HelloWorld: THelloWorld;
begin
  HelloWorld := THelloWorld.Create;
  try
    HelloWorld.Greet;
  finally
    HelloWorld.Free;
  end;
end.