Being Wrong Is Your Job

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had an amazing week!

I didn’t send an email on Thursday since it was Thanksgiving.

For those of you who celebrated, I hope you had some amazing turkey 😆

Save 55% on the latest GenAI skills

Udacity helps professionals build in-demand skills through rigorous, project-based Nanodegree programs created with industry experts. Our new Generative AI Nanodegree teaches the full GenAI stack—from LLM fine-tuning to RAG and multimodal workflows—so you can build production-ready AI systems. With our Black Friday sale live, now’s the best time to invest in your growth. Get started today.

Enroll Now & Save 55%

Being Wrong Is Your Job

When I first started coding, my standards were embarrassingly simple.

I only had 2 requirements:

1. It works

2. It doesn’t take forever to run.

If it followed those conditions, ship it.

I genuinely could not have cared less what it looked like.

Then I learned some fundamentals, read that Clean Code book everyone obsesses over, and took every optimization technique from school way too seriously.

Suddenly, I had opinions about what "good code" looked like.

No more throwing everything into one function, that's "ugly."

Instead, I'd architect 20 classes spread across 40 files and write tests for every possible scenario because that's what "real engineers" do, right?

Then I'd finally run my beautifully-engineered masterpiece and...

Broken.

The exact same result as when I didn't care about code quality.

Except now, instead of fixing one messy file, I had to debug 10 classes and update 20 tests.

So yeah, I "technically" wrote more robust, well-engineered code. I also wasted a ton of time for the same broken result.

This led me to think, “Wow, I’m a garbage programmer.” Which isn’t exactly a lie, but it also made me realize something else:

Being wrong is unavoidable in software engineering

You might think being wrong is a skill issue. And sure, sometimes it is.

But in the real world? You're wrong because you don't have enough information.

Here are some examples:

• Your UI design falls apart when you use real data instead of "Lorem Ipsum"

• Your coworker casually mentions there's an internal library that does exactly what you just spent two weeks building

• Your data source has some weird edge case that obliterates all your assumptions

• Requirements change mid-sprint

• A dependency gets deprecated

None of these situations is really "your fault."

If you had the information upfront, you would've written a solution based on it.

But you can't know about the information until you get it wrong.

And that's exactly why the best engineers write bad code first.

Speed Run to Being Wrong

The faster you identify your mistake, the sooner you ship.

Here's the approach that's saved me so many times:

Step 1: Write the dumbest version that could possibly work

And I mean dumb.

Hardcode values. Copy-paste code. Use global variables if you have to. Your goal is to prove the concept works, not to impress anyone.

Let's say you're building a feature to calculate shipping costs. Don't start by building an abstract pricing engine with strategy patterns, factory classes, and interfaces for every possible carrier. Just write a function that calculates a shipping cost.

def calculate_shipping(weight, distance):
    # Yeah, this is hardcoded. Deal with it.
    base_rate = 5.00
    per_pound = 0.50
    per_mile = 0.10
    
    return base_rate + (weight * per_pound) + (distance * per_mile)

Is this "good code"? Not really, but it proves the core functionality works.

You can now test if prices make sense, if the calculations are accurate, and if customers can actually check out. You know, the stuff that actually matters.

Step 2: Run it and break it

Don't just test the happy path. Try to destroy your code. Try weird edge cases.

For the shipping example, test negative rates. Put everything at zero. What if you somehow got a string instead of an integer?

For general situations: disconnect your internet. Send a bad user ID. Slow down your network to 3G. Enter a 500-character username. Click the submit button 47 times in a row.

Whatever breaks, now you know what you actually need to handle.

Because you need to understand:

Users will absolutely break your code, and not always on purpose.

Some are malicious. Some are confused. Some are just impatient and will spam that submit button 20 times even though there's clearly a loading spinner telling them to wait.

A lot of programmers assume people will understand how to use their app "correctly." They won't. They'll use it in every wrong way possible. Your job in Step 2 is to go from a programmer to a regular user.

