My Web Development Blog

Working with boot.dev to create great cloud content

2025-10-31T00:00:00Z

I’m thrilled to announce a major collaboration between Bevel Work and the incredible team at boot.dev!

We’re joining forces to develop brand-new Cloud Platform content designed to help you master the skills needed for today’s dynamic cloud environments.

I have to say, boot.dev is a genuine wealth of knowledge and hosts one of the warmest, most supportive learning communities I’ve ever seen. Their commitment to making complex topics accessible and engaging is unparalleled, and we are so excited to contribute to their mission.

Ready to level up your cloud skills? Get a head start and secure your spot (or snag a discount on boot.dev’s other amazing courses!) with this special link

Stay tuned for more updates on this project!

Quick Utils: quick-nats-are-bad

2025-10-08T00:00:00Z

Sometimes a combination of humor and details can change things. In my case convincing a team to take on the management of their NAT infrastructure is a difficult to do. So I wrote a quick tool to help and to give quick numbers if dealing with that nagging “should we replace these NAT Gateways?” question.

It scans your US regions, lists NAT Gateways, pulls pricing, reads CloudWatch data processing, and estimates monthly spend. The output highlights where your money goes—hourly NAT charges plus per‑GB data processing—and flags cross‑AZ routing that quietly adds $0.01/GB in both directions.

Source code is available on GitHub.

To install run:

brew tap bevelwork/tap
brew install quick-nats-are-bad

quick-nats-are-bad # Run it

For other quick utils, check out bevel.work.

You are what you eat; you believe what you do.

2025-09-29T00:00:00Z

You and everyone you know are a set of rules you make for yourself.

People make choices every day. What to eat, what to wear, what to do this weekend. In college, we’d guess that people would generally choose to do the thing that they thought was most useful or have the most utility for themselves.

And while seeming too basic an idea to be true, you can bring in a surprising amount of nuance to the system.

I chose to sleep in this morning because I value the sleep more than I value the incremental benefit of exercise.
I didn’t proofread this text message because I would rather spend my time on something else.
I became a developer instead of a teacher because I enjoy this particular balance of risks and rewards.

These are conscious and unconscious values we place on our interactions with the world. But what’s really interesting about human behavior is people will impose different rules on themselves, and change those rules over time. Their justifications and reasons for their choices are just as varied and at times arbitrary. My father as a child heard the phrase:

Blue and green should never be seen.

And so he applied that rule to his life. A rule that I’ve never heard anyone else apply to themselves. What rules do you apply to yourself? Take a moment and gauge yourself of a few different metrics:

How pragmatic are you:
- More Pragmatic: I’m going to spend my time on the most valuable things.
- Less Pragmatic: I prioritize following the process even if its less efficient.
How idealistic are you:
- More Idealistic: Some things have value in and of themselves.
- Less Idealistic: I only pursue goals that have clea, achievable, and measurable results.
Are you an individual or community?
- More Community Focused: I forego my needs so X can succeed.
- Less Community Focused: I can only accomplish what needs to be done if I take care of myself.
How do you handle risk?
- More Risky: I am confident in my abilities and choices despite the risks.
- Less Risky: I use my talents to build security and safety into my life.

You have unquantifiable values for each of these, and so do the people around you. So know your personal values, and when you take the same measuring stick and apply it to your professional life.

Manager X is pragmatic and highly risk averse, so making concerted effort to show up on time, and explicitly show how decisions compensate for risks is going to have more value demonstrating how your choices align with company values.

Manager Y is very culture and community oriented. So showing preferences that demonstrate personal sacrifice for the benefit of the group are going to carry weight.

This is not chess though, we do not have perfect information, but I think a huge amount of unforced errors would be avoided if we thought about:

So do you know what the real rules are for your goals, your team, and your life?
Do your actions reflect the rules you make for yourself?
Do you know what the people around you value?
Do the people around know what you value and do your actions reflect that?

Should You Learn IaC?

