Back in the day when I did consulting at a client office, a developer decided to throw a tantrum at his manager. We were in a meeting where a discussion the developers was having with his manager turned into an argument and then a fight.

One moment, it's a reasonable technical argument, another moment, this dev, is fuming with anger and the tosses the white board duster on the wall, takes off his coat, rolls his sleeves, kicks the chair, says something really nasty to his manager, slams the gate of the meeting room and leaves the meeting.

There is an awkward silence. We all look at each other. The manager is embarrassed. But in a few seconds, he pretends as if nothing has happened and continues the meeting without the developer.

After the meeting there was a general discussion on the episode with the central focus around WWYD (What would you do) if someone in your team had done that to you and my stance on this was crystal clear. If I was the manager I would have done all in my power to get the get a firing decision taken for this guy at the organization level. I would then get the firing letter printed, given him the letter and then asked for a public apology if he wanted me to take back the firing decision.

Based on how sincere his apology was and what the reason of outbreak was, I would then have calmly reconsidered if I wanted to revert my firing decision or move forward with it.

Being a nice guy, is an active decision. A choice. Not a weakness.

Both David Allen (the guy who created GTD) and a sequence in the movie the karate kid talks about the concept of mind like water. If you throw a small pebble in water, the water gives you a small splash back and then returns to calm state. If you throw a boulder in water, you get an appropriate reaction, followed by calmness. If someone throws a huge boulder at you and gets no reaction, you're not calm, you are just weak. There is no niceness or glory is being treated like a doormat and yet doing no harm.

We all like being loved and respected. But whether it's work on personal relationships, you job is not to be loved or liked by people who can't offer you basic respect and decency. When people start fights and lash out at you, not lashing out back at them tells them it's OK for them to lash out at people without any reason.

When someone is repeatedly humiliating you, insulting you and walking all over you, just taking it and doing nothing about it, is never an answer.

The mark of a nice person is that you don't start fights or don't say nasty things to begin with or you can let go things a couple of times. But when others behave inexcusably with you continuously, your inability to retaliate doesn't make you a nice person. It just makes you a weak, uninteresting, spineless doormat.

A lot of young managers I have worked with think it's cool to be friends with your team and in this desperate desire to be liked and be seen as a nice person they are willing to be treated like a doormat but never retaliate.

I also see a lot of developers who believe it's not a big deal if their manager continuously intimidates and humiliates them. It's a same problem in parenting. If you don't believe me look at a few kids throwing tantrums in the isles of any supermarket and the parents tolerating that behavior because they want to be seen as nice caring parents.

Same problem with married couples. Same problem with friendships. Today it's not hard to bump into a couple or a parent child or a sibling relationship where one person is humiliating the other person publicly and the other, is just taking it. The strategy of avoiding a fight when you are being treated like a door mat never works out in the long run.

The problem is so commonplace you have an article on life hacker around how you can avoid this issue. The bullet points in the article are spot on:

1. Start With You - If someone else is devaluing you there’s a good chance that you’re doing the same thing, so change has to start with you.
2. Start Teaching Others - Your response to someone’s behavior teaches them what is and isn’t acceptable, so if you roll over and take whatever they give, the message is that it’s okay for them to do that.
3. Stop Being a Bottomless Pit - It’s great to do things for other people, unless the act of doing things for other people is how you get validation, of course. People-pleasing is not a selfless act; it’s a selfish one.
4. Apply Confidence - If you’re used to people walking all over you, it’s likely that you’re not used to asserting yourself.
5. Raise Your Expectations - An easy life is one thing, but sticking your head in the sand and hoping things will fix themselves is crazy—as is setting your expectations so low that you expect to be treated like a doormat.

If you've ever been treated like a doormat, I recommend you go through the entire article. From chimpanzees to bears every animals marks their territory and sets expectations of how they wish to be treated by others in their group, tribe or flock. If those expectations are not met they retaliate.

You may have seen a dogfight or a bear fight on the discovery channel where the alpha is bullying the underdog and then after a point the underdog gets annoyed, fights back and beats the crap out of the alpha.

That's an animal telling the Alpha, "I've had enough dude, step away from me!". And once the alpha backs off the underdog goes about his job of grazing the grass or straying peacefully. I personally believe that the retaliation from the underdog is what ultimately brings peace and harmony to the flock.

I'm not saying you fight or punish everyone for every little thing, but it's equally important you have boundaries beyond which you will not allow anyone to mistreat you.

The retaliation doesn't have to be driven by anger. Neither do you have to become passive aggressive, destructive or play games. The reaction can be a calm, composed retaliation just to set boundaries but none the less, there needs to be a retaliation.

Taking ongoing abuse and allowing someone to treat you like a doormat invariably leads to failed projects, outright insubordination, broken relationships, bullying, shattered self respect and eventually does as much harm to the the person humiliating you as it does to you.

