Chakravarthy Parankusam

Manager's Schedule: A manager’s day is, as a rule, sliced up into tiny slots, each with a specific purpose decided in advance. Many of those slots are used for meetings, calls, or emails. The manager’s schedule may be planned for them by a secretary or assistant. Managers don’t necessarily need the capacity for deep focus — they primarily need the ability to make fast, smart decisions. In a three-minute meeting, they have the potential to generate (or destroy) enormous value through their decisions and expertise. Maker's Schedule: (Engineers, Artists, Writers etc. ) A maker’s schedule is different. It is made up of long blocks of time reserved for focusing on particular tasks, or the entire day might be devoted to one activity. Breaking their day up into slots of a few minutes each would be the equivalent of doing nothing. When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two

Your mind can be your best asset or your worst enemy. Train it well.

Inspirational quotes on leadership from historical figures and business leaders: “A leader is best when people barely know he exists…when his work is done, his aim fulfilled, they will all say: We did it ourselves.” —  Lao-Tzu , an ancient philosopher and founder of Taoism “Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” —  Sheryl Sanberg,  COO of Facebook “If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” —  Antoine de Saint-Exupéry ,  French writer and pioneering aviator. “Leaders need to provide strategy and direction and to give employees the tools that enable them to gather information and insight from around the world. Leaders shouldn’t try to make every decision.” — Bill Gates, founder of Microsoft “As a leader, I am tough on myself and I raise the standard for everybod

Why measure? There are a few different reasons why a software engineering team lead would want to track each software engineers individual performance. Fair Compensation Promote individual growth in key skill areas Assess individuals comparative to their team’s performance What to measure ? Ability to write source code that adheres to specifications Peer reviewing other team members work Debugging and troubleshooting complicated issues Process Improvements How to measure ? Here are a few ways to gather the information below Surveying the individuals more senior peers Creating metrics through issue trackers and time sheets Observing the quality and speed yourself Surveying the individuals senior most peers Source:   https://www.jmoses.co/2019/07/08/software-engineering-manager-guide-measuring-performance.html Feel free to share your thoughts in comments below.

You Procrastinate Because Of Emotions, Not Laziness. Regulate Them To Stop Procrastinating! There are two trains of thought – One leads to procrastination and one leads to motivation. And somewhere in between, there is a junction called anxiety. Procrastination train of thought: People procrastinate or avoid aversive tasks to improve their short-term mood at the cost of long-term goals. Procrastination is not a time management problem. It is an emotion regulation problem - we delay activities which might make us feel not-so-good. Procrastination is not laziness. Humans procrastinate because of poor emotional regulation about the outcome of tasks. In short, we often procrastinate because of perceived anxiety, stress, and poor emotional regulation about the completion of a task. Perceived anxieties make us feel ‘not so good.’ The aversion activity is a mechanism to avoid or delay the anxiety and repair the short-term negative mood. Habits like procrastination are a reaction

Famous and interesting laws of Software Development Murphy's Law: If something can go wrong, it will.  Brook's Law:  Adding manpower to a late software project makes it later.  Hofstadter's Law:  It always takes longer than you expect, even when you take into account Hofstadter's Law.  Conway's Law:  Any piece of software reflects the organizational structure that produced it. [OR] Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.  Postel's Law: Be conservative in what you send, be liberal in what you accept.  Pareto Principle:  For many phenomena, 80% of consequences stem from 20% of the causes. The Peter Principle:  In a hierarchy, every employee tends to rise to his level of incompetence. Kerchkhoff's Principle:  In cryptography, a system should be secure even if everything about the system, except for a small piece of information - the key - is pub

[Based on the research done by Triplebyte] Software engineers of all stripes want, more than anything else, to develop their abilities as engineers.  They want it more than pay, more than work/life balance, and more than autonomy. This is probably, at least in part, because they know that every other priority they have will eventually depend on keeping up with the industry. Women Engineers Want Growth, Too (But Also Comfort and Inclusivity) As expected, “inclusive workplace” shows the largest relative difference between men and women engineers. Female-identified candidates chose it three times as often, a far larger relative difference than any of the other common motivators. Great Engineers Are Different From The Best Engineers Great engineers answer “salary”, “impressive team members”, “autonomy”, “fast-paced environment” and “equity” much more. “Autonomy” suggests that these engineers know that they're skilled and can be trusted to work with minimal supervision, a

