Open Manage, Be Responsible

Manage, Be Responsible

All the popular tools companies use nowadays have a way to hide the mess you create while you are using the product, or at least attempt to hide it from you, in a way to not make you feel responsible for that mess. These products are built this way because it lets you tell yourself a story of how great this product this is that it doesn't make me feel bad.

Think about tools used for documentation, project management, chat tools, email clients, bug tracking software. Many of the tools in any one of those categories have a way to just create things "because it's important now but don't have the time deal with it right now". That same place fills up very quickly and starts overflowing even faster. And before you know it, you have created a monster that feeds on your good intentions will come to bite you at every decision you make.

It's hard enough to make any good decision at all. It is even harder when there is a bottomless pit that keeps distracting you with "What about this

Open Say No, Meet Expectations

Say No, Meet Expectations

At work, the demand for our time will always surpass the amount of time we have available. A colleague with an idea, a prospect wants to meet for lunch, a client has an internal emergency, a boss asking questions, your monitoring system alerting of a server going over capacity, a partner notifying you of changes to an already agreed plan, among many other common things that happen daily, are all requests for our time an interruption of the what we are focusing on.

The actual problem doesn’t come from the amount of requests because eventually, on a long enough timeline, we can work through every single request. But, actually the problem comes from the need to solve requests in a timely manner.

In order to do so, at the quality others expect from us, we have to communicate with them that we are or aren’t able to handle their requests in a timely manner that would satisfy their needs. Providing an alternative or redirecting to someone who can help is always welcomed. Having a

Open Enabling beginners to learn

Enabling beginners to learn

You have a problem in front of you that has a clear outcome but the steps to get there might vary, you can take many paths to solve the problem and there is no straightforward proven solution. On top of this, the problem you have to solve involves an entire system depending on your solution maintaining the correct functionality of the system.

What do you do? You start tweaking the system, making a small change here and there. You poke the system to see how it breaks or when does it run smoothly. You learn what is safe to change and what makes the system break. You do all of this without even consciously thinking about it, of course you can do this because you are an expert.

Will the beginners in your team be able to solve the same problem? Of course not. Will the other experts, without all the knowledge you have about the system, be able to solve the problem? Maybe.

To solve this you can take the easiest approach and make the watch you solve the problem but that’s lik

Open Good and bad, or average

Good and bad, or average

You have one good thing and one average thing.

The good one will become average which will become bad. The average will become bad. Both will decay at the same pace.

On one hand you can enjoy the good thing first and feel some disconfort with the bad thing.

On the other hand you can enjoy the average thing first and let the good thing become average.

Which one do you choose to enjoy first? The good one or the average one?

Open Build around your tone

Build around your tone

Any creation out there is the market can fall into two categories, simple or complex. The audience is what differentiates them.

Simple things are meant for individuals that share the same problems as you but haven’t put in the time to figure out a solution. Complex things are meant for systems that require unique solutions to their unique group of people.

Both solutions have the same goal, to save time. Both businesses have many weakness that can put them out of business. Both businesses have a unique advantage, the maker’s tone.

The tune can be summarised as a sum of problems, motivations and knowledge. Only you can solve problems for your audience the way you do but you cannot solve problems as other person would - you can attempt to copy them but it would be the same.

The first time you show it to the world it might happen that no one likes it. It might be that you showed it in a place where there was no audience. You have to keep showing up in order to find the swee

Open Two schedules

Two schedules

At the end of every year we make plans for the entire next year, fire years, decade. Some even dare to plan the entire century. We come up with big drawings, even bigger lists and even bigger charts that displays how much we know about how the future will look like, how are we going interact with it and make the best of it.

Yet, we forget about the day to day business, we treat as it is somewhat of a lower class. Maybe we do it because it is less compelling than the big stuff. Maybe it is because we can allow ourselves to have an abstract view of the future but for the day to day we have to be very specific. Maybe because the daily work is so specific for everyone that frameworks might get in the way instead of helping.

I have struggled with this for quite a while now and recently have arrived to the conclusion that by categorising the daily work into exploratory and actionable work, and batching tasks by those two categories allows for a mor productive day with lesser effort. 

Doi

Open Swing To Win

Swing To Win

Kettlebells Swings might seem like a simple exercise to an outside yet it take thousands of repetitions to get it right.

First you need to learn to pick-up and put-down the kettlebell from the ground. Next you have to learn how to translate the power from for you feet, to your quads and to your glutes. Next you have to learn to tension your upper body, use your hands to anchor the kettlebell and let it flow. Next you have to learn how to time the upswing, use your hands to push the bell down and flex the waist at the right moment. Next you have to learn to do this more than one at the time.

That is all you need to know about swinging kettlebells, you can read it again and again and not be able to swing a kettlebell without practicing each step individually and then learn everything as a whole.

The rules for swinging a kettlebell are short and straightforward but there is more depth to it. The way you approach the kettlebell swings practice session is what gives depth to this exercis

Open Jump into the rabbit hole

Jump into the rabbit hole

Currently I am working on a project that is using technologies I have learned 5 years ago for the sake of learning them. At that time I didn’t have any useful appliance for them other than learning them out of curiosity. I even doubted myself while learning because it seemed like a stupid investment of time but even so I thought it was cool and I kept doing it.

Soon, the ideas that I was discovering started to cripple in my day to day job to an even increasingly positive benefit towards the quality of my work, the way I was able to think and reason about problems - I felt like all of a sudden I had replaced a rock with a hammer and a screwdriver. 

Having those new ideas felt strange at first. Not knowing where they came from made me feel like an impostor, what made it worst was that I was getting my way more often than not. This had a spiralling effect of thinking what if I was making things

In retrospect, it took some time for the ideas I was learning to integrate deep

Open Upfront Reasoning

Upfront Reasoning

Everyone is capable of building complex things and there is no one better than a novice to put unnecessary complexity into a system; but knowing when to take the shortcut, when to pause an think it through, when you start over from scratch because you foresee the dangers ahead is skill only acquired through the process of mastery.

Your ability to reason increases the more experience you have and the more skilful you are, the more you are able to reason upfront be it because you tried something and found a cliff at the end of the road or because you know you can solve it in a simpler manner and do no harm to the final product.

Be aware of growing old and fixed in your ways. That’s a sign of your reasoning decreasing in skill because you might be dismissive of new ways to solve previous roadblocks where you got stuck. This leads to you not being able to reason so further down the road.

The further ahead you can reason, the faster you can build because you need less iterations to

Open Aim for 101% completion

Aim for 101% completion

We all have a tendency to stop trying hard as we are within reach of our goals. We start fooling ourselves with it’s just one more page that I have to write, it is just one more review that I have to do, it is just one more … . That one more thing is never just one more thing but we like to bath in the idea that our goals are just within the reach of one more thing because it is actually comforting.

The problem is that in the moment we have our goal within the reach of one more thing, is the moment at which we stop putting so much effort into achieving it, we fall into the trap of the small thing that I can do whenever I want to but seems like actually never want to do or suddenly you no longer have time to do it. 

This situation has a snowball effect and the more you keep yourself in it the harder will become to course correct and reach your goal. If you keep the situation going long enough, then you might abandon whatever is that you have been doing and lose all the effort

Open Lagging Behind

Lagging Behind

I have forgotten how it was before we had working supply chains. Before we had always ready stock for almost all the product variation a vendor offered. The waiting time for pieces. The little importance we gave to buying the latest of the latest. The focus we put on just solving our problem and not focusing on having a marginally better product.

It was this way because it was very hard to get your hands on the latest device anyway - and because choices were limited anyway. But recently we have fallen down the rabbit hole of too many options available to pick and every option is also available for purchase and can be purchased right away from many vendors in many places.

All this availability creates a FOMO environment because a device can never have the best on all of its attributes and will always be better or worse on some aspects versus other devices. To breakout we have to go back to the ways we decided when availability was a problem, to when we actually had a problem to solve.

Open Cleaning Is Part Of The Job

Cleaning Is Part Of The Job

Any work you will disorganize the things around you. You might end up with crayons out of their boxes, files all over your desk, so many tabs than only the closing button is visible, code comments that explain nothing, functions that nobody uses, too many hidden layers in a design file. The list could go on and on but you get the point.

