In 2024, Software has become the backbone of countless industries, it seems natural to equate software engineering strictly with coding. After all, code is the very fabric of software. However, I've come to appreciate that software engineering encompasses far more than just the act of coding. It involves understanding business needs, validating ideas, crafting user experiences, and so much more.

The reality is that while coding a solution is vital, it is also a considerable investment—both in time and resources. This investment makes it imperative to explore and validate options thoroughly before committing to a specific path.

Here, we delve into why software engineering is not just about coding and how a broader perspective can lead to more successful outcomes.

The High Cost of Coding​

Coding, by nature, is an expensive process. This cost isn't just financial; it encompasses time, effort, and the opportunity cost of not pursuing other projects. This high cost makes it essential to ensure that once the coding phase begins, the project has a high probability of success. Pre-validation steps, therefore, are not just beneficial but critical.

• Software: Costs for operating systems, databases, server software, and any other software infrastructure required.
• Cloud Services: Expenses related to cloud computing resources if the development or hosting environment is cloud-based, including storage, computing power, and bandwidth. | | Opportunity Costs | - Resource Allocation: The cost of dedicating resources to one project over another, potentially more valuable project. This includes the time and attention of the development team.
• Market Entry Timing: The potential revenue lost by not entering the market sooner, especially relevant in fast-moving sectors where being first can confer a significant advantage. | | Maintenance and Support Costs | - Ongoing Maintenance: Regular updates, bug fixes, and security patches to ensure the software remains functional and secure over time.
• Customer Support: Costs associated with providing user support, including staffing support desks, creating documentation, and developing training materials. |

The Value of Software Teams​

While coding is undeniably at the heart of the development cycle. The value that software teams bring to an organization stretches far beyond the lines of code they write. Recognizing and leveraging these additional contributions can significantly enhance the impact and success of projects. Here’s a closer look at the diverse values software teams offer:

1. Identifying the Problems: The first step in any software project isn't to start coding, but to understand the problem being solved. This means engaging with stakeholders, conducting market research, and performing competitive analysis. A profound understanding of the issue helps in crafting solutions that are not just technically sound, but also relevant and useful.
2. Validating the Business Case: Before a single line of code is written, it's critical to validate the business case for the project. This involves analyzing the potential return on investment, exploring the market demand, and considering various business models. Tools like the Lean Canvas can help in structuring these thoughts and ensuring that the project is viable from a business perspective.
3. Exploring Solutions Beyond Code: Not every issue requires a complex, coded solution. Occasionally, the answer might lie in utilizing existing platforms, integrating with third-party services, or even creating a non-technical process. For instance, automating tasks through existing tools or leveraging no-code/low-code platforms can be both cost-effective and efficient.

The Process of Creating New Solutions​

Tu fit the value of a team we have defined. This process involves several key steps designed to validate the business case, explore efficient development alternatives, and ensure the solution effectively addresses user needs without unnecessarily reinventing the wheel. Here's a closer look at these critical stages:

Validating Business Without Creating a Repetitive Solution​

Before diving into development, it's crucial to ensure that the solution being proposed does not merely replicate existing offerings without adding value. This validation involves:

• Market Research: Conducting thorough market research to understand the competitive landscape and identify gaps or unmet needs that the new solution could address.
• User Interviews and Surveys: Engaging directly with potential users to gather insights into their challenges and the limitations of current solutions.
• Feasibility Studies: Assessing the technical and economic feasibility of the proposed solution to ensure it's viable and sustainable over time.

This stage aims to confirm that the solution brings unique value to the market, justifying the investment required for its development.

Explore Buy vs. Build Alternative​

Once the need for a new solution is validated, the next step is to decide whether to develop it in-house (build) or leverage existing solutions through purchase or licensing (buy). This decision should consider:

• Cost Analysis: Comparing the total cost of ownership (TCO) for both options, including development, maintenance, and potential scalability costs.
• Time to Market: Evaluating how quickly the solution can be deployed using each approach, considering the urgency of the need it addresses.
• Customization and Control: Assessing the level of customization required and the importance of having complete control over the solution's features and development roadmap.

Exploring the buy vs. build alternative helps ensure that resources are allocated efficiently, focusing on creating value rather than duplicating existing technologies.

Explore Low Code and No Code​