2025-09-25T00:00:00Z

So I’m trying a new format. Here’s a video walking through why I got into Infrastructure as code, and the problems in my life it helps me solve.

youtube link here

Let me know what you think.

Devops Interview Prep: Leetcode as Code

2025-09-18T00:00:00Z

In a competitive job market it’s important to be able to demonstrate the technologies you’re proficient with, and the undisputed best test for this takes the form of a whiteboard exercise or an algorithm test to see if you’re able to implement common data structures and the sort.

But, could I succeed without functions, true if/else statements, and loops?

Fizzbuzz is often a first interview question for candidates and we’ll cut our teeth on it:


locals {
  iterations = 100 # First we specify the number of iterations
  fizzbuzz = [for i in range(local.iterations) : {
    index = i
    value = i % 15 == 0 ? "FizzBuzz" : 
      i % 3 == 0 ? "Fizz" : 
      i % 5 == 0 ? "Buzz" : 
      i # Otherwise, just return the index
  }]
  fizzbuzz_result = [
    for i in local.fizzbuzz : length(i.value) > 0 ? i.value : i.index
  ]
}
# ["1", "2", "Fizz", "4", "Buzz", "Fizz", <snip>..., "14", "FizzBuzz"]

Okay, not so bad, what about sorting? Surely this will scale well. Can it sort?

locals {
  mixed_list = [
    1, 3, 5, 1,1,1
  ]

  bubble_sorted_list = [
    for i, val in range(length(local.mixed_list)) :
    i < length(local.mixed_list) - 1 ?              # Make sure we don't go out of bounds
    local.mixed_list[i] < local.mixed_list[i + 1] ? # Determine if we need to swap
    local.mixed_list[i] : local.mixed_list[i + 1] : # Handle the swap
    local.mixed_list[i]                             # We were on the last element, just return the value
  ]
}
# Not quite. We're not sorted, and we misplaced a 5 somewhere.
# [1,3,1,1,1]

Let’s update that to use a module:

locals {
  state = [5, 4, 3, 1, 2]
}

# Five passes, each pass performs odd+even swaps
module "pass_0" {
  source = "./mods/pass"
  in     = local.state # [5,4,3,1,2]
}

# <snip> pass_1 through pass_4 </snip>

module "pass_4" {
  source = "./mods/pass"
  in     = module.pass_3.out # [1,2,3,4,5]
}

The timeless product of cs50 students everywhere, but we want to set our sights higher.

P.S. unfortunately importing ./mods/pass from within mods/pass led to a circular dependency, bringing terraform to its knees. I also considered putting terraform apply --auto-approve into a while loop and letting it mutate a file input, but I think I’m getting distracted.

# Here's the module:
variable "in" {
  type        = list(number)
  description = "Input list for a single odd+even bubble pass"
}

module "swap_odd" {
  count  = floor(length(var.in) / 2)
  source = "../swap"
  in     = [var.in[count.index * 2], var.in[count.index * 2 + 1]]
}

locals {
  pass_odd = concat(
    flatten([for i in range(0, length(module.swap_odd)) : module.swap_odd[i].out]),
    length(var.in) % 2 == 1 ? [var.in[length(var.in) - 1]] : []
  )
}

module "swap_even" {
  count  = floor((length(local.pass_odd) - 1) / 2)
  source = "../swap"
  in     = [local.pass_odd[count.index * 2 + 1], local.pass_odd[count.index * 2 + 2]]
}

locals {
  pass_even = concat(
    [local.pass_odd[0]],
    flatten([for i in range(0, length(module.swap_even)) : module.swap_even[i].out]),
    length(local.pass_odd) % 2 == 0 ? [local.pass_odd[length(local.pass_odd) - 1]] : []
  )
}

A bit messier, but it works. I think I could get rid of the swap module but I need a new challenge. Let’s try something with a cleaner approach: is this a palindrome?

