Chemaclass - career

Working With the Garage Door Open

2026-07-14T00:00:00+00:00

Most people work with the garage door closed. They work in private and raise it only when the car is polished and parked. The neighbors see a finished thing. Never the work.

The phrase comes from writer Robin Sloan. Researcher Andy Matuschak turned it into a practice: notes and half-baked ideas visible to anyone walking past.

Open the door.

It means showing the work while it’s still in progress. The draft with the ugly variable names. The experiment you’re halfway through. Not the demo. The middle.

Why we keep it closed #

Fear, mostly. A closed door protects you. Nobody judges a mess they can’t see.

So we hide the drafts. We only push code once it’s clean enough to survive review. By the time anyone sees the work, every real decision was made in private.

That instinct feels safe. It costs you the exact moments where help was still possible.

A finished result can only be admired. A work in progress can be shaped.

What the open door gives you #

When people see the middle, they can change it. A teammate spots the dead-end approach before you sink another day into it. A junior asks the “dumb” question that turns out to be the real problem. Pair programming is this at its purest: the door open, live.

The open door also kills the myth that seniors don’t struggle. When a junior watches you get stuck and google an error you “should” know, they learn what real work looks like. Not the highlight reel.

I lived this with bashunit, my bash testing library. I shipped it imperfect. Everyone who looked inside the garage shaped it: bug reports, feature requests, pull requests. Same with Phel and my public .claude folder. The open-source way.

But an open door isn’t enough #

Here’s the trap. You leave the door up, open a PR, write notes in a shared doc, and wait for help to arrive.

It doesn’t. Nobody wanders into your garage.

Visibility is passive. “Public by default” is the floor, not the goal.

Leaving the door open is not the same as inviting someone in.

The skill isn’t openness. It’s pushing the right signal to the right people, on purpose.

Push signal to the right room #

Every channel comes with an expectation of who reads it. Matching your update to it is the whole game. Post in the wrong room and you’re noise or invisible.

The whole company reads it. #general. Post only what matters to everyone.
The tech team reads it. #engineering. Where a work-in-progress update belongs.
Interested people opt in. #insights: industry news, customer signals. Useful, but nobody has to read it.
Nobody has to read it. #random. Say whatever.

Same update, four different outcomes depending on where it lands. Learn the map before you broadcast.

What a good signal looks like #

A good update is not “hey, I pushed something.” It carries enough context that a reader can engage without asking you a single question.

Say I’m halfway through a pilot: a new way to slice and review pull requests, tested on one team. I don’t wait for the end. A short update goes to #engineering: where I’m stuck, plus one explicit ask. “Has anyone tried this with a monorepo?” gets answers.

When the pilot ends, the result goes to the same room:

What I tried and why it mattered.
What worked, with a concrete before and after.
What didn’t, honestly. The failed part is the most useful part.
What you’d do to try it yourself.

Both are signals, not statuses. They turn one team’s experiment into something the whole org can copy or shoot down. This is Ship, Show, Ask applied past the pull request.

Start small #

Pick one thing this week. One experiment, one draft, one stuck moment. Do two things: leave the door open, then walk out and tell the right room it’s there.

You’ll get help you didn’t expect. You’ll teach someone without meaning to. And the fear that kept the door down will look smaller from the other side.

The polished result impresses people. The pushed signal is how the work gets better.

Open the door. Then point at it.

The Eternal Return

2026-06-01T00:00:00+00:00

Nietzsche proposed a thought experiment in The Gay Science. Imagine a demon visits you at night and says: this life you have lived, you will live again, infinite times, exactly the same. Every joy, every regret, every detail. Would you collapse, or would you celebrate?

He did not mean it literally. He meant it as a test. Can you live in a way that you would willingly relive?

Years passed before that idea found me again. Not as philosophy. As pattern.

Events That Rhyme #

A situation happens. Some time later, a different situation happens. Different people, different stakes, different city. Yet the shape feels familiar. Not the surface, not déjà vu, but something underneath. The same kind of pressure, the same kind of decision, the same kind of room you have to walk into.

It is not that the events are connected. They are not. Causality does not link them. Your brain links them, because exposure to enough life produces collisions of shape. The more you live, the more shapes accumulate. Eventually, the new one rhymes with the old one.

I have felt this many times. Changing companies, closing one chapter of work and starting another, with new people and new constraints, yet the same internal weather rising in me as I cross the threshold. Quieter moments too: a certain light in October, a certain silence in January, that returns each year and brings with it the same kind of thoughts, the same curiosities, the same questions I never quite finished asking.

The Trap of False Wisdom #

The easy conclusion is: I have seen this before, I know what to do. That conclusion is wrong.

The events are not the same. The lesson from the past one does not transfer cleanly. Acting as if it does is the most common way experienced people make experienced mistakes. They mistake recognition for understanding.

Familiarity of shape is not knowledge of solution.

What Repetition Actually Gives #

What repeats is not the situation. What repeats is you, inside the situation.

The same kind of pressure surfaces the same parts of you. The same kind of decision exposes the same instincts, the same fears, the same default moves. The first time, you are too inside it to see. The second time, you start to notice. The third time, you can name what is happening while it happens.

That is the gift. Not predictive wisdom about the world. Diagnostic awareness about yourself.

Exposure Is the Variable #

The people who get this benefit are not the smart ones. They are the exposed ones. The ones who took the difficult job, said yes to the hard conversation, sat with uncomfortable feedback, moved cities when it would have been easier to stay, accepted the project they were not ready for.

Patterns cannot rhyme if you only ever live one shape.

This is why staying open matters. Welcoming change is not personality, it is method. It is how you accumulate the raw material that, much later, lets you recognize yourself under pressure.

Ten Years Later #

Ten years ago I was writing a book of my thoughts. I wrote every few days, just to read it back the next morning and understand myself better. I am not that person anymore.

Every beginning carries the shape of an end. Accepting that lets you stop chasing finality and pay attention to the process itself.

Process over goal. The role you take matters less than the persona you build inside it. The impact you leave is not what you intended, it is the shape of the absence you create when you are gone.

What Is in Your Control #

The events themselves are mostly not in your control. What complications arrive, when, with what severity: not yours to decide.

What is yours: whether you stay long enough to see the shape. Whether you reflect afterward instead of moving on cleanly. Whether you let the next collision teach you something about yourself rather than insisting it teach you something about the world.

The world repeats nothing. You repeat almost everything.

The Real Eternal Return #

Nietzsche’s demon was not asking about reincarnation. He was asking whether you have lived a life worth being. The test is internal.

So ask yourself. If this exact life repeated forever, every detail unchanged, would the honest answer be joy or regret? You are the only one who can answer, and the hardest one to answer truthfully.

I love being alive. The fact it ends is what gives the time inside it weight. If I do not like who I am becoming, I still have time to change. That is the only useful thing recurrence ever offered. Not knowledge of the future. A mirror in the present.

We get one life. Make it one you would relive.

What Success Means to Me

2025-09-15T00:00:00+00:00

For the longest time, I thought success was about hitting certain milestones. Getting that promotion. Earning a specific salary. Building something that people would recognize.

But I’ve realized that’s not what gets me out of bed in the morning.

The real measure #

Success, for me, is straightforward now: waking up knowing that what I do makes the people around me, and myself, happier.

It took me a while to get here. This definition might not feel simple to everyone, and that’s okay. But for me, it clarified everything.

No complex formula. No checklist of achievements.

Success is about those small moments when you help a colleague solve a tricky problem, when you share something that makes someone smile, or when you finish the day feeling like you actually added some good to the world.

This applies whether you’re leading a team or just showing up as yourself. As I wrote about great leadership, real leadership starts with your own life and behavior. It’s fundamentally about making the people around you better, not just achieving targets.

Why happiness matters #

I used to think that focusing on happiness was somehow trivial. Like it wasn’t “serious” enough as a goal. But I’ve learned that making people happy, genuinely happy, is one of the hardest and most rewarding things you can do.

What does this mean in practice? #

Being present when someone needs you
Creating things that solve real problems
Choosing kindness over being right
Finding joy in what you do, even on tough days

When you focus on making others happier, you usually end up happier yourself. It’s not zero-sum. It compounds.

This connects deeply with understanding people and how they think. When you truly understand that everyone processes the world differently, you become better at creating genuine happiness, not just what you think should make them happy.

The daily practice #

How does this look in daily life? #

For me, it’s about checking in with myself regularly: “Did what I do today make things better?” Not perfect. Not revolutionary. Just better.

Sometimes that’s writing code that helps a team work more smoothly. Sometimes it’s taking time to really listen to someone. Sometimes it’s just being patient when everything feels chaotic.

It’s not always easy. Some days you miss the mark. But having this simple definition of success makes decisions clearer. When you’re wondering whether to take on a project, accept an opportunity, or say no to something, you can ask yourself: “Will this make me and the people around me happier?”

Consistency over perfectionism #

Here’s something I’ve learned the hard way: success is built through consistency, not perfection.

Perfectionism will paralyze you. It whispers that nothing is good enough, that you should wait until conditions are ideal, that one mistake invalidates everything. It’s a trap.

What actually works? Showing up. Day after day. Building small habits that compound over time.

As James Clear explains in Atomic Habits, real change comes from the compound effect of hundreds of small decisions. You don’t need to be perfect. You need to be consistent.

Don’t try to make a habit perfect, just repeat it.

This means:

Writing a few lines of code every day beats waiting for the perfect architecture
Having a short, genuine conversation beats waiting for the perfect moment
Making small improvements consistently beats waiting for the big breakthrough

The goal isn’t to never fail. It’s to build habits that align with making yourself and others happier, and to keep showing up even when you stumble.

