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?"
Whining. (Score:4, Funny)
Passive-aggressive complaints in a public forum looks like a good choice.
Re:Whining. (Score:5, Insightful)
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)
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)
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)
For many of us, doing things right in the first place is actually faster.
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
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.
This? Slashdot front page? (Score:3)
How on earth did that happen?
Re: (Score:2)
Re: (Score:2)
That more likely to bring fresh ideas than reply using the phrase "Passive-aggressive".
Seriously, every time I hear that phrase I want to grab the speaker by the wattles and slap them till they spit.
Have you grabbed the speaker by the wattles and slap them till they spit? Until then you are just being passive-aggressive.
Apparently you missed my last sentence.
yes (Score:2)
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)
To follow up on the other part of your question (what do I do), here are my suggestions.
Re:yes (Score:5, Insightful)
Is it possible the OP is already the junior developer hired for this purpose? :)
Re: yes (Score:2)
Re: (Score:2)
This is the real problem:
Much of this is because he is so busy and just wants to get everything out the door.
The real solution is to hire a junior developer to help out, either to take some of the workload off the senior developer, or to simply make the corrections instead of the OP.
AFAICT, this guy IS the junion developer. Three possible options:
1. quit
2. get him to change (unlikely), or get him fired (if he's senior and pumping out lots of stuff that looks iike it works, this is unlikely)
3. speak to him + management; see if he/they see benefit in a maintainable product; if so, propose that you be his bitch / code filter, and your job becomes quality control (you fix his stuff; improve/add automatic code checkers; clean up the source; etc etc). If they see the benefit in that over you
Get over it. (Score:4, Insightful)
Re:Get over it. (Score:5, Insightful)
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.
Re:Get over it. (Score:5, Funny)
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.
FTFY
Re:Get over it. (Score:5, Insightful)
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)
Re:Get over it. (Score:4, Insightful)
Yep. Passive-aggressive. (Score:3)
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
Re:Get over it. (Score:5, Funny)
had an intern try to clean up my code... (Score:5, Informative)
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.
Re:had an intern try to clean up my code... (Score:5, Insightful)
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.
different environments... (Score:2)
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.
Re:had an intern try to clean up my code... (Score:4, Insightful)
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.
Re:Get over it. (Score:5, Insightful)
Who said it's solely "hierarchical" seniority? This entire question smacks of a fresh-out-of-college kid (it is May 3... when's graduation?) being absolutely stunned to learn that the real world of software engineering isn't as pretty and glossy and anal-retentively-dotted-i's-and-crossed-t's as he was led to believe it would be in his college classes.
My guess is that the "senior guy" in question is a "senior guy" by virtue of the fact that he's been doing the work for years, and knows how to ship code.
When you're the new guy, it's always better to understand "why" somebody experienced is doing something a particular way before you obsess over changing it. Sounds like the submitter has walked in, doesn't like somebody else's code style, and is now freaking out about it without making any attempt to understand why the senior guy has chosen to work this way.
If it turns out the answer is "the senior guy is a shitty developer and actively harming the company," then you consider how to deal with that. But I'd be far more inclined to believe the answer is "the new guy is a whiny little bitch."
Re: (Score:2)
Subsequent changes in user requirements (Score:2)
You get paid by what works not how it looks under the hood.
What you say is true of a product that meets all present and future user requirements. But if a product looks good under the hood, it may prove easier to adapt to subsequent changes in user requirements.
Re: (Score:2)
Look at Adobe. Their Flash code base 'got the job done'.
Re: (Score:2)
And if it wasn't for that pesky Apple they would still be going golden.
Re:Subsequent changes in user requirements (Score:5, Insightful)
Look at Adobe. Their Flash code base 'got the job done'.
and people used it for years. We can complain, but they beat competitors by getting there first (rather than pretty under the hood).
Re: (Score:3)
People would probably still be using if it were fast, efficient, and secure. Those three things are tend to be a lot easier to achieve with a highly maintainable code base.
Re: (Score:3)
This is true... but how it looks under the hood can play a huge factor in how feasible certain design change requests will be within a manageable schedule.
The extra discipline that it takes to do it in a readable and manageable way the first time, so that any potential other developers who might work on the project later can actually meet their deadlines as well is easily effort that is very well spent. The relatively minuscule amount of time you save during the initial phases of a project by being laz
Re:Get over it. (Score:4, Informative)
By the time your prototype has 20 paying customers and publications in the trade press you can afford to bring in somebody to 'clean up the mess'. For the remaining 19 prototypes you just saved 90% of development cost with no harm done.
Not ideal, but yeah - perfect code is worth nothing if it never sees the day of light.
use the thedailywtf to your advantage (Score:3, Funny)
Re: (Score:3)
"worthless" seniors created the company and keep it in business and likely solve the vast majority of the issues that come up. might want to keep that in mind.
if you don't believe this take a look at open source projects. the ones with longevity (linux, xorg, mysql, mozilla) are run and carried by "worthless" seniors.
WTF does elegant mean? (Score:4, Interesting)
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
Re:WTF does elegant mean? (Score:5, Insightful)
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.
Re: (Score:2)
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
Re: (Score:2)
Temp tables can also make queries run faster especially when confronted with a single three pages long SQL statement.
Re:WTF does elegant mean? (Score:5, Insightful)
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.
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
There's absolutely nothing wrong with clever code or even deliberately using obtuse features of a language or framework to get a particular job done in an optimal fashion.
But...
Such things should always be gratuitously commented... clearly and quite thoroughly... because much as we'd like to think that anybody who maintains the code we write will be always know absolutely every trick or optimization that we might has either not been a professional programmer where they needed to work in a team for any
Like code doc more than code? (Score:5, Informative)
>> 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.
Different people have different programming styles (Score:3)
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.
Dupe (Score:2)
This is the third time this question comes up.
You two should talk (Score:5, Funny)
Might you be complaining about this gentleman? http://ask.slashdot.org/story/13/01/03/2255204/ask-slashdot-how-to-react-to-coworker-who-says-my-code-is-bad [slashdot.org]
Re: (Score:2)
Might you be complaining about this gentleman? http://ask.slashdot.org/story/13/01/03/2255204/ask-slashdot-how-to-react-to-coworker-who-says-my-code-is-bad [slashdot.org]
I wish I had mod points for this.
Functional or "Style" Mistakes (Score:5, Insightful)
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".
Re:Functional or "Style" Mistakes (Score:5, Insightful)
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.
How to phrase the change log entry (Score:2)
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."
Re: (Score:2)
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
Ability to respond to requirement changes (Score:3)
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?
Re: (Score:2)
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.
take responsibility (Score:5, Insightful)
Re: (Score:2)
Dupe? (Score:2)
http://ask.slashdot.org/story/13/01/03/1859210/ask-slashdot-how-can-i-explain-to-a-coworker-that-he-writes-bad-code [slashdot.org]
Deal with reality. (Score:2)
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
Same as everyone in IT. (Score:3)
With cruel sarcastic insults.
"quality" is hard to judge (Score:2)
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)
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.
Hire somebody to help (Score:2)
Learn from him (Score:5, Insightful)
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.
Lucky you. (Score:2)
It works and gets the job done
In order for my coworkers to make anything that works, the planets have to align
Learn (Score:3)
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.
This is a clash of styles. (Score:2)
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
Leave him alone. (Score:2)
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.
The usual (Score:2)
Recommend him for promotion - to another team.
You're doing the right thing (Score:2)
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)
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 delegate coding changes to you (Score:2)
FTFY: Rewritten the question correctly... (Score:5, Funny)
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"
Re: (Score:2)
This.
Typically those that whine about "sloppy" are newbies fresh out of college.
Somewhere out there ... (Score:4, Funny)
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.
Re: (Score:2)
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.
http://ask.slashdot.org/story/13/01/03/2255204/ask-slashdot-how-to-react-to-coworker-who-says-my-code-is-bad [slashdot.org]
no exceptions
Let's break down the problem a bit. (Score:2)
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
We can help (Score:2)
Just post your work and we'll clean it up for you
Report the unfollowed bugs (Score:2)
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.
Try asking his opinion (Score:2)
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 (Score:2)
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
Move on (Score:2)
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
Re: (Score:2)
The real question is: (Score:2)
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
Ask him and prepare to learn (Score:2)
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
This reminds me (Score:2)
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
Why the hate? Maybe submitter is right? (Score:5, Interesting)
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.
UML - designer not programmer (Score:2)
Re: (Score:2)
Basic idea is to flowchart important stuff. Get it approved by buisness. Then pass the generated code onto junior developers.
Generating code automagically = huge win. We've been doing it since the appearance of first assembly language, first adding mnemonics for opcodes, then adding expression translators and register allocators (FORTRAN), then adding lexical scope, subroutine prologues and epilogues (Algol), all the way up to ICs, PICs, open-coded allocators etc. Editing the results by hand = even huger fail. Why do we have the toolchain again? Does anyone compile .c files into gas assembly only to edit them by hand? I see a hor
Re: (Score:3)
This. If it's your job to go and fix his mess, do it without complaining. And document all the effort you put into it, to avoid being labeled as someone that just rewrites code without adding anything.
If you are not responsible for cleaning after the senior, then don't do it, let it all rot until somebody (your boss, or even your colleague) makes the decision it's time to clean the mess.
Re: (Score:2)
That's fine in school. You and your classmate were peers with a comparatively objective "supervisor" (professor.)
This is the junior guy telling the senior guy his work is sub-par. Not likely to go as well.
Re: (Score:2)
Re: (Score:2)
JSHint (aka Crockford Enforcement Enforcer)
JSLint (aka Crockford-lite)
PyLint (PEP8 compliance tool)
I am sure there are loads of others, but I work with js and python, so that is what I know.
Re:Visual Studio with ReSharper (Score:5, Interesting)
That'll speed the process up, you betcha. (Score:2)
Great idea! That way, you can get on with the process of interviewing for your next job so much faster.
Because, you know, being a self-righteous irritant to senior staff in the most obnoxious way possible is always a great way to terminate your current employment. You won't have to bother keeping track of any references, either, since you won't want future employers to talk to anyone you've already annoyed. It's win-win!