And how to be one of them
I worked with so many developers for more than fifteen years of my life and still working with a bunch of them. I have seen junior developers with twenty (yes, 20) years of experience and senior developers with only five years in the industry.
When I was just starting, I wondered what differentiates the senior developers from others.
Over the years, I became a senior developer, then became an entrepreneur, an engineering manager, and a CTO. Here’s what I learned about what makes a senior developer senior.
I’ll also give tips along the way for junior developers to help their way up.
Development starts before coding. Actually, if you don’t manage the part before coding well enough, you may have a tough time crafting good software.
As a developer, some people will always give you some requirements about the projects you’re working on.
If the requirements are reasonable and clear enough, it’s a good thing. But, to be honest, it’s rare. So, you probably won’t have great requirements.
This may have different reasons. But I saw two main reasons: 1- Business people don’t know what they want in software terms 2- Software people procrastinate to write reasonable requirements.
The solution is actually pretty easy. You sit down with the requirements and the people who wrote them and ask questions. It may take some time, but it will take longer if you don’t do this in advance.
The questions you should ask may vary from task to task, but the main idea is the following: You’ll need to understand what exactly happens and when. Remember that you’ll also need the failing cases, not only what happens when everything goes right.
The framework to achieve excellent software design will be the hardest process. After you have great requirements, it’s easier to have an inclusive software design. You’ll always have room to improve yourself on this topic.
As Uncle Bob states, “A good architect maximizes the number of decisions not made.”
You’ll also be responsible for changing the software along the way, so you better design it to welcome changes as much as possible.
Designing great software is a challenging process, and I suggest you learn as much as you can about it. It’s a good starting point for improving your organization and your software in general. Because when you design great software, everyone you work with will notice it, and they’ll try to act like you.
However, designing good software is also enough in your way to being a great software designer. Don’t quit improving yourself on that; I can’t emphasize this enough.
You’ll see principles here and there when you want to craft great software. Principles like DRY (Don’t Repeat Yourself) and SOLID. Let me explain SOLID principles with examples for you to understand why they’re needed. I also have analogies for you.
1- S: Single Responsibility Principle
Definition: A class should have only one reason to change.
Explanation: When you have something, it has to have only one job. If you have a thing that calculates, it shouldn’t also present the thing it calculates. Everything should have their own job, and only one job.
A: You should do this too!
2- O: Open-Closed Principle
Definition: Entities should be open for extension but closed for modification.
Explanation: You can extend the functionality of something you have in another place, but you shouldn’t need to modify it. So it should be a small thing that does a single thing so well that you won’t need to modify it.
A: You can fly in this new suit!
A: Also, you can be invisible if you cut your nails!
3- L: Liskov Substitution Principle
Definition (Simplified): You should be able to replace subclasses with superclasses.
Explanation: You’ll subclass so many classes. To keep the codebase sane enough, you should use the superclasses when you need to pass something. This way, you can use whatever subclass you want with the concrete implementation. So you design accordingly.
A: Is this you, your brother, or your father in this picture?
B: It doesn’t matter. We all share the same blood.
4- I: Interface Segregation Principle
Definition (Simplified): You wouldn’t have to implement what you won’t use.
Explanation: You’ll use interfaces (or protocols), and your classes will implement those interfaces. Let those interfaces be as small as possible, so no one would implement an unnecessary thing.
A: (Soccer) You’ll pass, I’ll shoot!
B: Go, team!
5- Dependency Inversion Principle
Definition: Entities must depend on abstractions, not concretions.
Explanation: Depend on interfaces (or protocols). Pass interfaces to constructors whenever possible. If not, make it possible.
A: I just love the idea of loving you.
B: How about I make? this dance move?
A: Hard to embrace, but still ok.
You should still learn to see when you need to use these principles in your codebase. It’s about trial and error, which improves pattern recognition, also called experience.
Yes, I have to say that. You should write tests. To be a senior developer, you don’t have to follow test-driven development (TDD) principles, but it’s a good practice anyway.
The best side-effect of TDD is, it eliminates debugging almost completely. If done right, it gives you confidence so you can have more frequent releases and peace of mind (yes, that’s actually possible).
There are too many details involved in all the points above. However, I tried to give you a box to think inside and out. The thing is, if you are curious and patient, you can be a senior developer in record time. Experience is just pattern recognition in general, the same as almost everything in life. The key point is which patterns you get used to, so choose wisely.
With that, I want you to know that I’ll write as much as I can and publish them here. So, if you would like to follow me, I’d be honored. See you next time.