"We're looking for a Senior PHP Developer."
"Are you a senior or a junior?"
"How many senior developers does your company have?"
These and similar questions come to appear when you're looking for a job. The IT market says it needs more senior developers.
I think there is more than enough. What we need are senior codebases.
Let's say we have 2 companies.
Company A has:
Company B has:
Which company would you pick as a better place for your next full-time work?
I have no idea. Fortunately, Bruce Lee is here to help us:
"It's like a finger pointing away to the moon.
Don't concentrate on the finger or you will miss all that heavenly glory."
The number of developers is not that relevant, neither is the number of developers by their skill.
It's better to have 2 developers instead of 1, so that they give each other feedback and grow more robust codebase. It's not such a difference if it's 3+.
The junior/senior game is an essential part of the manipulative process during hiring in companies around me. I'll describe a model hiring situation, that was shared by my friends who were looking for a job, and that I can relate to also from my personal experience.
John is looking for a job. He found both companies A and B. After 5 years in the same environment, where he has became an expert, he's looking for somebody to learn from - a skilled senior developer who's gonna be willing to share their experience.
John says that he's more attracted to company B, which has 3 senior developers, compared to a company with just 1. For him, it's a clear choice. He signs a full-time contract with a three-month trial period.
Now let's pause. What misconceptions have you spotted? Here are 3:
All 4 of those are false.
The story continues. During the first week John only learns to run the application and to work with it. It takes some time, but he thinks it's healthy because it's a huge project.
The second week he realizes the senior developers don't have time to teach him or share any of their experience because they're busy fixing bugs happening in the codebase. All 3 of them!
Third week he thinks about the meaning of the word senior in this company. It's not as much about experience or teaching, but rather about being in the company for many years and understanding the codebase better than anybody else.
It's not about teaching, experience, nor programming skills. John's expectations have not been met. John is disappointed. But who's to blame? Should he blame himself for his bad decision?
The company also had expectations. John told them he's a senior developer, but his work during the 1st and 2nd week was very slow. Company owners feel like John is lying to them just to get more money. Their expectations have not been met. They're disappointed too... But who's to blame? Should they blame themselves for hiring him?
We talked about junior, senior developers, teaching, experience, expectations, humans... Everything was so lovely and shiny at the start. We had a great team of great developers that were joined by another great developer.
Where did it go wrong? What have we missed?
People can make you feel better, and coffee might be good, the office might be on the highest floor with a beautiful and sunny view, your salary can be the highest you've ever seen. *But how does it relate to your everyday work?
You're not going to enjoy a coffee while watching over your city from the glass-floor view all day, you're going to work with the codebase.
That's why before I say I'll cooperate with any company, I need to see the codebase first.
Instead of asking 3 questions at the top of this post, we should focus on:
The most companies I met have junior codebases, but they look for senior developers. That's wrong and will lead mostly to John's story with its unhappy ending.
Junior developers can work with junior codebase because they're not being slowed down by codebase that is lower than their skill.
When senior developers are hired to orientate in a terrible codebase, they can't apply their experience with clean code, and they can't build a robust application with their high standards. They have to dig through the legacy code and try to fix leaking pipes.
Monkey see, monkey doo.
That's how our brain works; we're just like monkeys. We come to a new project, and we instinctively copy patterns we see. If there are broken windows all over the code, we make more broken windows.
Some people join your team, some people stay for a long time enough to be called seniors, and some will leave. The codebase remains as long as your company exists. That's why it deserves the best treatment.
People learn from your codebase, it's their best teacher.
Let's say you have 2 teachers in your life.
Teacher A:
Teacher B:
What teacher would you pick?
Take care of your codebase, and your codebase will take care of you when you're older.
Happy coding!
Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors.
I'd really appreciate it!
