This first environment requires that the employees constantly update their managers. Every detail they perform they need to send to their superiors and only then the managers (from now on I will call them overhead in reference to Dilbert) will be convinced that the employees are doing their job and doing actual work. The problem of course lies in the fact that you only have to give the update to the overhead and then all is well in the world. The actual work does not need to be done, as long as you communicated about it. It all boils down to the fact that the overhead does not trust the employees to do the work. So in a constant feedback loop if there is no update that means they are not working and therefore there is a constant positive reinforcement of the negative image. Onward to the next environment.

The other or second environment is one where you do not have to give constant updates to the overhead but instead they inform periodically with the employees about the progress or status. This of course boils down to the fact the overhead trusts their employees to do the work and in a constant feedback loop there is positive reinforcement of the positive image they have of their employees. Every time they ask are you hard at work if the answer is a resounding yes and you show actual progress, will make the overhead happy. If you say yes however your work is not up to par, the overhead will not be happy and can have a normal conversation with the employees.

Now for the statement that you can only thrive in one or the other. If you are of the type to constantly spam your managers you will thrive in the first one, but in the second one you will not. The overhead in the second one will find it annoying that constant updates are being sent and will view it with suspicion even though you might be doing the work. If you are of the type to never send updates to the overhead then in the first environment you will not thrive as they think you are not working but in the second the overhead will constantly get positive reinforced image of you as a hard worker. So far I have found that either you do the work and not inform whoever is your superior or you do not actually do a lot of work but you communicate a lot about it.

For me personally I cannot thrive in the first environment. I just sit down and do the work and I expect everyone around me in the company to do the same. We are all there to do our job and that is what I assume everyone is doing. If I find out someone is not doing their job it is quite simple, you are off the team. In contrast if you are doing your job I am very happy because I get that image constantly confirmed. I think it all has to do with trust and your outlook on work ethics of other people. Also for the couple of times there is not that much progress being made or I find that someone is starting to become complacent, then you can have a normal conversation built upon the experience that that is not the norm. It is easier to spot when things are difficult as well. As you can detect it quite easily by seeing that progress is slower than usual for example. In the first the updates about higher workload and pressure generally go unnoticed in the big pile of status updates and it is more difficult to act upon it.

* For those few instances, hardly ever.

#devlife #thoughts

So that had to change and in came CSS. Now you could better style the webpages. HTML for structure and CSS for look and feel. Perfect. However, this all was still static. It would be nice to add something to it that could dynamically update a page without reloading or just fetch data dynamically. In comes JavaScript. So we got the holy trifecta, HTML, CSS and JS.

Nowadays though, they feel everything should be able to be done from within JS ?!?!?!?! That is what React feels like to us.

render( {}, { todos, text} ) {
    return (
         <form onSubmit={this.addTodo} action="javascript:">
             <input value={text} onInput={this.setText} />
            <button type="submit">Add</button>
            <ul>
                { todos.map( todo => ( <li>{todo.text}</li> ) ) }
            </ul>
        </form>
  ); 
}

So we just wrote JS that contains HTML that contains JS that contains HTML. That has got to be the ugliest way to write HTML.

In addition to all this, is the fact that React is a library . It is not a framework . Always a fun question to ask during interviews, what is the difference between them? Well a library is code you use, a framework uses your code. That might sound vague, but in essence this is correct. You would use code from a library that does something specific. For example query DuckDuckGo and return the first result. A framework is something that is built for you to place your specific code in but it handles everything else. Angular is a framework in contrast to React.

What we like about Angular is it splits everything up nicely. You have HTML files for the structure, (S)CSS for the styling and then JS for making it dynamic. Although you only provide your code, Angular makes sure it works. There is a whole bunch of extra layers around it you don't see and know about in order to make it all work. That is beauty.

In the similar line exists the Polymer framework, from Google. It is based around the idea of Web Components and uses the <template> and <slot> tags from the HTML5 spec. Definitely worth a look.

