Ask HN: What to do about a client's bad programmer?

I freelance and previously full-time frequently in this situation. What I always try to do is bring the developer on my side, establish lead and get a champion for you internally.

If needed discuss with the client that you need more money or a higher hourly rate or hours set aside for each new implementation to go over it with internal staff. He already sees you as the lead so this is in your favor. This tactic is much more difficult if they believe their internal guy is competent, who isn't as competent -- very easy to fool bizdev level folks with low rates/visual when the backend is horrible.

Also, you never know what that internal guy is going through. He could be consistently crunched and make way less. Usually internal guys have alot of other tasks that almost make it difficult to code in an efficient way. I like to see everyone I work with as a client, treat them like that and it will pay back. Just make sure you are getting your value you put in, don't do it where it starts to harm your income or the project you need to deliver.

What you never want to do is create an enemy internally. You also have a chance to mentor someone a bit. Use that to your advantage which will also help the client. Not only will your project be better but internally you can improve the company. Remember you are a solution provider, they went externally because they have problems internally. If it drags on you, just ask for more money and show the increased workload in a nice way, if that is not respected then sometimes you have to let a client go.

Thanks. You are absolutely right and this is the right answer. I just need to decide if it's worth the time or if I exit, stage-right instead.

EDIT: ideally, I'd find someone to take over for me, and I'd keep the client in my consultancy, just not my responsibility. But I've had poor luck finding anyone willing to go come on fulltime for me.

It's better to 'lose the job' by raising your rates than to just flat out quit, because it lets your client save face. Telling them that their work is so bad that you refuse to work with them doesn't. So just pick a number that you don't think the client will be willing to pay and that's enough to take away a little of the pain.

Then the worst that can happen is that they pay your unreasonable rate. But it also means that the relationship has changed and your input is recognized as much more valuable, and therefore more likely to be heeded in regard to staffing. And by "worst that can happen" I mean that you will be paid two or three times as much as before.

On the other hand, if they turn your new offer down, you've essentially quit with no downside other than "we just can't afford it anymore." Not really even a burned bridge since they pulled the plug, not you. So long as you couch the change in rate as a simple evolution of your business based on the changing marketplace, they've got enough BS to rationalize their decision.

Good luck.

My advice to you is always have clear cut phases/projects.

Always break it up and phases usually last 1-6 months. You always have the opportunity to ask for more or move on more easily where needed, but you never leave a client or project on a bad note but a delivery and approval/payment cycle.

Never do some ongoing job like project that is just time with no clear cut deliverables. Have deliverables and get those approved at each stage in writing. Do not start the next stage until the previous is paid. I learned this one the hard way with a good client for years that became a bad client really fast when I believed they would pay after a 4 month project, it was my 30k stupid tax but also improved my processes and agreements.

This is good advice, but also a bit cold-blooded - can money compensate for anything? I know for me it can't.

I once thought like that, until an accountant friend shared his point of view on the matter.

That project you don't want to do, what amount of money would it take for you to accept that project? I'm not talking about what you think is a reasonable amount based on the work involved, put those thoughts aside. How much money would it take for you to actually be happy accepting that task? An extra 150K$? 500K$? 1M$?

Because that's what you tell them your price is. They can shop around and go elsewhere if they choose, but don't immediately respond with a flat refusal, because this is an opportunity for a win-win.

It can't always, but like I mentioned, if it is too much you can move on, but never leave them high and dry.

Money always at least temporarily helps and I happen to be a guy that likes to help see things to their agreed on goals even in some cases where I missed out on better projects or it has cost me. More money can get you through to that next, nicer time to move on.

Typically freelance/outsourced projects don't last years, more like quarters. Sometimes it is not worth it 100%, but as a professional I typically finish the round I am on. Then the great side of being a freelancer is you can make yourself unavailable for future phases if it actually harming your business and or is an un-winnable battle. There is always some amount of battle in work though.