This is where the process itself becomes the goal. It’s not about reaching some final destination of “being successful”, it’s about building daily habits and practices that align with what actually matters to you.

Success is personal #

Your definition of success will probably be different from mine, and that’s not just okay, it’s necessary.

“Have I always been like this?” The answer is no. I certainly wasn’t. Our understanding of what matters evolves as we grow. That’s part of the journey.

If you’re feeling stuck or unsure about what you’re working toward, try this: figure out what truly makes you and the people you care about happier. Not what you think should make you happy. Not what looks impressive from the outside.

Just what actually works for you.

And be ready to embrace the change when your definition shifts, because it will. What success means to you today might look different tomorrow. That’s not failure. That’s growth.

At the end of the day, if you wake up knowing that what you do brings more happiness into the world, including your own, you’re probably doing something right.

That feels like success to me.

Thanks to my friend Toni, for bringing up this question and inspiring this reflection.

Principles of Economics

2025-06-22T00:00:00+00:00

If you’ve ever scratched your head at the economy, wondered why prices keep rising, or questioned why money seems to lose value over time, Principles of Economics by Saifedean Ammous might blow your mind.

It’s not your typical dry economics book. Instead, it’s a bold, no-nonsense guide to understanding how the world really works, through the lens of Austrian economics. Here’s what stood out to me.

1. Economics = Human Action #

Ammous starts with something super simple but powerful: economics is just people making choices. Every time we choose to do one thing over another, that’s economics in action.

Forget all the charts and equations you might’ve seen in school. Real economics begins with you trying to make life better, one decision at a time.

2. Time Preference = How Much You Value the Future #

This idea was a game-changer: your time preference is how much you value stuff now vs. later.

If you spend everything today, you’ve got a high time preference.
If you save and plan for tomorrow, you’ve got a low time preference.

Low time preference leads to building cool things. Like businesses, families, skyscrapers, or even civilizations. High time preference? That’s fast food, impulse buying, and short-term thinking.

3. Good Money = Strong Society #

The quality of a society’s money affects everything. If your money constantly loses value (hello, inflation), people stop saving and start living for today.

He argues that government-controlled “fiat” money is the problem, and we need a return to “hard money” (like gold or Bitcoin) that holds its value over time. Good money helps people plan, save, and grow wealth across generations.

4. Producing Stuff Takes Time, and That Matters #

Making things isn’t instant. It takes time, tools, and planning. Ammous explains how advanced economies only exist because people invest in long-term production: factories, machines, supply chains.

That’s only possible when people trust their money and their future. So again, low time preference is key.

5. Entrepreneurs, Not Governments, Drive Progress #

If there’s a hero in this book, it’s the entrepreneur: the person who takes risks, builds businesses, and creates value.

Ammous has zero love for central planners, regulations, or government bailouts. He’s all about free markets and letting smart people solve problems without interference. When prices are honest and money is sound, people figure things out on their own.

6. Inflation and Central Planning? Big Red Flags #

Ammous doesn’t pull punches. He’s very critical of how governments manage money and the economy.

He sees inflation as a sneaky form of theft and believes that constant meddling (like printing money or setting interest rates) only makes things worse. He even calls out entire fields like climate economics and ESG as being more about politics than real economics.

7. Bitcoin: The Grand Finale #

While this book isn’t just about Bitcoin, it clearly leads there. After explaining why our current money system is broken, Ammous points to Bitcoin as the best solution we’ve seen in over a century.

It’s digital, limited, and no one can mess with it. Bitcoin is the return of sound money, and a chance to fix a lot of what’s wrong today.

Final Thoughts: A Crash Course in Real Economics #

“Principles of Economics” is like an economics red pill. It’s straightforward, bold, and sometimes brutal. But if you’re tired of the usual financial nonsense, this book will hit you like a breath of fresh air.

You’ll walk away with a new lens to see the world: why prices rise, why saving matters, and why the kind of money we use shapes everything.

Austrian Economics vs Keynesian Economics #

Digital Minimalism

2025-02-16T00:00:00+00:00

In an era dominated by constant connectivity, the concept of digital minimalism emerges as a refreshing antidote. Coined by Cal Newport, this philosophy isn’t about rejecting technology but rather about using it with greater intention and care. By implementing digital minimalism, individuals can reclaim focus, reduce anxiety, and cultivate deeper, more meaningful relationships.

The Core Principles of Digital Minimalism #

Newport’s approach to digital minimalism is built on three fundamental ideas:

Clutter is Costly: Unnecessary digital distractions fragment our attention and drain our mental energy. By decluttering our digital lives, we regain control over our focus and time.
Optimization is Essential: Rather than mindlessly accepting every new app or platform, digital minimalists carefully curate their technology use to align with their values and goals.
Intentionality is Key: Digital minimalists don’t just cut back on screen time; they deliberately choose how and when to engage with technology to maximize its benefits while minimizing its drawbacks.

The 30-Day Digital Declutter #

One of Newport’s most actionable strategies is the 30-day digital declutter. The idea is simple:

Take a 30-day break from all non-essential digital tools.
During this period, explore alternative offline activities that bring fulfillment.
After 30 days, reintroduce only the digital tools that add value to your life.

This method serves as a reset, allowing individuals to assess which technologies truly enhance their lives rather than simply consuming their time.

The Benefits of Digital Minimalism #

Those who embrace digital minimalism often report:

Improved Focus: With fewer distractions, deep work and meaningful projects become easier to accomplish.
Reduced Anxiety: Less exposure to social media and endless notifications results in a calmer, more present mindset.
Richer Relationships: By prioritizing face-to-face interactions, digital minimalists cultivate stronger and more meaningful personal connections.
Increased Productivity: Fewer digital distractions translate into higher efficiency and greater creative output.

Practical Steps to Get Started #

If you’re ready to experiment with digital minimalism, here are some simple steps to begin:

Audit Your Digital Life: Identify which apps, platforms, and devices are consuming the most time without offering meaningful benefits.
Set Screen Time Limits: Use built-in tools on your phone or computer to cap the amount of time spent on certain apps.
Establish Tech-Free Zones: Designate areas like the bedroom or dining table as screen-free spaces.
Prioritize Analog Activities: Replace digital distractions with books, hobbies, and in-person interactions.
Schedule “Offline” Hours: Set intentional times during the day when you completely disconnect from digital devices.

Final Thoughts #

Digital minimalism is not about rejecting technology altogether. It’s about using it in a way that enhances rather than diminishes our quality of life. By taking a more mindful approach to our digital habits, we can reclaim our time, improve our well-being, and refocus on what truly matters.

Video Summary #

Cal Newport interviewed by Lex Fridman #

Man's Search for Meaning

2024-11-29T00:00:00+00:00

In “Man’s Search for Meaning,” Frankl not only shares his harrowing experiences from the Holocaust but also presents a profound philosophy on the human condition. This book is a testament to the resilience of the human spirit, exploring how even in the darkest of times, individuals can find purpose and meaning.

Frankl’s insights into the psychology of survival and his development of logotherapy offer a unique lens through which we can view our own lives. As we delve into the depths of his narrative, we are invited to reflect on our personal search for meaning, challenging us to consider how we find purpose amidst life’s trials and tribulations.

Part 1: Experiences in a Concentration Camp #

Frankl, an Austrian psychiatrist, recounts his experiences in Nazi concentration camps, including Auschwitz and Dachau, during World War II.

He describes the psychological stages prisoners went through: shock upon arrival, apathy where they became emotionally numb to survive, and finally, the phase of disillusionment or bitterness if they were liberated.

Frankl emphasizes that even in the most horrific conditions, finding a purpose or meaning can provide the strength to survive. He notes that those who had something to live for, like a loved one or a personal project, were more likely to endure.

Part 2: Logotherapy in a Nutshell #

This section introduces Frankl’s psychotherapeutic method, which he developed based on his experiences. Logotherapy focuses on the meaning of human existence as well as on man’s search for such a meaning.

Unlike Freud’s “will to pleasure” or Adler’s “will to power,” Frankl proposes the “will to meaning” as the primary motivational force in humans.

Three Paths to Meaning:

Achievement: Doing a deed or creating work.
Experience: Experiencing something or encountering someone (love).
Attitude: The attitude we take toward unavoidable suffering.

Even in extreme situations, Frankl asserts that one can choose one’s attitude towards the situation, which can be a significant source of meaning.

He discusses this concept as the feeling of meaninglessness in modern society, leading to various psychological issues. Logotherapy aims to guide individuals to find personal meaning.

Key Takeaways #

Meaning of Life #

Frankl argues there is no one universal meaning to life; rather, meaning is unique to each individual and can shift over time.

Suffering and Meaning #

Not all suffering must be devoid of meaning; it can be a path to finding or reaffirming meaning.

Responsibility #

Each person has the responsibility to find their own meaning, which also entails the freedom to choose one’s path.

Frankl’s book is not just a memoir but a testament to human resilience and the power of the human spirit to transcend even the worst circumstances through the discovery of meaning.

Quotes #

“Ultimately, man should not ask what the meaning of his life is, but rather he must recognize that it is he who is asked.”

“We needed to stop asking about the meaning of life, and instead to think of ourselves as those who were being questioned by life, daily and hourly.”

“Everything can be taken from a man but one thing: the last of the human freedoms, to choose one’s attitude in any given set of circumstances, to choose one’s own way.”

“Freedom, however, is not the last word. Freedom is only part of the story and half of the truth. Freedom is but the negative aspect of the whole phenomenon whose positive aspect is responsibleness.”

Personal notes #

My favorite aspect of the book is its portrayal of life as an ongoing shift in perspectives, both from within oneself and in relation to the external world. It’s like adjusting a camera lens, zooming in or out based on context, recognizing that we are simultaneously individual entities and part of a larger collective.

