The GhazStation https://ghazstation.com Discussing technology, professional and personal development and education Sat, 08 Dec 2018 17:19:32 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.6 https://i2.wp.com/ghazstation.com/wp-content/uploads/2018/01/cropped-gazelle_logo_logo_big-1.png?fit=32%2C32&ssl=1 The GhazStation https://ghazstation.com 32 32 140594149 I am now writing the Software Weekly Newsletter https://ghazstation.com/tech/i-am-now-writing-the-software-weekly-newsletter/ https://ghazstation.com/tech/i-am-now-writing-the-software-weekly-newsletter/#respond Mon, 22 Oct 2018 14:47:37 +0000 http://ghazstation.com/?p=414 Today, I hit the send button for the Software Weekly newsletter. Top tech news, articles, with commentary, all curated by yours truly every week @software_daily Newsletter. Subscribe and let me know what you think....

The post I am now writing the Software Weekly Newsletter appeared first on The GhazStation.

]]>
Today, I hit the send button for the Software Weekly newsletter. Top tech news, articles, with commentary, all curated by yours truly every week @software_daily Newsletter. Subscribe and let me know what you think.

 

Checkout the newsletter and latest editions here: https://softwareengineeringdaily.com/newsletter/ 

 

The post I am now writing the Software Weekly Newsletter appeared first on The GhazStation.

]]>
https://ghazstation.com/tech/i-am-now-writing-the-software-weekly-newsletter/feed/ 0 414
Measuring the Health of Your Application: Why Healthchecks are not Enough https://ghazstation.com/tech/measuring-the-health-of-your-application-why-healthchecks-are-not-enough/ https://ghazstation.com/tech/measuring-the-health-of-your-application-why-healthchecks-are-not-enough/#respond Mon, 06 Aug 2018 17:25:57 +0000 http://ghazstation.com/?p=376 I was inspired to write after reading something on Twitter about how do we define “Health”? Specifically Ia m going to talk about Health for web services Focusing on larger systems with high availability requirements Systems...

The post Measuring the Health of Your Application: Why Healthchecks are not Enough appeared first on The GhazStation.

]]>
I was inspired to write after reading something on Twitter about how do we define “Health”? Specifically Ia m going to talk about

  • Health for web services
  • Focusing on larger systems with high availability requirements
  • Systems that lose money if they are down

Using Health-checks to check the Health of your service is like checking the Health of your car by looking at if the Headlight turns on

Health checks could be a /health API that might run a deep health check or simplify a ping that checks whether service is up or not.

Health checks in the simple ping form, tell you very little about your system. It indicates a single information which is that a certain API is reachable. It doesn’t necessarily tell you about the logic underneath or interactions with entire system/

Deep Health checks, those that potentially hit up your API and dependencies, are an indication of a better health check but they are costly. They might take a lot of time to run and they consume computing resources on your machine. They also incur a cost for your dependencies and therefore your entire system. Those deep health checks are only verifying some of your assumptions about how the system works. They don’t verify the entire system.

Shallow health checks are equivalent to checking if Headlight turns on in your car. If the headlight turns on, your car is healthy.

Deep health checks are equivalent to turning on the engine and revving the engine in your car. If you hear a noise, your car is healthy.

Using the car example, we haven’t really tested the brakes, the steering, the tail lights, the electric system, the air filters, the AC, the sound system etc.

Similarly using a health check for a measure of the health of your service is not enough. It doesn’t really tell you much about if your service is healthy.

Define SLAs for your System

You need to define SLAs for your system. Google popularized the concept in their RSE book but mainly companies have been using SLAs for a long time.

If you don’t have a clear idea of how your system should behave, how do you even define if it’s not doing what it should be doing?

An SLA defines conditions in a steady state of our system. Deployments and failures shouldn’t affect a highly available system. The more concrete our SLAs are the better we know what to expect from our system.

Defining Health

The Health of you system is the total of the health of all its subsystems. I am using the word System over service or application because we must be aware of all the little components of our system. A web service might involve APIs, static content, CDNs, load balancers and hosts it runs on. It might include databases and storage, replication, fault tolerance mechanisms and much more.

The best way to think about health fo your system is to decompose into smaller subsystems and define health for all of those.

Examples of Measures of Health (SLA, SLI and SLO everything)

The list is not exhaustive in any way and is very high level (I might follow up with a different article on this); below are examples of things we could measure to track the health of our service.

  • Backend web service: latency, failure, errors
  • Database: latency, failure, replication lag
  • Load Balancer: number of connections, services available,
  • Host: Disk, CPU, IO, memory
  • Runtime environment:  garbage collection pauses, crashes processes, heap size
  • CDN: availability, latency, failures, errors, cache hits

Hierarchy of Health

In order to define a good Health Monitor for your system, you need to have a hierarchy for your system. This hierarchy structure can run deep. In a very large complex system with hundreds or thousands of components and services, having this hierarchy is important. Being able to measure health for everything, and dive into little components will help you debug problems faster and figure out what’s wrong immediately.

Takeaways

  • Define SLAs for your system and measure them
  • Compose the health of your system into the health of smaller components
  • Monitor everything you care about in your system
  • Have an overarching Health Alarm/Monitor to track the health of your system
  • Health checks are not bad, they are just not enough by themselves

My Tweets

The tweets that inspired me to write this are below. Let me know what you think about Health of your system

The post Measuring the Health of Your Application: Why Healthchecks are not Enough appeared first on The GhazStation.

]]>
https://ghazstation.com/tech/measuring-the-health-of-your-application-why-healthchecks-are-not-enough/feed/ 0 376
Software Engineering Daily: Crash Reporting: Improving the Customer and Dev Experience https://ghazstation.com/tech/software-engineering-daily-crash-reporting-improving-the-customer-and-dev-experience/ https://ghazstation.com/tech/software-engineering-daily-crash-reporting-improving-the-customer-and-dev-experience/#respond Wed, 01 Aug 2018 00:38:43 +0000 http://ghazstation.com/?p=371 New Article is out. Learn about the new advances in monitoring and tools for observability. Check it out here: Crash Reporting: Improving the Customer & Dev Experience  Also check out my other articles on...

The post Software Engineering Daily: Crash Reporting: Improving the Customer and Dev Experience appeared first on The GhazStation.

]]>
New Article is out. Learn about the new advances in monitoring and tools for observability. Check it out here: Crash Reporting: Improving the Customer & Dev Experience 

Also check out my other articles on Software Engineering Daily

Software Engineering Daily: GDPR: Behind the Curtains of “We Updated Our Privacy Policy” Email Floods

Software Engineering Daily: GraphQL: Designing APIs for the Internet of Everything

 