Imagine a chef coming into work in the morning, after a large guests dinner party, and having to clean after the mess of the last night instead of being able to start preparing and cooking for the lunch hours. Well, something similar happens to all of us when we don’t care of cleaning the mess we leave behind be it digital or physical. We are not only shown down by the mess but actually blocked by it.

Cleaning is not only about our mess, but also about all the mess in our workspace. If you see a piece of code that could be cleaned up, power tools with dirt on it, empty coffee cups in the meeting room… are you going to leave that there or

Open Consistent Products Lines

Consistent Products Lines

The people working on a product build consistency within that product.

Have you ever interacted with a product that everything seems to be in place, that everything seems to just make sense, that works just perfect for the scope it was built for, that every feedback message made sense, that every process or setting or configuration had just the required amount of controls? Well, that is the result of people focusing on delivering the best product. It’s true that this kind of products might miss some bells and whistles.

The people working on a domain build consistency across that domain.

On other side, have you ever interacted product that everything seems to be customisable, that has all the right indicators, that has all the right information at the right place at the right time, that has options that you didn’t even knew you needed. Well, that is the result of people focusing on delivering the best domain expertise. It’s true that this kind of products might have too

Open Price changes

Price changes

Recently I increased the pricing for the software services I offer and I got two kind of responses. One was about the percentage I have increased as it seemed too high for some to adjust and another response that they accepted on the spot.

This got me thinking about the reasoning and I have concluded that the response comes from the base reference. 

For the first case, their reference was my previous quote. The amount didn’t matter but since the increased percentage was high it was all it mattered to for the first reaction to kick in.

For the second case, their reference was the price of the market that they would get if they requested the same services from another person in the market. No thought was given to the percentage increase.

These two scenarios lead to another conclusion that we all go through the same experience, be it with products or services required in our personal life or business environment. When we have an unsatisfied need, we look around at the market scouti

Open Use Others Software

Use Others Software

There is a positive stigma associated with writing software for the sake of writing software just because someone is capable of writing it. Every builder can build a hammer, that doesn’t me any of them actually builds their own hammer unless the project depends on that custom build. Writing software systems from scratch for a project work only for proof of concepts or solving highly defined problems in which you required to squeeze out every bit of performance. By doing this

When that is not the case, you are always better of by using software others wrote for common problems to solve your business cases because the only way to make any system more reliable is to push to the limits and there is no better example of this than the open source software out there. Used by many, in many ways that it wasn’t intended for, at scales for which it was not designed for.

To be clear, this has nothing to do with the headcount of your team. If you look at how large software companies operate

Open Done Means No Rough Edges

Done Means No Rough Edges

Nowadays a lot of software comes packed with features that you can clearly see that they haven’t been used by any customer of the product before being launched to the public. 

This manifests with scenarios like having to make a few wrong attempts in order to see how a feature works, when the tools usage flow is clunky, many options available all thrown together in an attempt to cross off as many items as possible from the features list.

This kind of behaviour erodes your customer trust and lowers their expectations of your products thus perceiving it as a low value product. Their thought process is “What if it remains like this forever?”. Product businesses can actually escape from this hole if the move fast enough and iterate enough until they deliver what they initially have promised.

Unfortunately, when businesses outsource their software needs and the budget limit is reached there is no more room for new iterations and improvements and they get stuck with a piece of

Open Don't Skip Steps

Don't Skip Steps

We all have written pieces of software with very similar capabilities, very similar internal functionality, for very different clients yet somehow there were always things that went south. That happens in part because no one can digest the entire system in their head and be aware of all the pitfall all the time.

But also because with each successful deployment our expertise grows, and so does our confidence, and we become a little bit more cocky next time and we start skipping steps in the process like requirements clarifications with the client, making system diagrams, building a list of use cases which will be used as test scenarios later.

To avoid that, we should look at expertise as something that allows us to see further down the road therefore enabling us to clarify more requirements at the beginning stage of the project which leads us to build the right solutions for our clients. 

It is our responsibility to ask questions, poke the thinking process of our clients, look fo

Open Implicit Hinders Reusability

Implicit Hinders Reusability

When we are writing code, we all tend to want to make one thing do more than one thing because in the moment it just makes sense to have all of that in one place. All those auto loaders,

Look ma’ I just press a button a solve all those problems!

…

For now.

But how about when the inevitable moment comes and your business rules change or an update to the underlying technology you are abstracting changes, or you need to change a service provider, or … and you have to adapt to it?

You have two options, degrading the capabilities of your code by adding conditionals that skip a lot of the steps you have built-in in the first place or a huge refactoring to allow the one thing to do another thing. Deep down, we all know for which one you will actually have time. 

There is a bigger problem than having to fit another use case in a component that was built to do an implicit thing and to do it well, or the time spent refactoring the entire service to be well scoped this

Open Do Your Best

Do Your Best

The better you can do. The better others can do.

Building a software application for your clients that enables them to improve stocks handling or fulfil order faster and cheaper or reduce response to customer inquiries, or the other million things you can help a business do better with software, enables them to do better.

Turns out this makes them rely on you and the quality of your products. 

On one side, If you have built a qualitative product from the beginning, you will charge your customers a fair share, they will be able to build more business, reinvest profits and build new business which makes them have new problems for which you can find solutions, bigger needs for which you can build even better solutions. For sure you will have to fix things now and then, here and there, for a small fee but anyone buying a system knows it comes with a maintenance toll.

With all this surplus, you can pursue new endeavour that might bring even more business to the company.

On the othe

Open More Reps Ahead

More Reps Ahead

More books, more lines of code, more started projects, more bad decisions, more good decisions, more biceps curls, more deadlifts, more kettlebells swings, more ran miles, more written words, more shower thoughts, more deliberate practices, more connections, more sales pitches, more discussions, more ideas, more early mornings, more late nights, more bonuses, more compounding activities, more savings, more product launches, more fuck ups, more customer data loss, more…

That’s all someone who you look up to, who is ahead of you really has.

There is a point to be made about moving sideways, finding a new edge, exploring new techniques but in the end, a better rep is just another rep.

When are you going to start catching up?

Open The Foundation & The Details

The Foundation & The Details

You can’t build the details without having a foundation and you can’t build a foundation without knowing which are details it will be used for.

When we are working on either the foundation or the details, it easy to keep our heads down and dismiss the other half of the project. That’s the reason every software project “last 10%” actually takes 90% of the time because it is actually the other critical half of the project.

The following sentences may affect you emotionally.

“I have all the foundation laid out, I just have to implement the details.”

“I have all the details figured out, I just have to lay the foundation.”

Now, it easy to dismiss this by saying “I have a reusable foundation” which is true if you are building the exact copy of a project which is never true because even the slightest change in the details will also affect the foundation. The same is true for the details, “I have all the details ready to use” is never true because the way you need

Open Tools, Frameworks & Details

Tools, Frameworks & Details

All the things that are built, crafted, manufactured inside a category have a common overlapping base because all the products solve a a general problem inside a category. 

By looking at all the hammers on the market, you can easily identify which is the starting point for all the hammers, yet there plenty of choices from which to choose because each hammer focuses on different types of details.

You can always try to build a hammer from the ground up by changing the structure, the position of the elements, the materials but you will always be missing the amount of time spent by the hammer manufacturer on nailing out the details for the specific case it was designed.

Once a design has stood the test of time, there is not much to gain by attempting to reinvent it again and again at the start of each project just because you have the knowledge and expertise to build it.

There is only so much time and energy you can spend focusing on the details that really matter in y

Open Beware The Glue Amount

Beware the Glue Amount

Working with glue is messy. You have to be very careful where you place so it doesn’t drip over anything. You also have to apply it carefully so it doesn’t stick to your hands; and you also have to store it carefully so it doesn’t stick the entire drawer together. All this trouble applies to every time you apply glue, so the more you use, the easier it gets to get in trouble. The funny thing is that after all this trouble we don’t know how long the solution is going to last.

And yet we use it again and again because is the best way to fix things, to get things to work together when they are not built from one piece. Of course there are better alternatives, to glue, like duct tape or wielding but in the end they are used for the same end, to bring many different parts built, many other people, to form the final structure that will be usable for our purpose.

We run into the same problems in when building software projects. There are several big components in our projects that a

Open Versions Are Disruptive

Versions Are Disruptive