This approach helps you gain a broader perspective, allowing awareness of both your limitations and your significance within any given scenario. Consequently, life doesn’t inherently possess meaning; rather, it’s the meaning we choose to attribute to it that shapes our existence.

Animated book summary #

People Skills

2024-09-02T00:00:00+00:00

So, you’re a software developer, and you’ve mastered coding languages, algorithms, and all the tech stuff. That’s awesome! But here’s the deal: technical skills alone won’t get you as far as you might think.

If you can’t work well with others, it doesn’t matter how great your code is, nobody will want to work with you.

Why People Skills Matter in Software #

In software development, collaboration is everything. Projects aren’t just solo endeavors. You will be part of a team, with other developers, designers, or even non-tech folks like managers and clients. How you communicate, collaborate, and handle feedback can make or break your success.

The Brilliant but Difficult Teammate #

Think about it. Have you ever had that one teammate who’s brilliant but hard or nearly impossible to work with? Maybe they don’t listen, get all the credit, or make everything more complicated than it needs to be. No one likes working with that person, right? It’s the same for you. If you can’t get along with your team, it doesn’t matter how good your code is.

What Being a Good Team Player Means #

Being a good team player means listening to others, being open to feedback, sharing ideas, and, most importantly, being respectful and considerate. You want people to enjoy working with you, not avoid it.

Good people skills help you build strong working relationships, solve problems faster, and create a better work environment for everyone. Don’t just aim to be a coding expert, ensure you’re also great to work with.

The Long-Term Impact #

In the long run, your people skills can boost your success as much, if not more, than your technical abilities. They play a vital role in a team’s success and make the work experience enjoyable for everyone involved.

People skills are as necessary as technical skills. No one will want to work with you if you are not a good team player.

What are people skills? #

The competencies that enable you to interact effectively and smoothly with others.

Core Communication Skills #

Communication: The ability to clearly convey ideas, listen actively, and engage in meaningful conversations. This includes both verbal and non-verbal communication.
Empathy: Understanding and being sensitive to the feelings, thoughts, and experiences of others. It involves seeing things from someone else’s perspective.
Emotional intelligence: Recognizing and managing your own emotions and understanding and influencing the emotions of others.

Collaboration Skills #

Teamwork: Working well with others to achieve common goals. This includes collaboration, sharing responsibilities, and supporting colleagues.
Conflict resolution: The ability to handle disagreements and disputes constructively, finding solutions that satisfy all parties involved.
Negotiation: Finding mutually acceptable solutions or compromises during discussions or disagreements.

Growth and Influence #

Adaptability: Being flexible and open to change, adjusting your approach as needed to meet different situations or personalities.
Leadership: Inspiring and guiding others, providing direction, and fostering a positive environment.
Networking: Building and maintaining professional relationships that can provide support, opportunities, and resources.

These skills are essential in almost every job and help build strong relationships, enhance teamwork, and create a positive work environment.

Why They’re Harder Than You Think #

These are often called interpersonal or soft skills, but mastering them can be surprisingly challenging, perhaps even more so than many technical skills. Unlike “hard skills,” which are tangible and can often be learned through a few hours or days of study, people skills involve navigating the intricate web of human emotions, experiences, and expectations.

While technical skills might require you to dive into documentation, run experiments, and refine your approach, understanding and relating to people is far more complex.

Humans bring their feelings, backgrounds, and routines into interactions, adding layers of complexity beyond machines’ straightforward logic. These personal details shape the reality we perceive, making interpersonal skills an essential yet complex part of effective communication and collaboration.

Great Engineering

2023-12-30T00:00:00+00:00

Coding is not just another job. Writing software can be really fun and, even more, it can be your personal hobby as well! You might be focused on coding, coding and more coding to level up your own career skills.

That itself is not bad at all! Practice makes the master, so a lot of coding will inevitably help you improve your coding skills… but there are other aspects that you need to keep in mind in order to help you grow into a great engineer.

As a software engineer, your job is not “just to write software” for its own sake, but to use software to solve actual business problems. To make that happen there are plenty of different methodologies out there, for sure. However, we must agree that you need to identify and understand your customer’s needs in order to know what to actually build.

You need to know your product, at least until certain level, so you can design your software using a similar language closer to the business, which will help its evolution and overall quality. This will be beneficial for the future (and present) maintenance of the product.

IT, Software, Product and People topics are highly interconnected, and having at least a common ground of understanding the relation between these can help the overall goal of every single individual.

The result of a great team work is not equal as the sum of the individual parts, as it’s multiplying the created value among their peers. To that, great communication skills are a key part of it in order to create as much clarity as possible from any different abstraction level.

That’s why a great engineer is a knowledgeable person about business, customer, product, and coding. Understanding these points have a strong impact on your daily work as it creates a difference between the average and the great engineer.

Image original by Nicola Ballotta.

The Alchemist

2023-11-07T00:00:00+00:00

The Alchemist is a classic novel in which a boy named Santiago embarks on a journey seeking treasure in the Egyptian pyramids after having a recurring dream about it. On the way meets mentors, falls in love, and most importantly, learns the true importance of who he is and how to improve himself and focus on what really matters in life.

Video Summary #

The Peter Principle

2023-09-30T00:00:00+00:00

A person who is competent at their job will get promoted to a position that requires other skills. If they lack the skills for the new role, they will be incompetent at the new level, and will not be promoted again.

If the person is competent in the new role, they will be promoted again and will continue to be promoted until reaching a level at which they are incompetent. Being incompetent, the individual will not qualify for promotion again, and so will remain stuck at this final placement or Peter’s plateau.

There are incentives at play. People work hard to reach a particular position or salary. Once they achieve that, some get lazy. Once people lose passion, they stop learning. They might fail to keep up with new developments, which might lead to poor work quality. To protect their comfort zone, they challenge any new idea or person that could make their life unconformable. Incompetent employees are often unhappy.

Have you experienced the Peter Principle? #

I’ve seen this several times during my 10-year career, working in different companies with people in various departments at different levels. It’s indeed more dangerous than it seems because it can kill the spirit of a healthy environment and company.

Creating awareness about this can help you to be cautious to avoid this from happening to yourself, or at least trigger warnings when you feel this might be happening to you.

What can you do about it? #

If you can recognize this situation within your company, I recommend helping to create awareness about it. Talk to each other. If you feel you can’t, that’s a symptom of an unhealthy working environment, and that’s something more significant to deal with.

If you are the one experiencing this in “first person,” I would recommend you:

Talk to your manager; ask for training, mentoring, or whatever you need to get the skills you lack, from confidence, communication, or anything that could help your new role. Maybe you didn’t get enough or proper training for the new job, which requires different skills.
Consider pivoting back where you were good and keep mastering that, helping and inspiring those next to you. Not everybody has to be promoted all the time.

Never Ending Loop

2023-07-05T00:00:00+00:00

It is hard sometimes to get to bed with the mind blank because, more often than not, I think about my next reading, learning, talk, or what I will write this or next month.

It is funny to remind that eight years ago, I stayed up for hours until all kinds of thoughts got out on paper, so I used to write one or more of them every week. Sometimes innocent thoughts came to my brain and didn’t let me sleep properly. Sometimes deep and full of worry that reflected how I struggled with certain situations that I was living in or remembering from my past youth.

I kept writing for three years; I wrote a lot, another format than I usually do today; a deep and personal book about my thoughts and feelings with the primary motivation of reading them later and doing some retrospectives to help me understand myself better. Nowadays, I like to mix my passion around software quality and people puzzles to achieve true excellence in my profession, always aiming for an honest and healthy egoism of helping others that could help me later. The better the people around me are, the better they will help others and me.

Back then, I used to write about my current and past feelings, always with a touch of illusion wanting to express myself differently for my future self. I remember clearly, in the beginning, I wanted the main readers to be my siblings, my family, to know how I was doing so far away from all of them, after migrating to another country, far away from my family. However, as the months passed by, the main reader changed to be no one but myself.

I spent hours on each thought, page, chapter… Drafting the initial idea and then reading it out loud once, twice, again, and again the day afterward. Helping this way to discover that part of myself that tried to reflect what was going on inside.

I can see some similarities nowadays. However, I no longer see the need to write about those deep old past thoughts because they healed. Instead, I can reflect and see how they did and how.

Writing is one of my favorite ways to express myself, especially when I cannot sleep. It reminds me of those years, and I think greatly about the incredible evolution since then.

Original photos from my trip to Tuscany, Italy, last month.

Learned Helplessness

2023-06-08T00:00:00+00:00

Learned helplessness is the behavior exhibited by a subject after enduring repeated aversive stimuli beyond their control.

It was initially thought to be caused by the subject’s acceptance of their powerlessness by discontinuing attempts to escape or avoid the aversive stimulus.

Experiments #

A classroom with different assessments #

Charisse Nixon, Ph.D Developmental Psychologist at Penn State Erie, The Behrend College and Director of Research and Evaluation for The Ophelia Project discusses the phenomenon of learned helplessness.

Original: Docking shocks and harnesses #

In 1967, the American psychologist Martin Seligman at the University of Pennsylvania researched docking shocks and harnesses.

In Part 1 of this study, three groups of dogs were placed in harnesses. Group 1 dogs were put in a harness for some time and released later. Groups 2 and 3 consisted of “yoked pairs.” Dogs in Group 2 were given electric shocks randomly, which the dog could end by pressing a lever. Each dog in Group 3 was paired with a Group 2 dog; whenever a Group 2 dog got a shock, its paired dog in Group 3 got a shock of the same intensity and duration, but its lever did not stop the shock. To a dog in Group 3, it seemed that the shock ended randomly because their paired dog in Group 2 was causing it to stop. Thus, for Group 3 dogs, the shock was “inescapable.”

