Better to be a mature developer than a senior developer, senior software engineer and all other senior titles
I keep hearing all sorts of things about being a senior developer, senior software engineer and so on. I especially hear how people from new people to this field how they want to become a senior developer as soon as possible and how having "senior" in your title means everything. Or I hear a lot when a new team is formed that everyone wants as many "senior" developers on that team as possible.
Fortunately, I learned these things mostly from other people's experiences. And I will be honest here, a lot of the things I will mention next in the post, I am guilty of too or used to be.
In general everyone puts accent on being a "senior" something that knows a lot of technical things which impress other people but not many people put enough emphasis on being a grown up adult, a mature developer. Being a mature developer involves a lot of things, having technical knowledge is just a part of them. But it requires other skills and a specific personality too.
Firstly, I see a lot of people more or less experienced in this field that think they are right almost every time. When they have an issue or a bug, it never is according to them the fault of their own code that they wrote. There is always something outside of their code which is at fault and not their code. This includes things like: someone else code which he used or an external 3rd party library which he used. But it's never their fault. This causes a lot of trouble for them.
They are so sure of their own code that they don't test it properly, because "Duh!", it's perfect, it neer crashes. Which is far from the case a lot of times. They also implicitly write fewer tests and unit test for the aforementioned reason. I admit that I was guilty of this in the past too but I have learned and I am still learning to overcome this.
And when they are debating how to implement something with their colleagues, their are so sure of their own idea, that they stop even listening and acknowledging other people's ideas and points of view. Of course, their ideas are not perfect, sometimes far for perfect. Now imagine what the rest of the has to deal with trying to convince him. Sometimes, they have to actually implement his idea, show then the result to him how bad it works and then he will change his mind. And even if you do, sometimes he can react badly afterwards like being even more stubborn.
Secondly, sometimes developers don't know when to take responsibility for something that is their own fault. A lot of times it's now even that obvious that they are also responsible for a bad situation. But another person can get into trouble for the mess and issues that they cause.
One of the cases that I sometimes run into goes like this. You have to explain something to another colleague, like a feature he is working on. But the thing is that he doesn't know some of the technologies and principles used to create that feature. And some of those technologies have 10 pages or more of documentation to understand and use properly. So in order to make your colleague understand what does feature does, you have to explain that complicated technology that you used. If he is an adult person, he will have patience and becomes aware of the fact that he has a lot more to learn that he thinks in order to understand that feature without passing the blame on you for not having the skill to explain things to other people. On the other hand if he is immature, he can pass the blame on you, that you don't know how to explain instead of admitting that he doesn't know some important things.
Or another scenario that I see all too often happen is that a developer sees a complicated piece of code and immediately blames the developer who wrote it for being so complicated. But a lot of times the requirements and the clients wants the application to do something complicated which translates directly into complicated code. In this case, it's the initial developers fault too for having trouble understanding that piece of code, because he doesn't know the requirement for that feature and what it should do.
And there are many more cases when developers don't assume responsibility properly for something.
Thirdly, mature developers have a healthy does of skepticism and doubts about anything, which includes things like their own code or other new "hot" emerging technologies, whereas more immature developers are more gullible and believe that almost every new emerging technology is better that what they currently use. A lot of times, this isn't the case and it has been proven time and time again in the history of software development. Like for example, when NoSql databases emerged, everyone went crazy for them and thought they were better that normal relational databases for almost every case.
Except that it's not like that. If you need to operations on records stored in the database that involve relating many records in the database to each other, they good luck trying to do this with a NoSql database because you can't relate things on it like you can do on a normal sql database.
Or another thing that emerged in the past decade, is microservices. Everyone was talking about how they solved almost any problem, about how the old way of doing things with big applications is very bad. But obviously that is not the case. Having worked with microservices a bit, they involved more work sometimes that developing a normal big application. You need to spend time developing the glue that links all those microservices together. This means things like creating rest clients for microservices so that another user can call and consume that service. This glue can also have its own set of bugs too. Also, you have to be more careful so that feature creep doesn't make some services much more bigger than they should be, when they stop being "micro". If this happens, it's much more harder to refactor and split that service, especially if they are backed by a database because you might need to split that one too.
Sometimes, developers trust a new technology so much, that they stop studying it properly in depth with it's list of issues and pitfalls. And they rush as soon as possible to implement something with it but they don't to it properly like the new technology was meant to be used.
Fourthly, sometimes developers lack the training and ability to read and properly understand technical documentation. Some developers are ever averse against reading documentation thinking they will was a lot of time. So when they need to use a method or something from a framework they can get stuck on it for some reason, like an exception that is thrown by that library. But when they see the documentation they get lazy, tired or scared or just lack the experience to read and understand it. So they waste a couple of day randomly trying to change the parameters to that method or the way they use that library with no avail when they could have read 50 lines from the documentation about it and solved that problem in one hour.
A mature developer should be used to reading documentation, it should be second nature to him so that a lot of times he doesn't need to know exactly how to use a library or technology. But he has enough knowledge and experience reading documentation, that with a 20 minutes read he can use that technology easily.
Fifthly, a lot of developers work in the same company and on the same project or related projects for so long that he starts to be in his own bubble, isolated from the rest of the world.. Or he just ignores all the other things even when he changes companies just focusing on his own thing, not even trying to look at other technologies or ways to do things.
This can especially seen during interviews, when you are interviewed by someone, and he expected everyone to know and have experience with what he works because in his own vision those are the only good and real things. All the other things are bad or sometimes even beneath him. Sometimes this lead to some downright arrogant and spoiled brat like attitude during the interviews. This can happen on both ends of the interview.
Or during normal work, this can be seen when a developer has a few solutions that he thinks are perfect all the time which then are forcefully implemented in situations where they are not needed and are actually contraindicated.
Sometimes entire companies live in this bubble, especially older companies that started to use the best technologies that were available at the time they were founded but since then have become obsolete. I actually ran into this recently, when I was involved to partially migrate a very old and big project to new technologies. I didn't work that much on that project but I had enough time to notice this. And when you need to interview with these companies, sometimes they will automatically have a bad impression of you because you see and do things differently from them. When an entire company lives in a bubble, its even harder for its employed developers to notice the bubble that hey are living in.
And sometimes, it might be that just a team or some teams from a company live inside a bubble. But it's pretty much the same case as I mentioned above.
Finally, there are many more things to mention here but it's already a pretty big post. And for sure some of these things also apply to me too and I am learning to get rid of these bad habits.
Fortunately, I learned these things mostly from other people's experiences. And I will be honest here, a lot of the things I will mention next in the post, I am guilty of too or used to be.
In general everyone puts accent on being a "senior" something that knows a lot of technical things which impress other people but not many people put enough emphasis on being a grown up adult, a mature developer. Being a mature developer involves a lot of things, having technical knowledge is just a part of them. But it requires other skills and a specific personality too.
Firstly, I see a lot of people more or less experienced in this field that think they are right almost every time. When they have an issue or a bug, it never is according to them the fault of their own code that they wrote. There is always something outside of their code which is at fault and not their code. This includes things like: someone else code which he used or an external 3rd party library which he used. But it's never their fault. This causes a lot of trouble for them.
They are so sure of their own code that they don't test it properly, because "Duh!", it's perfect, it neer crashes. Which is far from the case a lot of times. They also implicitly write fewer tests and unit test for the aforementioned reason. I admit that I was guilty of this in the past too but I have learned and I am still learning to overcome this.
And when they are debating how to implement something with their colleagues, their are so sure of their own idea, that they stop even listening and acknowledging other people's ideas and points of view. Of course, their ideas are not perfect, sometimes far for perfect. Now imagine what the rest of the has to deal with trying to convince him. Sometimes, they have to actually implement his idea, show then the result to him how bad it works and then he will change his mind. And even if you do, sometimes he can react badly afterwards like being even more stubborn.
Secondly, sometimes developers don't know when to take responsibility for something that is their own fault. A lot of times it's now even that obvious that they are also responsible for a bad situation. But another person can get into trouble for the mess and issues that they cause.
One of the cases that I sometimes run into goes like this. You have to explain something to another colleague, like a feature he is working on. But the thing is that he doesn't know some of the technologies and principles used to create that feature. And some of those technologies have 10 pages or more of documentation to understand and use properly. So in order to make your colleague understand what does feature does, you have to explain that complicated technology that you used. If he is an adult person, he will have patience and becomes aware of the fact that he has a lot more to learn that he thinks in order to understand that feature without passing the blame on you for not having the skill to explain things to other people. On the other hand if he is immature, he can pass the blame on you, that you don't know how to explain instead of admitting that he doesn't know some important things.
Or another scenario that I see all too often happen is that a developer sees a complicated piece of code and immediately blames the developer who wrote it for being so complicated. But a lot of times the requirements and the clients wants the application to do something complicated which translates directly into complicated code. In this case, it's the initial developers fault too for having trouble understanding that piece of code, because he doesn't know the requirement for that feature and what it should do.
And there are many more cases when developers don't assume responsibility properly for something.
Thirdly, mature developers have a healthy does of skepticism and doubts about anything, which includes things like their own code or other new "hot" emerging technologies, whereas more immature developers are more gullible and believe that almost every new emerging technology is better that what they currently use. A lot of times, this isn't the case and it has been proven time and time again in the history of software development. Like for example, when NoSql databases emerged, everyone went crazy for them and thought they were better that normal relational databases for almost every case.
Except that it's not like that. If you need to operations on records stored in the database that involve relating many records in the database to each other, they good luck trying to do this with a NoSql database because you can't relate things on it like you can do on a normal sql database.
Or another thing that emerged in the past decade, is microservices. Everyone was talking about how they solved almost any problem, about how the old way of doing things with big applications is very bad. But obviously that is not the case. Having worked with microservices a bit, they involved more work sometimes that developing a normal big application. You need to spend time developing the glue that links all those microservices together. This means things like creating rest clients for microservices so that another user can call and consume that service. This glue can also have its own set of bugs too. Also, you have to be more careful so that feature creep doesn't make some services much more bigger than they should be, when they stop being "micro". If this happens, it's much more harder to refactor and split that service, especially if they are backed by a database because you might need to split that one too.
Sometimes, developers trust a new technology so much, that they stop studying it properly in depth with it's list of issues and pitfalls. And they rush as soon as possible to implement something with it but they don't to it properly like the new technology was meant to be used.
Fourthly, sometimes developers lack the training and ability to read and properly understand technical documentation. Some developers are ever averse against reading documentation thinking they will was a lot of time. So when they need to use a method or something from a framework they can get stuck on it for some reason, like an exception that is thrown by that library. But when they see the documentation they get lazy, tired or scared or just lack the experience to read and understand it. So they waste a couple of day randomly trying to change the parameters to that method or the way they use that library with no avail when they could have read 50 lines from the documentation about it and solved that problem in one hour.
A mature developer should be used to reading documentation, it should be second nature to him so that a lot of times he doesn't need to know exactly how to use a library or technology. But he has enough knowledge and experience reading documentation, that with a 20 minutes read he can use that technology easily.
Fifthly, a lot of developers work in the same company and on the same project or related projects for so long that he starts to be in his own bubble, isolated from the rest of the world.. Or he just ignores all the other things even when he changes companies just focusing on his own thing, not even trying to look at other technologies or ways to do things.
This can especially seen during interviews, when you are interviewed by someone, and he expected everyone to know and have experience with what he works because in his own vision those are the only good and real things. All the other things are bad or sometimes even beneath him. Sometimes this lead to some downright arrogant and spoiled brat like attitude during the interviews. This can happen on both ends of the interview.
Or during normal work, this can be seen when a developer has a few solutions that he thinks are perfect all the time which then are forcefully implemented in situations where they are not needed and are actually contraindicated.
Sometimes entire companies live in this bubble, especially older companies that started to use the best technologies that were available at the time they were founded but since then have become obsolete. I actually ran into this recently, when I was involved to partially migrate a very old and big project to new technologies. I didn't work that much on that project but I had enough time to notice this. And when you need to interview with these companies, sometimes they will automatically have a bad impression of you because you see and do things differently from them. When an entire company lives in a bubble, its even harder for its employed developers to notice the bubble that hey are living in.
And sometimes, it might be that just a team or some teams from a company live inside a bubble. But it's pretty much the same case as I mentioned above.
Finally, there are many more things to mention here but it's already a pretty big post. And for sure some of these things also apply to me too and I am learning to get rid of these bad habits.
Comments
Post a Comment