The other issue that arises from using a library in contrast to a framework is that you have no clear same structure. You are left to choose your structure. However you want, as long it works it will be okay. In Angular you don't have that luxury as much and that is why we like it more. It is less gun-ho and cowboy style compared to React. You have to follow the structure they dictate in order to make it work. That means Angular codebases over all are predictable, uniform and that in turn makes it so Angular developers can switch projects relatively easily. In React we don't have that guarantee, so it is wildly different. Unless you had a disciplined dev, the odds are some corners were cut or some breaking away of the mold was done in order to make something work.

So our advice, write HTML, CSS and JS separately and do not try to smoosh them all together. Along a similar vein I will leave you with this.

#devlife #devops #thoughts

Our typical team will contain some software engineers, a team lead, some testers and a project manager.

Democracy

Let us get the easiest one out of the way first. This form is based on equal voting among the population. In our team it means everyone gets a voice and decisions are made using referendums. This means there will be a proposal with some outcomes to vote on, does not have to be a yes or no question, and then everyone gets to vote. Whatever the majority votes that will be the direction to head in.

This form will be beneficial when you have a lot of experienced people. At least the majority of them should be experienced. Everyone brings some point of view to the table and that will make discussion and these votes meaningful. It does not work if there is a polarization in the team. Be mindful if the team is experienced but headbutting a lot then this form won't work.

Oligarchy

This form of government consists of the ruling of a few that have power. Mostly persons or families. If we stick with families for a moment we could say only the most senior of their kind can operate. So the team lead, project manager and senior tester. They make all the decisions.

This might work if the team is somewhat bigger and you only have a couple of all round experienced people that happen to be distributed somewhat evenly among the coders, testers and project management. The advantage to this form is that a select few bear the responsibility and accountability for the success so if they are all well aligned then it will work out great. The disadvantage is that they can all have the same blind spot and therefore something might go wrong because of it.

Technocracy

This form of government consists of having the most expert in their field on the position and making decisions. Relating this to our team you will defer the decisions on infrastructure to most expert infrastructure person, the decisions on architecture to the most expert in architecture and so on. Regardless of position. This works really well in a small to mid sized team where there might be a lot of persons that are well versed in a lot of different aspects of software development. This also works when there are a lot of experienced/senior staff on the project to maximize the output and also give everyone a meaningful role and responsibility. Divide and conquer will be applied to the different topics and it is easier to make a project in to a success knowing the respective expert is put to great use.

Dictatorship

This form can also be seen as despotism, where only a singular figure holds the complete authority. This system might seem wrong, as it feels wrong. However it might work if the team is really really small with a few people and one singular person takes all the decisions. This breaks when the team is bigger than a particular size or when it becomes multi-disciplinary.

Meritocracy

This form of government gives power to those based on talent, effort and achievements. This seems closely related to the technocracy but it differs in one subtle way. This one does require you to be an expert, just have a good track record. This informal one works the best in young teams and ones where trust has been established. If you take a look at what a person has done rather than the statistics on their resume and also how they come across it might be that a junior is put on a singular task that is well within their capabilities. This is the most difficult to sustain though as talent, effort and achievements are a movable target and it shifts. Therefore the responsibilities in the team should shift and most people are not comfortable giving up a position of power.

Anarchy

This form of government means there is no form of government and there is an active rebellion against hierarchy. There is no formalized structure in place, no accountability nor are there protocols or processes in place and it seems there is no responsibility. This form again might seem to be a bad thing, not one to strive towards, yet if you have a team of people that are intimately familiar with one another you might not need any formal protocol. The work gets done and everyone feels equally responsible to bring the project to a success. Decisions get made and automatically trusted by the others and there is always the immediate feedback as everyone openly communicates everything to everyone else.

This form is dangerous as it is successful whenever everyone is on point, but a couple of missteps and you are heading into domino effect territory that can lead to catastrophe.

Theocracy

This form of government actually puts a deity in place as the leader. The laws of the religion in question are the laws and there are people in place to enact those laws and make sure it is all done proper with regards to the religion.

This form might seem ridiculous at first and it might be as such, but just think of the people that hold Agile in high regard, or Scrum, or Scrumban or Kanban or any other such thing. Maybe a language, Java or a framework like Phalcon. It does not matter what is placed at the deity level but all follows from it and everyone has to be a zealot to make it work.