In Part 2 of the experiment, the same three groups of dogs were tested in a shuttle-box apparatus (a chamber containing two rectangular compartments divided by a barrier a few inches high). The dogs could escape shocks on one side of the box by jumping over a low partition to the other. The dogs in Groups 1 and 2 quickly learned this task and escaped the shock. Most of the Group 3 dogs, which had previously “learned” that nothing they did affected the shocks, lay down passively and whined when shocked.

Even though this experiment was demonstrated with different types of animals, it also applies to people. This is visible in children when they integrate early failure to ask for help, frustration, giving up, poor motivation, and procrastination. And these points carry on as people age.

Because, if you “cannot do anything”, why would you even try it?

All this leads to anxiety and depression, and people think nothing can be done about their current situations and feelings.

Learned optimism #

The antidote to learned helplessness is learned optimism. These people are higher achievers, have better overall health, and have lower levels of depression.

How do you practice it? #

Permanence: bad events or failures are not permanent. So, you can recover faster than people stuck in these situations. However, good things or events happen for a good reason that you’ve worked on.
Pervasiveness: do not generalize failure. Failing in one area in your life should not affect other areas.
Personalization: bad events are external to blame, outside yourself, as you did all you could have done.

Isolate the problem and don’t extrapolate it to other areas. Stop generalizing failure.

English #

Español #

Have You Always Been Like This?

2023-03-16T00:00:00+00:00

I’ve got this question recently, a couple of times, and this is a great topic to share.

“Have you always been like this? Constantly reading books, writing blog posts, public speaker in conferences and meet-ups, learning in your private time, etc…?”

The short answer is: no, and let me tell you how I ended up in this situation.

I used to be introvert #

I used to be an introvert, but with work and effort, I managed to master some public speaking skills.

Sharing knowledge is hard because first, you need to have it.

I used to dislike reading; I always preferred other sources of getting information and learning new things. Of all of them, reading was the most boring one.

Reading is hard, because it needs your entire attention.

However, I have always enjoyed writing since I was a kid. For personal circumstances, writing was a way to express and reflect on me, doing regular retrospectives about the ideas in my head.

Writing to the rescue #

Combining “sharing knowledge” and “reading” from and to myself.

Writing was (and still is) a way to sort out my thoughts, especially during hard times; writing was a way to escape from the world. It helped me to understand myself better the day after. And it worked.

Knowing your limitations can help you understand your reality and fight against it. Life is hard enough to accept whatever “is there,” even if you are dissatisfied with it, especially if you have a reason for that.

I learned that I don’t want to waste my time in a life I will regret when I die. For that reason, I started seeking opportunities to grow at everything I do all the time.

Will I always be like this? #

“Are you all the time 100% learning and being productive?”

You cannot be 100% productive all the time. That’s impossible because of our human nature. Life is about constant “ups and downs,” which is also part of its beauty. It’s your responsibility to understand yourself; I mean, truly understand your emotions and your persona.

These are questions that can help you keep the focus while building yourself. When asking these types of questions, try looking from a rational and external point of view. Leave out emotions and personal feelings.

Who are “you”?
What differentiate “you” from other people?
What differentiate “today’s you” from “you a year ago”?
What about your “you” in 1 year?

Within your context and possibilities, you are what you choose to be. And that’s what differentiates you from your past and your future. The actions you do, the way you communicate and interact with others, the decisions you choose, etc…, differentiate you. That’s what differentiates you from yourself at another point in time.

This is why I enjoy reading (or listening to a book) per month. This is why I enjoy learning anytime, all the time. This is why I like to share what I know with others. This is who I choose to be.

A few years ago, I wrote about the process itself as the goal, which says basically: “Repetition is the key. Make it easier to do what you want to do. Make it harder to do what you want to stop doing. Enjoy the process: that’s the goal.”

How much time do I have? #

I like to prove myself wrong and challenge the status quo. I even decided to investigate, for example, how I could be one speaker in an international conference last year. The hardest step is always the first; once you’re there, it’s more fun than you initially thought. I might write a dedicated post about this “public speaking” topic. For now, you can check some tips I wrote about improving your public speaking talks.

Regarding reading, I need around 4 to 6 hours (on average) to finish a book. A typical working day can be divided into 3 slots of 8h; 8 sleep, 8 work, 8 leisure (or other obligations). I don’t work on the weekend, so those days are 16h each of leisure/obligations. So, assuming I work 5 days per week, this means 5 days x 8 hours (working days) + 2 days x 16 hours (weekend) = 72 hours of leisure/obligations time within a week!

Time is not the problem #

Within a month, I have 72 hours x 4 weeks = 288 hours of leisure/obligations time to spare with my girlfriend, talking to my family, playing music, partying or chilling with friends, going to the gym, walking in a park, traveling to other cities…, but also going to the supermarket, doing the dishes, preparing the evening meals, clean the apartment, commuting to work…, all of this requires time as well.

The problem isn’t time but the priorities I define. Within a month, I can really do a lot of things. The issue I usually encounter is not having a clear goal about what I want to reach in the middle-long goal for myself.

There might be others, but The power of habits and Atomic habits were the books I read so far about habits that impacted me the most, and I think they might help you if you are struggling with habits that you would like to change anyhow. It all starts by understanding yourself within your context.

I don’t expect things to change from one day to another. I enjoy experimenting, combining habits, and trying different approaches to improve and get the best out of them over time. Losing fear of failure and seeking constant and continuous improvement is a life-changing mentality.

What keeps me moving is the time I have left and the idea of thinking, “what would I like to have changed?” And in such a case, “Why didn’t I?”

Different Beliefs About Software Quality

2022-10-08T00:00:00+00:00

I recently got a great question on Twitter which got me thinking for a while and I decided to share my thoughts about it.

The tweet that started this #

But first, some context: I am feeling great because the codebase where I work is getting better and better, so I am tweeting this:

“As software improves with time, you can feel you’re doing right.”

And then I got a question asking for suggestions:

So there we go…

My answer #

Create agreements #

The first thing is to create agreements about what quality software means for your team and yourself. This helps clarify what software culture you want to establish and work towards that direction. Leaving your company should be the last resort once you have no other option.

Before thinking about leaving your company, I would ask you:

Why do you think you cannot improve the working codebase of your company?
What can you do to reduce the friction between your different beliefs regarding what quality means for software?

There is no perfect codebase to work on because software is a living entity and constantly changes. So, at least for me, quality software is the one that can cope with change smoothly.

Once you have agreed on that goal, and while there are multiple ways to achieve that result, my favorite way of working is keeping an agile mindset with doses of extreme programming values, principles, and practices in mind.

Software is about people #

Software is not just about writing clean and solid code. This is indeed desired, and we should aim for that, but we must first understand why we want that. The “why” is based on the values that you have as a team.

If you don’t share the same purpose, the same “why,” then you won’t enjoy working together, and in such a case, I would advise looking for another company that shares your values. But, before that, I would strongly suggest fixing the deeper issue and helping your team improve.

Understanding your why #

You first need to deeply understand your “why” so you can transmit this to your peers and the people around you. Have you tried all you can to create awareness about your “why”?

Some ideas include encouraging collaborative programming (pair/mob), presenting some internal tech talks, creating a culture of sharing knowledge on a regular daily basis, creating awareness about the current status quo, and looking for opportunities to improve everywhere.

Your career path #

If, after several months of (really) trying these ideas, none of them work, look for a new company that shares your beliefs. After all, you’re the first and primary responsible person for taking care of your career path.

Original twitter thread.

Extra thoughts #

If you want something to be different, don’t wait till it’s changed automatically. Try to change it; if it’s not working, leave it. Maybe you don’t belong in that place.

On the other hand, it’s crucial to reflect if you see that pattern often repeating (changing companies too quickly). In such a case, maybe the problem isn’t the companies but yourself.

Software development is not just about code but business. It’s essential to be aware of finding a fair trade-off between speed, costs, and quality, depending on the situation. You might want to use some tech debt to conquer the market as soon as possible.

It doesn’t make sense to have “low quality” as part of the identity of any team. Every team has certain quality expectations. Therefore, the key here is to agree on what good quality is.

The Path to Seniority in Software

2022-06-08T00:00:00+00:00

We all have been junior developers at some point. This is easy to know because it sits at the very beginning of your career. Your responsibilities were narrowed down by other peers who were looking after you.

At some point, after months or years, you got your promotion or another job, where you weren’t a junior anymore, but an intermediate.

An intermediate (also known as middle) is something between junior and senior. You know now that you are not a junior anymore, you know how to deliver value but yet you also have mixed feelings about seniority. You want to be a senior, but you don’t know how. There is no clear path to achieving this goal.

Wait for a second… there are actually two easy ways to get the senior title! You can get promoted as such in your company, or you can start a new position as a “senior” in another company, easy right?

Marketing and politics #

Unfortunately, the “seniority” level is very much polluted by marketing and politics. First, what does it mean “senior” in this context? In all the companies where I have been working (if not all) I have always been surrounded by people who claimed to be “seniors” when in reality only a few I would consider such.

Our senior label is inflated by companies needing experts on paper more than in reality, and this is a problem we need to deal with and speak about.

Seniority generally means more experience, but how do you calculate this? It is easy from a company’s point of view: more years in the industry. But, is the number of years you have been working really relevant in an industry that is constantly changing and evolving? Actually, this wouldn’t be a big issue if you have the software fundamentals well interiorized, but funny enough, I have seen these fundamentals in only ~10% of the seniors I have met across many years and several companies.

The fact that you have been working for 10 or more years doesn’t necessarily mean you are a “senior” with software. What else can we measure in order to identify if you deserve indeed this title?

