What I Learned From Building Something From Scratch

(This story is part of the weekly assignments for my internship at Nearsoft. I hope that some of the insights I learned this week can help others in their learning journey. Previously: Month 2, Week 3.)

Just earlier today, we handed off the project and it’s time to prepare for the next phase. However, in this essay I will look back into some of the lessons I learned this last month working as a team.

Checklists and Documentation

In the video How do we heal medicine?, Atul Gawande talks about the habit of top professionals: checklists. During this project, I understood the importance of checklists, processes and specially, written documentation. This helps, not only for others to learn from your mistakes, but also for your future self. This past weeks, there were more than a couple of times were we had a Liquibase, Docker or Git error. However, having the habit of not only following checklists but also, creating them would have saved us time and effort. In short, what I learned about this is that errors within a project are valuable knowledge and when you acquire this knowledge is vital for you to pass it to others asynchronally through documentation.

Optimism and Teamwork

Looking back to the beginning of our last sprint, I remember we were entirely optimistic about us completing the tasks for the demo. We were wrong. However, this optimism helped us keep morale high and continue. In the video, The Optimism Bias, Tali Sharot talks about why optimism is good for us to grow but also, she talks about what we can do to prevent failure. In this picture, there are some agile practices that I believe would have been a great parachute for us to develop. Which ones would you add?

The Optimism Bias Ft. Agile Development

Antifragility and Retrospectives

There’s an important difference between resilience and antifragility. Something resilience endures shock and stays the same but, something antifragile gets better. Then, how do we construct antifragile development teams? Through retrospectives. Retros allow teams to not only endure difficulties but, to get better because of them. Every end of a sprint is an opportunity to detect areas of opportunity, share them with the team and create actionable tasks to improve. This is somehow related to Moonshot thinking, Growth Mindset and the normalization of accepting one’s failures and learning from them.

In summary, there’s no better teacher than experience and, what better way to learn Software Development than by developing software. This experience has been challenging, demanding and difficult to say the least. However, looking back to everything that I learned, I wouldn’t want it any other way.

26 yo. Self-Taught Software Developer. I write about Career Change, Women in Tech and anything exciting I’m working on.