From time to time we all have to take some disagreement, even some insult, humiliation and crap. This is not about being an arrogant prick who makes everything about his / her bloated ego and self respect. It's okay to take some humiliation or even insult. It makes us a humble person and teaches us the power of self control. But equally important is drawing very specific boundaries on how much crap and humiliations you will take and making it clear that you will not be walked over or insulted beyond a point.

So the next time someone blatantly disrespects you and shows that as a consistent behavioral pattern, speak up if you can. Being nice is completely different from a being a weak, spineless doormat with no personality. We need lesser jerks in the industry and sometimes you have to become a jerk to tell someone it's not okay to be one.

I'm incompetent. On days I feel like a absolute looser who is unable to focus and get anything done. On other days when I am productive, I see others around me being incompetent and I get urges to tell them to snap out of it and get them to get some real work done.

In my entire life span, I can count the consistently productive people I've worked with using fingers on my one hand. And just to be absolutely clear, I'm not one of them. Oh and when I'm not productive, I've got thousands of excuses about why I'm unable to give my best.

The other day I downloaded a version of ionic and out of the box and it wouldn't compile a hello world project I stubbed out using it's own CLI. I felt angry at the incompetence of developers who were building the ionic framework and had the audacity to throw a crappy build out there under the name of iterative development!

Then I went looking for some help and someone had already whined about it on the ionic git repository, where someone else had given them an ugly patch to unblock them. So I applied the same ugly patch myself and life moved on.

On a different day, I was trying to get .NET core 2 application migrated to .NET Core 3 and it was just annoying. Were the developers at Microsoft incompetent? Or was I just having a bad day? Or, was I incompetent for not going through all the breaking changes between two version and writing planned code rather than doing reactive development every time something broke? I told myself I was just having a bad day and pushed on applying one fix after another and migrating the code over to the newer version of the framework. This was defect driven development but I got a lot done. Maybe I was incompetent but I was productive.

Then, the other day, I got on an elevator, and pressed the button to go to the sixth floor, the elevator literally bounced around a bit, then went to basement at full speed, then shot up at full speed all the way to fifth floor instead of sixth, came to a screeching halt, opened it's door and stopped. All of us in there were shit scared and spell bound.

Then the maintenance guy shows up and tells us he had no idea what just happened but 'guarantees' it wouldn't happen again. My nerd brain is screaming to tell him that he cannot theoretically give us that guarantee till he knows exactly what happened. But as per him, 'for now' everything 'seems' fine and we could go ahead and use the elevator again. I took the stair case instead.

Like it or not, we live in a world where everything is broken. I don't know how we got there. Maybe it was materialism or maybe it was just our desire to move fast or be agile, or maybe it was just our animal instinct to win races, but we're here. And like it or not everything is either broken or will break down soon. The only question is how badly will it break down and how soon?

This also means that as much as you want your work to be reliable it is just as reliable as the underlying frameworks you use, and most frameworks you use are going to be broken at some level. Add to that, our inherent incompetence, our laziness, all the distractions, the work culture most of us are working in, the interactions you're having at work, the number of meetings we're expected to attend  and the amount of grunt work that we're expected to do. On any given day if you can get anything done, you should give yourself a pat on your back.

We live in a world where incompetence is the norm. Everyone around you is incompetent. You are incompetent and so am I. And there are only two ways to deal with this incompetence:

Embrace Incompetence and Design for Resilience.

Start your day with realizing the potential of incompetence you have and set smaller goals and turning productivity into a game. If you have a todo list that expects you to do more than 2 hours of real work on any given day you are just going to be disappointed end up feeling like a piece of crap.

Know that you are incompetent, the frameworks you work with are unreliable, your work culture is broken and above all the folks you work with are going to struggle with these exact set of issues of incompetence as you are struggling with and they too will have mood swings and productivity cycles like you and you have to deal with all of that; not to mention your phone buzzing and email streams to distract you. So just aim to get less done without feeling guilty about it. You'll be happier.

If you want any mental sanity in today's world have really low expectations about your own productivity and productivity of folks around you.

Then when you get 3 hours of work done in a day you feel good about it rather than feeling like crap. And then when your dopamine circuits kick in, instead of being being constantly depressed about being non productive you can be happy and slowly push the two hour check list to a higher hour count because you are now gaining self confidence and control.

Put simply, design your life around unreliable things and build resilience into your work routines, the quality of work you do and even your social interactions. Life today is literally a game of inches and instead of hoping to walk a focused yard, it all boils down to your ability to grab and collect those little wins and inching forward. Embrace incompetence and grab whatever tiny inches of productivity you can grab out of your own life.

Draw Incompetence Boundaries

An elevator bouncing and going to the basement when you press 6 on the dials is acceptable. The same elevator crashing and killing people isn't. They told me that the elevator has a safety mechanism in place and it could dance around all it wanted but the likelihood of us dying in an elevator crash are very low:

The only known occurrence of an elevator car free falling due to a snapped cable (barring fire or structural collapse), was in 1945. A B25 Bomber crashed into the Empire State Building, severing the cables of two elevators. The elevator car on the 75th floor had a woman on it, but she survived due to the 1000 feet of coiled cable of fallen cable below, which lessened the impact.

The elevator manufacturers have clearly drawn a line on what's acceptable level of incompetence.

My general rule is, incompetence is fine as long as it's not costing someone their life, a physical injury, mental trauma or their hard earned money. That's where my boundaries are at. Anytime there is even a remote chance that any of these are violated, I have to shake my incompetence off, get some serious work done and take extra measures to try my level best to ensure that this doesn't happen. Absolutely, no excuses allowed. Fortunately most of us work on CRUD apps where the bugs we introduce are such that we can just go "Oops! Sorry!" - fix them and move on.

Also, It's good to have boundaries around just how much incompetence you will  tolerate from yourself. For me those boundaries are pretty relaxed but every once in a while I'll snap and will send a virtual check of hundreds of dollars to my mom stating that if I don't complete this task by a specific time and send her proof of it's completion she is free to encash the check and just take the money. She is not supposed to give me a chance to produce any excuses or explanations. Do you know how many time's she has had to encash the check because of me not fishing the task on time? Zero.

Suddenly, I've taken my incompetence which was causing me some minor annoyance and turned it into incompetence that's going to cost me enough money to make me uneasy. Lo and behold, things get done. Not in months or weeks, but in days and sometimes hours.

The other important thing to realize is that the only incompetence you can address or fix is your own. Trying to fix anyone else's incompetence is a recipe for becoming an as$hole. Every loud obnoxious jerk at your workplace believes that his or her coworkers are incompetent and he / she is just trying to help them get rid of their incompetence when in reality he / she is just being an as$hole.

The other day I was watching a video about a mass murderer who was being put on the electric chair but it was taking some time. This dude got so annoyed at the incompetence of his executor that he yelled something to the effect, that his executor was incredibly incompetent and in that much time he himself would have killed half the city! Once you start looking at incompetence of anyone other than yourself and start acting on your urges to 'fix them' you have taken your first step towards being a prick because now you're seeing someone as a lesser person.

Long story short incompetence is all around us and we live in a world where there are very few people or things that work consistently. You can either bitch about it and use it as an excuse to get nothing done, brood over it and be an arrogant pompous prick who thinks every else is incompetent; or embrace this incompetence and ship anyways. I don't know about you, but I prefer the later.

I did a talk in one of the Microsoft Events a couple of years ago where I took the audience back to basics using C# and the folks seemed to love it and gave it a five star rating. Simple things like function pointers, delegates, basic algorithms and data structures. I think everyone should recap at-least one of these topics every week and this series is my humble attempt to share what I recap with you. Today I'm recapping Bubble Sort.

Bubble Sort

Bubble sort is by far one of the simplest sorting algorithms. Let's assume that if you have 5 numbers in an array and you need to sort these numbers from low to high. Let's assume this is what the initial state of the array looks like:

Assuming you are sorting in ascending order, the goal is to run a for loop through every element in the array, using a simple for-loop and check if the number is larger than the number next to it. If the number is larger, swap it with the number on the right.

In the above example, the for-loop begins with 5. Because 5 is larger than 4, 4 and 5 are swapped. And then you compare 5 with 3. Basically here is how every iteration of the for loop looks like:

Once the for loop completes you are left with:

One round of the for-loop execution is what we call the first pass on the array.

From the above image you can clearly see that if I do three more passes (i.e put the for-loop inside another for-loop) the array would be sorted and the right numbers would 'bubble up' to the right places. Here is what the second pass looks like:

From the above diagram it is intuitively evident that if you do this for three more passes this is what the outcome the third pass would look like:

And the fourth pass would look like this:

So basically if you see each pass as a for-loop and 4 (N elements i.e. Len(array) - 1) passes as another loop, we can easily translate the above logic into code:

In the above code, the inner for-loop is basically a single pass where we run through each element in an array and swap values if the value of the element is higher than the value it's next element. The outer for loops is number of passes.

When I wrote the example and published the blog, Steve was kind enough the point out in the comments section of this post that the algorithm wasn't fully optimized and than it was doing way more iterations than it really needed. And he is absolutely correct. In the above example we have two loops and both are iterating through the entire array. However if you notice in the above theory after the first pass, the largest number would have essentially moved to the extreme right of the array:

What this means is the second pass can actually ignore the last element of the array when it iterates. The third pass can ignore the last two elements and so on. This means that the second loop can essentially be further optimized and doesn't have to iterate the highest numbers which have already been moved to the extreme right of the array. The optimized version of the code looks like this:

If you want a slightly different way of doing the same thing you can also look at Steve's code in the comments of this post. Special thanks to him for pointing out the optimization which I had completely forgotten, which is why revisiting these topics every now and then often helps!