It is not all about the money #

Let us be honest, senior titles are better paid than junior or middle positions. If you have the chance to get a higher salary because you got the “senior” in your job title, well, it wouldn’t be clever to reject it. But, independently of politics and marketing, we must address some seniority fundamentals to understand better what the word “senior” means in this context.

It is not all about the money, but also about the responsibilities that come with seniority.

Seniority fundamentals #

Being senior in our software industry is not about “the number of years of experience” but:

How well do you transmit your knowledge to others? Sharing what you know is a core task for a senior person.
How well do you collaborate with other people, including the PM/PO and other teams? Collaboration is crucial to creating a constant feedback loop.
How well do you work together with your peers? Pair-programming builds team cohesion and helps everyone become better.
How strong are your testing skills? Testing is tied to the quality of your work, and a senior should aim for an incremental design.
How well do you understand delivering value constantly in small chunks? The sooner you deliver value, the sooner you get feedback about it.
How deep is your technical knowledge of quality software and the trade-offs to get there? SOLID principles, clean code, TDD, refactoring as part of your daily job, low coupling, high cohesion, appropriate data structures, and choosing the right solution (KISS, YAGNI…).
How well do you adapt and cope with change? Change is inevitable, so we must learn to deal with it, especially the parts we cannot control.
How developed is your entrepreneurial thinking? Always keeping the organization’s goals in mind.

As you can see, there is no mention of concrete technology or years of experience. Why? Because technology is just an “implementation detail”, and experience comes by practicing and attitude, not by letting the time pass by.

Attitude is important #

We’ve got two persons:

A) a person who is working for 15 years, doing relatively the same every day, and without caring about his own skills. He just does what others tell him to do.

B) a person who is working for 5 years, challenging herself every week, trying different approaches when dealing with problems, and sharpening her own skills constantly.

Can you see the main difference? No, it’s not the 10 years difference of “experience” between them, but their attitude.

We wrongly understand that a year of experience must come with learning and knowledge, so we tend to use time as a measurement of seniority. But I argue that the “attitude factor” is equal or even more important. I have been surrounded by many people who call themselves seniors with 3, 6, 10, and more years of “experience” but lacking attitude, and you could clearly see this problem on a daily basis.

You need this combination to build yourself as a truly senior developer; time, experience, and most importantly: attitude towards improving your own skills and the ones that surround you.

Where to start #

Seniority is not granted, it is practiced. You don’t wait for the title, you build the behavior until the title catches up. Start small, and start now:

Teach what you know. Pick one thing you understand and explain it to someone this week. If you can’t explain it, you don’t own it yet.
Seek the uncomfortable. Volunteer for the task slightly beyond you. Growth lives at the edge of what you can already do.
Reflect on purpose. After each project, ask what you would do differently. Experience without reflection is just repetition.

The path is not a promotion. It is the daily decision to improve yourself and the people around you. Do that long enough, and the title becomes a formality.

Jonathan Livingston Seagull

2022-01-08T00:00:00+00:00

A fable in novella form about a seagull who is trying to learn about life and flight, and a homily about self-perfection.

Plot #

The book tells the story of Jonathan Livingston Seagull, a seagull who is bored with daily squabbles over food. Seized by a passion for flight, he pushes himself and learns everything he can about flying. His increasing unwillingness to conform finally results in his expulsion from the flock. Now an outcast, he continues to learn, becoming increasingly pleased with his abilities while leading a peaceful and happy life.

One day Jonathan meets two gulls who take him to a “higher plane of existence” in which there is no heaven, but a better world found through perfection of knowledge. There he meets another seagull who loves to fly. He discovers that his sheer tenacity and desire to learn make him “pretty well a one-in-a-million bird.” In this new place, Jonathan befriends the wisest gull, Chiang, who takes him beyond his previous self-education, and teaches him how to move instantaneously to anywhere else in the universe. The secret, Chiang says, is to “begin by knowing that you have already arrived.”

But, unsatisfied with his new life, Jonathan returns to Earth to find others like himself to tell them what he’d learned and to spread his love for flight. His mission is successful, and Jonathan gathers around himself a flock of other gulls who have been outlawed for not conforming. The first of his students, Fletcher Lynd Seagull, ultimately becomes a teacher in his own right, and Jonathan leaves to teach other flocks.

This novella has been translated into over thirty languages.

Audiobook #

Start with Why

2021-11-28T00:00:00+00:00

Start with Why asks (and answers) the questions: why are some people and organizations more innovative, more influential, and more profitable than others? Why do some command greater loyalty from customers and employees alike? Even among the successful, why are so few able to repeat their success over and over?

The ability to inspire those around you and to achieve remarkable things starts with WHY. Those who start with WHY never manipulate, they inspire.

People like Martin Luther King Jr., Steve Jobs, and the Wright Brothers had little in common, but they all started with WHY. They realized that people won’t truly buy into a product, service, movement, or idea until they understand the WHY behind it.

The ability to inspire those around you and to achieve remarkable things starts with WHY.
Any organization can explain what it does; some can explain how they do it; but very few can clearly articulate why.
Your WHY is your purpose, cause or belief.
Every inspiring leader and organization, regardless of size or industry, starts with WHY.
When your WHY goes fuzzy, it becomes much more difficult to maintain the growth, loyalty, and inspiration that helped drive your original success.

People don’t buy WHAT you do, they buy WHY you do it.

Great leaders are able to inspire people to act. And those who are able to inspire give people a sense of purpose or belonging that has little to do with any external incentive or benefit to be gained.

Video Summary #

Become an Effective Software Engineering Manager

2021-06-27T00:00:00+00:00

A great compilation of all topics that are important for management: 1:1s, performance reviews, hiring and laying off, workplace politics, remote work, and others.

The book is divided into 3 parts: the first part covers things a new manager should know, the second and third parts go into topics that all managers should master.

Although I kept nodding along with the bits of advice, I sometimes felt it was too “wordy” or going into too many details that I wasn’t interested in. That said, I kept moving forward, and I am glad that I finished it, gathering a lot of useful tips.

My takeaways from this book:

Part 1 - Getting Oriented #

Chapter 01: A New Adventure #

Practical advice on things to do the first week and finding misalignment signals on your first week.

Chapter 02: Manage Yourself First #

A good reminder of how getting your things an order comes first - this is a pre-requisite to you being efficient, as a manager.

“Your calendar it is both for you and other people to use. Keep it tidy and meaningful. It represents you. Making meetings public by default can help others reason better about how to schedule time with you.”

Part 2 - Working with Individuals #

Chapter 03: Interfacing with Humans #

This chapter covers a lot of ground on how to communicate with others.
Think twice before broadcasting information.
Be consistent in your communications style.

“Don’t communicate when you want to, but when you need to.”

Chapter 04: One-to-Ones #

It’s their meeting, not yours.

“Try to get your direct reports to do 70% of the talking. If you feel like solving their problem for them, don’t. Ask another question and let them arrive at the conclusion themselves. This is an art that takes some practice.”

Chapter 05: The Right Job for the Person #

Motivation and the hierarchy of needs. Developing skills with some practical examples on doing so.

“However, as their manager, you can work with them to place these career achievements at the bottom of their skill tree, and then plan out the milestones along the way that they can aim for to make measurable progress. Thus pushing the frontier of their zone of proximal development further and further.”

Chapter 06: The Most Wonderful Time of the Year (Performance Reviews) #

Preparing for performance reviews ahead of time. Getting peer feedback, and doing this via email, for example.

Chapter 07: Join Us! (Hiring) #

The case for not needing the most senior candidate.
Culture fit.
Setting up an interview process.

Chapter 08: Game Over (Attrition) #

People leaving is normal.
Voluntary resignations that are:
- “good reasons”, aka you could have not done much about it.
- “bad reasons”, that is you could have caught (and addressed) things early like coworker conflict, lack of challenge, compensation.

“As a manager, you are doomed to failure if you think that you are going to keep everyone in your current team indefinitely. […] You should never fight to keep staff if you cannot actually provide the conditions under which they can become happier than they already are. You’ll just defer their departure.”

Chapter 09: How to win friends and influence people (Being well-connected) #

Building your network . Making introductions, checking in with others.
Coaching and mentoring.

Part 3 - The Bigger Picture #

Chapter 10: Humans are Hard #

Working harder or faster isn’t what you should be focusing on. Instead, you should be creating the conditions that make your staff happy and productive through nurturing their autonomy, mastery, and purpose.

“At more senior levels, During bad times, you will get the fingers pointed at you as you are fundamentally accountable, even though it may have not been your fault.”

Chapter 11: Projects are Hard #

“The eye off Sauron” - working on high-stakes projects.
Things slowing down as the team is growing. More (legacy) code, more problems to deal with.
Scope, resources and time balance.

“Lead from the front: As a leader, you need to set the example for the rest of the team. Put in the work. The hardest projects can become career-defining moments. Own them and be there.”

Chapter 12: The Information Stock Exchange #

Spies and gatekeepers.

“As a manager, you will be required to make regular decisions about how much you should share with other staff and when.”

Workplace politics.

“In workplace politics, your network of peers is important as it allows you to be more broadly informed about how the wider business feels about your own initiatives and priorities.”

Chapter 13: Letting Go of Control #

Remove distractions and recharge properly outside work.
Use 10% of your time each week to do nothing and let your thoughts emerge.

“Let go of outcomes that you cannot control. Be accepting of trying your best, and encourage the same behavior in your staff. Unpredictable results are normal. Failure is acceptable. As long as you are trying your best, and you are enabling your team to try your best, then you have nothing to worry about.”

Chapter 14: Good Housekeeping #

