~/$ mbaurin's blog

when your team tells you to slow down

last week during a code review session, one of my colleagues made a comment that stuck with me. "mathieu, maybe try coding a bit slower next time." not in a mean way, but in that gentle way that makes you realize something important.

i have been pushing code fast since i started this job. really fast. the kind of fast where you finish a feature, push it up, and immediately start thinking about the next thing. i thought this would make a good impression. i thought this meant i was the productive new guy.

turns out, productive and thoughtful are not the same thing.

the feedback that changed everything

it was not just one person. over the past month, different teammates have been giving me similar feedback in different ways:

at first, i was a bit defensive. i mean, my code works. tests pass. features ship. users are happy. i was delivering fast, making an impact. what more do you want?

but then i started paying attention to the code reviews i was getting. long threads of back and forth. questions about decisions i had made quickly. suggestions for approaches i had not considered.

the pattern became clear: i was optimizing for speed over clarity. for impressing people with my delivery pace instead of impressing them with my thinking.

the cost of wanting to impress

here is what happens when you try to make good impressions by shipping features fast: you make assumptions about user behavior that turn out wrong. you implement flows that work for the obvious use case but break in edge scenarios. you write endpoints that handle the happy path perfectly but crash when someone sends unexpected data.

the irony? instead of looking impressive, i was creating more work for everyone. my "fast" features were generating long code review threads. my teammates had to spend extra time explaining things i should have considered upfront.

i realized i was making the opposite impression i wanted. instead of "wow, this new guy ships fast," it was becoming "wow, this new guy needs a lot of guidance in code reviews."

learning to pause and question everything

so now i am trying something different. before i write any code, i sit with the problem for a bit longer. i ask myself:

but the real change is what happens after i write the code. now i review my own pull request multiple times before sending it. i go through every line. i question every decision, even the small ones.

why did i use this variable name? does this function do too many things? should this be extracted into a separate method? why did i choose this approach over that one?

i even question punctuation decisions. does this error message need a period? should this log statement end with an exclamation mark or stay neutral?

it sounds obsessive, but it works. by the time i send the pull request, i have already had most of the conversations with myself that my teammates would have had with me.

the paradox of slowing down

here is the thing nobody tells you: when you slow down your coding, you actually speed up your shipping. less time in code review. fewer questions about basic decisions. less back and forth explaining why i chose approach a over approach b.

my pull request descriptions are better now too. because i have already questioned every decision, i can explain my reasoning upfront. "i chose this pattern because..." "this handles the edge case where..." "i considered this alternative but..."

and most importantly: better impressions. instead of being the person who ships fast but needs lots of guidance, i am becoming the person who thinks things through.

i am still learning this. still catching myself rushing through implementations to hit some imaginary deadline. still having to remind myself that thoughtful code makes a better impression than fast code. but my teammates are noticing. the feedback is changing from "slow down" to "good thinking" to "nice approach."

turns out, the best way to impress people is not to move fast, but to move thoughtfully. even if it means questioning every comma.