Learning

Quality is never an accident. It is always the result of high intention, sincere effort, intelligent direction, skillful execution , and it represents the wise choice of many alternatives.

My notes from this class: A good situational leader is the one who can quickly change leadership styles as the situation changes. Development levels The right leadership style will depend on the person being led – the follower. Blanchard and Hersey extended their model to include the Development Level of the follower. They stated that the leader’s chosen style should be based on the competence and commitment of her followers. They categorized the possible development of followers into four levels, which they named D1 to D4: D1: Low Competence, High Commitment – They generally lack the specific skills required for the job in hand. However, they are eager to learn and willing to take direction. D2: Some Competence, Low Commitment – They may have some relevant skills, but won’t be able to do the job without help. The task or the situation may be new to them. D3: High Competence, Variable Commitment – They are experienced and capable, but may lack the confidence to go it ...

Here is the synopsis of ideas for the design phase of the project from “Dynamics of Software Development” book. Getting the best ideas expressed and available for analysis is the hardest part of the design process. Unity of purpose: Having a theme for the product means that you eliminate or at least minimize orthogonal values. This reduction can be a painful process, and yes it involves risk. But once you decide what the theme is, you have to sacrifice other qualities that don’t support the theme. Even if they are qualities you cherish that are expressive of your fondest and longest help beliefs.Here the author is clearly indicating the need for the mainline customer scenarios. The need to understand these scenarios by the whole team is essential as the need for them comes in many many meetings during the course of the project. examples Bug triage. How do you choose between fixing a bug and releasing your product? Performance scenarios What are the scenarios you need to o...

I finished reading A Painted House . Luke tells us the story of a rural farm life in Arkansas in early 50′s. Luke is a seven year old who lives on the family with his parents and grand parents. Baseball is his passion and he follows the cardinal games only from a single radio in the house. The dinner table conversations takes us into the family life in those days. Luke’s family gets all of their vegetables from the garden. Luke’s mother helped create and maintain the garden. How nice if you can do this for real, I miss the taste of fresh vegetables that are grown in ones own garden without any pesticides. The family works on cotton fields and employs two different groups of people to help. One group is Mexicans who come from Mexico every cotton picking season. The other is hill people who live in Ozark mountains and come to farm. Throughout the story the author gives a realistic description of many facets on farm life. Their single truck, the Sunday church, women gossip,dinner c...

In any real asynchronous programming projects shutdown and cancel requires a real strategy from the beginning, often times I ended up designing shutdown after I am done with main line functionality. This causes real pain. When we are initially concentrating on the main functionality done we don’t concentrate much on how are going to implement shutdown and cancel functionalities. Sometimes while fixing shutdown bugs I end up redesigning a whole lot of code just to support a clean shutdown. Today while fixing a shutdown bug where we are supposed to handle a notification handle before we can cleanly die I ended up rewriting bunch of code. I should remember this for the future and put shutdown and cancel as work items and allocate time for them.

I worked in testing position testing low level components before I started working as a developer. I believe designing various test cases ahead of coding is very useful. Here is what every developer should do. After finishing up spec and initial design reviews, a developer should create a test module that has signatures and comments for each test that he is going to write once his coding is complete. The tests could include very simple to elaborate scenario tests. I think a developer loses the big picture as he goes deeper and deeper into the coding cycle, its not that he forgets the big picture but the number of details that gets into ahead gets so crowded that big picture kinds of fogs away. In order to keep the perspective and make his code rock solid designing real tests ahead of the time is very essential.

Leap Year: Leap years are years with 366 days, instead of the usual 365. Leap years are necessary because the actual length of a year is 365.242 days, not 365 days, as commonly stated. Basically, leap years occur every 4 years, and years that are evenly divisible by 4 (2004, for example) have 366 days. This extra day is added to the calendar on February 29th. However, there is one exception to the leap year rule involving century years , like the year 1900. Since the year is slightly less than 365.25 days long, adding an extra day every 4 years results in about 3 extra days being added over a period of 400 years. For this reason, only 1 out of every 4 century years is considered as a leap year. Century years are only considered as leap years if they are evenly divisible by 400. Therefore, 1700, 1800, 1900 were not leap years, and 2100 will not be a leap year. But 1600 and 2000 were leap years, because those year numbers are evenly divisible by 400. Leap Second: A leap second is a s...