locals {
  is_palindromes = [
    "", "a", "aa", "aaa", "kayak", "radar", "racecar", "madam", "dog", "god",
    "cat", "act", "rat", "mat", "hat", "bat", "tab", "cab", "bac", "aca", "cac",
    "aac", "cca", "aaa", "ccc", "aaaa"
  ]
  palindromes = [
    for str in local.is_palindromes :
    length(str) <= 1 ? true : # empty string and single characters are palindromes
    alltrue([
      for i in range(floor(length(str) / 2)) :
      substr(str, i, 1) == substr(str, length(str) - 1 - i, 1)
    ])
  ]
}

The next challenge is Two Sum, which we can conquer with a map:

locals {
  # Test data for Two Sum
  two_sum_array = [2, 7, 11, 15, 3, 6, 1, 8, 4, 9]
  two_sum_target = 23
  
  two_sum_value_map = {
    for i, val in local.two_sum_array : tostring(val) => i
  }
  
  # For each number, check if (target - number) exists in the map
  two_sum_raw = [
    for i, num in local.two_sum_array :
    contains(keys(local.two_sum_value_map), tostring(local.two_sum_target - num)) && 
    local.two_sum_value_map[tostring(local.two_sum_target - num)] != i ?
    {
      indices = [i, local.two_sum_value_map[tostring(local.two_sum_target - num)]]
      values = [num, local.two_sum_target - num]
      sum = local.two_sum_target
    } : null
  ]
  
  # Filter out null results from optimized solution
  two_sum_results = [
    for result in local.two_sum_raw: result if result != null
  ]
}
# {
#     "indices" = [3,7]
#     "sum" = 23
#     "values" = [15,8]
# }

Ah yes Mitchell would be proud.

Quick Utils: quick_pipreqs

2025-09-17T00:00:00Z

Never again will I spend 10 minutes on Monday morning handling dependabot/renovate merge conflicts.

The best way to build momentum is to consistently release small things. Not everything needs to be a masterpiece—sometimes the most valuable tools are the ones that solve one specific problem really well.

This is my next small thing: quick-pipreqs.

It’s a simple tool that iterates through large Python monorepos and utilizes pipreqs to update all requirements.txt files it can find.

It does them all in one go and allows for quickly parallelizing them. Really helpful if you want to clear out a lot of Renovate or Dependabot merge requests at one time. Never again will

Available via:

github.com/bevelwork/quick_pipreqs

brew tap bevelwork/homebrew-tap 
brew install quick-pipreqs

What is super. Examples of Composition, Inheritance, and Interfaces

2025-09-13T00:00:00Z

So when I was first programming, the concept of super() was a hard for me to grasp. I saw things like react components where things would break if you suddenly forgot to include it in certainly places.

Simply put super (or base, or parent depending on the language) explicitly import behavior from something else. So let’s start with a language that doesn’t have this like go.

type Cat struct {
    name string
}

func (c Cat) Name() string {
    return c.name
}

type Dog struct {
    name string
}

func (d Dog) Name() string {
    return d.name
}

So we’ve got a Dog and a Cat here, both with names. In Go, we can relate these through interfaces - things that share common behavior.

// Here's an interface that we can use to relate to everything that has a name
type Nameable interface {
    Name() string
}

func namePrinter(n Nameable) {
    fmt.Println(n.Name())
}

// Both Cat and Dog implement Nameable, so we can use them interchangeably
cat := Cat{name: "Whiskers"}
dog := Dog{name: "Fido"}

namePrinter(cat) // Whiskers
namePrinter(dog) // Fido

Now let’s see how we can use composition to create more complex structures:

type Animal struct {
    Nameable
    age int
}

func animalNamePrinter(a Animal) {
    fmt.Println(a.Name())
}

// Create animals using composition - embedding the Nameable interface
cat := Animal{
    Nameable: Cat{
        name: "Whiskers",
    },
    age: 2,
}

dog := Animal{
    Nameable: Dog{
        name: "Fido",
    },
    age: 3,
}

