"How" vs. "What"

As I continue to grow as a software developer, I've come to realize that my interests lie more in the way we create solutions (How) rather than the solutions themselves (What).

At the beginning of my career, I was captivated by the incredible things that technology allows us to do - from launching rockets into space to developing video games and robotics. However, I've come to understand that the true value lies in how we approach the development process. It's not just about the impressive products we can create but about the method by which we bring those ideas to life.

In our daily work as developers, the most important aspect is how we tackle challenges and bring our visions to fruition. This focus on process rather than the product has become increasingly clear to me over time.

Currently, the following aspects of my work as a software developer are most important to me:

• The way we work as a team and support one another's growth as developers.
• Our ability to communicate and collaborate effectively.
• The value we create for our customers through our solutions.
• Our dedication to continually innovating and improving our processes, relationships, and learning. 

These are the elements that, in my opinion, truly drive success in our field.

For me, the journey is just as important as the destination. It's the people and experiences I encounter along the way that truly matter.

It may seem counterintuitive, but in my experience, I've found that by focusing on the "how" of things - the process and the people involved - I'm able to be a part of creating strong, effective teams that produce great results and products.

So to evaluate new opportunities, I follow these steps:

• First, I evaluate whether the opportunity aligns with my personal mission and ethical values (See more at my Personal Mission).
• Second, evaluate "How" they work:
• Whether the focus is on resources and assets or people and skills.
• Whether the company's values are reflected in their hiring practices.
• How the company approaches uncertainty and risk in the product development process.
• Whether the focus is on outputs or outcomes.
• Whether the company is open to validation and learning, or if they seem to have all the answers already.
• Whether there is a genuine culture of collaboration within the company.

In summary, are they optimized for continuous change or are they optimized for an industrial age that is no longer relevant? ;) 

I'm trying to determine if the company's culture is 'green' or 'teal' in nature (see the following infographic), or if at least the company is open to evolving towards those models.

For me, "How" we work directly affects my day-to-day satisfaction, my motivation, and my overall performance.

Related stuff:

• My personal mission
• cultura y xp nos funciona (Spanish)
• http://www.reinventingorganizations.com/ the book, and some videos (videos )
• Apprenticeship Patterns Guidance for the Aspiring Software Craftsman
• The Long Road Sandro Mancuso
• How great leaders inspire action

(Text updated 2022-12-20)

Interesting talks/podcasts (December 2017 Part I)

These are some interesting talks/podcast that I've seen during December:

• Attitude Determines Altitude- Engineering Yourself  Randy Shoup
• Decentralized Objects with Martin Kleppman Software Engineering Daily podcast
• How to build a company where the best ideas win Ray Dalio
• The poetry of programming Linda Liukas TEDxCERN
• Cultivating Collaboration: Don't Be So Defensive! Jim Tamm. Radical Collaboration (via @msanjuan)

"It depends" / Jocelyn Goldfein model for software classification

Continuing with the idea of knowing the context of our software as the first step to making better decisions (see it depends blogpost). I will explain in this post a software classification that I found very useful.

This software classification was created/defined by Jocelyn Goldfein in the article http://firstround.com/review/the-right-way-to-ship-software/ and explained at The "right" way to ship software Jocelyn Goldfein - hack.summit 2016.

The presentation's core message is that there is no single "right" way to ship software, as every release process optimizes for different goals and involves trade-offs. The optimal approach is situational, determined by a company's technology stack/deployment model and business model/mission, requiring a flexible and adaptable mindset rather than adherence to a "religious" belief about one methodology.

The model classifies an application in two axes:

• Horizontal axis: Technology stack and deployment model. From very costly to deploy (on-premise, operating systems, embedded software, etc.) to easy to deploy (web application in a cloud PaaS).

• Vertical axis: Business model and customer type. From costly enterprise-critical software to free consumer apps.

This classification helps define the cost of making a mistake, the optimal release process, how to gather feedback, and more.

For instance:

• Web/cloud deployment allows rapid iteration and testing. Bugs are easier to fix, enabling a more risk-seeking approach ("move fast and break things").
• On-prem or device deployments are slower and riskier. Bugs are expensive to fix and may severely disrupt customer operations, thus requiring more conservative, predictable processes.
• Enterprise-grade software often requires predictability over speed. Customers need to plan around releases.
• Consumer-facing software benefits from great UX and fast experimentation cycles. New features can be introduced continuously without prior scheduling.

Beta programs are an especially effective tool across all quadrants: they allow for frequent shipping and direct feedback from users who are willing to tolerate early-stage issues in exchange for access and influence.

Changing release processes is hard, because it usually demands culture change. Engineers tend to become attached to the processes that worked for them in the past, even if the current context requires a different approach. This can lead to internal conflict, especially when companies pivot from one quadrant (e.g., web) to another (e.g., mobile). To navigate this, teams should align on shared values and mission. Processes are negotiable; purpose is not.

When hiring, prioritize learning mindset over specific methodologies. New hires should understand the current context to avoid blindly applying processes that made sense elsewhere but may not fit now.

I found this classification very useful for my day to day work. But remember, the context can be different for each part of a large system and also evolve with time.

According to this classification, these are the systems in which I have been involved:

Thank you, Jocelyn Goldfein, for this useful classification model.

References:

• http://firstround.com/review/the-right-way-to-ship-software/
• The "right" way to ship software Jocelyn Goldfein - hack.summit 2016
• http://www.eferro.net/2017/12/it-depends-context-on-creating-software.html

"It depends" / context on creating software products (I)

"It depends" is the standard consultant answer to any question. It sounds like a joke, but in fact, it is an excellent answer.

If we are involved in creating software products, our day consists of making a lot of decisions. We have to take decisions at very different levels, for various purposes, and with different importance level:

• Constant micro decisions when developing and designing software (what is the next test? should we remove this duplication? should we divide this class? what is a good name for this method? and for this module? etc.)
• Constant Architectural decisions about macro design, practices, strategies, etc.
• Sometimes estimations (or even better, how to split the features into small steps, so we don't need estimations).
• What are the optimal priorities for the next tasks to accomplish?
• Wich experiments can we define to validate a hypothesis?
• Wich technical debt should we pay right now? 
• etc.

Making decisions is hard, very hard...

In my experience good tactics to make decisions in our profession are:

• Know as much as possible about the context (business, purpose, why you need to decide about this, etc.).
• Minimize the risk associated (for example pushing for reversibility when possible).
• Postpone as much as possible (to gain more awareness about the problem, the context or the risk).
• Simplify to minimize the number of decisions needed.

And here is the problem. I usually see very little awareness about the context in which we develop the software.

This lack of awareness is why we can waste a considerable amount of energy discussing dynamic typing vs. static typing, optimize runtime performance vs. developer productivity, should we use cloud/containers/microservices.

Everyone is right, or everyone is wrong, depending on our point of view.

If we don't know about the context, the decision is always wrong :)
So "it depends"!!! (on the context)

Interesting talks/podcasts (November 2017 Part I)

These are some interesting talks/podcast that I've seen during November:

• NEXT17 | Bruce Sterling | Live from 2027
• Being a good citizen in an event driven world Ajay Nair
• Mob Programming: A Whole Team Approach Woody Zuill
• #ModernAgileShow 14 | Interview with David J Bland, Founder & CEO, Precoil
• Radical Candor — The Surprising Secret to Being a Good Boss 
• RailsConf 2017: A Clear-Eyed Look at Distributed Teams Glenn Vanderburg & Maria Gutierrez