The post Software Engineering Daily: Crash Reporting: Improving the Customer and Dev Experience appeared first on The GhazStation.

]]>
https://ghazstation.com/tech/software-engineering-daily-crash-reporting-improving-the-customer-and-dev-experience/feed/ 0 371
Software Engineering Daily: GraphQL: Designing APIs for the Internet of Everything https://ghazstation.com/tech/software-engineering-daily-graphql-designing-apis-for-the-internet-of-everything/ https://ghazstation.com/tech/software-engineering-daily-graphql-designing-apis-for-the-internet-of-everything/#comments Wed, 20 Jun 2018 14:00:30 +0000 http://ghazstation.com/?p=359 Are you curious about what GraphQL is and how to use it? GraphQL will change how you change aboutGraphQL API design. It will change how you build internet of everything applications including websites, phones,...

The post Software Engineering Daily: GraphQL: Designing APIs for the Internet of Everything appeared first on The GhazStation.

]]>
Are you curious about what GraphQL is and how to use it? GraphQL will change how you change aboutGraphQL API design. It will change how you build internet of everything applications including websites, phones, TVs. It will change how you think about both the front-end and the back-end.

Check out my newest article on SoftwareEngineeringDaily.com to learn how to use GraphQL and design APIs with it through examples.

https://softwareengineeringdaily.com/2018/06/19/graphql-designing-apis-for-the-internet-of-everything/

Let me know what you think about the article and GraphQL. Interested in hearing your thoughts about it as well as any technical topics you would be interested in learning more about.

 


Also check out my previous article on GDPR for SoftwareEngineeringDaily here

The post Software Engineering Daily: GraphQL: Designing APIs for the Internet of Everything appeared first on The GhazStation.

]]>
https://ghazstation.com/tech/software-engineering-daily-graphql-designing-apis-for-the-internet-of-everything/feed/ 1 359
Software Engineering Daily: GDPR: Behind the Curtains of “We Updated Our Privacy Policy” Email Floods https://ghazstation.com/tech/software-engineering-daily-gdpr-behind-the-curtains-of-we-updated-our-privacy-policy-email-floods/ https://ghazstation.com/tech/software-engineering-daily-gdpr-behind-the-curtains-of-we-updated-our-privacy-policy-email-floods/#comments Thu, 07 Jun 2018 13:26:29 +0000 http://ghazstation.com/?p=351 I published a thing!   I published an exclusive article on www.SoftwareEngineeringDaily.com about GDPR and what it means for you as a consumer and as a tech company.   I am hoping to write...

The post Software Engineering Daily: GDPR: Behind the Curtains of “We Updated Our Privacy Policy” Email Floods appeared first on The GhazStation.

]]>

I published a thing!
 
I published an exclusive article on www.SoftwareEngineeringDaily.com about GDPR and what it means for you as a consumer and as a tech company.
 
I am hoping to write more exclusive content for SED and continue writing at www.GhazStation.com as well. Check the article out and let me know what you think. How do you think GDPR will impact your business and consumers?
 

 

While at it, checks Software Engineering Daily’s podcasts. It’s the best podcast for software engineers who are interested in technology and software.
 
Check it out here

The post Software Engineering Daily: GDPR: Behind the Curtains of “We Updated Our Privacy Policy” Email Floods appeared first on The GhazStation.

]]>
https://ghazstation.com/tech/software-engineering-daily-gdpr-behind-the-curtains-of-we-updated-our-privacy-policy-email-floods/feed/ 2 351
With Great Power Comes Great Responsibility In Social Media: The Curse of the Million Followers https://ghazstation.com/uncategorized/with-great-power-comes-great-responsibility-in-social-media-the-curse-of-the-million-followers/ https://ghazstation.com/uncategorized/with-great-power-comes-great-responsibility-in-social-media-the-curse-of-the-million-followers/#respond Sun, 03 Jun 2018 03:15:09 +0000 http://ghazstation.com/?p=332 With Great Power Comes Great Responsibility In Social Media This is not the Spider Man edition or the Voltaire edition. It is not about superpowers or political power. This post is about great power...

The post With Great Power Comes Great Responsibility In Social Media: The Curse of the Million Followers appeared first on The GhazStation.

]]>
With Great Power Comes Great Responsibility In Social Media

This is not the Spider Man edition or the Voltaire edition. It is not about superpowers or political power. This post is about great power that comes from being an influencer, someone who is popular in a specific field and has a following of people online.

The Political Power Responsibility

Throughout time, politicians and civil servants understood that their position allows them so much power and that they must do good with it. They must  step up and take responsibility for their people, for what they represent. Similarly those with super powers are usually similar. When we teach politics we teach ethics. When we read The Prince, we inquire within ourselves about the implications of every action we do. The book don’t address ethics or morality directly, but you can’t be a leader of people without really contemplating the morality of your actions and if you are on the side of good or evil.

The Superpower Power Responsibility

Similarly those with super powers power carry a huge burden to use their super power for good. Bill Gates spends his time and wealth on to cure illness, fight poverty and increase accessibility to education. Ray Dalio spends his time spreading his teachings and giving back to the community. Einstein sent letters arguing for the need to strive for peace and illustrating the danger of war and the atomic bomb.

Our Communities Are Filled with Powerful Responsible Role Models

Our communities are filled with people with great powers who strive to be role models. The head of a religious worship place, the leader of a youth group, a teacher, are all examples of such people. A teacher, a religious leader and a youth leader all know that they hold great power. They might not use it for good, but they know they carry great powers and great responsibilities. Many of them are role models for the people they teach and lead.

Bursting the Bubble

The difference between those in our communities and those political and superpower powerful people is the size of the bubble. If you are a politicians and you interact with other politicians and government leads, you are in a bubble. You need to break the bubble. You need to realize you are in a bubble in order to really care the great responsibility that’s on your shoulder.

Those who are able to see how their actions, their knowledge and power can impact everyone outside their bubble are the true good role models.

Modern Powers with Little Responsibility

Today there seems to be more people under the spotlight who are in power, many who attract huge folllowing and become defacto role models. They are not the explicit kidn of role models you will write about in your common appliation, but they type that is implicit. You have many of these. Many people you follow on Instagram, Facebook, Twitter, LinkedIn, Medium or many more other platforms. This includes heads of states, Youtubers, celebrties, models and company executives.

This is a unique situation where the number of followers you have indicate power you have. You now have power to influence. You are now a role model. People watch you, people follow you. People want to be like you. People observe your life, critique it but also try to embody it in their own lives.

What’s surprising is how many of those powerful people seem to brush off their powers and not realize they are role models. Back in the day, the celebrity scandals were far in between, but now a day doesn’t pass without some news about some very important figure saying or doing something they shouldn’t have done in public.

