How To Learn More

 How to Learn More - An Info graph

 

 

Back Again To Blog

 It has been a while since I wrote anything.

Almost like three years since I wrote something useful, meaningful. (this is debatable, you could argue that I never wrote anything useful which I will flight to prove you wrong, but I know you will eventually win ;-))

I can blame "the busyness" at work, health, personal life (everyone has everything, but they still do it)

The processors are never idle. When they do not have any instructions to run, they kill the time by doing "No operations" - an idle task.

How one can kill time - by idle, thinking about things that are non-existent, neither useful, imagination of future (leading to anxiety) and retrospection of the past (leading to guilt, anger) without any concrete outcomes. Killing time is by hobby. Oh no, it started as a hobby eventually I have become a subject-matter-expert

The truth is - I have not been reading as much as I could (which equals to reading nothing).

For me, the confidence level takes a hit, when I stop learning. Regaining confidence takes a time.

 What i m going to do - read stuff on the things I have been doing recently and probably learn doing things at scale.

Building a Tribe - Sweet Spot

Building a "Tribe" is much more important than anything else. 100% of the time, "The Tribe" gets done everything, always delivers more than what is stated. It takes a while for the tribe to get there, but once the tribe reaches there, the tribe fires all cylinders - it is called the sweet spot.

Random signs of sweet spot:

1. Individuals support the tribe without being asked
2. Individuals care for the tribe than they do for themselves
3. Individuals believe that they can do anything (comes the confidence they have on the tribe)
4. Individuals believe that they can influence the outcomes
5. Communicate well
6. Organize themselves better
7. Happy to downplay, happy to level-up
8. Blunt and cut-throat in saying what they feel (never gets ashamed of saying something)
9. Feel reduced without their tribe
10. Share (credits, knowledge)
11. They do not need managers, they manage themselves
12. Try to create a "Zero Entropy" system
13. Keep reinventing
14. Grow themselves and the tribe
15. Gossip less

Hashmaps - Python

It has been a while that I wrote some code. Been learning Python using Udemy for some time. Python is truly expressive and batteries included language. I read about Hashmaps and thought I should give it a try. Within a very short duration (say 1 hour), I was kind of able to complete full hashmap implementation along with basic tests using PyTest. My coding screenshots. You can also check out my GitHub (that has Jupyter notebook file)

Visualization in Python - Case Study: Urban Accidents in India

I was reading a news item related to accidents and wanted to explore more. With a bit of search, I landed in Govt of India Data website. The website had so much data and visualization in different industries/areas. With another double down, I managed to download the data for Urban accidents in all Indian states.

With a couple of hours of staring at the data and coding, managed to pull out the following charts. The data had absolute numbers for each state and I had come up with a ranking on the following KPIs (had to download population data from Wikipedia according to 2011 census report)

1. Number of urban accidents
2. Percentage of accidents with a weighted urban population

Feedback loop: Data -> Information -> Insights -> Business Transformation

Tools Used:

1. Python (no Numpy or anything else)
2. Matplotlib for visualization
3. Jupyter to cook Python code quickly

Source code and visualization can be found in my github repo

Questions:

1. Why GA has more accidents than TN? (why??)
2. Why HP has more accidents than PY? (terrain?)
3. What can be done to minimize accidents?

Visit www.geekshub.in to know more and learn more on Python/Go/Cloud/Cloud Native/Javascript

GeeksHub

As some of you know that I used to do the mentoring of students to improve their employability at a personal capacity. I thought I should give a formal structure to it as I continue to create impact. We are seeing career transformation and the time is just right.

I am merging my contributions in mentoring through GeeksHub, where I will be serving as an advisor. GeeksHub is an upskilling company primarily targeting entry and mid-level software engineer to improve their hard skills (coding, technology and related). You can find more about them here

I will continue to use this blog for technical/technology discussions and others related to technology. I will refrain posting general stuff related to life (but you never know)

More on GeeksHub in next post :-)

Attitude to Learn

A new thing resets competency and level sets the competition. People sitting near the fence waiting for "right time" to jump in and take a dip often end up being a latecomer and take up what is leftover.

There is a clear advantage of being a lifelong student. Learning pays linearly, the attitude of constant learning pays exponentially.

Agree?hashtag

Master, Expert and Machine

To build something new, you need a master. To improvise something that is built, you need an expert. To run something that is already built/improved, you need a machine

The points are:

1. To build a software you need a master, to sustain it you need an expert and to operate it, you need a machine.
2. To build quality you need a master, to improve it you need an expert and to just regress the past, you need a machine

These are phases and need not be necessary done by different people. The skills required diminishes as we traverse the phases (so are complexity)

Build -> Sustain -> Run requires Master -> Expert -> Machine

Upskilling is the mantra

The future needs a functional guy – someone who sees the customer and her pains.

DevOps is more than set of tools, a framework to add business value and reduce customer pain. Someone who can respond to pain like a doctor in emergency not just taking a note of the situation.

Cloud developer is not just a developer. The fast paced world needs him to be everything. He needs to be “Agile” – groom his stories, make an initiative to understand the business requirements, develop them into a piece of functionality, test them, automate them so that it cries when something is broken, document everything that needs to be and act on the feedback. Be a positive feedback machine.

I don’t want to be a dev guy and I don’t want to be a test/automate. There is no space for someone who wants to sit in dev or test and just do what he is skilled at. The newer world needs someone who gets excited to jump on the unknown and gets the hands dirty and quickly build expertise (just what is needed).

Overall, an outcome based, customer focused tribe capable of scaling horizontally and vertically over a period of time.

Upskill is more of mindset than a skillset

So, Upskilling is the mantra

Get, Set, GOLANG

[Reading Time: 3 to 5 minutes]