Bubble sort is not super efficient when it comes to it's time complexity, and there is hardly anywhere we hand code sorting, but the algorithm itself is something that gets thrown around a lot in discussions so it's good to know what bubble sorting is all about.

Empathy is the foundational building block for good leadership. It makes you tolerable and worthy of forgiveness as a manager. It's a foundational building block for all relationships that you are going to form in your workplace. Steve Yegge's timeless blog post of empathy is my go-to post to read every time I find myself starting to act like a jerk.

But even as a person with empathy, you will make mistakes. These mistakes will often effect your team and make you feel like a jerk.

Time and again, a lot of managers (me included) make these same rookie mistakes. I have seen development teams suffer because of these mistakes and bad management styles. I truly believe most managers don’t have malicious intent and can fix these mistakes really easy by exercising a little bit of mindfulness.

This series of posts is my attempt to document these mistakes and try and spread some mindfulness for managers. I post them as commandments because we are wired to remember commandments and they sound just a little more serious that way.

For today's post let's start with the first mistake most managers make:

Thou Shalt Not Tell Us What We Need to Look at.

Ever worked with a manager who calls the entire team in a meeting room, points out a bunch of open items, says  "we need to start looking at this" and then ends the meeting?

Then weeks after that meeting he calls you and gets really angry that "this" was not done?

There are multiple problems with this "we need to look at this" style of management. Here are few fundamental issues with this style of management:

#1: You never told us who amongst the team needs to look at "this".
As a manager when you aren't specific about who in your team needs to own a problem and pick it up to solve it, two things can happen:

1. No one picks it up (and you are actually lucky if this happens) or:
2. More than one over-ambitious pricks in the team pick it up and then step on each other’s foot all the time and get into stupid arguments because both of them have assumed ownership of the problem.

The first rule of delegation is you need to be crystal clear who you are delegating to. The second rule is you never delegate one thing to more than one person. The "we need to look at this" style of management violates both these rules of delegation.

#2: You never created any agreement on what will be done and by when.

The bigger problem with this style of management is that you never told me exactly what I need to do and by when I need to do it. "We need to look at this" doesn't mean anything. Maybe I just looked at it, realized it was bad but then I was busy, so I decided I will fix it next year.

If you want me to act, be specific about what you want me to do and by when you want me to do it. Till the time you do that you have no right to expect anything to get done and absolutely no right to ask for status.

#3: You are not paid to have visions.

The "we need to start looking at" school of managers believe that they are visionaries. Newsflash! As a manager, your job is not to have visions. It is to crystallize visions your leadership or your customers have into actionable items and enable your teams to materialize those visions.

True, every once in a while you are free to have a great idea or vision but that is not your primary job function. When you are managing a team just giving them a vision and hoping they will do the management required to materialize that vision into action is not what a manager is paid to do. A manager is supposed to manage the execution of that vision.

When you are managing a team of programmers  it's easy to see yourself in some sort of high-end leadership role where you have all the great ideas and then delegate the actual boring clerical management aspects of the execution of those ideas to the team, but that doesn't make you a great manager; it just makes you a slacker who is not doing his job.

#4: Your Job Is Helping People Stay Productive (Not confuse them).

Organizing tasks and helping people stay productive is your primary job function. Having visions and ideas is a soft skill that is nice to have. If you don't like the clerical and meticulous aspects associated with management, maybe you may want to consider taking up a specific directorial role or maybe even start your own company with your own visions. But as a manager, you are as good as your ability to give clear precise executable tasks to your team members, get impediments out of their way and keep them productive and in the flow.

Unless you are a director or the CEO of a company, the "we need to look at this" style of management is a recipe for long term disaster.

One example from the Steve Jobs book comes to mind here.

Even as CEO Steve Jobs was crystal clear about having a specific rounded edge in the windows and dialog boxes on his operating system and he made is crystal clear who would work on it and by when he wanted it.

As a CEO he could have just said, "we need to start looking at making an OS like the one we saw at xerox", packed his bag and gone home. But instead, he chose to drill down into the specifics of how his dialog boxes of that operating system would look, what the size of the mouse would be and a million other nitty-gritties. He wasn't micromanaging. He was giving direction by breaking vision into tasks and then giving people autonomy to execute the tasks.

Even if you are the CEO of your own company, you specifically need two aspects in personality, one is seeing the vision and the other that is breaking it into clear executable work items and assigning those work items to the right individuals or teams who are competent and enjoy executing them.

If you are a director, a vice president or a CEO, you might be able to get away with "we need to look at this” style of management if you have hired kickass managers who can translate that vision into an executable plan but if you are a manager or directly working with programmers, and you are expecting your team do the entire execution of your vision themselves, both you and your team are going to be disappointed, hurt and struggling to get anything done in the long term.

Always remember, when you are managing a team and you want something done, never ask your team to just "look at" something. Tell them what needs to be done, tell them who needs to do it and tell them when it needs to be done. Anything short of that is just is bad management. Anything more than that, for example, controlling how they do it, is micromanagement. Right between that bad management and micromanagement is a thin line where really effective management happens. Your job as a manager is to walk that rope.

