Mixing
Is this normal in the software-industry? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-2
down vote
favorite
I'm sure about the vague title but I was not sure how to post this question.
My situation is the following. I have been working in a company for about 10 months now, and I was hired as a junior (java) software engineer after finishing my uni degree. The company I am working for now is a company with almost no communication in the software team. We have about 6 juniors and 3 seniors (rather small company). We have a chatclient for communication (and questions) yet it is hardly used, and when someone does use it, not often something valuable comes out of the short exchange of words. (Which is on the order of two times a week)
The lack of communication is one thing that struck me as a bit odd. In addition we don't seem to employ design patterns or other common software engineering practices. (If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it). And furthermore, I feel like I am not learning anything new at this job.
Lastly, and perhaps my main issue, is that even though I am hired as a java developer, I spend programming maybe half a day to one day a week. The rest of the week, I spend doing HTML/CSS design, or changing some config files.
I was wondering if this is normal for the software industry, or perhaps this is more a characteristic of small companies? Would it be different in larger companies?
software-industry software-development
edited Apr 5 '16 at 17:37
paparazzo
33.3k657106
asked Apr 5 '16 at 17:14
Guest
2
closed as off-topic by IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal♦ Apr 5 '16 at 19:08
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal
suggest improvements |Â
up vote
-2
down vote
favorite
I'm sure about the vague title but I was not sure how to post this question.
My situation is the following. I have been working in a company for about 10 months now, and I was hired as a junior (java) software engineer after finishing my uni degree. The company I am working for now is a company with almost no communication in the software team. We have about 6 juniors and 3 seniors (rather small company). We have a chatclient for communication (and questions) yet it is hardly used, and when someone does use it, not often something valuable comes out of the short exchange of words. (Which is on the order of two times a week)
The lack of communication is one thing that struck me as a bit odd. In addition we don't seem to employ design patterns or other common software engineering practices. (If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it). And furthermore, I feel like I am not learning anything new at this job.
Lastly, and perhaps my main issue, is that even though I am hired as a java developer, I spend programming maybe half a day to one day a week. The rest of the week, I spend doing HTML/CSS design, or changing some config files.
I was wondering if this is normal for the software industry, or perhaps this is more a characteristic of small companies? Would it be different in larger companies?
software-industry software-development
edited Apr 5 '16 at 17:37
paparazzo
33.3k657106
asked Apr 5 '16 at 17:14
Guest
2
closed as off-topic by IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal♦ Apr 5 '16 at 19:08
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal
4
No, that is weird and broken.
– Telastyn
Apr 5 '16 at 17:19
1
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - if you mean just formatting, then that can happen on large code bases with many branches in development at once, because the danger is that formatting changes will break everyone's merges. If you want to make formatting changes you have to pick a moment when everyone's stuff is checked in e.g. around a release, and where you don't have too many stable branches on the old formatting to back-port fixes from head to.
– Rup
Apr 5 '16 at 17:45
would this be better for stackoverflow.com or would it be OT there?
– mcknz
Apr 5 '16 at 18:18
This is a sign of bad management, hopefully it will improve in time.
– Kilisi
Apr 6 '16 at 0:10
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - this could also indicate lack of tests. For example, if there is not a good test suite, a developer can't always be confident that "formatting changes" didn't inadvertently introduce bugs.
– Brandin
Apr 6 '16 at 8:03
suggest improvements |Â
up vote
-2
down vote
favorite
up vote
-2
down vote
favorite
I'm sure about the vague title but I was not sure how to post this question.
My situation is the following. I have been working in a company for about 10 months now, and I was hired as a junior (java) software engineer after finishing my uni degree. The company I am working for now is a company with almost no communication in the software team. We have about 6 juniors and 3 seniors (rather small company). We have a chatclient for communication (and questions) yet it is hardly used, and when someone does use it, not often something valuable comes out of the short exchange of words. (Which is on the order of two times a week)
The lack of communication is one thing that struck me as a bit odd. In addition we don't seem to employ design patterns or other common software engineering practices. (If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it). And furthermore, I feel like I am not learning anything new at this job.
Lastly, and perhaps my main issue, is that even though I am hired as a java developer, I spend programming maybe half a day to one day a week. The rest of the week, I spend doing HTML/CSS design, or changing some config files.
I was wondering if this is normal for the software industry, or perhaps this is more a characteristic of small companies? Would it be different in larger companies?
software-industry software-development
edited Apr 5 '16 at 17:37
paparazzo
33.3k657106
asked Apr 5 '16 at 17:14
Guest
2
I'm sure about the vague title but I was not sure how to post this question.
My situation is the following. I have been working in a company for about 10 months now, and I was hired as a junior (java) software engineer after finishing my uni degree. The company I am working for now is a company with almost no communication in the software team. We have about 6 juniors and 3 seniors (rather small company). We have a chatclient for communication (and questions) yet it is hardly used, and when someone does use it, not often something valuable comes out of the short exchange of words. (Which is on the order of two times a week)
The lack of communication is one thing that struck me as a bit odd. In addition we don't seem to employ design patterns or other common software engineering practices. (If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it). And furthermore, I feel like I am not learning anything new at this job.
Lastly, and perhaps my main issue, is that even though I am hired as a java developer, I spend programming maybe half a day to one day a week. The rest of the week, I spend doing HTML/CSS design, or changing some config files.
I was wondering if this is normal for the software industry, or perhaps this is more a characteristic of small companies? Would it be different in larger companies?
software-industry software-development
edited Apr 5 '16 at 17:37
paparazzo
33.3k657106
asked Apr 5 '16 at 17:14
Guest
2
edited Apr 5 '16 at 17:37
paparazzo
33.3k657106
edited Apr 5 '16 at 17:37
paparazzo
33.3k657106
edited Apr 5 '16 at 17:37
paparazzo
33.3k657106
33.3k657106
asked Apr 5 '16 at 17:14
Guest
2
asked Apr 5 '16 at 17:14
Guest
2
asked Apr 5 '16 at 17:14
Guest
2
2
closed as off-topic by IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal♦ Apr 5 '16 at 19:08
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal
closed as off-topic by IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal♦ Apr 5 '16 at 19:08
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – IDrinkandIKnowThings, paparazzo, Chris E, gnat, Lilienthal
4
No, that is weird and broken.
– Telastyn
Apr 5 '16 at 17:19
1
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - if you mean just formatting, then that can happen on large code bases with many branches in development at once, because the danger is that formatting changes will break everyone's merges. If you want to make formatting changes you have to pick a moment when everyone's stuff is checked in e.g. around a release, and where you don't have too many stable branches on the old formatting to back-port fixes from head to.
– Rup
Apr 5 '16 at 17:45
would this be better for stackoverflow.com or would it be OT there?
– mcknz
Apr 5 '16 at 18:18
This is a sign of bad management, hopefully it will improve in time.
– Kilisi
Apr 6 '16 at 0:10
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - this could also indicate lack of tests. For example, if there is not a good test suite, a developer can't always be confident that "formatting changes" didn't inadvertently introduce bugs.
– Brandin
Apr 6 '16 at 8:03
suggest improvements |Â
4
No, that is weird and broken.
– Telastyn
Apr 5 '16 at 17:19
1
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - if you mean just formatting, then that can happen on large code bases with many branches in development at once, because the danger is that formatting changes will break everyone's merges. If you want to make formatting changes you have to pick a moment when everyone's stuff is checked in e.g. around a release, and where you don't have too many stable branches on the old formatting to back-port fixes from head to.
– Rup
Apr 5 '16 at 17:45
would this be better for stackoverflow.com or would it be OT there?
– mcknz
Apr 5 '16 at 18:18
This is a sign of bad management, hopefully it will improve in time.
– Kilisi
Apr 6 '16 at 0:10
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - this could also indicate lack of tests. For example, if there is not a good test suite, a developer can't always be confident that "formatting changes" didn't inadvertently introduce bugs.
– Brandin
Apr 6 '16 at 8:03
4
4
No, that is weird and broken.
– Telastyn
Apr 5 '16 at 17:19
No, that is weird and broken.
– Telastyn
Apr 5 '16 at 17:19
1
1
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - if you mean just formatting, then that can happen on large code bases with many branches in development at once, because the danger is that formatting changes will break everyone's merges. If you want to make formatting changes you have to pick a moment when everyone's stuff is checked in e.g. around a release, and where you don't have too many stable branches on the old formatting to back-port fixes from head to.
– Rup
Apr 5 '16 at 17:45
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - if you mean just formatting, then that can happen on large code bases with many branches in development at once, because the danger is that formatting changes will break everyone's merges. If you want to make formatting changes you have to pick a moment when everyone's stuff is checked in e.g. around a release, and where you don't have too many stable branches on the old formatting to back-port fixes from head to.
– Rup
Apr 5 '16 at 17:45
would this be better for stackoverflow.com or would it be OT there?
– mcknz
Apr 5 '16 at 18:18
would this be better for stackoverflow.com or would it be OT there?
– mcknz
Apr 5 '16 at 18:18
This is a sign of bad management, hopefully it will improve in time.
– Kilisi
Apr 6 '16 at 0:10
This is a sign of bad management, hopefully it will improve in time.
– Kilisi
Apr 6 '16 at 0:10
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - this could also indicate lack of tests. For example, if there is not a good test suite, a developer can't always be confident that "formatting changes" didn't inadvertently introduce bugs.
– Brandin
Apr 6 '16 at 8:03
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - this could also indicate lack of tests. For example, if there is not a good test suite, a developer can't always be confident that "formatting changes" didn't inadvertently introduce bugs.
– Brandin
Apr 6 '16 at 8:03
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
6
down vote
First of all, when you're hired as a developer on a small (or small-ish) team, you're almost definitely going to wear many hats (meaning you will assume the duties of multiple job titles at once), so the fact that you're doing HTML/CSS is not surprising.
The communication strangeness and the fact that it seems like good methodologies aren't being used sound like it perhaps is simply a very 'new' development team entirely.
So to clarify: "Is this normal?" - Somewhat
PS: You should write up something professional and polite to address your concerns about processes and methodologies and talk to your superiors about it! If they are a good team they will welcome good ideas and 'proper' programming!
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
1
I would be careful about "writing up something professional and polite..." and sending to superiors. Change happens gradually and it's often better to pick your spots strategically, rather than trying to sum up everything that's wrong in a given environment. Often people already know what's wrong, but don't have the time/support to correct it.
– mcknz
Apr 5 '16 at 18:01
@mcknz Absolutely true. It depends on the team and the personalities I suppose. I've been on teams where this sort of thing would have been welcomed with open arms, and I have at least interacted with teams where this would have set you on the path to getting pushed out the door. User discretion is advised
– Ethan The Brave
Apr 6 '16 at 14:12
suggest improvements |Â
up vote
4
down vote
Although the situation as you describe is not ideal, and certainly not "normal," unfortunately it's not uncommon, especially among smaller companies. Companies can start small, with employees who teach themselves software development, and build homegrown systems.
What you are seeing is classic technical debt -- design decisions are made for short-term goals, rather than long-term maintainability.
You would likely see better development practices at a larger company, but there are trade-offs -- for the most part, at a smaller company you get to do more things more quickly. At a large company development can be more specialized and subject to layers of (sometimes necessary) bureaucracy.
You're gaining valuable experience not only in hands-on coding, but lessons on what not do to in the future. As long as you are trying to apply sound practices and encouraging others to do the same, you and your team can improve.
If the situation doesn't get better gradually however, you may want to look for other opportunities -- it can be frustrating and stressful when you know the right way to work, but the company culture doesn't allow it.
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
First of all, when you're hired as a developer on a small (or small-ish) team, you're almost definitely going to wear many hats (meaning you will assume the duties of multiple job titles at once), so the fact that you're doing HTML/CSS is not surprising.
The communication strangeness and the fact that it seems like good methodologies aren't being used sound like it perhaps is simply a very 'new' development team entirely.
So to clarify: "Is this normal?" - Somewhat
PS: You should write up something professional and polite to address your concerns about processes and methodologies and talk to your superiors about it! If they are a good team they will welcome good ideas and 'proper' programming!
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
1
I would be careful about "writing up something professional and polite..." and sending to superiors. Change happens gradually and it's often better to pick your spots strategically, rather than trying to sum up everything that's wrong in a given environment. Often people already know what's wrong, but don't have the time/support to correct it.
– mcknz
Apr 5 '16 at 18:01
@mcknz Absolutely true. It depends on the team and the personalities I suppose. I've been on teams where this sort of thing would have been welcomed with open arms, and I have at least interacted with teams where this would have set you on the path to getting pushed out the door. User discretion is advised
– Ethan The Brave
Apr 6 '16 at 14:12
suggest improvements |Â
up vote
6
down vote
First of all, when you're hired as a developer on a small (or small-ish) team, you're almost definitely going to wear many hats (meaning you will assume the duties of multiple job titles at once), so the fact that you're doing HTML/CSS is not surprising.
The communication strangeness and the fact that it seems like good methodologies aren't being used sound like it perhaps is simply a very 'new' development team entirely.
So to clarify: "Is this normal?" - Somewhat
PS: You should write up something professional and polite to address your concerns about processes and methodologies and talk to your superiors about it! If they are a good team they will welcome good ideas and 'proper' programming!
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
1
I would be careful about "writing up something professional and polite..." and sending to superiors. Change happens gradually and it's often better to pick your spots strategically, rather than trying to sum up everything that's wrong in a given environment. Often people already know what's wrong, but don't have the time/support to correct it.
– mcknz
Apr 5 '16 at 18:01
@mcknz Absolutely true. It depends on the team and the personalities I suppose. I've been on teams where this sort of thing would have been welcomed with open arms, and I have at least interacted with teams where this would have set you on the path to getting pushed out the door. User discretion is advised
– Ethan The Brave
Apr 6 '16 at 14:12
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
First of all, when you're hired as a developer on a small (or small-ish) team, you're almost definitely going to wear many hats (meaning you will assume the duties of multiple job titles at once), so the fact that you're doing HTML/CSS is not surprising.
The communication strangeness and the fact that it seems like good methodologies aren't being used sound like it perhaps is simply a very 'new' development team entirely.
So to clarify: "Is this normal?" - Somewhat
PS: You should write up something professional and polite to address your concerns about processes and methodologies and talk to your superiors about it! If they are a good team they will welcome good ideas and 'proper' programming!
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
First of all, when you're hired as a developer on a small (or small-ish) team, you're almost definitely going to wear many hats (meaning you will assume the duties of multiple job titles at once), so the fact that you're doing HTML/CSS is not surprising.
The communication strangeness and the fact that it seems like good methodologies aren't being used sound like it perhaps is simply a very 'new' development team entirely.
So to clarify: "Is this normal?" - Somewhat
PS: You should write up something professional and polite to address your concerns about processes and methodologies and talk to your superiors about it! If they are a good team they will welcome good ideas and 'proper' programming!
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
answered Apr 5 '16 at 17:18
Ethan The Brave
1,612716
1,612716
1
I would be careful about "writing up something professional and polite..." and sending to superiors. Change happens gradually and it's often better to pick your spots strategically, rather than trying to sum up everything that's wrong in a given environment. Often people already know what's wrong, but don't have the time/support to correct it.
– mcknz
Apr 5 '16 at 18:01
@mcknz Absolutely true. It depends on the team and the personalities I suppose. I've been on teams where this sort of thing would have been welcomed with open arms, and I have at least interacted with teams where this would have set you on the path to getting pushed out the door. User discretion is advised
– Ethan The Brave
Apr 6 '16 at 14:12
suggest improvements |Â
1
I would be careful about "writing up something professional and polite..." and sending to superiors. Change happens gradually and it's often better to pick your spots strategically, rather than trying to sum up everything that's wrong in a given environment. Often people already know what's wrong, but don't have the time/support to correct it.
– mcknz
Apr 5 '16 at 18:01
@mcknz Absolutely true. It depends on the team and the personalities I suppose. I've been on teams where this sort of thing would have been welcomed with open arms, and I have at least interacted with teams where this would have set you on the path to getting pushed out the door. User discretion is advised
– Ethan The Brave
Apr 6 '16 at 14:12
1
1
I would be careful about "writing up something professional and polite..." and sending to superiors. Change happens gradually and it's often better to pick your spots strategically, rather than trying to sum up everything that's wrong in a given environment. Often people already know what's wrong, but don't have the time/support to correct it.
– mcknz
Apr 5 '16 at 18:01
I would be careful about "writing up something professional and polite..." and sending to superiors. Change happens gradually and it's often better to pick your spots strategically, rather than trying to sum up everything that's wrong in a given environment. Often people already know what's wrong, but don't have the time/support to correct it.
– mcknz
Apr 5 '16 at 18:01
@mcknz Absolutely true. It depends on the team and the personalities I suppose. I've been on teams where this sort of thing would have been welcomed with open arms, and I have at least interacted with teams where this would have set you on the path to getting pushed out the door. User discretion is advised
– Ethan The Brave
Apr 6 '16 at 14:12
@mcknz Absolutely true. It depends on the team and the personalities I suppose. I've been on teams where this sort of thing would have been welcomed with open arms, and I have at least interacted with teams where this would have set you on the path to getting pushed out the door. User discretion is advised
– Ethan The Brave
Apr 6 '16 at 14:12
suggest improvements |Â
up vote
4
down vote
Although the situation as you describe is not ideal, and certainly not "normal," unfortunately it's not uncommon, especially among smaller companies. Companies can start small, with employees who teach themselves software development, and build homegrown systems.
What you are seeing is classic technical debt -- design decisions are made for short-term goals, rather than long-term maintainability.
You would likely see better development practices at a larger company, but there are trade-offs -- for the most part, at a smaller company you get to do more things more quickly. At a large company development can be more specialized and subject to layers of (sometimes necessary) bureaucracy.
You're gaining valuable experience not only in hands-on coding, but lessons on what not do to in the future. As long as you are trying to apply sound practices and encouraging others to do the same, you and your team can improve.
If the situation doesn't get better gradually however, you may want to look for other opportunities -- it can be frustrating and stressful when you know the right way to work, but the company culture doesn't allow it.
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
suggest improvements |Â
up vote
4
down vote
Although the situation as you describe is not ideal, and certainly not "normal," unfortunately it's not uncommon, especially among smaller companies. Companies can start small, with employees who teach themselves software development, and build homegrown systems.
What you are seeing is classic technical debt -- design decisions are made for short-term goals, rather than long-term maintainability.
You would likely see better development practices at a larger company, but there are trade-offs -- for the most part, at a smaller company you get to do more things more quickly. At a large company development can be more specialized and subject to layers of (sometimes necessary) bureaucracy.
You're gaining valuable experience not only in hands-on coding, but lessons on what not do to in the future. As long as you are trying to apply sound practices and encouraging others to do the same, you and your team can improve.
If the situation doesn't get better gradually however, you may want to look for other opportunities -- it can be frustrating and stressful when you know the right way to work, but the company culture doesn't allow it.
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
Although the situation as you describe is not ideal, and certainly not "normal," unfortunately it's not uncommon, especially among smaller companies. Companies can start small, with employees who teach themselves software development, and build homegrown systems.
What you are seeing is classic technical debt -- design decisions are made for short-term goals, rather than long-term maintainability.
You would likely see better development practices at a larger company, but there are trade-offs -- for the most part, at a smaller company you get to do more things more quickly. At a large company development can be more specialized and subject to layers of (sometimes necessary) bureaucracy.
You're gaining valuable experience not only in hands-on coding, but lessons on what not do to in the future. As long as you are trying to apply sound practices and encouraging others to do the same, you and your team can improve.
If the situation doesn't get better gradually however, you may want to look for other opportunities -- it can be frustrating and stressful when you know the right way to work, but the company culture doesn't allow it.
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
Although the situation as you describe is not ideal, and certainly not "normal," unfortunately it's not uncommon, especially among smaller companies. Companies can start small, with employees who teach themselves software development, and build homegrown systems.
What you are seeing is classic technical debt -- design decisions are made for short-term goals, rather than long-term maintainability.
You would likely see better development practices at a larger company, but there are trade-offs -- for the most part, at a smaller company you get to do more things more quickly. At a large company development can be more specialized and subject to layers of (sometimes necessary) bureaucracy.
You're gaining valuable experience not only in hands-on coding, but lessons on what not do to in the future. As long as you are trying to apply sound practices and encouraging others to do the same, you and your team can improve.
If the situation doesn't get better gradually however, you may want to look for other opportunities -- it can be frustrating and stressful when you know the right way to work, but the company culture doesn't allow it.
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
answered Apr 5 '16 at 17:58
mcknz
15.6k55468
15.6k55468
suggest improvements |Â
suggest improvements |Â
4
No, that is weird and broken.
– Telastyn
Apr 5 '16 at 17:19
1
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - if you mean just formatting, then that can happen on large code bases with many branches in development at once, because the danger is that formatting changes will break everyone's merges. If you want to make formatting changes you have to pick a moment when everyone's stuff is checked in e.g. around a release, and where you don't have too many stable branches on the old formatting to back-port fixes from head to.
– Rup
Apr 5 '16 at 17:45
would this be better for stackoverflow.com or would it be OT there?
– mcknz
Apr 5 '16 at 18:18
This is a sign of bad management, hopefully it will improve in time.
– Kilisi
Apr 6 '16 at 0:10
"If the code layout is messed up for example, they would rather leave it that way than taking a few minutes to fix it" - this could also indicate lack of tests. For example, if there is not a good test suite, a developer can't always be confident that "formatting changes" didn't inadvertently introduce bugs.
– Brandin
Apr 6 '16 at 8:03