The First Myth Of Management Is That It Exists

My Personal Beliefs on Management


I often like to quote the age-old adage that 'the first myth about management is that it exists'.

Rather I view the role of manager as a facilitator, almost equivalent to an umber grunt. The manager's job is to listen and eradicate blockages with the ultimate goal being to get better utilization out of existing resources. Good managers realize they work for their employees, not the other way around. Micro managing is bad; mentoring is good. Some of my fondest success stories are hiring interns who gradually became full time productive coders who may even out grow the job and leave, but if they want to work with you again, that is the best compliment you can get.

Firing employees is not management. Anybody can do that. Rather converting an unproductive resource to a productive resource is the goal. Obviously part of this requires being able to measure performance but it is deeper than this. Without getting too psychological, programmers are basically artists and they come in all shapes and sizes. Some like to be challenged, some not so much. This is not necessarily a bad thing. Some people love to be given the impossible and get bored at a task they know they can complete in a short period of time while others thrive on being able to quickly complete a task and move on to the next. Some coders produce consistently on a daily basis, others go through down periods where their output is barely discernable but then bam, they go through a period where they produce some fantastic results in a short period of time. A manager's job is to understand the individuals as well as to be able to measure their performance and create a plan of success based on the individual's unique characteristics.

I also believe in positive versus negative reinforcement. Most people respond to accolades and atta'boys better than having their mistakes amplified. Good programmers enjoy the ability to show others how creative and intelligent they are. They like to share their success stories far better than their failures even though we can all learn from our failures. It is more productive to allow them to surface their mistakes and show how they eventually got on the right path rather than to lament the lost time they spent going down the wrong path. Subtle peer pressure is far more effective in motivating coders. I can't think of one time a boss yelled at me and my take away was, boy do I want to work harder for that guy.

While business is not always a democracy I do believe that consensus works better than trying to impose one's will on others. An example of this is the conventions surrounding an organization's code base. The placement of curly braces, the level of indentation, the design patterns used, etc are better to come from group consensus rather than some big dog imposing their will on the team. Understanding that while 'this is how we have always done it' produces consistency, maybe 'this is a better way to do it' is an important part of constant process improvement and constant process improvement should always be a goal since perfection is a myth.

A good manager should always be trying to mentor their co-workers and encourage them to communicate what they like to do and what they don't like to do. In this way, you can avoid giving folks tasks they are not motivated to accomplish. At Amazon I worked with tons of project managers who were Harvard MBAs who considered the work they were doing below their dignity. As a result a lot of these project managers did not do a very good job of managing their project. A healthy engineering organization in my mind (which is actually anti-Amazonian) is not a bunch of PHDs who are gifted geniuses but rather a mix of younger coders who are learning on the job, mid tier guys who just love doing the work, and guys who are already at the top of their game. In this way you have resources who are not always doing something they consider grunt work. One person's grunt work is another person's challenging and fun task. Part of a manager's job is figuring this out.

Finally, on a personal note, I like fungible assets. This allows me to run a Kanban type operation rather than strictly Agile. In Kanban, workers pull the next request from the board and can often select which task they would prefer to do. While this is not always possible it is a goal. To this end I like paired programming where periodically, coders of differing skill sets are paired with the goal being cross training. Maybe a front-end coder and a back-end coder pair up on a task with the goal being they will cross-pollinate. Over time you may end up with two coders who can both do front-end and back-end work which means at some point in the future someone can take a vacation and the organization doesn't come to a screeching halt. Kanban is also designed as a ground up constant process improvement discipline where changes in how things are done are initiated by the actual people who do them rather than some ivory tower type who may or may not get it.

Obviously all this takes time to develop and is based on the concept that an organization is growing and evolving over time. Change can be disruptive in both directions and organizations sometimes just have to get work done quickly in order to meet higher order business objectives. Keeping the lights on should always take priority but it doesn't mean constant process improvement needs to stop. Knowing how to balance these seemingly competing priorities and when to take the time to pay down technical debt as well as when to move on to new technologies is part of what goes into effective management which as my opening quote claims, doesn't exist :-)

