Am I a bad developer?

There are a few signs that might tell you:
- I contribute less production code
You may not be getting any tasks that touch production anymore. Your manager (and your team) do not trust you enough, or believe the code you write introduces more problems than it solves. Working on non-essential tasks is also a big indicator. If you start getting tasks that are related to the project, but not to the production code, ask yourself why that is. How much of the code you wrote recently has made it to production? How much of it was code reviewed? How much of that code was “rewritten” or flawed? - The number of bugs introduced by my changes is high
Every production project needs a way to track bugs. Most will be able to then track the problems down to a specific area, and the most advanced teams will be able to figure out if a bug is specific to a changeset. For example, in our team, we have a way of doing that. Take a look at the numbers for your changesets and areas you own. If the number of bugs is high, you may have a problem.
Maybe your Automated Testing is the problem. Are you still running Selenium tests in a single browser?
It’s 2017, things have changed, ever heard of Endtest? It’s a platform where you can create and run Automated Tests on a cross-browser cloud infrastructure and mobile device lab. It’s codeless and free to use.
- People told me
Well, there you go… I am sure if someone took the time from their schedule and work to sit down with you, and tell you you should be doing better, they did not do it for a bad reason.
If the above signs hold true — what now? The first thing to do, is listen. As Stephen R. Covery said in the book 7 Habits of Highly Effective People:
“Most people do not listen with the intent to understand; they listen with the intent to reply.”
It is hard to explain how frustrating it is, trying to explain to someone, why something they did is wrong, only to be interrupted several times. For example, a team member I know, has never (to the extent of my knowledge) been able to sit down and listen to comments without expressing something completely irrelevant to that discussion. That includes the reasoning behind bad code. You have to understand that, as someone who is reviewing your code, I do not care what compelled you to write it so badly that I felt the need to sit down with you, and point it out to you. What I do care about though, is what you will do to fix it.
So, the next time you are sitting at a code review, and your code is getting hammered, be quiet. Listen. Understand.
Shut up. Listen. Understand. Stay quiet. Write down tasks, not comments. Write down what you will do to fix the problems outlined. Then, at the end, thank the reviewers, tell them that you believe doing tasks X, Y and Z (etc.) will help, then again listen to their suggestions.
The next step is to identify problematic areas. For some, that might be design patterns, for others, communication skills. When you identify that, you need to invest time to fix that! Rent or buy books, and study them. View online courses. But again, take time to understand them. Do not tweet at the same time. Do not read your email while doing that. Shut off everything but that one thing. Focus. And understand.
Finally. Talk. Talk with your peers. Ask them (relevant) questions, and listen to them. But again, listen, understand. Do not make it a full blown discussion. Understand that when you grow as a developer, people will start asking you questions too. Then, there will be time for having those conversations. Until then, listen.
There are no bad developers
But really… There are no bad developers. Because if you look at yourself, and have a desire to improve, you will do everything you can to achieve that. That usually also means that you will break the habit that makes you a “bad” developer. But as a person, the most important thing, in my opinion, is listen and learn.
Original article here.