Step 3: Identify the real problems

After breaking your code, you'll discover what actually matters. Maybe you need different rates for international shipping. Maybe heavy items need volume-based pricing, not just weight. Maybe you need to handle expedited shipping options.

Now you know what problems you're actually solving, not what problems you thought you were solving.

Step 4: Refactor with intention

Now you can write better code. And "better" is specific.

You're not making it "more extensible" or "following SOLID principles." You're solving the actual problems you discovered in step 3.

class ShippingCalculator:
    def __init__(self, region):
        self.rates = self._load_rates_for_region(region)
    
    def calculate(self, weight, distance, is_expedited=False):
        # Now we know we need regions, expedited handling, and proper rate loading
        base = self.rates['base']
        per_pound = self.rates['per_pound']
        per_mile = self.rates['per_mile']
        
        cost = base + (weight * per_pound) + (distance * per_mile)
        
        if is_expedited:
            cost *= 1.5
            
        return round(cost, 2)

Your code quality should scale with your understanding of the problem. The more you understand what you're actually solving, the better you'll be at focusing on the right abstractions and optimizations instead of premature optimization.

The Real Value of AI

Look, I get why people hate on AI-generated code. It's usually garbage for production.

AI is terrible at writing production-ready code that covers edge cases, handles errors gracefully, and matches your standards.

But here's what AI is actually good at: creating quick, dirty prototypes that get something minimally viable working.

AI makes you wrong faster. That's a feature, not a bug.

Here's why: AI doesn't cover edge cases or optimizations unless you explicitly tell it to. Which means you have to notice these problems. It forces you to think about what's missing, what breaks, and what actually matters.

Here's how I use AI in this workflow:

For Step 1 (dumb version)

Just ask AI what you want. Yes, it’s that simple.

"Write a Python function that calculates shipping cost based on weight and distance." Boom. Done in 30 seconds. I don't care if it's perfect. I need to see if this approach even works.

For Step 2 (breaking it)

Ask AI for edge cases.

"What edge cases should I test for shipping cost calculations?"

AI will remind you about obvious edge cases like negative values, international shipping, and dimensional weight.

And yeah, they seem obvious now. But when you're deep in implementation mode, your brain glosses over the "obvious" stuff.

You're thinking, "Of course, users will enter valid weights." Meanwhile, someone's already typed in "-500" and broken everything.

AI is basically that anxious, cautious coworker who asks "but what if..." for every scenario.

You can't get mad at AI for being thorough.

For Step 4 (intentional refactoring)

Tell AI to refactor based on the edge cases.

"Refactor this shipping calculator to support different regional rates."

Now AI has context about your actual problem and can help you implement a specific solution.

Once it generates the solution, please review it. Don’t blindly trust it, but don’t optimize it too much yet.

The key is using AI as a "get to wrong faster" tool, not a "write perfect code for me" tool.

Because nobody can write perfect code, whether you’re a human or a machine, so please…

Don't Get Attached to Your Code

Almost all code you write will eventually be rewritten or completely thrown away.

I've seen engineers get genuinely upset when their code gets replaced.

They'll defend every architectural decision like their reputation depends on it and argue against improvements because "the current way works fine."

But that doesn’t work with software.

Your project pivots - That entire microservice you built for B2C customers? Useless now that you're going B2B. All those consumer-facing features? In the trash.

The team grows, and standards change - What made sense for a 3-person team absolutely doesn't scale to 30 people. Your clever shortcut that saved time? Now it's technical debt.

Technology evolves - Remember when everyone was building with jQuery? Or when everyone used XMLHttpRequest instead of fetch? Technology gets better; that's just how this works.

Better solutions emerge - Someone just has a legitimately better approach. It's simpler, faster, and more maintainable. Your code is objectively worse. It happens. Learn from it.

The engineers who succeed aren't the ones who write code that never gets replaced.

They're the ones who write code that's easy to replace when the time comes.

