Skip to main content

Posts

Showing posts from July, 2019

Managers and Makers

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 pieces each too …

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

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


Inspirational quotes on leadership

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 everybody; however I am very caring because I want…

Measuring a software engineers performance

Why measure?

There are a few different reasons why a software engineering team lead would want to track each software engineers individual performance.
Fair CompensationPromote individual growth in key skill areasAssess individuals comparative to their team’s performance
What to measure ?
Ability to write source code that adheres to specificationsPeer reviewing other team members workDebugging and troubleshooting complicated issuesProcess Improvements
How to measure ? Here are a few ways to gather the information below Surveying the individuals more senior peersCreating metrics through issue trackers and time sheetsObserving the quality and speed yourselfSurveying 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.

Procrastination to Motivation (Regulate your emotions)

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 to the idea of compl…

Famous Laws Of Software Development

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 public knowledge.Linus's Law…

Want to hire the best programmers? Offer growth

[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, and “salary”, “fas…

What is legacy code ?

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 about m…

Software Development Lessons (learned the hard way)

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 CodeWrite Steps as CommentsGherkin Is Your Friend to Understand ExpectationsDesign Patters Are Used to Name Solution, Not Find ThemThinking Data Flow Beats PatternsThe Magic Number Seven, Plus Or Minus TwoCognitive Cost Is The Readability KillerLearn The Basics of Functional ProgrammingShortcuts Are Nice, But Only In The Short RunDebuggers Are OverratedThink About The UsersTesting SoftwareUnit Tests Are Good, Integration Tests Are GooderTesting Every Function Creates Dead CodeTests Make Better APIsMake Tests That You Know How To Run On The Command LineGood Languages Come With TestsDocumenting your codeDocumentation Is A Love Letter To Your Future SelfThe Function Documentation Is Its ContractIf A Function Description Includes An "An…

Design Patterns are not solutions

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 the real …

Design Differences Between RDBMS and Cassandra

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.

DENORMALIZATIO…

What does schema-less mean for a document database?

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 interesting exce…

Learn to Respond, Not React

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

A Wealth Of Information Creates A Poverty Of Attention

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 economistpolitical 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".