should I tell my boss about our new coworker’s low work quality?

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 the 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.

Here’s where I need your help. My boss doesn’t often deal with this employee’s front-end 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.

Assuming you have even a halfway decent manager, this is something he’d want to know about. And frankly, even if he’s not a halfway decent manager, he still needs to know about this because (a) it’s a problem affecting your work and (b) it’s his job to do something about it.

You’re concerned about tattling, but that’s not really a concept that applies here. You’re not reporting that your coworker was five minutes later or making a lot of personal calls or complained about your boss behind his back — you’re raising a significant work issue that’s getting in the way of you being able to your job. That’s not tattling. That’s surfacing a problem that need to be solved.

Go talk to your boss and say something like this: “I’m concerned about the coding work Bob has done for projects X, Y, and Z. What I’m seeing is _____, and the impact that’s having is __________.” That second spot might be filled in with the amount of time you’re spending fixing his work, delayed projects, or so forth.

This should trigger your boss to take a closer look at your coworker’s work. But if your boss is a bad manager, it’s possible that he’ll try to avoid dealing with the problem — by excusing the problems as just being the result of Bob being new, or telling you to to just keep helping him, or by making vague noises about doing something about it and then not actually doing anything. If that happens, then you need to go back to your boss. This time, frame it as asking for advice. For instance: “I’m not able to move forward on Project X because of the number of errors in the code I received from Bob. How would you like me to handle it?”

There’s one other thing you might try, if you’re willing, and that’s talking to Bob directly. It sounds like he’s not getting a lot of feedback from your boss. Are you willing to give him some? You might be doing him a real favor by mentoring him a bit and seeing if that makes a difference. If he doesn’t have the skills, then he doesn’t have the skills — but sometimes people need to clearly hear about how their work could be better in order to realize it’s something they need to focus on fixing. And that’s especially true when someone is right out of school and isn’t used to doing professional work at professional standards.

But you should be keeping your boss in the loop, either way. This is something that he’s responsible for handling.