For many organizations, low code and no code platforms offer a compelling middle ground between buying off-the-shelf solutions and custom development. These platforms enable:

• Rapid Prototyping: Allowing teams to quickly build and iterate on solutions without extensive coding, speeding up the validation process.
• Cost Efficiency: Reducing the need for specialized development skills, thereby lowering the cost of solution development and maintenance.
• Empowering Non-Technical Users: Enabling business analysts and other non-technical stakeholders to contribute directly to the solution creation process.

Exploring low code and no code options can democratize the development process and accelerate innovation within the organization.

Creation of Throwaway MVPs​

Developing throwaway Minimum Viable Products (MVPs) is a strategy to test hypotheses about a solution's value proposition with minimal investment. This approach involves:

• Focused Development: Building a simplified version of the solution that includes only the core features necessary to test its viability and user acceptance.
• Feedback and Learning: Using the MVP to gather user feedback and insights, which can inform further development or pivot decisions.
• Willingness to Pivot or Discard: Being prepared to modify the solution significantly or abandon it based on feedback, minimizing sunk costs in non-viable directions.

The creation of throwaway MVPs allows teams to experiment and learn quickly, ensuring that development efforts are focused on solutions that genuinely meet user needs and have a viable business case.

Embracing a Full Spectrum Approach​

Software engineering is a discipline that transcends coding. It's about problem-solving, creativity, and understanding human needs. By embracing a holistic approach that includes rigorous validation, exploration of non-coded solutions, and a keen eye on the business aspects, software projects can achieve greater success. This approach saves resources and ensures that when we do code, we're building something of genuine value and relevance.

As we navigate the complexities of modern software development, let us remember that our goal isn't just to write code but to solve problems in the most efficient and impactful way possible. This perspective is what will continue to drive innovation and success in the field of software engineering.

In the realm of software engineering organizations, the synergy and coherence of a department are often the driving forces of success and innovation. As an engineering leader, I've witnessed the transformative power of establishing common practices across teams.

These practices streamline operations and foster a culture of collaboration and continuous improvement. The key lies in identifying and implementing a “minimum common denominator” of practices that all teams can adhere to, ensuring consistency while accommodating the diverse nature of our projects and teams.

The Importance of Common Practices​

Common practices serve as a shared language and methodology that bridge the gaps between different teams within a software engineering department. They ensure that despite the varied nature of our work—be it developing new features, fixing bugs, or innovating on technology—there is a foundational set of standards and processes that everyone understands and follows. This common ground enhances efficiency, as teams can seamlessly collaborate or transition between projects without the friction of having to learn entirely new ways of working.

Moreover, these practices lay the groundwork for a culture of quality and accountability. When everyone adheres to a set of agreed-upon standards, it elevates the overall quality of output. It also simplifies onboarding new team members, as there is a clear set of practices they can learn and adapt to from day one.

Navigating Risk of overshoot or undershoot​

In the quest to harmonize operations within a software engineering department, striking the right balance between implementing common practices and allowing team-specific practices. Both extremes—having too many common practices or none—pose significant risks that can hinder a team's, and ultimately organization's ability, efficiency, or creativity.

Let's explore these risks in detail:

The Risks of Too Many Common Practices​

• Stifled Creativity: Over-standardization can create an environment where teams and their members feel their creativity and problem-solving abilities are constrained by rigid guidelines. This can dampen innovation, as teams may be less inclined to explore novel solutions that fall outside established practices.
• Reduced Flexibility: Too many common practices can make it difficult for teams to adapt to specific project needs or unique challenges. This lack of flexibility can lead to inefficiencies, as teams are forced to follow processes that may not be optimal for their current context.
• One-Size-Fits-All Pitfall: Software projects can vary greatly in terms of scope, complexity, and objectives. A heavy-handed approach to standardization fails to acknowledge these differences, potentially leading to suboptimal approaches and solutions.

The Risks of Too Many Common Practices​

