Ruminating on ordered delivery

 A new outlook now in a much more supportive environment, got much more time to think the magic of getting a group of people to perform and deliver on planned goals. In short, life just got real and my convenient crutches has also been taken away. 

I am sure that some of us have sought the safe harbour of unable to perform due to something I cannot control before in our lives. What if that is no longer there ? You are just left with the goal in front of you and how to plan to get there. Unmovable objects are most of the time crutches or excuses why we cannot do something. Without it then life becomes just that little bit more scarier as you have nothing left to blame. 

It's scary and humbling knowing that what ever lies ahead, you got nothing and no one to blame except yourself. Internally, I have reached the point where I can no longer give a good answer what is wrong with what I am doing now, and what is blocking me from trying to achieve my mission or what I want to do. I am at crossroads. Each crossroads comes with their own hard set of questions. Here are some of the hard questions that I am going to have to find answers to:

• It's easy to throw up your hands and say I cannot proceed because this huge roadblock in the form of company procedures, my boss not giving me chances which has been laid in front of my way is preventing me from going forward. It's harder and more uncomfortable to find out why you supported best laid plans just went awry and you fell flat on your face. 
• How to put all the stuff that I have read and want to try (organisations, software methodologies) into small measurable experiments to see over time if it's achieving what I originally planned. 
• Related to the second point, now the chances are here swirling around in this huge cloud of opportunity, how then do I inject a bit of structure into the chaos to capture the lightning and harness the electricity. Lightnings are good and powerful but a battery or an electric socket is more predictable and productive value that can be used by others. 
• Not getting lost in the woods and loosing sight of the trees. I have to really get better at recognising what is impactful and can bring the best value contrasted with what is enjoyable to do or interesting to do. After so many years, I have yet to find a good system to do this. 

Yeah, so in summary, in a better headspace but crucial is when in times when support is given, what I will be delivering with the given support.

That one where I almost lost my life but ended up rolling over a 5 year old boy part 1

 You know when they ask you in interviews "What is your most embarrassing mistake" ? Well I always lie and mutter something that I think they want to hear and a false cringe on the face to add dash of believability into the whole story. It's false. That is not my most embarrassing mistake. The most embarrassing mistake I have ever done in my life happened before I was even working. I think this was in the 90s. 

It was the days life was simpler. Mom had her wits with her, before Dementia stole her memories and I could talk with her and dad was still alive. Out of all my school mates I guess I was one of the privilege few who had enough money to join a sports club after school. It was something like paid tuition for badminton. It was called "Pioneer Badminton Club" and we had a coach that taught us badminton. We played mostly during the weekends on "proper badminton playing skills". Coach was this like older guy who was very passionate in badminton and read many books on the subject. He was like the authority in badminton for me. We played in this really spartan place which could easily be used a sauna on hot days and it had another name called the "Green House". Although it was town area but it was situated in a kind of rural part of town so we got to experience what it was like playing badminton in a place situated almost like in the middle of a full blown jungle. 

The place was owned by this family who also played Badminton at this place. 2 girls and a guy. They were really good too. I used to have a crush on the older sister. She looked demure and slender. I liked her and she was part of my boyhood fantasies. Anyway, back to this story, they are only the co-stars of today's story. The main actor (protagonist of antagonist depending on which side you are staring this tunnel from) is the older brother of the family who played both the part of the senior patriarch of the family. He is a truck driver and he is one of those guys that really look the part. Picture an older Chinese guy with the steely gaze of Ironside, not to mention his fiery temper and you will be in the same ball park as me. 

Anyway, I used to practice Badminton with a whole bunch of other guys at this place every Saturday and Sunday and the coach used to come to my house to pick me up. Although it was hot and sweaty, I welcomed the change of pace and scenery it injected into my bored teenage life every week. There were four courts in this place and usually 2 of the courts would be used by our club. We had like almost 40 students at one point so this guaranteed that there will always be some guys who are not playing or training at one time. Those of us are who are "benched" in these intervals would gather outside the court and bond with each other as only teenagers knew how, calling each other names and playing stupid punky pranks on each other. 

It was a idillic, simple and happy life. Funny how the Little did I know that pretty soon all this would almost come crashing down right in front of my eyes. 

Why for some it's the end while others it's a challenge ?

 Today I started thinking about how challenges to certain people appear as roadblocks while others they are just challenges and is a problem to solve. I thought it was will power, vision and some character trait, but came to a conclusion after listening, reading and analysing successful people describe the challenges they face and how they overcome the challenge. 

I noticed more than anything they treat challenges as a problem to solve and they look very objectively at the problem. Their feelings or their sense of self are not tied to the outcome of the problem, rather the outcome is just an outcome to be observed to either be successful - stop the problem solving or iterate further and try a different approach to solve the problem. Problem solvers comes from in all shapes and forms, from all sorts of background but this is one of the trait that they seem to share. 