In the end it is money, I have had lots of great clients and fun projects that have lost me money over the time I have put in, or over other project opportunities, to see things through with current projects. I typically move on from ones that do that unless it benefits me in other ways. I do projects to help fund my own projects, so sometimes work is just work to fund that and make that happen.

Compensation is not really the point. Anything that'll affect the bottom line will make a business seriously consider what you have to say.

It sounds to me like there are cultural/organization issues that are very problematic and I would start the process of moving on. This particular programmer is probably just the icing on the cake.

That said, if what you really want to do is fix the behavior of this programmer here is my suggestion:

- Institute mandatory code reviews for all commits for everybody. There are any number of great tools for facilitating this and it is good practice anyway. Not everyone has to approve every commit, but at least 1 person must thumbs up before it can be merged.

- On this particular programmers commit, you have to code review and comment on everything. Say things like "strongly typed objects are idiomatic C# code, we should follow that" or "this seems like it might have performance problems" or "hey I'd do that 'this way'".

- If this is problematic, institute code standards for the whole team. Have the terrible bike shed discussions and make him make his bad way the standard for everyone if he wants it. This will enlist others in your cause (and probably make him realize how bad what he is doing is)

- Don't let other people fix the bugs he introduces. As soon as you find one, document it and give it to him to fix. If the ORM is not providing value, his argument is valid, but likely he is arbitraging the pain of using the ORM initially by making others maintain his nonsense. Don't let him do that.

Four things can happen if you do this: - he gets tired of the crap and quits - he gets tired of the crap and gets you fired/to quit. - he gets better - he never gets better but the code isn't impacted and you make it obvious to everyone on the team what a drag he is.

There are three kinds of people:

1) those that understand and discover new things by themselves

2) those that understand when being taught by others, and are willing to learn

3) those that don't understand anything, ever - they are unwilling to learn and incapable of following other people's arguments

Looks like your guy is a solid 3. He will remain bad.

Basically, it boils down to:

- how much do you hate your job because of him? Can you change the way you react to this circumstance, by mentally re-framing it in a way that makes it less annoying?

- how easy is it to find a new gig?

Of course I'm not telling you anything you don't know already. I personally hate working with 3s, and their presence is a sign that engineering excellence is not a focal point in the organization. Also, envy and resentment are potential issues that might ensue.

I've worked with people like this, and it's very tough indeed. My Advice is to not get emotionally invested in it; you can be the best coder you can be and set an example, but you can't make someone care who doesn't. If he's just unsure, branch off his work and show him a diff of what he's not doing that he could.

You can beat the drum and push for better, but if you push too hard or nag you'll meet more resistance. There are many cases where I've made a case for something, had it shot down, only to see the same or similar being decided as the direction a few months down the line.

But really, just let it go emotionally. If he's writing code that is problematic and his boss doesn't care, then you shouldn't care. Then again, you are the technical lead. So, who is responsible when something goes wrong? who's head is on the chopping block? because that's the person that gets to make the call. If that's you, put your weight into it and do not let up. if that's your client, advocate for best practices, but accept that some people need to go their own way.

He could prefer SQL over ORM due to knowledge about object relational impedance mismatch, I often prefer SQL over ORM for lots of use cases. Maybe you could get him to use a query building API that handles escaping user input for him [like an ORM does], but still allows him to work in SQL which is preferable to ORM in many cases. For example if using PHP: https://github.com/jstayton/Miner