Turn problems into learning opportunities.
Work on improving the team communication.

Chapter 15: Dual Ladders #

Designing an Individual Contributor and Manager track is vital to a healthy engineering organization culture.

Chapter 16: The Modern Workplace #

Diversity and inclusion.
Remote working.
Lead by example: work-life-balance.

Chapter 17: Startups #

Management doesn’t mean bureaucracy.
Good management is a light touch and continued collaboration.

“Remember that start-up experience is highly sought after because being impactful in that environment involves being enterprising, self-motivated, collaborative, and quick to learn. Even if the start-up itself doesn’t work out, your next gig will be all the better for it.”

Chapter 18: The Crystal Ball #

Your career vision. Looking back, looking ahead.

“An important part of a long and fulfilling life is purpose. Purpose is not about economic status or feeling well-being. It’s about a life worth living.”

Open-Source Software

2021-05-03T00:00:00+00:00

Every project you ship stands on open-source software. Your framework, your test runner, your compiler, the small library you never think about.

You use it every day. The real question is whether you ever give back.

Giving back is not charity. It is one of the fastest ways to grow as a developer.

What is OSS? #

Open-source is not the same as free software. Free software is one kind of open-source, but open-source does not have to be free to use. Two examples draw the line. PHPUnit is open-source and free. Spryker is open-source and paid. Both publish their code for anyone to read.

OSS is software that is public, open to the world.

Benefits #

Two groups win from open-source: the companies that publish it, and the people who contribute.

For companies #

Open access drives adoption. The easier the code is to get, the faster people build on it. Training and tutorials pull in newcomers and grow the ecosystem. The code tends to sit on the cutting edge, because software that stands still goes obsolete. A public project gathers a community around it, and public channels make that community easy to join.

And because anyone can read the source, anyone can check its quality. That is trust you cannot fake.

For individual contributors #

You pick what you work on. You practice real skills without the pressure of a production outage. You get to play with the newest features of your language, or try a language you have never touched.

You also sharpen the soft skills that carry a career: writing clearly, explaining a change, holding your ground when people disagree.

The code teaches the hard skills. The disagreements teach the rest.

Contributing to OSS #

Getting started with GitHub #

Starting is easy, and you have two doors. Open your own project, or contribute to one that already exists. A pet project fits the first door perfectly.

Pet projects #

A pet project is a playground to build real software and train real skills. Put it on your public GitHub profile and you get every benefit of contributing to OSS, plus one more: you answer to nobody. You set the roadmap. You decide what to build and how. You are your own boss.

The project is there for you. You are responsible to play, explore, and push past your limits.

My pet projects #

Active:

agnostic-ai: write AI agents, skills, rules, and hooks once, use them in every AI CLI.
bashdep: a simple dependency manager for Bash.
phel-snake: the snake game in your terminal, written in Phel.
edifact-parser: a parser for a UN/EDIFACT file format in PHP.
unspent: a PHP library for UTXO-like bookkeeping with unspent entries.

Inactive:

create-pr: a Bash script to open a pull request from your branch and context.

Abandoned:

stock-ticker: get a notification with the news from your favorite Tickers.
jira-status-notifier: Notify when the JIRA tickets don’t move along.
php-best-practices: what I considered best practices for web-dev (archived).
php-scaffolding: a basic PHP scaffolding with Docker (archived).
knob-mvc: a framework to create WordPress templates (2015/2017).

… and many more on github.com/Chemaclass

My OSS organization contributions #

Active:

phel-lang: Phel is a functional programming language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet. I already wrote a post about this: Phel: A Lisp that compiles to PHP
gacela-project: Gacela is a PHP framework that helps you to improve the design of your application by splitting the logic into different modules.

Abandoned:

nm_template: The base template for NuevaMetal (2013-2016).

Code is only half of it. The other half is what you write down and hand to the next person.

Blog posts #

… and many more on https://chemaclass.com/blog/

The beauty of OSS #

Contribute in public long enough and you start to see your own growth. The corrections you keep making. The code you wrote last year, already aged. The mistakes, all of them, in the open. And underneath, the slow proof that you are getting better.

You build a sixth sense for patterns you have hit before, the good ones and the painful ones.

Show your skills. Help the people around you. That is working with the garage door open.

Open-source software offers you one of the best opportunities to start building a career of continuous improvement.

This is a (Spanish) talk that I did remotely on April 2021, for PHPMad Madrid Community. I present all these ideas together with a live demo of how to contribute to a real OSS.

Embrace the Change

2021-03-01T00:00:00+00:00

The book Who moved my cheese? presents a tale inside the main story that consists of 4 characters: two mice, Sniff and Scurry, and two little persons, Hem and Haw.

Published in 1998, and I just read it at the beginning of 2021. Better late than never. Actually, thanks to my brother Jesús, who recommended it to me.

They live in a Maze (that represents one’s environment) and in order to survive they need to go out of their comfort zone and look for cheese (which represents happiness and success).

The tale starts when both groups end up at “Cheese Station C”, full of cheese. The humans established routines while the mice kept their instincts active.

One day the mice arrive at the “Cheese Station C” and find no cheese left. So they go out to find more cheese somewhere else. On the contrary, when Hem and Haw see that there is no cheese left, they start complaining. Hem, angry and annoyed, demands “Who moved my cheese?!”. Both humans counted on the cheese supply being endless and constant, so they weren’t prepared for the unexpected. The main difference here is how Haw and Hem react to this situation.

Hem denies moving away from the “Cheese Station C”, so he keeps going there every day expecting to find cheese without success, being weaker, and with continuous fear of doing something different. Haw, on the other hand, decides to laugh at the situation, turns down his fear, and goes out looking for more cheese.

… I will leave the rest of the tale to you.

The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change.

Noticing small changes early helps you adapt to the bigger changes that are to come.

This book is full of lessons that apply to everyone no matter who they are or when they read it. I fully recommend it.

My favorite lessons of the book #

Change happens. They keep moving the cheese.
Anticipate change. Get ready for the cheese to move.
Monitor change. Smell the cheese often so you know when it’s getting old.
Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese.
Change. Move with the cheese.
Enjoy change. Enjoy the taste of new cheese
Be ready to change quickly and enjoy it again. They keep moving the cheese.

“Everyone knows that not all change is good or even necessary. But in a world that is constantly changing, it is to our advantage to learn how to adapt and enjoy something better. It is not what is in the story of “Who moved my cheese?” but how you interpret it and apply it to your own situation that gives it the value.“ - Ken Blanchard.

“Life moves on and so should we” - Spencer Johnson

Who moved my cheese?

2021-01-16T00:00:00+00:00

This book presents a tale inside the main story that consists of 4 characters: two mice, Sniff and Scurry, and two little persons, Hem and Haw.

The tale is a beautiful metaphor of the different attitudes that people adopt as part of their identity in life when they have to confront any change.

My favorite lessons of the book #

Change happens. They keep moving the cheese.
Anticipate change. Get ready for the cheese to move.
Monitor change. Smell the cheese often so you know when it’s getting old.
Adapt to change quickly. The quicker you let go of old cheese, the sooner you can enjoy new cheese.
Change. Move with the cheese.
Enjoy change. Enjoy the taste of new cheese
Be ready to change quickly and enjoy it again. They keep moving the cheese.

“Everyone knows that not all change is good or even necessary. But in a world that is constantly changing, it is to our advantage to learn how to adapt and enjoy something better. It is not what is in the story of “Who moved my cheese?” but how you interpret it and apply it to your own situation that gives it the value.“ - Ken Blanchard.

I wrote a blog post about this book: Embrace the change

The Process Itself Is the Goal

2020-09-08T00:00:00+00:00

No goal should be an achievement on its own, but the process itself that helps us to go in the direction of these goals.

Goals, in business and in life in general, should be conceived as directions, where their real intention is to help us accomplish more in the way we planned or want.

If we get rewarded only for results and not for processes, we will become pretty miserable.

Society doesn’t reward the journey, but the results, and that’s exactly part of the problem when you are too focused on how society acts on you. Of course, it’s important to listen to society, but it’s more important to listen to ourselves in order to improve constantly. Continuous improvement doesn’t apply to software only but to everything in life.

How do I keep myself focused? #

This is a totally subjective topic that might be different from person to person. That said, I think it might be useful to share my thoughts with you, so I’ll do it.

Self-reflection #

I used to write my thoughts in a “diary” for some years. Back then, in 2015, when I moved to Germany, I didn’t know many people here, and the environment was completely new. I decided to write my thoughts to myself in order to read them the day after and do some retrospection about it. Finally, after around 3 years, in December 2017, I published a book named “Ojos en un recuerdo”. That book is the compilation of those thoughts. No story behind it. They are as they came. You can see the evolution of the topics and about what and how they were written.

The exercise of self-reflection itself was more important than the book! The goal here wasn’t writing a book at all. The goal was the self-projection to understand what was going on inside myself. Publishing those thoughts in a book was an accident. A beautiful accident, though. This habit of thinking about my actions and decisions (what do I do and why) helped me to develop who I am nowadays.

Sports #

Exercise helps my mind to disconnect from the tech area. It keeps my body active using some energy in a different environment. But most importantly, it helps to get fully tired before going to bed. I feel myself resting much better if I’ve done some sport during the day: contact sports, fitness studio, or simply running.

The specific sport itself is an irrelevant detail as far as you feel comfortable. The act of doing sport is the key here.

Books #

I try to read tech throughout the day and non-tech during the night. For example, some days before going to work or after working time I might read a tech book. And some days before going to sleep I like to read a non-tech one. This way, I feed my brain with knowledge and I also provide it with non-tech space, so it can rest from code and enjoy other “universes” as well. Some suggestions that helped me to understand how we behave, why we do what we do, and therefore build some habits that I didn’t know how to:

The Power of Habit, by Charles Duhigg.
Atomic Habits, by James Clear.
Scrum: Doing Twice the Work in Half the Time, by Jeff Sutherland.

Personal tricks #

I wish I would have read much more. Nowadays, with the number of distractions that we have, keeping yourself focused is pretty hard. Some tricks that help me a lot when I want to focus:

I keep my personal phone always in silence and vibration mode.
I used to spend hours on social media; a lot of time wasted. Not anymore. I reduced the social media noise to the minimum by removing the apps that prevent me from being as productive as I want. Some of them from my phone, others the account itself.
I used to play video games. Not anymore. Instead, I go to GitHub to work on my pet projects, contribute to an open-source project, or simply read a book.
When I go for a run, I enjoy it twice by listening to a 45-min podcast that I want to listen to since the very morning. The reward of listening to the podcast is linked with the act of going out and running. I conscientiously created that habit.

It’s not about removing your old habits but replacing them with new ones.

How to improve your habits #

Habits emerge without our consent. To save energy, the brain creates a habit loop that looks for a trigger to cue a behavior.

Willpower can be learned. It needs exercise, like a muscle.
Small successes are the building blocks of bigger wins.
Focus less on goals and more on systems and processes.
To change habits, change how you identify yourself.
To build good habits, the environment is more important than being motivated.
To break a bad habit, reduce exposure to the cues that cause it.
Bundle an action you want to do with an action you need to do.
Don’t try to make a habit perfect, just repeat it.
Reduce friction for good habits and increase friction for bad habits.
Like in Scrum, removing waste is fundamental to get better.

Repetition is the key. Make it easier to do what you want to do. Make it harder to do what you want to stop doing. Enjoy the process: that’s the goal.

Interesting links #

7 languages in 7 weeks

2020-05-21T00:00:00+00:00

You should learn a programming language every year, as recommended by The Pragmatic Programmer. But if one per year is good, how about Seven Languages in Seven Weeks? In this book you’ll get a hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Whether your favorite language is on that list, you’ll broaden your perspective of programming by examining these languages side-by-side. You’ll learn something new from each, and best of all, you’ll learn how to learn a language quickly.

I created this repository with all my learnings while I was reading and playing aroung with the languages from this book https://github.com/Chemaclass/7LangIn7Weeks

How to Improve Your Tech-Talk (or Any Other Presentation)

2019-11-18T00:00:00+00:00

We have found ourselves attending a meeting that felt like we were wasting our time with a “monologue” that is either hard to follow or doesn’t seem so interesting as it could. Let’s fix this.

Therefore, I was thinking about it, and I tried to get some keys to improving their general quality. It applies to all presentations but also tech-talks and other tech presentations in which engineers are usually involved.

Structure of the talk #

To explain how I think a good presentation should look like I will address three main topics that are relevant to structure and design your presentation.

Content of the presentation: what message do you want to convey to whom and how?
Design and Layout: how you can design an easy-to-follow presentation that supports your talk instead of taking away the attention from what you are actually trying to say.
Lastly, I think also the audience is responsible for making a tech talk successful, so I will also add a reminder about the role and responsibilities of the listeners.

Consider your audience #

When you prepare your presentation, ask yourself:

Who is attending the talk?
Which backgrounds do they have?
Which position do they have?
Which information is relevant to them?
Do they have to know all the keywords that you would like to use?

Introduce the topic #

Create some atmosphere. Try to answer these questions:

Why should they listen to you?
Why should they spend their time in another meeting?
What will they have learned by the end of the talk?
What is your main message?

Every meeting should have an output and an outcome. Keep it in mind.

Create a Storyline #

When preparing the main content of your talk, think about a storyline that connects your arguments. This makes it easier for the audience to follow.
Stick to the messages that are necessary to explain your idea or concept.
Leave out any unnecessary information that is not relevant to the core of your message.

Build a conclusion #

Summarize the main conclusion(s) in a concise way:

What is the conclusion of this meeting?
What are the learnings from this meeting?
What are the open questions or next steps?

Design and Layout #

Write less, talk more #

A tech-talk is about learning new ideas and concepts.
A presentation should support your talk, not replace or replicate what you have said.
The more words on the slide, the fewer they will be remembered.
Use visuals/graphics that support your talk instead of additional text.

Large fonts #

If you have some code to present, consider:

If it is a picture: use large fonts inside. I recommend using https://carbon.now.sh/ for simple snippets. Or just screenshots from your favorite IDE.
If you code in live: prepare your editor in advance. Use the Presentation Mode of your IDE.

Role of the Audience #

Responsibilities of the attendee #

No unnecessary phone usage, like Twitter, Instagram, Facebook, WhatsApp, Telegram, etc.
Keep your questions for the questions time, unless the presenter mentions at the very beginning that you can ask at any moment. Usually, it’s better not to interrupt the topic, so we can ask the questions at the end.
Show interest in the topic. The presenter should have spent some time preparing the slides for you.
Pair with the presenter the interest of the topic. This is also the responsibility of the presenter. You both should be eager to learn more about the topic.

Inner questions #

Was it worth the time that we all spent in this room?
Do we regret the attendance of this meeting?

At the end of the meeting, we should ask these questions in order to improve. Ask other people for their feedback, so we can grow further and together.

Atomic Habits

2019-11-12T00:00:00+00:00

People think that when you want to change your life, you need to think big. James Clear has discovered another way. He knows that real change comes from the compound effect of hundreds of small decisions. He calls them atomic habits.

Takeaways #

Focus more on systems and processes and less on goals
Change how you identify yourself
The environment is more important than being motivated
To break a bad habit, reduce exposure to the cues that cause it
Bundle an action you want to do with an action you need to do
Instead of saying “I have to,” say “I get to”
Don’t try to make a habit perfect, just repeat it
Reduce friction for good habits and increase friction for bad habits
To make something not seem like a chore, do it for short periods of time
To achieve long-term goals, make small habits rewarding
Never miss more than once of a habit

I wrote a blog post about this topic: The process itself is the goal

The Power of Habit

2017-03-20T00:00:00+00:00

Takeaways #

All habits operate the same way
Changing a habit means changing one key aspect…
…and changing one habit can change a lot of things
Willpower is a muscle
Practice, practice, practice

The Pragmatic Programmer

2016-10-01T00:00:00+00:00

Takeaways #

Don’t Repeat Yourself.
Mindset is as important as knowledge.
Good code is easier to change than bad design.
Choose great tools and become fluent with them.

Don’t Repeat Yourself (DRY) #

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.

Mindset is as important as knowledge #

Some important aspects of this mindset include:

Taking responsibility for your work by not making excuses or passing blame when things go wrong.
Writing software that’s good enough. This means not wasting time on things that are better than they need to be to make the product successful.
Not ignoring technical debt. The authors use the analogy of broken windows:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead.

The Clean Coder

2016-08-01T00:00:00+00:00

Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common attribute: They care deeply about the practice of creating software. They treat it as a craft. They are professionals.

Readers will learn #

What it means to behave as a true software craftsman
How to deal with conflict, tight schedules, and unreasonable managers
How to get into the flow of coding, and get past writer’s block
How to handle unrelenting pressure and avoid burnout
How to combine enduring attitudes with new development paradigms
How to manage your time, and avoid blind alleys, marshes, bogs, and swamps
How to foster environments where programmers and teams can thrive
When to say No and how to say it
When to say Yes and what yes really means

Summary #

Chapter 1: Professionalism #

Being a professional means taking full responsibility for one’s actions.
First rule is not doing harm to the function nor the structure of the software.
You will always make occasional mistakes, but you must learn from each.
You should be certain about all code you release and firmly expect QA to find nothing wrong with it.
- Test it and test it again.
- Automate your tests.
- Design your code to be easy to test.
You should follow the Boy Scout rule and always leave a module a little cleaner than you found it so that it becomes easier to change over time, not harder.
Your career is your responsibility, not your boss nor your employers.
- Spending 20 hours a week beyond your normal work to improve your knowledge and skills.
- Read, experiment, practice (kata), talk to other, collaborate, look over the fence, mentor.
- It should be fun.
Also, know your domain, identify with your customer (no “us vs. them”, ever).

Chapter 2: Saying No #

Professionals have the courage to say no to their managers.
Managers and developers have roles that are often adversarial, because on the short term, their goals tend to conflict.
The higher the stakes, the more valuable a “no” becomes, and the harder to say.
Good teams will successfully work towards a yes, but only a right yes, that will later work out in practice.

Chapter 3: Saying Yes #

There are three parts to making a commitment:
- You say you will do it
- You mean it
- You actually do it
Your commitment must respect the limits of what you expect (based on your experience) you can and cannot do.
- If you recognize you will probably not be able to meet a commitment, you need to raise a red flag immediately.

Chapter 4: Coding #

Programming requires a level of focus that few other disciplines require.
“The zone” (or “flow”) is not as good as people think: you will be locally productive, but will often lose the bigger picture and possibly product not-so-good designs.
Interruptions are bad distractions.
- Pair programming is helpful to cope with them.
- TDD helps to make the pre-interruption context reproducible.
  - Minimize time spent debugging
Coding is a marathon, not a sprint, so conserve the energy and creativity.
Leave when it’s time, even in the middle of something important.
Continuously re-estimate your best/likely/worst completion time and speak up as soon as you recognize you will likely be late.
- Do not allow anyone to rush you.
- Use a proper definition of “done”, with sufficiently high quality requirements.
Programming is too hard for anyone, so get help and provide help to others, in particular (but not only) in mentoring style.
- Don’t be shy from asking.

Chapter 5: Test-Driven Development #

