Image for post
Image for post
Photo by Christina @ wocintechchat.com on Unsplash

Working With a Really Terrible Developer

We recognize them. Managers often don’t.

Chris Fox
Chris Fox
Sep 26 · 7 min read

If you’ve never had this experience you have my envy. You’re on a development team and one of the developers does sloppy work and there is nothing you can do about it.

Time was when everyone in software from the first-day QA trainee to the executives had some experience at coding. That is long gone and now we have layers of methodology “masters” and managers who have never written a line, and who regard any and all complaints about others’ work as insubordinate and as personal conflicts, never considering the criticisms on their technical merits.

If I say that one of the other members of the group is doing shoddy work, even if I explain politely and in technical detail, managers hear “unpleasantness” and focus all their attention on team cohesion, which means I’m the one who gets in trouble.

Externalities

I was working until a few weeks ago on a distributed team for a company in England. One team member, whom I will refer to as L, not only did terrible work (more on this below) but on the daily Zoom status update was three times louder than anyone else in a voice that could etch diamond, made little effort to pronounce English clearly, and insisted on hijacking others’ computers with a compulsive screen-share that illuminated nothing, just so the rest of us could watch him wiggle his mouse.

He was mechanical. His reaction to any transition was always the same. His turn to talk? “Let me share my screen.” Get an error message? Take a screen shot. Explain a keyword? Another screen shot. Thanks, L, I didn’t know how to spell “foreign key.”

I came to dread the call because his abrasive and loud voice gave me a headache. While everyone else on the team had mastered English well enough to be understood, L moved the accented syllables of words in a way that reminded of why so many companies that outsourced tech support to his country are now moving it to the Philippines.

He was unresponsive to communication and made changes to interfaces and API behavior without informing anyone of them. Since we did not have code reviews, which I tried hard to spearhead, we only discovered these wanton changes when things broke.

Worst of all L appeared to get cognitively rebooted every few minutes. This company had its Git branches set up all wrong, two “master” branches in the same repo, one for the front end and one for the back. My cryptography work was in a branch off the front end “master.” We had been talking about the branches by name for about ten minutes, and it was clear as could be that I was doing my work in “frontend-crypto,” which we had both mentioned many times.

He suddenly asked me, apropos of nothing, “Chris, which branch are you working in?”

This sort of thing happened many times and managers would patiently explain to him what any eight year old could have followed. They could see he wasn’t tracking but for some reason it was only a problem when I expressed my frustration at having to explain simple matters over and over.

Bad Code

I usually work in the C family of languages and in web development I write in C#. I had to learn JavaScript, Python, and Django. I ended up working almost exclusively in JavaScript and in the front end. I am usually a back-end developer; in this project L did all the back-end work.

He did a lot of work, all of it very low quality. In addition to industry standard illegibility he did the absolute bare minimum in rigor that he could get away with.

I needed a new API, one that would return two or more rows for recipients who may or may not already be in the database. I didn’t know Django well enough to do it perfectly, not knowing where Python ends and Django begins (I really dislike Django, it shows no coherence or idiom), but I wrote out all the logic and status codes.

Suppose I called this API seeking the encryption keys for ten people. Here are the number found and the HTTP status codes in my original bad Django:

Number returned    HTTP code
10 200 (full success)
1-9 206 (partial content)
0 204 (data not found)
server exception 500 (exception)

If the response had fewer rows than the number requested I returned an array of their not-found identifiers.

I turned it over to L to fix up the Django syntax, not to rewrite it, but this is what he did:

Number returned    HTTP code
10 200 (full success)
1-9 200 (wrong)
0 200 (wrong)
server exception 400 (wrong)

So even if not a single row was returned, he called it a complete success, and he removed my array of the rows not found, so the client had to enumerate the returned data, compare to the request and determine which ones didn’t come back. And a server exception returned 400, Bad Request, which was completely wrong.

This guy was supposed to be their back end expert. I expected him to know these codes; I don’t know every single one of them but I know the dozen or so most common ones. And even with the logic and intended status codes right in front of him he threw it all away and did it “his way.”

To be fair there are multiple schools of thought on how to handle intermediate levels of API success. I almost never see any 2XX status code other than 200; that and 500 are the only codes most developers return.

It would be charitable to allow that L had his own approach that was different from mine; in my view we have more than four status codes for a reason, and I use them. I knew however from months of working with him that he had just copied and pasted in 200 for all of them; he left my sieving logic for the cases above (0, 1–9, 10) but pasted the same line without checking.

In any case an API is a transaction and if he changed the behavior it was incumbent on him to inform me or whoever was issuing the call, expecting these more detailed status codes. Not only did he fail to do so, he never answered me when I asked him about it. This isn’t teamwork. This was a pattern in working with him. Since this project had no QA it would likely have been customers who first saw the holes in the logic.

I was furious. I had done it all correctly except for the Django syntax which he could have fixed in under a minute, but instead he rewrote the whole thing with significantly altered logic. And of course his code looked like a pair of cats had fought on the keyboard.

I tried asking L why he had made these changes but when he ignored me as usual I asked the managers for a conference call. I showed them what I’ve written above. They tut-tutted and said they would talk to L about it. I don’t think they did, because two weeks later it was still unchanged.

And they paid this guy.

So if they didn’t talk to L then they probably decided I was bringing conflict to the team, though they never told me so. This was my last item in the work, all my stuff worked except this mangled API. I was done. With three new languages under my belt and experience in a really cool cryptographic implementation.

I didn’t bother talking to L again. What would be the point? He had done a bare minimum lousy job and in his work ethic that was just fine. In previous debates on design he had contributed nothing. I could have mentored him but I knew from months of working with him that he would have ignored me and gone on doing things the way he was accustomed: sloppy, shoddy, and illegible.

Managers Who Don’t Know Code

As with so many who say that “people skills” are more important than “coding skills,” the managers on this project were more interested in keeping things nicey-nicey in the team than in doing a solid product. Since this was a very security-centric application it was more vital than usual to do the most rigorous job possible, but they allowed L’s sloppy rewrite to remain.

Their attitude toward my report was probably that there was some “friction” between me and L; I got along fine with everyone and managed to mask my frustration with L and his mysterious context-loss episodes and godawful code, and my part was about done so not much came of this.

This is what comes of regarding software development as a social activity. It sure as hell isn’t engineering yet.

But had I been the development lead, L would have been looking for another job.

There is a continuum in the software development work ethic; the two poles are

  1. Do it as perfectly as possible and to hell with the deadlines
  2. Do as little as you can get away with and make clearing your task list your only priority. Take up the slack by writing unit tests (which we didn’t do).

L and I were at opposite poles of this continuum. Stir in his disinterest in communication and we had a mess.

The Startup

Medium's largest active publication, followed by +719K people. Follow to join our community.

Chris Fox

Written by

Chris Fox

American Software Engineer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

The Startup

Medium's largest active publication, followed by +719K people. Follow to join our community.

Chris Fox

Written by

Chris Fox

American Software Engineer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

The Startup

Medium's largest active publication, followed by +719K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store