Actually, we use an ORM that is just SQL. I learned a long time ago that I couldn't trust most of the developers I worked with to dispose their ADO.NET objects properly, and that given an inch to concatenate strings, they'll take a mile of SQL injection. So years ago I developed a system around const strings (defined in attributes tagged to methods, so you don't have any option, the string must be constant) and reflection.

It's exactly, 100% the code you would write if you were writing ADO.NET code from scratch. It just doesn't give you the option of screwing it up. Stored Procedures get created automatically. You can prototype queries as text queries if you want, before flipping a switch to make them SPs. You don't have to worry about matching parameter names in the SP declaration correctly, because it's drawn from the method signature. The result sets map out to plain, ol' C# classes with 0 effort. And it all runs fast, because it doesn't do any sort of graph traversals to figure out type mappings. It just takes the first layer of reflection and runs the entire mapping against that. Not enough overhead to ever worry about.

And he'd rather be super verbose and just write his own ADO.NET code, for no benefit and a whole lot of error.

We're talking about .NET here and plain ADO.NET that comes with .NET will safely handle query parameters in raw SQL if used properly (DbCommand.AddParameter() etc). I suspect that the developer in question was simply concatenating the parameters with the command text string. He probably just never bothered to learn to use the runtime properly.

That is the case. He creates a SqlCommand object and then concats the parameters he wants into the query string, rather than adding a parameter to the query, or creating an SP.

A rule in life: ruthlessly stomp on the maladaptive tendency of our brains to try to expand the scope of our responsibilities beyond the scope of our power.

If you were the boss of this company, it would be your job to do something about an incompetent programmer. But you're not. You're a freelance programmer. It's your job to write code. You've raised the issue with the boss. He has decided to keep things the way they are, as is his right, even if he's mistaken; he's the one signing the paychecks. That's all that was up to you to do about it. Having done that, your job is to write your code and let the other guy write his code.

That's shortsighted. Eventually this bad code will be the responsibility of the freelancer (who at 3 years in is more permanent than most of the other devs it seems).

Another reason to take care of this now and be a "team player": making the company more successful ensures a renewed contract.

You're missing the point. He has no authority to take care of this now. Continuing to nag the boss after he's already been told 'no' in no uncertain terms not only won't make the company more successful, it will make him unhappy, get him a reputation as a troublemaker and not a team player, and possibly end up getting him fired.

That's been my big hold-up. I've always believed "I succeed when my client succeeds". It's hard to think of leaving. Leaving--when I know they don't have anyone to replace me and their hiring process won't likely winnow out a suitable replacement--feels like abandoning them.

Have you communicated to the boss in a rational way that this is such a big deal to you it would cause you to leave? Or have you just told them the other guy isn't good.

This is how I typically approach these types of problems....

Ask yourself if you're ready to see this through and by that I mean every possible outcome including leaving or getting fired or potentially getting the other guy fired. That means assessing your financial situation, possibility of getting more work etc. to me the logic goes that if this is such an important thing then I should be willing to accept all outcomes as this is the Right Thing To Do. It might seem a little melodramatic but it forces you to ask yourself hard questions.

Then, approach the boss. Tell him that you heard what he said before but the quality of your colleagues work is such that you can't stand over it and it's affecting everyone working on the project. If you end up having double standards for the code it brings everything down to the lowest common denominator.

My next option would be to bring a _solution_ to the table as opposed to just a problem. Let's bring in code reviews and I'll work with MrProblemCoder directly on his reviews one on one for a few months to try and bring his standard up. However, you need management backup for this. Maybe you don't even want to single him out, maybe you sit down collectively once or twice a week to do group reviews and breakouts afterwards. Maybe Friday afternoons are review the review days. The big thing here is that you want to make clear to the boss that there is a Significant Problem in a clear, rational way and have him understand the impact of it. Try leave your emotion at the door. Then present a solution which involves the group taking collective responsibility for the code quality with you leading the charge, but that management must back up and present.

If the outcome of that conversation isn't positive, then you have a management who doesn't care about quality and more importantly doesn't trust what you're saying about the impact. That would make it much easier for me to walk away as I now understand they've chosen the next path for themselves.

If you're not ok with that path then you could still try "influencing" these types of initiatives over a longer period of time instead of entering in to brinksmanship. Institutionalise code reviews for a portion of the team and show less bugs/rework and show the cost of crappy code. It's a softer approach and may take months and months of collecting data and influencing your colleagues.

These situations are not easy unless you're actually in a position to institute change directly!

Others have covered the possible approaches to talking with the developer and the boss pretty well. Aside from that, I just wanted to point out that the only big worrying issue is the SQL injection. I would focus on this above everything else. You may have to show the client why this is a big deal.

I've found that many businesses are willing to put up with less performant code. If they're getting the same functionality for a lower price from a less expensive developer, they consider that a win. In many cases, it's actually hard to write web code with performance bad enough that a client will care.

I wouldn't just fix the developer's mess for him. I would definitely tell the boss that you're willing to fix the less performant code for him, but unless the website has a 2+s response time or crashes every day, don't be surprised if they say no.

"One of his programmers in particular--who is currently his most-senior on-staff programmer--is bad."

If you have a good relationship with your client make your concerns known and the consequences (price). A good client will take this in and may give you some insight. Give yourself a set time-frame or project. Wait, see what happens. If nothing happens, increase your prices adjusting for the losses and get a new client.

From browsing comments, I'm thinking that maybe your desire to quit is what's really at play here, that it's what's mediating your relationship with this guy, who's being related to as basically an excuse to quit.

I mean if you were being paid well, and if you don't have much equity if any in the company, and if this guy is not getting you in trouble, I wouldn't be bothered by his incompetence, even if it slows you down.

If you can afford to do so, quit. I think that's what you're getting at, and you seem talented enough to jump on other promising opportunities.

I've also dealt with this in the past. I would make sure that the boss knows that the in house programmer is slowing you down and continue encouraging him to improve and adopt some better practices.

You don't want to call him out but you also don't want to look like you aren't getting any work done. If you are getting paid by the hour and can deal with the headache, you are getting the better end of the deal anyway. If the boss knows that, they might be more likely to do something about the situation.

Good luck. It is a tough situation.

I'm gonna take a wild guess and say software development is not their business focus.

I hate to say this but his response to you is a huge red flag and if I were you I'd seek a new gig. I might be looking to much into it but that statement is pretty backhanded and either he doesn't like you, doesn't care, or he's an idiot. Now, you can suck it up and stay, but you're miserable. I think you know what you want to do. Just do it strategically and you'll be fine.

Just fix the code, and try and continue to try and educate him as to why your way is better. Quitting seems out of proportion, especially since you are a freelancer.

Also, try and understand where he's coming from. Just laziness? Hatred of ORMs? Something else?

We've discussed these issues before (back a year ago when I viewed him as just inexperienced but promising) and he seems to think C# is a bullshit language, that C++ would be better. But judging from the code he writes, things would be much, much worse for us if we were working in C++. He doesn't just write C++ in C# (which would be bad), he writes bad C++ in C#.

He just... doesn't seem to learn. It's not so much that he makes mistakes, it's that he makes the same ones. He will change for a little while after I talk to him, then revert back to really, really bad practices.

I mention quitting because I'm bored of the project and just wondering if it's not time to move on to greener pastures.

when money involved and clear for both side, quit is an option.

https://news.ycombinator.com/item?id=9628477

When his code causes problems I wouldn't fix it directly. Put the fix as a comment in the bug tracker and kick it to him. If he can directly see what he is doing vs the correct way and why the correct way is correct, maybe he will take a hint.

I see these types of comments a lot and I do understand the logic of them. Most of the time it's devoid of sentiment. It's us engineers going "hey, there's a problem, this is the solution". This input causes this output. Problem? Open bug, assign to problem developer. I'm extremely sympathetic to it though as this would have been the way I dealt with this problem. Not only that but there's still a little bit of me that goes "yeah, right on! Shit code, shit coder! Make him clean up his own mess!"

The problem here is it's passive aggressive and doesn't actually communicate the issue to your colleague. The fact he's producing bad code probably isn't something he gets up to do every day.

The first part of any situation like this is clear communication. Talk to the person and you may have to do it dozens of times before it gets through. That doesn't mean the equivalent of throwing a bug report at him "Hey buddy, your code is shit. Fix it!"

He's a colleague. Sit down and talk through some of the code. Note your concerns and offer to help. Have clear and precise examples of your concerns, maybe presenting him with evidence. The first reaction any sane person is going to have if someone approached them like this is embarrassment and they're probably going to get a little defensive. Know that going in and tailor your conversation appropriately.

Enter in to the situation with some level of respect maybe even if that person hasn't really shown that he's deserved it.

Possibly, he'll never change, but I've seen enough people get better through coaching, mentoring and encouragement to know it's just as likely he'll make an effort if approached in the right way.

I saw it more as mentoring by brick. Op has already tried to talk to the guy, but he keeps making the same mistakes. Teaching by example may help him to remember that certain constructs lead to certain issues because he has seen the bug reports, and how to handle them.

Op is a contractor, not a life coach. I doubt his contract includes a large number of hours for mentoring. Maybe he could request them?

Everyone should be a little bit of a life coach :-)

