Weekend. You open VS Code, put on some lo-fi, and in 4 hours implement an authentication system with OAuth2, JWT refresh tokens, rate limiting, and even deploy it with CI/CD.
Monday. You spend the entire day trying to add a field to a form because you need approval from 3 teams, the database is managed by another department, and deployments only happen on Thursdays.
The code you write at home
# Side project at 2am
class PaymentProcessor:
async def process(self, payment: Payment) -> Result:
validated = await self.validate(payment)
charged = await self.gateway.charge(validated)
await self.notify_user(charged)
return Result.success(charged)
Clean. Simple. Works. You chose the stack, designed the architecture, and didn't have to explain to anyone why you didn't use the internal framework nobody likes.
The code you write at work
# Work at 3pm, after 2 meetings
class PaymentProcessorV2LegacyBridgeAdapter:
def process(self, payment_dict, legacy_flag=True, use_new_gateway=False):
# TODO: remove when we migrate (2019)
if legacy_flag and not use_new_gateway:
return self._old_process(payment_dict)
# John asked for this, don't know why
elif legacy_flag and use_new_gateway:
payment_dict['__hack_mode'] = True
return self._hybrid_process(payment_dict)
# This will never run
else:
return self._new_process(payment_dict)
And you didn't even want to write it this way. But there's the legacy system. And the vendor API that follows no standards. And the requirement that changed mid-sprint.
Why does this happen?
1. Constraints vs freedom
At home: "I'll use PostgreSQL because it's the best for my use case." At work: "The company has a contract with Oracle, so..."
2. Controlled scope
At home: You build exactly what you need. At work: You inherit 7 years of decisions other people made.
3. Selective perfectionism
At home: "I'll refactor this until it's perfect." At work: "Does it work? Ship it. There are 15 more tickets in the backlog."
4. The audience is different
At home: Yourself (and maybe 3 people on GitHub). At work: Product managers, clients, compliance, and that dev who's gonna maintain this 2 years from now.
The plot twist
Here's the secret nobody talks about: your work code is probably more valuable.
Your beautiful, well-architected side project? Serves 0 users and generates $0.
That ugly code at work with 47 flags and comments mixing Portuguese and English? Processes millions of transactions and pays your salary.
The balance
I'm not saying to accept bad code. I'm saying to understand the context.
- Side projects are your playground. Experiment, fail, refactor 10 times. That's how you learn.
- Work is where you apply pragmatism. Sometimes "good enough" is the right answer.
The experienced dev knows when to fight for quality and when to accept trade-offs. Not all code needs to be a work of art — sometimes it just needs to solve the problem and not break in production.
TL;DR
Your personal code is "better" because you control all the variables. At work, you're a variable in someone else's system.
And that's okay. Keep making your beautiful side projects. They keep you sharp enough to survive Monday's legacy code.
Now, if you find a job where you can code like at home... let me know.