// Both work with our functions
namePrinter(cat) // Whiskers
animalNamePrinter(cat) // Whiskers
namePrinter(dog) // Fido
animalNamePrinter(dog) // Fido

So our interface says here are a bunch of things that have this in common. It doesn’t require any extension of the Cat or Dog structs themselves and just asserts that anything passed as Nameable will meet the requirements of the interface.

The composition method creates a struct that explicitly includes the Nameable interface. So while we have to add in the behavior ourselves, it gives us a means to glue a bunch of things together and reason about the whole.

Now let’s look at super(), and to do so we’ll switch to some python code, and afterward’s we’ll look at what’s going on.

class Animal:
    def __init__(self, name):
        self.name = name

    def get_name(self):
        return self.name

Here’s our base Animal class with a name and a method to get the name. Now we can create specific animals that inherit from this base class.

class Cat(Animal):
    def __init__(self, name):
        super().__init__(name)

class Dog(Animal):
    def __init__(self, name):
        super().__init__(name)

# Create our animals
cat = Cat("Whiskers")
dog = Dog("Fido")

print(cat.get_name()) # Whiskers
print(dog.get_name()) # Fido

So when we initialize a Cat or Dog, we call super().__init__(name). Super lets us reference the parent class’ implementation, in this case the initialization and the methods and properties that were implemented for Animal. This is really attractive, as if we had 100’s of animals, we wouldn’t have to implement get_name for each of them. This can also be chained together. So Animal -> Kingdom -> Phylum -> Class -> Order... Each class is aware of its parent in a linked-list fashion.

However, here’s the issue I’ve often run into. What if we have the proverbial horse with no name, that is some situation where we want to include some aspects of Animal, but not all of it. How much work would it take to extend our systems to accommodate this new behavior?

// First we update our definition of Animal as not all animals are namable

type Animal interface {
    // Nameable <-- This was removed
    GetAge() int
}

// Our new horse
type HorseWithNoName struct {
    age int
}
func (h HorseWithNoName) GetAge() int {
    return h.age
}

// Our implementation of Cat and Dog do not have the change
// ... Snip ...

func namePrinter(n []Nameable) {
    for _, animal := range n {
        fmt.Println(animal.Name())
    }
}

func agePrinter(a []Animal) {
    for _, animal := range a {
        fmt.Println(animal.GetAge())
    }
}

This didn’t require much change to our code, and the functions can tie directly to the aspect that pertains to their use case. All animals can still be handled by the animalAgePrinter function, while only nameable animals work with namePrinter.

Now let’s see how this same scenario plays out with Python’s inheritance model:

# We can keep our Animal, but we'd have to add a nil name or override get_name()
class HorseWithNoName(Animal):
    def __init__(self, age):
        # Problem: We still need to call super().__init__() but with what name?
        super().__init__("")  # We have to provide something, even if it's empty
        self.age = age

    def get_name(self):
        return "This horse has no name"

# This works, but it's awkward
horse = HorseWithNoName(5)
print(horse.get_name())  # "This horse has no name"

Or we have to bisect Animal into base Animals and Nameable Animals:

# Separate concerns - not all animals have names
class Animal:
    def __init__(self, age=0):
        self.age = age

    def get_age(self):
        return self.age

class NameableAnimal(Animal):
    def __init__(self, name, age=0):
        super().__init__(age)
        self.name = name

    def get_name(self):
        return self.name

class Cat(NameableAnimal):
    def __init__(self, name, age=0):
        super().__init__(name, age)
# ... snipped dog example ...

class HorseWithNoName(Animal):
    def __init__(self, age):
        super().__init__(age)

# Now we can handle both cases cleanly
def print_animal_ages(animals: List[Animal]):
    for animal in animals:
        print(f"Age: {animal.get_age()}")

def print_nameables(nameables: List[NameableAnimal]):
    for n in nameables:
        print(f"Name: {n.get_name()}")