Unemployed Again and the Javascript Fat Arrow

As is often the case when I become involuntarily unemployed I find myself with free time on my hands.  I was recently working as contractor for Hilton Hotels indirectly for a recruitment agency known as Apex. What I learned from this experience is you should read the contract. In this case it simply said if I want to quit I must give them a two week notice but if they no longer require my services they can just tell me that day. While they weren't that draconian in this instance (they told me Thursday that the next day Friday would be my last) I still don't view this as an equitable exchange and so in the future I will be sure to amend the contract one way or the other or just not take the job.

But I digress. Having free time on my hands allows me to catch up on the new stuff I am normally missing out on because when I am working full time I very rarely have free time on my hands and that which I do is typically consumed by my wife. For some reason this woman wants to constantly be around me and consume my time with small talk and other trivial stuff so unfortunately when I am working I have little to no time to catch up on what's new and exciting with my favorite tools.

Such is the case with Javascript because even though I have been using Javascript productively since around 1999, it seems I am not aware of the foundational concepts on which it is predicated and the way those concepts have been expanded and used. It is one thing to know a language such that you can produce working code. It is far different to have an academic understanding of the language. I learned this several years ago when I befriended a professor at the local university. He was teaching Python and while I had been using Python every day it was apparent he knew a lot more about Python than I did even though he had never written a line of Python that was used in a production environment.

Anyway, back to the topic at hand, the 'fat arrow'. While some might say the fat arrow is basically syntactic sugar for function declarations this would be doing a great disservice to the fat arrow. In fact it differs from standard Javascript function declarations in a variety of ways.

A) Syntactical Differences
First, the syntactic sugar.

function someFunc() {          // decalre a function with no arguments
const someFunc = () => {       // declare a function with no arguments

function someFunc(props){  // decalre a function with a single argument
const someFunc = (props) => {  // declare a function with a single argument
const someFunc = props => {    // also declare a function with a single argument

// and finally we have this parameter free syntax
const things = [{name:'thing1', price:'10'}, {name:'thing2', price:'20'}];
console.log(things.map(prices => prices.price));

B) Use as a Constructor
Another difference between functions defined using the fat arrow and standard Javascript functions is that functions defined using the fat arrow may not be used as constructors.

C) Use as a Generator
Functions defined using the fat arrow syntax can’t be used as generators. Using the yield keyword in a function defined using the fat arrow will throw an error.


D) Implicit Return Value
When using normal functions there is no implicit return value. You must use the return statement to return a value from a function defined using the standard function syntax. Functions defined using the fat arrow syntax CAN POTENTIALLY have an implicit return value.

const someFunc = () => 'boo'
someFunc()      // returns 'boo'

For an arrow function to have an implicit return an expression is required. But in JavaScript, many language constructs are not expressions but are statements. In fact, for a function defined using the fat arrow if it has a statement in its body it must be defined using curly braces and as soon as you have curly braces surrounding your function body, returns are no longer implicit – for either statements or expressions.

const broken = () => { 'who cares' }
broken()       // returns undefined
const thisWorks = () => { return 'boo who' }
thisWorks()     // returns 'boo who'

Our old pal the ternary operator allows an expression, and as was previously mentioned an expression can be returned.

function ternary() { return true ? 'Yup' : 'Nope' }
ternary()     // returns 'Yup'

E) Return Values
If you want to return objects from an arrow function, you need to wrap them in parentheses.

const details = name => ({ firstName: name }); // will return an object
const details = name => { firstName: name };   // will return undefined

Not so using the funnction syntax to define a function.

function syntax1(){
  let someObj = {first:'Joe', last:'Blow'};
  return(someObj);
}
function syntax2(){
  let someObj = {first:'Joe', last:'Blow'};
  return someObj;
}
console.log(syntax1()); // prints { first: 'Joe', last: 'Blow' }
console.log(syntax2()); // also prints { first: 'Joe', last: 'Blow' }

F) This is Now Lexically Scoped
Finally, the meaning of 'this' is different for a function defined using the function syntax versus a function defined using the fat arrow. Instead of trying to describe what 'lexically scoped' means I'll simply show you an example I saw somewhere which I copied (sorry to the author but I forgot the link and I can't seem to find it again). Without just showing you the code though I'll try to explain briefly using my own experience.

