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.
Comments
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.