• Stifled Creativity: Over-standardization can create an environment where teams and their members feel their creativity and problem-solving abilities are constrained by rigid guidelines. This can dampen innovation, as teams may be less inclined to explore novel solutions that fall outside established practices.
• Reduced Flexibility: Too many common practices can make it difficult for teams to adapt to specific project needs or unique challenges. This lack of flexibility can lead to inefficiencies, as teams are forced to follow processes that may not be optimal for their current context.
• One-Size-Fits-All Pitfall: Software projects can vary greatly in terms of scope, complexity, and objectives. A heavy-handed approach to standardization fails to acknowledge these differences, potentially leading to suboptimal approaches and solutions.

The Risks of No Common Practices​

• Inconsistency and Chaos: Without any common practices, teams operate in silos, leading to inconsistencies in code quality, project management, and communication. This can result in integration challenges, technical debt, and a steep learning curve for team members transitioning between projects.
• Knowledge Silos and Isolation: The absence of shared practices can lead to knowledge silos, where expertise and solutions are not effectively shared across the department. This isolation can hinder collaboration and slow down problem-solving and innovation.
• Quality Control Challenges: Without a baseline of common practices, ensuring consistent quality across projects becomes a daunting task. This can affect the reliability and maintainability of the software produced, impacting customer satisfaction and trust.
• Complexity in Creating Coherent Systems: A lack of common practices complicates the development of systems that work seamlessly together, leading to disjointed user experiences.

Defining a Minimum Common Denominator​

With these risks in mind. The challenge lies in defining a set of practices that is broad enough to cover the essential aspects of our work, yet flexible enough to allow for the unique needs and creativity of each team. This involves:

• Identifying Core Practices: Focus on establishing a core set of practices that address critical aspects of software development, such as languages, coding standards, version control, and testing. These practices should form the backbone of your department's operations, ensuring consistency and quality.
• Allowing for Flexibility: Encourage teams to adapt and supplement these core practices with methodologies that suit their specific project needs and challenges. This flexibility supports creativity and innovation, allowing teams to find the best solutions.
• Fostering a Culture of Collaboration: Promote an environment where teams are encouraged to share their successes and learnings from adapting common practices. This can help evolve and refine your core practices over time, ensuring they remain relevant and effective.

By defining and adhering to these minimum common practices, software engineering departments can achieve a balance between uniformity and flexibility. This balance is crucial for fostering an environment where teams can work efficiently and innovate freely, driving the organization towards its goals with cohesion and excellence.

Creating an Organization-Specific Technology Radar to Define Common Practices​

To tailor common practices to the unique needs and strategic goals of a software engineering organization, developing an organization-specific Technology Radar can be an invaluable approach. Inspired by the ThoughtWorks Technology Radar, this framework allows organizations to systematically evaluate and adopt technologies and methodologies that best fit their context. Here’s a step-by-step guide on how to implement this framework:

1. Define the Radar Structure: Similar to the ThoughtWorks model, organize your Radar into quadrants that are relevant to your organization, such as Tools, Languages & Frameworks, Platforms, and Practices & Techniques. Within each quadrant, use rings to categorize technologies or practices based on their adoption stage: Explore, Adopt, Trial, and Hold.
2. Gather Input: Solicit input from across the organization to identify technologies, tools, and practices currently in use, as well as those being considered for future projects. Encourage teams to share their experiences, challenges, and successes with different technologies.
3. Evaluate and Categorize: Define an organization wide session to evaluate the collected input based on criteria such as strategic fit, potential benefits, current maturity, and the organization’s ability to support and implement the technology or practice. Based on this evaluation, items are placed into the appropriate quadrant and ring of the Radar.
4. Communicate and Implement: Share the Technology Radar and the derived common practices with the entire engineering department. Provide guidelines, training, and resources to facilitate the adoption of these practices. Encourage teams to integrate these practices into their workflows and projects.
5. Monitor, Review, and Update: Do this at least once a year. Monitor the relevance of the items on the Technology Radar. Gather feedback from teams and conduct periodic reviews to update the Radar and the associated common practices. This ensures that your organization remains agile, adapting to new technologies and methodologies as they emerge.

By creating and maintaining an organization-specific Technology Radar, software engineering departments can foster a culture of innovation and continuous improvement. This framework not only helps in aligning teams around common practices but also ensures that these practices are dynamically updated to keep pace with technological advancements and organizational growth.

Final Thoughts​