Before the fat arrow, 'this' referred to the thing you were running, so to get the desired behavior in a function that was passed to the timer I would have to use the trick of using a closure to define a variable (some like myself would call this variable 'self' or 'that') and then we would get the desired behavior. Being the chucklehead I am I had no idea Javascript functions had a default function called 'bind()'. While the closure trick still works with normal functions it is no longer necessary if you use the fat arrow to define your function. The following code which you can simply copy and paste into a file on your desktop which you then just double click on to see it in action in your default browser should demonstrate the concept better than a bunch of words.

<html>
  <head>
    <script>
// globally defined this.i
this.i = 100;
var counterA = new CounterA();
var counterB = new CounterB();
var counterC = new CounterC();
var counterD = new CounterD();
// bad example
function CounterA() {
  // CounterA's `this` instance (!! gets ignored here)
  this.i = 0;
  setInterval(function () {
    // `this` refers to global object, not to CounterA's `this`
    // therefore starts counting with 100, not with 0 (local this.i)
    this.i++;
    document.getElementById("counterA").innerHTML = this.i;
  }, 500);
}
// manually binding that = this
function CounterB() {
  this.i = 0;
  var that = this;
  setInterval(function() {
    that.i++;
    document.getElementById("counterB").innerHTML = that.i;
  }, 500);
}
// using .bind(this)
function CounterC() {
  this.i = 0;
  setInterval(function() {
    this.i++;
    document.getElementById("counterC").innerHTML = this.i;
  }.bind(this), 500);
}
// fat arrow function
function CounterD() {
  this.i = 0;
  setInterval(() => {
    this.i++;
    document.getElementById("counterD").innerHTML = this.i;
  }, 500);
}
    </script>
  <body>
    Bad Example. This code is actually broken:<span id="counterA">0</span>
    Using a closure: <span id="counterB">0</span>
    Using 'bind':<span id="counterC">0</span>
    Using the fat arrow: <span id="counterD">0</span>
</html>

So now you know everything I know about the fat arrow.

Critical Review of 'Thinking and Destiny' by Harold Percival

'Thinking and Destiny' is first and foremost a tough read at over 1,000 pages. If you were to start with the philosophy of Nietzsche and then combine it with Theosophy, Hinduism and Buddhism you would be half way there. Where this philosophy separates itself is in its addition of Masonic numerology to describe the afterlife/consciousness and structure of the The Realm of Permanence/Heaven/Nirvana. It is a creative, honest attempt to explain the meaning and cycle of life. 

Personally, I think some of the beliefs are a bit tough for me to accept, but who knows. Percival seems to indicate this book was dictated while he was in an altered state, which is fine. It certainly is deep enough and does present some unique concepts. It is the life's work of a highly educated, dedicated person who appears sincere in his beliefs. Much like Szekely who translated the 'Dead Sea Scrolls' and then set up an organization to make sure they were available for $1 in perpetuity, Percival set up 'The Word' foundation to make sure this book would be available for free (download it here https://thewordfoundation.org/wp-content/uploads/2016/09/Thinking-and-Destiny-by-Harold-W-Percival-fourteenth-printing.pdf) forever. 

When you think about it, 1,000 pages is actually economic when compared to how much you would have to read to get the main concepts of Nietzsche, Theosophy, Hinduism, Buddhism and Freemasonry. If reading this much is not your thing simply watch the movie 'What Dreams May Come' and you will get most of what this book is about. Alternatively, reading the book 'The Path' will accomplish much the same. All things considered I would recommend reading this book. 

