My Leadership Vision

Good and performant leadership is a critical component of any successful endeavour. I have been a leader most of my career; however, only in the last 12 months have I come to appreciate what being a leader is. A good leader is an expert at aligning their thoughts, behaviours, and morals with their authentic being. I believe it is through the conscious and cognitive process of aligning your being with the needs of your followers that dominates the efficacy of your leadership. I have identified four statements that I believe are the key to keeping oneself aligned with the values and behaviours of a truly Transformational and Servant Leader.

Vision is everything.

To lack vision is to invite chaos. Followers with a poorly defined vision cannot know where they should go. Inspirational vision underpins almost every aspect of good leadership. Without it, your followers are blind and cannot function effectively. No vision means no alignment, collaboration, strategy, or future. A leader must be inspirational and ensure that the followers have an articulated and purposeful vision supported by conversation, action, and positive role-modelling. Followers must have something to rally behind and believe in; failing to do so is a grave injustice.

Emotional Labour is everything else.

It is equally vital that a good leader role-models mindfulness and managing their emotional labour. Great leaders are aware of their own emotions and the emotions of their colleagues and can temper them before they become destructive. Failure to regulate one’s emotions can lead to a breach of trust and may undermine the faith your followers have in you and your vision. Leaders help their followers do the same.

Delegating tasks creates followers but delegating authority creates leaders.

Leaders have a duty of care to their followers. Part of that duty is to create an environment where they get to exercise and practice their leadership traits and skills. An employee is more likely to emotionally invest in the leader’s vision if they feel as though they are empowered and trusted to excel. By allowing followers the freedom to become authorities in their work, you create an environment much more favourable to innovation and success. As followers become leaders themselves, supported and armed with a clear vision, they will inspire others and become powerful agents of positive change.

You can control, or you can lead, but you can’t do both.

You can leverage your positional power over a follower to get them to do something the way you want it done, but to do so is not leadership. Effective leadership means trusting your followers to know your reasons for your decisions. If you cannot explain your rationale to your followers, they may lose faith in their purpose and your competency to lead them. Trust that your followers want to do what is in the collective best interest, and you must not do anything to undermine the trust they’ve put in you. Leadership is not demonstrated by wielding power but by increasing the power of those following

Changes to ActiveRecord::Dirty in Rails 5.2

A while ago I wrote a small post on how to manually mark an ActiveRecord model attribute as dirty. Since Rails 5.2 has some fundamental changes to ActiveRecord::Dirty.

Specifically, three methods have been deprecated and changed in 5.2. These are:

  • attribute_changed?
  • changes, and
  • previous_changes

Using these methods in a Rails 5.2 application will now result in the following message (or a variation of it) being outputted in your logs:

DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead.

attribute_changed? and changed? remain the same when called within a before_save callback. But when used in an after callback there are new methods you should use instead, which the Rails Core Team believe should reduce code ambiguity of changed? before saving to the database: will_save_change_to_attribute? and has_changes_to_save?

In summary, if upgrading to Rails 5.2 and after modifying an object and after saving to the database, or within after_save:

  • attribute_changed? should now be saved_change_to_attribute?
  • changed? should now be saved_changes?
  • changes should now be saved_changes
  • previous_changes has no replacement, since the behavior for it changes.

And (optional; less ambiguity, more readable, but longer) after modifying an object and before saving to the database, or within before_save:

  • attribute_changed? should now be will_save_change_to_attribute?
  • changed? should now be has_changes_to_save?
  • changes should now be changes_to_save

NotImplementedError Must Have Battered Wife Syndrome

I’ve been doing something very wrong my whole life.  I think it’s time to confess and seek help.

You see, like so many developers I see the NotImplementedError class in various languages and think, to my self “I haven’t had a chance to fully implement this class, so in my methods that my colleagues call that I didn’t finish yet, I will raise that exception to let them know.”

I am ashamed of myself.  And it’s time to get help.

You see the actual purpose of the NotImplementedError (as defined by the Ruby docs) is:

Raised when a feature is not implemented on the current platform. For example, methods depending on the fsync or fork system calls may raise this exception if the underlying operating system or Ruby runtime does not support them.

ERMERGERD!  I am a terrible person. Abusing this error class just because  my sub classes cannot meet the contractual obligation of the super class.

And I know I am not alone.

So whats the best practice, then?

Well, in Ruby’s case it turns out the answer is super simple; don’t raise an error at all! Instead, document the expectation and if a subclass fails to meet it a NameError, or often its subclass NoMethodError, will be raised automatically.


Converting TEXT columns to JSONB in PostgreSQL

Recently I had a text field being used to store JSON data from my web application. I hadn’t yet discovered the amazingness of the PostgreSQL JSONB datatype.

JSONB is an amazing datatype because Postgres understands how to query the structure and the keys and values can be indexed.

So if you have a text fields you want to convert to JSONB (provided the existing data is in properly formed JSON already) You can change the datatype and convert the existing data using this simple SQL command:

alter table tbl_name alter column col_name type jsonb using col_name::JSON;

You may be inclined to covert the text using the to_json function like: ‘USING to_json(col_name);’ – BUT DON’T DO THAT! What happens with that is you get a single string encapsulating the valid JSON, containing your JSON. Effectively a double-encoding bug.  The former (casting the column to JSON is the correct way).