The zen of developer (almost)

Throughout my career I have been in situations that I have dealt with thanks to the advice of those mentors who have guided me, that is why I write these principles that have helped me to deal with problems in software development, some principles have been taken from the following sources and are not my authorship.

1. Crispin, L., & Gregory, J. (2009). Agile testing: A practical guide for testers and agile teams. Upper Saddle River, NJ: Addison-Wesley.
2. Poppendieck, M., & Poppendieck, T. D. (2007). Implementing lean software development: From concept to cash. Upper Saddle River, NJ: Addison-Wesley.
3. Fowler, M., & Beck, K. (1999). Refactoring: Improving the design of existing code. Reading, MA: Addison-Wesley.
4. Fowler, M. (2004). UML distilled: A brief guide to the standard object modeling language. Boston: Addison-Wesley.
5. Martin, R. C. (2009). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice Hall.
6. Martin, R. C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Boston, MA: Prentice Hall. ISBN: 978-0-13-449416-6

• The best way to get a project done faster is to start sooner.
• In high-performance teams, the leaders managed the principles, and the principles managed the team.
• If we want users to like our software, we should design it to behave like a likeable person.
• The best way to predict the future is to invent it.
• No amount of testing can prove a software right, a single test can prove a software wrong.
• No one in the brief history of computing has ever written a piece of perfect software. It’s unlikely that you’ll be the first.
• We can be proud of our abilities, but we must own up to our shortcomings, our ignorances and our mistakes.
• In an abstract sense, an application is successful if it correctly implements its specifications. Unfortunately, this pays only abstract bills. In reality, the success of a project is measured by how well it meets the expectations of its users.
• The mark of a mature programmer is willingness to throw out code you spent time on when you realize it’s pointless.
• Technical problems can be remediated. A dishonest corporate culture is much harder to fix.
• Because we all make mistakes, we also know that everyone else makes mistakes. So, within reason, we don’t judge each other on the mistakes we make. We judge each other on how we deal with those inevitable mistakes
• the biggest problem to solve in tech is to get people to stop making things harder than they have to be
• Any program that tries to be so generalized and configurable that it could handle any kind of task will either fall short of this goal, or will be horribly broken.
• A team of highly competent programmers who are also highly territorial, egotistical politicians will fail while a team of equally competent programmers, who are also egoless, cooperative, team players will succeed.
• Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You don’t know where you’ve been, you don’t know where you’re going, and you don’t know quite where you are.
• When you come across a stumbling block because the code doesn’t quite fit anymore, or you notice two things that should really be merged, or anything else at all strikes you as being “wrong”, don’t hesitate to change it. There’s no time like the present
• Write shy code – modules that don’t reveal anything unnecessary to other modules and that don’t rely on other modules’ implementations
• As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.
• You can’t learn everything. You can’t hold every concept fully expanded in your head. And moreover, you shouldn’t. As we compress formerly fundamental concepts, we make room for new, grander abstractions.
• A good programmer is someone who always looks both ways before crossing a one-way street.
• Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward.
• We have to fight chaos, and the most effective way of doing that is to prevent its emergence.
• Any optimization that is not about the bottleneck is an illusion of improvement.
• If the data structure can’t be explained on a beer coaster, it’s too complex.
• The most dangerous phrase in the language is: We’ve always done it this way.
• We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process
• The ability to simplify means to eliminate the unnecessary so that the necessary may speak.
• With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
• The place to start the implementation is to list exactly what the user will do to achieve his or her goals and how the system will respond to each user action
• If you’re going to do anything new or innovative, you have to be willing to be misunderstood.
• A Fallacy of Software: If it works, and we don’t change anything, it will keep working.
• If we want to build great products, we need great people. If we want to attract and keep great people, we need great principles.
• You can’t have great software without a great team, and most software teams behave like dysfunctional families.
• Teams move at the speed of trust. Be the kind of dependable person you would want to work with
• Focus is a matter of deciding what things you’re not going to do
• Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren’t sure which way to do something, do it both ways and see which works better.
• First solve the problem then write the code.
• It’s very important that a programmer be able to look at a piece of code like a bad chapter of a book and scrap it without looking back. Never get too enamored with one idea, never hang onto anything tenaciously without being able to throw it away when necessary; that should be the programmer’s attitude.
• Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that can be made
• I’m not a great programmer; I’m just a good programmer with great habits.
• The craft of programming begins with empathy, not formatting or languages or tools or algorithms or data structures.
• Optimism is an occupational hazard of programming; feedback is the treatment.
• The best meetings get real work done. When your people learn that your meetings actually accomplish something, they will stop making excuses to be elsewhere.
• Complexity has nothing to do with intelligence, simplicity does.
• Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
• People, not methodologies or tools, make projects successful.
• Of all my programming bugs, 80% are syntax errors. Of the remaining 20%, 80% are trivial logical errors. Of the remaining 4%, 80% are pointer errors. And the remaining 0.8% are hard.
• You can optimise for low latency. You can optimise for high throughput. You can optimise for memory occupation. However 90% of times the most precious thing you should optimise for is maintainability.
• Programs, like people, get old. We can’t prevent ageing, but we can understand its causes, limit its effects and reverse some of the damage.
• I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.
• If you’re afraid to change something it is clearly poorly designed
• If it doesn’t work, it doesn’t matter how fast it doesn’t work.
• Remember, code is your house, and you have to live in it.
• The benefit of allowing a team to self-organize isn’t that the team finds some optimal organization for its work that a manager may have missed. Rather, it is that by allowing the team to self-organize, it is encouraged to fully own the problem of performing its work.
• Before software can be reusable, it first has to be usable.
• Teams are immutable. Every time someone leaves, or joins, you have a new team, not a changed team.
• Don’t make the user provide information that the system already knows.
• If you cannot grok the overall structure of a program while taking a shower, you are not ready to code it
• The structure of a software system provides the ecology in which code is born, matures, and dies. A well-designed habitat allows for the successful evolution of all the components needed in a software system.
• The first concern of the architect is to make sure that the house is usable — not to ensure that the house is made of bricks.
• It’s hard enough to find an error in your code when you’re looking for it; it’s even harder when you’ve assumed your code is error-free
• Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?
• When you are stuck in a traffic jam with a Porsche, all you do is burn more gas in idle. Scalability is about building wider roads, not about building faster cars.
• Good design adds value faster than it adds cost
• The manager’s function is not to make people work, but to make it possible for people to work.
• Premature optimization is the root of all evil