Business People Cannot Tell a Good Developer From a Bad Developer
Topic: Martha's Diary
Business people cannot tell a good software developer from a bad software developer because they look the same from the outside.
All developers have the same attributes. We have social profiles, portfolio records, a bunch of technologies we are supposed to be good at.
We all have a picture in the profile. Some developers have a beard. I don’t have one, so I may look less experienced.
It’s a wonder how different the impact made by different developers can be!
Some of us help businesses to grow. Often, my customers start feeling so successful that they forget about problems technologies can bring into their life. Sometimes they even forget about me.
If they do so, other developers capture my place. And if that happens, the customer will remember all problems one could have with a technology.
My product owner has been hiring people for a year now.
The first one was John. A reputable developer who spoke with dignity. I remember his first phrase on a call. The PO introduced him and said, ‘John, say a few words about yourself’. John said, ‘Well, a few words about myself - usually I am not very good at that’. And then spoke for thirty minutes straight.
Over the next two months he did not commit any code to the repository. Well, he tried once, but the code contained a migration that would wipe out one of the existing tables, so another girl and I declined it within minutes. After that, John never tried committing any code again.
But he always had a good report prepared for a call. The most informative part of such a report was ‘still learning how it works’ and ‘hope to make a pull request this week’.
John was fired two months later and did not express any frustration. I think he considered his participation successful and added a record to his resume.
When a new guy came, we understood that John had been super cool and harmless.
The new guy’s name was Doug and he would make commits straight to the master branch without sending the code for review.
Doug had a great resume with the whole lot of technologies listed. Doug called himself a senior. He had a beard and a bald head. He looked seasoned and mature.
His code was just some random code written somewhere near the module the task was about.
The code would cause the application to break randomly, but that did not bother Doug.
Surprisingly, it did not bother the PO either. What did bother him was my weak attempts to protest. I got scolded for that multiple times.
Doug had a special permission to commit his code without getting it approved by the others - he was a senior. I was a conflictive girl.
Doug’s input was a permanent source of bugs that the rest of the team - five developers - had to fix.
It has been six months since Doug joined the team. The software works because five people support their main “senior”. That is a waste of time, but the PO is content with the overall team’s efficiency.
Just a week ago, we got another senior developer. His name is Jeremy and he is quiet and nice.
He doesn’t have a beard. He doesn’t brag and clashes with no one.
He follows the common procedure and submits the code for a review.
His code is as good as Doug’s.
Oh, my God!
Now we are fixing his bugs too. Sometimes I wonder what will happen if I and a couple of others quit the project and leave all the tasks to Doug and Jeremy.
Maybe nothing. Who knows how many users will feel bad if the system starts logging everyone out every 15 minutes? We have over 100,000 users in the system and not every one of them is there by choice. They are someone’s employees too.
Maybe something will happen over time. The system will start falling apart and the companies paying for their accounts will start asking questions, reducing their payment plans, and moving to other systems.
Why does it have to happen? Why are five people struggling with strange people who don’t know how to write simple scripts?
I don’t know. Maybe the product owner has his own reasons. Like, he needs a presentable inhouse team that he can show to investors.
Or more likely, he is just a dreamer living in an imaginary world where these senior developers are really talented and knowledgeable.
One needs a special qualification to see the difference between a good developer and a bad one - especially in a team where good engineers adjust their daily routine to help bad engineers. The plane stays on course while the balance is supported.
Let’s imagine that our PO actually wanted to filter out poor devs before hiring them? What could he do taking into account his lack of technical knowledge?
Maybe he could ask us, people who proved their skills. He could rely on those engineers who proved to be valuable.
Come on, what am I talking about? Nobody does that.
Every project owner believes in his or her communication skills and intuition more than in software developers that work for hire.
They believe in themselves more than in you and me.
Even if we have been showing unordinary results throughout years of collaboration.
Read my post about how smart people make smart mistakes.