Wisdoms for IT professionals and all others
Below are some wisdoms and life experiences that have played a role in my personal life as well as in my professional life.
#1: Many things take longer than you initially expect
When it comes to large, complex, or time-consuming projects, it’s impossible to consider all the details in advance. Unfortunately, this also means that the total time required cannot be accurately estimated. That’s why you should take small steps, gather knowledge and constantly re-evaluate the time required.
#2: Reduce cognitive load wherever possible
No matter the topic, make it as easy as possible for your readers, listeners, and viewers to follow you. Whenever something is easy to follow, it’s a sign the creator has put a lot of thought into it and invested a lot of time. In other words: Take the effort on your side as a producer and make it as easy as possible for the consumer.
#3: Be careful what you feed your thoughts
Thoughts are sometimes followed by action. If you feed your mind the wrong information, you quickly develop false goals that make no action right. Social media and very big companies show us this every day.
#4: The power of a simple, clear “No”
There are situations where it’s better to invest your energy in a clear “No, we won’t do that” than in a solution that will never meet the requirements. Software and programming are no way to avoid conflicts that must be resolved. Saying “No” can be the hardest task in life.
#5: You always pay with something
Everything has a price. Common currencies include time, health, money, data, attention, anger, loneliness, and many more. You always pay the price – whether you want to or not, and whether you admit it to yourself or not.
#6: If it is free, you are the product
Free products or services from a company are ultimately worth it for the respective companies. You’re doing something of value for them. For example, you’re giving them personal data.
#7: Think carefully about how you invest your time
There are an incredible number of ways to invest your time. The options seem endless, with countless companies demanding our attention and, therefore, our time. But time is precious because everyone has a different amount available.
#8: IT is rarely an end in itself, it helps other disciplines
In most cases, computer science helps other disciplines like finance, logistics and medicine. This is practical, applied computer science. So, you should be there for others, support them with your skills, and not insist that you’re just a computer scientist.
#9: Many topics are cyclical
Many topics have existed before, disappeared, and then reappeared. They must be viewed and evaluated in the context of the respective time. Sometimes it helps to open the history books.
#10: Knowledge, experience, being able to act accordingly
All the expertise and experience are useless if you can’t act on it. Other people often make decisions based on numbers about topics they know very little about. This prevents contemporary quality from being achieved.
#11: Prototyping whenever possible
Prototypes provide solid foundations for future work. Without prototypes, everything remains a big theory. Therefore, prototypes should be developed and discussed as often as possible.
#12: Complex systems evolve from simple systems
Simple systems can evolve into complex systems. This is due to the experience gained step by step. However, this doesn’t mean that a simple system has to become a complex system. It’s better to keep things simple wherever possible. A complex system rarely becomes a simple system because no one wants to lose data, power, opportunities, etc.
#13: First data, then algorithms – don’t forget security
In our age of big data, data lakes, and more, Robert Pike’s rule No. 5 applies more than ever. First, model the data, and then the algorithms will emerge automatically. In contrast to the time when Robert Pike formulated his rule, today there is an additional requirement: security.
#14: Data is sociable
Data quickly leads to more data. More data is the consequence of the phrase “simple systems can evolve into complex systems.”. That’s why you should always leave the door slightly open so that you can open it further if necessary.
#15: Never change a running system
Good: Do the right thing and avoid things that are unnecessary. Bad: This phrase is often used to ward off change and progress. The sentence “If it ain’t broke, don’t fix it” falls into the same category.
#16: Immutability eliminates many problems
Many runtime problems arise from states, their changes, and a lack of consideration in programming. Therefore, states and their changes should be modeled as best as possible. The use of immutable classes in object-oriented programming is designed precisely for this purpose.
#17: Divide and conquer first, then put together
Divide and conquer is a key universal concept that helps solve an incredible number of problems. However, one must be careful not to lose sight of the bigger picture. This happens quickly, especially in large projects with many sub-projects.
#18: Software erosion is real and unstoppable
Software is initially developed and then often maintained. This means bugs are corrected and new features are added. This inevitably reduces maintainability, which must be accepted as a simple fact. Countermeasures are only possible to a limited extent. At some point you have to start completely over.
#19: Many solutions already exist
Solutions already exist for many problems and challenges. Often, we don’t know them, and therefore can’t build on what previous generations have developed. For this reason more exchange or preliminary research is time well spent before building an own solution. The real problem: existing solutions are simply not applied.
#20: Primitive obsession is very dangerous
Object-oriented programming languages are about objects that combine data and algorithms in a clear context and interact with each other. As soon as you start working too much or only with data rather than objects, it’s a sign that something is wrong with the design. Objects shouldn’t just give away their data; they should work on it on demand.
#21: Choose names carefully
The names of development objects, methods, functions, variables, and other programming components are like signposts. They can point you in the right direction or the wrong direction. Therefore, they should be chosen carefully, which can be incredibly time-consuming. By the way: names are already documentation.
#22: Be the hero who fixed it but don’t blame the person who raised it
Often, a lot of energy is spent discussing blame. That doesn’t solve the problem. If you want to discuss something extensively, then focus on the cause and how to avoid the problem in the future. Usually you find fewer people to talk to.
#23: Fail-Fast
In the vast majority of cases, fail-fast principle is the right way to handle an error situation. However, there are different ways to handle this principle and this is where the challenge lies. Learn how to deal with an exception situation.
#24: Isle of Happiness as a way out
In order to be able to work with modern approaches in legacy code, it is worthwhile to develop your own “Isle of Happiness” (e.g. a class) and to integrate it at the appropriate point in the legacy code (narrow bridge leading to the island).
#25: You learn a lot from mistakes
You do learn from mistakes. But that doesn’t justify making every mistake, as many people believe. There are mistakes you can make exactly once in your life.
#26: Lack of resources is a good teacher
In fact, a lack of resources often promotes creativity. However, even under a lack of resources, creativity has its limits. You just have to face reality. It may be more rewarding to increase resources than to wait for a genius to come up with an idea.
#27: Be always open minded, future happened maybe somewhere else
Even if you’re a big fan of a company, a technology, or a software (that’s fine), you should always be open-minded. The future could be happening elsewhere, and you should be aware of that and deal with it accordingly.
#28: Human relationships before technology
Even though social media would have us believe that everything happens online, there’s still an offline world. And it has a huge influence on what happens online. A genuine, helpful contact you know personally can be worth more than thousands of followers, comments and likes.
#29: Difference between design and behaviour
Computer scientists are intensely concerned with design and behavior. These are two concepts that we must reconcile, just as designers of other everyday products must: how is it intended and how is it actually used?
#30: Model View Controller, Input Process Output and more
There are many good standard approaches to deal with challenges in practice. What they teach us is that a structured approach leads to more maintainable software.
#31: The 80/20 rule really exists.. in retrospect
The 80/20 rule (Pareto principle) exists, but it’s not an exact science that allows for easy decisions to be made in advance. This principle becomes more apparent after a project, a statistical analysis, or something else, i.e., after data has been collected. It often only reveals itself in data that isn’t available at the beginning.
#32: Saving is finite and sometimes highly dangerous
You can achieve a lot through saving, but it has a lower limit (boundary) that poses great danger. If there’s nothing left to save, then you have to invest to bring about change. However, so much may already have been destroyed through saving that the necessary investment seems incredibly overwhelming, and then it’s no longer made.
#33: Single-responsibility principle
This principle is a good companion in software design because it helps to create order and order means that you can better assess things in advance. As with all good principles, you have to exercise it repeatedly in practice and remember that it is not an incontrovertible truth. You always make trade-offs.
#34: Separations of concerns
See “Single-responsibility principle”. This recommendation is also a great companion in software design but hard to master.
#35: Always reproduce errors yourself
Some reported errors don’t exist at all, are incorrectly described, or require intensive (repeated) analysis. Therefore, you should recreate errors yourself and study them whenever possible. Never just trust your gut feeling. Facts matter.
#36: The runtime is not important at first – it must run at all
Before you begin optimizing runtime behavior, an application should basically work. If runtime issues subsequently arise, then you need to optimize, not earlier.
#37: Difference between What and How
A clear distinction should always be made between “what” and “how”. The “what” can refer to a requirement or an error, for example. The “how” can refer to an implementation proposal or a solution to the error, for example. Always keep your focus on what’s going on.
#38: Information, Decision, Action
Collect numbers, data, facts (all information), use them to decide your next action, then act. This cycle repeats itself over and over unless you get stuck in one of the phases because of lack of information, pending decision or lack of action.
#39: Problem and solutions
If there’s a problem, invest sufficient time in analyzing it. Only then consider possible solutions as suggestions, usually based on facts rather than assumptions. Choose the most appropriate one from the suggestions.
#40: Make or buy
Make or buy sounds good in theory. In practice, there’s usually no proper analysis of what’s appropriate – decisions are made without proper foundation. Gut feeling, personal acquaintances and preferences and much more decide.
#41: Empty your cup so that it may be filled
Some topics require an open mind and not constant comparisons with past experiences, even though that’s typically human and protects us from many problems. Otherwise, you’ll miss something.
#42: Our upbringing shapes us forever
What we learn from our families, school, and friends at a young age shapes us forever. Breaking out of these learned behavioral patterns as an adult is incredibly difficult, yet unfortunately necessary time and again. Conversely, think carefully about what you teach your children.
#43: Routine is necessary
Many things are practiced thousands of times through boring routines so that they work when needed. Our work consists more of boring routines than of extraordinary moments, even if they keep us going.
#44: Keep it simple, stupid!
The one solution that fulfills the KISS principle is preceded by many solutions that do not (compare one consumer market product vs. 15 prototypes). KISS is incredibly difficult in practice but nevertheless desirable.