Thanks, HN. You really helped me think it through and get my head on straight before lighting up his inbox unnecessarily.

Your third options sounds real good for a freelancer. He is giving you a pay-check, albeit indirectly.

Yeah, if I calm down a little bit and try to think rationally, I start to think that way, too. I'm a little flustered right now because we've been having problems with performance on the project, problems I've been tasked to fix, but they keep pulling me off of it to firefight stuff that turns out to be the kid's fault. I'm just worried I'll end up spending all my time fixing his code and my client will wonder why the big features he expects me to build have ground to a halt.

And I've been on the project for 3 years now. I'm pretty ready to move on. I'm not really getting anything of personal development out of it anymore. I've been working in VR stuff on the side and a LOT of people have expressed interest in my work. But I just don't have the momentum to do that fulltime yet.

This is probably why he's their senior programmer--everyone else is too busy fixing his shit to appear productive while every feature he adds eventually ends up working great.

I would say you should leave. The programmer doesn't have a clue, most importantly the client doesn't have a clue, and it's seldom if ever worth the emotional, spiritual and mental toll to try to fix such a situation.

On the other hand, if he could get this guy straightened up, not only is that an awesome skill to possess (can you imagine working for/with someone like that, it'd be awesome), but he'd be doing his client and the bad programmer a huge favor.

Deleted comment

You, sir, have made my day.

This is... appealing.

Just out of curiosity, does this developer seem panicked or overwhelmed?

I don't know, I'm not on site so I can't see what he's like. We've been fine with the 100% remote situation for about 3 years now. I don't really know when things started to go sideways, because we were supposed to have been transitioning the majority of work off of my plate (which seems to have just meant they don't tell me about some 10% of things). It's getting weird.

I'd probably feel panicked and overwhelmed too if I were in way over my head but felt like I had to save face because some hotshot freelancer was brought in.

Sometimes it's not the problems you point out, but how you point them out. (Not saying that this is what is happening in OP's case, since it's hard to judge from a paragraph or two.)

I started the project 3 years ago. He was hired in about a year ago.

If I were on-staff, I'd be the most senior programmer, and I'd be the first person to last more than 2 years in a long time. I think the freelance arrangement actually helps insulate me a lot from the weird culture of the company. I've been on the project the longest, and I have more experience than any of their other developers combined.

I also charge more than twice what they pay them, combined. Which is still not a lot. Turns out they hire these people off of Craigslist and then don't pay them very well.

> I also charge more than twice what they pay them, combined. Which is still not a lot.

So why don't you do what you paid for which is also to clean up code? I ask this because I'm a low rate programmer who usually know someone like you. Programmer like me being paid to get shit done. The code produced is what it's worth.

Because I don't want this to be my full-time job again. I was only doing this part-time, and the rest of my time I've been spending on projects of my own design. If I have to take care of my tasks and clean up after someone else, then there isn't enough time for my own projects.

why fight the client ignorance? as long they paid you okay.And as long they dont interfere or mention the bugs of the system you created. okay.If they started to take lawsuit then diff matter.