It’s time to take on responsibility

I think those in power need to realize the power they posses and they must take responsibility for their power or else they must at least acknowledge the implications of not doing so.

Influencers With Great Power and Varying Amounts of Responsibility

I present you examples of People with Great Power and the implications of their responsibility.

I am writing this to show that not every person in power is a good role mode (but that they should). We should only give power to people who are doing good for humaity and we should hold those people to high standards.

Influencers who are tryig to Give Back

The influencers here ackwloedge the amount of power they have and use their infleucne for causes they care about. They are trying to give back to humaity any way they can.

Bill Gates

Bill Gates is one of this influencers who is trying to give back, dedicating his time and money to fight poverty, diseases and spread education.

Michelle Obama

Michelle Obama advocates for girls education and advocates for girls power.

Influencers Who are Not Living Up To their Expectations

Sometimes we don’t choose the superpowers we get, but we get them and then we must use them for good. The influencesrs here have a lot of infleucne whether they asked for it or not, but they are not really trying living up to the amount of good they can do in the world.

Mark Zuckberg

Whether or not he signed up for the role, Facebook is a media company: it’s actually in the name “SOCIAL MEDIA”. Mark Zuckberg keeps insisting that Facebook is a technology comapny not a media company. I think this is shying away from being a true leader, being true change in the world. I urge Mark to consider that he is one of the most infleuntial people in the world and that he has a huge opportunity to change the world (hopefully for the better). Shying away from the opportunity and doing nothing is bad. Staying silent is siding with evil.

Jeff Bezos

The richest man in the world, Jeff Bezos is usually busy thinking about space travel through his company, Blue Origin. I think there  huge missed opportunity to leave a true legacy in the world and really make a difference in ways that could help eradicate diseases, poverty, increase education, etc.

Influencers Who Are Doing It Wrong

Logan Paul

With over 17 Million Followers on YouTube, Logan Paul is the most influential YouTuber and Social Media celebrity. Aside from being really SAVAGE, he took it too far when he found a dead body in the Japanese Suicide Forest. Logan Paul, you have so much impact on younger generations. USE IT for GOOD!

Elon Musk

Elon Musk with 21 Million Followers on Twitter and people who would buy every flame thrower he makes and put money down for a car they never seen, Elon has a lot of power and infleunce with his own fanboy club. Fighitng with journalists and trying to build tunnels in LA without taking into account safety of any of residents in LA or the environment, it seems like Elon’s power is getting to his head and he is heading in the wrong direction.

Influecers Who Acted Too Late

Travis Kalanick

Travis Kalanick, former Uber CEO, was on top of the world, but after numerous scandals at his company, it seemed like Kalanick had a huge opportunity to really speak up and change the state of things specifically for discrimnation and harassment but his the way he handled things really helped spread the idea of doing whatever it takes to win in the business world: a very bad lesson to be teaching people. He did speak up everntually but it seemed forced and it was too late.

Why Am I Writing This

I am really writing this to make us think about how our powers are impacting the world, to let everyone of us consider their legacy. If you have powers, if you are in a position of influence, you can make a great deal of impact in the world. You can make an impact on diversity, on youth, on equality and health. We can make educationa accessible and peace prevelant.

What I want to say is, each one of us has an infleunce and I want to stir discussion about what is the legacy we are leaving the world. I think we should all be thinking about that from a young age. Ray Dalio only started thinking about his legacy when he was retiring, but WHY. Why don’t we think about our legacy always. Why don’t we realize that we could be infleucing people for good or bad.

The post With Great Power Comes Great Responsibility In Social Media: The Curse of the Million Followers appeared first on The GhazStation.

]]>
https://ghazstation.com/uncategorized/with-great-power-comes-great-responsibility-in-social-media-the-curse-of-the-million-followers/feed/ 0 332
Should Everyone Learn to Code & The Struggle of Software Craftspersonship https://ghazstation.com/education/should-everyone-learn-to-code/ https://ghazstation.com/education/should-everyone-learn-to-code/#respond Sat, 05 May 2018 04:50:45 +0000 http://ghazstation.com/?p=321 Should everyone learn how to code and how does this fit with ideas of software craftspersonship? Should we be more inclusive or more standardized? I am a little torn at the moment. A friend...

The post Should Everyone Learn to Code & The Struggle of Software Craftspersonship appeared first on The GhazStation.

]]>
Should everyone learn how to code and how does this fit with ideas of software craftspersonship? Should we be more inclusive or more standardized?

I am a little torn at the moment. A friend stirred a discussion online about whether who should know how to code and the level of competence people should have in order to code. And therefore I am still very torn.

Should Everyone Learn To Code?

I do think that software is eating the world. Everything is software. Software is part of every minute of our lives. It controls everything. If we learned anything from the recent Facebook/Cambridge Analytica fiasco and many other failures of privacy, it is becoming more important that everyone understands how software works.

If you watched the videos of Mark Zuckerberg being interviewed, you will notice that a lot of people didn’t understand how the internet works or how software work. 

Why Everyone Needs to Code?

Now imagine a future, not far from now, where AI is part of our every day lives, where software is part of everything we do and controls everything we do. Hold on! We are already there. Okay so we are there or almost there and we are letting technology take over but we don’t really quite understand it. I mean a few of us do, there are millions of programmers out there but that is still not everyone.

Politicians, government officials, leaders, CEOs and many of our family members and friends don’t quite get how everything about software works. And that is scary.  Remember back in the 1400s how the state was able to control people because only a few elite were able to read. Today only a few are able to read and understand software and that elitism is hurting everyone else. It’s why people get scammed.

How can we make rules about Artificial Intelligence and regulate software if we don’t truly understand it? How do we know Facebook is wrong if we don’t truly understand software? Why is Equifax not getting the same type of scrutiny as Facebook for their data breach?

Software Literacy over Computer Literacy

I am not sure that I know the answer to all the questions but what I do know is that everyone needs to get their hands a little dirty with coding and software. I think educational programs all over need to teach coding as a core competency on equal grounds as English, Math, and Science (social and natural).

I remember being introduced to programming very early on but I didn’t really quite get it and it was too theoretical. It was only a short experiment that didn’t continue at my school. But I do imagine a world where everyone I graduated with knew a bit of coding. What world would that be? Would everyone understand the implications of Equifax data breach? Would people understand how it is a big deal and that it could’ve been avoidable?

I am going to make two claims and I am going to try to reconcile them

  1. Everyone should learn basic programming and coding skills because it is a necessity of modern society
  2. Software engineers who practice software development as a profession should have a regulatory/accreditation   body that ensures high craftpersonship (like preached by Uncle Bob Martin and complained a lot by the Society of Professional Engineers)

