What to do when co-workers code badly?

Question

I am working part time in a small software company to raise some money. Without sounding arrogant: some of my co-workers I am working with in a team are writing horrible code. Both syntax- and algorithmic wise. Sure there are moments in the shadow of a deadline where things get a bit hacky but they do it all the time. Every time I have to read code like this it hurts. I want to be able to stand behind the product we are developing. But I can't do that with the knowledge of crap under the hood. Besides when their code surprisingly results in failures I'm the assignee of those issues. So I guess the project manager thinks it's my fault (ok maybe my ego speaking here just a tiny bit, too).

So to finally get to my question: What should I do? I am just the part time college student at the bottom end of the hierachy. Am I "allowed" to stand up and tell them their stuff just sucks? Or should I just keep silently fixing their code if I have enough time? In general the job is pretty great. I doubt I could get that much responsibility and involvement in another student job (it is badly paid though).

Answer 1

Telling them their stuff sucks isn't going to help.

Try and talk to them about it, and suggest better ways of doing it, but do it like:"Have you thought about doing it this way?" Be subtle and praise them (in a non-patronizing way: "I like how you've done that." or simply a "Well done!") if they implement your suggestion that you discussed together.

The main thing is, if they are shown better ways of doing it, they either run with it and enjoy learning better approaches, or they don't give a hoot. In the latter case, they should really not be in this job in the first place.

Answer 2

It's difficult to handle this without annoying the people at fault. I would talk to your manager about this, and provide evidence of what's going on. Whilst doing this, emphasise that you have no issue resolving other people's issues (after all, you're part of a team), but the current scenario impacts both your schedules and your professional reputation.

I think that, given you're the most junior member of the team, that it's going to be difficult for you to present yourself as the best coder/programmer on the team without annoying your co-workers (regardless of whether it's true). Probably the best way forward is to present possible solutions (enforced unit testing, code reviews etc.) to your manager and encourage him to introduce these.

Ultimately this is one for your manager, but you need to communicate this issue to him. If you carry on without telling him and silently resolving other peoples issues, how is he going to know?

Answer 3

You probably have better theorical backup that your co-workers (more if they left studing years ago), but sure they have better working experience than you. I thing that everybody can learn of this situation if they (and you) are both reasonable.

If you give they better ways of do their work, and they accept those solutions (it is what they should do), may be they give you nice advices in the future when you need it. If you try to fault they to the proyect manager, probably they will do the same in the future with you and then, nobody gains.

It's your choose but in my experience it is (almost always) better to collaborate and accept advices from my colleages, than start an internal war that always loose the week part.

Don't envy your situation, good luck ;)

Answer 4

Bad code or good code can be decided by understanding how well one exploits the benefits of a language, that they are coding, effectively.

Let your co-workers know the coding standards (whatever the language may be) followed generally. Make them understands that following standards help them groom as better programmers & also helps to maintain the project at the later stage.

Help them walk through some of the good codes available outside. You can request them to review code (may be yours) & comment on it. If you find yourself superior in coding, then they should be able to see it when they review!!!

Slowly they would start appreciating & adhere to good coding practices!

Answer 5

Keep it technical, writing comments in which you explain the improvements you've made and the positive effect that they've had on the code base. Take the issues you encounter one by one and prove in technical terms the advantages of the methods you use over the methods that were being used before you rewrote the code. Suggest that for the sake of consistency and efficiency, new code should try to "cooperate" in the same manner, in order to keep the project maintainable and robust as a whole.

Answer 6

I'd echo that a couple of Dale Carnegie's principles apply here like "Don't criticize, condemn, or complain," and "Give honest and sincere appreciation," for handling people. Thus, saying it sucks would get you nowhere aside from some defensive developers that I don't think you want to make into enemies now do you?

I'd suggest asking some of the more senior people why they use what they do. There may be some surprising answers about things you don't know or didn't realize had to be done in a particular way. While you may think they are putting out crap, you don't know their side of the story.

Answer 7

Don't email them a link to this page... and hope they don't find it.

Answer 8

How about just correct tidbits of their ugly code here and there, while leaving a comment like "corrected for better readability (and sanity)." See some time later if they'll like it or not?

Answer 9

A couple thoughts.

First off, don't become the "complainer" of the group. While their code may suck (and I don't doubt it), only you will look bad if you just start spouting off how badly the code is. Worse is that you will only cause mistrust and anger among your team members. This is definitely not something you want to do as you will shut down the team.

Second - you mentioned that you were the most junior developer. A college student even. Well, one advantage that college students have is that they have some of the latest and greatest training that more senior developers may have missed out on. If your team has regular code reviews, or regular meetings discussing status, one thing you can do is take this time to provide insight as to another way to do something. Do not start spouting off about how bad the code is. Just provide gentle suggestions. It may be helpful to find individuals who seem open and willing to learn and try teaching them. Offer to do lunchtime sessions not targeted at any one person where you teach on various topics about software development. Not only will you get to teach members of your team (improving your team as a whole), but you will also put a good notch in your own career belt as a self-starter and that you take the initiative.

Hope these help you out. Good luck! This is probably a problem you will always be dealing with, so get used to handling it now while you're early in your career.

Answer 10

Getting Things Done When You're Only a Grunt by Joel Spolsky

(Strategy 4: Neutralize The Bozos)

Answer 11

Since you are at a student position, you have GOLD in your hands, called the master-disciple routine. Say you want to understand how they came up with those solutions and need more depth from all that awesome glory that comes from their fingers. Midway thru the convo, just ask what he thinks of this logical, organized and self-explanatory code you came up with, and watch them roll their eyes in desperation -- but since you are the disciple, they wont feel disrespected and will usually EVOLVE from those situations.

Successful case story of your life at your job

Answer 12

In my opinion, the best way to deal with people who are not performing well is to put them in a situation where they WANT to perform well. Fixing their stuff, telling them they suck, etc. is counterproductive. As the new guy, you bring a fresh perspective. The old guys are probably stuck in some ruts. Instead of trying to fix everything, go in with a genuine desire to learn what you can from them - ask lots of questions. Ask them what THEY would do in a situation. Discuss designs with them, even if you already think you have a great solution. Get them thinking. Chances are, you WILL actually learn something from them and they will learn something from you too. Then, instead of being the cocky new guy who changed everybody's code, you're the guy who got everybody thinking and improved the engineering culture. Sounds too good to be true, but it definitely worked for me.

Answer 13

lead by example

Answer 14

Right now, im in the same situation, but what i do, is for example if they aren't using oop, i found some helpful link about it's advantages and send to all of them in an email like:

"hey, didn't know about this advantages of doing it like this...."

The point is to let them know that you just discovered that better way...

In other harder cases, i will talk to the manager, and let them know we all need some capacity courses... or if you are both close to each other, talk to him sincerely...