Posts

Showing posts from October, 2022

* Null reference

Image
 Null reference is every programmer's nightmare. Null reference happens when an object is referenced without being initialized. Every programmer knows how to solve this error. They also know how to check and prevent this. But most of the times this error creeps in unexpected. In most cases this error is pretty hard to debug and fix. As a concept null means empty - nothing - vacuum. Funny thing is programming languages allow you to pass null around. How can I transfer nothing to you. In real life passing nothing is meaningless. But there is a reason for this in programming. Each program has a logic which dictates when a value is assigned to an object. At the beginning it will be empty. After some event it will have certain value. After some other event it will have some other value and then it will be out of scope and die.  Developer will specifically set null to a variable to indicate there is no meaningful value available at the time. Another aspect is about allocating memory...

Handling problems

Image
  T here are different ways people handle problems at workplace. Company culture and leadership contributes to this behavior. These problems can be work related or personal one’s impacting the work. Denial mode: Similar to popular myth ostrich hiding head in sand, people fail to acknowledge the problems. Or they act as if problem does not exist. This mode manifests in different ways as below. Some time it will be a progression from one mode to another. Not a fact:  Reject the problem by denying the facts of the problem. I did not see it happening. You might have missed something and assumed the issue. These are the responses one gets for raising the problem. No impact:  If you succeed in establishing the fact, then denial is shifted to impact. No, this won’t have any impact. Or it is simple issue. Problem is downplayed. This is denial of seriousness of the problem. Not ours:  Another way of denying is to give reasons. Lot of work pressure caused this issue. ...

Law of diminishing returns and innovation

Diminishing returns is the decrease in marginal (incremental) output of a production process as the amount of a single factor of production is incrementally increased, holding all other factors of production equal.  This is usually used to find the optimum number of team members. If a software feature requires 100 days effort it cannot be completed in 10 days by a 10 member team.  Number of developers does not mean working software. Since software is like crafting something new it does not fall in the same category as assembly line. More number of developers can write more lines of code. But it just increases the complexity. Complexity is directly proportional to number of bugs. All these lead to additional time to production.  Is it impossible to build features faster? Yes, it is possible. It requires innovation. Let us see the problems preventing a team from achieving its potential.  Clarity in communication Solutions are abstract.  Any problem can have multi...