Freelance Project With a Senior Developer
Been coding on my own for about a year and a half. Tutorials, YouTube videos, a few small personal projects I half-finished, one Udemy course I paid for and abandoned around week three. Thought I was doing alright.Then a college connection pulled me into a freelance project with a senior developer he knew. Six weeks, one actual paying client, one real deadline. By the end of week two something had shifted in how I understood the whole thing. Hard to explain precisely. I'll try anyway.
He didn't open his laptop for the first 30 minutes and it threw me off
First client call. I had my editor open before the call even started.
He just asked questions. Not technical ones. Things like who's going to look after this once we're done, if something breaks on a Sunday night does the client fix it herself or wait until Monday, what parts of this might she want to change down the line.
I kept waiting for us to get to the actual work.
Those 30 minutes ended up saving us probably four or five days of building. Two features we'd have started on immediately turned out to be things she didn't really need once she talked through them out loud. We found that out from the questions, not from building halfway into something and realising.
My whole approach until that point had been to understand what's needed, open the editor, start typing. It genuinely didn't occur to me there was a step before that. Still a bit embarrassing to think about.
His code looked nothing like what I expected
I assumed a senior developer's code would be impressive in a technical way, the kind of thing that made mine look like a first draft.
It was simpler. Noticeably simpler.
Short functions, variable names so obvious they felt almost too casual, comments that skipped over what a line did and went straight to why it was written that particular way.
At some point I asked about a pattern I'd picked up from a tutorial, one I'd been using because it seemed like the right approach. He looked at it for a second then said he wouldn't remember what that meant in six months, and neither would I.
I'd been writing code to look competent to some imaginary future reader. He was writing it for a real future version of himself who'd have forgotten the context entirely and needed to figure it out quickly. That reframe took a while to fully settle in. I kept turning it over for days after.
Production bug, Wednesday, around 7pm
Client texted. Something wasn't working. People were trying to use it.
I had five tabs open within about thirty seconds. Started typing into Google before I'd finished reading the error message properly. Wrote the same console.log probably three times and deleted it each time without actually running it.
He got up and made tea.
Came back, opened the error log, read through it without touching anything else first. Just read it like it was a document worth understanding before responding to.
Found it in twelve minutes. A timezone issue, the specific kind that only shows up when a user in a different region does a particular thing at a particular time of day, something that would never appear in local testing.
I keep thinking about those twelve minutes. My hands were genuinely a bit shaky during it. His weren't. He moved through the whole thing like someone reading a report, not someone trying to stop a fire. Whatever changed in how I handle things going wrong since then came from watching that, not from anything I've studied.
The first time he reviewed my code
Not a pleasant experience, though not for the reason I'd been bracing for.
The feedback wasn't vague or discouraging. It was very specific and that was somehow harder to sit with. He'd ask what the function does if someone passes in an empty string, or point out that it was doing three separate jobs and ask which one it was actually meant to be responsible for.
I'd been reviewing my own code for over a year and I realised I'd been doing something closer to just checking that it ran. Whether a stranger could follow the logic, whether it handled inputs I hadn't considered, whether future me would understand it with no memory of writing it, none of that was in my process.
Took a few days to stop feeling defensive about it. The gap between working code and code that actually holds up is obvious once someone shows it to you in your own files. Before that it's just a thing people say.
A few things I'm still turning over
He answered most of my questions with a question back. Annoying at first, then I figured out he was trying to gauge what I already understood before deciding where to start. Made the actual answers land better once they came.
Near the end, week five or thereabouts, he mentioned that getting from junior to mid-level isn't mostly about picking up new tools. It's closer to learning what to ask before you start writing anything.
Wrote it in my notes app. Still sitting there between a grocery list and a phone number I saved from somewhere and have no memory of.
Six weeks later
I know considerably more about timezone edge cases than I ever planned to.
Other things are harder to measure. I spend a few minutes at the start of anything new just asking myself questions before opening the editor. I try to read code I've written like someone encountering it cold, no context, no memory of the decisions behind it. When something breaks I try to properly read the error before reacting to it. That one still slips when I'm rushing or it's late.
Most of what shifted over those six weeks didn't come from anything written down anywhere. It came from watching one person work through real problems in real time while I was sitting next to them. That's a surprisingly difficult thing to access any other way. If you get the chance, even a short project, even unpaid, it's probably worth more than you'd expect going in.
"You can't Google your way to good judgment."
0 Comments