The iPhone has only ever released 2 versions. The iPhone 1 that introduced smooth multi touch gestures on a phone screen without a physical keyboard attached to it and the iPhone 2 that made the transition from a phone to a smartphone enabling you to install apps an basically have a powerful mini computer in your pocket. All the subsequent changes in number actually are better iterations of the iPhone 2, more battery life, better screen resolution, better sound, better connectivity.

Getting to Version 1 is a tough road filled with many Version 0 of products that almost had all the necessary requirements to make it but in the end they weren’t a viable solution for the problem they set to solve. Some Version 0 are solid enough that investments in their next iteration are justified even if only for the learnings that you will get from going down that road.

The good thing is that all Version 0 provide learnings on what to do, what to not do and your skills get polished for the n

Open Practice Brain Dumps

Practice Brain Dumps

During our working time our minds collects feedback about the work we are doing and during our downtime our minds wanders and tiny sparks of brilliance come up. Subconsciously we try to hold them for as long as possible in our working memory but unfortunately our capacity is very limited thus creating situations in which we can’t think of anything new because we are at capacity.

For this reason, practicing brain dumps from time to time has a positive impact our performance because it brings order to the chaos that our working memory has become. It helps you situate yourself by doing a recap of recent events, emptying the working memory of currently going on things and provide structure for the upcoming events.

Here is how it works:

1. Make a list of all the things you are currently handling and are in your working memory
2. Remove those items that no longer seem to make sense
3. Make a list of all the upcoming things you can recall
4. Group what you have had in your worki

Open You Pay For Taste

You Pay For Taste

Good taste is the result of all the time someone spends on thinking about and working on any topic in any field.

The technical side of it is the time spent learnings the skills necessary for bringing a project to completion; of refining the techniques to accomplish even better details than the previous version; of all the fruitless paths taken in order to know what to anticipate even further in the future what will work and what won’t.

This is the baseline required of everybody in any field.

Now, what makes a difference is the personal experiences that one embeds into the work which gives a unique shape to the otherwise practically identical base that all things in the same space have.

This is the reason why you prefer a painter over another, a musician over another, an architect over another, a gadget maker over another and so on.

The taste is also the reason why sometimes some products that have very similar technical specifications can get away with charging two, three

Open Cookies & Broken Promises

Cookies & Broken Promises

Good taste is the result of all the time someone spends on thinking about and working on any topic in any field.

The technical side of it is the time spent learnings the skills necessary for bringing a project to completion; of refining the techniques to accomplish even better details than the previous version; of all the fruitless paths taken in order to know what to anticipate even further in the future what will work and what won’t.

This is the baseline required of everybody in any field.

Now, what makes a difference is the personal experiences that one embeds into the work which gives a unique shape to the otherwise practically identical base that all things in the same space have.

This is the reason why you prefer a painter over another, a musician over another, an architect over another, a gadget maker over another and so on.

The taste is also the reason why sometimes some products that have very similar technical specifications can get away with charging tw

Open Slice The Work

Slice The Work

Work comes in various sizes from the smallest change to the largest taunting feature but there is only so much that one can focus on at a time while delivering a high quality output.

Just like a pizza is easier to eat when sliced, work is easier to perform and the result of better quality, when a though or two is given to how to split the big chunk of work into smaller, more manageable, easier to argue about and understand rather than having it all at once. And like pizza, if one feels like leaving a slice or two out because you have already reached your goal, you can do it.

When looking at a thing as a whole is close to impossible to figure out the inner workings of the system, to understand why some tradeoffs were made. In order to start exploring what are the moving parts that make up the components one has to reduce to First Principles the requirements of the problem in order to really understand what is needed to build the feature. 

For this reason one has to first unders

Open Urgency Towards Action

Urgency Towards Action

The calm pursuit of moving aggressively towards tangible solutions while maintaining a high standard for quality. This is not about rushing the work just to get it out the door in hopes no one notices. A high degree of autonomy, and implicitly high trust, provided by the context in which one operated and personal agency at an individual level is required.

If one has a viable solution for the problem at hand but it is not sure that it will work, one should discuss with a trusted colleague on helping to find unaddressed issues. A viable solution that can be put in front of the customers in two days is better than a perfect solution in the next two months as it will allow for faster iterations with actual feedback from the customers and avoid building in the dark in hopes that we are building the right thing.

When the solution to the problem is clear and works because there is a track record of success then one has to implement that solution and move the project forward. It shou

Open Effective Status Communication

Effective Status Communication

The complex nature of work that is inherent to any environment in which the individuals performing the work are autonomous, and expected to make decisions on their own in order to move the project forward, communicating status about their work is a must have skill in order to make the whole team work effectively.

Status communication are the signals we send others about our current situation to inform them about things proceeding according to plan, new uncertainties that arose during work that require a deviation from the original plan, roadblocks at which we are stuck and accomplished milestones that indicates progress.

Communicating with others is not writing detailed logs about everything we do but sending the right signals at the right time frequency so that everyone is in the loop and knows what is happening.

In the same fashion that when we develop complex systems we make it send success signals that indicates if everything is working as expected, warning sig

Open Disagree & Commit

Disagree & Commit

In any true collaborative environment, solutions for problems never have a silver bullet kind of solution but a mix of negotiated solutions and accepted trade-offs. Therefore, even though the problem might be the same, there will never be an identical solution to the problem, even if someone on the team has already worked on that problem in the past, because the context has changed.

The solution to this is to debate with our team possible solutions for the problems we are facing, to decide whether the problem is worth the trouble, to better understand the context of the problem and why the problem exists in first place because more often than not we can solve problems by removing rather than adding new features. This debate is the time to raise any concerns one can have and to clarify as many unknowns as possible.

Everything that is proposed in the debate is not feasible to be worked on or implemented, therefore the team has to make trade-offs and scope the solution to the availab

Open Ask Clarifying Questions

Ask Clarifying Questions

All human work comes with a certain degree of uncertainty. When work is crystal clear it needs to be automated and performed by machines and it should never be our expectation to not have unknowns. The more unknowns we have, the bigger the opportunity for a more creative solution.

There is a set of questions that helps us bring clarity to problems and shade a light on unknowns and future possible problems in order to raise awareness and keep in mind those scenarios when we make plans; and the questions are “Why?”, “What?”, “Where?”, “Which?”, “When?” and “How?”. Asking that set of questions again and again is the best shot anyone has at reducing uncertainty.

To keep drilling for more answers for possible future scenarios add “And then … ?” to all the previous questions. Keep doing this to the proposed solutions in order to create a map and see which steps taken in what order are going to be the best overall solution to the problem at hand.

At times this process can be di

Open Types Of Tasks

Types Of Tasks

We have three types of energy reserves for effort, be it mental or physical, which we can use to perform our daily tasks and achieve our goals. Intense, Hard, Resistance are the names of each one of the reserves and each one have their own utility during the day. I have made this correlation from the practice of kettlebells and how physical exercise routines and practices should be organized in order to get the most out of our limited energy.

We only get so much energy in each reserve and it is not interchangeable between the reserves nor the order in which we use it can be altered, also the amount of energy we have in each reserve is not equal.

The reserves are distributed approximately like Intense (20%), Hard (30%), Resistance (50%).

The way we use our energy is in order from Intense, Hard and Resistance even if we are not performing work or training even if we are not making the best use of it. If we start by doing work that is better suited for Resistance reserves and attempt

Open Meaningful Rests

Meaningful Rests

Taking a break from the current work you are doing and distracting yourself with other activities doesn’t equate with rests. Yes you are not thinking about work per se but you aren’t recharging either. 

I once had a professor who said that when you are tired of working on a subject or topic, take a walk and change the subject but don’t stop working. Pairing this idea with the different types of tasks becomes a powerful tool that enables you to work on a few projects at a time because each project can be at a different stage and require different types of energy which can be managed accordingly. For example switching between working on a project that is in active development phase and working on a project that is in maintenance; or when I’m tired of writing software and can’t even see the editor no more I choose to watch some software conferences talks.

This concept also applies to sports, if you have had a harder practice or feel like taking a day off of practicing demanding physic

Open GOOD, now what?

GOOD, now what?

I have discovered this saying by Jocko Willink while reading Tools of Titans by Tim Ferris and it has forever changed the way I approach interruptions, unexpected requirements or emergencies.

Things that happen during software development:

• The client has delayed the launch by two weeks? We get to have time to improve the code that we wrote early in the project.
• The server had an issue during the preview demo? We get to avoid a major downtime during the public launch.
• The project requires a technology we are not that familiar with? We get to learn something new.
• A junior member asks many questions? In a year we will have another productive member in our team.
• You are running in circles figuring out a coding solution? You will get to learn new thinking tools for the next time.
• The project I am halfway through gets cancelled? I have more time to spend mentoring the team.
• You get assigned to solve some Helpdesk issues? You will know more about the customer and their

Open Logs Are Details

Logs Are Details

Activity logs are a very important piece of information produced by any entity on this planet, be it a human, a plant, an animal or machine. It is the result of actively measuring and / or observing behaviour and keeping track of it. 

This information is very useful when we have to make decisions or attempt to experiment with another set of parameters in order to compare the outputs. But we have to be aware that logging is not part of the activity, therefore we have to keep it separated from the main activity.

When we are measuring an activity like how much we can run in 5 minutes we have to slap an external device that measures the distance and the time for use because our body doesn’t have those capabilities internally because those details are not essential for the body to function.

In the software world this translates to not writing your business logic and your logging tied together but splitting your business logic so that each operation performs the least amount of releva

Open Launching Is A Bet

Launching Is A Bet

Building a new version of a product comes with a lot of anticipation about “What is going to be new?”, “What is going to be kept as it is?”, “What is going to removed?” and the most important is “Are we going to delight our customers or make their lives worse?”. These questions surface uncertainties about the future and your job is to reduce it for your team, so that they know what to build, and for your customers, so that they know they still can rely on your solution.

When building a new feature, how much of it is a something new and how much of it is an adaptation of an already existing concept or a mix of a few concepts brought together in a new fashion. The more amount of newness you build, the less amount of all kinds of details should be introduced so that your customers can grasp and understand the bare bone concept. On the flip side, the more common the feature the more bells & whistles you can add. Take for example the Hey Email Client which introduces many features not pr

Open Live In The House You Build

Live In The House You Build

The main reason that great products is because the people who build them use them. There is not a single person in the world more motivated to build high quality products than the team who is building it and will use the production version of it.

All the feedback sessions, all the user testing, all the surveys, all the other ways there are to collect feedback will not replace the hands on experience of the person who is also building it because that person also knows what is possible to build and the capabilities of the platform more than anyone else. 

There is no way to beat the team that experiences the issue their customers are experiencing and have the power to make a change because they have a deeper understanding of the entire platform. What might be proposed as a surface level solution by the customer will always have a better, more meaningful solution by the team who is also experiencing the same issue.

I am not talking about quality control, which in many pla

Open Unexpected Guests Unwelcome

Unexpected Guests Unwelcome

One of the worst features I have ever seen in project management tools is the automatic rollover of incomplete tasks to the next day because 

Having unexpected guests coming to your house is never a good experience because they are always interrupting something that you were doing that you had rather keep doing instead of taking care of them because you would have wanted to meet with them then you would have had made plans to meet.

The same applies to the Rollover feature of many project management tools that automates the scheduling of tasks to the next available slot if they weren’t completed by their original scheduled date. In theory this seems like a good idea but in practice it has sa snowballing effect that becomes unmanageable in the long run. 

The Rollover feature fails to recognize the fact that you have future plans and even if you would have the option to make tasks dependant on other tasks, so that if one task is rescheduled all other tasks are also shift

Open Untitled

A Checklist For Code Reviews

Code reviews are actually easy, you have to make sure that the code that is checked-in is code that you will be able to maintain later on, that is the only purpose for which the process exists. The only goal is to keep the codebase in good shape over long periods of time. 

The amount of changes in a code review is as many lines or as few lines as the feature requires to be whole but there should be rules to how often you ask for an intermediary review while you are writing the entire thing.

If you keep running into coding styling issues, forgotten print statements and TODO comments, please make yourself a favor a lint those things away.

Reviewing incremental code changes gives you the opportunity to learn about a project, to be part of the decisions that lead to the latest version of it and gradually understand what is going on. So, reading code reviews is as good of an exercise for the one who reads it as it is for the one who is being reviewed. Make use of Draft Co

Open Planning & Execution

Planning & Execution

To plan well you need to have a the right information at the right level. Take a step forward if you need more details and a step backwards if you need to further into the future. Do not think about how exactly you will get there but about where you want to go and what success and failure looks like.

The further in the future you plan, the less details you have and less details you can control because during execution time you will learn new things, discover new possibilities and face roadblocks that might change the plan. 

The more those little changes pile up, the more changes compound and the further you move away from the original plan. For this reason, is better to plan thinking about where you want to go and where you don’t want to go instead of having a rigid plan that fails under the stress of execution because it doesn’t integrate back feedback from the execution time. Keep in mind that even buildings built with reinforced concrete have tolerance, so should your plans.

Open Explain The Changes

Explain The Changes

Making changes to an existing system is harder than delivering a new feature because your users are already familiar with certain features, and workflows, and because you have to work with an existing thing that is interconnected with the whole system.

We are creatures of habit and once we solve a problem a certain way, and unless it is a tedious process that we put up with for lack of other options, we want to keep what works as it is because it is familiar to use.

For this reason we have to plan and make sure the amount of change that we are going to introduce is a digestible amount for our users and also if it something that is bothering them or something that we think we can do better but actually nobody wants, needs and we risk to alienate our users because of changes that were nice to haves but not needed.

We can differentiate between two types of changes, the look & feel and the functionality. The more you change of one the less you can change of the other because if y

Open Keep In Touch

Keep In Touch

This is not about the cliché of asking “How you doing?” before asking for a thing in an email, chat, message or in person. It is about being up to date with what is going on while you are heads down in your own work.

In order to produce the best result we have to use most of our brain capacity to focus on that one thing we are working towards to because we have to keep in our head all the things we have said no, all the things we have said yes to, the current problems, the current roadblocks, the next milestone, the distilling feedback we are getting among many other things that go into building something new.

While we are heads down into building mode is easy to get lose track and get consumed by it and by the time we are done building maybe something changed around us in the world that makes obsolete the thing that we have built or maybe it makes it even more useful but since we have been so ignorant to the external changes it has been impossible to react to those changes.

There

Open Beyond The Basics: Software

Beyond The Basics: Software

It is easy to learn the basics of a new framework because the entire documentation is designed around getting you started in order to get you to that moment of “See how productive you are with our framework, that’s why we are the best!”

There is also a lot of people “writing” guides about X & Y technology who are mainly rephrasing the official documentation so it easy to keep searching for the golden example instead of taking the time to actually understand the concepts explained in the official documentation to learn the fundamentals.

I have found two ways to move beyond the basics and learn the more advanced patterns of a new technology that I’m getting familiar with.

The first one is to set up a new project that includes the minimal required tech stack and try to solve an isolated problem without dealing with everything else that goes on in a production app. Solving a problem that you actually have keeps you focused so you don’t wander aimlessly through the seeming

Open Beyond The Basics: Kettlebells

Beyond The Basics: Kettlebells

Kettlebells, when following the hardstyle guidelines and rules, is the kind of sports that can fit in anyone’ schedule and the results far outweigh the time invested in the daily practice. It has a very small, although rock solid, foundation of swings, cleans, presses, front squats and snatches, that once you learn it stays the same forever; your technique will improve over time but the exercises will stay the same.

At first, it is hard to imagine how is it possible to get results with only five exercises and keep progressing over time because we are so used to all the ads selling the secret technique to grow X or Y muscle, how to get results that take years but in 5 minutes and so on that many of us keep chasing in the beginning that we forget that we have to move past the basic movements and exercises and get into the structure a practice and then the planning of the practices in order to get the results we want.

Open Is Selling Water Your Business?

Is Selling Water Your Business?

One of the most annoying practices in bars and restaurants is paying a premium for still water. It is a too common practice that makes no sense even if you are trying to find a formula for maximizing the value of the menu.

Water is ordered because one is thirsty not because it is will replace another beverage choice from the menu that has a higher markup and will generate more profit. So it plays a complementary role because is “this drink and water” and never “just water”. In the rare case someone is that cheap to not have a drink and orders only water will most surely also order the most cheap items from the menu which means it is far from being the ideal customer anyway.