Web Assemblies and the Theory Behind Blazor

Back from the days of Java applets, flash and Silverlight, companies and developers alike have always dreamt of being able to run full blown applications inside the browser.

But then, most of these technologies have always been bulky, not so secure and fairly proprietary. Then as JavaScript evolved (both on the client side and the server side), true Single Page Applications became a reality. But, even today as JavaScript matures to become a ubiquitous platform for web development, most developers have a love hate relationship with JavaScript.

Enter Web Assemblies.

Web Assemblies ship with a light weight stack machine which is capable of running code that has been compiled to binary. Think of this as Byte Code for the Web. This is cool because with web assemblies you can run compiled languages like C++ inside your browser.

It’s developed in a W3C community group which tells you it's not proprietary; The community group behind web assemblies has representatives from almost all browsers.

Web Assemblies run in any browser, on any platform at almost native speed. If you want to know more about Web Assemblies you can go here.

And why are we talking about Web Assemblies in a post on Blazor? Because Blazor is .NET runtime built using Web Assemblies. This means I can now take Dotnet code and run it inside a browser.

You build .NET Apps or assemblies and ship them as Blazor Apps. The Dotnet code you write gets downloaded and runs on the Blazor runtime which is basically a web assemblies implementation. It has the ability to interact with the Dom extremely efficiently and even find out what changed in the DOM.

Alternately, you can have the same C# code run on the server and have it update the client side Dom using a Signal-R Connection. Any UI events that happen on the client side are sent to the server using Signal R. The Server captures these and runs the relevant server side code. When the server modifies the dom, Blazor calculates a diff, serializes that diff back to client and browser applies it to Dom.

Let's Try Out Blazor

Actually, Blazor has existed for sometime now; but what's interesting is that Blazor Server now ships with .NET Core 3.0 and is production ready. The ability to build completely client side apps in Blazor using Web Assembly is in still in preview through and will most likely ship in May 2020.

The tooling is seriously awesome and simple. The implementation is so neat that to pick up the basic concepts all you have to do is just generate a new project with it and the tooling stubs out a fully functional hello world sample you can learn from.

As a quick overview let's stub two Blazor Projects, one using Blazor Server and one using Web Assemblies and let's try to learn from the basic hello world examples the tooling generates. As always we'll use Visual Studio Code because it's free and let's us look under the hood to understand the tooling.

Blazor Server Example:

To generate a new project I fire:

dotnet new blazorserver -o serverexample

This stubs out a project for me:

I can now simply hit "Dotnet Run" like any other Dotnet Project and the stubbed out code runs like any other web application:

Notice that the application is running on port 5001 using HTTPs. I just hit https://localhost:5001 and then hit "Fetch Data" on the left to see an example of how data is fetched using Blazor:

Awesome. We now have an example with Blazor Server running. Let's take a quick look at the code to see what's going on. The first thing to look at is the startup file. There are a couple of things happening here:

Just like we do a "UseMvc" in a typical dotnet application, here we are the Server Side Blazor service to the service pipeline. We use the new Endpoint routing that comes with .NET Core 3.0 to Map a Signal-R hub Blazor uses internally. The Fallback route of "/_Host" is theoretically supposed to be hit when no routes match. This means you can use other controllers and pages without conflicting with Blazor routes, but when none of the other routes match, the _Host route acts as a starting point for the application.

The above _Host view has two aspects. After it lays out the head and body tags, it has a section that hosts the entire app and another section to display errors. The app section itself manifests itself as a view (app.razor) of what happens when a route is found and not found:

When routes like "/FetchData" are found the corresponding views are rendered the respective View Razor files are invoked:

Notice the HTML is similar to regular HTML and Rather other than the fact that it uses a local C# variable called forecasts which is declared in the @code block. The @block is where you write your c# code. If you don't prefer mixing HTML with C# you can actually extract this code out in a separate file which makes it very similar to the code behind model that we used with Web Forms in ASP.NET. The Forecast Service Class in the code above is just another C# class that runs on the server, which can then invoke Rest APIs and do things. In the stub is just returns hard coded data.

What's important to note here is that the C# code that write here is running on the server which means having an offline client is not possible. Also under the hood the server needs to keep a connection open using Signal-R with every connected client. Where I see this being used is small and quick prototypes or places where there is the going to be heavy use of Signal-R anyways and connection are going to be open with the server anyways all the time. A classic example is a real-time price ticker! If you need a more disconnected SPA experience you are better of moving to the client side model of Blazor.

Blazor Web Assemblies Example:

Even though this is in preview till May 2020, the tooling for building Blazor Web Assembly pages is also really awesome with .NET Core. I had to get .NET Core 3.1 (preview) for this to work though. Once I have the right version of the framework I create a new project using:

dotnet new blazorwasm -o clientexample

I built it and run it just like any other .NET project:

And we get:

I get the exact same output as the server example we did before but the underlying tech and design that's powering this example is completely different though. Let's take a look at the code to see what's different:

This project kicks off with a regular main method that basically utilizes the Blazor Web Assembly Host Builder to host your application. The App.razor and other aspects of your app might look similar to the server example that we tried out but what's strikingly different is the call to fetch the data:

Notice above that we are using the HttpClient library of C# directly on the client side and then passing the URL of a Json file to it. This could also be a URL of a service that returns Json. There is no backend server side in this app as far as fetching data is concerned and the client is doing most of the heavy lifting.

This design is pretty similar to any angular or client side application where the .NET pieces are just being used to start and host the application. All C# code that you put in your views is directly running on your client and using Http Client libraries to hit micro services or web-api's that run on the server.

Take Away

The maturity of the tooling both on client side and the server side as far as Blazor is concerned has blown me away. All the complexity behind Web Assemblies and Signal-R are encapsulated rather elegantly by the tooling. Having said that, will I use Blazor in a production level application yet? I'm not sure.

The sever implementation of Blazor seems creepily similar to the code behind model of ASP.NET where the server has to do bulk of the processing. Unless it's a prototype or something really simple I'm building I'm not sure if I am ready to go that route.

The client side model is still in preview but that's something worth keeping your eyes on when it goes live and ready for production. Till then, back to angular and the good old JavaScript and TypeScript.

If you are a web developer, Web Assemblies are a big paradigm change and Razor is Microsoft's bet on it, which is what really makes it worth spending some time on it and seeing if it fits your problem statement.

True Automation And Data Collection In Your Life.

Wearables and fitness trackers were virtually non-existent five years ago. The nerds amongst us were using a physical pedometer to track our steps.

Fast forward five years and wearables are now a 25 billion dollar market. They are everywhere!
Even though most metric the wearables track hardly mean anything, wearable health trackers have at least proven that people love the idea of monitoring their health. I personally believe that automation and analytics involve more than just wearing a band and tracking your steps or even heart rate. I have talked about my fascination for automation here.

For me effective automation must satisfy  a couple of simple criteria before it can become a part of my life:

True automation is transparent.

It’s one of the biggest reasons why I don’t like wearables. If you have to check your watch five times every day to see how many steps you walked and stare at your heart rate every hour to infer your health from that, I don’t think you’re automating and tracking anything! All you are doing is losing touch with yourself and cultivating obsessions and anxiety.

That’s what the companies who make fitness trackers want you to do, just like social media companies want you to constantly engage on their platforms, your fitness tracker wants you to keep looking at it, dozens of times a day to get validation about your health and wellbeing. No wonder there are times when these devices fail and people get panic attacks.

You shouldn’t be constantly peeking at a watch or an app to get confirmation on how healthy you are. Your health is something you should be mindful of and your body should talk to you. Your health is something you should feel. You should be able to mindfully listen to your body.

Also, step count metric is a bad measure of fitness, the data you collect is hardly analyzed over long term and the automation of collecting that data using a band, is way too obtrusive.

True automation and data collection works silently. Without you even noticing it. You set it and you forget it.

Really, when the big tech giants of the world are collecting your data from your browsing history they aren’t constantly pinging and buzzing you. That is what makes their data collection so effective. It’s so silent, you don't even know it's happening.

When you work on collecting data about yourself, you need to have similar processes in place for automation and data collection. Also, not everyone needs to collect the same data either, which transitions us to our next point.

True Automation Is Personalized.

As a nerd who has run a half marathon and multiple 10k’s I understand that step count is a bad metric and means nothing. For me, the hours I spend working out is a much better metric than the number of steps I walked.

Collecting the number of steps actually messes me up! I see 16000 steps on a pedometer on most evenings and then I silently convince myself that I have done way more walking today than a regular person so I don't need to work out.

It's a lousy metric that is literally detrimental to my cardiovascular health and overall fitness. Every time I wear a band, the band convinces me that I don't need to work out and my workout sessions come down.

For me, simply counting the number of days I worked out in a month is a way better metric than my step count of every day for an entire year. The point? What matters to me, may not matter to you. True automation is personalized.

For example for me commute is a big deal. I like to hack my time and minimize the time I spend commuting to work and back. It’s such a big deal for me that I need to track and analyze that data. If you live close to your workplace and spend ten minutes walking to office, tracking commute might mean nothing for you.

Spam calls are a serious problem for me and I feel the need to automate blocking those because I literally get multiple spam calls a day. You may not be getting any and may not want to automate blocking those.

Similarly, since I moved away from the city my family lives in, the amount of time I spend talking to my parents and family back home is a big deal for me, so I track that.

Things that matter to everyone are different. Automation should be personalized and if you truly want to automate parts of your life, it's about time you put a bit of programming effort on your own customized automation, taking your own data in your own hand and pick up a few tools of automation that work for you.