Coding & Ethics

Software engineers are in fact engineers. They are serving society and they are building infrastructure for almost everything in our modern society is based on. Software engineers must therefore be held to a really high standard.

If you think about a self-driving car, you definitely would want the best of engineers to have worked on that and made sure there are no flaws in the software system. After-all, the cost of a flaw is human lives. Similarly a structural or civil engineer is held to the same high standard but their standard is actually enforced through regulation and accreditation.

Additionally an electrician installing systems in your house could lose their license if they don’t follow the practices of their profession. Now why is a software developer that allowed millions of customer data out not held to such a high standard?

I am more upset about Equifax breach because I didn’t agree to my data being leaked, while technically everyone didn’t read their user agreement and gave Facebook unlimited access to their data. So really Equifax should be scrutinized and punished more. Many other companies and data breaches should be held to same high standard. Read Equifax was 100% preventable

Professional Software Engineering

I believe that software engineers who take software development as a profession should be held to high standards. I think this is challenging because number of software developers has been doubling since the 40s and it is continuing to grow such that the average experience of a software developer is less than five years. This makes for lack of experience in our industry on average.

Additionally software developers can’t agree on anything. We can’t agree on standards, frameworks or software best practices. Surprisingly though even though some don’t agree and some are trying to reinvent the wheel, its mostly due to lack of experience.

This lack of experience is killing us. We are chasing after the new shiny thing. We are repeating the mistakes of the past. We are coming up with 20 millions languages that don’t really do anything special or improve our lives at all.

There is clearly a lack of mentorship and learning in our field. And when I say learning, I am not learning new languages or frameworks because we excel at that actually. But we seem to not learn to regulate and simplify.

Regulation of Software Engineering

I suggest we need a regulation body to accredit software engineering as a profession. We are professionals. We should be held to a high standard of testing our products and protecting security of everything we build. I think we need to create our own. The Professional Engineering society has failed us because of its strict requirements. We can’t accredit engineers fast enough especially if we need to train them. Additionally we are the generation of the internet and technology and the old methods of Professional Engineering society are old.

There could be classes of software engineers. I don’t think we need to create the same classification for everyone. Just like there is a distinction between an electrician and an electrical engineer and a nurse and a physician on their responsibilities and abilities of things they can do, we can regulate industry similarly with different varying levels. I think start simple and grow from there. In the future I think software engineering would have separate disciplines anyways: database engineering, vs networking vs AI vs distributed systems.

Innovation VS Standards

It is true that nay kind of standarization will limit innovation. Software developers like to prototype and create amazing web experiences and computers games (basically the reason so many people like computers). And I don’t know yet what to do there?! I know we need to help educate people better but also leave a lot of room to break the rules and be creative and do some amazing things with technology. Where do we draw the line?

Teach Everyone to Code but Setup Standards for Software Engineering

Many in the software industry has started talking about craftspersonship (craftsmanship). There is an entire manifesto for it. But it is not enough. The agile movement though good in principle failed us because it was not well standardized understood. We need to standardize software development and we need to do it fast.

I will write more about this idea of standards in future posts. I already wrote about some personal guides for writing software previously here

The post Should Everyone Learn to Code & The Struggle of Software Craftspersonship appeared first on The GhazStation.

]]>
https://ghazstation.com/education/should-everyone-learn-to-code/feed/ 0 321
The Cost of Building It Right the First Time https://ghazstation.com/tech/cost-building-right-first-time/ https://ghazstation.com/tech/cost-building-right-first-time/#respond Sat, 28 Apr 2018 17:19:48 +0000 http://ghazstation.com/?p=305 If you already have experience and you know the right answer, then the cost of building it right the first time is low. This is huge. Having the right answer is extremely valuable. The...

The post The Cost of Building It Right the First Time appeared first on The GhazStation.

]]>
If you already have experience and you know the right answer, then the cost of building it right the first time is low. This is huge. Having the right answer is extremely valuable. The cost of finding problems early on is important. This is why hiring is important. This is why training people is important.

In this article, I want to illuminate the cost of a flawed design during different stages of building a product and then I will extend the idea into figuring out the best way to build products in today’s world.

Cost of Flawed Design at various stages

Design Phase

The cost of finding a problem with the design of a bridge or a Skyscrapper early on is important. Having good engineers find the problem during design process is cheap. Some work will be redone but shouldn’t usually cause too many delays in project. People with experience still makes mistake (It’s the difference between experienced and expert), but finding those mistakes is still easy in the beginning.

Building Phase

Now imagine finding a problem in design during construction. It’s a project management disaster. Some stuff might have to be scrapped. Walls might have to be taken down, beams might have to be readjusted. This is costly financially, usually demoralizing and takes off a project off its plans. This usually happens but the mistakes that are found are small (have to move structural beam a little bit). It is still costly. People with experience can usually come up with solutions to these problems quick. The cost of fixing is large but coming up with solutions is usually not too expensive.

Post Construction/Production Phase

The worst scenario is when a project is complete, but we realize in retrospect a major flaw in design. Sometimes the design flaws are aesthetics such as the Chelsea Wateside Park . Sometimes its a major structural/architectural flaw. There are two types, flaws that are discovered early such as the Ottowa-Gatinuea Bridge and those are not discovered until a disaster happens such as the Florida Bridge Collapse at University of Miami.

The cost of fixing a problem that is discovered after completion of project is extremely high. Sometimes there is no way to fix it and it must be torn down, thus cost is all that wasted money and effort as well as money and effort to demolish. It is not easy fixing a bridge and cost and effort are high to fix something afters it designed and built.

If the problem goes unnoticed, the cost is not just money, but also lives. And human lives are the most expensive.

The Importance of good design

I choose to use the bridge metaphor because bridges are foundational structures of our modern society. Governments, societies and regulators spend a great deal of time regulating the engineering industry, putting a really high bar on becoming a certified engineer in order to design and build bridges. Despite that bridges fail and lives are lost.

I want to make it clear that having good systems to detect problems early is the only way to eliminate the problems of flawed design. There are two things I advocate for: hiring good people and building testing systems to verify things work.

Back in the old days only the smartest were given the tasks for building bridges, because they are important, because a mistake costs lives. But we didn’t just trust those smart people, once a bridge is built, they would roll a huge piece of rock on the bridge to make sure it is structurally sound.

I don’t want to dive any deeper into topics of bridges or structures. The takeaway here is doing it right the first time is important and reduces the risk. The best builders build it right the first time.

Building Your Product: Building It Right The First Time

When you are building a new product, be it a software product or anything else, building things right the first time is very important. I am not advocating over-engineering or overthinking our products. I am simply advocating that building it right the first time is something we should aspire to do, and that it should be a calculated risk.