This is one those practices that the customers just have to tolerate because this is how business is done and have to suck it up but it actually hurts the whole experience. It takes so much more effort to make the whole experience so much better so that your customers move past the high price paid

Open Comeback Notes

Comeback Notes

The majority of notes are written to be reviewed later on, to highlight some important concepts that we are currently learning about and annotated to differentiate between the different actions that we might want to take like lists for outlines, todos for action required, an idea we had while learning new information, highlight important information for context and so on.

We take this process very seriously for external information but it seems that more often than not we ignore the information we produce, maybe because we don’t think it is important or we are over reliant on our memory. Both cases seem to be thought of crazy if we were to behave the same when listening to new information or doing research.

It is even crazier when we think about this in our day to day jobs at which we get interrupted, way more than we would like to admit, and the amount of time it takes to come back. Some interruptions are short and we can work back from memory to where we were before but other inter

Open Three Attempts Or More

Three Attempts Or More

Looking back at the huge amounts of code I have written for my ever new “Million Dollar Idea™️” , I came to the realization that when I’m building a new app with unfamiliar technologies, or wrestle with a new idea, I need at least three attempts to build an app that somewhat works in a reasonable amount of time.

I have gone through this while building the apps powerbell and DressUp Club. I learnt React Native while building powerbell and even though I was fairly productive using react before, I had trouble organizing the app structure and even though I shipped the app, it would require an entire rewrite to add almost anything new to it. For DressUp Club, I went the other way around and made it more complex that it was required which turned app into bloatware that is slow and took a lot of time to build but can be extended in any shape of form.

After going through step 1 and step 2 with React Native I learnt that unless I am b

Open Show, Ask, Adjust

Show, Ask, Adjust

I have yet to work on task, let a lone a project, that I could make it to be ready for production from requirements alone because no matter how many wireframes you draw or diagrams you make, nothing beats using the product hands-on while you get immersed in the experience from start to end.

The software development world is a much more creative world than many recognize or attempt to make into factory production, build from blueprint kind of work. There are so many new possibilities that open up when you spend a big chunk of time working and thinking about the problems at hand that couldn’t be thought of before hand. This is the curse of the software developer who knows the most about a domain right before completing the project.

Initial ideas and proposal are too abstract and lack the level of details required to make specific requirements that can be executed and carry out to perfection without any kind of intervention along the way. We all would be better off by defining the ou

Open Not Now, But Then

Not Now, But Then

Instant Messaging has become the de facto channel for communication nowadays, bet it for business or in our personal lives. It is great tool because it is instant, write a text, press send and the receiver is notified almost immediately. This experience makes us expect to have a response back immediately.

We should not expect an message to be treated as an alert to which the receiver has to drop E-V-E-R-Y-T-H-I-N-G that they are doing and give us an answer. But, as a signal to let the other person of group of people about update or inquiry that we have and need some feedback from them in a timely manner but not now.

By treating every message as an alert to which we have to react no matter what we are currently doing, we discount the importance of our own work. So, messaging becomes more important than our assignments, projects and goals because no matter what we redirect our full attention to any incoming message as soon as that notification bubble pop ups on the screen.

As muc

Open Beware Of Writing New Software

Beware Of Writing New Software

After writing software for 9 years, I have seen countless people putting a lot of effort on activities that were not important to their career progression, nor to the team effort nor to the business itself but sound very good and interesting in conversations with other software developers as if the statement “whoa, you guys are doing that!?” pays the bills.

Most of the time, these time wasters fall under the following categories: a big architectural drawing that takes forever and it will take forever times two to implement, a fresh rewrite of the project with very similar technologies or rewriting the entire framework your project is based on just to reach a similar output to what they previously had.

I consider those activities to be time wasters because it does not add any single unit of value to the end activity of the business. For sure there are some business in which an entire department is dependent on activities like that but that are a few exceptions and in t

Open Releasing Is Part Of The Process

Releasing Is Part Of The Process

I have seen many roadmaps end with big words “RELEASE”. Many teams, colleagues and even myself, give it all to make it to that last final step as if all the problems would go away once the software is released. Whatever happens afterwards, happens and is no longer our problem is a naive and unrealistic approach.

But it turns out it is our problem and it is only made worse by this myopic focus on the goal to release, wrongly believed to be the last step. We cut some corners, stick things together with duct tape and hide them behind something pretty, write a bug as an “exception that should not happen normally” and move on without further investigation and many other things that helps us move faster towards our end goal, the “RELEASE”.

The result of hurrying only makes matters worse when, at the end, we realize we are not, in fact, at the end, but we are at a step in the whole process and now we have to live with the mess we have made and, more often than not, redo th

Open After A Crisis, Move On

After A Crisis, Move On

Periodical crises are inevitable situations when working with system. Either because the system degrades over time, we make changes to the system that have unintended consequences or the outside rules and laws change forcing us to adapt our system to be in compliance.

During a crisis period we come up with all kind of ideas and solutions to solve our problems and other ones to prevent it from happening again or at least mitigate as much as possible the intensity and duration of the crisis. 

Having invested much time and effort turning these ideas into a reality we might end up becoming attached to the solution because of how clever we feel having had or found these solutions in first place. This might lead to wanting to find new problems to apply our solution losing sight that we only came up with the solutions as a reaction to a problem which, more often than not, is a specific problem to the way our software works or our business is structured rather than being common prob

Open Distill Conclusions Into Actions Items

Distill Conclusions Into Action Items

We spend so much time on a day to day basis on brainstorming new ideas, getting a buy-in from someone, clarifying misunderstandings, mentoring a more inexperienced team member among many other topics we discuss with our team, our bosses or external vendors. Now, everybody is happy because we can continue to work.

But, this effort goes to waste more times than we would like to admin because nobody takes action because they thought somebody else would take action. This happens because in the moment we all have all the context of the conversation and the commitment is still fresh in our memory but as soon as we get back to the things we were doing the things that were so clear a moment ago start to get blurry and entangled with everything that we have going on.

Action items, a one phrase that describes a single action we have to take, solve this problem by creating a list that can be referenced later on to keep ourselves and others accountable. They also serve as

Open Pat Attention In The Moment

Pay Attention In The Moment

The best way to write good quality software is to pay attention in the moment because that’s when all the ideas are circling in your head and you have all the context needed to be make good decisions.

When you come back to a piece of code you have to re read everything to gain context and the larger the project the more times it takes to get to know that small details that matter.

For this reason you should never stop working on the clock but in logical increments that you can discard once you are done in order to make mental space for the next thing.

Open Assume But Veerify

Assume But Verify

One of the mistakes that it took me the longest to rectify was to always verify my if the changes I made to a piece of work actually worked. 

I always thought that not knowing for sure something works was a sign of weakness without realizing that delivering faulty work has far worse effect on one’s reputation. And as bad as it is to delivering faulty work, people will lose will no longer rely on your word.

They will lose credibility on you because they will asume you have dropped the ball and they must verify your work for you which will also make them resent you. This is not to say that nobody should review somebody else’s work but there is a difference between polishing and actually having to make sure the basics works.

Other than thinking it was a weakness, I kept doing this mistakes because eventually I would get a one thing right, deploy it and fix a problem and would get a few compliments like “you are so smart”. Now looking back I realize they weren’t remotely worth it a

Open Say No, Meet Expectations

Say No, Meet Expectations

At work, the demand for our time will always surpass the amount of time we have available. A colleague with an idea, a prospect wants to meet for lunch, a client has an internal emergency, a boss asking questions, your monitoring system alerting of a server going over capacity, a partner notifying you of changes to an already agreed plan, among many other common things that happen daily, are all requests for our time an interruption of the what we are focusing on.

The actual problem doesn’t come from the amount of requests because eventually, on a long enough timeline, we can work through every single request. But, actually the problem comes from the need to solve requests in a timely manner.

In order to do so, at the quality others expect from us, we have to communicate with them that we are or aren’t able to handle their requests in a timely manner that would satisfy their needs. Providing an alternative or redirecting to someone who can help is always welcomed. Having a

Open Smart Enough, Yes. But Daring Enough?

Smart Enough, Yes. But Daring Enough?

Recently I have read Paul Graham’s essay “Beating The Averages” in which he talks about how he and his team were able to outperform the competition by making a few key decision about technology. Decisions like going web first, writing their software in the Lisp programming language or choosing Linux OS to run on their servers.