This can work successfully if everyone is a zealot and is on board. Just make a cult of things and attract the same minded followers and a theocracy as your form will work excellently.

#devlife #thoughts

We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.

This ties in with the so called hype cycle. That cycle has five phases starting at inflated expectations through disillusionment arriving on the plateau of productivity. The thing to learn is how to skip all these phases and arrive at the end immediately. I hope I will give you some insight on how to approach this.

The first thing is the most difficult one. Not to get excited at the new shiny toy that is so alluring and mesmerizing that you drop all reason and you just feel like this must be the greatest thing on Earth, how can we ever live without it now that it is here. Just calm yourself, take a few breaths and try to work out the following question :

What problem does this new piece of technology solve or is it trying to solve?

That question will leave you aside from the how and what and get you to the why. That is the most important question you need answered before you can evaluate in the most objective way possible whether or not this new piece of tech is for you, is good, is great or simply not worth your time. Or maybe, just maybe, it is not good at all. If you read my post about React for example, I do not think it is great at all. Not at the beginning and not now. The reason for it is the problem it tries to solve. That particular problem is not a real problem and furthermore it has already been solved by IETF in regular HTML5 spec coupled with the TS39 spec for JavaScript. You already had a Shadow DOM which could be used for self contained apps. The concept of a Virtual DOM already existed and if you needed structure in the front-end development world then Angular did a far better job at that than they did. Well maybe not AngularJS specific, but these days yes. So why did people use it? Because Facebook made it and uses it and therefore it is the shit. Same reasoning can be applied in reverse, that company uses it well then therefore it must be bad and I will never use it because reasons.

That is the other thing to look out for that feeling or sensation that everyone is using it because everyone else is using it. There are certain things that have just become best practices, these are learned through experience and failures, a lot of failures in most cases, and therefore are considered to be quite good and that is why everyone is using it. It is on a good foundation. If you can not answer why you are using a piece of tech with some solid good clear well-founded reasons then maybe you should not be using it.

Again the question to the answer why is very important to solve the problem of piercing through the illusions. Just like a real illusionist where you usually stop at the how does he do it, it is better to focus on the why does he do all these actions if you want to stop being fooled.

#thoughts #devlife

The hypothesis came to me when having to be forced to work with Kubernetes and Hyperledger. They are both tools made using Golang. Therefore it touches the Go community and as I underwent my athloi, like Heracles and Theseus, I faced a monster and conquered it.

What is it?

So first things first, what is Go or officially Golang? Well it is a language designed and maintained by Google. What is special about it ? Well it offered in the beginning a very nice way of doing async programming through the usage of so called coroutines and it called these goroutines. How cute.

Syntax

It does not feature a great syntax. Especially not compared to Python. I find the syntax to be unclear and wonky at best.

Packaging

