I’ve found that the primary cause for sloppy work, outside of the programmer simply not caring, is a lack of knowledge. Unfortunately in a lot of environments, lack of knowledge is looked down on rather than openly discussed.

Some techniques that I’ve used with success to foster discussion, growth, and general excitement about programming are:

• Weekly brown bag tech sessions (Have them research a topic and present).
• Daily or weekly one on one mentoring sessions between junior and senior members.
• Code reviews (with an emphasis on learning, not pointing out mistakes).

Learning is contagious. When you foster an environment that encourages learning you not only produce better developers, but show others on your team that they are part of something bigger than a way to get a paycheck.

Upon seeing that you were hired as the Sr. PHP dev and your job is to fix things, I suggest it’s time you flex some muscle.

If I was in your place, I’d do a good survey of the code and see mistakes that are happening over and over again. Block off meeting time each week to go over these things with the team. Don’t point fingers or name names, just show how to do that task properly.

Next, since you’ve already seen needs fixing, make a list. If it’s quick and easy to do, do it. If it’ll make your life easier to have it done….do it. Make a list of all the things that need to be done and make tickets for them and see when people have cycles to do them. If someone is fixing a bug in a problem area, walk them through how to fix it properly.

If it requires a large change, sit down with the team and the stake holders and discuss options.

Have an open door policy where you’ll help people out. Be someone who educates and not intimidates. No, “you have to do it this way” and more “it would be better if it was done this way”. Explain advantages to doing it the way you suggest and the disadvantages of the way it’s been done. People will be more willing to do it the right way if they feel they have learned something instead of being told their way is wrong and to do it some other way b/c you say so.

Management’s Perspective of the Problem
If they have accepted the time of development in relation to the amount of defects, why would they risk it? When long-term benefits contradict short-term objectives, they usually lose. You are asking them to take a short-step back. They may think this will cause a lengthy delay. You have to convince them it won’t along with the added benefits. If they don’t think they have a mess, ask them to explain why it takes so long to quickly introduce new bugs with each “fix”.

Code quality is contingent on many circumstances and situations. Sales, marketing, and managers will make you believe every failed deadline means the company will miss that one shot at the mega-million venture capital investor. The reality is, they don’t want to break the bad news to the 1% of your clients who really didn’t need the feature anyway. I’m being extreme and usually it falls somewhere in between, so developers need to learn what is an actual emergency. Then it’s easier to convince them to take the time to do it right instead of needing time to do it over. You have to understand the risks.

Like a great novel, code isn’t written well the first time, but unfortunately it still gets published too often. Start with something fundamental like establishing a coding standard. Everyone has one, but many like in your situation, they haven’t been formalized nor are they very stringent. “Do whatever you want.” is a standard that’s very easy to maintain. The next step is to determine how you’re going to maintain your standards.

You have a major task ahead of you. Maybe a few great programmers have developed their skills and habits to the extent they never have to compromise on the quality of their code or go into technical-debt, but wait and see what happens when that angel investor promises everyone will get rich.

Sit and write the prototype (or some module if the whole project is too big) that uses really good design as you see fit. Then present / discuss it with the team. It may be easier to convince by example.

In this process, you may also discover that some tools, libraries, approaches or the like are not that good. Always evaluate first and ask your team to use that later. Beware of cheap marketing around substandard tools.

Also – very quickly bury statements like “I could do it myself.” Even if you think that you could, and indeed, even if you could. You need to strive to persuade the team to accept your technical leadership on quality-improving practices. They must not see you as “smartypants.”