In conclusion, establishing common practices within a software engineering organization is a strategic endeavor that balances innovation with consistency. These practices serve as the backbone of a cohesive engineering department, enabling teams to navigate the complexities of software development with agility and confidence. Ultimately, the careful definition and implementation of common practices empower organizations to achieve their strategic objectives, enhance the quality of their outputs, and maintain a competitive edge in the ever-evolving landscape of technology.

In the dynamic field of engineering, effective decision-making is crucial. From day-to-day team choices to strategic departmental shifts that align with company-wide objectives, understanding how to navigate these decisions is key to fostering a productive, innovative, and cohesive engineering environment. A well-established decision-making process is vital for several key reasons:

1. Clarity and Efficiency: It provides clear guidelines and roles, streamlining decision-making and saving time and resources.
2. Accountability and Quality: Assigning clear roles enhances accountability, leading to more informed and thoughtful decisions.
3. Transparency and Trust: A transparent process builds trust among team members, ensuring decisions are made fairly.

In every organization, decisions are made daily across various levels, to help shape the direction we collectively strive for.

Decision Stratum’s​

The Team Level​

Decisions at the team level often involve immediate, tactical issues related to required execution, technology choices, or problem-solving methods.

Empower your teams by encouraging autonomy and ownership of decisions within their scope.

Implement a decentralized decision-making process, where the teams and its members can make decisions based on their expertise and understanding of the context. This approach enhances agility and accelerates the development process. However, ensure these decisions align with broader domain and departmental goals through regular sync-ups and transparent communication channels.

2. Create a Conducive Environment: Choose a comfortable setting free from distractions. A relaxed atmosphere encourages more open and creative thinking.
3. Encourage Uninhibited Participation:

• Emphasize that all ideas are welcome, no matter how outlandish they may seem.
• Encourage participants to build on or combine ideas from others.
• Avoid criticism or evaluation of ideas during the brainstorming phase to keep the flow of ideas going.

4. Use a Visual Aid: Write down ideas on a whiteboard, flip chart, or shared document visible to all participants. This helps keep track of the ideas generated and can inspire further thoughts.
5. Timebox the Session: Set a clear time limit for the brainstorming session (e.g., 15-30 minutes). This creates a sense of urgency and helps maintain focus.
6. Facilitate the Session: Have a facilitator guide the session to ensure everyone has a chance to contribute. The facilitator can also help keep the session on track and encourage quieter members to share their ideas.
7. Review and Prioritize: Once the brainstorming phase is complete, review the ideas as a group. You can discuss, combine, or refine ideas and prioritize them based on criteria relevant to your objectives.
8. Plan Next Steps: Decide on actionable steps to explore or implement the top ideas. Assign responsibilities and deadlines as needed. |

The Domain Level​

Domain-level decisions impact a specific area of expertise within the engineering department, requiring a blend of technical knowledge and strategic foresight. These decisions might involve adopting new technologies, architectural changes, or methodologies that affect how projects within the domain are executed.

Engage cross-functional teams in these discussions to gather diverse perspectives and ensure the decision supports both engineering & product goals.

One framework that can be used is RFCs (Request for Comments) documents, as they help to build consensus and will become part of your historical knowledge base. You can start using it by following the next process:

• Define the RFC Process: Clarify who can submit, the format/template, the review process, and decision-making criteria.
• Submission and Publication: Make the RFC accessible to all stakeholders through a shared system or platform.
• Feedback and Discussion: Allow a set period for stakeholders to provide feedback and engage in discussions to refine the proposal.
• Decision-Making: After feedback, decision-makers approve, request revisions, or reject the RFC, communicating the decision clearly.
• Implementation: Approved RFCs are added to the project roadmap or backlog for execution.
• Review and Retrospective: Post-implementation, review the outcomes and conduct a retrospective to improve future RFC processes.

2. Submission and Publication: Make the RFC accessible to all stakeholders through a shared system or platform.
3. Feedback and Discussion: Allow a set period for stakeholders to provide feedback and engage in discussions to refine the proposal.
4. Decision-Making: After feedback, decision-makers approve, request revisions, or reject the RFC, communicating the decision clearly.
5. Implementation: Approved RFCs are added to the project roadmap or backlog for execution.
6. Review: Post-implementation, review the outcomes and conduct a retrospective. |

The Department Level​

