Boss vs Motivator

André Jacques — Sun, 14 Apr 2019 05:49:25 +0000

My take about leadership

Disclaimer

I want to start this article by saying this is only my opinion and it is not, in any way, enforceable to other kinds of people. I want to emphasize that I'm talking about competent leaders.

Context

Let's say we have a team of five or six members, working on different projects throughout the year. It doesn't matter if that team is agile or not, what matter is that someone will be holding The Leadership, meaning that he or she will steer the team in the same direction. I have encountered two types of those people, the Boss and the Motivator.

Commonalities

The Boss and the Motivator usually shared some traits as such:

they both value the opinion of an expert strongly;
they both receive great respect from their peers;
they both take decision they believe are for the best interest for the project success.

Distinction

The difference is basically how those leaders take decisions.

The Boss will usually weigh in the pros and cons and take a decision by him or herself and may do so over expert opinion. With a boss, you know where you are going.

The Motivator will usually take expert opinions first, or at least the opinion of concern members of the team. With a motivator, you have a bigger voice.

(NOTE: usually doesn't mean always).

Boss

What I like

I generally enjoy working with bosses when they have a lot of experience, counting in tens of years. At that point, they generally have a very well-tuned vision of how a project should go down to. They know the drill, the pitfall and know how to explain why some opinions have been left out. I must say that in my career, I might have worked under two or three great bosses, out of a dozen.

What I don't like

The main drawback I have with bosses are when they are managing a kind of project they never had before. I once had a 30-years of experience in C++ developing different tools, being sent on a Web application in PHP using an MVC Framework. I kid you not when I say it took a month to explain to that guy that memory management is not really a thing in PHP at that point and also that CSS is not really the forte of software engineers.

Motivator

What I like

I generally enjoy working with motivators when they first have some experience in at least half the concept needed for the project. Those I really love working with were those who put a lot of hours in order to fetch up the most important information on the domain they have little knowledge. They are dynamic, meaning that they can try something (prototype), and if it does not work, go the other way. I usually feel more part of a team, with a voice that is being heard.

What I don't like

At some point, a motivator needs to take decisions, and sometimes they need to be made against the majority. This is where the line between a good motivator and a bad one is: their ability to make that call. I had so many of these people that literally, in a span of three months, start to point A, went to point B, to come back to point A without even noticing it.

What kind am I?

My career span over 10 years, so I like to think about me as a motivator. I had many projects where I was the manager and really liked to listen to what people had come up with, making propositions to fill the gaps between two concepts, and see the final product working has expected. I do believe a boss would have made the same job faster, but since only the experience will get you there, better be a good motivator.

What are you?

I would like to see what you think, what kind of good leader you have encountered, but the most important is how do you see yourself?

Override `equals` method in Java

André Jacques — Tue, 10 Apr 2018 20:28:43 +0000

The == operator is a false friend in Java. It works properly only on primitive and will make you cry if you used it on any other referenced Object, for the most part.

The basic

As a rule of thumb, every equals method should start like this:

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }

        if (!(obj instance ClassName)) {
            return false;
        }

        // custom logic here
    }

The ClassName should be replaced by whatever type your class is. After that, I usually apply one of the following solutions.

The class as only one relevant field

In the case that the class has only one relevant field, I will return automatically either the == operation (for primitive) or the equals of the field.


public class Person

    private String fullname;

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }

        if (!(obj instance Person)) {
            return false;
        }

        Person converted = (Person)obj;

        return this.fullname.equals(converted.fullname);
    }

}

The class as many relevant fields

I usually have two options here.

The `toString()` contains all the relevant field

There is no need to add complexity in a class if something can help you with your code. There is no need to test for instanceof since toString is defined everywhere, and no need to cast for the same reason.


public class Person

    private String firstname;
    private String lastname;

    @Override
    public String toString() {
        return this.firstname + " " + this.lastname;
    }

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }

        return this.toString().equals(obj.toString());
    }

}

It is not mandatory to be the toString. Sometimes other methods do the same job. You need to keep in mind that other methods will require to test for and cast the object before comparing.

There is no method to help

In that situation, I will usually cascade if until the last relevant field.


public class Person

    private String firstname;
    private String lastname;
    private Date dob;

    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            return false;
        }

        if (!(obj instance Person)) {
            return false;
        }

        Person converted = (Person)obj;

        if (!(this.firstname.equals(converted.firstname)) {
            return false;
        }

        if (!(this.lastname.equals(converted.lastname)) {
            return false;
        }

        return this.dob.equals(converted.dob);
    }

}

I know that I could probably do something like this:

    return this.firstname.equals(converted.firstname) && this.lastname.equals(converted.lastname) && this.dob.equals(converted.dob);

I don't really like this because it is mainly hard to read. I know that Java will probably optimize the bytecode with these kinds of statement, nevertheless, I believe that in most cases, it won't really matter.

Don't forget that, to be able to use HashMap and stuff, you also need to override the hashcode. Here are the main rules:

If 2 instances are equal, then both hashcode MUST BE equal;
If 2 instances are not equal, then both hashcode SHOULD NOT BE equal.

A good hashcode algorithm that lives up to the second rule will make the use of HashMap and HashSet more efficient.

Forem: André Jacques

Boss vs Motivator

My take about leadership

Disclaimer

Context

Commonalities

Distinction

Boss

What I like

What I don't like

Motivator

What I like

What I don't like

What kind am I?

What are you?

Override `equals` method in Java

The basic

The class as only one relevant field

The class as many relevant fields

The toString() contains all the relevant field

There is no method to help

The `toString()` contains all the relevant field