Changing code with out tests is like doing aerial gymnastics without a net.  What is legacy code? Let's look at the strict definition: Legacy code is code that we've gotten from someone else. Maybe our company acquired code from another company; maybe people on the original team moved on to other projects. Legacy code is somebody else's code. But in programmer-speak, the term means much more than that. The term legacy code has taken on more shades of meaning and more weight over time. What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don't really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking abo

An interesting graphical intro to computers and coding. https://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/ From: Paul Ford (A writer and programmer who is a founding partner of Postlight, a company in New York City that builds Internet platforms and develops interactive products.) Isn't it interesting ?  Feel free to share your thoughts in comments below.

These are the exhaustive list of lessons Julia Biason learnt in 30 years working with software development. Folks who have spent some time in software development can easily connect with them.  Programming Before you start writing code... Spec First, Then Code Write Steps as Comments Gherkin Is Your Friend to Understand Expectations Design Patters Are Used to Name Solution, Not Find Them Thinking Data Flow Beats Patterns The Magic Number Seven, Plus Or Minus Two Cognitive Cost Is The Readability Killer Learn The Basics of Functional Programming Shortcuts Are Nice, But Only In The Short Run Debuggers Are Overrated Think About The Users Testing Software Unit Tests Are Good, Integration Tests Are Gooder Testing Every Function Creates Dead Code Tests Make Better APIs Make Tests That You Know How To Run On The Command Line Good Languages Come With Tests Documenting your code Documentation Is A Love Letter To Your Future Self The Function Documentation Is It

Design Patters Should be Used to Name Solution, Not Find Them Most of the times I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern. My guess is that the heavy use of "let's apply this design pattern" before even understanding the problem -- or even trying to solve it -- comes as a form of cargo cult: "We saw that people used this pattern and solved their problem, so let's use it too and it will solve our problem". Or, worse: "Design pattern is described by Famous Person, so we must use it". Here is the thing: Design pattern should not be used as a way to find solution to any problems. You may use some of them as base for your solution, but you must focus on the problem, not the pattern. "Do a visitor pattern will solve this?" is the wrong question. "What should we do to solve our problem?" is t

Design Differences Between RDBMS and Cassandra NO JOINS You cannot perform joins in Cassandra. If you have designed a data model and find that you need something like a join, you’ll have to either do the work on the client side, or create a denormalized second table that represents the join results for you. This latter option is preferred in Cassandra data modeling. Performing joins on the client should be a very rare case; you really want to duplicate (denormalize) the data instead. NO REFERENTIAL INTEGRITY Although Cassandra supports features such as lightweight transactions and batches, Cassandra itself has no concept of referential integrity across tables. In a relational database, you could specify foreign keys in a table to reference the primary key of a record in another table. But Cassandra does not enforce this. It is still a common design requirement to store IDs related to other entities in your tables, but operations such as cascading deletes are not available. DENO

Document databases are sometimes called schema-less, but that’s misleading, as the code that reads the data usually assumes some kind of structure—i.e., there is an implicit schema, but it is not enforced by the database. A more accurate term is schema-on-read (the structure of the data is implicit, and only interpreted when the data is read), in contrast with schema-on-write (the traditional approach of relational databases, where the schema is explicit and the database ensures all written data conforms to it). Schema-on-read is similar to dynamic (run-time) type checking in programming languages, whereas schema-on-write is similar to static (compile-time) type checking. Just as the advocates of static and dynamic type checking have big debates about their relative merits, enforcement of schemas in database is a contentious topic, and in general there’s no right or wrong answer. -------- Completely agree with the above the statements beautifully put by the author. An in

You will continue to suffer if you have an emotional reaction to everything that is said to you. True power is sitting back and observing things with logic.  TRUE POWER IS RESTRAINT If words control you that means everyone else can control you. Breathe and allow things to pass. Let it R.A.I.N. - Recognize, Accept, Investigate & Not-identify ----------- ​"10% of life is made up of what happens to you. 90% of life is decided by how you react." -Stephen Covey Source: Internet

What information consumes is rather obvious: it consumes the attention of its recipients. Hence a WEALTH of INFORMATION creates a POVERTY of ATTENTION, and a need to ALLOCATE that ATTENTION efficiently among the overabundance of information sources that might consume it. ~ Herbert A. Simon (Nobel Prize winner in economics) Herbert Alexander Simon  (June 15, 1916 – February 9, 2001) was an American  economist ,  political scientist  and  cognitive psychologist , whose primary research interest was  decision-making  within organizations and is best known for the theories of " bounded rationality " and " satisficing ".