Everything I learned | Month 2| Encora/Nearsoft Academy

Hi everyone! 🤗

Here’s another special edition blog post of what I learned in the second phase of the Academy program. I learned a lot by working on a real-life project and I have some interesting sights, but first, let me tell you about my readings.

— — — 🦢 The Black Swan: The Impact of the Highly Improbable 🦢 — — —

Most of the time, when we plan something we take the highly probable scenarios and built upon them, But, what happens if one of the rarest scenarios just comes up, we don’t know what to do.

With globalization, the planet became smaller. In islands, you have more diversity in 1 square meter than entire continents. Then, the rarest scenarios are even rarer.

The black swan describe an event that comes as a surprise, has a major effect and is often inappropriately rationalized after the fact with the benefit of hindsight

Also, when there is a big mistake, we make future generations fix it.

But, how can we be protected from these black swans? We need to know how robust we are.

How do we know we are robust?

Start playing with the parameters and see how much the output changes

The tail events matter

— — — 🦾 Agile In Practice 🦾 — — —

Overall this month, I applied agile practices in project management, and I realized how important all of their concepts are. A quick survival guide will be the following:

• Pair programming: A practice when there is a couple of developers solving a single problem, where is someone driving (coding) and someone is navigating (focus on the goal and tools). The quality increases as there are people building things together.
• Continuous integration: As developers, we are building a system apart at a time, every time a feature is completed we add it to what we already have, the build. If the new feature doesn’t pass the tests, then the build is broken, otherwise is ready to go. This practice reduces risk and helps deliver a defect-free solution.
• Frequent small releases: Making this practice agile teams get feedback quickly, incorporate the feedback into future releases, and give a quicker return on investment.
• Definition of done: A practice between the development team that defines when a user story is done.
• Burn-up charts: Metric that shows the progress made against the release plan. It gives an insight into how to manage the team to achieve the scope.
• Test-Driven Development: Software development discipline where developers write automated test cases for enhancements or new features before they write any code. Ensures quality, keeps code clear, simple, and testable, provides documentation for different team members, repeatable tests, as well as enables rapid change.
• Automated testing: Provide continuous and early feedback, avoiding boring and repetitive testing.
• Planning poker: Tool that encourages all team members to contribute to the activity of estimation and share their opinions, thoughts, and concerns. Happens after prioritizing the work.
• Retrospectives after iterations: This allows the team to pause and reflect on how are they working together? how can they improve? and what issues need clarification?
• Sustainable pace: The more relaxed and rested a team is, the better they can perform at a sustainable peace.
• Success sliders: Define the success criteria at a high level for a project. It should involve the Project Owner and SCRUM Master. Normally involves scope, cost, quality, and time.
• Prioritization using MSCW: Method to determine the priority of the user’s stories. Must have, Should have, Could have, and Would have.
• Showcases: Demonstrate completed work to the project owner, sponsor, and other stakeholders to get feedback and present, inspect, and adjust opportunities for the team to course-correct if changes need to be made.
• Stand-ups: Status meetings that long no more than 15 minutes, they should answer the questions What did you do yesterday? What will you do today? What is blocking your progress?
• Big visible charts: Share the project’s information at glance, they should be available and visible for everyone, as communication is key to ensure the project's success.
• Social contracts: Create a respectful and safe work environment, states the obligations and rules for all team members.
• Story cards/user stories: Capture user requirements as the view of the user, and manage the delivery of user functionality. It should have the structure: As a … I need … So that …

— — — 🍣 The Optimism Bias 🍣 — — —

I should accept that I’m an optimistic person, I believe that everything would work well for me, even if the tendencies showing otherwise. I embrace the optimism bias.

The tendency to overestimate our likelihood of experiencing good events in our lives, and underestimate our likelihood of experiencing bad events.

It has its good sides like being confident, and enjoy things more

• Interpretations matter
• Anticipation makes me happy.

But, as always, there are pitfalls of the optimism bias:

• Risk behavior

That remembered me two weeks ago, my failure to estimate the time I would need to solve a particular issue, my optimism made me not completing the task and pay a high price for it. So, I believe that the only way to have an optimistic bias, and not having the consequences is:

Plan for failure

— — — ⛑ How Do We Heal Medicine? ⛑ — — —

How do we get good of what we do? Become a system

1. The ability to recognize success and failure
2. Devise solutions
3. The ability to implement

When you are a specialist, you are not interested in the final result, instead, you are interested in data.

The same way we can apply it to software engineering, where almost everything is done individually, and with the proficiency of the craftsman.

— — — 🥖 Antifragile: Things That Gain From Disorder 🥖 — — —

• Fragile: Something when it changes, it breaks
• Robust: Something doesn’t change.
• Antifragile: Something when it changes, became better.

How to become antifragile:

1. Enough stressors.
2. Enough time to recover.

You have to fail in order to get success. Chaos leads to growth.

This applies to my last failure, which was not taking risks. I didn’t understand at the moment, but after I realize that I need some chaos and big boundaries if I want to learn and succeed.

— — — ✨ The Team Project ✨ — — —

This month was one of the most fantastic moments in my Academy journey, I learned a lot from my teammates, mentors, failures, and most importantly, myself.

Working with someone else is not easy, sometimes someone makes a mistake, and instead of doing all the toxic practices of a normalized job, I realized how supportive everyone could be, and that is a place I want to be part of.

Also, even if I couldn’t decide about my preferred tech stack, I learned a lot about javascript, and one of my interests in technology, Express, which in my opinion, it was easy to understand and apply.

— — — ⛰ Final Thoughts ⛰ — — —

Team working is not a skill you can acquire easily, you should have to practice it at all times with extreme care of not being the undesire teammate. But, when a team is in coordination the sky is not a limit.

Thank you for reading until here!

See you! 👋🏽