As it is the same to theorise how placing your hand on a hot kettle will be painful when your hand is not really on the kettle it's easier to think in theory when you are not actually in the situation, I think this also needs to be implemented and tried in real life, I will try to do this in my day to day now. It's hard but it's how a problem solver should think.

Do not rely on will power too as it is a limited resource and if it's a situation you to to force yourself to think daily, it is exhausting. It will not last long. 

Koan-ing around

 In what I do daily, unfortunately I spend more hours than I care for in very uneventful meetings. You know those kinds that when you go to you either get dismissed for what you say or you end up contributing less than 3 minutes worth of comments. Another down side of this meeting even realising the facts above, the whole world would go topsy turvy when you miss one of these useless meetings. So you can say that I have a lot of free fidget time on my hands. A few hours here, a few hours there really adds up to a lot. So I decided as an extension to my basic tutorials of Rust, I decided to advance to try out my hands in doing their version of Koans called "Rustlings". It's been great ! 

Coupled together with the great error messages of the Rust engine gives another dimension to Rust's Koan - Rustlings. Learn to love the descriptive error messages and you will begin to think of it like your own private Rust tutor. You can get started with Rustlings here: https://github.com/rust-lang/rustlings. 

The exercises are short enough (at least the starting few) that you don't get over invested to the point someone actually notices that you are not paying attention during these meetings. They are however good enough to test your understanding of Rust syntax and language structure. 

It tests you on syntax, logical structure and some basic usage of popular built-in libraries. So, get off your laurels and stop flittering away your hours in useless meetings, instead spend it polishing or sharpening the axe. All of us have the same hours of the day, how we decide to use those hours though separates the wheat from chaff. Happy koaning around ! Also, Koans are very popular in most languages so if your interest is not in Rust just try googling for <you language>+koans and most probably will find something out there that will butter your toast. Hasn't failed me yet. 

Some things to stop doing

 Here are a. few things that I am going to try my best to stop doing:

1. How some relationships can stand in the way of success or goals no matter how much the person that is allowing it to happen says it's not so. 
2. How mediocrity can be tolerated in service of a friendship.
3. Trying to figure out how words and actions don't usually come hand in hand. 
4. Stop looking deeper and continuously evaluating the values of my own goals. 
5. Going to multiple virtual meeting at once. Like all the ones above this one is not worth it, no matter what I used to think in the past.
6. Being surprised how mule headed and un-logical people can be when protecting a useless or pointless process. 
7. Trying to understand why #6 is the way it is, you can ask why but usually the official reason does not make sense anyway. 
8. Tying my organisational and personal mission to a person. That person might have inspired me towards my mission but that's it. Have a good day. I will take it from here.

Time here is ending ?

    Time here with my team after so long (coming to 3 years), looks like is inevitably coming to an end. Am I pissed ? Damn right I am. We are kind of paying the price of someone's insecurities, he fears we have to go. It's been a journey and unfortunately the journey ends in melodrama. I did not plan for this to be a tragedy or drama. It's supposed to be a feel good movie. How can I spot these kinds of things before actually joining a company during the initial courtship of interviews ? For this one, during the initial stage I did not even detect anything. I just noticed that the A-hole was kind of dismissive during the interview, cutting me off in mid flight during my sentences but the content of what he was saying was positive or neutral at best. I mean who in their right mind would go out and show your worse side during the interview right ? I wish I knew of some questions to uncover Jerk bosses ? I guess something like this would be serviceable ? 

https://www.themuse.com/advice/10-questions-ask-job-interview-avoid-bad-boss

Something like this: https://www.themuse.com/advice/the-best-interview-questions-to-ask-if-you-want-the-truth-about-company-culture 

perhaps to uncover bad company cultures ? It's not easy moving from company to company, it's stressful on us too as we are again thrust into the proving battlegrounds of being unconfirmed after surrendering all of your previous progress in the previous company at it's door. I feel naked usually hit hard with culture shock as well as another strong case of impostor syndrome. 

I can tolerate a lot of things where I work, but not being undermined, belittled and dismissed. I just have to keep on asking myself what the hell that I did wrong and which deity I accidentally killed on my way to work one day, as I have no freaking idea. The good side to all of this ugliness though, is I have clarified and understood the things that I want and my mission in life. Guess what ? It's not just purely about DevOps. DevOps at the end of the day is just a tool. A means to an end. What has always interested me is how to create a place of work where engineers can humanely work to contribute their time while still being able to hit company goals. Admittedly I think this motto and goal needs further clarification and refinement. Like the author, this goal needs work and is at this stage still a WIP. 