Problems change. Solutions change.

So don't get personally offended when your code gets tossed or rewritten. It's just software engineering. The faster you accept this, the faster you'll become a great engineer.

Plus, not being weirdly defensive about your code makes you way more enjoyable to work with.

Nobody wants to be in a code review with someone who treats every suggestion like a personal attack.

And being enjoyable to work with? That's how you actually move up in your career.

Not by writing the "cleanest" code. Mediocre programmers who are great collaborators get promoted over brilliant jerks every single time.

Practical Strategies for Embracing Bad Code

Let me give you some concrete tactics for putting this into practice:

Set a "proof of concept" deadline. Before you write a single line of production code, give yourself a tight deadline (like 2 hours) to build the ugliest working version possible. This forces you to cut through the noise and focus on core functionality.

Do "messy pair programming" sessions. Get on a call with a teammate and explicitly say: "Let's write the ugliest code possible that solves this problem." It's honestly liberating. Full on hackathon style to solve something as fast as possible. You'd be amazed at how much faster you can validate ideas when nobody's judging code quality.

Document your learning, not your code. Instead of writing extensive inline comments explaining your clever algorithm, write a quick README explaining: "Here's what I learned about this problem, here's what I tried that didn't work, here's what I'm still uncertain about." This is way more valuable for the future you (and future teammates).

Timebox refactoring. When you do decide to clean up code, set a 30-minute timer. If you can't make meaningful improvements in 30 minutes, you probably don't understand the problem well enough yet. Come back later.

When Bad Code Becomes a Problem

Look, I'm not saying you should always write bad code forever. There's definitely a point where bad code becomes technical debt that slows you down.

Here are some good signals you should invest in code quality:

When you're copy-pasting the same logic 5+ times - Yeah, that probably needs to be abstracted. But not before you've copy-pasted it enough times to understand the pattern.

When bugs keep appearing in the same area - If you're constantly fixing issues in the same 100 lines of code, that's a sign it needs better structure and tests.

When onboarding new developers takes forever - If new teammates can't understand what your code does without a 2-hour explanation, it probably needs better organization and naming.

When changes take exponentially longer - If a feature that used to take 1 hour now takes 8 hours because you have to update code in 15 different places, your abstractions are probably wrong.

Just remember: You can only identify these problems by first writing bad code and seeing where it hurts. You can't architect your way around problems you don't understand yet.

How to Make Projects Less Painful

Start projects the way you did when you first learned to code: just solve the problem.

Get something working first. Understand what you're actually dealing with. Then optimize and clean it up.

Trying to write "good code" too early is like trying to edit your novel while you're writing the first draft. You'll just get stuck, second-guess everything, and never finish.

Write bad code. Ship it. Learn from it. Then make it better.

The best engineers I know aren't the ones who write perfect code on the first try.

They're the ones who can move from bad code → working code → good code faster than everyone else.

They fail faster. They learn faster. They ship faster.

And for the love of all that is holy, don't get too attached. It's all gonna be junk code eventually anyway.

Your project will pivot. Requirements will change. Technology will evolve. Someone will find a better approach, and if you don’t believe that, give it six months.

The code you write today is just a stepping stone to the code you'll write tomorrow.

Last week, there was no challenge! Time to start grinding again.

Day Number of Year

You’re given a date string in the format month/day/year, based on the Gregorian calendar. Your task is to return which day of the year that date corresponds to (1–365, or 1–366 for leap years).

Examples

dayOfYear("12/13/2020")
output = 348

dayOfYear("11/16/2020")
output = 321

dayOfYear("1/9/2019")
output = 9

dayOfYear("3/1/2004")
output = 61

dayOfYear("12/31/2000")
output = 366 # leap year
dayOfYear("12/31/2019")
output = 365 #non leap year     

Notes

• Make sure to account for leap years when February has 29 days.

How To Submit Answers

Reply with

• A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

• or if you’re on the web version leave a comment!

• If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.