If you are not risking lives, or a lot of money, you are more free to experiment and break things more. Sometimes you don’t know the answer right off the bat.

But I am not here to talk about experiments. I am here to talk about the cases where we know how to build something. There is a lot of things we know how to build. We know how to build bridges. We know how to build electrical systems. We know how to implant a mechanical device in your heart to keep your heart working. We know how to build software to get us to the moon, and back!

I am going to be make two claims:

  1. that a lot of what we do today, we already know how to do
  2. For those tasks we should get it right the first time

The other claim I am making here, is that there are things we don’t know how to do. We don’t know what product will stick, or how people will interact with new technology X. I believe that those are the things we should be spending our times focusing on and not things we already know how to do.

Example of the App that Can’t Scale

I heard the story many many times. Some people come up with a great idea and they decide to build an App/software to do it. It’s great; people love it; and it becomes super popular. They get funding and decide to expand. NOW HERE IS THE CRITICAL POINT. We have some funding; we need to move fast and deliver value. So here is where the mistake is made.

A lot of companies would choose to not invest a lot in making things work from the get go. We know how to build apps. We know how to build services. There are many tools that do these things. SO MANY! So why is it that Apps crash when they become successful now.

Examples below of bugs inability to scale:

How to Fix It: Hire the Experts

Is scaling so hard? It is, but also it is not. There is so many experts in the area. I think there is a mentality in software that anybody can do anything. That an engineer in embedded system design would know everything about networking or whatever.

It’s WRONG. People specialize and just like any other field, we should strive to find people are are experts in the field. We should hire them; we should develop them ;we can avoid a lot of these outages that way.

I think great software developers know when they don’t know something. Just having a great developer who will speak up, admit what they don’t know, and ask for more resources from management is a great asset. It reduces your cost significantly. It reduces the cost of breaking things in the future. It reduces the cost of failed design.

Every server crash is costing your product a lot of money, as well as engineering effort in order to fix it.

Why can’t we build it right the first time?

How To Fix It: Test It To Make Sure It Works

Sometimes you have some really amazing people that work on your product. And they can go figure out anything. I truly believe those people exist. They are the same people who know when they don’t know something and they go figure it out. They go investigate and learn.

My problem with learning is its not enough. You are a novice now in that area. You are no expert yet. And even experts make mistakes.

So how do we prevent ourselves from making mistakes. You test your stuff. Engineers test their bridges. Using modern software simulations, today’s engineers put their bridges, skyscrapers and submarines under heavy simulated computer testing to make sure their structures are sound. An inexperienced engineer will build something that would break easily, and have to redesign it several times. An experienced engineer will design it right from the get go (usually) or just require minor modifications to make it work.

But even great engineers test their things.

Sometimes a test is just having someone look at it. In construction, multiple people usually need to sign off on a project before its approved for building.

When you are building a product, make sure you are testing it. Make sure you test all the assumptions. test it for user experience. Test it for compatibility. Test the colors of your design. If you expect scale, test your scaling!!!!

The cost of the Flawed Design

We spend a lot of time figuring out the new innovative part of our software. Sometimes its the product itself thats innovative and we spend all our time focusing on testing that (which is good), but we might forget to test the things that we think we know well. well because we all make mistakes.

If you are a founder, or a manager or the lead for a product, you probably spend a lot of your time making sure that the product vision and the innovation behind what you are doing is right.

But don’t forget to hire the right people! And don’t forget that those right people always test their stuff, no matter how small it is!

 

Future work:

In a set of series articles, I am going to publish what I consider “doing it right” the first time means for specific software engineering topics. I hope by doing so, I can help educate others about my approaches. But I also hope that others with more experience can poke holes in my design.

The post The Cost of Building It Right the First Time appeared first on The GhazStation.

]]>
https://ghazstation.com/tech/cost-building-right-first-time/feed/ 0 305
Personal Principles To Develop Software https://ghazstation.com/tech/personal-principles-to-develop-software/ https://ghazstation.com/tech/personal-principles-to-develop-software/#comments Mon, 26 Mar 2018 13:33:09 +0000 http://ghazstation.com/?p=289 I am starting a new chapter in my career. I wanted to write down everything the principles I learned so far to develop software, so I can come back look at them, reflect, change...

The post Personal Principles To Develop Software appeared first on The GhazStation.

]]>
I am starting a new chapter in my career. I wanted to write down everything the principles I learned so far to develop software, so I can come back look at them, reflect, change and add to the list.

My Principles to develop software

On Testing

  • Write tests. Testing is what adds engineering rigor to develop software.
  • Test driven development is wonderful. Start with writing tests for any big APIs/interfaces.
  • If you are touching code that already exists, refactoring or adding new functionality and there are no tests, write tests for first for the existing functionality before writing your new code and adding adds new tests for that.
  • You don’t need to write tests if there is one person only working on the software. The minute you add another person, everyone needs to start writing tests.
  • We test in order to verify assumptions. We verify assumptions about how the code we write works and we verify assumptions about how it interacts with code we didn’t write.
  • Writing tests is a great way to solidify your contract (and is a variation of design by contract development).
  • Understand the testing pyramid. At its base, are unit tests (tests only testing small-ish components), followed by functional tests (big components by using mocks for dependencies/external elements), followed by integration tests (tests for entire component/service), followed by end-to-end tests (testing multiple and large complex systems together).
  • Testing can be a scam. Specifically 100% unit test coverage doesn’t correlate to better code quality. Accepted principle is 80% is good enough (invest rest of time in higher level tests).
  • Integration tests can also be a scam. It’s very complex to test all dependencies and all failure scenarios. Mid-level integration testing is the solution (always heavily draws on design by contract principles)

On continuous integration & continuous delivery

  • CI & CD are one of the greatest contributions to develop software in last few years. Being able to deploy and test changes instantly is what allowed the exponential growth of software technologies.
  • Invest heavily in having build systems build and deploy packages automatically as well as run tests. Automation of full suite of tests should be part of the CI pipeline.
  • Invest heavily in deploying packages to multiple environments. Always have a test stage before your production stage. Observe the behavior when you deploy new changes (and invest in roll-back mechanisms). Monitoring is important
  • Investment in tooling is what differentiates a fast vs slow moving company. with tooling to build, deploy, test, monitor and manage infrastructure, you can do so much more.  try to use on the shelf. don’t reinvent the wheel