cat = Cat("Whiskers", 2)
dog = Dog("Fido", 3)
horse = HorseWithNoName(5)

print_animal_ages([cat, dog, horse])
print_nameables([cat, dog])

The Trade-offs

The Go composition approach gives us flexibility at the cost of more verbosity. We have to explicitly implement the methods for each structure, but we can compose those structures together, or build interfaces that allow us to interact with aspects that are shared between them.

Python’s inheritance with super() provides a clean way to extend functionality, but it can become problematic when the inheritance hierarchy doesn’t perfectly match the real-world relationships between objects. The “horse with no name” scenario highlights how inheritance can force us into awkward compromises or require significant refactoring.

As I’ve written more things I’ve come to write more composition-based code. For when my future self comes back to that code the idea of locality of reference, e.g. keeping the related code together as much as possible, makes a huge effect on how long it takes me to get up-to-speed on a codebase.

References

Go watch this, its fantastic

Quick Utils

2025-09-11T00:00:00Z

Something I’ve always enjoyed is when a tool or widget is surprisingly useful. Almost always, utilities I write are useful for their intended purpose and solve the immediate problem, but then they end up in the elephant graveyard that is 1-starred git repositories.

I think the key is to publish them, accept feedback from your peers on what actually makes it into their technical toolbag, and lean into the ones that get a bit of traction. So we’ve released one of these tools: quick-ssm.

It’s a simple tool that lets you quickly create a new SSM session without having to log in to AWS, look up the instance name, or confirm that the instance is on.

It lets you quickly expose a port to see if a web service is really running.

It lets you see the thing you obviously forgot and need to go fix. There’s something honest about a simple tool and making it available to the world.

Just Enough Automation

2025-09-09T00:00:00Z

Every developer faces the same question dozens of times: “Should I automate this task?” The answer is rarely obvious. Automate too little, and you’re drowning in repetitive work. Automate too much, and you’re building elaborate systems for problems that don’t exist.

In projects I’ve worked on, I’ve inevitably had to weigh this decision, and the answer invariably is “Maybe?”. But “maybe” isn’t helpful when you need to make a choice.

What should factor into this decision? Where is the threshold between valuable automation and wasted time? What intangibles are we trying to optimize for?

Terms

So let’s try to quantify this.

Value Delivered = Value of the Task
                - The Effort of Implementing the Task

Simple enough, if I see a penny on the roof of the parking garage next door, is it worth going down the stairs, navigating the parking garage, and picking up the coin? Maybe not, but there exists a pile of coins where the hassle is definitely worth it.

So for tasks that we are never going to do again, we best optimize for the effort
to get the task done and nothing else. Let’s expand our equation to accommodate an
ongoing effort:

Value Delivered = Value of the Task * Number of Iterations for the Task
                - The Effort of Implementing the Task

So if the task is repeatedly done, or perhaps the effort for automating the task is exceptionally low, it may be the best return on our time.

The Hidden Costs

Everyone who has decided to handwash that one dish instead of putting it in the dishwasher has made this calculation in their mind. However, let’s spend a moment talking about the non-obvious consequences of automation.

Maintenance. Whether you’re doing the task yourself or automating, there’s going to be some upkeep:

If you’re out of the office, how do you make sure the task still gets done and
someone knows how to do it?
If you write that script (workflow, program, process), who will go and update
it as the task changes, and make sure it’s still doing what it’s supposed to?

Value Delivered = Value of the Task * Number of Iterations for the Task
                - The Effort of Implementing the Task
                - Maintenance Costs

Documentation. If you’re doing a task that has any impact beyond yourself, you’re going to need to document it. This is the proverbial Sticky Note on the fridge to buy milk. There’s also a cost of occasionally running out of milk when we can’t be bothered to leave a note. Let’s add that in:

Value Delivered = Value of the Task * Number of Iterations for the Task
                - The Effort of Implementing the Task
                - Maintenance Costs
                - Documentation Costs