This got me thinking that it can’t be that they made those decisions just because they smart because there is plenty of smart people all over the place working on software. It also can’t be that they were the most pragmatic ones because choosing such a different technological stack back then meant that you had to build a lot of supporting features yourself; features that others got for free just because they choose another tech stack.

They did not made the decision to write their codebase using Lisp just to recreate the Java stack but to be able to do things that Java did not enabled them to do. Nor choosing Linux over Windows Server, nor

Open The Pragmatic Avoid The Mediocre

The Pragmatic Avoid The Mediocre

One of the big time wasters in software programming is having to deal with mediocre implementations that, although well written and documented, are poorly thought through resulting in bad abstractions and code smells all over the place.

Think of the parts of your codebase that you feel like you are stuck with them. Neither too bad to need a refactor nor good enough to not give you any headaches. The kind of abstractions that helps you in some ways but leaks enough to force you to make a few bad decisions. This makes mediocre code spoil what otherwise would have had the potential to be great code.

Two types of behavior lead to this mediocre result. Thinking too far ahead and writing too many abstractions. Creating a whole ORM system, database query builder, deploying a micro services architecture, creating a plugin system among many are huge abstractions that are too big and too complicated to build at the beginning when you don’t even know if you are on the right pa

Open Your Password (Or Passcode)

Your Password (Or Passcode)

That is the dilemma that got me into a 2 hours standoff with my bank because I couldn’t log in anymore. It all started from a misunderstanding of what information should I fill in the password input.

When I first created my account I used the “Continue with Apple” option in order to avoid using a password. But any bank apps I have used so far they also require you to create a password which you can later protect behind a FingerPrint of FaceID check. A very common way of doing authentication nowadays.

Because the process of creating your account involves a lot more than your email, a password and some built-in feature for authenticating yourself. It also involves making use you are writing your address well, you provide the correct photos for the “Know Your Customer” process, that you give details about the source of the money, that you are choosing the right plan and many other steps that banks require you to fill in before finally submitting your account for approval.

Open Bug Fixing Is Not A Chore

Bug Fixing Is Not A Chore

Software bugs are an inevitable part of one’s job when writing code. Overconfidence, negligence, or rushing to meet a deadline or poor planning, or just pushing it down the road are among the main causes of bugs. Fixing them is mostly seen as a chore rather than task someone wants to actively do.

More often than not, bug fixing is associated with those chores that nobody wants to do but they have to do because of company policy. One way companies attempt to tackle this chore is to make everyone equally miserable by rotating the developers attending to HelpDesk. The chances to fix a bug that you introduced are narrow and the chances that somebody else will fix the bug rather than just apply a quick-fix are even narrower.

Another popular approach is to give Friday, either the whole day or only its afternoon, time for developers to fix bugs. You have to very naive to expect any kind of positive results from this approach. Fridays are the least productive time of the work week

Open The Leaps You Make As A Beginner

The Leaps You Make As A Beginner

Learning new things is always a daunting endeavour. In the beginning you don’t even know what is good advice and what isn’t. Which resources to trust and which ones to run from. The lack of mental models makes every lesson that much harder to learn. Overall, it feels clunky.

When I started this blog I got 2 views per post, now I get 10. It’s a five times multiplier from when I started. I have to get the to 50 views per post to have the same multiplier and after that I have to get to 250. Meanwhile, the same amount of views seems to become less and less relevant stats. What was a multiplier at 10 views, it will become an addition in the road to 50 views and will go unnoticeable on the road to 250.

Before even getting to these tangible two views, there is theory that I had to learn. Basics things like the structure of a blog post or writing like you speak or more advanced ones like “Who am I writing for?”.

Once you get the basics right and you are used to the mecha

Open Handovers, More Than A Procedure For Vacations

Handovers, More Than A Procedure For Vacations

Changes within an organization are inevitable. People join and leave, take short or a long break, move up or down the ranks. All these movements change the way the individuals, teams and the organization as a whole function. It alters the internal workflow and the way information flows.

This presents two challenges for the impacted teams. First, you have a gap in knowledge that can, and should, be covered by the internal documentation in the best case scenario and at worst can be gained more slowly by doing the work hands on.

Second, and more critical, is the gap in the way work happens and information flows. As these happen to evolve informally over time, there is no documentation and in many cases no procedures because, let’s be honest, the sheer amount of information to cover everything you do would make that documentation unusable.

Handovers are a great way to deal with these two situations. It closes the knowledge gaps by making people review a

Open You Always Work For Yourself

You Always Work For Yourself

“You can only make it if you work for yourself” seems to be a popular way of thinking nowadays. Fuelled by internet influencers that sell access to groups, courses and coaching, this trend is growing bigger and bigger.

It’s quite interesting how the same people who are selling the message of people being full of potential are also the only who can help unlock it. As if someone who becomes very good at what they do is also so clueless to how others are taking advantage of them.

If people are so clueless, how did they manage to get the job? How did they manage to learn the knowledge they have, sale their skills, negotiate a salary, market a positive image, keep their promises, deliver their commitments, manage their relations with peers and managers, retrospect and take feedback.

All these skills are required when “working for yourself”, a.k.a. being an entrepreneur. Having knowledge that can be monetized, making sales, negotiating with clients, product and services ma

Open Ego-Lifting Is Good Sometimes

Ego-Lifting Is Good Sometimes

There are always a handful of people in the gym who are constantly competing on how much each weight they can lift on a single lift. Always impressing the new comers with their abilities to perform the trick.

A say it’s a trick because it’s only impressive until the new comers transition to beginners and start realizing that these people are stuck in their performance act. Always looking to get the next impression, barely improving the amount of weight they can lift.

The problem the new comers face until transitioning to beginners is that they make the false assumption that to progress you have to go very hard at every moment and even then you barely move the needle. But the needle hardly moves because the whole premise is wrong.

What actually helps the progression and evolution is what is considered the boring staff at the beginning. Learning about things like maintaining good form while doing the exercises, learning what is the right exercises sequence, how to cho

Open Retrospections Over Evaluations

Retrospections Over Evaluation

In any company at any size there is, or should be, a time for review. Even when there is only one employee, you. And I would suggest that this is a good practice even at a personal level.

More of often than not, reviewing the current state of affairs is a process that looks like a grading a paper in school. Someone takes the time to look at the current situation and grades it with either “Exceeded expectations”, “Met expectations”, “Failed to meet expectations”. And on they go to the next thing on their todo list.

While this method works in school, where the assignments are based on the same learning materials for everyone and the only variable is how much effort an individual puts into learning, it fails big time for any evaluating any kind of work that any degree of uncertainty. And the more uncertain the work, the more this evaluation based review fails because it only evaluates the end result. 

With increasing uncertainty in the work requirements you have to sp

Open Lets Check If It Works

Lets Check If It Works

The moment your software has its first user is the moment you have to reduce breaking changes to the minimum and keep the system up for as long as possible.

There are a few strategies to deal with this like, working in small increments, versioning the system for gradual adoption and deprecation, creating various intermediate environments between development and production, testing the quality of the code, testing the final integration, monitoring the servers capacity, etc. These are among the most common practices that are implemented in all software projects indifferent of the team size.

The only problem with all these strategies is that they deal with the code after it was deployed and none of them deal with improving and ensuring the code quality while writing the code which is where the most leverage is.

To have the ability to reproduce as close as possible all the context in which your piece of software will be part of is an underrated method by which you can ensure a

Open The Next Satisfactory Step

The Next Satisfactory Step

Debugging your own code is hard. It challenges your mental models that led to the solution in the first place. You have to question every piece of code, even that one that makes you feel like you are very smart.

Debugging other peoples code is even harder because you don’t have the mental models that led to that conclusion. You are missing all the assumptions that the original author had when they wrote piece of code. So everything is under question. Paradoxically, it is also easier because you can look at it with fresh eyes. It can take you a few moments to fix or more time than to the original author.

In the beginning, when what is failing is unclear, you should make big swings until you stuck gold. The more satisfactory steps you take towards the solution the more precise the changes you make need to be in order to keep narrowing down the problem until the root cause is found. From commenting out huge parts of the code or big moving parts one at a time to changing the

Open Guidance Towards Getting Results

Guidance Towards Getting Results

Simple activities are too often overlooked. They are as beneficial as they are powerful. You can hit the ground running and keep making progress in small, digestible steps.