TDD is not a cure-all and is impractical or inappropriate in some (rare) cases.
TDD Cycle:
1. Add a test
2. Run all tests. The new test should fail for expected reasons
3. Write the simplest code that passes the new test
4. All tests should now pass
5. Refactor as needed
6. Repeat

Chapter 6: Practicing #

A programming Kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem.
- A Kata is about the process, not the solution.
- You aren’t solving the problem because you already know the solution.

Chapter 7: Acceptance Testings #

Avoid garbage in, garbage out. Make sure you understand the requirements.
- Creating this understanding means removing ambiguity.
The best way to do this is defining acceptance tests:
- All customer’s conditions need to be fulfilled by automated tests to prove the expected software behavior.
- Success of those tests constitutes the definition of “Done”.
Code implementation should start only when the tests are complete.
Unlike unit tests (which are only for programmers), the audience of acceptance tests are both: business and developers.
Run all tests in a continuous integration and immediately fix any failures.

Chapter 8: Test Strategies #

Consider QA part of the team. They act as specifiers: writing acceptance tests, including the failure cases and corner cases, and perform exploratory testing.
Testing pyramid:
- Most tests are unit tests. By developer and for developers.
- Many tests are component or integration tests. By QA or Business assisted by Developers. For Business and Developers.

Chapter 9: Time management #

Management roles in software development requires good time management.
Meeting are necessary but are also often huge time wasters, so avoid meeting that have no clear benefit <- this is a professional obligation.
Meeting must have an agenda and a clear goal.
- Agile stand up meetings can be an efficient format.
- Iteration planning should take 5% of the iteration.
Concentration (focus) is a scarce resource.
- Use it well when present and recharge with simpler tasks (meetings) and breaks in between.
- How to improve?
  - Sport.
  - Creative input.
  - Short breaks every 45 minutes.

Chapter 10: Estimation #

Estimation is the source of most distrust between business people and developers because the latter provide estimate which the former treats like commitments.
- Both are insufficiently aware that the estimate really is a probability distribution, not a fixed number.

Chapter 11: Pressure #

The professional developer is calm and decisive under pressure, adhering to his training and disciplines, knowing that they are the best way to meet pressing deadlines and commitments.
Avoid situations that cause pressure via:
- make only commitments you can fulfill
- keep your code clean
- work in such a way that you need not change it when in crisis
Don’t panic. Talk with your team. Don’t rush. Trust your disciplines.
Offer to pair to others in crisis.

Chapter 12: Collaboration #

Not all but most programmers like working alone. But we need to understand the goals of the surrounding people, including business folks.
- This requires communication.
Likewise, within the development team: only collective code ownership and pairing produce a good level of communication.
- Programming is all about communication.

Chapter 13: Teams and Projects #

Teams need time (months) to gel, to really get to know each other and learn to truly work together.
- Assigning fractional people to different projects is a bad idea, as is breaking up a good team at the end of a project.
- Instead, assigning several projects to one team can work well.

Chapter 14: Mentoring, Apprenticeship and Craftsmanship #

Young programmers need mentoring.
- Mentoring can be implicit or explicit.
Given that we entrust software with all aspects of our lives, a reasonable period of training and supervised practice would be appropriate.

In this lesson, Uncle Bob demonstrates the need to write a clean code and establishes the bases to achieve it, being these bases of a social and scientific nature. Making it clear that the future of programming is based on an ethical and polite code.

In this second lesson, Uncle Bob teaches us the purpose of comments in the code, breaking the paradigm that commenting is something “I have to do” for the simple fact that we mistakenly consider that commenting is a good practice. For Uncle Bob, writing a comment is a sign of failure, since a good code must be able explain by itself: Fewer Comments = Better Code.

In this third lesson, Uncle Bob focuses on raising awareness, given the need to increase the level of criteria in code production. Pointing to the lack of preparation in most programmers, as one of the main reasons for the inefficiency in software development today.

In this fourth lesson, Uncle Bob introduces us to a software development methodology oriented through testing. This is the Test-Driven Development (TDD), a practice with a long learning curve, but with significant results to generate a more robust, safer, more maintainable code and with greater development efficiency.

97 Things Every Programmer Should Know

2016-07-15T00:00:00+00:00

Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you’ll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice.

My main key takeaways #

01.- Pay off technical debt as soon as possible.

02.- Learn and master functional programming.

It makes your code less prone to error and easier to debug.

03.- Don’t guess what a user would do; get users to do things and watch them.

04.- Automate coding standards.

05.- Write simple code, simple descriptive names, simple relationships.

06.- Before you refactor: consider the existing tests and code.

Work in increments, make sure the tests still pass after every change.

08.- Always leave code cleaner than you found it, even if you didn’t write it.

10.- Choose your libraries/frameworks carefully to avoid unnecessary complexity.

11.- Make your code easy to understand using domain terms.

13.- The layout of the code is also important.

14.- Use code reviews focusing on knowledge-sharing among team members.

15.- Objects immutable whenever relevant. Each variable should have the smallest possible scope. Never include more than four function arguments.

18.- Take responsibility for your own education and never stop learning.

That can be done with just a bit of time each week and there are many ways to go about it (e.g. podcasts, lessons, books, etc.).

19.- When designing an API, aim to make it easy to use, not convenient to code.

20.- Deploy early and often. Do not leave it until the end of the project.

22.- Improving your skills should be on your daily basis.

23.- Adapt the technical level of your domain-specific language to your audience.

24.- Don’t be afraid to break things if that’s what’s necessary to fix things.

25.- Careful with your test data because that might go public accidentally.

26.- Handle your errors as they appear, don’t leave it for later.

27.- Learn different programming languages.

Learn their own “culture” or way of doing things.
It’ll make you definitely a better programmer.

28.- Don’t just catch your errors, really handle them.

29.- Understand at least some complexities of your business, not just programming.

30.- DRY: Don’t Repeat Yourself.

32.- Encapsulate behavior, not just state.

33.- Floating point numbers inevitably can create errors in calculations.

34.- Open source is a great opportunity to do interesting work and develop programming skills.

36.- Give proper context when asking for help, because people can’t just guess what’s going on.

37.- It’s not about the long hours. Learn to work effectively.

Dedicate time to continuous learning and to think about what you’re doing.

38.- Write proper bug reports:

Precisely how to reproduce the bug,
how often it appears,
what should have happened,
what actually happened.

39.- Don’t write unnecessary code.

Only write code that adds value and is needed right now.
Remove dead code.

41.- The main cause of delays in application response time is a high number of remote interprocess communications, not the algorithm.

DB connections, for example.

42.- If a compiler warning shows up in your build, fix it.

Don’t leave it for later. Even if it’s not going to be a problem in production.
Compiler == any static code analysis for non compiled languages.

43.- Learning to use command line tools is a valuable educational experience, and you might end up preferring them.

44.- Learn (at least) two different languages and paradigms well.

45.- Invest some time to master the IDE you’re using.

It’ll make your life easier and save you time in the long run.

46.- Know and work with your limitations: budget, resources, time, etc.

47.- Work in small tasks, don’t be afraid to throw away changes.

You’ll still have the insight you gained from the experience.
Know what you need to accomplish beforehand.

48.- Use a relational DB if your application is going to handle a large, persistent, interconnected set of data.

49.- Learn to communicate well in many “languages”: not just to your machine, but also to business partners, and maybe even pick up a foreign language too.

It’s good for connections and for life.

54.- Think twice before implementing “temporary solutions”.

55.- Make GUI easy to use correctly and hard to use incorrectly.

Anticipate errors and find ways to prevent them.
It’s about the user’s experience, not your own.

56.- In projects, find ways to make the invisible visible.

57.- Message passing leads to better scalability in parallel systems.

58.- Write code that other people can easily understand.

59.- Using polymorphism in your classes and objects reduces the need for if/else statements, which results in smaller, safer code.

60.- QA is your friend, not your enemy.

61.- Version your releases.

62.- Make sure your source code clearly states what the program is doing.

63.- Learn about the build process. It’s an important part of development.

64.- Practice pair programming.

65.- Prefer domain-specific types over primitive types.

They make the code more readable and less prone to errors in development.

67.- A professional takes personal responsibility for their career and their code.

68.- Use version control.

69.- Sometimes the best way to solve a problem is to step away from the computer and let the solution magically appear in your mind.

70.- Reading code is a good way to learn. Other people’s or your old code.

72.- Reinventing the wheel is a great way to develop your skills.

75.- If the code you wrote is truly horrifying, don’t try to fix. Delete it and start again.

76.- Apply the Single Responsibility Principle (SRP).

77.- If a client or team member requests a product change, don’t dismiss it outright even if you don’t agree. Ask why instead.

That will lead to a more productive conversation and better results.

78.- If you’re doing the same thing over and over, try to find a way to automate it.

79.- Take advantage of code analysis tools.

80.- Write tests based on the desired functionality of your program, not incidental behavior.

83.- Testing takes time, but it ensures the quality of the end product. Do it.

85.- There are many benefits to collaborative work and pair programming.

86.- Sometimes fixing a mistake in the code leads to uncovering a hidden error.

87.- Write code with other programmers in mind.

88.- Learn to use Unix tools. Learn how to use the terminal.

89.- Use the right algorithm and data structure for the job.

To do that, you need to understand them well.

90.- Have a good logging policy.

91.- Using the DRY principle helps you identify and repair performance bottlenecks.

92.- Testers and programmers should collaborate.

93.- Write code as if you had to support it for the rest of your life.

94.- Try to write “small” functions.

Good tests act as documentation for the code they’re testing.

They describe how the code works.

To be a good programmer, you have to care about the quality of the code.
Really, really discuss things with your customers before assuming you understand what they want.