I'm becoming increasingly convinced that the frustrations found in programming teams are largely because the industry wrongly selects foremost for programming skills and not for people skills.
Being a good coder is like 30% of your job. The rest is being a good teammate, which is about diplomacy and communication.
My favourite co-workers today and in the past would almost certainly never get a FANG interview but damn do they have the passion to do well and work together.
Joined a code base and all I see are bugs ( eg. Casting bugs are easy to find) + logic errors.
I think good programming is how much wtf/ minute you have, when you read the source.
I'm normally easy to talk to, but I'm having difficulty for that now because:
- fixing a simple bug leads to a rabbit hole of fixing bugs.
- no seperation. Something can influence something everywhere. It's nuts, eg. A text explanation on a enum ( state) has been added in the businesslayer and transformed 3 times before it reaches the frontend. ( I removed all those texts to show only on the view with the appropriate conditionals)
- code is unreadable -> too much time spend in debugging
- a bug was fixed when it did something wrong, instead of looking for the root of the problem. So actually fixing a bug correctly creates a new bug, because it has already been fixed 2 times on different places. Just the root case was never fixed before.
- ...
All in all, solving a bug is tedious. Fixing it the right way, creates so much bugs, because previous workarounds for probably the same/similar bug everywhere around.
I'm pretty sure that good programming leads to better communication.
And bad programming leads to a clusterfuck of problems
Maybe I've worked with bad code for too long, but my opinion is, being the one person who understands some clusterfuck of poorly designed and hard to read code is job security and improving it can be satisfying. Reducing coupling, making a codebase more readable, rewriting code to make it more unit testable, or making a given piece of code run faster I find to be satisfying and educational. You learn from direct experience a myriad of ways in which not to do things and exactly why not to do them, and you can use this information going forward when you write your next feature.
It can also be incredibly frustrating. There's a human reason the code is a mess, and unless that situation changes, the code will rapidly revert to a mess no matter how clean you make it.
Not necessarily. At least in my experience, most people want to improve their coding skills and if you build a good relationship with your coworkers and have a track record of putting out good work, then you'll be in a position to offer up suggestions on how everyone can improve.
Or the management will come and say that they signed another contract for something that has to be done in 3 months (they said it's already basically ready, just a few last brushes to go) and now there is no time to do anything right. Everything becomes its worst possible version and every day you pray that you will never ever have to look at the code you've just written again. And then you look at the code others have just written and now you have to work with, and you wish you were never born (or dream about being a baker).
Yeah, fair enough. I work in a position where the deadlines for what we are building are mostly self imposed (we of course want to be competitive with other businesses that do what we do, so there is some sense of urgency, but it is not going to significantly impact the business if we late by a mont or two on something). While we do have deadlines, they are somewhat flexible as long as you can give a really good reason why you can't meet it.
I think the only thing you can do in this situation is to express frustration with whoever was involved in determining the 3 month deadline. You can only tell them that it is not enough time and that they should involve some technical people when making decisions like that. If they don't like what you have to say or the whole strategy of the company is actually based on doing things cheap and fast, then maybe it is time to move to a new company that has an environment which is more aligned with your values.
When the underlying problem is a lack of knowledge in the group, it can be easily fixed by the introduction of someone with the neccessary knowledge. In that case, you are solving the human problem. That's one of many possible reasons for why the code is a mess.
2. Being asked to do something too quickly (or the technical team not asking for enough time up front).
3. Being asked to do something dumb and giving in.
The second point happens everywhere to varying degrees, so I just see it as part of the job description of being a developer. You will always have to fight for more time since everyone who requests you to build something wants their software features now and not tomorrow. Points 1 and 3 can usually be solved with better communication and some education.
All of these problems are solvable assuming the management of the team understands these problems occur and is on the same page as the people implementing the software. If that isn't the case and the management isn't going to listen to the devs, I think that is one of the few situations where it is time to just find a new job. Possibly this is more common than not and I have been lucky enough to only experience one manager who was this stubborn and ignorant.
The article is a rant about bad code, not about bad teammates. Maybe they were hired because the manager liked them for having people skills instead of actually being good at their jobs. I agree communication is an important part as well, that does not has much to do with people skills, though. Being a good programmer should be more like 75% of a programmer's job to actually make their temmates life easier.
Comments
I'm becoming increasingly convinced that the frustrations found in programming teams are largely because the industry wrongly selects foremost for programming skills and not for people skills.
Being a good coder is like 30% of your job. The rest is being a good teammate, which is about diplomacy and communication.
My favourite co-workers today and in the past would almost certainly never get a FANG interview but damn do they have the passion to do well and work together.
Just my experience.
Joined a code base and all I see are bugs ( eg. Casting bugs are easy to find) + logic errors.
I think good programming is how much wtf/ minute you have, when you read the source.
I'm normally easy to talk to, but I'm having difficulty for that now because:
- fixing a simple bug leads to a rabbit hole of fixing bugs.
- no seperation. Something can influence something everywhere. It's nuts, eg. A text explanation on a enum ( state) has been added in the businesslayer and transformed 3 times before it reaches the frontend. ( I removed all those texts to show only on the view with the appropriate conditionals)
- code is unreadable -> too much time spend in debugging
- a bug was fixed when it did something wrong, instead of looking for the root of the problem. So actually fixing a bug correctly creates a new bug, because it has already been fixed 2 times on different places. Just the root case was never fixed before.
- ...
All in all, solving a bug is tedious. Fixing it the right way, creates so much bugs, because previous workarounds for probably the same/similar bug everywhere around.
I'm pretty sure that good programming leads to better communication.
And bad programming leads to a clusterfuck of problems
Maybe I've worked with bad code for too long, but my opinion is, being the one person who understands some clusterfuck of poorly designed and hard to read code is job security and improving it can be satisfying. Reducing coupling, making a codebase more readable, rewriting code to make it more unit testable, or making a given piece of code run faster I find to be satisfying and educational. You learn from direct experience a myriad of ways in which not to do things and exactly why not to do them, and you can use this information going forward when you write your next feature.
It can also be incredibly frustrating. There's a human reason the code is a mess, and unless that situation changes, the code will rapidly revert to a mess no matter how clean you make it.
Not necessarily. At least in my experience, most people want to improve their coding skills and if you build a good relationship with your coworkers and have a track record of putting out good work, then you'll be in a position to offer up suggestions on how everyone can improve.
Or the management will come and say that they signed another contract for something that has to be done in 3 months (they said it's already basically ready, just a few last brushes to go) and now there is no time to do anything right. Everything becomes its worst possible version and every day you pray that you will never ever have to look at the code you've just written again. And then you look at the code others have just written and now you have to work with, and you wish you were never born (or dream about being a baker).
Yeah, fair enough. I work in a position where the deadlines for what we are building are mostly self imposed (we of course want to be competitive with other businesses that do what we do, so there is some sense of urgency, but it is not going to significantly impact the business if we late by a mont or two on something). While we do have deadlines, they are somewhat flexible as long as you can give a really good reason why you can't meet it.
I think the only thing you can do in this situation is to express frustration with whoever was involved in determining the 3 month deadline. You can only tell them that it is not enough time and that they should involve some technical people when making decisions like that. If they don't like what you have to say or the whole strategy of the company is actually based on doing things cheap and fast, then maybe it is time to move to a new company that has an environment which is more aligned with your values.
When the underlying problem is a lack of knowledge in the group, it can be easily fixed by the introduction of someone with the neccessary knowledge. In that case, you are solving the human problem. That's one of many possible reasons for why the code is a mess.
I can only really see a few possibilities here:
1. Lack of knowlege in the team.
2. Being asked to do something too quickly (or the technical team not asking for enough time up front).
3. Being asked to do something dumb and giving in.
The second point happens everywhere to varying degrees, so I just see it as part of the job description of being a developer. You will always have to fight for more time since everyone who requests you to build something wants their software features now and not tomorrow. Points 1 and 3 can usually be solved with better communication and some education.
All of these problems are solvable assuming the management of the team understands these problems occur and is on the same page as the people implementing the software. If that isn't the case and the management isn't going to listen to the devs, I think that is one of the few situations where it is time to just find a new job. Possibly this is more common than not and I have been lucky enough to only experience one manager who was this stubborn and ignorant.
I've heard the book Working with Legacy Code [0] recommended for strategies to bring order to these kind of projects. Haven't read it myself yet...
[0]: https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
That sounds too much like the code base I inherited, it gradually wears on you.
The article is a rant about bad code, not about bad teammates. Maybe they were hired because the manager liked them for having people skills instead of actually being good at their jobs. I agree communication is an important part as well, that does not has much to do with people skills, though. Being a good programmer should be more like 75% of a programmer's job to actually make their temmates life easier.