I hit upon this when interviewing with another company who advertised for a "Senior DevOps lead", could not afford it and at the end of it tried to stretch it's reach by asking me to come up with a "Go to Market" plan which usually are done by teams ... yes teams in other companies. Really Meh-9 wasted my time with that stinker. We should all just maintain a list of Cina Apek companies that should be avoided during interviews. Glassdoor did not help much during this process too as most of the reviews looked positive. 

That's pretty much all I got to say for now, I hope this blog will become my therapist as I pour out my pains, insecurities, anger and disappointments here and out of the ashes of all my pains will come out a better me and hopefully I will finally land somewhere that will appreciate me for what I contribute and somewhere where I grow with the company. 

How do you run inspec.io on Solaris without killing yourself ??

We are using inspec.io for our post deployment verification / checking strategy. When I evaluated inspec, I really like a few things about it:

• It had a small toolchain and good support for various platforms - Windows, Redhat, Ubuntu, Mac etc. Easy to install, experiment and implement.
• It's supermarket checks is like collection of checks done and outsourced by other teams which are open sourced which we can leverage and quickly get working on our own script to do code as governance. 
• You do your scripts in Ruby. Period.
• The ability to run locally as well using ssh which is something that I really liked as well. 

We were planning to use inspec as the post deployment verification after deployment as part of our Continuous Delivery strategy. Everything was going along fine, until today. A few things hit us. This target server that we wanted to run the scripts on was a Solaris platform. First warning bell tolls. Sola-whut-again ? Really ? No packages were available for Solaris for inspec on their site. 

So that rules out calling our post deployment checks locally on the server. I mean of course this is not the end. We can try to install inspec on the server using source. Have not tried this, don't know what kinds of misery awaits to take huge chunks of meat from my arm when I reach out to open this door once, but I have a feeling we will have an easy time with this one. At this point too I was thinking ... I might not know enough here but who in their right minds runs a production system on an OS whose very existence instantly puts the whole project into a deep tech dept ?? Put another way, I was at one point in my life, keyword here definitely being "was" impressed with SunOS way back in 2005 back in the days of IpVx watching in awe as my Senior banged out long strings of commands without the help of the tab key and could somehow magically get the commands right every single time while he looked straight ahead and banged them out in blinding speed. Fast forward to 2019, let's just say after all that's happened I have lost equal measure of respect for that senior as well the OS on which he was banging out those commands on. Come on .... who uses SunOS in this day and age ? I don't really like using RedHat when managing servers but RedHat is manna from heaven compared to this rusty old doornail. Thanos ... hand me that glove while I snap this tired old OS out of it's existence in my workplace! The day was getting along, tired and a trying to avoid pushing my blood pressure up any further, I soldiered on for other solutions that we could use.

Installing inspec on the Jenkins server ?

So, then we thought about calling inspec from the build server which is a Jenkins server. So, the plan: Install inspec on the Jenkins server, call the scripts from the Jenkins server and use the "-t ssh:// ..." argument to target the deployment server. Sounds good. Not ideal but it's workable. I don't really like this idea as in order to run it in this fashion, ssh keys has to be maintained in the Jenkins server or some kind of script wizardy has to be imbued in the scripts to make it run correctly. At this stage my first paddle did not look so good, so I decided what is the harm in trying the second paddle ... turns out the second paddle has it's problem as well. It's running an almost ancient version of Windows. I know, I know who in their right minds would run Jenkins on Windows right ? Sigh, for the sake of argument and the readability of this post, believe me, we did question this. Let's just say the server OS choice and installation is out of our control and our control extends as far as being able to configure stuff using Jenkins only. Again we hit the same problem here: There are not packages available for this OS as well. Yes another day in the land of "Dev" on this side of the mountain while "Ops" being on the other continent! So yayy for our second paddle sinking to the murky depths of the river. 

So what now ?

The way I look at it, we are left with a few choices now. All unknowns ... great! 

1. Try to bash my skull in and install inspec on Solaris. There was one measly comment on SO when someone asked this question pointing to some Chef scripts. That's all ! Confidence level plummeted to the core of the earth after seeing this. The usually boisterous SO was strangely quiet this time. 
2. Try to install all of our post deployment scripts on an external RedHat server and call them from there. The question here then becomes how the heck to you capture the status of the checks ? Is this even possible ?
3. Spin up a docker instance in Jenkins and call the scripts from within the docker from the Jenkins server ? I really don't know this one and I have not tried it. 

I am reaching out to all those 48 people who read this blog if you guys have ever tried or better yet succeeded in using inspec on your Solaris boxes before, please find it in the kindness of your hearts to share in the comments section on how you did it to benefit the tired writer of this blog as well as the others who might one day stumble upon this blog post. Cheers.