5 Lessons from My Team's Architect That Helped Me Become a Senior Developer
25 Oct 2025 #career #codingI used to be a problematic team member.
I delivered my tasks late. Sometimes I worked late fixing bugs and finishing my tasks on the sprint’s final day. That was in my second job.
My previous job was in a non-tech company. I wasn’t used to Scrum, deadlines, and working as part of a development team. In this job, I had to work hard just to keep up.
After a year or two, I had the chance of working next to the team’s architect. Maybe that was part of a performance improvement plan and nobody told me. Who knows?
I learned a lot from my team’s architect. He became my mentor, although I never explicitly asked him to. Here are 5 lessons I’ve learned from him:
#1. Read for 1 hour.
My mentor spent ~1 hour after work going through blogs, Reddit, Hacker News, and other news sites. Often, he arrived at work saying, “Hey, check out what I found yesterday.”
Apart from staying up to date, there was a real reason behind that habit.
Sometimes, the CEO, who used to be a coder, arrived at the office asking my mentor, “Hey, did you read about…?”
I remember my mentor telling us, “It can’t be that, being the architect, the CEO asks me about something and I don’t know how to answer.”
You don’t have to know it all, but always find time to learn.
#2. Struggle first.
Apart from being the architect, my mentor was the “team enabler.”
He told us, “If you’re still stuck after one hour, come back and ask for help.” He didn’t answer immediately, he made us struggle first, so the answers would stick.
That’s the same trick I use when I help others.
#3. Read code.
No coding class taught me the value of reading code.
My mentor was the one who taught me. He read the source code of almost all libraries and tools we used. That’s how he knew about their hidden features or undocumented behavior.
Reading code was how my mentor learned from the best.
#4. Simplify problems.
Break down coding problems into one-liners, just like movie plots.
Instead of “a complex async system,” say “a queue and a processor.” It helps you present and explain complex ideas, especially to non-tech people. Helpful to keep the larger picture when coding too.
#5. Don’t be a one-trick pony.
I remember my mentor saying, “Imagine an architect who builds the same house over and over.”
For him, every project was a chance of learning. Don’t build the same thing twice. Of course, there’s nuance here. Don’t suffer from shiny object syndrome either.
After more than 5 years of working with my mentor, I’ve kept the habit of setting aside time to read. I use idle moments to scan headlines and see what’s going on in the tech world.
My mentors taught me lessons that college or bootcamps don’t teach, like how to ask for help, read code, and say no politely. I’ve included some of those lessons in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.
That’s me passing on the lessons my mentors taught me and the ones I’ve learned on my own. That book is my way of mentoring you to help you to grow and code like a pro.