On monitoring & observability 

  • Monitoring allows you to determine if your system is healthy. Observability allows you to determine what went wrong
  • Writing software is a small part of the job. Having good metrics, proper alarming and tools to look at logs and figure out what happened in your system are more important than the code or tests your write.
  • If you don’t know how your code is running, you are flying blind.
  • You need to monitor business metrics…constantly and you need to alarm on them. If you are only monitoring functional metrics but not business metrics, you might be missing how customers are interacting with your software and you are practically flying blind
  • Have SLA and targets for your metric. A metric with no SLA is useless. Have measurable metrics and trigger alarm on them.
  • My personal rule is to always be able to tell what went wrong in a system just by looking at alarms. If a dependency went down we should be able to tell right away just by looking at metrics.
  • Must have dashboard with a graph for every metric that has an alarm for it. I should be able to always figure out what is causing a problem in a system by looking at dashboard for < 5 minutes, this is what observability is all about.

On Metrics

  • Sample but never aggregate. Aggregates reduce correctness of data, sampling doesn’t.
  • Events not just metrics, events give an idea of everything that happened, not just random statistics
  • Explore don’t dashboard, be able to dive and figure out what happened and how it related to everything else
  • Event traces, not event strings, must be able to see entire trace of how everything happened in system (and store that). Its important to understand interactions of evenets
  • You can never measure everything, it is wasteful and uneconomical.

On developing software, building & complexity

  • The most common misconception/myth about programming is that the way things are done is the best way”
  • Over-engineering is bad engineering
  • the best engineers simplify their problems
  • Knowing how to break a complex problem into smaller simpler ones is key
  • Always think of layers, think at appropriate layer and dive deeper as you need
  • Complexity in software (just like in engineering or the sciences) is where people spend most of their time. Learning to make what seems complex, simple is key to being a good engineer
  • Building is a way of thinking that can lead to success

On customer obsession, experimenting &  failure

  • If you claim you care about your customer, you must have tools to understand your customer: metrics to track customer behavior, ways to engage with customers, track conversion/frustration/etc
  • Sometimes/usually its hard to find what customer really wants, then you must experiment. Google did this with Marissa Myers back in the days to understand if customers liked color blue vs black vs whatever
  • Experiment and fail. Fail fast. Make mistakes, learn from them and keep improving and growing. the more you can experiment, the faster you can improve.
  • Do the same thing with yourself, try things, experiment, fail and keep trying again
  • Never give up. Start ups fail to self suicide more often due to no market need way more than they do for running out of cash

On optimizations 

  • Without metrics and data it is absolutely stupid to optimize your systems. Always run load test, profiling or look deeply into your business metrics before you decide on what to optimize.
  • It is impossible to get 100% correctness/perfection in distributed systems. Always aim to have high SLA for most of your cases.
  • Try to invest time in improving what matters. Profile to really see where the system bottlenecks
  • For most of the time, readability matters over speed (thats most of the software I have written). Speed matters a lot for a lot of cases, and for those, we still should add readability using comments/proper naming of variables/methods/classes.
  • Whatever you optimize for speed, efficiency, cost, always remember to optimize code readability for the person reading the code after you
  • cant improve if you cant measure. Efficiency comes from measuring
  • Understand your cost

On design & refactoring

  • we should always try to design and think before we write code
  • With experience and learning, one can start seeing patterns for how to design and write code. design patterns are important (not just OO patterns but patterns for testing, for distributed systems, etc)
  • A software design is usually wrong, because it makes assumptions which are usually broken when things get implemented. Therefore know this when you start designing and you start coding.
  • Software designs should be as flexible, extensible and modular as the code that creates the software. They should be able to change and should always be changing.
  • Software design is a process of hypothesis, doing something and acting on it. We must then STOP. We must finish and consider something done. Then we must look back and evaluate it. We then consider what we are going to do next and we optimize our design, improve our hypothesis and act on it. This is the process of Refactoring.
  • Software design is iterative. Refactoring is continuous design
  • Even initial implementation of code is always wrong. It’s always limiting and doesn’t foresee optimizations of the future (and usually if it did see optimizations, they are wrong because they are premature/made up optimizations).
  • We should always refactor and extend our designs and we should always refactor and extend our code; BUT only as the need arises.
  • Never refactor code because it just looks ugly. Refactor code because you are going to add something to it, because you are extending it for some immediate future use. If you refactor for sake of refactoring, you are wasting your time.
  • Never rewrite code (especially without tests to validate your changes). It is always always always better to refactor in place than to rewrite code. Code carries with it, the thoughts of those who came before us and wrote it. It carries hidden edge cases and fixed bugs. Every time you decide to rewrite, you lost all the knowledge inside the old code (despite how ugly it is or how much you hate language X). Rewriting should be for extreme cases only.
  • We must finish and work in increments in order to stop and reflect; and improve therefore (our learning and understanding as well as our code and design)
  • Establishing a domain design (from domain driven design) is one of the fundamental ways to improve how entire teams and organizations build software. This is often overlooked but is truly the hidden secret to well architected software (BELIEVE ME IT IS NOT THE TECH USED UNDERNEATH). How everyone on team communicates is HUGE in determining success of code and business

On documentation

  • The problem with documentation is it becomes outdated really fast. A design document is usually outdated, the minute we start implementing it.
  • The code itself is the best documentation of the system but that is overly complex for someone to be able to understand in order to understand system architecture, so we must put effort in documentation.
  • We must try to keep documentation of whats working at a high level (at a low level documentation is usually useless), this is important if we have a lot of teams/a lot of people working on systems
  • Documentation is very important for APIs and Libraries. It should always be updated
  • Documentation should live with the code. That’s usually how it lives with libraries and APIs but it should be how it is built for large scale systems

On technical debt

  • Everything carries technical debit. Code always has its limitations.
  • As a developer once said, ‘code should have an expiry date’
  • Always try to document and understand the limitations of what you write
  • Verify your assumptions using testing
  • The simplest solution is usually the best design “simplest solution with loosest guarantees that is practical”
  • wanting to try out a new technology is always technical debt. There is always the debt of learning, the debt of hiring people who don’t know the technology and time to onboard them, the debt of finding tools and integrations.
  • Despite how shiny new things are, old things are sometimes better because they are well supported, more secure, etc. We should invest in new technologies and let them grow but we should do that knowing the risk.
  • If you have to make changes in multiple systems to add a feature, your system is bad. This includes multiple classes in same service (mildly bad). It is extremely terrible when software systems require changes in multiple services to enable a new feature. In a distributed system this is the biggest code smell and the biggest thing you should fix. Loose couple microservices, otherwise you just built a big  distributed mess.