Department-level decisions shape the engineering culture, define processes, and set the direction that aligns with the company’s strategic objectives. This might include decisions on budget allocations, hiring plans, department structure, or significant technology shifts.

Such decisions require inclusive leadership—soliciting input from domain leads, team managers, and sometimes the entire engineering staff.

It’s crucial to balance transparency, providing enough information for informed input, with decisiveness, making clear choices even when there’s no unanimous agreement.

2. Define Key Results: Identify measurable outcomes to gauge progress towards each objective.
3. Regular Check-ins: Conduct quarterly OKR reviews to assess progress, make necessary adjustments, and decide on priorities for the next quarter. |

The Company Level​

Decisions at the company level often involve considerations beyond the engineering department, including market positioning, customer needs, and cross-departmental initiatives. Engineering leaders must collaborate with peers in other departments and the executive team to ensure engineering strategies and resources align with company-wide goals.

Participate in strategic planning sessions and executive meetings with a clear voice for the engineering department, advocating for decisions that support both immediate product and technology needs and long-term innovation and growth.

2. Identify Key Performance Indicators (KPIs): For each strategic objective, define specific, measurable indicators of success.
3. Strategic Review Meetings: Hold regular strategic review sessions to discuss progress on KPIs, assess alignment with strategic objectives, and make decisions on strategic adjustments. |

Decision Alignment​

Aligning decisions across multiple levels within an organization is a critical challenge that requires a structured approach to ensure coherence and efficiency. As organizations grow and become more complex, the need for clear communication and defined roles becomes paramount to avoid confusion and ensure that everyone is working towards the same goals. A key strategy in achieving this alignment is to ensure that decision-making processes are transparent and involve the right stakeholders at the right time. This involves not only identifying who needs to be involved in making decisions but also clarifying the extent of their involvement and the expectations from them. Effective alignment means that strategic decisions made at the top level are informed by insights from all relevant parts of the organization and that these decisions are effectively communicated and implemented at the operational level.

2. Determine the Participants: Identify all individuals and teams involved. This includes anyone who will perform tasks, make decisions, or needs to be kept informed.
3. Create the RACI Chart: Set up a matrix with tasks or decisions on one axis and the participants on the other. Fill in the matrix with R, A, C, or I to define the role of each participant for each task:

• Responsible (R): Who is responsible for executing.
• Accountable (A): Who is ultimately accountable for the completion and success of the task. Typically, this is one person.
• Consulted (C): Who needs to be consulted or involved in the decision-making process because of their expertise or input.
• Informed (I): Who needs to be informed about the task's progress or decisions. |

Conclusion​

Effective decision-making across an engineering department is a multifaceted challenge that requires a nuanced approach at each level. By empowering teams, fostering cross-functional collaboration, engaging in inclusive leadership, and aligning with company-wide objectives, engineering leaders can navigate the complexities of decision-making with confidence. Remember, the goal is not just to make decisions but to make decisions that propel the department and the company forward in a coherent and strategic manner.

The frameworks exposed in this article can be use to aid the decision-making process, at the same time there are no hard boundaries for them. For example, we used to use RFCs at department level for cross domain alignments. Be prepared to have a toolbox that allows you to apply what makes more sense at each moment to help your team & organization.

TL;DR;

In essence, leadership and management are two sides of the same coin, each playing a critical role in guiding teams and individuals towards achieving their potential and realizing organizational objectives. By building trust and taking control in measure, you empower your teams to innovate, perform, and thrive in an ever-evolving landscape.

Have you ever worked in an organization that either seems too lax on the process or too stiff? What is behind that lack of balance? Are Leaders & Managers roles completely contradictory?

In the realm of organizational success, the distinction between leadership and management is not just semantics. It's foundational to how teams and individuals achieve their goals. While management is essential for ensuring tasks are completed, budgets are adhered to, and deadlines are met, leadership goes a step beyond, it cultivates an environment of trust, vision, and empowerment.

The Essence of Leadership: Building Trust​

Leadership is inherently about building trust. It's a leader's responsibility to create a safe environment where team members feel valued, heard, and encouraged to contribute their best work. Trust is not built overnight but is developed through consistent actions, transparency, and an open dialogue. Here are a few ways leaders can build trust:

• Empathy and Understanding: Leaders who show empathy and genuinely understand their team's challenges and needs foster a deeper connection, demonstrating they value their team members not just as employees but as individuals.

