If you're unfamiliar with the Maine Island Cabin Rebuild, check this article out:

Maine Island Cabin: The Build

It took a family and friends to build the memories, and it took the same to rebuild.

https://paragraph.xyz

1. A project with one architect and laborers moves faster than one with all architects

Defined roles on a team are crucial to setting expectations, task management, and maximizing daylight and output. Arguing over how things should be done just wastes time. If you ask one hundred builders how they'd build something, not one answer would be exactly the same. If you ask a developer how something should be architected, chances are their tech stacks will vary, and same with how they structure their solution.

Having hierarchy optimizes decision-making and delegation of tasks, maximizing efficiency. In an engineering team, dividing and conquering feature sets and having the point person connect pieces together makes for a smooth build. Without one source of truth, assigned tasks can overlap when accountability is split and result in duplicated tasks. In a development perspective, this can look like merge conflicts or misunderstandings of the feature or ticket. That being said, always be asking if coworkers need assistance or clarification. Keeping a pulse on their progress shows awareness and prompts question asking, as well as makes sure that there's nobody doing redundant work

2. Don't chase a dropped screw

In essence, try to avoid wasting time and energy on a smaller task that won't yield as much impact if it slows down a larger, more impactful task. Especially when building out larger features, it's important to not get bogged down with the small, nitpicky aspects, unless it involves security of course. I like Coinbase's idology when it comes to work ethic and prioritization of tasks:

We focus on the 20% of work that will get us 80% of the impact

By tackling tasks with the highest impact, more progress is shown as opposed to being slowed down by tasks that don't move the needle as much. There's seldom difference in replacing a screw if it's a quarter of an inch off the center stud, just put another one in and keep moving on. Similarly, especially in pre product market fit companies, getting stuck having the perfect UX or designs won't yield new customers if the feature set isn't fully there yet.

3. Don't fight the wood because the wood will win every time

Oftentimes, you need to read the piece of wood to see which way it curves, called Crowning, which is a common lumber defect that occurs when the center of a piece of wood is raised while the edges dip down. Eyeing the crown of the piece of wood may not seem to have a meaningful impact, but when it comes time to drill screws in, if you're off by a fraction of an inch, it could result in an uneven surface. Similar to this, if you're not thinking about a function and it's intended purposes before you start writing code, you'll have to go back through after and refactor each method's implementation to fit the updates or have multiple methods to maintain that do very similar operations.

4. Measure twice, cut once

When making measurements for cutting lumber, you don't want your measurement to be off. For time and money's sake, double checking your work before committing will save embarrassing instances and shame down the road. Before creating a method or component, make sure you fully understand all the details of the task to avoid a rewrite. Additionally, see if there's existing similar components or methods to save you time as well. This can also be applied to SQL queries, especially if they're destructive!

5. Tidy up the job site before leaving

After a hard day's work, putting the batteries on the chargers, organizing the power tools, and sweeping up the debris not only will save you time tomorrow searching for tools you need, but also reduces the risk for accidents. Applying this to code, before a commit is pushed, cleaning up the console logs, adding comments, and running checks will save time during a code review and cleanup down the line. Updating documentation will save loads of time when a future developer is looking for context as well, while you don't have to explain to them what the additions do.

Thanks for reading, and keep on hammering 🔨