🎓 Making (reasonably) good decisions quickly; Using a third Entity instead of a Join Table
🤔 How to make (reasonably) good decisions quickly.
Part of a senior engineer’s responsibility is creating clear direction for their projects and their team. Clear direction comes from decisions made in uncertain situations, where multiple options are viable.
By making well-informed decisions quickly, a senior unblocks themselves and their team and enables action, learning, and iteration.
Why make decisions quickly
The decisions we’re talking about today aren’t clear and obvious ones. They’re decisions made during uncertainty. Maybe you have multiple options that all seem viable. Maybe you aren’t sure if your problem will be solved by the chosen direction.
Decisions should be made quickly to get clarity faster.
The faster a decision is made, the faster action can be taken, and the sooner you will have the result or outcome of your decision.
Decide → Act → Learn → Repeat
How long exactly is “quickly”?
Every engineer’s favorite answer: it depends!
There is no specific time frame a decision must be made within. Thankfully, there are two heuristics you can use to help gauge how long to consider your options:
How big an impact will this decision have on the organization? If the topic is mission critical and will support the foundations of the entire business for years to come, take your damn time! If there’s minimal impact and things can be easily changed, decide quickly and iterate from there.
When will you know if the decision was good or bad? If the outcome of your decision can’t be known for a long time, spend more time up front. (And be careful that your scope isn’t too big.) If you’ll know in a reasonably short time, the initial decision can be made more quickly.
How to decide quickly
Understand the problem. Make sure the problem and desired outcome from the decision is well-defined. Have an answer to the question “How will I know if my decision was correct?”
Prioritize. Focusing on the most critical aspects of a decision can make the process faster.
Reduce scope if needed. Does the decision seem massive, with a large potential impact? Reduce scope to be less impactful, and can be decided and iterated on more quickly.
Research your options. Narrow your choices through research that supports better options and rules out others. Limit your time using the aforementioned impact and duration heuristics.
Collaborate with your team. Utilize the knowledge and experience of your peers. Ask for their opinions, especially if your options are more subjective. Letting your team express their preferences will help you get buy in.
Don’t wait for unanimity. It’s incredibly rare to have everyone fully agree on something. Don’t wait for it. Make a decision that is supported by a majority.
Don’t stall with multiple choices. When you’ve done all this and there are still multiple options that seem like good choices, just pick one! Especially if the impact is low and you can iterate quickly. Getting to the act phase is more important than choosing the “best” option, because acting will help you learn what best actually is.
Use prototyping, testing, and automation. Building prototypes and conducting quick tests can provide immediate feedback and inform decisions, especially when choosing between different technical approaches or designs.
How you can apply this today
When presented with a choice that you would usually ask a more senior team member for direction on, try deciding yourself first. Then talk to that team member, present the options, and what you think the best decision is and why.
If the team member disagrees, you can have a conversation about why. A great learning opportunity.
If the team member agrees, the conversation will be short, you have saved them time and mental capacity of having to make another decision, and you both get confidence in future decision making opportunities. Eventually you’ll be empowered to make decisions like that without consulting others.
👥 Using a third entity instead of using a join table
A join table is commonly used in relational databases to associate two records with each other in a many-to-many relationship.
Consider this example of a University with Student and Class entities. There are many Classes, each with many Students. A basic join table structure may look like this:
This works just fine if there is no additional data in the middle of this relationship. However, the University wants to know more than who is in the class. We need to track attendance, grades, etc. for each student.
We could add these attributes to our existing join table, but some frameworks and ORMs don’t play nicely with that. We’re also now seeing more of our domain coming into play. This isn’t just a relationship, this is first-class data.
Let’s reflect that by replacing the join table with a proper Enrollment entity:
By adding a third entity, we’ve:
Better reflected the domain and business logic of the University (a student enrolls to a class)
Alleviated any issues with frameworks or ORMs that don’t play nice with additional data in join tables
Kept all the same relationships
Things & Happenings
Tech
Learning
Eloquent JavaScript (4th Edition, 2024), a book about JavaScript, programming, and the wonders of the digital
Tools
dbdiagram, used to make those table graphics 🙂
Other Reading
Coming Up
What an MVP actually is
Horizontal vs. Vertical scaling
I posted a poll on LinkedIn about future topics to cover. Head there to vote and influence the content of this newsletter!
Talk to you again soon.
Aken 💙