Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Programming IT

Ask Slashdot: How To Handle a Colleague's Sloppy Work? 332

An anonymous reader writes "I'm working on a new product with one of the more senior guys at our company. To be blunt: his work is sloppy. It works and gets the job done, but it's far from elegant and there are numerous little (some might say trivial) mistakes everywhere. Diagrams that should be spread over five or six pages are crammed onto one, naming is totally inconsistent, arrows point the wrong way (without affecting functionality) and so forth. Much of this is because he is so busy and just wants to get everything out the door. What is the best way to handle this? I spent a lot of time refactoring some of it, but as soon as he makes any changes it needs doing again, and I have my own work to be getting on with. I submit bug reports and feature requests, but they are ignored. I don't want to create bad feelings, as I have to work with him. Am I obsessing over small stuff, or is this kind of internal quality worth worrying about?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To Handle a Colleague's Sloppy Work?

Comments Filter:
  • Whining. (Score:4, Funny)

    by Anonymous Coward on Friday May 03, 2013 @12:24PM (#43621157)

    Passive-aggressive complaints in a public forum looks like a good choice.

    • Re:Whining. (Score:5, Insightful)

      by cayenne8 ( 626475 ) on Friday May 03, 2013 @12:39PM (#43621393) Homepage Journal
      Just do as much as it takes to get the job done successfully, and move on to the next thing.

      VERY few people have the luxury of the time to spend to tweak and get everything perfect and "just so".

      • Re:Whining. (Score:5, Insightful)

        by Nethead ( 1563 ) <> on Friday May 03, 2013 @01:32PM (#43622061) Homepage Journal

        Exactly. If you want to be that anal about the product you should look for a job in aerospace. You'll fit right in.

      • Re:Whining. (Score:4, Insightful)

        by eth1 ( 94901 ) on Friday May 03, 2013 @01:48PM (#43622257)

        Just do as much as it takes to get the job done successfully, and move on to the next thing.

        VERY few people have the luxury of the time to spend to tweak and get everything perfect and "just so".

        I'm like the OP in that most of what I turn out is correct and consistent in all details. It doesn't take me any longer than the people that turn out "it works, but it's not pretty (especially if it has to be modified later)," and takes less time later since it's understandable and maintainable.

        Cleaning up crappy work, however, takes way longer than doing it neatly or sloppily the first time through.

        I find that the cause of this is usually people that don't bother to think any farther ahead than just finishing the job at hand, while I think about what's going to happen in 6 months when this needs to be changed.

        Everything we do has to be peer-reviewed, so the way I deal with it is to simply not approve anything that doesn't meet my standards, and help the person to understand why. Usually, if the person in question has half a brain, they'll catch on eventually.

      • Re:Whining. (Score:4, Insightful)

        by tutufan ( 2857787 ) on Friday May 03, 2013 @02:10PM (#43622525)

        For many of us, doing things right in the first place is actually faster.

      • Do they have time to read the summary on Slashdot? What he describes is far from what you are saying. What he describes is phenomenally sloppy work, and what you offer as a solution is anything but.
      • You see this attitude from people fresh out of school, or maybe fresh from some company that has a huge budget for time wasting. They are baffled that the real world doesn't work as smoothly and orderly as all they imagine from the textbooks, they're confused that the extensive set of processes that they used to have aren't in place at the new company, and so forth.

    • I submit bug reports and feature requests, but they are ignored.

      Hopefully he's also talking to him face-to-face, because using the issue tracker for filing a "his diagram is too big to fit on one page" would seem like overdoing it.

  • by Osgeld ( 1900440 )

    you are obsessing, and yes internal quality counts a lot, cause if its sloppy internally, its sloppy externally as it sets the attitude

    • Re:yes (Score:5, Insightful)

      by digitrev ( 989335 ) <> on Friday May 03, 2013 @12:33PM (#43621305) Homepage

      To follow up on the other part of your question (what do I do), here are my suggestions.

      • See if there are any documents that back you up on this, e.g. style documents, and so on. Use them to your advantage.
      • Find people he's worked with before and see if this is a chronic issue, or if they've ever made headway on getting him to clean things up.
      • Get a feel of the culture there. If there's a culture of "get 'er done", you might be out of luck.
      • Talk to him. Let him know that you're having a hard time following his work in the format he typically hands to you, and that you end up spending a great deal of time refactoring things so that you can properly implement it. Emphasize that the whole project will go much smoother and faster if he's willing to spend some of his time cleaning things up. If you're lucky, he cleans things up. If you're less lucky, maybe he'll at least acknowledge the extra overhead, and manage his expectations of you accordingly.
      • Give up. If the guy is senior enough, or he's got an "in" with upper management, or he's just an asshole, then it might be better for you to just slog along and wait until the product launches.
  • Get over it. (Score:4, Insightful)

    by The_Wilschon ( 782534 ) on Friday May 03, 2013 @12:25PM (#43621171) Homepage
    If he's the senior guy and he's getting the job done, then I suspect he knows what he's doing and knows which aspects of the job to focus on and which to ignore because they are useless trivialities. Just stay out of his way.
    • Re:Get over it. (Score:5, Insightful)

      by Nerdfest ( 867930 ) on Friday May 03, 2013 @12:31PM (#43621257)

      There's getting the job done, and there's getting the job done in a way that can be maintained by someone else in the future. The only way you should let someone continue developing an unmaintainable mess is when there is absolutely no chance it will ever need to be fixed or added to. I have yet to see that happen.

      • by jeffmeden ( 135043 ) on Friday May 03, 2013 @12:54PM (#43621575) Homepage Journal

        The only way you should let someone continue developing an unmaintainable mess is when there is absolutely no chance it will ever need to be fixed or added to by you.


      • Re:Get over it. (Score:5, Insightful)

        by Beardo the Bearded ( 321478 ) on Friday May 03, 2013 @01:16PM (#43621889)

        I'm not a drafter. I'm an electrical engineer. I can make drawings, I can follow the guidelines, but I'm not as good at drafting as our drafters are.

        The drafters can understand what I'm trying to say and then make it pretty.

        Let people be good at what they do and support them with staff that can hold up the spots where they don't shine quite so bright.

        • Re:Get over it. (Score:5, Interesting)

          by Kneo24 ( 688412 ) on Friday May 03, 2013 @04:35PM (#43623889)
          Certain comments deserve a +10 (or 11 if you prefer). This is one of them. You have hit the nail on the head. I do exactly this with our engineers where I work. They're terrible at writing documentation that other people in the building need to read. Some of the stuff I have seen is absolutely abysmal. What I decided to do was to be the guy that makes everything pretty and easy to digest before official releases for them. Over time a few of them have come to thank me for this, as it saves them a lot of headaches. The net result is that everyone looks good.
      • Re:Get over it. (Score:4, Insightful)

        by jythie ( 914043 ) on Friday May 03, 2013 @01:42PM (#43622181)
        Which, without details and context, we do not know which this is. I have met plenty of developers who fail to think about maintainability and plenty who prioritize idealogical artifacts over purpose. I have also known plenty of developers who consider anything they can not scan easily (meaning, the exact style they learned) to be 'sloppy', so from this limited context we do not even know how much is actual (reasonable or not) sloppyness vs aesthetic differences.
      • While the first poster's comment might have been intended as snide or humorous, there's a grain of truth in it. Not about whining, necessarily, but about his behavior at work.

        The thing is, there is probably no future in doing what he is doing: somebody else's work, without credit.

        I can appreciate that he wants to make sure things are done right, but he's doing work that should have been done by somebody else, and not making sure that it's being noticed. That's a great formula for failure. I know beca
    • by Tr3vin ( 1220548 ) on Friday May 03, 2013 @12:32PM (#43621287)
      Uh-oh. It looks like he also reads slashdot!
    • by schlachter ( 862210 ) on Friday May 03, 2013 @12:53PM (#43621559)

      I had an intern try to optimize and clean up my code on his own initiative. It was pretty irritating.

      It was an internal demo and I had written the code quick and simple to get the job done. It didn't need to be clean or optimal. I wanted the intern to spend his time doing better things.

      OTOH, if I had tasked him to clean up my code and optimize, I might have been happy with his work.

      • by Nerdfest ( 867930 ) on Friday May 03, 2013 @01:13PM (#43621853)

        I've found that those 'internal demos' pretty much always become production systems if they work. There is rarely such a thing as 'throw-away code', so I've stopped writing stuff like there is.

        • Not a bad idea at all, but in my environment, the real take away from a demo is usually a concept, algorithm, approach, or user interaction paradigm.

          If people like it, funding increases by 1 to 2 orders of magnitude (i.e. going from $100K to $10M) and a ground up reimplementation and expansion of the idea ensues.

      • by Kjella ( 173770 ) on Friday May 03, 2013 @03:08PM (#43623085) Homepage

        I had an intern try to optimize and clean up my code on his own initiative. It was pretty irritating. (...) OTOH, if I had tasked him to clean up my code and optimize, I might have been happy with his work.

        You have an intern that can actually clean and optimize your code and you're complaining? Clearly he feels undervalued and wanted to show his skills or is just eager to learn and want to sharpen his skills, in either case just give him a proper assignment and be grateful.

  • by Mahldcat ( 1129757 ) on Friday May 03, 2013 @12:25PM (#43621179)
    find some of the more fun things from his code, and submit submit submit....
  • by alen ( 225700 ) on Friday May 03, 2013 @12:27PM (#43621203)

    i see a lot of "elegant" SQL code that i end up fixing to make it simpler so it runs faster

    Microsoft releases new versions of SQL Server every few years to make code simpler to read. and yet people still insist on "elegant" code that's a pain in the A$$ to figure out why its running so slow

    • by i kan reed ( 749298 ) on Friday May 03, 2013 @12:29PM (#43621229) Homepage Journal

      Elegant is supposed to be readable. They're supposed to be the same. If you write code no one understands, it's not elegant, it's obtuse.

      • by alen ( 225700 )

        over here it seems to be to write hugely complicated SQL code with lots of temp tables and then complain that it runs too slow

        instead of writing some CTE's, views or anything else MS has come out with in the last 5 years to make code easier to read

        or one time i had a view loving dev go view crazy. he had his team write dozens and dozens of views that called other views and mostly did simple things. kind of like C++, but in SQL. and then complained why the SQL job was running too slow. he had a few stored pr

        • by pigiron ( 104729 )

          Temp tables can also make queries run faster especially when confronted with a single three pages long SQL statement.

      • by icebike ( 68054 ) on Friday May 03, 2013 @12:38PM (#43621383)

        Unfortunately, elegant has been re-defined by many a geek as being the shortest possible line of code, regardless of how obtuse it is to read and understand. You can still see people spouting shell scripts or C statements designed solely to show how clever they are, at the expense of readability or maintainability.

        • by jythie ( 914043 )
          "elegant" is whatever is in style at the time the speaker got into programming. People generally consider something elegant if they can look at it and quickly determine what it does, which generally means it has to look like what they are used to reading because that is how our brain tends to deal with reading and patterns. You might be surprised at how much someone's comprehension speed changes if, say, you take a developer who has primarily worked in camelcase and have them read underscore separated cod
      • by gorzek ( 647352 )

        That's not always true. It can be "elegant" in algorithmic terms, but difficult to understand as pure code. But in that case, "elegant" is probably standing in for "clever." Clever code is often unreadable. Some languages are built around how much cleverness they encourage. Perl is probably the gold standard for cleverness, while Python goes out of its way to make you code something that's readable rather than enigmatic.

        • by mark-t ( 151149 )
          This is entirely true... but in that case, you should be commenting the code so that what is happening is clear.
      • Elegant is supposed to be readable. They're supposed to be the same. If you write code no one understands, it's not elegant, it's obtuse.

        With SQL, often it is easier for humans to understand stuff that has a lot of subqeries. But for an optimizer, it is easier to optimize if there are not subqueries. So, if elegant= more readable, then elegant != efficient.

  • by xxxJonBoyxxx ( 565205 ) on Friday May 03, 2013 @12:31PM (#43621261)

    >> Diagrams that should be spread over five or six pages are crammed onto one

    And you still figured out what to do? Sounds like he knows what he's going then.

  • If his code works and his methodology produces consistent results then his methodology is sound. Perhaps you shouldn't be less concerned that other people have different ways of working than your own.

  • This is the third time this question comes up.

  • by LoRdTAW ( 99712 ) on Friday May 03, 2013 @12:32PM (#43621285)
  • by adisakp ( 705706 ) on Friday May 03, 2013 @12:33PM (#43621293) Journal

    It works and gets the job done, but it's far from elegant and there are numerous little (some might say trivial) mistakes everywhere.

    If there are functional mistakes, then it shouldn't be working and the best way to complain would be to make bug reports and document your fixes to the code.

    However, if it's not buggy and you are refactoring because it's not "elegant" that's much harder to justify or document. Because it kind of sounds like you are complaining about his coding style while he is being productive and writing a ton of less than perfectly styled code that "works and gets the job done".

    • by fermion ( 181285 ) on Friday May 03, 2013 @01:06PM (#43621747) Homepage Journal
      I agree. First, let me be blunt and say it is not your job to make other people work the way you did or the way you learned in college. There are many different ways to get a job done, and often we benefit by adjusting and learning different ways of doing things.

      Second, if you are refactoring simply to make it look like you want it, and those documents are not being put into general use("I spent a lot of time refactoring some of it, but as soon as he makes any changes it needs doing again") then you may be wasting firm resources. If you can't get the work done without reworking everything, there are really only two options available. Realize that you are doing to have to some of this on your own time, or learn to read what is clearly company standard documents. These are after all what you have been given.

      Third, identify if there are actually any real issues with the current system. Base change on improvement that will result in significant efficiency, not just 'the way it should be done'. There has been many occasions where I have come in as the junior person and was allowed to make changes because those changes would result in real savings. There were other times where I was just trying to be clever or controlling. Know the difference.

    • However, if it's not buggy and you are refactoring because it's not "elegant" that's much harder to justify or document.

      It's all in how you phrase the change log entry: "Improved understandability of the code to allow easier implementation of future changes to user requirements."

      • by adisakp ( 705706 )

        However, if it's not buggy and you are refactoring because it's not "elegant" that's much harder to justify or document.

        It's all in how you phrase the change log entry: "Improved understandability of the code to allow easier implementation of future changes to user requirements."

        Still, spending a lot of time refactoring code that is functioning correctly and as he claims "works and gets the job done" is time that he is not working on other tasks. Also, he notes that the other employee is extremely productive at just getting code done that actually works while he is spending lots of time refactoring this working code and then complaining about his "wasted time".

        I've seen plenty of coding styles and even if it's a little ugly but works, it's often better to do your own tasks and

        • it's often better to do your own tasks and focus on your own productivity than cleaning up code that already works.

          Unless a project is completely waterfall model, with the smallest changes billed at the same rate as creating a new system from the ground up, increasing the ability of the company to respond to requirement changes for an existing product increases the productivity of all the company's employees. Is it the fact that a particular person's contribution to such an increase is hard to measure?

          • by adisakp ( 705706 )
            The code works... he's spending time complaining that he has to beautify it because he doesn't understand it due to the current style. I'd really suggest thinking about this wisdom from another slashdot thread... []

            There's also the matter of rewriting things introducing new bugs and getting the "so what good did it do to rewrite it when the new code doesn't work?" element. Worse is when the new bug is difficult to reproduce or troubleshoot.

  • by bauerbob ( 1049344 ) on Friday May 03, 2013 @12:33PM (#43621295)
    Don't send him bug reports and feature requests. If he's in charge of something you care about, ask him if he would give it to you (completely!). Then you can fix whatever you want. You will see that there'll be a new guy soon who thinks that your work is sloppy, sending bug reports and feature requests to YOU!
  • I work with dozens of small companies many of whom have their own proprietary software and development. Consistency across these companies is nonexistent and consistency WITHIN the code any of the software packages is at best unpredictable.

    I deal with this by writing comments into all their code for my own information. If and when there is an issue, I can typically find the problem area very quickly and correct it.

    I make no effort to clean their code up if its operating acceptably. I get it so it works and

  • by FatLittleMonkey ( 1341387 ) on Friday May 03, 2013 @12:39PM (#43621387)

    With cruel sarcastic insults.

  • I see several different kinds of quality in my co-workers' code.

    I see problems that are called sloppiness, like bad variable names, and "ugly" looking loops. These are not worth worrying about. I find that many new programmers - programmers raised looking at open source code that is coded without comments with the fewest possible lines - find "ugly". Even the use of Gotos and similar, use of variables without accessor functions. The refactoring is to make functions shorter, to remove comments (since now t

  • That's "Agile" (Score:2, Insightful)

    by Animats ( 122034 )

    This sounds like some old waterfall-model guy complaining about a modern "agile" programmer. If you're just doing web crap, quality doesn't matter. Time to market does.

  • You say he may be doing this because he's just too busy... Maybe these things are not things he should be doing in his job, maybe he's better suited to something else? Maybe you need to hire somebody to do these things so he can concentrate on the other things he might actually be good at, and would then have sufficient time to do a good job. I've seen this happen where people get pushed into doing too much, and doing things they aren't good at, and then they start looking like poor workers.. well what d
  • Learn from him (Score:5, Insightful)

    by Fnkmaster ( 89084 ) on Friday May 03, 2013 @12:42PM (#43621441)

    I like working with people who get the job done, quickly and simply, and focus on functional completeness and minimizing defects. People who I can count on to tell them "here's what it needs to do" and I can know that I'll get something out that does what we need.

    I don't like working with people who obsess about every line of code they produce and who worry more about documenting things internally than about getting working code out the door.

    Sure, given the choice I prefer clean, maintainable code to shitty, sloppy code. But complaining about diagram quality in internal documentation? Unless you are making components for NASA or MRI machines, I think you're obsessing about things that don't matter that much.

    The reason the guy in question is senior to you is because management likes people they can count on to get shit done.

  • It works and gets the job done

    In order for my coworkers to make anything that works, the planets have to align

  • by nazsco ( 695026 ) on Friday May 03, 2013 @12:51PM (#43621533) Journal

    Lear all you can. how can he do less work and not create bugs? (if he creates bugs, stop fixing his work and let the problem fix itself)

    All in all, he is you tomorrow. You will get like him. Maybe there's a reason for that. maybe it's just indifference that comes with age. either way, i'd recomend you to learn his ways and start sooner, for as soon as you start that, you will get better pay, more respect, and a youger idiot to clean up after you.

  • Nowhere in the parent post do I read that there are problems with his code not working. In fact the phrase "far from elegant" really does tell the tale. The true "problem" here is obvious: The product isn't being done the way *you* think it should. It is admirable that you have these standards, but in the "real world" one has to work on a continum between time and budget.

    Also, the author complains that 1) the code is not up to his stanadards, yet 2) he doesn't feel he should have to make it so. If you
  • The work gets done, and is good enough.

    Anything else is your bosses concern, not yours.

    Worse, any time you use trying to fix him directly and negatively affects his morale.

    Sometimes it's better not to know what goes into the sausage.

  • Recommend him for promotion - to another team.

  • I'm a systems integration person, so I have actual real-world experience getting one steaming turd of enterprise software to coexist with another one. Even if it's just coding style, and nothing your team does shows up in the final product released to customers, sloppy work means that your customers are going to have longer waits for bug fixes in the future. They're also going to be cursing your company because your products are a pain in the butt to install, require 100% of a high-end server's resources fo

  • Love your colleague. (Score:5, Interesting)

    by galexand ( 151650 ) on Friday May 03, 2013 @12:58PM (#43621625)

    My boss is like that, he abuses cut-and-paste to the exclusion of proper factoring. The code is sometimes comical. He does it for the exact same reason, he wants to move on to testing/fixing/improving, rather than spending a lot of time dreaming-about-how-it-ought-to-be.

    Sometimes, maybe 3 or 4 times in the decade that I've worked with him, I have needed to do a major re-factoring just to be able to shoe-horn in a new feature. He is glad I'm here to do that, because he doesn't enjoy re-factoring. I'm glad he's there to do his part, though, because a lot of times he can throw out a big *working* piece of garbage in just a few days, while I would still be arguing with myself about where to start.

    The machine works. Therefore, I cannot point to any component that is broken. The machine works.

    So I enjoy this, I look at all of the numerous insurmountable customer problems that we have dispatched over the years together, and it is beautiful to me. I love my boss.

    That's my advice to you: learn to love this guy, to think of his foolish shortcuts and disorder as unique tools that a unique person uses to solve the problems in front of him. Consider it "local flavor." If you're being hauled up in front of management and they're blaming you for his bugs, that's one thing. But if the machine works, learn to love it. If you can't love it, quit programming and go into a less creative field.

  • Insist this senior doesn't have time to do the coding himself, let you handle all of it. Insist it will be more efficient if you code the changes, that should sway him.
  • by maroberts ( 15852 ) on Friday May 03, 2013 @01:03PM (#43621697) Homepage Journal
    I'm working on a new product with one of the more junior guys at our company. To be blunt: his work is sloppy. Because he obsesses over details, whilst his work is elegant and has few mistakes, he never completes any work. It never gets to the stage where It works and gets the job done, but there are numerous incomplete (some might say major) sections everywhere.

    Diagrams that could fit in one page are spread over five or six pages, he's anal over naming convention and minor details like whether arrows point the right way (whether it affects functionality or not) and so forth. He spends lots of time refactoring code instead of making progress and never gets anything out of the door, costing us money. What is the best way to handle this? Whenever I make necessary improvements he goes over my changes with a fine toothcomb, instead of getting on with his own work he spent a lot of time refactoring some of mine. The annoying little tyke then submits bug reports and feature requests, but which my fellow senior peole read with condescending amusement. I don't want to create bad feelings, as I have to work with him. Is he obsessing over small stuff, and should he see the Bigger Picture"

    • by Lumpy ( 12016 )


      Typically those that whine about "sloppy" are newbies fresh out of college.

  • by BaronAaron ( 658646 ) on Friday May 03, 2013 @01:07PM (#43621757)

    There is a senior developer submitting a Ask Slashdot article about what to do with a know-it-all junior developer wasting time "refactoring" all of his code.

  • "It works and gets the job done"
    Yay! Always a vitally important thing to all projects.

    "but it's far from elegant"
    Define elegant. Also, is elegant a project requirement, or asset, or is it just a personal affection?

    "numerous little (some might say trivial) mistakes everywhere"
    Those are a problem. Mistakes are always problems, but they do occur.

    "Diagrams that should be spread over five or six pages are crammed onto one, naming is totally inconsistent, and so forth"
    If it is within your power, have a document
  • Just post your work and we'll clean it up for you

  • Simply report at your meetings with your manager that a lot of bugs are appearing, being assigned to him and being ignored.
    There is nothing more annoying than someone that ignores bug reports or that doesn't fix problems he just introduced when they are pointed out.

  • Next time you want to refactor or "fix" something he's produced, ask his opinion of your proposed change. It's possible you are doing him and your team a favor, and it's possible you are wasting your time on pointless re-work and acting like a know-it-all. Find out which.

  • The last thing you want to do is cover for him without letting your boss know that's where a percentage of your time is going, otherwise you will appear to be slow/unproductive on your own work.

    Let your boss know how much effort you are putting into catching his mistakes.

    It might not be a bad idea to make sure they know by letting a few of the bigger ones slip through, preferably timed to coincide with the time you take vacation and they will notice, so they actually feel the pain of you not being there to

  • We don't know what sort of development you're doing or diagrams you're talking about.

    If they're design diagrams, why are you printing them? Spreading a diagram across "pages" is painful when you're trying to read online and have essentially infinite zoom capabilities. If he wants to do single-page diagrams in four-point font, click that little "+" or drag the slider and zoom in on the part you want to see.

    Unless his code doesn't work, or someone assigned you the task of cleaning his code up, I'm not sure wh

    • He's some kind of marketing guy/girl or something, and he's working with visio or its ilk. Their "code" is a business process. Move along.
  • What is the push-back from the 'customer' using this data?

    If it is an end customer who can't understand the diagrams or a subcontractor that can't implement the design, then get them in the loop with a customer feed back survey.

    Anonymize the authors of the various components and ask them (the customers) to provide feedback. If they think the work is crap, let them say so. If they can deal with it, then OP is being too picky. Yes, there is an issue of professionalism. Neat work leaves a better impression

  • You sound like a kid fresh out of college that just hit the real world. You don't want to come across as a whiny brat as you'll sink your own career. Instead of taking an attitude that he is doing it wrong, take the attitude of there is something to learn here. Ask him why he does certain things the way that he does, are there reasons he doesn't do things the way you learned?

    It's okay to say you've got a mismatch, admit your own ignorance and ask why someone does or doesn't do something. You'll get a lot mo

  • I'm a bit like that chaotic guy too. If my colleagues wouldn't pay attention, naming conventions would go over board, documentation is so so. What I pay attention to is to not make mistakes regarding memory allocation and concurrent programming. Also making sure that loops run beyond array boundaries is important. I also make attempts to think about what happens "else" even if I end up just writing a comment down.

    The obvious annoying stuff I leave to my colleagues who are way more anal retentive. What I als

  • Is it possible - maybe not likely, just possible - that the submitter is in the right? The following is completely fictional and I'm making it up entirely for illustrative purposes. None of it ever really happened. Honest. Ahem.

    I transferred from one department in a previous company to another, and was assigned to help a Principal Software Engineer polish up some code for release. When I first looked at the code, I thought maybe I was in over my head. I felt stupid. I couldn't understand a thing. I brought this up to my manager, who chided me for nitpicking about coding styles.

    So I slaved away to understand how the project worked and how all the pieces fit together. I'd ask questions like "why are we monkey patching standard library classes to alter their behavior" and be told "it's easier this way". I'd ask why we had 9 levels of inheritance and be told it was to keep the abstractions clean (although I couldn't understand why 7 of those 9 layers only had one child class that derived from them). Why are chunks of server code in the client? Because that's how the design diagram works. Why did we invent our own unit test framework? Because the others weren't good enough for us.

    The whole mess came crashing down when our boss asked me to add a data validation check on a certain input. It was a stupidly simple check like "if value < 0: raise ValueError('value must be >= 0')" - that kind of thing. It turned out to be impossible. There was a hell's brew of code that handled errors by returning None, code that returned a string with the error message, and code that used exception handling. There was not one single clean codepath between the API layer and the database model.

    My boss had been more concerned with my questions over the weeks, but it wasn't until I showed him the code that he really "got it". He flipped. Meetings were called. VPs were summoned. Design and code reviews were scheduled. The original coder became so frustrated with what he saw as "micromanagement" - things like "unit tests must actually pass before deployment" and "don't monkeypatch everything" - that he quit and I was given ownership of the ball of mess. Since then, I've managed to make reliable, vastly simpler (seriously, I've probably reduced line count by 2/3 and call stack depth by 3/4), and understandable. It no longer uses ML for a templating language. You can read a method's code to see how it works instead of running "git grep methodname" to see if another module patches it at runtime. I'm no longer ashamed to be associated with it.

    Sorry, submitter, but I don't have any advice for you. I do have advice for the rest of the readers, though: consider the possibility that the submitter was telling the truth. There are silly code style differences that shouldn't get in the way of getting your work done. You like studly capped method names and your coworker likes_under_scores? The sun will still rise tomorrow. But just because someone is senior doesn't mean that their code isn't a fetid ball of fail.

If you suspect a man, don't employ him.