W4D3: Adapting to existing projects and company conventions

Third session of the final week, and it’s another non-technical one. The subject is what happens after you get hired: you open a repo you didn’t write, full of decisions you don’t understand, and you have to be useful in it without breaking anything. Lucian is blunt that most of this week’s slides look pessimistic, and he explains why — there’s nothing to learn from the scenario where everything goes fine.

What’s covered

Joining a codebase you didn’t write

• The many flavours of “existing project”: a friend’s side project, a company’s million-line monolith, a freelance client’s small app. Different rules, same core problem.
• Why so much production code is spaghetti. Two reasons, both economic: it’s often cheaper to hire a junior who takes a week than an expert who takes a day, and business decisions are made on ROI, not elegance. Lucian is clear he’s describing how it is, not how he’d like it.
• What you’re actually adapting to: coding conventions, testing processes, and the pipeline that moves a task from To Do to Done or Shipped.
• The first week: roughly 20% imposter syndrome, 80% confusion. Normal. It’s also the team’s job to sandbox you so you can poke around without taking production down.

git blame, and asking the right person

• A live walk through git blame in a GUI client. Lucian doesn’t pretend to be a command-line git person and says straight out he recommends a visual tool, and that’s a strong opinion.
• What blame is actually for: not blaming anyone, but working out who last touched a line so you know who to ask “why is this like this” or “can you help me do the same thing over here”.
• He also admits he uses it rarely enough that he re-learns it every time.

Restraint

• Resist the urge to rewrite everything. Understand the module you’ll be working in first. The exception is if refactoring is literally your job, which is a mid/senior conversation.
• Feature creep and noise: do what the task description says and nothing else. If you spot something worth doing, write it down or raise it at the retro instead of sneaking it in.
• Important vs urgent. Lucian’s mental trick: if you only had time for one of your ten “important” things, which one? That tells you what’s actually top of the list.
• “This could be better, file it away for when you have free time” — never. He says this still happens to him and he doesn’t expect to escape it.

Company conventions

• Code conventions (naming, underscores, field style) plus project conventions that are Unity-specific: how prefabs are built, whether scenes are Unity scenes or prefabs instantiated into one persistent scene, how async loading is handled.
• Soft conventions too — don’t ping people on Slack at certain hours, that kind of thing. Different for every team.
• If a million lines already use a convention you dislike, you don’t refactor it to be pretty. Follow what’s there. Same team, two projects, two different styles? Stay consistent with each.
• Don’t try to revolutionise their methods. They probably already tried your idea and it broke something. Being right isn’t enough — a suggestion needs to move a number: deliveries per month, retention, revenue, team happiness.

Shipping, trade-offs and estimates

• The “ship it perfect but never” versus “ship it decent and next week” framing runs through the whole session.
• Sometimes you’ll deliberately break a best practice to hit a deadline. Your job is to say so out loud, so the decision sits with your lead rather than quietly with you.
• Estimations: most people are bad at them even after ten years. Lucian adds 30–40% to his own now; his advice to everyone else is just double it.
• Testing in production happens. It can almost always be prevented and people do it anyway. He references the CrowdStrike incident from the week before.
• Design first, code later. Coding is mostly translation from idea to implementation. He admits he still skips this, writes garbage, then draws two lines in a paint app and rewrites the whole thing in ten minutes.

Timestamps

• 00:02:00 — What “coming to an existing project” actually means, and why there are too many variations to cover them all
• 00:06:30 — Why production code is usually bad: the junior-vs-expert cost math and plain ROI
• 00:11:00 — First week reality — confusion, imposter syndrome, and being sandboxed so you can break things safely
• 00:15:00 — git blame demonstrated in a GUI client, and why Lucian refuses to do it from the command line
• 00:22:00 — Finding out who to bug with questions, and resisting the urge to rewrite everything
• 00:26:00 — No documentation, the one person who knows everything, and what to do when you have nothing to do
• 00:33:00 — Asking a senior or architect: “what are the three best places to look for the next three hours”
• 00:37:00 — Ignoring noise and feature creep: do exactly what the task says, log the rest
• 00:42:00 — Important vs urgent, the gun-to-your-head prioritisation exercise, and sprint reality
• 00:48:00 — Company conventions: naming, prefabs vs scenes, and non-technical team rules
• 00:55:00 — Learn the rules before you break them; why “you could be right” isn’t enough to change anything
• 01:02:00 — Chat detour: Unity in the industry, Pokémon Go and DI overhead, Lucian’s 2013 Ubisoft internship, how many people it took to build PUBG
• 01:12:00 — Splitting work so you finish something visible every week, and why three weeks with nothing done is corrosive
• 01:17:00 — The level-of-detail method for features: ship an end-to-end ugly version first, detail it later (with the whiteboard sketch)
• 01:28:00 — Deliberately sacrificing best practices to ship, and passing the trade-off up the chain
• 01:31:00 — Estimations, doubling them, and testing in production including the CrowdStrike reference
• 01:37:00 — Design first, code later, plus working with clients and building soft skills when you’d rather not
• 01:47:00 — Job hopping early on, and Q&A: most stressful project, biggest failure, most successful plugin

What you take away

A working model for your first month on someone else’s project. You’ll know how to trace ownership of a line of code, how to ask for the shortest useful onboarding path, and how to tell the difference between a convention worth questioning and one you should just follow.

The section that carries the most weight is the level-of-detail approach to features. Instead of building the main menu’s start button perfectly and then moving on, build the whole menu crudely — start, exit, options, all connected, all ugly — then increase detail across the next passes. Two payoffs: you always have something to show, and in maybe 30% of cases someone tells you in week three that half of it isn’t needed, which means you never polished it. Lucian says this is how he landed his first Upwork gig — he built a rough version of what the client asked for, sent it with the proposal, and they were sold on the spot.

There’s also the career advice he flags as unoriginal but repeats anyway: don’t stay more than six months at your first company, then six at the next, switch a couple of times, and only then settle if you like it. Soft skills, he argues, are what separate an 80 salary from a 120. He rates himself as having gone from a 4 out of 10 to an 8, which he says took deliberate work.

Who should watch this

Anyone about to start their first Unity job or first freelance contract, and anyone who has technically learned C# but has no idea what a sprint retro is or why their refactor suggestion got shot down. It’s also useful for solo devs, since the sections on prioritisation and end-to-end prototyping apply directly to projects with no external structure. Skip it if you’ve already spent years inside a team — you’ll recognise most of it, though the estimation and trade-off communication bits still hold up.