Are you a great developer?
Oh, you are a senior, tech lead, principal, architect… it does not matter. Are you sure you are a great developer, or even good?
Let me save you some time: if you fall under one of these categories, there is a high probability you are neither great nor good.
• You have only worked with one codebase.
• You have used one language your entire career.
• You do not change the architecture or check if it still makes sense.
• You think the system is “bad” and your code is not the issue.
• Nobody discusses issues or ideas with you anymore.
• You control everything that goes into the project.
These are generic signs, but in most cases they are red flags that you have stopped growing.
You have only worked with one codebase
Being loyal to a company or startup is great, but that does not mean you know the best or even the correct way to go. It just means you are loyal, and it looks great with the participation trophy saying “Senior Engineer Level 3 at Never Ending Name AI.”
Most developers who stay stuck for a long time in a specific company lose track of how technology evolves. This is a reality. You may like it or not, but you can avoid this even if you stay in a company for a long time.
You can follow new updates in empty projects, try things outside of the work environment, fight the very things you think are right.
If you already do that but you have been somewhere for a long time, there is another point you should look at to understand if you are in the right place. Do you feel that everything that changes in that project is easy for you? You do not feel challenged? Well, there is some bad news for you.
This means you are so confident and comfortable that you are probably making obvious mistakes, but nobody challenges you. At that point, it is not a question of skill; it is a question of who you are as a person.
Great developers challenge every file, line, module, package, library, or structure, even if it is the same one used ten years ago.
You have used one language all career
What is wrong with this? Very simple.
Developers who only use one language their entire career make a simple but costly mistake: they build things around the limitations of the language.
So, if in Android Java garbage collection is an issue, developers start building things to avoid this issue. What happens then?
Try changing an architectural decision in a large application, and tell me if you can find the issue.
Of course you will get stuck in code that does not make sense, with singletons inside singletons and interfaces everywhere because at the time that was the way to go.
Now Kotlin is here, and all that code is just dead weight you must support. If you do not support it, everything breaks. Because Steve decided it was a great idea to make a core module with 25 abstractions of BaseModel, one for each working day of the month, plus three for the extra days you will be on call fixing this at 4 a.m.
Java and Kotlin might not be the perfect example, but it is still valid with the changes introduced in Kotlin.
You do not change architecture or checks if it still makes sense
During the development cycle of any software that is used, there will come a time when the architecture stops making sense.
Maybe because the number of users scaled, because the number of features increased, or because of bad decisions accumulated over the years.
Welcome to the practice of development. If you never check if it still makes sense, if it still should be that way, I have bad news: you are not a great developer.
Over time, you should think about whether it still makes sense, whether the folder structure still makes sense, etc. Breaking news: 90% of the time, after some time, it does not.
Get Pedro Capela’s stories in your inbox
Join Medium for free to get updates from this writer.
Being a great developer means questioning your own decisions and being able to understand issues that you caused. When you do that, congratulations, you are starting to get somewhere.
You think the system is “bad” and your code is not the issue
How are you able to think that the system is wrong and your code is not the issue?
I am not saying this is impossible, but still how?
Do you understand that most OS systems have at least more than 100 developers during their lifecycle, and that is a very small OS. Something like Android has 1000+. Do you think you are so good that the system is the issue? Really?
I would double-check ten times if my code is not the issue, or if the way I built a system is the issue. Because I can tell you right away: unless you are doing some dark magic in your code, it is not your three views sharing data that are the issue. It is most likely your bad architecture that you decided to follow just to avoid the recommended one provided for the OS your app should run on.
But, just saying…
Nobody discusses issues or ideas with you anymore
Here is the personal side of things. Let me give you a bit of a reality check. Do you know the difference between artificial intelligence and a person? One can understand others; the other can only understand instructions.
If people avoid you, do not want to discuss anything with you, do not want to understand next steps, or even try to get a simple idea across to you, let me tell you this: you can be a great coder and an instructions follower, but you are a horrible developer.
Developers need to be great people who listen and understand issues, and more importantly, contribute in a way that helps others get to the next level.
Let me give you another small reality check: see all the docs you read? See all the languages you use? See all the libraries you import that have docs? Notice how all of them have certain things in common?
Yes, they have different ideas inside, they share common principles, they achieve great results. The reason? People other developers who understand the responsibility of shipping a library, and know it should be simple and easy to use, should have docs, and everything else.
Without people, you will not go anywhere.
There will come a time and a place when you will not evolve. At that point, you can be brave and understand the need for people and ideas, or you can continue to think you are a 10x developer but still have the capacity of building only a calculator. Still, I would check for memory leaks just in case, and make sure you picked the right architecture (Apple, I see you in macOS 26, by the way).
You control everything that goes into the project
So you are important for this project. Great. Stop micromanaging code, and most importantly, stop micromanaging developers.
If an MR is good to go and you are not the reviewer, do not go there. There is absolutely zero need. You are not making the project better; you are just thinking that adding an extra line whatever file is going to fix the mentality and the bad architecture you decided to follow ten years ago, and now everyone needs six months to understand the code.
Let me give you a quick and easy response to that: no.
Great developers understand that the code of the app is company property, and they need to do the best they can to get it to a good place, where evolution is possible and developer experience is easy and pleasant. New joiners should interact with the code easily and simply.
Control shows that you are thinking of this app as your child. Well, it’s not.
This is not your child. This class you built in 1999 is not your perfect and beautiful child; it is just a class that probably needs a big refactor and is probably missing 100 unit tests.
So just go and make the class better. Next time, understand that software is not your child. It is your job, and you should do it calmly, with priority, for the future and for the present, to make it the best possible.
This is not art. This is software.
The end
If you read this and feel offended, great. It means you have work to do. Go build nice software, for the future, for the next one.
Respect the next one as much as you expect to be respected. Instead of saying no, teach. Be better. That is the expectation that is on you.