[Edited] Reposting this as i have decided to change the book.

Looks like programming languages are sweeping the internet today. Ever since the programming languages were introduced, the pace of new languages was rising gradually. Today, we are seeing a higher pace of several new and promising languages. Python and Go seem to take up cloud software development quite strongly. Python has been around for a lot of time. Go seems to pick up - offering ease of development comparable to languages like Python and giving a speed of execution of that of C/C++. From now and for next few months, I have to ride two horses - learning both Python and Go. I have to admit that I cannot put off my temptation (which I kept off for last three months).

Go in Action by William Kennedy
and Others

Similar to Python, my goal is to become fluent in Go. I am not sure of the timeline but I do see a compelling need to be good in Go in near future. I would like to take up this self-learning of Go by reading books and trying out exercises in GitHub. Having decided to learn Go, I was searching the internet for where to start. There are several good books out there. Go in Action is one among them which was highly recommended in a couple of forums. Being decent sized book (not too small or not too big) and based on my first impression after reading the table of contents, I feel that it would provide a good start in my journey.

It consists of 9 chapters (270 pages). The chapters are said to be designed in such a way that an intermediate programmer can get best out of it (the audience the folks with some programming experience but new to Go, so no boring stuff). This is a quite a promise to keep up. I am excited to ride two horses.

Let us see how it goes. I am excited to learn Go and share my reading journal with you on Go :-)

There is another language that is creating so much noise - Rust. Check it out. If you are a C guy, you have to watch out Rust (hoping that I will not jump the gun in learning Rust)

Note 1: You will see "Reading Time" in all my posts. I want to alert you how much time you are likely to invest reading my posts so that you can decide when and whether to read the post.
Note 2: My goal is to keep it short and give you links in every page to read posts relevant each post

[Update after reading first chapter and reading the second chapter after half way through]
Looks to me that Go In Action has taken the learning in a different perspective and I am certainly feeling little tired to get past each sections. Somehow, I feel this should not be my first book on Go and I am going to switch to another book - which probably offers step by step in small increments.

Unit Tests - Are they important?

While I was going through some of the projects in GitHub, I found that almost all the projects have automated unit tests (I hope you will also see many of your projects have that. These days it is quite common to start off by writing tests first). These tests are run most of the times - before every commit, after every commit, nightly tests and at various stages. These tests are a critical and important piece in CI/CD. Tests, in general, are the cornerstone to software development. The tests are proof that the specific part of the software is working correctly and consistently.  In this post, I am going to talk about unit testing and in subsequent posts show some examples (in Python but you can find similar tools in other modern languages)

What is testing?

It is the systematic exploration of the subject and verifying all the aspects of the subject is intact. It is the philosophy that a faulty brick is responsible for bringing down a massive building. The main purpose of testing is building quality (correctness and consistency) and the side effect is "defects". 

What is a test case?

A test case is a scenario which ensures that a certain aspect of the subject works as intended (or does not work which becomes a defect). When you change the condition, it is altogether a different scenario. A test case with the correct result is the proof that the system works fine in a specific scenario. A test case is narrow (in the sense that it verifies only a specific part/function), to the point and repeatable. It is concrete, it improves confidence and it builds quality.

Top-down approach

When you test a bigger piece, it is often challenging to find out the boundary of the piece. As you explore, you tend to get a feeling that the bigger piece is expanding as you explore (and often never-ending as you come to know more about the system). It quickly gets out of control. The top-down approach (knowing the bigger system first and then decomposing it further, keep working on it until you come to a unit) is time-consuming and tedious to do in all situations (someone fixing a small bug needs to communicate why she has fixed that brick), and delaying the validation of a unit until bigger piece is built is ineffective.  The top-down approach should focus on the problem domain and wider aspects/functions much at a higher level.

Bottom-up Approach

This is not to say that top-down approach is wrong. Rather the top down is not sufficient or it is sufficient but fixing it when the system is developed fully is going to hurt the product in many ways (very likely). It needs to be complemented by the bottom-up approach. Write your "unit of code" and while you are writing your "unit of code", write your own tests. It is even better if someone writes unit test code for your unit of code. The top-down and bottom-up are two different perspectives of the same system (the first perspective is system has components and the second perspective is the components make the system)

What is a unit of code and unit testing?

This is a very vague term, often confusing and means different things to different people. We can consider a unit of code as "smallest possible amount of code that can be tested". You can call a function as the unit (like the ones that we are going to see tomorrow) but then the entire main() function where your application runs is too big to be called the unit of code. So, apply your mind when deciding how smaller or bigger is the unit of code.

A unit test is a scenario (setup, input, output, validation, cleanup, and reporting). Each unit test will have certain environment or conditions that are assumed to be present, input values, output returned, the validation that proves that the test is passed or failed, cleanup and finally last but not least reporting the success or failure.

When the unit test suites/cases can be run?
It is an absolute must that a developer writes unit tests before she writes production code. It is the test code that is to be written first and runs or at least while you are writing your code (writing test code after you commit your code is the biggest sin that you can do to your code). The idea is to break the software and keep fixing it. With that philosophy, it is a critical piece in software development. The unit tests have to be run successfully during the development stage (numerous stages and numerous times), before the code is committed, after the commit and nightly builds.

Why automated unit tests?
If you look at the above point, it stresses the importance of running them all the times. So, it becomes easier (and productive too) to write/automate once and run millions of times throughout the life of the product. So prefer automated unit tests over manual.

In the above analogy, unit tests are certainly examining each and every brick that they are good. The other forms are testing ensures that the joints between bricks are correct, the walls are correct, all the room comply with the requirements and overall the building is a masterpiece.

In the next post, we will start off with a simple example, learn the trades of unit testing and learn Python's built-in "unittest" module.