7 Things Senior Developers Do That Juniors Think Are 'Lazy'
Source: Dev.to
Introduction
My senior colleague closes his laptop at 5 PM sharp—every single day.
When I was three months into my first job, I thought he just didn’t care about the work. I’d be sitting there at 7 PM, eyes burning, fixing a bug I introduced at 4:30 PM because I was too stubborn to step away. Meanwhile this guy was already home cooking dinner or whatever.
Six months in, I started paying attention. Not just to the “leaving‑at‑5” thing, but to everything else:
- The way he’d stare at a whiteboard for an hour before touching his keyboard.
- The way he’d kill features that took us weeks to spec out.
- The way he’d say “I don’t know” in meetings like it was completely normal.
It messed with my head. I thought senior developers were supposed to be the ones who knew everything and worked the longest hours. Turns out, almost everything I believed about being a “great” developer was backwards.
1. Predictable Schedule ≠ Laziness
“The most productive person on our team had the most predictable schedule. In at 9, out at 5. No exceptions.”
Meanwhile, I was pulling mini all‑nighters trying to prove myself. Staying late felt productive. It felt like dedication. I’d message the team Slack at 10 PM just so people could see I was online—real pathetic behavior looking back.
What I didn’t understand: my senior colleague got more done in his focused 8 hours than I did in my chaotic 12. He wasn’t checking Twitter between tasks. He wasn’t context‑switching between five things. He sat down, worked on one thing at a time, and when his brain was done, he went home.
The part that really got me? He almost never introduced bugs at the end of the day. I did. Constantly. Tired code is bad code, and bad code creates more work tomorrow. He understood that. I had to learn it by breaking things at 9 PM on a Thursday.
Leaving at 5 isn’t laziness. It’s a career strategy. Burnout doesn’t sneak up on you. It moves in slowly and then hits you all at once. The seniors have either seen it happen to someone else or lived through it themselves.
2. “I Don’t Know” Is a Strength
This one genuinely confused me at first. We’d be in a meeting, someone would ask a technical question, and my senior colleague would just say “I don’t know, let me look into that.” No hesitation. No faking it.
I would never have done that as a junior. If someone asked me about a technology I’d barely heard of, I’d nod along and then panic‑Google it under the table. The fear of looking incompetent was so strong that I’d rather pretend than admit ignorance.
Watching a senior developer say “I don’t know” taught me something: Nobody in the room lost respect for him. Actually the opposite. People trusted his answers more because they knew he wasn’t making stuff up. When he said something with confidence, everyone believed him, because they knew he’d tell them when he wasn’t sure.
There’s also a practical angle. Pretending you know something has a cost:
- You might make a decision based on wrong assumptions.
- You might waste two days going down the wrong path because you were too proud to ask.
“I don’t know” saves time. It saves everyone’s time.
I still catch myself wanting to fake it sometimes. Old habits. The difference is now I recognize it and force myself to just say it.
3. Small Pull Requests, Big Impact
During my first big project, I was cranking out code like it was a competition—hundreds of lines a day. I felt unstoppable. My pull requests were massive.
My senior colleague’s pull requests? Tiny. Embarrassingly small compared to mine. I remember thinking he must be slacking.
Then came code review.
- His small PRs got approved in minutes.
- My giant ones? Comments everywhere. Rewrites. Whole sections that needed to be deleted because they were solving problems that didn’t exist yet.
I’d spend a day writing code and then two days rewriting it.
The senior developer’s secret wasn’t writing faster. It was knowing what not to write. Every line of code is a liability. It needs to be maintained, tested, debugged, and understood by the next person. The fewer lines you ship, the fewer things can break.
He’d spend ten minutes thinking about whether a feature actually needed custom code or if there was an existing library or pattern that already solved it. Half the time, the answer was “we don’t need to build this at all.”
My proudest moment was when I deleted 400 lines from my own PR after a review. That was the day I started getting it.
4. Planning Is Real Work
I used to sit down and start typing immediately. Keyboard go brr. That was my whole approach to software development. Problem comes in, fingers start moving.
One day I walked past my senior colleague’s desk and he was just… sitting there. Notebook open. Drawing boxes and arrows. No IDE on screen. I passed by again 45 minutes later. Same thing. Boxes and arrows.
I thought he was procrastinating. Maybe planning a vacation. I don’t know.
That afternoon, he opened his laptop and wrote the solution in about 90 minutes—clean, working, well‑structured. The kind of code that makes you say “oh, obviously” when you read it.
I realized he wasn’t procrastinating. He was doing the actual hard part. The coding itself is the easy bit. Figuring out what to code, how pieces connect, where edge cases hide, what the system looks like six months from now when requirements change… that’s the real work.
Junior me confused typing speed with productivity. My fingers were always busy, but half my “coding time” was actually me figuring out what I was building while simultaneously building it. Which is like drawing a map while you’re already driving.
Now I keep a notebook next to my laptop. Sometimes I spend an entire morning just thinking and scribbling. It feels unproductive. The results say otherwise.
5. Saying No to Shiny Features
There was a planning meeting where someone proposed a really cool feature—genuinely interesting, technically fun to build. The whole team was excited. Lots of nodding.
My senior colleague said no.
(The story cuts off here, but the lesson is clear: not every cool idea is worth the cost.)
Takeaways
- Predictable work hours can be more productive than endless overtime.
- Admitting “I don’t know” builds trust and saves time.
- Small, focused pull requests are easier to review and maintain.
- Planning and design are essential; they’re not procrastination.
- Questioning shiny features protects the team from unnecessary work.
By observing a senior who left at 5 PM, I learned that quality, focus, and honesty outweigh sheer hours and bravado.
Lessons Learned from Senior Developers
The Meeting That Changed My Perspective
I was in a meeting where a senior developer asked a few tough questions:
- How many users would actually use this?
- What’s the maintenance cost?
- Does this delay the stuff we already promised?
- Is there a simpler version we could ship first?
By the end of his questions, the energy in the room shifted. The feature went from “obviously we should build this” to “hmm, maybe not right now.” Some people were annoyed—I was one of them. The feature would have been fun to work on.
Two months later, a different team at another company shipped something similar and it flopped. Users didn’t want it. Our senior had called it based on experience; he’d just seen enough “cool features” die in the wild to recognize the pattern.
“Saying yes to everything feels generous and ambitious. In practice, it’s how projects bloat and teams burn out chasing things that don’t matter.”
The seniors I’ve worked with treat their “no” like a super‑power. Every no protects a yes that actually counts.
My Own Struggle with Saying “Yes”
I’m still bad at this. When someone pitches an exciting idea, my instinct is to jump in and start working on it. That one experience destroyed a myth for me.
The Myth of the All‑Knowing Senior
I always assumed senior developers had everything memorized—like their brains were full of syntax and API references, and they could just reach in and pull out the right method signature for any situation.
Then I sat next to one for a week during pair programming. He:
- Googled “javascript array remove element” at least twice.
- Looked up CSS Flexbox properties.
- Had a Stack Overflow tab open basically all day.
I was genuinely shocked. This guy had been coding for 12 years and was searching for the same stuff I search for?
Yes. Memorizing syntax is a waste of brain space. That’s what documentation is for. What he had memorized was the important stuff:
- System design patterns
- Debugging strategies
- How to break a problem into smaller problems
- When to use which data structure
- How to read error messages and trace them back to the root cause
The stuff you Google doesn’t matter. It really doesn’t. “How to center a div” has been Googled billions of times and nobody’s career suffered because of it. What matters is knowing that you need to center a div, why, and how it fits into the larger layout. That’s the part that takes years to develop.
I stopped feeling embarrassed about Googling after that week. It freed up a lot of mental energy I was wasting on feeling dumb.
Hero Culture vs. Preventive Work
Early in my career, I heard a story about a developer who stayed up 48 hours straight to fix a production outage, saved the company, and got a standing ovation. I thought: that’s what I want to be—the hero.
My senior colleague had a very different take:
“If one person needs to stay up 48 hours to fix a system, the system is broken. Celebrate the fix, sure. Then ask why it happened and make sure nobody ever has to do that again.”
Hero culture rewards the wrong things. It celebrates the person who pulls an all‑nighter to fix a fire, not the person who made sure the fire couldn’t start. The developer who quietly writes reliable code, sets up monitoring, and documents the tricky parts will never get a standing ovation, yet that person is the reason the outage never happens in the first place.
The seniors I’ve watched don’t want to be heroes. They want to be unnecessary. Their idea of success is going on vacation for two weeks and having nothing catch fire while they’re gone.
Redefining “Senior”
I used to think “senior” meant being the person everyone depends on. Turns out it means building things so well that nobody needs you for emergencies.
Everything I thought made a great developer was wrong:
- Long hours
- Big PRs
- Memorized syntax
- Saying yes to everything
The seniors I admire are quieter and less “busy” than the juniors around them. They’re not working less; they just know where to put the effort. They’ve figured out, usually the hard way, that looking productive and being productive are completely different things.
My Current Situation
I’m 19, have been doing this professionally for under a year, and I don’t have it all figured out yet. I still:
- Stay late sometimes
- Write too much code
- Get excited about features we probably shouldn’t build
The difference is I’m watching. The people worth watching aren’t the loudest or busiest in the room.
Want More?
If you found this useful, I share more stuff like this on Telegram and sell developer toolkits on Boosty.