Saturday, December 30, 2017

"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:

            (Text updated 2022-12-20)

            Saturday, December 09, 2017

            "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  for example.

            The model classifies an application in two axes:

            • Horizontal axis: 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. From very costly software for a critical mission for an enterprise, up to free software for consumers.


            Attending to this classification, we can define the cost of making a mistake for the application, the optimal release process, how to obtain feedback, etc.



            For example, for costly enterprise software deployment on-premise, the best approach for obtaining feedback, perhaps is having beta tester programs with discounts for the customer. But to get feedback from a customer-oriented software that is sustained by ads, the fastest way is A/B testing and continuous deployments of new experiments.



            Another example, if we consider 1x the cost of making a mistake for a free consumer web application deployed in the cloud, perhaps the cost of making a mistake for expensive enterprise software deployed on-premise may be two orders of magnitude higher.





            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:



            Thursday, December 07, 2017

            "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)