Mistakes. However you perform a task, the human element will exert itself. That could be a typo in your script or leaving a $1,000 tip instead of a $10.00 tip. What will happen to the value proposition when you discover your mistake?

Value Delivered = Value of the Task * Number of Iterations for the Task
                - The Effort of Implementing the Task
                - Maintenance Costs
                - Documentation Costs
                - Mistake Costs

Long Term Effects.

Life is a sum of all your choices
– Albert Camus

Choices you make on small items have a cumulative effect on the long term. Working out today won’t make you much more than sweaty, but working out for the next decade may change your life.

The same principle applies to automation decisions. Each choice to automate or perform a task manually builds your skills and shapes your approach to future decisions. Performing the task manually might improve your understanding of the process, while automating it might develop your technical skills. The key is recognizing that these long-term effects compound over time, potentially outweighing the immediate cost-benefit calculation.

Consider the developer who always automates their deployment process versus one who manually deploys each time. After a year, the first developer has built robust automation skills and reliable deployment systems, while the second has gained deep intuition about deployment nuances. Both outcomes have value, but they’re different kinds of value that affect future decisions.

Long Term Value = Value of the Task * Number of Iterations for the Task
                - The Effort of Implementing the Task
                - Maintenance Costs
                - Documentation Costs
                - Mistake Costs
                ± Long Term Effects

Conclusion

Automation is a tool, not a goal. We should never automate something for the sake of automation. Our professional lives are full of rituals:

A ritual is a repeated, structured sequence of actions or behaviors that alters the internal or external state of an individual, group, or environment, regardless of conscious understanding, emotional context, or symbolic meaning.[^1]

Essentially performing an act regardless of its effectiveness at being fit for any particular purpose (e.g. Standups filled with idle chatter, meetings that fail to state or accomplish a goal, creating dashboards that will never be used).

I think automation can be a great self-documenting tool, or a means to fight human error, but it should be wielded with purpose.

References

[^1] https://en.wikipedia.org/wiki/Ritual

The Case for Cowboy Coding

2025-09-03T00:00:00Z

It seems like a desirable thing to be able to look at work that you’ve done
over the years and say:

“That stood the test of time, I wouldn’t change a thing.”

And so, enthusiastically, I set forth to craft my project. Infusing it with
creativity and passion, only to have the wolrd assert itself:

Hey, I need this done this week.

So the one week version was what was written, and we know the heart of something
great is there, but in an honest moment I look at that projects I’ve completed and say:

I’m not sure I’d do that again.

Or worse:

That was a waste of time.

Why is this? What can be done to correct this? Is something going wrong in my
preparation, my craft, my follow-through? So with years of projects to look back
on, I’m faced with two archetypes of myself of which I have conflicting
feelings. What approach can I take to deliever value?

The Samurai Developer. The version of myself who prepares well, is
considered in their approach and work. A well-executed plan is the highest prize,
and large refactoring and abandonment the highest price.

“Measure twice, cut once.”, or “A sitch in time saves nine.”

Or the Cowboy Coder, who implements quickly, with minimal thought for the
long-term vision, and is comfortable with ambiguity. Who loves getting the job
done, and testing the validity of requirements with a working prototype.

“Perfect is the enemy of progress.”, or “A bird in the hand is worth two in
the bush.”

These two mindsets I’ve used in many projects. Let’s review a few:

The Generic Feature

This is a feature that will be used by many other downstream efforts. It has a
clear vision, and detailed requirements.

The Samurai will approach this with gravitas. I probe the requirements
for unforeseen roadblocks, and I’m willing to push the start date until the work
is truly ready.

I consider the data model and logical abstractions that will be needed. I
diligently implement and test The Generic Feature and do a good job.

The Cowboy delivers the feature ahead of schedule. It may be a bit more
austere, but it will be delivered.

Which I choose depends on this equation I subconsciouly go through for each
task:

Value I Deliver = Benefit of the Task 
                - Implementation Cost
                - (Refactor Consequence × Risk)

So the Benefit of the Task is reason why we’re doing the task. Some things
are really worthwhile, while others are certainly worhtless.

The Implementation Cost is the cost of waiting for the feature to be
delivered. My empoloyer is paying me to do the work, and other engineers and users
are waiting for that work to be delivered. In almost all cases, fewer days is
better.

The Refactor Consequence is the cost of refactoring the code. What would it
cost us if we have to refactor this code? Will we lose that client? Will we delay
a release, or am I the only person on earth that will know about this feature?
We’ll come back to this.

Risk, quantifies the chance that we will need to refactor this. Some code
will never be touched again. Some code will be rewritten ten times as it
becomes the hot path for your application.

Okay, so we’ve got some levers, and we solve for while maximizing value. Let’s
go to another example.

The Pacemaker

This project is make it or break it. Any failure mode has disastrous consequences
eclipsing the value of the whole project, let alone the feature. So if we plug
this into our equation:

Value I Deliver = Benefit of the Task 
                - Implementation Cost
                - (Company Ending Event × Risk)

In the case were failure is catastrophic, we must do everything we can to
reduce the risk. Predicting this let’s us know if what it would take to implement
is actually worth it.

So the methodical Samurai will win out.

The Idea

Your company has definitely had an idea or two. One or two of them are why this
whole project is happening. These might be untapped treasures, or these might
be a collossal ego project for someone signing the checks. How do should you
approach this?

Value I Deliver = Benefit of the Task # Nearly zero as this is a lottery ticket.
- Implementation Cost
- (Refactor Consequence × Risk)

In this case the only variable we really control is the cost of implementation.
Its value is arbitrary. So do we build a featured implementation that will
succeed for any future, or do we build a prototype to validate the idea, knowing
full well we’ll have to refactor or throw it out.

The Cowboy wins here. They get to validate the idea the soonest for the
least amount spent. Allowing a company to test the market with lots of ideas
and not bet the farm on a single one.

Okay, so “it depends” on the situtation. I think that’s something you knew
already coming into this article, but my challenge to you is that you should
almost always be a cowboy.

Unknown unknowns There are a category of roadblocks that simply cannot be
known until the project is in motion. This significantly increases the
likelihood that all code will be refactored anyways. That refactoring will
benefit from both an existing prototype and knowledge of requiredments that
could no be known otherwise.
Most of what we write does not matter. Look at code you wrote 6 months ago,
would you write it the same way? Your code is not going to last forever.
Refactoring will happen naturally as bottlenecks are discovered, and as
features are expanded upon. Writing the simple version first avoids a whole
category of premature optimization problems.
There is a huge benefit in repetition. You solving a certainly class of
problem repeatedly will end up in a great solution that you can readily
produce. Take this example:

[A] ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay. ^[1]^[2]

Does quality matter?

Yes, uniquivocally. We connot hire an army of interns to build a prototypes
and expect to succeed in the market. Our same equation applies:

Value I Deliver = 0 #  Benefit of the Task
                - Implementation Cost
                - (Refactoring Consequence × 99%) # Risk

If you’re code does not meet the requirements it is not delivering on the value
of the feature. If you’re code always has to be refactored then any value
you’re delivering is going to be short lived.

My favorite method is two fold:

Create the simplest version of the feature that can be delivered.
Reflect and if necessary refactor.

In this way we never comit a huge amount of resources to an unproven idea. Better
developers will deliver great simple features and get a chance to test it against
the market. Junior developers will get feedback on their ipmlementation and how
to improve their approach.

So in summary.

Know the tradeoffs of your approach and weigh situation against them.
Place a high value on iteration time. Simple components are usually better.
Most of our code is unimportant, and the important code will likely be refactored.
Utilize protoypes and be a cowboy.

Learn to look at your code and say, “That was probably the right thing at the
time.”