And yet beginners dismiss them in favor of the more complicated ones.

The way to get results, with either the simple or the complicated activity, is by learning and practicing what comes after the introduction and the basics. The underlying principles, techniques, methods and protocols.

Practicing KettleBells is one of these activities that you learn everything you need to learn in a few hours. Then you can dedicate your time to getting results rather than wasting time on figuring out the intricacies of each exercise machine. There are no secrets or extensive guides. And the learnings are transferable to other sports like barbell lifting.

“That’s it?” is a common question to dismiss the simple. When a beginner sees what they will be doing they fail to see what the next stages are. The proce

Open Subjective Codebase Health Parameters

Subjective Codebase Health Parameters

Debt is a property of any system. It allows the system to keep functioning in times of crisis by borrowing resources from the future to compensate for today’s shortcomings.

The more debt there is in the system, the harder it is to work with it. It takes effort to keep it under control. The more you try to reduce it the harder it becomes to further reduce it. Attempt to maintain it within a healthy range but don’t bother optimizing a property that follows an asymptotic path.

Plenty has been written about how to measure technical debt by assigning a value on a scale to anything that can be attributed such thing. There are one too many strategies suggested by consultants on how to deal with the most generic of the problems as if those are the ones that are going to make or break your codebase.

Both measurements and strategies are focused on the code. The easiest thing to blame. It never argues back. The coders are almost always left out of the equation yet they

Open Coding Out Of Fear Rather Than Necessity

Coding Out Of Fear Rather Than Necessity.

The software world currently suffers from an attitude that too much cannot be bad. Every aspect of a project has so much flexibility built in as if a decision will be made at any moment to swap out the entire thing.

As if all the rationality that went into thinking the project the first time is thrown out the window once the project is released.

This same attitude was prevalent in the 80’s when purchasing computers and servers. “Nobody Gets Fired For Buying IBM”.

Translated to the software world it looks like this:

“Nobody gets fired for yet another level of abstraction”

“Nobody gets fired for yet another level of indirection”

“Nobody gets fired for yet another micro-service deployment”

“Nobody gets fired for yet another planning session”

“Nobody gets fired for yet another external service”

“Nobody gets fired for yet another documentation page”

“Nobody gets fired for yet another documentation page”

…

“Nobody gets fired for play

Open Gambling Warning For Generative AI

Gambling Warning For Generative AI

Generative AI and gambling have random dopamine hits in common, the most powerful addictive hook there is.

Some times the simplest strategies is the one which wins, other times is the most complicated one. What makes it more interesting is that the same strategy used twice might not have the same result. You are always “one more round” away from the win.

This is how the addiction begins. What if I should have generated 10 more images. What if one more code refactoring would have finished the feature implementation? What if the next article rewrite would have been popular?

Due to the fact that the results are predictable, the sunk cost fallacy kicks in even harder. Since there is no specific parameter that you can tweak and see predictable, reproducible changes if you move it along a scale, you don’t even know what is wrong. Is it the prompts? Is it the seed? Is it how the problem is formulated? Is it the right solution but I’m unable to see?

People use gener

Open The Joy Of Working Alone

The Joy Of Working Alone

The speed at which a software feature is delivered can be measured by the amount of work an individual can do cutting through the vertical of the stack.

The details and the foundation compromise each other. When people work on their own corner, a lot of extra communication is required to accomplish a task. Negotiating back and forth every little detail takes a lot of time ends up making everyone equally miserable and agree on anything just to move on.

“If you have had told me that you needed it that way I could have organized myself better”.

“If you have had told me that this meant so much work I could have easily worked around it.”

If I am responsible for the foundation only then I have to make sure that other people that will look at the foundation don’t think I’m stupid.

If I am responsible for the details only then I have to make sure that other people that will look at the detail

Open The Spoils Of Reputation

The Spoils Of Reputation

Earning a reputation is very easy, just do things that makes people talk about you. The hard part is having a positive one. Even harder yet is to maintain it.

It’s hard to earn a positive reputation, delivering work that’s at least as good as the premium brands without the ability to charge that much. Depending on the release cycle of the product or the delivery time of the service it can go from a few months to a few years until the positive reputation is built. At the beginning, it is hard to even find the critical mass required to have the opportunity to even start building a reputation.

What makes keeping a positive reputation harder than earning is that eventually, on a long period of time, there will be conflicting moments where doing the right thing will be so expensive that taking an alternative route and damaging the reputation will look like the best option in the moment.

Not being aware of this period of time and thus not planning how to properly mange the env

Open Manageable Code Over Clean Code

Manageable Code Over Clean Code

The notion of clean code is confusing. It enforces a set of rules that sound very good on paper but might not be beneficial at all for the project or the team.

It suffers from the same logical fallacy of picking a similar tech-stack as one of BigTech™ does or implementing your own abstract framework similar to existing open source solutions just to get to a similar end result. It also provides the perfect scapegoat for when the inevitable fuck-up happens.

The “What if one day … ?” is not worth the trouble and effort in the software world. The only time a piece of code requires a change is when the scope of what it has to do also changes. It’s a bliss to not have to think about any inherent system degradation that might happen over time.

This is not true in the engineering world where this thinking of starting any project, big or small, only within the standards is the de facto way of doings things. In all fairness, it makes sense to do it this way when you take in

Open In The Spirit Of The License

In The Spirit Of The License

In recent years a few major open source project have changed their original permissive license to a business oriented one. They did this after having had plenty of success and contributions specifically because they had that permissive licensing to begin with.

The most recent one is WordPress changing their trademarks only to force a competitor, of which they owned a share in the past, to pay a ransom for using their open source CMS. Other examples include MongoDB, ElasticSearch and Redis (more recently).

The story goes likes this: A company builds an open source project and gives it to the community. They build a service around the open source project. It picks-up interests and other people start contributing. The interest grows and other companies start providing competing services for these technologies. The original company gets mad and changes the license from a permissive one to a strict one forcing other companies to cease offering competing services.

At least

Open The Arrogance Of Software

The Arrogance Of Software

All the successful people that made it in software seem to think that the world needs changing, that they have the ability and the means to do it.

They fall for the same problem they had in the software world. A team of people comes up with big, audacious ideas that sounds amazing on paper that gets delivered over budget and way past the deadline without meeting half the initial expectations. Any attempt to undo it might be harder than building it.

Failing to realize that the software world is infinitely easier to change than the hardware world because software changes in the background while hardware changes in the foreground. The size of software change has no impact on the ease of deployment.

A bug fix, a performance improvement, a complete refactor are all a deployment command away. Now try fixing a few potholes on a highway and you will see you much disruption there is. Try adding a lane to a highway. Try closing a two six months old bridge because it has grown its

Open Markup & Interactions

Markup & Interactions

All apps and websites are a way to display some information in an organized way. Some do it more handsomely, others focus more on function.

Too many software developers put to much emphasis on the technology stack because they want the job opportunities that come with those technologies failing to realize that the technology stack is there to help you solve problems not to find problems to solve.

There is an exception tho. When there is a leap forward in technology that opens up new opportunities that were thought to be too hard to handle before. Moments like when people first started switching from Java to Ruby on Rails or from jQuery to React meant that all of a sudden you were orders of magnitude faster during the development process if you knew how to solve certain problems and had the all the other skills required to solve certain problems. It was never the other way around of learning how to use the tools and then looking for problems to solve with them. It might have be

Open Am I Allowed To Do This?

Am I Allowed To Do This?

All creative endeavors are filled with people who have a disdain for rules and a strong conviction that their way of doings things is the best way.

Being a beginner in such an environment is harder that one might expect. There are no hard rules to follow to get results and your mentor, if you are lucky to get one, will have their own way of doing things and dealing with problems. Having neither a wrong nor a right answer makes the whole endeavor highly subjective and therefore highly criticizable.

What might be a good decision for someone will the be the worst for another one. There are no single sources of truth because the whole field is too big to learn for a single person so everyone is talking from their own personal experiences of what they managed to discover so far. "It depends" is a highly frustrating answer when you are trying to learn something new and have been banging your head against a wall for a while.

There is no way around the subjective side. Our own i

Open The Cake Goes First, The Cherry Tops It

The Cake Goes First, The Cherry Tops It

