should I tell my boss that my coworker’s work sucks?

by Alison Green on October 18, 2017

A reader writes:

I work as a web developer on a small team of four people, and we often collaborate on projects. It was just three of us for a while, and we recently hired a fourth person. He was hired primarily as a back-end developer, but also to do front-end work (mainly HTML and CSS) when we need him to.

The problem? His HTML and CSS work are terrible. This is his first “real” job out of college, so I understand that he has some catching up to do as far as honing his skills (as well as how he conducts himself in the office, but that’s another story entirely), but I don’t think that excuses his lack of front-end coding skill if that was part of his job description. I’m currently trying to jump in to help develop one of his projects, and I’ve wasted the past two hours trying to pick apart his code into something I can use. My other coworker has met the same frustrations when trying to use this person’s code.

My boss doesn’t often deal with this employee’s code, so I’m not sure he knows how bad it is. It took us a long time to find someone to fill this position, so I think my boss is just glad to have a back-end developer here at all. As new employees we are supposed to have three-month reviews with our boss to discuss our progress, but this employee was even let off the hook for his review.

Should I go to my boss with my concerns/frustrations, and if so, is there a professional way to do it that doesn’t sound like I’m “tattling”? My other coworker and I are incredibly frustrated by having to deal with the bad code, and wasting so much time trying to decipher it before we can do our own work. It makes it very hard to do our job when we have to spend hours cleaning up someone else’s code before we can add our own.

I answer this question over at Inc. today, where I’m revisiting letters that have been buried in the archives here from years ago (and sometimes updating/expanding my answers to them). You can read it here.

You may also like:
{ 71 comments }

