2 edited wording of first paragraph to make it sound less negative
source | link

Many companies are stuck like this; you might even be surprised to find that some of your 'developer'developer colleagues are self-taught and became developers with no formal background whatsoever. These developers are often better at their jobs, since they will be the ones that are driven to learn new skills and succeed instead of simply doing the job. Unfortunately this can also mean that, while they're excellent at programming, they might not be aware of the benefits of these practices. The fact is these are best practices, not common practices. The best use them, but they are not at all requirements to get an application workingsucceed, they are simply tools to help make success easier.

You're absolutely right, it's going to be overwhelming to try to implement everything all at once. You'll likely burn yourself (and maybe your team) out trying to do it, which is going to demotivate future pushes to adopt new methodologies/technologies. The best thing to do in a situation like this is pick one thing (logging is probably a good start, as you've probably got a tough road ahead finding bugs without logging, and there are sure to be bugs) and talk to the team about it. You don't have to singlehandedly implement this; you'll do much better discussing the pros and cons with the team (and your boss, who absolutely MUST be on board with something like this) and coming up with a plan to implement it. It's going to have to be as painless as possible (remember, you're telling people that they now have to write extra code in addition to what they already do).

And let me say again, make sure your boss buys in. This is crucial; you will probably find that the speed of fixes/releases slows down as you implement new things. The point is that you're paying upfront to save down the line; they MUST understand this and be on your side. If you don't get them on board, you're fighting a losing battle at best, and at worst they may consider you as actively sabotaging the team (ask me how I know).

Once you bring these items to the table, discuss them with the team, plan how to implement them, and follow through, the second, third, eighth, etc. will be easier. Not only that, there's a potential for the team and your boss to gain respect for you as your suggestions are implemented and recognized as adding value. Great! Just make sure that you stay flexible: you'r pushing against inertia here, and change isn't easy. be prepared to slowly make small changes, and make sure that you can track progress and value earned. If you implement logging in a new process and it helps you save hours finding a bug in three weeks, make a big deal about it! Make sure everyone knows that the company just saved $XXX by doing the right thing ahead of time. On the other hand, if you get pushback, or have a tight deadline, don't try forcing the issue. Let the new change slide for the moment, and circle back. You won't ever win by trying to force the team to do something they don't want to do, and you can be sure the first thing they'll suggest dropping is the new 'extra' work (like writing logging, or following a styleguide instead of just 'getting it working').

Many companies are stuck like this; you might even be surprised to find that some of your 'developer' colleagues are self-taught and became developers with no formal background whatsoever. The fact is these are best practices, not common practices. The best use them, but they are not at all requirements to get an application working.

You're absolutely right, it's going to be overwhelming to try to implement everything all at once. You'll likely burn yourself (and maybe your team) out trying to do it, which is going to demotivate future pushes to adopt new methodologies/technologies. The best thing to do in a situation like this is pick one thing (logging is probably a good start, as you've probably got a tough road ahead finding bugs without logging, and there are sure to be bugs) and talk to the team about it. You don't have to singlehandedly implement this; you'll do much better discussing the pros and cons with the team (and your boss, who absolutely MUST be on board with something like this) and coming up with a plan to implement it. It's going to have to be as painless as possible (remember, you're telling people that they now have to write extra code in addition to what they already do).

And let me say again, make sure your boss buys in. This is crucial; you will probably find that the speed of fixes/releases slows down as you implement new things. The point is that you're paying upfront to save down the line; they MUST understand this and be on your side. If you don't get them on board, you're fighting a losing battle at best, and at worst they may consider you as actively sabotaging the team (ask me how I know).

Once you bring these items to the table, discuss them with the team, plan how to implement them, and follow through, the second, third, eighth, etc. will be easier. Not only that, there's a potential for the team and your boss to gain respect for you as your suggestions are implemented and recognized as adding value. Great! Just make sure that you stay flexible: you'r pushing against inertia here, and change isn't easy. be prepared to slowly make small changes, and make sure that you can track progress and value earned. If you implement logging in a new process and it helps you save hours finding a bug in three weeks, make a big deal about it! Make sure everyone knows that the company just saved $XXX by doing the right thing ahead of time. On the other hand, if you get pushback, or have a tight deadline, don't try forcing the issue. Let the new change slide for the moment, and circle back. You won't ever win by trying to force the team to do something they don't want to do, and you can be sure the first thing they'll suggest dropping is the new 'extra' work (like writing logging, or following a styleguide instead of just 'getting it working').