• Consistency in Words and Actions: Trust is nurtured when leaders follow through on their promises and demonstrate integrity in all actions, proving they are reliable and trustworthy.

• Empowering Others: By delegating meaningful tasks and showing confidence in their team's abilities, leaders empower their colleagues, which builds trust and cultivates a sense of ownership.

• Leading by Example: Actions often speak louder than words. When leaders embody the values, work ethic, and attitude they wish to see in their teams, they set a powerful example that encourages others to follow suit. Leading by example bridges the gap between directives and action, showing that leaders are willing to do what they ask of others.

The Role of Management: Taking Control​

Management, while often seen in a less glamorous light, is crucial for organizational success. Managers take control by organizing, planning, and directing resources to meet objectives. Control, in this context, means ensuring that processes are efficient, objectives are clear, and outcomes are predictable. Here's how management takes control:

• Setting Clear Goals and Expectations: Managers excel at clarifying goals and setting expectations, ensuring everyone knows what needs to be done and by when.

• Monitoring Progress and Making Adjustments: Control involves keeping a close eye on progress, identifying issues early, and adjusting plans as necessary to stay on course.

• Efficiency and Optimization: Managers focus on optimizing resources, reducing waste, and improving efficiency, ensuring that the team can achieve its objectives with the resources available.

• Keeping Everyone in Sync: Effective managers facilitate communication across departments, share insights and updates, and ensure that their team’s objectives align with broader company goals.

The Imbalance of Leadership Without Management, and Vice Versa​

Seeing both roles as contradictory tends to push organizations towards failure. Organizational success requires a delicate balance between leadership and management. An imbalance, where one exists without the other, can lead to challenges that hinder a team’s or organization’s ability to reach its full potential.

• Leadership Without Management: Leadership focused on building trust and vision without the grounding force of management can lead to a lack of direction and inefficiencies. While teams may feel inspired and valued, the absence of structured planning, goal-setting, and resource management can result in missed deadlines, unmet objectives, and wasted potential. In essence, the drive and motivation fostered by leadership need the rudder of management to steer the organization towards its goals effectively.

• Management Without Leadership: Conversely, management without leadership often leads to a rigid, uninspired work environment where tasks are completed, and objectives are met, but there’s little room for innovation, engagement, or personal growth. This scenario can enforce a culture of merely 'going through the motions' rather than thriving. Teams may achieve short-term goals but at the cost of long-term engagement and loyalty. The vision, inspiration, and trust-building aspects of leadership are critical for cultivating an environment where employees feel connected to their work and motivated to contribute their best.

Finding the Right Balance By Bridging Leadership and Management​

The most effective leaders are those who can blend the visionary, trust-building aspects of leadership with the pragmatic, control-oriented nature of management. Here are a few ways to bridge the gap:

• Communicate Vision and Purpose: Share the bigger picture and why work matters, connecting daily tasks to overarching goals.

• Foster an Environment of Growth: While maintaining control over the essentials, encourage innovation and risk-taking within parameters that ensure alignment with goals and values.

• Practice Emotional Intelligence: Recognize your emotions and those of others to manage interactions and communications effectively, blending empathy with decisiveness.

The synergy of inspirational leadership and effective management ensures that teams are not only motivated to reach their goals but are also equipped with the strategy, resources, and direction to do so.

Why would I do this?​

Docker-desktop is a paid product, their licensing mode is by user, and it provides value not for the software side but for their cloud offering (registry, etc). For this, if the intent of you're a company is to use containers locally to facilitate software development, the cost tends to be high.

What is podman?​

Podman (short for Pod Manager) is an open-source, Linux-native tool designed to develop, manage, and run containers and container images. It offers a Docker-compatible command-line interface (CLI) that does not rely on a daemon, but directly interacts with the Image registry, container, and image storage, and container process operations.

Migration Steps​

1. Clean-up Docker Desktop (Optional)​

you will need to run the next bash script

#!/bin/bash

# Uninstall Script

if [ "${USER}" != "root" ]; then
    echo "$0 must be run as root!"
    exit 2
fi

