I was introduced to a first principles-ish approach to understanding your priorities when making a product. It's consequence has changed the way I think about writing code in industry. The idea is simple, but it's a little abstract, so I'll jump right into an example.
Last week I spend a lot of time writing tests for a (big) refactor a couple of us have been working on for a key component of the product. Because we wanted to be iterative, we wanted to write tests for the new changes that we were making. As talked about last week, testing is an important form of documentation. As part of that, I was asked to add comments explaining why each test was needed.
Because the tests I were writing were fairly short unit tests, I had a hard time writing meaningful comments and ended up basically explaining what each test was doing (ie checks that this function is called between this time and that time). Technically this is why the test was needed, but after some more discussion, I ended up understanding what my reviewer meant by why.
Earlier I talked about making product decisions on the job. This is a direct application of keeping the end users in mind but in reverse.
The idea in that post specifically is we want end user needs to direct how we build our codebase. Now the idea is we want anyone reading the codebase to be able to link some functionality of the codebase to an end user need.
This is a pretty logical consequence to the former idea. I've been thinking about React's design lately, so another way of describing the idea is you want your codebase to be a function of end user needs. Because there's no automatic diffing algorithm to transition from one state to another, each transformation must be done by hand.
Because of this, you not only need to know what a piece of code does in relation to the codebase (ie this updates the database), but also how it provides to some end user need (ie the end user needs <some reason>, so we need to update the database). Without that understanding you won't be able to manually perform the transformations needed to maintain codebase = f(end user needs).
I've realized that I also need to write code in such a manner that keeps the end user goals clear for others. Comments are one way to this end, but the design of codebase is another implicit form of communication of how a piece of code meets the end user needs.
This also means that I when reading code, I should be thinking about how a piece of code links to an end user need. While it's daunting at first to start digesting a new codebase on the implementation level, I need to be sure that I'm also able to interpret how the implementation comes together to realize some feature in the product.
When I mentioned "first principles," I'm talking about how all of this stems from the single idea that the goal of a company is to make money. Because Dynasty is providing a product for others to buy, we make money when our users are happy with our product. The new goal becomes to create and maintain customers happy with our product.
This is what created the first post about Product Decision Making, to always keep the end user in mind when building on the product.
This post is the consequences of all of that above, and includes more actionable goals when writing code. Personally, I think it's cool to see the evolution of the posts to reflect the evolution of the knowledge gained from the internship. Until next time.