{ 65 comments… read them below }

  1. The IT Manager*

    #1 I just agree wholeheartedly that this is not tattling especially when you take your own work time tryng to fix his poor work and this will delay your project. You should definately alert your boss to the issue. He needs to be made aware.

    #2 That said be prepared that even a conscenious boss may not act to put the guy on a PIP or fire the guy because new guy was hired to mostly be a back-end developer. If he has good back-end skills, the HTML and CSS coding may be a very far second in the job requirements. You boss should be aware and make adjustments to his expectations for your projects and maybe get this guy training, but your boss may not be willing to give up a good or decent back-end developer he found to fill a hard to fill position because he lacks skills in the secondary job requirements especially when that sceondary job already had three people assigned to do it full time.

    1. Anonymous*

      I strongly agree with #2 here. I would first make sure that everyone’s understanding about what front end work as needed actually means for the new hire. More often than not in this type of work, the understanding is that “front end as necessary” means only doing what is needed to get back end data to where the designers can use it to build the feature, leaving the building of the front end functionality to the specialists.

      1. Jessa*

        Yes but if that’s the case this person should not be tapped to work on that if they can’t do it. Find a way to re-shuffle the work so that this person is doing the back end stuff and someone else is doing the other code. Can this person be given parts of the OPs work so that the OP or someone else qualified can take on the front end code? Either way the employee shouldn’t be allowed to suck all the work and air out of the OPs life. Something has to give. And a good manager finds out how to allocate this stuff so it does.

  2. CF_programmer*

    Agree with IT, above. Also, it might be a good opportunity for you. If you approach your manager with your co-worker’s problems and immediately present a solution: you being willing to mentor and train him shows your ability to manage. That’s the first step to a promotion, should you wish to move to management someday.

  3. Judy*

    Do you not do code reviews? That’s good for him to see how your code is and for the rest of the team to mentor him in his code.

    1. Joshua*

      Yeah, a fresh college graduate having relatively bad coding skills/habits is kind of the norm right now. Most programs aren’t really preparing them for working in the software programming industry in general and especially not web development. If you’re not already, I would strongly encourage you or your boss to give the guy some feedback on his work product and see how he responds.

      If for some reason you or your company don’t want to mentor coworkers/employees, then you should probably not be hiring fresh college graduates.

      1. Amber*

        Agreed. I would expect as a first job out of college to come with a lot of training. You guys got what you paid for, expect to do a lot of training. Help him and teach him how it’s done. Like Joshua said, if the company isn’t ok with hiring people that need a lot of training then don’t hire fresh college graduates, instead hire mid to senior level workers.

        Remember you get what you pay for, there is a reason his pay check is small.

        1. Judy*

          What was said below, I really agree with. I’ve “trained by code review” so many software engineers over the last 20 years. In school, you write one program, then write another. It’s rare that even within a 16 week class you keep building on a project, usually you start over on the next assignment.

          Understanding what makes code maintainable, testable, reusable, etc, etc takes a while to learn. This person needs to see your code, and you need to see his.

    2. Neeta*

      My thoughts exactly.
      If your colleague is a beginner, and to your project, it would be good to make sure his work is up to your team’s/company’s standards.

      Of course, like Judy said, this is also a very good practice for all team members. It’s always possible to miss little things, that a second pair of eyes can spot.

    3. Colette*

      Completely agree. Someone who is just out of school won’t understand the difference between code that works and code that is maintainable.

      1. Windchime*

        This is such a good point. I have found that programmers who are not accustomed to working in a team environment will often do things in a way that works for them as they work alone in their “silo”. But once they join a team, it can be difficult for them to start understanding the difference between “it works” and “everyone can read and maintain my code”. This is a skill that is learned; hopefully your guy can learn it with some mentoring.

    4. Vicki*

      In all of the companies where I’ve worked, one of them did code reviews.

      So many companies seem to think they don’t have time for code reviews.

      1. Windchime*

        We are struggling with this right now on our small team. I would rather see a 1:1 type of peer review, but others on our team feel that it should be done with the whole team. In the past, I have seen that turn into, “Let’s all get together and tear Mike’s code to shreds while he sits there and feels embarrassed and ashamed”.

        1. Pandora Amora*

          Why not let individuals choose which style of code review they prefer to receive? If someone wants the group experience, give it to them; I would question why they think their preference should be pushed across the entire team, though.

  4. A Reader*

    It may not be useful in this case if your manager decides to keep your co-worker on, but I work for AVID Technical Resources, an IT recruiting company that you might consider recommending for the future. There are a lot of IT recruiting companies out there that aren’t particularly reputable, so I don’t want to be pushy if your initial reaction is a knee-jerk “No thanks!” We’ve got 100 4 and 5 star google reviews, though, and I think if you check out our website (www.avidtr.com) you might find us worth a look. Feel free to email me directly if I can be helpful to you, too. samantha.keefe@avidtr.com. Sorry for the plug, but it seems like it could actually be useful in this instance….?

  5. Briggs*

    Unless the guy is oblivious, or using a conversion tool to convert photoshop templates into html/css, then he’s probably concerned with his output and feeling a little internal stress. I’m actually a little concerned that he hasn’t brought this up himself, which leads me to believe he might be oblivious.

    On the other hand, if I knew I was turning in sub-par work, I would be very grateful if I had a coworker or manager offer to help me improve in this area. If you have the time and are so inclined to help, you could turn this guy into a very grateful and loyal coworker.

    However, if this problem is majorly impacting deadlines and project quality, you might need to start looking for a replacement NOW. It’s asking a lot for someone to be proficient in half a dozen coding languages, and you might even be better off outsourcing your occasional overflow to an independent contractor who specializes in the work you need done.

    1. Neeta*

      I’m inclined to give him the benefit of doubt. Maybe he doesn’t realize that there ARE actual standards to consider with frontend coding as well.

      I remember when I started out, on ASP.NET, we would have very nicely organized Backend code. The frontend, on the other hand, was created using Visual Studios editor. The idea was, that the “frills” should not be taking up a lot of time. If it works, it is good enough.

  6. Anon Accountant*

    Is reviewing his coding an option? Such as “Hey Bob, when you get to this part of the project, I want to review your coding. This has to be accurate and correct so I can finish my coding for XYZ”.

    And can you or someone else serve as a mentor for him?

    1. Windchime*

      Mentoring is so valuable in these situations. When I started out in my first C# job, I was paired with a young woman who was (and still is) a very, very good programmer. Much of my time was spent sitting in her cube, asking questions and observing as she coded. I was also given small assignments within that project, and so she could see my code as we checked in and she would give me feedback. I’m sure it wasn’t easy for her to have a newbie sitting with her, but it was so helpful to me and I feel that it got me on the right track much sooner than trial-and-error would have, or big group code reviews where my work was criticized and torn apart. (Not that all code reviews are that way, but that was my experience at that particular shop).

  7. hamster*

    ->Can you train him? If his back-end skills are good, i expect CSS/HTML code to be a lot easier to grasp. Do a code review meeting, show him how it’s done.
    ->I fully get your pain. we had a project delayed and delayed by a coder who had bad back-end skills ( he came from PHP and the way he handled memory in C was atrocious. he acted like he had a garbage collector ) . Anyway, a good measure would be to implement “coding standards” that address the most common pattern of annoyance in his code. That might be a good documentation for the future also.

  8. NYC Employee*

    I was in a work situation recently when a newer colleague could be overheard having borderline inappropriate personal conversations with clients. A more senior colleague advised against going to management, noting that this was too small an issue and management would eventually catch it. However, he said, larger issues should absolutely be brought to management. A week later, the newer colleague was overheard asking for the client’s personal credit card number – direct violation of company policy – and disappeared for the rest of the day. I might add that we’re in a small office with cubicles and every conversation can be heard. Keeping in mind the advice of my colleague, this transgression was immediately reported to management with the proviso “This is what I heard but I may have heard this out of context.” The colleague’s telephone call was reviewed immediately (all calls are taped from this call center) and in so many words, I was told that he was fired. Management thanked me for coming forward because this evidence of fraud by an employee could have cost them a huge contract and reputation, not to mention how many people would be out of work.

  9. Brett*

    Just realize that a likely resolution of this problem is for new guy to be pulled off all CSS/HTML. It really is a totally different skill set from backend development and frankly it makes little sense for him to be doing it (maybe if it was AJAX work, but if it is just CSS/HTML, that seems odd for him to be doing both).

    Considering the amount of time you are spending on deciphering his CSS/HTML, you might really consider having him do some pair programming for a while if he is going to keep doing CSS/HTML.

    1. Pandora Amora*

      +2 for recommending pairing in this situation:

      • A new employee
      • fresh out of school,
      • in their first job ever,
      • struggling to produce code
      • that they have no demonstrated affinity for.

      Frontend development is especially hard for new devs to learn: there are a multitude of ways to implement any given design, and there are so many different gotchas to keep in mind for how different browsers will render things.

      Tell your manager you’d like to experiment with pairing with this new dev for 4 or 6 weeks. If you’ve never paired before, pair up with some of the other devs so you can get a feel for what works and what doesn’t. Consider investing in an extra USB keyboard and mouse so you and your pair can both drive the computer.

  10. CAA*

    I’ll second that you should start a code review process. Also, has anyone told him what you expect? Do you have written coding standards, or have you three just kind of developed a consensus over time and you’re expecting him to know what you know?

    As a kid fresh out of college, he’s used to school assignments where you write something and throw it away after the assignment is graded (or maybe you add onto it throughout the semester, but you’re the only one working on it.) If he has previous work experience, it’s probably at solo freelance projects.

    Writing code that can be maintained by someone else is a different skill than writing code that works. Packaging your code in a way that makes it reusable is another skill. My experience is that new grads are clueless about how to do these things and they don’t even recognize them as needs until somebody tells them. Then once they understand why it’s important, it takes constant tutoring and reminding for several months before it will become second nature. That’s why a daily 30-minute code review meeting can make a big impact.

  11. Anonymous Software Geek*

    Does his code have bugs, or does it simply not align with your ideal of what elegant code should look like aesthetically?

    The first can be solved with regularly reviewing automated tests that are created before coding: test driven development.

    The second can be solved with having coding standards enforced by automated metric checkers. Bring the results of that to the regularly occurring code reviews. Not doing code reviews on a regular basis? Shame on your existing team and not a fresh college grad.

    What steps have you taken to train him in the ways of your team?

  12. Victoria Nonprofit*

    Just wanted to say that it’s really interesting to see a question from a field that’s way different from mine. I’m loving see the coders and IT folks pop out of the woodwork with great suggestions here.

    1. J.B.*

      I also love the two options Alison gave, the first should prompt the manager to take action but acknowledging that may not happen in the real world, here’s what to do next.

    2. Stryker*

      Agreed, Victoria, though I’d like to add some two cents and reiterate what other folks brought up: namely, that new college grads are struggling with ‘real world’ skills, though they do wonderfully well in academia. It’s not just IT–it’s every newly-minted degree holder, I think, who has a problem becoming useful.

      That said, they should all be getting internships and such before now so they have some idea what they’re doing, PLUS the student-cum-professional shouldn’t have oversold his capabilities. I recently got offered a SEO/Web content position that requested some experience I’d touched but never been trained in, and was upfront with the HM about it. They still offered me the position, along with resources to train me in it so I can gradually take over all the duties. There’s much to be said for admitting you’re not perfect, and it sounds like the OP’s coworker did himself and his new company a disservice from the start.

      1. VintageLydia*

        But hasn’t that always been the case? Traditional college was never considered job training as entry-level jobs performed that function. It’s only been in the last decade or so (or maybe less?) that internships were considered a “must have” upon graduation. It used to be that training new grads were expected. And heck, even if he wasn’t a new grad, he’d still need to be trained on how this particular company writes and organizes code.

        Plus we have no idea if the new employee oversold his abilities. His primary job isn’t what the LW is complaining about, and the letter implied that the manager might not know this is a problem because his other, greater aspect of the job he’s OK at. Maybe the manager was expecting the LW and his colleagues to help him out or something because, well, he’s a new grad without a lot of on-the-job experience.

        1. Stryker*

          True! I’d forgotten that aspect. Even as a competent writer, there’s training required to learn the company’s desired voice and audience, all that sort of stuff. Nowadays, though, I think it’s fair to say that some sort of professional experience is the best way to go and more employers are expecting it.

          And fair enough about the alternate duties & such, but then it sounds like the manager’s at fault for not explaining those expectations to the OP (that he expected the younger guy would get the training from the older folks). I would still love to have been a fly on the wall at his interview to see which is the case.

          I wonder, though… OP, just how big a part of the front-end CSS/HTML coding abilities is the job about? If it was just a bonus on the hire, then great, but if not, I’d stand by my original idea that he oversold himself.

      2. Meg*

        And for self-taught programmers and coders like myself, internships aren’t always an option. What I’ve experienced in this field is that it’s not about the education, but the skills. Sure, he has a degree so he KNOWS it, but can he DO it? He may know all about the different CSS properties and selectors and HTML5 elements, but can he use them make an application? ‘

        I tend to think of web development as a trade in that sense; with the skills and product (portfolio), who cares if you don’t have a degree?

  13. Meg*

    As a web developer who does 85% front-end (HTML, CSS, Javascript) and 15% back-end (JUnit and Selenium test with Java, modifying property files), I would recommend some pair programming with new hire. It’s his first job for one, and the benefits of pair programming with this kind of situation is monumental.

    Not only does it improve the quality of his work, but you also have a second pair of eyes on YOUR code (and a second pair on HIS code). The new hire will be able to pick up on the styling standards also(my tech lead is pretty anal about indenting, and my particular team loves commenting new features with a description of functionality, or if it’s a particular tricky piece of logic that needs to be explained).

    Definitely implement some sort of code review. We use Crucible by Atlassian that is integrated with our version control (we use Subversion/SVN), so every time you check in/commit code, it goes right to Crucible, and then you group your check-ins into reviews, and assign someone (we typically assign a peer – on my particular project, I have two other front-end developers, and two back-end/Java developers. I assign the front-end code to the other two FE devs, and to the tech lead outside of the project). Since we’re using Agile/Scrum methodology, code review is a requirement for “done.”

    Code review could even be less formal than that, as simple as “does this make sense to you? Did I miss anything?”

    And if the quality of his front-end work is THAT atrocious, but it’s not his primary role, I would try to not assign any major front-end work to him. Minor stuff to hone his skills, things that would easy to correct if needed, or to format (for CSS, does your entire rule go on one line vs property per line? For HTML, does your start/end tags go on separate lines from the content?).

    As far as bringing it up to your manager though… I’m pretty sure the answer would be pair programming. Usually anytime someone’s coding is sloppy, our tech lead would ask them to pair program with someone whose code is nearly immaculate. The work is still getting done, and you’re teaching someone to do their skills better.

  14. lisa*

    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.

    You answered the issue. He was hired for back-end, not front-end. You are evaluating his skills on front-end only, how is his back-end coding? If he is competent there, then you shouldn’t harshly judge him as a whole for 5% of his job. It’s probably ok according to the manager that he not be a 10 or even 6 on his front-end skills, if the back-end stuff is done at a 9.

    1. Forrest*

      Yea I feel bad for the guy since (apparently) there are three people doing front end stuff and just him doing the back end.

    2. Betsy*

      I totally agree with this comment. As a developer myself, I know that finding someone with every skill you want is always a pipe dream. I have never taken a job or brought on a new hire where I or they met every “requirement” listed in the job description, and the ramp-up time is always significant. If he’s not receiving support through his ramp-up time (so he actually ramps!) that’s not his fault, it’s his manager’s.

      I second the suggestions for either a clear description of the standards or a review process where his deviations from accepted norms are pointed out in a non-confrontational way.

  15. PEBCAK*

    Just agreeing with what everyone said about standards and code reviews. Does he even know what’s expected of him? When I took my first code QA job, there was a very specific format to be used in the titling of test cases. Nobody told me, and then six months later, when we needed to do some bug testing, people were like “it’s impossible to find your test cases in the data base because you didn’t follow our naming convention.”

  16. PPK*

    If you want to rile up a group of programmers, bring up code formatting.

    I work on the “back end” and know if I was asked to dabble in HTML(for something more serious than internal wikis or tests ), the HTML would likely be ugly (even if I was trying to do a decent job). Could I hack it out? Sure. Would the people who work on it as their primary job like it? Probably not.

    In additional to AAMs suggestions, I would definitely bring up code review as others have suggested. No one really likes code review (okay, I’m sure some people do), but we know it’s good for us.

    On a side note, you might think writing code would be quite rigid — but I can often tell who wrote what bits of code just looking at the style.

    1. Windchime*

      So true, PPK. Even when there are guidelines, you can usually guess who wrote what.

      We had a guy that worked for us for awhile at OldJob. We were re-writing some modules into WPF, and this guy simply refused to follow our naming conventions. Refused. He insisted on pre-pending every variable like this: “m_”, so you’d have a huge list of variables that all started with the same letters. It was maddening, but we were in the middle of nowhere and programmers were hard to come by.

      He would even go through other people’s code and change the names of their variables to his whacky naming scheme. Drove me crazy.

      1. Judy*

        Either he used to work with me, or used to work where a former co-worker worked. All the variables were m_ for module scoped and g_ for global scoped. Even though our coding standards just dealt with persistence of variables (capital first character of words for persistent, all lower case for not persistent.)

  17. Apollo Warbucks*

    I write a lot of SQL code (self taught with no formal training) and it took me some time to learn not only the conventions of the language but the house rules as well. I can not stress enough how much the help and advice from my senior colleague has improved my ability, I would be nowhere near as competent without that input.

    Several years on and my team has expanded and my knowledge is being passed on to the new juniors. Take the time to teach him some real world skills and the effort you put it will worth it in the long run and can increase your skill set if you’re interested in a management / supervisor role.

    Maybe put off talking to your boss for now and deal with the employee directly, unless he is unresponsive to your efforts to help.

    And one last thing, please please don’t leave this to be picked up in a performance review, nothing that is said in a performance review should be a surprise you or the boss should talk to him and let him know what he needs to do to improve as soon as possible.

    1. Natalie*

      As an aside, what did you use to learn SQL? I work with Excel a lot and I’ve thought about trying to learn it (I’ll have significant downtime this winter) so I’m curious about different resources.

      1. Apollo Warbucks*

        I used this web site for the basics of the language:

        http://www.w3schools.com/sql/default.asp

        Being able to work on a database was really helpful, if you have Access you can write SQL in there , or Microsoft let you down a trial version of SQL server and provide a couple of databases to work with, one called north wind the other called adventure works that’s useful

  18. hamster*

    @ PPK – So true. I can even differentiate between code written by people in a team i’ve never actually worked with , just maintained/reviewed their code.
    Yes pair programming is incredibly helpful. At a previous job, i had to shadow a colleague for one week . Like he explained everything he wrote/configured . And sometimes he let me write with him watching commenting etc. Fastest on boarding ever. Best work experience.

    1. Windchime*

      Yes. Same here, only it was longer than a week because it was my first job in that language. It was so, so helpful.

    2. Meg*

      My company has two buildings, across the street from each other. I was randomly assigned in the second building and my team was in the first building. For the first week or so, I was shadowing our tech lead until we got space with the rest of the team. On the second day on the job, one of our developers were out, and I got to use his machine with my logins. I was able to do ACTUAL WORK on my SECOND day, and then shadowed/pair programmed with our tech lead, and took a dive into our code base to fix some defects since we were at the end of a project.

      Very fast onboarding, and my boss and our tech lead often comment about how fast I picked up our conventions and understanding of our code base. They’ve never apparently had a developer start non-supervised/non-shadowed work on their second day.

      Pair programming/shadowing is the best way to get developers up to speed, whether they are a new developer or just a new hire.

  19. Sissa*

    I have a similar problem with a colleague. We were hired as web designers and developers, but she writes awful, awful code that might have been fresh pre-2000. Tables, inline styles, you name it! And teaching her how to do things in a more modern way with CSS and HTML is a real pain in the butt. I’ve also brought this to my manager but don’t really see much of a change, and whenever I try to confront her about it, she gets defensive and says that her way works the best.

    There was a saying once that I think applies in these kind of things… “Standards are like toothbrushes – everyone agrees you should have one but nobody wants to use yours.”

    In the OPs case the coworker is probably just doing whatever makes it work instead of thinking semantics, usability or anything of the sort. If it’s tables and inline styles like in our team’s case… I feel for you. I really do.

  20. Stryker*

    Okay, question about code. Since it’s behind-the-scenes and no end user should be able to see it, why should it be pretty? And what makes code “pretty,” anyway? Honest question here, I’ve heard the term before and it’s made no sense to me. I also know NOTHING of code beyond poking around with HTML for fun, so again, totally serious…

    1. Betsy*

      The answer comes down to maintainability. There’s a sense that non-developers have that you write the code, and it works, and then it’s done. The reality is that you are almost never actually “done” with a piece of code. You write it, and then you need to tweak it to add a new input field, and then someone says, “We should check if that date is valid before the user tries to submit the form,” and then for some reason, the data looks funny, and you’re trying to figure out why.

      If I wrote the code, and it “works”, but is ugly and tangled up, then no one else is going to be able to figure out what to do to fix it. A “pretty” piece of code is like a clean and organized pantry cupboard: no one is likely to see it, but when I’m sick and my friend comes over to cook soup for me, she can actually find my pasta.

      1. hamster*

        When i was young and stupid i worked at a website with some colleagues from college. As we disagreed over who to do which part/how should we split the money between us, i decided to call it quits, and move on. The rage on them when they got to modify php code with variables names $sunflower or $dolly …. I then realised that after a month even i could not remember what a poorly documented no comments and non descriptive variable named code does. And it wasn’t even such a big project.

        1. Betsy*

          Yeah, my father-in-law tells a story about having to debug a 10-year-old piece of machine code. He says it was around 500 lines long, and had exactly one comment, at around the midpoint: “I don’t know why this works, but it does.”

          1. Judy*

            There’s the urban legend about the guy who named all his variables with his initials and a 6 digit number. Supposedly he had a notebook that had cross references to the “real” names in it that he took home every night.

          2. hamster*

            That’s so funny. At my first job this was a hazing of sorts. They’s gave you a chunk of old microprocessor code , spaghetti, no comments and watch you struggle with it. The company actually gave up that code, and sometimes still asked “the colonel” ( a retired developer) to come and maintain it occasionally, but the other devs just loved watching a new hire struggle and sweat over it a few days.

      2. LovelyLibrarian*

        I love the pantry idea! I’m not a developer but I work with them and have to be able to at least read and understand code, if not write it. The analogy of the pantry works really well: assuming I already know how to cook, I should be able to go into a pantry and find all the things I need to put a dish together. “Ugly” code is like going into a pantry to find everything in unlabeled boxes, then opening those boxes only to find non-food items like light bulbs. If you can’t tell what thing is / does what, you won’t be able to get anywhere.

        On the other hand, the pleasure of reading / writing “pretty” or good code is like opening the cupboard to find everything labeled and organized, all the implements lined up and accessible, and making a great meal!

        Thanks, Betsy – I’m going to use this from now on :)

    2. Betsy*

      To answer the definition question, which I realized I just totally bypassed, a pretty piece of code is simple, elegant, intuitive, well-formatted, and correctly documented. An “ugly” piece of code might have overly complex logic (making it hard to follow), weird variable names, strange formatting, or too much going on in one place (code lets you split your logic up into manageable chunks, so you can figure out what each piece does — like having a different drawer for socks, shirts, trousers, and pajamas instead of just keeping them all in the same drawer).

  21. hamster*

    @ stryker
    A code should be as pretty as possible without compromising experience/usability because after you someone else is going to update it at a point/maintain it/re-use it / add a feature and it would be a pain in the ass for them to understant what you wrote and then do something with it.
    For a example a() && b(); is a pretty legal statement but much more pretty would be
    if ( a() ) { b();}

  22. Unethical Behavior*

    So, if you have a coworker that is working a second job on company time, is it considered tattling if you bring it to the bosses attention? Just because it is wrong in my beliefs, does it make it wrong in everyone else’s?

  23. LaFemmeTech*

    “It took us a long time to find someone to fill this position. . . [for both front and backend development]”
    Translation?
    It took a long time for us to find some poor sucker willing to work as a mid/senior level developer for entry level pay.
    Who on earth expects a recent college grad to complete both client-side and code behind projects without any mistakes? Rather than gripping, one member of the team should spend one hour a day in a one-on-one code review.

Comments are closed.