True AI

Some in the programming community consider code that dynamically alters the weight of its attributes in its calculations as AI, some do not. I fall into the latter category. To me, true AI is code that generates new code that the old code uses in subsequent operations. In this way we can say the machine learned. 

While I do not expect this to be realized in my lifetime what I do believe is possible is the beginnings of this process in which we substitute human interaction for machine learning. When required, a human programmer creates a new library entry which the old code can now learn to use. Human assisted machine learning (HAML). 

More NLP

While the syntactic parsing of language is almost mechanical in nature these days, using that data to actually do something of value requires we break it down further into semantic units. These units which I call a concept are standard objects with dynamic boundaries. The fact that the boundaries change is of no concern since the more difficult work is to derive meaning and structure from the syntactic input. 

To help with this we rely on verb conjugation. Clearly the statement 'I am here' carries a far different meaning than 'I was here'. What is not so obvious perhaps is noun conjugation, 

We all have a name. While our name by itself may not be indicative of anything, the way it is used may often be used to help derive intent from a statement. 

In English it is not uncommon for a name to have several variants with each carrying a different connotation. For example, Robert, Robbie and Bob. My name is Kenneth but very few people call me this. When I am in a formal environment like the DMV people call me Kenneth. Outside of a formal environment this form of my name is used to convey a feeling of dominance or authority. My second grade teacher called me Kenneth. More often than not I am referred to as Ken which is what an acquaintance or coworker might call me and Kenny is what my family or close friends call me. 

So in much the same way we can use verb conjugation to derive context, so too we may do with proper nouns. It should be noted that closely associated with this is the usage of pronouns to also aid in the determination of intent. My second grade teacher called me Mr. Smith when she was angry at me. If in a the middle of interpreting a document a person stops referring to someone as Joe and starts using Mr. Jones this too conveys information we can use to derive intent and use this to alter context. 

Intent Versus Context

While the syntactic parsing of language is almost mechanical in nature these days, using that data to actually do something of value requires we break it down further into semantic units. These units which I call a concept are standard objects with dynamic boundaries. The fact that the boundaries change is of no concern since the more difficult work is to derive meaning and structure from the syntactic input.

To help with this we rely on verb conjugation. Clearly the statement 'I am here' carries a far different meaning than 'I was here'. What is not so obvious perhaps is noun conjugation,

We all have a name. While our name by itself may not be indicative of anything, the way it is used may often be used to help derive intent from a statement.

In English it is not uncommon for a name to have several variants with each carrying a different connotation. For example, Robert, Robbie and Bob. My name is Kenneth but very few people call me this. When I am in a formal environment like the DMV people call me Kenneth. Outside of a formal environment this form of my name is used to convey a feeling of dominance or authority. My second grade teacher called me Kenneth. More often than not I am referred to as Ken which is what an acquaintance or coworker might call me and Kenny is what my family or close friends call me.

So in much the same way we can use verb conjugation to derive context, so too we may do with proper nouns. It should be noted that closely associated with this is the usage of pronouns to also aid in the determination of intent. My second grade teacher called me Mr. Smith when she was angry at me. If in a the middle of interpreting a document a person stops referring to someone as Joe and starts using Mr. Jones this too conveys information we can use to derive intent and use this to alter context.

The Collective

There only is and there only isn't.

You are the collective.

You know all but understand niegh.

You are both here and there.

When you die you will remain.

Never and forever.

All will be as it was,

through constant change.

Self contained karma,

defined by the collective.

Defined by your actions.

Your net effect is always zero.

What you did less what you didn't.

Who you harmed less who you saved.

For it is always yourself. 

Though some occupy more 

None occupy less. 

We are all equal yet all different.

Individually we know nothing

Collectively we know everything.

Accomplishment is a collective expense

and a collective benefit

because you are the collective.