It did offer another part better than Python. You could compile a binary and that binary would run automatically on any system that shared the same architecture. So you compile once for x64 and it can run on Windows, Mac and GNU/Linux ( I don't want to upset RMS ) provided they run on x64 hardware. So like everything else in life it matters most how you look and how you sound and not so much what you actually say.

Hypothesis

The hypothesis is difficult to formulate using the scientific method to make it exact and concrete yet I can link it to another phenomenon and I think that will place it nicely in the same category and labels.

Imagine if you will you start to learn the new tech that got hyped and sold to you by a company with a big name and a reputation for making things that are smart. During the first moments you feel like you are not getting it actually and not fully understanding it. The documentation does not help as it seems to be written by people that fully understand their own product and expect others to also fully know the product already. You see where that can go wrong. How are people supposed to learn the new thing when there is no good path to learn it other than just try and bruteforce your way through.

At the same time you cannot accept the fact that you are someone not getting it because the company sold it so it must be true. Other people are saying it is amazing so why are you not getting it. Surely it is you so you start to say to yourself it is amazing. Then you commit more time and you slowly but surely and steadily learn the new tech. You find it severely lacks the potential the hype sold you. If this sounds familiar it is because it is called the hype cycle and I wrote a post about it on how to make it not so impactful and give you tools to pierce the illusions.

Now though you spent some time on it and it is incorporated into your stack you cannot turn back. You are forced to commit or admit your mistake and that will hardly ever happen. So you can see how it all works. People adopt this tech and then by utilising the technique described above they are forced to stay and use it. I read a post about AMP for example. It is a good idea but nothing major, however if you don't use AMP then your content won't rank in the result pages, the so called SERPs. You cannot back out now anymore. Same goes for things written in the Golang eco system. Or how about Kubernetes to manage your containers? Well when it came out it helped out for sure but nothing AWS ECS ( Elastic Container Service) could not handle as well. The thing I dislike the most is the whole bad documentation and not fully knowing what to do and all of a sudden you are too deep and you cannot go back. My experience just connecting to Kubernetes cluster running on AWS EKS with either eksctl or kubectl was phenomenally bad. Again turns out the mentality spreads out. This mentality of not documenting it completely to draw people in like it is quicksand. Just like quicksand at a certain point you'll just float and cannot escape. You are just stuck there.

The tooling at AWS normally is quite good except when it comes to eks command then it reverts back to not fully describing everything and not working like you think it does to why does this command accept these parameters but the other one not while they are both part of the same tool ?

So like I said the hypothesis is that people bought into an overhyped and well marketed technology that is purposefully vague enough to keep you hooked until the moment comes where you realise you cannot escape anymore. Look at Flat Earth Society, it has a lot of the same properties and therefore I also think people that made Golang and derived products are failed engineers or software developers like Flat Earthers are failed scientists at heart.

We should educate them better and provide more resources to avoid these situations in the future. We should take lessons on how Python and Ruby are being developed, the core language and runtime. It is how things should be.

#thoughts #devlife

I was contemplating for a couple of days why I was so against it. I wrote already about something in the Golang community making it so they have vague documentation and undocumented steps. That was part of what was bothering me. The real reason I will state after a quick sidestep into self reflection.

Your self

It is important to get to know your self and yourself. This can be only be done by self reflecting a lot. I was having internal conversations putting reasons to my self for disliking kubernetes and seeing if that was really what it was or not. For me the trigger is a simple feeling of yes or no. No other way to explain it then just a sensation that either belongs to yes or not to yes.

Putting reasons to your own self is almost like an Artificial Intelligence playing against itself and learning in the process.

I highly recommend you doing this for subjects that you do not have answer to the question of but why? Again that question that is asked by kids where we go nuts because a lot of things we don't know why is the most important question and instead of parents stopping them from asking this question it should be encouraged.

Back to why I have negative feelings towards kubernetes and the reason why.

My self found an answer

The answer my self found for not having fuzzy warm feelings about kubernetes is the fact that it sets you up for failure. You start at step 1 and then at step 4 you realise you missed something at step 2. Then you have to go back start again from step 2. The fact that you missed it is because they don't tell you aforehand but only at a later step is the suddenly required mandatory prerequisite shown to you.

If you need labels for almost anything in kubernetes why allow one to create anything without them being present?

Example of a company that sets you up for success would be AWS. It is very difficult to not get something to work via the Web Console they provide and also via the cli tooling. In Cloudformation you can miss something but there they also give you good guidance in the documentation as well as provide fully functional examples that you can use as a template. Everything is designed to make it work for you at the end. You want to give the user success.

How to achieve this

In order to achieve this setting up for success it is greatly linked to making things monkey proof, or idiot proof or anything similar sounding ending in proof.

You want to close off all the avenues that lead to failure. It should not feel like playing a Sierra adventure game where you suddenly die and you forgot to save and you died because you did not execute the correct prerequisites. Don't get me wrong I love playing those games. I love them because I play them for the challenge in my downtime.

Tools that should improve my productivity should not be designed to allow for more ways to be less productive than improve it.

So keep in mind to close off the avenues that lead to Sierra states and your users will be all the more happy for it.

#devops #devlife

I read about the so called IKEA effect. This effect describes the cognitive bias that people have to disproportionately value the work/products higher when some parts of it are assembled by themselves. Meaning any challenge will add to this effect making you skew the actual worth of something because you put effort into it.

I can liken one more thing to it and that is like IKEA the things come with bad instructions and soon you are picture 5 and it states that you should get the plank with the three holes and there is not plank with three holes. Don't say there is, because there obviously is not. Until you think back to the moment where you asked yourself where would that extra hole be for? Only that was already a while ago.... So you start over. Again.

That last part is what defines Kubernetes for me. Also someone else tweeted it as well which sparked all this from me.

#devops #devlife #thoughts

Why?

The answer you get is because tech company Megacorp is using it, therefore we need to use it. This is not a valid reason of course. This thinking and reasoning is composed of the following effects and biases:

• Bandwagon effect
• Confirmation bias
• Congruence bias
• Conservatism (belief revision)
• Continued influence effect
• Default effect

Bandwagon effect

There is this effect that people generally accept it as fact that a certain action or belief is true because a lot of other people do or believe it. This tendency is very strong and is part of our group mentality. We as human beings like to fit in more than we want to stand out.

Of course the more people use Starlit Snowflakes the more it will proliferate because more people are using and therefore it must be good. You can see the potential for viral marketing and the value of a well known name and image. Also Kubernetes anyone ? You did not think I had forgotten about it did you?

Seriously though I think the bandwagon effect and congruence bias is used in most cases where a piece of tech solved a specific issue to make it better than it is. For example Golang was created to run on multiple platforms, like Java, but have an easier way to do concurrency. Fair enough, that is a specific use case and solution. How many of us out there have this need ? Maybe you only need to deploy the application to one server (or a bunch of servers) running one type of Operating System and the concurrency only needs to be written once over a relative normal period. So there is no need for fast development with easier concurrency and also no need to run it on multiple platforms at the same time. You can write it in Elixir, Python or Java just as easy from that point of view.

There are more technologies that fit this bill like among others: – React (by Facebook) – Bazel (by Google) – Kraken (by Uber)

There are also examples of tech that can be used by anyone because it is a better solution (or the best solution) to a well known problem. An example I can give is H3 by Uber. They made a better solution for doing geospatial indexing based on hexagons because they fit better together and used in different resolutions they can better describe regions on the Mercator projection of Earth that will not result in overlapping areas and not defined to complex areas created by mankind nor influenced by new postal codes or redefined existing areas.

Confirmation bias

This is linked to conservatism explained a little later. People tend to look for things that confirm their opinion and value that higher and stronger than those things that oppose their view or opinion and either deny those or value them weaker.

So in this case the engineer will only look for stories confirming this is a good piece of tech to use.

Congruence bias

This has to do with testing the hypothesis only directly and not testing the alternative options. In our case the engineer will just make a case for the one tech it wants to use and state it is the best instead of actually looking around for other solutions and making sure there is no alternative.

Starlit Snowflakes is the best to solve Megacorp problems and there is only one who suffers from them, Megacorp. Take this into account when reasoning about a piece of tech.

Conservatism

This is the most important one so I think this is the one that is the basis for a lot of the other ones. This is also linked to the continued influence effect. This conservatism is also called belief revision or more accurately the belief revision resistance. It is the fact that people do not correct their belief as much as they should when presented with new information that should correct their behaviour.

I liken this to a self correcting mechanism each one of us has. There are people in the spectrum that have this self correcting mechanism so powerful that they are always right and nothing can make them see they are wrong and more importantly these people will convince others that they are the single source of truth.

Then the other end of the spectrum is the people that have not a self correcting mechanism that says they are right but consistently telling them they might be wrong. They will never say they are right because they might not be. It is an engine of doubt that makes them explore other avenues of thought.

The rest is in the middle spectrum that have a mild version of self correcting. On core beliefs it will correct and say they are always right but on peripheral items they do not really care and will adopt whatever seems reasonable.

The problem is this mechanism makes it damn near impossible to make people see the error of their ways, the mechanism is simply too strong. I think it is wise to adopt a mechanism near the spectrum of the doubt engine mixed with certain base fundamental truths you know to be true.

Continued influence effect

This effect is interesting because it happens when you learned something in the past that later turned out to be false. This will fuel the self correcting mechanism with ammunition to state you should not change just because of the new information. The information you already had in your mind is worth more than the new contradiction information. Also the mechanism devalues the new information so it sustains each other nicely.

This might mean the engineer learned something in the past that absolutely no longer holds or never was true in the first place but it is hard to get rid of that information.

Default effect

This is when there are a bunch of options to choose from persons tend to go for whatever is the default more often than not. This is met on the same edge with best practices and community preferences. It might be that for a specific case the best practice or community preference does not fit the bill completely and there is a need for a slight deviation and that will not be done because it is not the default.

It might be that the default option does not fit the case at all and something far off the beaten path is better suited, it will not be chosen.

It might also be that blindly the default will be chosen and maybe the bandwagon and congruent testing support the blind choice.

Solutions

The moment I have one or many I will share them. For now I think it is enough to identify the biases and effects and see if you can address them one at a time. For all the biases listed and more go here.

#devlife #thoughts

What does it mean to go nuclear though?

Emotional state

Some people just tick you off faster and quicker than others and there are situations where you just feel there might be something that is unjust or unreasonable. Those moments you feel your emotional state getting the upper hand and you move into predominantly emotional responses that can be irrational. At these times you might go nuclear. It means you send a message to the CEO of a company or in these times maybe you send a message to the interwebs. You post on Facebook, Twitter, Medium, Reddit or other similar sites.

Alternative weapons of mass destruction

You have to go through your arsenal at a reasonable pace. You start with a gut punch, then knife, moving to pistols, rifles, shotguns, assault guns, rocket launcher and then calling in some strike teams to assist before you punch the big red button to launch the nuclear warhead.

You first try and talk directly with whomever you have a problem. Then maybe with HR present, or have HR act on your behalf. Then team manager and then his manager maybe. A couple of subsequent talks might be necessary. Then when all else is lost and nothing works. You go for the extreme method.

Once you go nuclear there is no going back. You cannot undo it.

Long lasting effects

Like the real nuclear warhead there are long lasting effects and they are that people will remember you for it. They will now hold in their head you once went nuclear. So information might be withheld or you might suffer from it in other forms. Once you posted it on social media the effects are there for life. Really consider this option if there are no other possible avenues you can pursue and you are assured of the righteousness of your cause.

Of course the last point is usually the case you think so but verify with others you hold close and you trust the judgement they give you to be fair and uninfluenced by the fact the source asking is you.

#devlife

Time

Even if you take 2 weeks to script something that only takes 5 minutes to do manually it depends on how many times you have to execute that 5 minute task. If it is a couple of times a day then it might not be so handy. You need 12 of them to get an hour saved and then 80 times 12 to get even with the two weeks. Let us say you execute it 5 times a day. That means you have to execute it for 192 days. That is about 6 months. Every time after those 6 months you save an additional 5 minutes. So the remaining 6 months you saved another two weeks of manual labor. That is not that impressive maybe, but that is one task that now automated gave you an extra two weeks of time to do something else. Like optimizing another 5 minute task that gives you more time and so on.

Errors

Another reason to automate something is to reduce the amount of errors. Well actually not reduce. Because if you create an error in the automated script or procedure the error gets reproduced. However the error is consistent across the executions. In contrast with a manually executed task, the error can be introduced at any moment.

Transfer of ownership

It is easier to share a script than it is to share knowledge that only is in your own head. If you write it down that is kind of writing a script only the automaton will be another human. Otherwise you cannot, as far as I know, at will telepathically transfer your knowledge to any one who wants it on demand.

Security

If you write a script that any one can execute, then the problem becomes that anyone can execute it rather than a select few. That is easily remedied as you can shield the script from eyes that do not need to lay on it. Other option is to shield the resources the script operates on. In any case you only have to do either or.

Reproducibility

The property that it is easier to reproduce everything is a nice property. If something new has to be created after a while of not having done so, the time to create it and think about what was needed is minimal at best.

Easier to reason about

It is easier to reason about this process if you can easily see in one overview what the total process is about.

Conclusion

In short there is always an automaton, either it is human that is very poorly programmed resulting in inconsistencies or it is an digital construct that at the very least is consistent.

#devlife #thoughts