An eloquent one liner in software. A short sentence that conveys more meaning than a book. The pure display of strength when snatching a 32kg KettleBell for reps.

As a beginners is all that you can see. A glimpse of those peak performance moments. But what you can see in public is not what makes it possible. Attempting to perform the highlight without going through all the preparation required that enables that one moment in time is a recipe for failure. Worst even, you will reach the conclusion that you are not suited for it and give up on even trying to get better.

Imagine trying to learn to walk by looking at Usain Bolt running a World Record 100m dash, attempt it, fail at it, and concluding you are not suited for walking.

It's normal to be amazed by the highlights but these aren't the starting point. For the cherry to be at the top there needs to be a cake first and for the cherry to be highlight the cake needs to be perfect. Using the top performers h

Open A Test, A Competition, A Feat, An Exploration, Not A Challenge

A Test, A Competition, A Feat, An Exploration, Not A Challenge

"I challenge myself everyday" can mean two widely different things. Either you put yourself in unplanned situations and try to overcome them or you carefully plan for a little discomfort everyday in order to keep growing. It depends by who is listening.

The word "challenge" is used interchangeably and more often than not it replaces words that would convey a more specific meaning. What everyone understands is that a challenge is an event that gets you of your comfort zone. An event that forces you to make an temporary adaption in order to get over it. Since the comfort zone is different for everybody and everybody has a different approach on getting out of it, a challenge means a different thing for everyone and is perceived in a different way by everyone.

This gap leads to a misunderstanding of what each one of us is capable doing and it skews how we assess the capabilities of others. Somebody who plans carefully sees a challenge as a

Open Eloquent Codebases

Eloquent Codebases

From time to time you come across such a good implementation that it makes you stop and go explore it in depth.

You wander around for a few minutes, marvel at how well designed that code is, how easy would it be to refactor things if it were the case, how much thought went into keeping it within scope; then you realize that you still have work to do and go back to it while concluding that you would never be able to do such great work.

And you would be right because neither the author themselves think that they did great work. All they can see are the bugs that keep pilling up, the missing nice-to-haves, the trade-offs made in order to enable such eloquence. The same things that we all see in the code we write ourselves.

Most of the time we find these great snippets of code are within the bounds of language libraries, software frameworks or developer tools. More often than not, we fail to realize that the main purpose of these artefacts is to make the life of other developers

Open It's Time To Work

It's Time To Work

Delegation is often used as a way to give other people the tasks someone don't want to deal. In all these cases they are tasks and duties that require the context and decision making power of the person delegating the tasks. Worse even, in most cases the person who receives the tasks doesn't have a set of rules to makes decisions.

"Read my emails and create the appointments in my calendar" instead of "You manage my schedule and here are the rules and I will abide by your decisions".

"Write the code X and Y functionality" instead of "Here what the component should do and these are the guardrails you have to say in-between".

This approach to delegation fails on both sides, the delegator and the delegatee because neither can develop the full picture. The delegator is missing on the details that might affect the bigger picture and the delegatee doesn't have know the bigger picture in order know what decisions to make about the details. The delegatee might do the best job for the ta

Open When Maintenance Hits

When Maitenance Hits

Maintenance is one of the most overlooked aspects of a system. The software developer underestimates how many bugs and unhandled edge cases there will be. The client overstates the simplicity of the solution they need.

Both parties are at the opposite end of the system thinking spectrum. The software developer wants to systemize everything and the client wants to just solve the problem at hand. At the same time, both parties are constrained by the budget but they want different outcomes. As a software developer you want to make money now - "I will do to for cheap and make money on maintenance". As a client you want to solve your problem now - "I want to pay once and make my problem go away".

Yet maintenance is the hardest aspect to handle because it happens in production. A hostile environment filled with debris from unhandled edge cases over time. Life will never be easier than in development. Got something wrong? Just restart the entire thing. Deleted some users by accide

Open For Sure I'm Too Stupid

For Sure I'm Too Stupid

Recently EA has open sourced the codebase of the game saga Command & Conquer. Looking through it made me raise my eyebrows a few times.

First of all, it is insanely pragmatic and easy to read. For the time I looked around I could not find any "what ifs" implementations. No useless abstraction, no strategy mechanism if its purpose was not clear in the moment, no useless factories just to have them. The matchmaking class should be studied as the way to implement software for your clearly defined problem. Those who wrote the code clearly understood encapsulation and execute properly on that. The whole thing made sense then and makes sense now.

Second, you can see the passage of time and the adoption of new conventions to write code by looking at the comments. Some

Open AI, The Senior's Autcomplete

AI, The Senior's Autocomplete

When you start learning how to code you usually do it using a basic text editor where you type in the tutorial and run the code. The first time you start using an IDE, a feeling of insecurity overwhelms you; the thing already knows how to do all you know that you know to do.

The more you keep learning and progressing towards mastery, the more you realize that for every new lesson you learn there is an existing solution to that problem which already has all the bells and whistles needed. To make your self-esteem suffer even more, these solutions are open source and in almost all the cases is also free to use for commercial purposes. It's just too easy to conclude that "What the fuck am I even trying to do here?". And that's where you are wrong.

Plenty of so called senior software developers are in shambles right now because of AI. All they know how to do, the AI can do for them - and even worse, the AI can do it for anybody who asks. In the same way that autocomplete re

Open Shortcuts, Not Subpar Work

Shortcuts, Not Subpar Work

One of the few rules that will determine the success of a project is how fast are you iterating through experiments. Not incremental steps, not sprints points, not logged hours, not moving, but iterating.

Iteration as in a complete feature that solves a problem at its most basic level without all the bells and whistles, without all the decorations, heck even including the rough edges. Just the bare minimum that will allow you to sneak peek into the future and see which path forward to take. That's where and when you see if you are making a new painkiller or a vitamin.

What is often seen as taking shortcuts by implementing a very straightforward solution to the problem ends up being more than enough to validate the idea and because the implementation is simple in its initial phase you can either easily rollback or keep building upon it based on the learnings of actually putting the feature in front of your users. Or even better, due to the lack of sunk cost fallacy, you ca

Open Por Amor Al Arte

Por Amor Al Arte

The work we have to do is plenty. The day never seems to be long enough, the week goes by too fast, the quarter's end is always looming and by the time you realize it's the end of the year.

Adding more systems to organize the work seems to have the effect of more work being added rather than completed. Increasing the work capacity through people not machines always results in more work to be done because guess what, people have ideas and give you feedback which is amazing but it also translates into more opportunities which result into more things to do. Prioritizing has also fallen short of its original purpose to determine the one single thing that needs to be completed next and morphed into an unmanageable pile of tasks that get re-sorted every so often.

Some of this work gets done because tokens are needed for everyday life, some because it gives status points within the social hierarchy is important, some because of virtue signalling, some because the result messes with a comp

Open The 30 Minutes KettleBells Practice

The 30 Minutes KettleBells Practice

To keep a habit over long periods of time it must not feel neither like a chore that you just go through the motions, nor as an obstacle to everyday life that you must do or else lose all progress. The carrot and the stick doesn't work even for duolingo.

A 30 minutes practice of KettleBells does just that. Short enough so that you can vigorously perform the activity. Malleable enough so that you always keep a few days when needed and not lose progress. Although not strict on the schedule, the practice must follow a rigid structure in order to be effective and reap all its benefits.

The outline of a 30 minutes KettleBells practice follows the three types of energy we have: Explosive, Strength and Endurance. A single practice can be divided into three 10 minutes slots following the Explosive -> Strength -> Endurance sequence; or a two

Open Journaling for Retrospection: Not a "Feel-Good" Activity

Journaling for Retrospection: Not a "Feel-Good" Activity

In the internet culture that I grew up in, journaling and keeping a dairy was generally seen as a girly activity that we boys, for the most part, made fun of.

After reading Marcus Aurelius' Meditations I had to change my opinion. If they guy ruling over the Roman Empire at its peak era kept such a great journal, then for sure it had to be of more value and substance than merely recording one eating oatmeals on a given day.

All the information I could find on how to start journaling and what to journal was about the same surface level, feel good kind of things like "I felt inspired today". While it might make one feel good in the moment, it has no value for retrospection which is actually the whole purpose of the journal. Rather than such vague statements, a journal should be filled with details about specific activities one does in a given day as they happen. Treating it as a ritual, at the end of they day or whenever, gives it too much impor