Many companies are stuck like this; you might even be surprised to find that some of your developer colleagues are self-taught and became developers with no formal background whatsoever. These developers are often better at their jobs, since they will be the ones that are driven to learn new skills and succeed instead of simply doing the job. Unfortunately this can also mean that, while they're excellent at programming, they might not be aware of the benefits of these practices. The fact is these are best practices, not common practices. The best use them, but they are not at all requirements to succeed, they are simply tools to help make success easier.

You're absolutely right, it's going to be overwhelming to try to implement everything all at once. You'll likely burn yourself (and maybe your team) out trying to do it, which is going to demotivate future pushes to adopt new methodologies/technologies. The best thing to do in a situation like this is pick one thing (logging is probably a good start, as you've probably got a tough road ahead finding bugs without logging, and there are sure to be bugs) and talk to the team about it. You don't have to singlehandedly implement this; you'll do much better discussing the pros and cons with the team (and your boss, who absolutely MUST be on board with something like this) and coming up with a plan to implement it. It's going to have to be as painless as possible (remember, you're telling people that they now have to write extra code in addition to what they already do).

And let me say again, make sure your boss buys in. This is crucial; you will probably find that the speed of fixes/releases slows down as you implement new things. The point is that you're paying upfront to save down the line; they MUST understand this and be on your side. If you don't get them on board, you're fighting a losing battle at best, and at worst they may consider you as actively sabotaging the team (ask me how I know).

Once you bring these items to the table, discuss them with the team, plan how to implement them, and follow through, the second, third, eighth, etc. will be easier. Not only that, there's a potential for the team and your boss to gain respect for you as your suggestions are implemented and recognized as adding value. Great! Just make sure that you stay flexible: you'r pushing against inertia here, and change isn't easy. be prepared to slowly make small changes, and make sure that you can track progress and value earned. If you implement logging in a new process and it helps you save hours finding a bug in three weeks, make a big deal about it! Make sure everyone knows that the company just saved $XXX by doing the right thing ahead of time. On the other hand, if you get pushback, or have a tight deadline, don't try forcing the issue. Let the new change slide for the moment, and circle back. You won't ever win by trying to force the team to do something they don't want to do, and you can be sure the first thing they'll suggest dropping is the new 'extra' work (like writing logging, or following a styleguide instead of just 'getting it working').

1
source | link

Many companies are stuck like this; you might even be surprised to find that some of your 'developer' colleagues are self-taught and became developers with no formal background whatsoever. The fact is these are best practices, not common practices. The best use them, but they are not at all requirements to get an application working.

You're absolutely right, it's going to be overwhelming to try to implement everything all at once. You'll likely burn yourself (and maybe your team) out trying to do it, which is going to demotivate future pushes to adopt new methodologies/technologies. The best thing to do in a situation like this is pick one thing (logging is probably a good start, as you've probably got a tough road ahead finding bugs without logging, and there are sure to be bugs) and talk to the team about it. You don't have to singlehandedly implement this; you'll do much better discussing the pros and cons with the team (and your boss, who absolutely MUST be on board with something like this) and coming up with a plan to implement it. It's going to have to be as painless as possible (remember, you're telling people that they now have to write extra code in addition to what they already do).

And let me say again, make sure your boss buys in. This is crucial; you will probably find that the speed of fixes/releases slows down as you implement new things. The point is that you're paying upfront to save down the line; they MUST understand this and be on your side. If you don't get them on board, you're fighting a losing battle at best, and at worst they may consider you as actively sabotaging the team (ask me how I know).

Once you bring these items to the table, discuss them with the team, plan how to implement them, and follow through, the second, third, eighth, etc. will be easier. Not only that, there's a potential for the team and your boss to gain respect for you as your suggestions are implemented and recognized as adding value. Great! Just make sure that you stay flexible: you'r pushing against inertia here, and change isn't easy. be prepared to slowly make small changes, and make sure that you can track progress and value earned. If you implement logging in a new process and it helps you save hours finding a bug in three weeks, make a big deal about it! Make sure everyone knows that the company just saved $XXX by doing the right thing ahead of time. On the other hand, if you get pushback, or have a tight deadline, don't try forcing the issue. Let the new change slide for the moment, and circle back. You won't ever win by trying to force the team to do something they don't want to do, and you can be sure the first thing they'll suggest dropping is the new 'extra' work (like writing logging, or following a styleguide instead of just 'getting it working').