In this series of posts, I plan on showcasing how I personalize my automation and share some of the tools I use with you. Every tool I use eventually collects data about my activities and the time I spend. I’ll also show you how that data then pools into a centralized database that I own myself, which brings us to our next topic.

Good Automation Doesn’t Work In Isolation

What I eat has an impact on my mood. How much time I spend on the road actually has an impact on how efficient I am at work. How much sound sleep my wife gets has an impact on how many fights we have. :) Tracking an isolated item like the number of steps or heart rate literally means nothing.

When you start bringing a bunch of these random facts in a central database suddenly you start getting insights you never had before.

If you truly want to automate and analyze your life with data, you need to design and own a database of data points from your life that matter to you.

When you own your own data sets and when you design your own automation it makes it that much more easier for you to connect things and write smarter code and analytics to make sense of your data.

And The Point Of This Series Of Posts Is?

The idea I’m trying to share with you is that you need your own personalized automation and a database of data that really matters to you. I’ll be doing a series of posts here where I talk about things I automate and track in my own life.

In this series of posts, I plan on taking you through some simple automation tools and techniques to make you more effective and help you collect and analyze data about yourself and your loved ones.

We will use a bunch of random collection techniques I use and go through some of the fun automation I’ve set up around my life.

As nerds, most of us are excited about automation, machine learning, and data science but most folks learning it don't have any real project to work on it. Why not put it to use to automate and improve your own life?

Through this series of posts, I want to learn from you more than I want to teach you. Please use my techniques and tools if you like them and go build your own automation and intelligence around what matters most to you. Please use the comments generously or drop me an email to let me know the automation you are doing.

Think of this series of posts as nothing more than a nerd mucking around and having fun with some data and some code. And in the process, I hope to learn and share something meaningful and something useful with you.

In the next post we’ll start with reducing your physic weight and using basic automation on your phone to get things that bother you out of your life. So watch out for this series of posts (or subscribe to this blog) for more on the topic of basic automation, machine learning and analytics to improve your life!

Beautiful IDEs and Developer Productivity tools are my weakness. Which is why when PowerShell was released back in 2006, the first thing I wrote about was how you can skin it and make it look beautiful. But that was 2006. Things have changed now and Microsoft is taking the cosmetics of your terminal pretty seriously. Add to that a little bit of magic from the open source community and you can have really slick looking terminals now.

This is my diary of making my terminal beautiful on my work laptop. This is what we're trying to get to:

Let's start with first things first. We begin by getting the new Windows Terminal and then sprinkle a bit of open source magic on it.

Getting Windows Terminal

Windows Terminal is available in the Windows Store. You can search for "Windows Terminal" and you should see it there.

The Repository is available here. I had a slightly older version of windows 10 available so had to upgrade it before windows store would allow me to install the terminal. Oddly enough, if you don't meet the system requirements the Microsoft Store doesn't give you any visible attention grabbing error. The download link simply doesn't work. I am just about to give up when I see the tiny "See System Requirements" link (shown in the screenshot above). I click it the Microsoft Store tells me what the issue is:

There is an upgrade button in the store which takes me here and that link lets me upgrade my windows to the version of windows needed. After upgrading windows to the required version I'm able to download and install the Terminal from Microsoft Store. I open the terminal after installing it and  I'm presented with:

Installing Git and Oh-My-Posh + Posh-Git Modules

Most of the times when I am in the terminal I'm working on codebases and am on git repositories, so let's make the console pretty and also make it Git aware. We begin by installing Git for windows and then move to installing Oh-My-Posh and Posh-Git modules. The following comments install both modules:

Install-Module posh-git -Scope CurrentUser
Install-Module oh-my-posh -Scope CurrentUser

Modify Your Profile Script

Once you have fired the commands above you need to modify your profile. Type "Notepad $Profile" in the terminal and that should open a blank file for you.  Add the following code into your profile:

Import-Module posh-git
Import-Module oh-my-posh
Set-Theme Agnoster

The "Agnoster" used above in one of the many other themes oh-my-posh provides you and you can pick the one that works best for you.

Installing the Right Fonts:

You need fonts that support Glyphs, without which the beautiful symbols that you see in the screenshot are nothing but ugly characters. To put things simply when people collectively agree that a bunch of character translate to a graphic we have a Glyph. Glyphs are useful because they allow you to represent a combination of characters with pretty looking symbols and icons.

You can choose from all the fonts here which already have glyphs patches inside them (or you can patch any font you like with Glyphs), but I'm just keeping it simple and using this one. From the link download "Delugia.Nerd.Font.Complete.ttf" and install it on your machine just like you would install any other font using your control panel fonts app.

Modify Your Profile settings, (JSON):

You can get you profile settings by clicking on the Down Arrow menu in the terminal and clicking on settings:

This should open up your profile file. There are a few aspects of the profile file worth understanding:

The profile file holds a collection of profiles. The 'defaultProfile' contains the guid of the profile terminal uses by default when you launch it. Here you will notice that the guid matches the guid of the profile called "Windows PowerShell". That starts PowerShell by default every time I start the terminal. If I wanted the terminal to start the Command Prompt I can replace the defaultProfile guid with the guid of the profile called "cmd".

Now look at the profile named "Windows PowerShell" in the screenshot above. The "commandline" tells the terminal which executable it should use. The Font Face tells it which fonts to use. Delugia Nerd Font is the font we just installed in the "Installing the Right Font" section of this post and that has Glyphs oh my post and post-git need already patched into it.

In the screenshot above I'm setting Delugia as the default font by setting the fontFace with the value 'Delugia Nerd Font'  in all my profiles. The Color Scheme tells the terminal which colors to use. In the screenshot above, My Color Scheme is called "ThousandtyOne" and this is what it looks like:

If you want my entire profile you can grab my profile.json from GitHub here. If you've done everything correctly start your terminal and your terminal should now look like:

It's good looking and the fun part is, it's git aware. Notice the Git integration above. My git strip in the prompt, when I switch into a folder that contains git repository, looks green because there are no changes. Once I make changes the strip changes orange and shows me the number of changes right there in the command line:

Note that all these colors are controlled by  your color themes in the profile file so if you wanted different colors you could totally change the profile file to fit your needs and customize each theme.

I do realize that as far as Windows Terminal is concerned I'm a little late to the party. Here is an awesome post from Scott Hanselman on this topic. Think of this post as just my diary of the issues I faced and a customized version of the profile I am using for myself. If you're like me and spend a bulk of your time in command line it might be a good idea to get windows terminal and work with a CLI that is a little more good looking and slightly more git aware than what you get out of the box.

Go on, make your own gorgeous terminal now and share your profile with others. Time to have some fun with your terminals people!

Note: I did face an issue with not being able to save my profile cleanly with VS Code and VS Code kept complaining about conflicts with older version of the same file. When that happened the changes I made in the profile.json are not having an impact on the terminal. That's an issue with dirty write where if you get warnings about conflicts when you save your profile.json. This link contains a solution. The idea is that every time you have a conflict saving the profile isn't enough. You have to explicitly accept the changes. The link shows you a screenshot of how you can do that.

Malcolm Gladwell is one of my favorite authors. If you have read Blink, Tipping Point and Outliers one thing you love about Malcolm Gladwell is that he is not a self help writer. The suggestions and tips that he provides in his books are purely a side effect of his research and not an end goal of the books he writes. Put simply Malcom Gladwell is a phycologist and a philosopher bundled inside one brain.

Talking to strangers is his book that takes his style of writing to the next level:

From the FBI failing to identify foreign spies working inside the FBI, right under their own noses, to parents failing to see their own kids being molested by their coaches and doctors, this is a book on biases and short comings of human beings and how we are really bad an analyzing people and their true intents.

This is also a book on erring on the side of good and defaulting to a position of trusting people.

If you head over to Amazon one of the biggest gripes that you see people having about this book in the review section of it's amazon listing, is that Malcolm doesn’t provide any ‘solutions’. Take this review on Amazon for instance:

Fascinating facts are revealed in typical Gladwell fashion which keeps the pace moving. But he comes terribly short on providing any sort of value for actually talking to strangers. Gladwell basically says, "Hey! We suck at talking to strangers. Here's some interesting situations that prove my point. But I have no ideas on how to be better at talking to strangers."

The review section in Amazon is littered with these kinds of comments. Looks like the readers are looking for a silver bullet or at least an assorted collection of solutions from Gladwell.

What the reviewers seem to be missing out is that, just like blink, tipping point and outliers, this is not a self help book. Malcolm Gladwell has spoilt his audience by giving them potential solutions in his past books even though the solutions proposed in his past books were always just the side effect of his research and never the end goal.

Gladwell was never trying to reach to ‘solutions’ in any of his books! Non biased, deep and not trying to hard to reach a solution, are exactly the qualities that make his books special.

And this book is no different. In fact, I would argue that this book takes his writing style to the next level.

For me, this is one of the best books written by Gladwell. He brings me face to face with our short comings to understand other human beings. We all think we know our friends, colleagues, relatives, spouse and partners.

We don’t.

In this book Malcolm brings out an important insight: if you are a good person and you err on the side of good, you are bound to make huge mistakes in understanding and talking to strangers and even people you know and love. And that is OK.

In a world where people pick up a book only to find a silver bullet or bunch of solutions that can improve or change them, this is a book that makes your brain take a pause, think hard and have a realization that maybe you are not as good at understanding people as you think you are. The book makes you mindful of your own short comings as a human being and sometimes, just having that mindfulness is the solution.

In a world where every author out there is busy giving answers, we need authors like Gladwell asking the right questions and making us think. To me this is by far one of my top ten books to read and I highly recommend you grab a copy and read it. And if you do, please login to your Amazon account and provide your reviews because most people downvoting the book seem to be missing the whole point of the book.