while true; do
  read -p "Remove all Docker Machine VMs? (Y/N): " yn
  case $yn in
    [Yy]* ) docker-machine rm -f $(docker-machine ls -q); break;;
    [Nn]* ) break;;
    * ) echo "Please answer yes or no."; exit 1;;
  esac
done

echo "Removing Applications..."
rm -rf /Applications/Docker.app

echo "Removing docker binaries..."
rm -f /usr/local/bin/docker
rm -f /usr/local/bin/docker-machine
rm -r /usr/local/bin/docker-machine-driver*
rm -f /usr/local/bin/docker-compose

echo "Removing boot2docker.iso"
rm -rf /usr/local/share/boot2docker

echo "Forget packages"
pkgutil --forget io.docker.pkg.docker
pkgutil --forget io.docker.pkg.dockercompose
pkgutil --forget io.docker.pkg.dockermachine
pkgutil --forget io.boot2dockeriso.pkg.boot2dockeriso

echo "All Done!"

2. Install Homebrew​

Homebrew is the defacto command line package manager for OSX, if you don't have it is very recommendable to have it.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

3. Install Podman​

On Mac, each Podman machine is backed by a QEMU based virtual machine. Once installed, the podman command can be run directly from the Unix shell in Terminal, where it remotely communicates with the podman service running in the Machine VM.

For Mac, Podman is provided through Homebrew. Once you have set up brew, you can use the brew install command to install Podman:

brew install podman

Next, create and start your first Podman machine:

podman machine init
podman machine start

You can then verify the installation information using:

podman info

At this point, podman should have created a proxy file in /usr/local/bin/docker, if it does not exist you will have to create it with:

sudo vim /usr/local/bin/docker

add in that file the content:

#!/bin/sh
[ -e /etc/containers/nodocker ] || \
echo "Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg." >&2
exec podman "$@"

the script needs to be made executable by:

chmod +x /usr/local/bin/docker

you should now be able to run a docker as normal

docker run -it docker.io/hello-world

4. Use podman-mac-help​

You should consider using podman-mac-help to migrate transparently to Podman on macOS.

• Continue using familiar Docker commands.
• Take advantage of the benefits of Podman on macOS.
• Your tools, such as Maven or Testcontainers, communicate with Podman without reconfiguration.

The podman-mac-helper tool provides a compatibility layer that allows you to use most Docker commands with Podman on macOS. The service redirects /var/run/docker to the fixed user-assigned UNIX socket location.

To enable this, you just need to run:

sudo podman-mac-helper install

5. Install Podman Desktop (Optional)​

Finally, to have a better compatibility and a UI to work with as with docker desktop, you can install Podman desktopby running:

brew install podman-desktop

Welcome to our Continuous Delivery Bootcamp! We'll teach you the skills you need to get your projects out the door fast, without sacrificing quality. By the end of this program, you'll be a pro at transforming code into working software. Sign up today and start transforming your workflow!

This chapter we will do an example on how to build and validate our project in github actions.

Video

{% embed https://youtu.be/QMwXxezykHc %}

Watch the video on Youtube

This is a #functional #programming series focusing on the main concepts using #kotlin.

In this second chapter, we will initialize a project with gradle and kotlin

Video

{% embed https://youtu.be/YSbMLid1h-c %}

Watch the video on Youtube

This is a #functional #programming series focusing on the main concepts using #kotlin.

In this first chapter, we will do an intro of the differences between OOP and FP

Video

{% embed https://youtu.be/DG3cj6dV3YM %}

Watch the video on Youtube

Welcome to our Continuous Delivery Bootcamp! We'll teach you the skills you need to get your projects out the door fast, without sacrificing quality. By the end of this program, you'll be a pro at transforming code into working software. Sign up today and start transforming your workflow!

This chapter we will do an intro on the tools we will use and how to commit code with git and GitHub works

Video

{% embed https://youtu.be/nwpUtvHulWM %}

Watch the video on Youtube

Welcome to our Continuous Delivery Bootcamp! We'll teach you the skills you need to get your projects out the door fast, without sacrificing quality. By the end of this program, you'll be a pro at transforming code into working software. Sign up today and start transforming your workflow!

This chapter we will do an iteration writing test, doing test driven development not only as a testing tool but also as a design tool.

Video

{% embed https://youtu.be/MG-Uqve41BQ %}

Watch the video on Youtube