An Incomplete List of Mantras for Engineers at @Branch
Startup engineering requires a constant balance between moving fast — which is one of a startups ONLY competitive edges — and making smart engineering decisions which allow you to scale and grow dynamically. Often these two things go hand in hand with each other, actually, but to an engineer they can feel mutually exclusive due to apparently disparate pressures of Product wanting to “get things done” and Engineering wanting to “get things done right.” I believe that with a proper framework we can alleviate the sole engineer from having to align these pressures by themselves and instead can bake them into the day to day culture of engineering.
A simpler engineering solution is (often) also a simpler product
One of the easiest traps for Product to fall into is trying to solve every single product edge case, often with solutions that are both extremely difficult to understand and, thus, also code. This leads to unmaintainable code and more untestable engineering edge cases. To avoid this trap engineering should inject itself into the conversation and represent the side of maintaining conformity around functionality in the product. This requires Engineering to break down product goals into building blocks, and to figure out a way to combine these building blocks to accomplish Product or Designs goals. This conversation forces Design and Product to not haphazardly solve special cases and instead use solutions with intent, understanding that there is a tradeoff between special casing and quality. If an engineer can’t understand all of the logic which they have coded into a product how can you expect a user to?
Implementation is always different from presentation
In order to enable product to pivot as quickly as possible the engineer needs to be able to determine the underlying building blocks and implement those in as simple a way as possible. They can then use the blocks to build the current iteration of product, but are free to rearrange them in the future as product deems necessary.
An example of this is if you have a number of different type of participants in a room (ex. faving a room, posting in a room, faving a post in a room). Product comes to you and says “We want to display a roster of everyone, with different meta information around different people depending on how they have participated in the room.” Through further discussion you determine that this is important as to provide context about the room. Rather than building a straight roster, with a number of booleans determining how each user has participated, the important piece to engineer is context. Whether showing everyone in the room provides the best context, or a subset of the people participating in the room, is something that can’t really be known until it is seen. Therefore implementing this in such a way where you have a list for each type of participation and then can combine them or not as necessary allows product to play with what information actually provides the best context.
It takes a village
As engineers we often are required to get lost in the weeds. We need to take a spec or design from someone else and figure out how to build it in a way that takes into account all of the disparate forces. Things like code reviews are invaluable in this situation. They allow an engineer to be content getting lost in the weeds, knowing that in code review their peers have their back on the overall design. They also allow the engineer to not get worried with “is this the best way?” (a P = NP hard problem) knowing that surely someone in review will say “Did you think about this?”
A more difficult, but equally helpful, part of code reviews is that they require the engineer to be selfless. Engineering shifts from a competition driven practice of discovering the best, most creative, trickiest way of getting something done and instead becomes about building the best possible solution you can think of knowing that this is simply a draft. The egoless way of engineering is challenging at times but, ultimately, freeing.
