Theory X and Theory Y

Ultimately- it's deep education that matters

Learn from the Israel PM, my favorite BB sir

It's very important for one to gather the right view about the big picture of the technology he works on but at the same time, he cannot neglect the nitty-gritty of the work. It's like a building architect should have sound knowledge about the basic masonry job or as a matter of fact, some knowledge about the painting or the interior decoration.

However, a mason may not always have to have the knowledge of an architect, but vice versa is not good for a true professional.

Please enjoy my early days' expression about the tech sector,

 

As I was going through Douglas McGregor's Theory X and Theory Y, I was astonished to map them to my own life. 

Let me start with my childhood days. Those days I was really afraid of Mathematics. I could not do well in the maths exam. Then my Mom came to my rescue and she did a little bit of hand-holding. She encouraged me and asked me not to be afraid of it and told me that practice makes a man perfect. From that day maths became one of my favorite subjects. 

This happened in my professional career as well. After a few years of work, I was almost on the verge of breaking down. I loved software, but somehow I was not getting the urge from my inner self. Then my wife did that magic. She gave me all the encouragement I needed. From that point in time, I came back into the industry again. 

I cited these two examples to tell you how a positive attitude and a little pat on the back work wonders. Probably theory Y was long back described in Indian Philosophy. 

According to the Hindu sage Swami Vivekananda

"

Each soul is potentially divine. The goal is to manifest this divinity within by controlling nature, external and internal. Do this either by work, worship, or psychic control, or philosophy – by one or more or all of these and be free.

"

Here I would like to quote Mother Teresa - "There is more hunger for love and appreciation in this world than for bread". 

Being in the software industry for quite some time, I can understand how it feels when someone new in this world faces the wrath of a foul-mouthed manager for not being able to fix the bugs or not being able to understand the compilation and linking error messages. For a newcomer, these may not be easy, but when someone, instead of empathizing with that poor guy, starts castigating him, it becomes more difficult. 

According to the Gita, one of the holiest books of the Hindu religion, a person has four stages in life. First, he will suffer, then he will be thirsty for knowledge, then he will go in pursuit of truth and then he will attain wisdom. 

I think in the software industry as well, a software engineer's first few years are years of suffering. But this period of suffering can be lessened and the thirst for knowledge can be injected by wise organizations. However, for that to happen we need mentors who themselves had gone through these phases.

I would like to add the concepts of intrinsic motivation vs extrinsic motivation here.

Intrinsic motivation is the act of doing something without any obvious external rewards. You do it because it's enjoyable and interesting, rather than because of an outside incentive or pressure to do it, such as a reward or deadline.

An example of intrinsic motivation for a software engineer would be deciphering a piece of a framework code because you enjoy doing it and have an interest in the matter or subject, rather than doing it because you have to prove a point to others or pass an exam.

Intrinsic motivation comes from within, while extrinsic motivation arises from outside. When you’re intrinsically motivated, you engage in an activity solely because you enjoy it and get personal satisfaction from it.

When you’re extrinsically motivated, you do something in order to gain an external reward. This can mean getting something in return, such as money, or avoiding getting into trouble, such as losing your job.

Now, the responsibility lies on the organizations to create a supercharged environment so that the engineers feel that intrinsic motivation - because the environment signals the gene of a human being to go the extra mile.

So here is the conclusion for the middle managers

"Praise more and criticize less" and get the best out of your juniors...

And for all those new comers in the software industry.... remember...

To Win is no more than this... To rise each time you fall...

My presentation on WiFi Security

The Evolution of a matured C++ software engineer

One day one junior friend of mine came to me and asked what he should do to become a proficient C++ developer. And I was stumped. I didn't have any direct answer to his queries. Then I started pondering on this matter and was amazed to know that although there are so many books and articles on C++, but there is hardly anything which will tell a novice what to do or rather what to read to become a matured C++ engineer. Hence I am writing this article to demystify some of the basic things one must be aware of to become proficient in this subject matter. Some of the ideas presented here are common to any software domain, but I have given stress on C++ specifically.

UML Use Case

Before delving into the nitty gritty of the language one should be comfortable with UML use case analysis. Because this is one of the major ways for requirement gathering process. And for a GUI oriented project this gives the developer the pictorial view of the different flow of the application. Or in other words the developer can visualize about the work he is going to produce. Because I believe that a piece of work is done first in the mind and then it is depicted in the actual coding.
But how to develop the skill set for the UML Use cases. The best way to go about this is to think in terms of use cases. One should try to divide any software work into small use cases. The use cases developed this way may not be very complex but it gives the developer the idea of the subject. One should pick up any standard books on UML and formulate the idea. There are free tools available on the internet. One tool that comes to my mind is Visual Paradigm for UML. It has a community edition which is free of cost.

C++ Basics

With the increase in knowledge of UML use cases, the developer should start learning about the different aspects of C++ side by side. He should clarify the ideas about inheritance, polymorphism, virtual functions, abstract classes and so many other things. This may take several months to complete for a person having computer science background, and for one without any computer science background, this may take more time.
Once he is familiar with the basic C++ ideas, now he is ready for an entrance in the industry.

Coding Standard

Before writing a single line of code in a commercial project, the developer should be aware of the coding standards. Besides telling about the indentation and commenting about the comments, the coding standard is helpful in understanding the basic C++ concepts. It gives the developer an idea about how to write a maintainable C++ code. It tells the developer about the naming convention and helps him to understand why long and self-explanatory naming of variables and functions are preferred. Not only that, it also tells one about some of the basic things one should follow when developing C++ code. As an example the following item in the coding standard tells the developer how to delete a heap based pointer.

SomeClass* ptr;
......
.....
....
delete ptr;
ptr = NULL;

So if one always keeps these things in mind, it will become his habit.

UML Class Diagrams, Sequence Diagrams, etc

After learning about the C++ basics, the developer should focus into learning the rest of the UML concepts. This includes mainly Class Diagram and Sequence Diagram. My suggestion for the developer would be to translate any kind of C++ code into Class Diagrams and Sequence Diagrams. Again Visual Paradigm for UML would be a perfect free tool to learn about these things.

C++ Design

Now as the developer has started some coding and as he is familiar with UML, he becomes more or less comfortable with the C++ programming style. But what about the design. This is a very important aspect in any object oriented programming. So my suggestion to the developer would be to pick up some good books and learn about the designing aspect of C++. He may go through books like Effective C++, More Effective C++ and books like these in that series. After going through all these books, one should get familiar with the concepts of Design Pattern. The developer should pick up the Design Pattern book of GoF and become familiar with several aspects of an object oriented project. I also suggest the developer to pick up design pattern books like POSA.

Open Source Library

Now the developer has become a proficient C++ programmer. So my suggestion would be to delve into the source code of some C++ libraries like Boost and Loki. Some of the concepts from these libraries like Generalized function pointer, etc are very interesting.

Documentation

This is also very important aspect of good software. Any software should be accompanied with useful documentation. So my suggestion to the developer is make it an habit to extensively document and comment in the source code. All the public interfaces of a class should be well documented. Along with that a document which will give the bigger picture of how different modules are interacting with each other would be useful. UML diagrams will be a perfect requirement in documentation.
Conclusion

Are these all to become a good C++ engineer? Obviously not. The main challenge lies in how one can traverse from the problem domain to the solution domain; how one can break down the actual problem in hand into classes and modules. In other words how one can visualize the problem and its solution. The UML tools are there to help one out, but ultimately its the responsibility of the person to use that tool.

Hopefully the above discussion will guide the novice to become a proficient C++ engineer.

My Presentation on Thin Template

Thin Template Explained from Somenath Mukhopadhyay