Everything starts with an init.
It’s a perfect time to release my new project, Moonshot Engineer, a place where I can share my learnings and my views mostly about tech, startups, software, and data.
One thing I love the most is understanding how people work in their day to day basis. Jump in or starting a new project require to understand how the project works, what’s the purpose and goals of it, aligned with the philosophy behind it. From the outside we can see the inputs and the outputs, but the pipe between is most of the time hidden. Focus on the pipe, what’s inside, how things are made behind the hood? What were the decisions, the different proposals, the challenges, the methods, the tools, and why these choices were made?
All of these questions are hard to answer when you don’t work with the team or in the company itself, and that’s what I want to discover, the unshared stories. One great thing is that, in the software community, open source is almost the root culture and, that can help us to explore and understand how things are made! So it will be one of the most used channels to try to understand stories.
Behind the rocket
We have seen with the last SpaceX launch people interested in the software and the hardware that support this kind of technology. Some people tried to discover how things are made by aggregating conversations from engineers to understand how they implemented things. And discovering new technics and methods and maybe try to solve their problems with a different approach.
That’s the question, how the implementation looks like? Two different projects can produce the same output but what’s the difference between those two, how they are built. At some point in a project, we face new challenges, and sometimes these challenges were already tackled by others and we can save time to directly ask them what works and what doesn’t. We don’t have to delegate or skip steps because it’s what makes us learn but avoiding getting stuck and having another point of view, that the thing. The actual learning will come when we start the implementation.
We start with assumptions and lots of changes happen during the journey getting only the final state doesn’t lighten the full story. So logging the journey can help to understand the starting point and the path followed to reach the landing point.
This place is where I will share my logs.
Let’s dig in!