{ 71 comments… read them below }

  1. ChaoticGood*

    I’m curious if OP knows – is the new coder is working to improve front-end skills? They don’t sound vital to their work. At my coding bootcamp, our typical course went from knowing near-nothing about a language on week one, to practicing it all day every day, to a “large” project at week five where we were expected to present competency.

    It sounds like this coder may not be up to speed on their non-primary skill is all, and OP might not be aware of whether their boss has skills-improvement planned. Lots of unknowns here.

    The how to conduct yourself in an office, though — that’s something the coder needs to get used to REALLY quickly. Adjusting to workplace norms for non-coding behaviors buys you a lot of goodwill, especially in tech where not everyone has people skills.

    1. CES*

      I’d be curious to hear your thoughts on coding bootcamps! Could someone without any formal programming education do the bootcamp then get a job? Do you think it was worth it?

      1. Annie Moose*

        I work as a web developer for a small contracting company, and we have some developers whose only programming education was coding bootcamps. I haven’t worked closely with any of them so I can’t comment on their skill level, but yes, it’s entirely possible to get a job after a bootcamp! I’d suspect you need to have a lot of self-motivation and genuine interest in coding, though. Most of our devs still come from the traditional university background.

        1. JM60*

          FYI, I’ve heard that these coding boot camps have very low rates of success. They either are too intense for most, and require too much motivation for most people, or they don’t prepare you enough. The youtuber Eli the Computer Guy said that when he used a boot camp that ends with taking a test for some kind of official Microsoft certification, he was one of only two people in his entire class to finish it and get the certification. The others just left thousands of dollars poorer.

          IMO, if you’re motivated enough to finish a decent coding boot camp, then you’re motivated enough to learn to vice using free guides that are readily available online. There are lots of free tutorials online, and many colleges will upload entire courses online. I went to grad school to get a masters in computer science in spite of not having any background in the subject prior to applying, and watching Harvard’s CS50 course on YouTube helped me get acquainted with the subject.

      2. BananaPants*

        I know that people do find jobs after doing bootcamps, but it’s not an educational path that my F500 employer considers acceptable for developers (ours all have a more traditional comp sci background).

      3. Chaotic Good*

        I’m sorry I can’t really speak to that here — it would be novel-length & would veer off topic & I don’t see it being helpful to OP

        1. Chaotic Good*

          …And I submitted that comment before realizing that many others had already addressed it. So – edit! I have nothing new to add that previous posters didn’t mention.

  2. Judy (since 2010)*

    This sounds like a good case for code reviews. That’s generally where the real learning of how to make understandable code happens.

    1. mskyle*

      Yeah, it sounds like he lacks a skill… why not focus on giving him the opportunities and feedback he needs in order to learn that skill? I mean, I think pretty much everyone who writes good code used to write bad code! If he has the opportunity to learn and refuses to, that’s something else, but if he just lacks skill, seems like it’s time to get him that skill.

    2. Jesca*

      Oddly enough, I was just reading this same question in the archives the other day. The comment section there had amazing advice on this and even with potentially what was going on. Code reviews seemed to be the consensus there.

    3. Annie Moose*

      Additionally, you can have him do code reviews of your code. At my first fulltime job, they had me do them and it was a great way to understand the codebase and see how more experienced programmers worked.

      2. Stone Satellite*

        Code reviews are standard for everything where I work. Even top-tier developers who have been with the company for years have to get another dev to sign off on their work before they can submit it. It’s formal and programmatically enforced here, but with only four devs it seems like they could just start a policy that all code must be reviewed before submitting. After all, even senior developers make mistakes or miss things, plus adopting and enforcing a style guide during review will make all of your code more readable for everyone. Around here we also try to make minimum viable changes, so if a change under review could reasonably be broken down into two or more different changes we encourage that, because it’s much easier to review changes to 20 lines over 3 files than 100 lines over 8 files. Just thoughts on a process that works for a large and successful software company. :)

    4. taco_emoji*

      Yeah this is a management problem–you shouldn’t have to fix his bad code, HE should have to fix it BEFORE it goes live, by going through a peer code review. And it should apply to everyone, not just junior developers.

  3. Gramarye*

    I hope someone is checking his back-end work too, in case this is a general lack of skill. I’ve been on a development team with an incompetent coworker, little review and a hands-off manager before – he wasn’t caught for months, and it took more months to find and undo the damage. In the end every line of code he’d written was updated – we literally would have been better off without him.

    1. Tau*

      Oh yeah. There are cold shivers running up my spine at the idea of a guy like this being let loose without supervision in a backend code-base. If he’s as bad as described, I have to doubt it’s just a front-end thing.

      1. Still Here*

        Yup. And backend code is usually more critical than frontend, as that is where most of a site’s security lives. Bad backend code can lead to Sql injection, attacks etc.. It also tends to be less fluid than frontend code that gets redone to every time the site gets a refresh.

        Formal code reviews are definitely a good idea. Should occur when the initial approach to each functional area is defined and then as needed for the code as it is written. Note that ALL modules need to be reviewed, no matter how small. A small function blowing up or leaking can wreak as much havoc as a large one.

        1. Still Here*

          To make it clear…. I know writing good frontend code takes a lot skill. But because the results are visible on screen there are less places to hide bad work.

      2. Anon backend dev*

        I don’t necessarily agree with this. I I consider myself generally a stickler for code quality (and I can’t imagine running a development team without doing code reviews), but I’m a backend developer, my HTML/CSS skills are crap because they’re neither relevant nor interesting to me, and I don’t think that reflects on my actual skill set at all. And if I were hired as a backend dev on a team that didn’t have any, but certainly does sound like it has frontend devs already — I would feel like I’d been the victim of a bait and switch if I got hired as primarily a backend dev with some incidental frontend work and then found myself in serious trouble at work because my frontend skills weren’t exemplary. They’re really very different skill sets from my perspective.

        1. cncx*

          i would be pretty annoyed if i got reported to my boss for something that was supposed to be my secondary skill set by someone for whom it was their primary, especially if there were more of them than there was of me doing primary skill set.

          I wonder how much the backend guy was told about how much of a percentage of his workload the front end stuff would be, or how important it would be to his overall duties. It could be that the job description was one thing, but the day to day realities of the job are another, and that is on the company not on this developer. I had a job like that once where i was supposed to be doing 90% paralegal work with incidental event planning, and when i got there, it was 90% event planning and 10% paralegal, which would be fine, except my skills in event planning were not as good as my paralegal skills. And it showed and people complained, and i was all, “you didn’t tell me in the interview i was supposed to be an event planner, you told me i was supposed to manage your contracts.” Sure, maybe the guy could get his HTML and CSS up but does he know he was hired for that? I sure didn’t know i was hired to do event planning.

          Not dogpiling OP here- i just think there needs to be some clarity with the boss and the team about potential training and code review and what the real job description of that position is.

  4. Game of Scones*

    I was once a front end web developer in a very small software development company, with one other junior front end developer and a senior back end developer. A new front end developer was hired because he had 10 years of experience and executive management wanted higher tier work.

    His.Code.Sucked. His business analysis sucked. His unit testing sucked. Everything sucked.

    The other developers and I kept it to ourselves for years, but we should have spoken up to executive management as soon as possible. The company, which had very little payroll cash, was blowing a high salary on a guy who made the rest of us work at least twice is hard to help with his work too.

  5. Chris*

    As a manager, I’d want to know, and it should be clear your comment is in support of higher team objectives, and not a personal grievance. Your manager may be relying on you for feedback, and if they’re not directly involved in production, they may never become aware of the issues unless someone tells them. How can you correct something you’re not aware is a problem?

    You could phrase it like ‘Hey, I know Fergus is new to this industry and I’m wondering how much support / training we should be giving him because he’s still learning? It’s impacting Bob and I somewhat in our productivity in that we have to correct his x and y a lot, I was just wondering, is this something you want us to continue doing?’

    Or ‘Hey, were you aware that Fergus doesn’t seem to know the accepted standards for x and y? I know our management expects quality and I’m not sure this is something I can correct from my role, but we’ve run into it here, and here, and here’.

    1. NotAnotherManager!*

      I agree with this. It drives me nuts when people know there is a problem and don’t tell me (particularly when I ASK how things are going or how a particular project turned out and don’t get accurate feedback).

      I am also a big fan of checklists and written processes/framework, too. I do a sort of work that needs to be zero-defect or pretty darn close, and they’re necessary to ensure everyone on the team is working to the same standard and that new people have a way to get on board with what we’re doing.

      This guy also needs his initial review so that he can get feedback and also provide feedback on the training that he needs. Ideally, feedback on his work would be provided as it is completed/reviewed, but he needs to know that everything’s not sailing along smoothly and be offered the opportunity to have input on the additional training/resources that would be helpful to him.

  6. A Front End Dev*

    This sounds miserable! Maybe even just having him run through the super basic codecademy course would help? I’m trying to fathom how you screw up HTML and CSS though… like, CSS has stupid problems but how hard is it to write readable code?? I feel like I’m missing something here.

    Good luck OP :(

    1. VC*

      HTML/CSS is one of many skills where it’s easy to pick up the basics, but much harder to master. You can easily slap together some DIVs, name some classes and IDs, and style all the things while avoiding technical errors. Writing production-ready HTML/CSS that does what the designer / UX folks asked you for while also being semantic, accessible, performant, scalable / easily maintained, properly scoped, etc. is another story.

      IME, back-end developers are frequently uniquely bad at it because they know “coding” but don’t know front-end conventions and best practices (or think they know better) and often attempt to port over principles they know from other programming languages that aren’t suited to HTML/CSS.

      1. Samiratou*

        And this is why they’re usually broken out into separate roles. Maybe he can be brought up to speed on front end conventions and whatnot enough to meet the need, but since it took so long to hire this guy, one wonders if the company had expectations beyond what is reasonable for one person to provide (at the rate they were willing to pay). If he was hired as a back end developer because that was more important then yes, management should be made aware of the lack of front end skills, but not necessarily in a “Bob sucks” way but in a “Since Bob’s main job is back end but we need him to be competent at front end stuff, what can the company/management do to help Bob improve front end skills to meet the need?”

        1. LQ*

          And it might be worth asking if he really does need to be competent at front end stuff? How necessary is it to the role? Was it a gee it would be really nice to have someone who can do it all? Are they 50/50? Could the job be just a back end job? (I don’t know that the OP can raise that question though…)

      2. k8*

        lol this– especially backend devs thinking they know better! If i had a nickel for every time a backend dev told me that it’s “just” css . . .

      3. A Front End Dev*

        So I’m indeed missing something! I’m early on in my career and in a small company with small sites that I manage (I’m the only developer here, my manager isn’t a dev of any sort). This actually helps me know more of what to expect as I move forward in my career.

        Thanks for your reply!

      4. Lise*

        ^ This. Also there’s a lot of stuff that “works” or is “good enough” in HTML/CSS that causes problems in large codebases, or in places where multiple developers are working on the same code. That one !important keyword you throw into your personal site CSS doesn’t matter much, but it will make all your teammates hate you if they ever have to override it in a large codebase.

        (I have so many pet peeves about back-end devs writing HTML/CSS. My favorite is the “I don’t understand block vs. inline level elements, so I’m just going to stick a break tag here so something drops to the next line”).

      5. Annie Moose*

        I’m a full-stack developer (that is, I do both front-end and back-end work), and honestly? I would be delighted if I could just work on back-end stuff. Front-end stuff is not that easy! When I’m nested sixteen CSS files deep and the frakkin’ third-level header on the search page still is six pixels too far right, I just want to throw my laptop out a window and go hug a database server.

        CSS and HTML are governed by esoteric laws of black magic, I tell you.

        1. hypernatural*

          Could not agree more. I also hate when trying to override a CSS style and think that my selector is more specific and should override and…. nope! Some other style is still overriding the new one I’m trying to make. And that’s not even getting into the nightmare that is @media and making everything look good at all screen sizes or trying to make anything work properly in IE…

    2. Corey*

      > I’m trying to fathom how you screw up HTML and CSS though…

      Yikes! If you don’t frequently see bad HTML and CSS in the wild, then you’re either not looking or we are a little closer to answering the “how” :) On the other hand, if you think those are easy to write, then you can make a lot of money cleaning up bad front-end code bases.

      > Maybe even just having him run through the super basic codecademy course would help?

      We might be talking about projects of different scales.

      1. A Front End Dev*

        When I initially posted my comment, I was thinking about it in my own experiences as a dev in a *very* small company with small sites and thinking about it purely from a technical perspective vs all the other things that can go into a project. So, yes, we were thinking about different scales of projects.

        I learned some new things today :D

  8. animaniactoo*

    I would raise it as “Now that I’ve worked with his code, it’s become clear that it’s something he can do, but not do well at this point and if we’re going to rely on him to fill in, I think there needs to be training for him in getting his code up to par. It created a significant delay for me to update my part when I had to unravel and redo portions of his code to make them cohesive with the rest. It might be very helpful for Bob or I to sit with him and show him our standard code-writing practices and what didn’t work well with the code he’d written. He’d still need some more training and practice, but it could be a good starting point.”

    1. Mockingjay*

      This is a really good script. It presents the problem to the boss in a clear, matter-of-fact way and follows with solutions the boss can act on.

  9. Snark*

    OP….you are not a child, your boss isn’t your dad or your teacher or the principal, this is not snitching nor tattling. I don’t want to be too harsh, but c’mon, my dude, you’re a professional in the workforce. “Tattling” is not a concern here! You’re doing work for a business that has business needs, your coworker’s performance isn’t serving those needs, and your manager needs to know about your coworker’s performance issues if they’re not in a position to directly observe them so they can, y’know, manage.

  10. Coffee*

    Allison, I think you’ve already published this question?

    Either way: it could be well that he was hired for back-end and so his front end skills are irrelevant to why he was hired. Most developers tend to specialize in one or the other.

    2. Game of Scones*

      “I answer this question over at Inc. today, where I’m revisiting letters that have been buried in the archives here from years ago (and sometimes updating/expanding my answers to them).”

    3. (Mr.) Cajun2core*

      Well, it seems like my comments (see below) aren’t really relevant. Apparently there is a major difference in back-end and front-end coding. I would have thought that good, readable coding skills would have been universal but obviously there is more to it than I realized.

  11. Ann O'Nemity*

    It’s becoming increasingly difficult to find someone good at both front and back end. Not quite a purple squirrel, but rare and expensive. (Let alone the majestic full stack developer.) If your company hired someone straight out of school to do primarily backend with some front end as needed… yeah, I’d expect less than stellar front end work.

    But that doesn’t mean the OP can’t talk to the boss the effects that the quality of Fergus’s is having – additional work for the OP, lengthier timeframes, delayed code releases, etc.

  12. (Mr.) Cajun2core*

    Disclaimer: I was an old 3GL programmer, so my comments may be inaccurate or may not even make any sense since the environment has changed so much.

    I also have to wonder how is his back-end code? Is it readable? If his back-end code is readable, can you use his good code there to show him what good code looks like to provide examples of what good code looks like and to train him how to do the front-end code?

    I also have to wonder, how he got through college without good programming techniques. Back in ancient history when I went to college and got my computer science degree, we had a class specifically on good coding techniques. We also had a class on end-user requirements and good front-end design. However, that was a couple of decades ago.

    1. k8*

      it’s been my experience that CS degrees are more theory-based? — but i might be biased since i have a ~non-traditional tech background~

    2. ArtK*

      I have a CS degree and I’ve seen the work of others with MS and PhD in CS and I can assure you that your experience is unusual with respect to good coding practices. In fact, almost nothing on development process and tools. I’ve seen a few capstone projects that included some of this but very often it’s an experienced student bringing the information in from the outside.

    3. SusanIvanova*

      I’ve lost track of how many programming languages I know, but none of them are even close to HTML/CSS. If I tried, it would suck, no matter how much of the techniques I tried to apply from other languages. Actually that would probably make it worse – the worst code I ever saw came from a guy writing in RPG who could only think in Cobol. (No, I’m not that old. The code was :) )

    4. Annie Moose*

      I wish my university had a class on good coding practices! Alas, I had to pick it all up on the job.

      We did have a class on project management, taught by my favorite professor, and it was incredibly useful. (especially because, at the time, I was interning for a large company, so I saw projects in practice on a daily basis)

  13. Miss H*

    “He was hired primarily as a back-end developer, but also to do front-end work (mainly HTML and CSS) when we need him to.”
    “It took us a long time to find someone to fill this position, so I think my boss is just glad to have a back-end developer here at all.”

    It’s possible he said in his interview that he hadn’t had much experience with front-end work and your boss hired him with that understanding. You do need to explain what the specific issues are to the boss and coworker so that boss can either take coworker off of front-end entirely, tell him to use X checklists, or have him take X training.

    Is it that his front-end stuff works on the webpage display, but it has too much excess in it and isn’t commented and/or following any style conventions?

    1. Boötes*

      Exactly. I was expecting to see a revised version in which Alison asserts that she encourages people to see a job posting’s list of qualifications as more of a wish list rather than minimum requirements. Since it took a long time to fill the position Bob may well have seen the posting months earlier and decided to give it a shot because it still hadn’t been filled.

      If Bob was hired with no deception on either side, ie Bob and the manager knew which skills he did and didn’t have, then dissatisfaction at Bob’s abilities is more of an indicator of your manager’s judgement than of Bob’s overall performance. In other words, don’t shoot Bob for his poor front-end coding when the manager may have said it was okay that he didn’t have that ability. It’s up to the manager to address the requirements that this employee apparently cannot yet fill.

      Other side of that story: more than once in an interview or application, I have been entirely up-front about skills I didn’t have. I didn’t expect to be accepted or offered the job. But I was. Then the people I actually worked with were surprised and annoyed that I couldn’t do X (in one case, because of a recently diagnosed medical condition I made clear to the interviewers, but which didn’t trickle down to the people I worked with / reported to). It reaaallly sucks to be on your co-workers’ / supervisor’s / manager’s shitlist despite having what you thought was crystal-clear understandings of capabilities & limitations in filling the role. That kind of tension, if not expertly handled, can induce stress and manifest in various, perhaps unexpected ways.

      On that note, did the job description match the salary? People with the requirements you need may well be getting jobs that pay accordingly more.

  14. Longtime Listener, First time Caller*

    I think one of the most helpful lessons I’ve learned from reading this blog is that if it affects your work, it isn’t tattling. This has helped me let go of things that are annoying but workable and raise issues with colleagues or management when necessary.

  15. Bryce*

    If his code is functional but not readable, it may just be that he hasn’t had the practice in proper standards. Fresh out of college, focused on backend, I can easily imagine someone who’s just done some quick-and-dirty coding on the front that nobody had to see the guts of. It’s hard to write good code if you don’t know what it looks like.

  16. k8*

    my major question is what the op’s code review process is like? i guess I’m wondering why the op is “pick[ing] apart his code into something [the op] can use”– imo, the OP and coworker should be providing feedback and the backend kid should be fixing the issues. ime it’s kind of a faux pas to be futzing with other people’s work without at least letting them know . . .

    1. Zathras*

      This. Identify the flaws and send it back to him to fix. If deadlines are an issue, make him submit his stuff for review well in advance. If the fact that his code sucks is going to cost you time, spend the time helping him improve.

      1. LQ*

        Agreed about mentoring being time consuming. But I think the question of bad hire would come in how much time should/is he doing this. If it’s 1 project a year and his back end work is excellent? Can you just move him off the front end work unless necessary. (Especially if it was very difficult to hire, which makes me think they aren’t paying enough for the position…)
        I don’t know that I’d jump to bad hire or maybe not jump to fire him, it could be a bad hire but there weren’t a ton of options so the best possible at what they were willing to pay.

        1. paul*

          And budget for the position.

          If your company is paying noncompetitive wages they should (IMO) be willing to mentor and work with people to get them up to speed in technical skills you know?

      2. taco_emoji*

        Sounds to me like bad process and POSSIBLY a bad hire. If there were code reviews in place, he would both A) read other people’s code & learn from it, and B) have them reviewing his code and pointing things out that he may not be aware of. If he goes through a few reviews and still isn’t improving, that would be a solid red flag that he was probably a bad hire, but at this point it’s hard to say.

    2. Student*

      This is so very wrongheaded, and such a common response. I have a hard time putting into words how much this bothers me, and why, but I’ll try:

      The guy needs training, if anything. Training is a thing you do to teach somebody a specific set of skills, so they’ll use those skills for you. Going through training can be either a punishment for not having a required skill up to snuff, a reward for somebody who is expanding their skills beyond basic job requirements, or simply a normal part of the job you have to do.

      Mentoring has an entirely different point and tenor. Mentoring is developing and supporting somebody so they can get a leg up in their career.

      This guy is bad at what he does! He does not deserve a mentor because he is worse at what he does than all his peers. The people who deserve mentors are the ones who are GOOD at their jobs and deserve to go further up in the company. Mentors are a reward. You don’t give special career perks to the slowest runner in hopes that he speeds up! This mentality of giving mentors to poor performers and “underachievers” gets you dysfunctional business where the people who “have so much potential but never quite live up to it” are in charge, and the hard workers are covering for their boss’s deficiencies more than getting useful input from the bosses.

      1. Kitten*

        I know I’m late to this post, but I really don’t agree with this.

        The OP clearly states that this guy is new to the working world, and that he was hired primarily to do a backend dev role. Mentoring is exactly what he needs here – someone to show him not only the code standard for their organisation, but to explain when he should be asking for help and who he can go to when he needs additional support. He needs someone to walk him, kindly, through the impact that his bad code is having on his team mates. These things might seem obvious to people who have held this role for years, but I think we all forget how difficult it is to transition between University and work.

        I totally agree that management should be spending development effort on people who are already doing well in order to push them to the next level, but that shouldn’t be at the expense of people who are struggling. There’s a difference between lack of experience and willful ignorance and without further evidence of the latter, I think this guy would benefit massively from some mentoring and support.

  18. Stranger than fiction*

    So, what if Boss acknowledges your concern but he hired Bob and Bob is a friend of his and has to balance CYA’ing to his boss with your concern?

  19. Tau*

    This is very helpful advice! So far I’ve always had someone more senior to hide behind, but I’ve been in the situation where I’m working with a fellow coder who is just… not very good… and I’m aware that there is zero way any member of management knows about this and I’m going “uh, what should I do about this?”

    One of the difficult things, I think, can be that the effects of good vs bad coding aren’t generally visible to upper management. Bad code doesn’t really result in things breaking apart in a flaming mess where it’s easy to point to the culprit. Instead, we’re talking a higher rate of bugs, it taking more and more time to do coding because it’s so hard to understand the codebase, it becoming harder and harder to add anything new without breaking something else… a lot of it is long-term trends, really. In fact, for someone technically inexperienced I suspect bad programmers can look like they’re good ones, because they don’t want to spend time on “unnecessary” things like code reviews or unit tests, they just toddle off and implement things when told instead of protesting that these things are a bad idea and should be done differently*, etc. It makes it hard to point out bad coding if you’re being supervised by non-technical people.

    * one day I will tell the story of how me and another junior developer ended up the last line of defense for good data security practices in a project that was dealing with super, super sensitive data. It still amazes me because this was absolutely not our job, there were so many layers of consultation and technical experts that proposals were supposed to go through before they reached us. And yet.

  21. Junior Dev*

    It’s an old question but the first thing I’d ask OP would be if they have standards for pull requests in their documentation. There are all kinds of resources online for HTML, CSS and JavaScript best practices; pick a style manual for each one, write up a document with links to the style manuals and tools you can use to check your own code, and enforce them in all pull requests.

    If your company can’t get it together enough to document and consistently use these standards, the problem goes far beyond this one employee.

    1. Daughter of Ada and Grace*

      Heck, some of these standards can be automated – we do it at my office. Tie a build server to your repository, set up some rules so the build fails if your code doesn’t meet those rules (say, no methods more than X lines, or requiring use of semicolons in JavaScript files). If the build fails, the pull request can’t be merged in, no matter what the other developers say. (The build should also fail if it doesn’t compile, or if the unit tests fail.)

      That means other developers can focus their code reviews on things that are harder to automate but easier for a human to read (descriptive method and variable names, ensuring the unit tests cover the right things).

      If one person’s pull requests consistently break the build, the other developers will absolutely notice.

  22. eemmzz*

    As someone with more industry experience you should be coaching this person and you could even try and improve your team’s processes. Look into doing code reviews and pair programming more often. I think you should focus on these things and not that someone new to the industry writes bad code.

  23. nonegiven*

    Boss was so happy to get a back end coder? Is his back end coding any good and the front end is the problem or is it all bad?
    They really are 2 different talents.

  24. Bea*

    I just had to have the uncomfortable conversation with my boss about my report who is struggling with doing their job. There’s still learning to be done so we’re still trying to keep our hopes up but this gives us a chance to address the issue with the employee. Now he has a chance to try to work harder to improve knowing he’s on watch.

    So it’s not tattling, it could help your coworker by looping in the right people. If anything it needs to be brought to his attention and see how he reacts. Some people are just bad at judging their own work and he’s new, much like my current problem child, so there’s a lot to be gained for everyone not letting him skate by and continue to frustrate you.

  25. Gray Bearded Geek*

    I’m in my 3rd decade of working in the software industry. Much of that time was in programming. Much at different layers.

    When I first started my career, I obsessed with following style guides and writing elegant code. That’s fantastic. If you can stick with that line of work, it’s much more enjoyable.

    Most business systems aren’t brand new development. You need to learn to work with others’ code. Ask ten developers if something is elegant, and only the author might agree. The other nine will have nitpicky suggestions for improvement, most of which are formatting. It’s rare to have a code review that unveils logical errors or performance problems. It’s all about how many spaces to indent and whether you should include spaces after parentheses or not.

    Some people just can’t write code. You need to learn how to deal with that. My guess is that the OP has a few years of experience. I’d guess less than 8-10 years. This lesson only comes with time and experience. My younger self wouldn’t have listened to a word I’m writing now. :)

  26. Trisha*

    Employees have to get away from this notion of “tattling”. If there are issues with fellow employees performance (like this example), how is your manager going to know if no one tells them. As a manager, I consistently tell my employees, it’s not tattling, I can’t fix what I don’t know. I can see and track people who come in late or don’t respond to requests or have difficulty with office culture but I’m not a subject matter expert – I don’t know if someone is quoting incorrect policy or legislation. Someone needs to tell me!

Comments are closed.