On scalability

  • in distributed systems, vertical scaling is burdensome and expensive, horizontal scaling is the way to go. Horizontal scaling is HARD.
  • Coordination is what usually kills things and reduces performance. Building “stateless” software reduces complexity.
  • Simple solutions are usually the most scalable
  • Depend on ‘infinitely scalable’ technologies when you can if you are building applications. This means using S3, DynamoDB and to some extend things like SQS.
  • Event driven software can be better than synchronous software because it enforces loose coupling. Generally using a messaging broker like SQS or Apache MQ allows work to continue at a later time, which is cost effective. (event driven might be harder to debug in some cases though!)
  • testing the scalability of a system is one of the biggest challenges of distributed systems. The important thing is to always try to test the assumption of how scalable your system is using actual tests.
  • test other failure scenarios besides high load, test dependency failures, network failures and infrastructure going down.
  • Serverless is the future. Kubertenes/containers is to serverless  as virtualization is to cloud computing. Virtualization lost and nobody builds datacenters any more (besides dropbox and a few others). Serverless is the future and I would recommend putting effort into using and building serverless than using containers (if you can).
  • Don’t go building your own container orchestration whatever. the winner here is obvious. use Faragate by AWS. Seriously its’ amazing
  • Serverless should infinitly scales, but we should test it, invest in it and think of ways to make it better (Think: serverless elasticsearch)
  • Best ways to scale is: divide and conquer & approximate correctness, add jitter
  • You have to give up durability or consistency sometimes. That’s okay, think about business logic. Sometimes you can add latency and customer won’t notice or care
  • Cheapest function call is the one that never happens. Remove dependencies you don’t need. Simplify your system
  • Adaptive, reactive, serverless seem like the way to go.

On Software topics

  • Caching: Caching is hard, its as hard as naming variables. The two hardest problems in computer science. Add jitter, especially for caching. We usually don’t want all cache entries to expire and try to retrieve data at the same time.
  • On serialization: Serialization will cause bugs, always test. Be careful if you change serialization libraries. serialization is costly. Observe if it causes a bottleneck for your latency
  • AWS: is bomb
  • Serverless is even better, especially with Java
  • On JS frameworks: seriously its overwhelming, someone tell them to stop creating frameworks!!!

On security

  • Security is important, though still usually overlooked
  • Software must be part of the language you use. This is why Java sometimes is very popular because it is known to be secure
  • To develop software means it scales and never goes down, as well as never compromises data of users. Both are important
  • Every software developer must understand the principles of software security in order to be a good engineer. It takes time but is a very valuable skill

On Agile Development

  • Sprint points and estimation usually measure how good we can estimate or how good we can report to managers. They don’t increase to develop software efficiency.
  • Agile processes should be improving efficiency on how team runs (with just little sacrifices for proper tracking).
  • I believe sprint planning should be lightweight and easy and focus on getting priorities for next sprint. don’t believe in estimation at sprint level. Optimize for utilization/productivity of the developers.
  • Estimation is  useful in t-shirt sixes for projects, but estimations are always wrong. estimations are only useful in comparison to each other
  • Pair-programming where two people sit on same screen is usually wasteful. It doesn’t allow engineers to think and then discuss and then code. I don’t like the idea of the two, it’s limiting. Ideas should be triangulated.
  • Working together tightly with other people, sitting closely and bouncing off ideas all the time is the best way to code.
  • Coordination and communication is always the biggest overhead

On team culture

  • I believe in philosophy over doctrine (we should strive to test when it makes sense, rather than we must always tell)
  • Conventions are good, they especially help establish a base for everyone both junior and senior on the team
  • Enforce rules using automation: check-style, code coverage etc. I think it’s absolutely useless and wasteful when someone makes a style comment on code
  • code reviews are generally good (for growth of junior developers especially). They are pointless sometimes and I hate when they block meaningful work and progress.
  • The biggest blocker internally within a team are usually code reviews. Always build a system in team to reduce the blockage of code reviews.
  • give everyone responsibility, diffuse responsibility. Everyone must try everything. nobody should be doing the same thing over and over (since that concentrates knowledge and limits its expansion)
  • Be humble. Listen more, talk less. Ask questions, talk less.
  • Wise teams have a diversity of opinions and independence
  • There is no one-fit-all developer, always find team fit, product fit and a vision fit
  • Organization matters. Having a vision matters. Having a manager who believes in you matter.

On mentoring and growth

  • Create guidelines for mentorship
  • Set specific goals
  • Allow people opportunity to grow and make mistakes. Sometimes its hard to see people struggle but we must let people develop their own ways and figure things out in order to grow (because usually that’s how we ourselves learned also).
  • Giving the answer right away is not good, people might think differently, the situation might be different and people might come up with better ideas (instead of go use X caching technology, allow person to investigate and figure out the best solution themselves).

Things I want to do more this year:

  • How to design and build simpler software for complex problems
    • Ants: Don’t build software that require leaders. ants don’t have leaders but they coordinate with each other just by passing knowledge in surrounding (ants around them). There is no global communication of ants. Messages are broadcast one by one. Ants are simple and that’s the way
  • Use Akka for writing actor model software and how it can be used in distributed systems
  • Learn Go and Koltin for Java
  • Running better chaos engineering: resilence

Do you have any ideas for things you learned/think are important

 

The post Personal Principles To Develop Software appeared first on The GhazStation.

]]>
https://ghazstation.com/tech/personal-principles-to-develop-software/feed/ 1 289
Keys to Success: Lessons from Multi-Generations of Successful People https://ghazstation.com/personal-dev/keys-to-success/ https://ghazstation.com/personal-dev/keys-to-success/#respond Sun, 07 Jan 2018 03:09:38 +0000 http://ghazstation.com/?p=268 Do you want to learn the keys to success from families that maintained generations of successful people. When you think of success, you usually think of the likes of Bill Gates, Warren Buffet and...

The post Keys to Success: Lessons from Multi-Generations of Successful People appeared first on The GhazStation.

]]>
Do you want to learn the keys to success from families that maintained generations of successful people.

When you think of success, you usually think of the likes of Bill Gates, Warren Buffet and Mark Cuban. Indeed, those guys are very successful and there is a lot of focus on the their keys to success in online and in books. The lessons of those rich and famous are important, but sometimes they are not transferable because we are specifically measuring their success by their fame and wealth.

Instead we can learn more about how to be successful by learning from those who were able to cultivate success in their families for generations.

I am going to make two important points before I share the keys to success

  • Success is not measured only by your fame
  • Success can be taught

How do we study success today

Today there is a lot of focus on learning from the success of the famous. Everyone seems to want to learn how Mark Zuckberg hit gold with Facebook or how Kylie Jenner became a fashion icon. As I mentioned before those people have traits of successful people, but they still get lucky.

What is Success

Our study of success is always about fame. Even we study successful scientists and authors, we have to touch on their fame as a measure of their success. Think about successful people you in history and science Aristotle, Tesla, Newton, Einstein, Nicolo Machiavelli, Shakespeare and many others.

