Okay, okay, I know how the headline feels. I also know how it relates to previous articles about discipline. But consider this a continuation. Take it as a continuation of the journey toward success, and please give me 15 minutes of your time.
The road to success and happiness does not have to be paved with self-deprecation. That is not a feeling that leads to success.
In the previous article, we showed how to think about discipline and what you need to understand before embarking on a project. Today, we will finally look at how to build discipline. We will talk about 3 principles that lead to discipline, and if you follow them, you will have enough self-control for long-term work on your dream. We will talk about consistency, focus, and system.
The principles of discipline are simple; adhering to them is what is difficult, but if you persevere, your life will change significantly.
Let's take a look at how to build discipline. The journey begins in your head, in your attitude. In your attitude toward the thing you are striving for, in your attitude toward yourself.
And you will need to take certain facts into account.
Today, we finally get to the first real skill needed for change and growth - discipline. Discipline is a necessity, a prerequisite for achieving your goals, for becoming what you want to be.
The word "discipline" itself may sound ominous to many, like something we want to avoid. But discipline is the foundation of growth, and in this article, we'll look at how to make discipline our ally.
Self-discipline is not punishment, but salvation.
leadershippersonal development
After luck and talent, today we will look at motivation. You may be wondering what the title means, since motivation is often discussed in management and leadership. We talk about how to motivate employees, we talk about internal and external motivation... Yet motivation is probably the most overrated feeling.
Scatter-Gather is another member of the family of design patterns dedicated to separation of concern. The main benefit of the scatter-gather pattern is parallelization—the ability to perform several operations at once. It is therefore suitable for environments and languages that offer parallelization, have threads, workers, or can run new processes.
In the continuation of the series on factors that influence success, today we will look at talent. If you haven't read the article on luck, I recommend it. Many factors are similar, and I won't explain them again.
However, unlike luck, talent has a practical impact on success (it can be worked with). But what is talent? In my opinion, many people misunderstand talent.
Many people interpret talent as something that gives a person an advantage, and that is not true.
The luck I want to talk about today is not "You're lucky, you won the lottery," but "You're lucky to have such great colleagues, to have such great offers," etc. The former is almost always luck. The latter is almost never. And yet you hear it often...
However, it has very little to do with luck.
In my last article I discussed the rules engine pattern, a pattern motivated by separation of concerns, high cohesion, and low coupling. Today, we will continue with another pattern that supports these principles: pipeline
Design patterns are like tools in your workshop. They can greatly simplify both writing code and the code itself. Today, we will start with examples of patterns specifically related to a pattern called Rules Engine.
The rules engine allows you to improve both separation of concerns and high cohesion and low coupling, thereby significantly reducing code complexity.
"Software architecture is the design of API, database and should be robust and stable."
There is almost nothing true about the previous sentence. Modern software architecture is something very different. It's missing the main thing. What the goal of the architecture actually is.
So what is software architecture?
Many things can be regained or replaced. A house, a car, money - all of that comes and goes. There is a resource more precious than money or gold. Time. Time is a great equalizer; everyone has the same amount - 24 hours a day. There is no way to have more. The only thing you can do is manage it.
Have you ever heard people to say "I do not have enough time"? I'm not talking about work. I'm talking about "I want to go to the gym, but I don't have time.".
Is it worth always "being right"? What does it mean to "be right" in software development? How important is it for a leader to "be right"? When does it all becomes arrogance? Have you ever had to deal with someone who always has to be right?
Explore the points of view of developers, leaders, and architects.
Continuing my previous article, we will discuss scale, support and accidental complexity, types you can manage, reduce and even remove.
Complexity is the primary enemy of software design and architecture. The primary job of a software architect is to remove, reduce, or manage complexity in that order. But what if the problem space itself is complex? How do you do that? What does it even mean? What is complexity, anyway?
There are actually multiple types of software complexity, and each type requires a different approach.
Developers use the word "abstraction" regularly, yet there is limited understanding of what it means. In a broader sense, abstraction has been overshadowed by its use in some languages to denote a method or class that will be overwritten later, as well as the phrase "use abstraction." is understood to mean "write an abstract class.".
Abstraction is one of the most important techniques for achieving decoupling and stabilizing your public interfaces at any level.
There are many ways to create a Modulith, and I will introduce you to one of them. The important parts that we will discuss are: Application layer, Business modules, Facades / Repositories, Event bus/broker, CQ Router and Utilities.
Understanding the roles of these parts is essential to building a code base that won't end up as a "big ball of mud".
The monolithic style has a bad reputation, but it is useful for smaller applications. The problem is not the monolith itself, but rather how it is written.
Why choose a monolith over a distributed architecture, such as microservices? Networking creates its own set of problems. There are benefits, but also costs.
Modular monolith - modulith is the way how to start application.
"You should be loyal to the company, share our goals and align your values with the company's values”. That's not going to happen... Don't get me wrong, I'm not saying "I'm not going to do that," I'm saying it won't happen, it can't happen, it's not possible.
People are not loyal to the company, people are loyal to the people in the company and enjoy the culture created by the people in the company.
Some people think dependency injection should be everywhere and is state of the art. Some people think layered architecture is for everything, and some people think the same about microservices.
Some people think serverless is always the way to go. Everything has to be written in Rust on the backend and VUE3 on the frontend.
Some people think you make one manager product owner, another scrum master, send them both on a 2 day certification, have standup, review, retro, Jira and you are an agile team doing scrum.
All these things have one thing in common: a lack of understanding of values and principles.
Why do you do what you do? What makes you want to go to work? What drives your decisions? What is your professional purpose?
tl;dr - it's not the money.
I firmly believe that there are other values that are more valuable than money. Values that create a better business, a more sustainable business, while actually making money. These values are: customer, team and quality; and they go hand in hand.