In today’s world, we focus on famous rich people. In a way, this makes sense, since popular culture is a major part of modern society.  Even in niche fields, we tend to focus on the famous rich people in those fields (niche pop culture).

By themselves, money or fame could be a success criteria for some people. But neither is the only way to be successful. Everyone can define their success differently. Success can include other things like having a lot of friends, or starting your own company or helping people in your community.

Success is personal and has a unique definition for each person. What we want to focus on is teaching the keys to success.

Success Can be Taught

Our society today widely accept  that keys to success can be taught (Gladwell popularized The Story of Success to some extent). That’s usually the reasonable explanation for why self-help books are popular and people spend great lengths studying the ways of the successful ones (apparently these book will make you successful).

The distinction that I want to make is that those who repeatedly are successful should teach success. We usually focus on those who repeatedly succeed ( A good case study is how many people follow the PayPal Mafia for their continued trends of success).

But we can learn success better from those who are actually able to teach it to their children, grandchildren and their grand-grandchildren instead of learning it from the failures of Ray Dalio, Bill Gates or Warren Buffet.

Affluent Bluth Family photo Keys to success

The Keys to Success of generations of Successful People

The Old Money Case study

We are going to use wealth as a measure of success, specifically families who maintained wealth in their family of generations. They are usually called Old Money. Again wealth is not the only measure of success but it’s one of the best case studies.

If we can learn anything from the fictioanl Bluth family, being rich doesn’t mean your children will be rich.

According to the Williams Group wealth consultancy,  70% of rich families lose their wealth by the second generation and 90% by the third generation. This is troubling. This means that many rich people fail to understand what made them successful and pass that on.

There is a few people who understand what made them rich and successful and they continue to teach that to their children.

Rich parents of generational rich-families share many of the lessons below  with their children. Remember these are the people who are able to keep up their wealth for years. They are still lucky by they do things to increase their changes of success.

Money Left Over generation (Source: Williams Group wealth consultancy)

Lost Money over Generations Keys to success

Keys to success: keys to live life, not make money

The keys to successbelow is that they are about how to live life, how to be a good person overall. They are simple rules, that those people follow and helps them be successful people.

In contrast to the traditional mindset of doing things differently to accomplish results, these successful people keep doing the same things over and ovet to reach their goals.

Old money’s children are usually very successful doctors, lawyers, business men and politicians.

They embrace less is more

This is very useful advice if you want to run your own business or be successful in any field. You need to be mindful about your resources and think about how to spend them to get the most gain.

This means prioritizing your time and efforts. It also means not spending money on anything you don’t need.

They focus on quality over quantity

Old money are known for wearing the same old clothes, passed down from generation with great pride. They invest in quality shoes and wear them for 20 years. Most of us don’t do that. We waste our money buying new clothes every season. We don’t really invest in quality.

This means investing in quality education, housing and relationships. You will find many rich people who drive old F-150s (actually most popular car for millionaires). Next time you think about spending something, think about its utility. Try to put your efforts, time and money into quality things that will pay off for years to come.

They create long-term roadmaps

The most successful families have well throughout plans and rules. They have missions statement and bylaws for their families (you don’t get any money until you are 30 except for college, etc). They also have long term vision and think about the future.

Professional American athletes are notorious for going bankrupt soon after they retire or lose their contracts. That’s because they think of the short term and not the long term.

This means thinking about how your decisions today affect you in the future. This is where concept of compound interest becomes important. It means starting learning something a year earlier, you exponentially become better.

Invest in yourself early. It will pay-off and it will pay-off a lot.

They are modest & humble

Successful rich legacy people know that they don’t know everything. They know that there is so much unknown. They are modest and humble about what they don’t know. Even geniuses know that the unknown is vast.

They know they are privileged. Therefore they are modest.  Money doesn’t define them but their values and beliefs do. Therefore, they work hard to enlist modesty and humbleness in their children.

Being humble is a key to success because it allows you to reflect and be conscious of your role. It allows you to stay humble and open.

They are open-minded

Knowing that you don’t know much is humbling but it takes open-mindedness to accept new ideas and see life in a different way. Ray Dalio preaches this in his book. He learned through tough experience that open-mindness is a key to success.

Successful rich people teach their kids to be open-minded. They teach them to think about new ideas, new ways to evolve and how others think. Being open-minded is hard but it is one of the most important things to success. They know that they can be wrong.

It is surprising that many old money people are always described as successful but only recently do we come to realize that it is a true trait of a successful person. Ray Dalio spent years to discover that trait.

They are educated and well-rounded

Those people care about education so much and spend a lot of money and effort to educate their children. They specifically also diversify their education into sciences, arts and sports.

Successful people must invest heavily in their education. There start early and spend a lot of time trying to improve and get better. Specifically studying the classic history of those successful who ame before us is important. It’s free life experience in a way.

They appreciate luck and are thankful

Many old money appreciate their luck: they understand it and they value it. Money and affluence came to them on a silver spoon and they don’t forget that. They appreciate it and are humble about it.

They are thankful. Many rich people like to send thank you cards after each invitation and after each dinner. It is not because they are trying to show-off. Instead, it’s because they know they are truly lucky and they want to share their appreciation for others.

They spend time with their family, friends and community

Old money seem to have strong values in family and friends. They keep their family and friends close and only have a few quality friends.

Also a lot of old money believe it is their duty to serve their community. It is their most important goal in their life. They spend money and time volunteering and helping out their local community and charities.

Most importanlty they like to be surronded by other hardworking people like them.

They work really hard

Contrary to what you might believe, those people work really hard. They work 12 hour days and spend sundays with the family. They know that they must work to improve themselves and to become successful. Hardwork is necessarly to progress and improve in life.

Old money don’t wait for money from trust funds, but they always go on their own to work and bring their own money. Hard work is what builds character. Contributing to society is important and necessary.

Are those people real? They are not the rich people I know?

They are probably not the rich people you know. People use the term ‘Old Money’ usually to study those people who are able to keep their money for generations. I don’t like the term per-se but in reality old money are people who can keep their money for generations. The cultural divide between old money vs new money is mainly due to tradition that will keep the money in the family for years to come.

In a way the thinking of those with old money helps them become successful as their family grows.

The above keys to success apply really well if you want to be a well-rounded successful person.

Old money is about values, priorities and habits. surprisingly all those things translate to success.

 

I would love to hear your thoughts about this below. In future articles, I will add more insights into each of the keys to success individually.

The post Keys to Success: Lessons from Multi-Generations of Successful People appeared first on The GhazStation.

]]>
https://ghazstation.com/personal-dev/keys-to-success/feed/ 0 268