Slashdot Mirror
Ask Slashdot: How To React To Coworker Who Says My Code Is Bad?
A week ago, you read the other side of the same question. Now, an anonymous reader writes "I have been with my company for 10+ years and have seen many development cycles on our projects. We have a developer intern who has not been on the team for very long. On day one he started ripping into my code on how terrible it is. We have a code base of roughly 50,000 lines of code. When he comes to me with a complaint about the code it is simply because he does not have the experience with it to actually understand what the code is doing. He is a smart guy with lots of promise, he is asking good questions, but how do I get him to look past his own self perceived greatness enough to slow down and learn what we are doing and how we have pulled it off?"
After all, he's fresh from a CS program where they taught him everything.
What political party do you join when you don't like Bible-thumpers *or* hippies?
This is an ancient problem, with 10 years experience I'm amazed you haven't run into this constantly throughout your entire career. New guys (even old guys) perceive everything they didn't write as shit.
How you deal with it is dependent on a lot of things.
First: is he right? Maybe your code does suck. Hell maybe you suck! At minimum. code that has been around for a while, has been written by multiple people over a long period of time, been adjusted and re-worked to meet changing requirements, and been done under a deadline usually does suck at least a little. Admitting this is hard.
New guys want to re-write everything and don't understand the value of code maturity... most of the time a re-write isn't practical, and even the shittiest code usually attains remarkable stability by virtue of having all the bugs pounded out through years of use. Reminding him that this isn't a university project and a certain level of ugliness should be expected might help.
If you don't think he's right, learn how to properly describe why you do things the way you did, and conversely expect him to explain why they are wrong. This is the biggest thing to learn when doing code reviews, and applies here. If you can't objectively describe what is wrong using with references to either standard or internal best practices or conventions, arguing code ugliness just becomes subjective. If you want to defend your code, learn how to describe how it doesn't suck.
Having some company guidelines will really help, because it gives you something to point at in defending a decision. Ultimately what one guy considers good code may be considered bad by another. You are always going to have cases where someone thinks your code is too abstract, or not abstract enough, or sacrifices too much performance for maintainability, or too much maintainability for performance. At least with standards, the new devs will rail against the standards rather than personally attack you, and a standards document is a lot easier to defend (and yet still allows good changes without too much politics of hurt feelings).
Critique is only as good as the suggestions for improvement. So, that's your answer. I feel that if someone has issues with my code, then show me better and prove me it is better. In the end, clarity, code reuse, design patterns, performance, all of these things come to play.
Just say "FUCK IT ALL AND DO YOUR JOB!" and then turn back to your display :D
Did you even RTFS? They linked to it.
Take a step back and seriously consider his criticism, as if he were one of your 10+ year coworkers. Whether or not he's right informs the right reaction.
Firing him might be the best lesson he ever learns...
You Are Not Your Code: http://sstephenson.us/posts/you-are-not-your-code
Ask Slashdot: How Can I Explain To a Coworker That He Writes Bad Code?
If you have the time, try to find some impartial third party who has nothing to do with your company. Grab a snippet of some code (not enough to give away company secrets or whatever), and have him evaluate whether the new guy is just full of himself, or you are.
I'd probably bet my next paycheque that the code itself falls somewhere right inbetween the two extremes, but both the new guy and the old guy are too stubborn or filled with illusions of grandeur to see it any other way than what's cemented firmly in their heads.
Might as well close the forum down, this is gonna be the best answer concerning this issue. if only I had mod points
have you seen my sig? there are many others like it but none that are the same
Give me a freaking break...
< insert witty song about geeky stuff here >
coding is life
- Have a real code review in your group and get everyone to contribute to better solutions
- Use all static analysis tools and styling tools available.
- Remove dead code
- Refactor redundant code
- Add unit tests
Consider that both you and the intern need to ditch your attitudes, and make improvements for the betterment of the product.
Wow could you not even be bothered to even read the first sentence of the summary?
A week ago, you read the other side of the same question.
Guess what? Yes, that was the question you linked.
outside, at the gate.
And ask him what you can do to improve yourself? Do so in a way that gives him work to do in correcting you. But either way...offer to buy bad code offsets
You can always learn, and the world can always stand to benefit from more people offsetting their Bad Code.
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
And a follow up question: do you have any internship openings?
Seriously, if he was hired as an intern I take it he has little/no real experience, and may not have even finished his formal education. He thinks your code is bad because it doesn't look like the code of whatever professor he most admired in school, or it violates some rule of some particular coding sect that he subscribes to. Tell him to write his objections down in a safe place, and come back to them after a year of working "for Real" and you will gladly sit down and listen to what he has to say then.
I would be as blunt, harsh and straightforward back to him, as he is was me, were I in your shoes. I might add a few nails to the coffin of the argument.
Him: "Your code sucks."
Me: "Back it up. What suck why."
Him: *explanation*
Me: "Well, I can understand you not realizing X, Y, and Z, being new and ignorant, but give it a few years."
Him: "Why'd do you do [pattern X, Y, Z]? Isn't it better to do [pattern A, B, C]?"
Me: "In certain circumstances, sure, but in [insert current circumstances and logic for X, Y, Z], this methodology works better."
Put him in his place if he needs it, otherwise, just educate. Also, listen - just because he's less experienced than you doesn't mean he hasn't picked up something useful. I know a lot of people who think they don't have anything to learn from the new guy, when the new guy had a few tricks up his sleeve. I've been one of those people who's learned from the new guy he didn't suspect. I've also been the new guy with unsuspected tricks.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
*ducks*
Recently went through this myself. Despite having used a kanban board, used version control, commented code, written unit tests, etc, some junior devs thought the code sucked. My takeaway was that there were still too many barriers to entry. Too many passwords, not enough installation instructions, etc.
Somewhere in the process of learning to write production ready code, it occurred to me that it was necessary to work the process backwards. Begin a project by setting up your hosting or distribution environment before starting to code. Write unit tests before starting to code. And so forth.
Getting other people to contribute to your project requires the same kind of thinking. Set up a project page before you start to code. Write a vision statement before you start to code. Write installation instructions, coding style guidelines, and operations support instructions before you start to code. That way, as you proceed in the project, you have clearly build up the documentation that other people are going to need to join your project. These things shouldn't be started after the fact.
If you can't point a new dev to a website and say 'download the source and instructions' here, it's probably too complicated and will meet resistance.
Only fifty thousand lines? Is this really possible?
From your description, the guy isn't mean spirited. He's likely never had to deal with multiple revision code bases before.
On the other hand, if this is code that has been through multiple revisions and re-purposes, admit to yourself -- it probably is bad. I'm the lead engineer and dir. engineering at a company I've been at for 10+ years, and I'll be the first to tell you that the code-base I am most proud of (30-50k lines of embedded/DSP code, mostly mine) is TERRIBLE! I wouldn't wish that code-base on my worst enemy. But its also been bread and butter for the company for the last decade and is stretched to its limit.
We've had at least two hotshots come onto the project in that time who have been terrified seeing that code-base and declaimed it as schizophrenic at best, and they are right. It is bad code, poor coding practices, and everything else bread out of necessity to keep the project(s) going and alive.
Your mission -- accept that whatever reasons are out there for the code being the way that it is, it probably is poorly structured and could use a rewrite. SO - this is a good chance for him to learn that not every bit of code that should be rewritten can be. Its called business reasons and experience. Whatever the reasons, you probably, as a company, don't have the time or resources to rewrite from scratch (we surely don't!), but a fresh out of school developer probably has not experienced these -non-engineering- reasons for bad code, and certainly was not there for the blood, sweat, and tears that went into them. He won't know about those all nighters that "saved the company" that you and the rest of the team probably went through en-route to this codebase.
What is the problem with his criticism? Encourage him to write a patch for improvement. If it's better than what there was before, he was right all along and you have learned something new; otherwise he has learned something.
Perhaps the problem is you just don't want to hear criticism of your work (a common problem). In this case you should consider working in a team where there is less back-and-forth. Like a one-person company.
Ask him how he would do it, and be genuinely interested in his response. Maybe he just wants to beat his chest a little, and maybe he'll even say something useful.
I'm sure if he re-reads your internal design specifications, coding standards, and comments in the code he will understand your design.
It's also possible the younger coder learned a trick developed since the older coder got his skills fairly solidified, and the older coder never saw, or came up with in his own experiences.
Just because the new guy is disagreeing and less experienced, doesn't make him wrong. Yes, 9 times out of 10, the new, less experienced guy will be wrong, but that 1 time out of 10, makes it worth giving the other 9 times a fair hearing as well.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
. . . are really just not satisfied with themselves.
Give him a copy of "The Psychology of Computer Programming", and tell him to read the bit about egoless programming . . .
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
You are very fair and polite in your description of the situation, so show him this page with all the responses.
Give him time with that, and to get a more mature viewpoint through that experience.
Sounds like he wants to be a big boy. Put him in your shoes with an incredibly challenging and time-sensitive project (real or fake). Then start changing the project requirements every week/day at random. In my experience this is how shitty code gets made (other obvious way is person is inexperienced).. If his code works and looks great and is bug free, maybe you'll learn something, if not, maybe he will..
If a co-worker can't present criticism in a constructive way, his road to success in a company is going to be long and steep.
Anyone who's written any serious code knows that compromises are made too often because of schedule or resource limitations. If you haven't done that you work for an imaginary company or you are lying. Code/software architecture can almost always be improved, but if there is not a business case (and often, even if there is), it will still not be improved.
The most valuable lesson this intern needs to learn is that you work with people and they are human. If you call my children ugly, then anything else you say is not going to be greeted warmly.
We've all been in situations where a new hot dog 'somebody' comes into the workplace, swings the dong around to show their intellect or to make their positional place in their new turf. Put your tenure and title away, along with his/her blunt explanation or criticism of your code for a second and I think what you have to consider is merely a few things:
1) Did he/she make you think about something you didn't consider before or how to handle?
2) Did he/she offer absolutely any real suggestions with proven code that will expand on what you did and make it better?
If it's 'no' to both, then tell that person to piss off. Because it's nothing more than someone wanting to hear themselves speak.
I have this happen to me all the time: People question what you, how do you, why you do, not because there's some sense to 'learn' from your experience, because they are just simpletons who try to be this all-knowing-intellect-goat and 'look good' in front of their peers.
I think if you have a perfect, well-balanced, engineered, methodical and concrete explanation WHY you did something, then I would consider the person's commentary as a fart in the wind and certainly as nothing more than being a typical douche-bag trying to hand out solutions-looking-for-problems.
It sounds as if your code is lacking. Specifically, you need to add some comments to explain WTF you are doing and/or why TF you did it that way. There is no excuse for anyone looking at your source code to not understand it.
/* changing to this funky data structure because jerry's an idiot */
/*funky data structure description follows:... */
Did you have to use a funky data structure because jerry's an idiot and his functions couldn't handle your original one? There's a way to explain that:
An old mentor of mine once told me "I try to comment my code as if, a year from now, an idiot may be looking at it and trying to figure out what I was thinking, because I may have to look at this code a year from now". That stuck with me. Even if you can remember all the reasons why you did things yourself, if your code doesn't have comments explaining these kinds of things clearly, be prepared to defend it over and over again every time someone looks at it.
Well I am back at the place where I was 10 years ago. I thought the code was great then, I think it is shit now.
But what I've learned in the intervening time, and having been a software development manager myself, is that code is optimized on a few axis:
- Brevity (get er done!)
- Clarity (I'll be able to read this again in 5 years and understand it)
- Structure (Object models)
- Formatting
- Efficiency
All of them factor into a meta category, which I call "Maintainability", where you want high clarity and structure. Maintainability is by far the most important aspect to an organization. Your n00b developer won't have your company's maintainability desire in mind. Efficiency is the dead last because increased computing power is cheaper than the development time to make it efficient, save some scenarios.
So my recommendation is to have him rate his code on those axis and your code on those axis. Hopefully he'll learn there's more than one way to code. It is very likely he's just out of school and his head is filled with registers and asymptotic running times. Those are important, but not as important as shipping maintainable code on time.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Each one immediately assumes that they are in the right.
As I've said before, negative feedback improves the product. Positive feedback improves my ego, but little else.
I don't like the standard "Don't complain unless you have a solution!" response. Often, the "solution" sucks, so we use that as a way to beat up the "whiner." Or, it is just used as an excuse to shut them down.
I get really, really pithy feedback on some of the stuff I write. That's because of its audience. Folks that are used to beating their problems into greasy stains on the sidewalk.
Saying "F**k Off!" is not an option.
It's my job to research the feedback. Sometimes, they are right, sometimes, they are wrong.
My first software job was working on 100,000+ lines of 1970s-vintage FORTRAN IV code, through 300-Baud modems. The code sucked. This was everyone's (including the original author's) opinion.
Still, it was our product, and we had to keep it going. Bug fixes often were most effective when done after circling the cubicle 3 times widdershins, and sacrificing a can of Jolt. You poked, and hoped that it fixed the bug.
After that, all code smells like Chanel No 5 to me...
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
Yeap. If you have 50,000 lines of code, and it isn't clear how to enter it and begin to understand it, then the code sucks. It might be good in other ways, but in at least one crucial way it's bad.
"First they came for the slanderers and i said nothing."
Interesting question and one I've thought about for a bit since the original question, from the other side came out.
I would say, bring in the team lead as an arbitrator. It's their job to direct the work and (hopefully) develop team members - this guy sounds like he needs a bit of development and level setting.
myke
Mimetics Inc. Twitter
About a month ago there was a "How do I tell my co-worker he writes bad code?" and now this!
Clarity and maintainability are characteristics of good code as well. Not just the smallest, tightest, most accurate, fault tolerant or most abstract design/implementation possible.
Everyone, and I mean everyone thinks the code they're working with is shit and they can do better. In reality all code settles down to the least common denominator.
The problem that the "new guy" has that the seasoned people don't have is facing the reality that deadlines, design mistakes, inter-operation with different teams, maintaining an old code base, changes in coding style between developers, maturity of the company, maturity and stamina of the active coders all factor into a project. Not to mention simply setting the right standards and scope to get the project done. If you have never seen someone make horrible desperate compromises to meet a deadline, you haven't worked long enough.
Problem then solves itself.
I've come to realize that the code I wrote years ago could have been done better. There might be some truth to his words but he might not realize yet that as time goes on you get new deadlines, projects, etc that can keep you from going back and changing things. This is especially true if those things are working fine the way they are so why fix what isn't broken?
Note: This isn't saying that you never have to go back and fix things, just that the time isn't always there when you'd like it to be. One of many reasons why that person is at your desk since they got fewer deadlines and more time so to speak as the new guy.
~~ Behold the flying cow with a rail gun! ~~
This questioner says he's been at the company 10 years and the new kid is hassling him. That prior question says the guy he's hassling has been at the company longer than the hassler has been alive. If they've hired a 9 year old as a coder then they deserve all the atttitude they get.
Every new guy coming onto a project thinks the existing code is crap. They will want to rip it all out and do it over from scratch. And, if they did, they would quickly run into all of the bugs and problems which caused the code to take on the form it does. New out of school coders are terrible for this as production code rarely looks like textbook code.
My suggestion would be to explain why you do things your way. Then ask him how he would improve the design. if he has good ideas then that is great. if his approach has obvious flaws, point them out to him. One of you (hopefully both) will learn valuable lessons from the exchange.
Stay in the agreeing side with him. Let it be, we can all have opinions. Now, ask him do this:
* Go out in the wild and find code-dissecting and style- or flaw-checking software tools (snavigator and its spinoffs).
* Ask him produce all sort of reports with these tools, especially the call graphs, inheritance if there is such etc.
By the time he finishes, he will know the code inside/out, have asked the interesting questions and even have started contributing back.
If he can't follow that, he's probably not ready for the team aspect.
All real world code sucks. Seriously. Mine, too. It's all a matter of priorities. Writing good code is hard. Writing good code that is constantly changing is almost impossible. Considering the value of the resources (your time) it would be stupid to not except trade-offs. When someone joins the project it gives valuable information where the parts are that are difficult to understand. Improve them by making them clearer and everyone profits.
When faced with spending an additional, relentless, unpaid and thankless 20 hours per week to fix the engineering mistakes and sloppy code, he'll fall in line soon enough. You can throw a "welcome to the world of the career programmer" party for him when he figures it out.
Before defending you, we need to know if your code actually suck or not. Post some example or something, then we will help if you deserve it.
it sounds like he has some growing up to do. with that fact out of the way, you are not Don Knuth. at least some of his points have merit. Put aside pride and work to understand his viewpoints. Only after you clearly understand what he's saying you can a agree or explain tight deadlines or explain why the existing approach is better. You can certainly make liberal use of terminology he's unlikely to understand to put him in his place. First, though, be sure you're really listening. Seek first to understand, then to be understood.
By definition your code sucks, because it's legacy code and you wrote it.
So what? Does it work? Does anyone want to fuck with it? Is he willing to risk his job to change the code and break everything?
New developers want to rewrite everything, and don't understand that new projects don't happen often - and when they do, they don't get to work on them unless they have skills. That doesn't mean they need to kiss ass, but it does mean that they have to write code that works.
Maybe there -is- a better way to write it now. It'd be worth it to ask. Maybe he's right? Most likely he's has no context - it's written that way because it was written that way. Maybe he can rewrite it in his spare time and show everyone.
NOTE: if he was able to read your code and said it sucks and should be refactored or something, that means the code doesn't suck as much as he said it does - because he could read and understand it. That means that it's maintainable. So that's a plus on your side.
The problem isn't the intern who doesn't understand your code. The problem is the intern who doesn't undestand how to interact with grownups.
Explain to him that if he ever wants to be an employee - there or anywhere else - instead of an intern, that he needs to learn to be more diplimatic.
The only way to deal with this professionally, is to look at his complaints in detail and either refute them or acknowledge them. Code quality is an area that cannot tolerate any power games. Have him actually explain in detail why he things some piece of code is bad and then explain to him why it is not, or why there are external circumstances that require it to have the form it has. Make that perhaps a repeated session, until one of you learns something about their coding skills. Go into this open and with a pure technical PoV. If he should happen to be right, then he is right. If not, you have to be able to explain why. That will also deal with the most common source of this behavior: The younger person feels under-appreciated and not respected.
If that approach goes nowhere because he cannot admit limits in his skills or is unwilling to learn, escalate to management. But make very sure the problem is not on your side before you escalate. Typically, escalation will not be needed, but some junior engineers are so convinced of their own superiority, that they cannot see anything else and cannot learn. I had that twice. In one case it resulted in the termination of the lady in question. That one was so set in her ways, she was not even willing to implement an interface designed by somebody else, but could not explain why it was bad. (It was not. She was just not able to implement anything not of her own design.) Zero team-working skills and zero ability to learn. It happens and it is not your job as a developer to resolve it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
As an engineer, I've adopted the maxim that there is no good and bad, only fitness for a particular purpose. I prefer a discussion of trade-offs to statements of principle.
I tend to ask "what requirements does this code fail to meet?" And very often, the reviewer has invented his own new requirement! Depending on your process, your response might be anything from "good point, let's add a test case for that" to "you should submit a Requirements Change Form for that. Make sure to get all the required signatures."
And if the criticism is for something immeasurable like "readability" or "maintainability" you can let your critic make the case to the boss why fixing this code is worth the cost.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
No, the other question just stated that the person had been programming longer than he had been alive. Not that he had been at the company for that entire length.
Of course, being a very smart person who has been programming since before I was born makes him fairly impervious to criticism,
Devil's Advocate:
Just because he's young and fresh doesn't mean he has nothing to contribute. He may very well have learned something valuable that he's trying to share. It is difficult for many engineers to withstand criticism and often instinctually become defensive ("ripping into my code"). Even if you've been there 10 yrs, as a technical professional, you should be making an effort to stay current on techniques.
Reality:
If there exists excellent unit & integration test coverage of the subject code area, then let him rework it if he cares that much about it. If he breaks the tests, he fails. Succeed or fail; he can then explain to the business why he spent expensive engineering labor reworking something not on the value-added todo list that was already functioning properly. I think a lot of professional engineers are a bit perfectionist which can interfere with making appropriate decisions in a business context. You know - academic v.s. practical.
Why not?:
In this case, for only 50k LOC, it shouldn't be too difficult to overhaul nearly everything towards more modern methodologies and techniques (not fads). This also makes it sound like a small project/firm where there should be greater agility and flexibility to change things. There should, however, be a compelling reason to do so. The effort and brainpower is better spent developing new revenue-generating features.
I recently had to put up with a new "smart" guy who only had a few years of experience and was hired for a position he was not even close to being qualified for because his lack of real-world experience, but he made up for it by being a friend of one of the bosses.
Just like the poster's experience he had to start working with a huge codebase that had evolved over 10 years of constant changes. He was way over his head. He didn't have the first clue how to find his way through code he didn't write. That was understandable. I have decades of experience and I've been thrown into huge mature projects many times and I can quickly orient myself and become productive with code I've never seen before. I couldn't do that until I had many, many years of experience.
But rather than admit he was over his head he did what all ego-driven individuals do -- he attacked the code, he attacked everyone who'd ever written the code, he demanded that he be allowed to rewrite it from scratch (because he knew he could rewrite 10 years worth of code in just 3 months because he was "that good").
Although I had only worked on small parts of that code base from time-to-time whenever he got bogged down unable to find or fix something I'd come along and in a very short order find or fix it for him. In a few cases he'd describe a bug to me and I wouldn't even have to look at the code to tell him what likely is happening and what he should look for. Again, that's the difference between vast experience and purely ego-driven bravado.
In time did this guy learn humility? No. He's messed up badly over time and lost credibility, but since one of the executives' credibility is on the line it is hidden as much as possible. The guy still brags, still is way behind schedule, still puffs up his chest with ego, but fortunately I no longer have to work much with him.
B-B-But...
Stacktrace.
Or.
GTFO.
If the code is so bad, give him the assignment of fixing it. Allot say 8 hours, or maybe even a week if you want to get him out of your hair for that long, where is assignment is to find the worst problem area that will have the greatest possible positive effect on the project, that he can fix start-to-finish within that time span, re-write, test, go through your complete process whatever that is, get completely ready to commit. But it all has to be done/complete within the allotted time frame. At the end of the time, take his code, evaluate & review it with him & 2-3 others who are intimately familiar with that project. If it's fabulous code that really does meet all requirements and improve on the existing code, then hurrah! Commit it and you're a step ahead. If (as is more likely) is full of shit and has far more serious but possibly hidden problems than the code it's supposed to replace, then you explain the problems to your boy wonder, deep six the supposed improved code, and it's a learning experience for everyone.
Incorrect, he said the guy he's hassling has been "programming" since before he was born, not at that company per se. RTFA.
stare him directly in the eyes and, in an outrageous French accent, curtly state "MIND YOUR OWN BUSINESS!"
Karma: NaN
I just started someplace as an intern working under some positively brilliant and highly accomplished people and, unfortunately, have been complaining a bit about code quality. Hendrik, if you're the OP, then I apologize!
Even if this post isn't targeted at me, here's what could be happening:
The codebase off of which I'm working is highly efficient, effective, and successful from an algorithmic/functional standpoint, but at great sacrifice to software engineering practices. Huge chunks of little-related and deprecated code are all in the same file, global variables are used for almost everything to avoid passing them around, variables are unintuitively-named (e.g. "limg" and "rimg" are "layered image" and "raw image", rather than left and right), and there a slew of objects that have similar purposes, but aren't related from a object-hierarchical standpoint, making it difficult to pull the necessary data from them for processing.
I completely admit that I don't understand most of the codebase is doing, but that doesn't make the code [i]itself[/i] bad, but rather the organization. We're in a research division so the code is extremely advanced (everyone who's working on it has a PhD, while I'm an undergrad), but if it were partitioned into well-named methods and commented more, I'd at least have a much better sense for what's happening with the code, even though I don't understand what's going on with the code itself.
TL;DR: I'm in an identical situation as the intern; OP's code may have poor readability for fresh/inexperienced eyes, resulting in loss and confusion on the intern's part. Better commenting and code organization would help reduce those negative onboarding experiences significantly.
There are no coders or technically literate people here.
Incorrect.
"You dare insult my code!? I'll kill you where you stand!"
Might I suggest you give him a poem?
Roses are red,
Violets are blue,
All of my code is bug-free,
Perhaps it's time you got a clue.
How to react to the coworker who complains to you that a coworker thinks that his coding is bad.
listen to his concerns, and explain why they aren't valid, or take them on-board if they are. He's trying to make his mark on the team, and assert his position, and may want to be the "alpha" of the group. It might not hurt to remind him he's a junior memeber of the team, but doing so without belittling him could be difficult. You could also just tell him you inherited a lousy code base from previous developers or something like that.
If he's complaining then he needs to explain why it's bad. Who knows, maybe he's onto something but if he's just some "straight out of uni" brogrammer, then put him in his place.
Just tell it "Well, if you think it's that bad, go ahead and improve it. You'll get fully responsible for it though."
In college I learned .NET languages right after they had been released. It's been my experience that anyone about 5+ years out of college has no idea how to code properly with them. They write the code like it's VB6 instead of VB.NET and I'm sure it makes sense to them but it's so far from MS's best practices or any remotely modern coding practice, it's almost impossible to read. It's so roundabout and needlessly complex without using any of the new features and there are legacy commands galore that should have been removed from the language that I've never seen before because superior modern ones exist and that's what we learned.
So in summary, your code likely is less than ideal. As a general rule, the closer someone is chronologically to having finished college, the more correct and prettier their syntax is and the older programmers simply refuse proper retraining or learning in general really.
The first problem is that you regard the code as "yours" rather than "the project's" or "the company's." Engineering discussions should not be personal, and getting emotionally attached to the code is unlikely to help you evaluate it objectively.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
You stop writing shitty code
...longevity should be limited, I would (severe, though probably merited by his superior (for an underling) attitude) tend to reduce the priority of his learning experience. If he was under evaluation for a permanent position, I would think this confidence/arrogance should buy him an earlier than usual trial-by-fire of a somewhat substantial project, or at least a portion of one he can lead the development on. Hopefully, he would do well, though probably still find himself a bit more isolated than he might otherwise have been, which should be helpfully chastening.
Ok. If he thinks it sucks then invite him to make it better. Cause you're awesome like that and have so much free time.
We always see bad code as technical debt and treat it as debt. When we have cycles we pay it off, when we don't we get some more.
Having been doing this for 12+ years, I have come to realise I have never liked anyone's code and figured out its more of a style or personality than bad or good. Yes there is bad code, but there is no good code per say. Or put another way, if done right its good and you and I still may not like it.
Its just the nature of the beast, its kind of like driving a car, all other drivers seem bad.
If you DON'T think the code you wrote any more than six months ago sucks then you're probably stagnating.
I'm being a bit facetious there of course, but the point is that a good developer is always evolving and learning and you should see the flaws in your own existing code as time goes on because they're ALWAYS there. Often-times it takes a fresh set of eyes to see them.
That's not to say the guy isn't an obnoxious jerk who thinks more highly of himself than he should. If it was me, I'd turn it around on him: "Ok, could you please rewrite the code as you think it should be, and then we'll do a code review of your solution?" You have to do this with an open mind of course because in some ways his solution may well be better, but chances are in other important ways it won't be: it'll probably be more complex (because inexperienced developers ALWAYS think more complex than they need to), it'll probably be less maintainable (probably commented like shit for example) and probably more "flexible" than it needs to be (new developers always think 10 levels of abstraction makes things more "flexible" because they don't understand the realities of day-to-day development and maintenance).
Bottom line: you can probably learn something from him, especially given you think he's got promise, but he most definitely can learn from you... and the first time he realizes that I bet he backs off and treats you with the respect your experience should entitle you to.
Seriously, how do you have 10+ years of coding on this code base, and still have no clue how to respond to this kid? "Dear Slashdot, a bully pushed me down today on the playground, and said my face looked like a butt. How should I react?"
There are some very easy options here:
1) Is he right? If so, ask him for some pointers, and try to learn why it's bad, and how you can improve.
2) Is he wrong? If so, explain to him why he's wrong.
In both instances, realize that "your code sucks" is not an objective statement, but a subjective statement. He's saying, "I'd write it differently." So, without acknowledging the personal critique one way or another, ask him to rewrite some pieces on a separate branch in version control, and talk about the differences when he's done - why he did it one way, and you did it another. He might have some good ideas, and some bad ideas, mixed together. You might learn a few things, and he might learn a few things.
But really. I can't believe that a grown fucking man (or woman!) needs to ask this question. I'm tempted to believe that the new hire is *right,* simply because you seem dimwitted enough to have to ask this question as an - ostensibly - experienced professional.
so I never have trouble with the critique. Most of the people who criticize my code however, allow that my software is usually more reliable then theirs (fewer errors and crashes) and has the best interfaces in the office (i.e. easiest to understand and navigate). So, what to make of this? They keep asking me to write stuff, even though I barely use classes except to extend and manipulate arrays (I use a lot of arrays). Empirically, this tells me that good form isn't everything, and that while it's nice to know about callbacks, virtual void functions, etc. for most everyday little apps, it doesn't seem to matter much.
Please do not read this sig. Thank you.
say "I'm rubber, you're glue...... etc"
then give him an atomic wedgie and/or a swirly....
OSHA sandards call for at least a 2 man lift for swirlies BTW.... safety first!
https://vernonryoung.wordpress.com/2010/01/11/banning-assholes/
My current team is very good about providing positive criticism and admitting when our code sucks. We are all in it for the same reason, to produce a great product and make money, but last year was a different story. We had a guy who would never, ever take responsibility for bugs in his code and would openly criticize others because it wasn't done the way he would do it. No matter what your reasoning was, you were wrong, he was right. Period. He could have been a good developer had he actually taken input from the team.
These guys HAVE to go! They will bring down the morale and productivity of the entire team.
Knowing that your work will be negatively criticized obstructs the creative flow needed to produce quality code efficiently. I've personally lost hours either being upset or second-guessing my work because of unfair criticisms. Just replacing that one guy has made a world of difference. We are now very direct with each other, accept that we make mistakes, and can even jokingly say "What the fuck were you thinking on FooBar.java:152!" and no one will take offense.
Explain to him why his behavior is unacceptable, and if it doesn't change, let him go.
In class he was graded on things like code efficiency and punished for NOT following certain guidelines by getting a bad grade. In the corporate world, you get paid based on your code working, and doing everything it's supposed to do. No one in management cares if a module is 1500 lines vs 1200. Welcome to the real world.
Submitted by the same guy even. Either the submitter got put in his place when he tried to tell the more experienced guy how to do how job or the submitter is just schizophrenic and is talking about himself.
If you are not allowed to question your government then the government has answered your question.
The odds are really high your code does suck. I've reviewed a lot of code, and guess what, most of it sucks big time. Few programmers actually write good code.
Just because the new guy is disagreeing and less experienced, doesn't make him wrong. Yes, 9 times out of 10, the new, less experienced guy will be wrong, but that 1 time out of 10, makes it worth giving the other 9 times a fair hearing as well.
I honestly don't think "experience" has anything to do with it. How long you've sat in front of a computer monitor doesn't directly translate to your understanding of software development. I've worked with a few guys with 15+ years experience. One created more work than he produced over 6 months (we were cleaning up shit from him a year after he was canned), another whom I bitched about in the last question really had no fucking clue how to structure code. He'd write stuff that "worked", but basically misused every concept in computer science. No one could follow his code and there was no clean way to cut it out. I also know plenty of CSc and S.Eng. student that never learned how to code in school. I mean, yeah, they passed assignments that required coding but never really got a grasp on writing software.
On the flipside I've worked with people straight out of school that were as good as experts with plenty of years behind them. The big thing I've seen is there tends to be two groups: people who understand software development and those that don't. People who don't understand can write working code and even create big projects.. but they are hell to maintain and even hell for that person to write. For people that understand, it's a lot more fluid. We all start at the ignorant stage and some get beyond it quicker than others, some never make it out.
I honestly didn't learn to code (as in really code) until late in my degree, but I buckled down and got over the learning curve.. then it all became a lot easier and way more fun. More practice and the fog cleared even more. I think I still have quite a ways to go (as I'm able to recognize those that are much clearer than I), but that's ok as long as I'm dedicated to moving forward and can recognize others are more cognizant and clear and lean on them when I can. Some areas I might be better than others and if they are good they lean on me for that. It feels great to work in an environment like that. Life is hell when you're trying to fix some clueless code.
One other observation I've had is that people that understand tend to code throughout their career. Those that don't quickly move onto non-coding positions (analyst, management etc) and drop coding as quickly as possible.
"If you are going through hell, keep going." - Winston Churchill
If you have to get on the internet and whine everytime someone critcizes you then just give up now. Maybe you should consider that perhaps he is right and your code sucks. Thats whats wrong with a lot of people, they cant accept the fact they arent right all the time and do everything wonderfully.
Grow some balls and either talk to him about like a mature adult or ignore him or maybe sit and look at your work and consider the possibility it does suck.
But if you get butt hurt everytime someone doesnt like something dont run to the internet hoping for some people to rally behind you to feel better about yourself and justify your work. Be a man for gods sake and grow up.
It's extremely common for bright young inexperienced programmers to take this attitude toward existing projects or code, so much so that I'm surprised that this is the only situation in which you've encountered this behavior.
A manager's job is to take this arrogant kid and groom him so that he can be used productively in a team environment. If he's already talking about how much your code sucks then he's got a bit to learn about presenting contrary opinions in a respectful way. All the same, you need to keep your ego in check so that his good ideas (if he has any) can be applied productively to solving the company's problems.
You start with him the way you do all new guys: assign him a small piece of the code and limit his job to refactoring or rewriting a portion of it. Make sure everything's marked in source control before you let him loose. And have him give a general presentation at the end (at the source code as well as the project level) as to why his changes have improved things. Reward him for playing nice with others and chastise him for being arrogant or a lone gun. And give him bigger jobs as he proves he can handle them.
My basic rule is to listen for as long as possible before overruling a junior programmer's opinion. Make sure that he has his chance to give his say. But after hearing it, take the counsel of your own 10 years over his if your opinions diverge. Experience does matter and there's really any substitute for it.
Maybe your code really does suck? I've had several instances of dismissing criticisms as a younger programmer only to understand more clearly why I was wrong later in my career.
I swear to God...I swear to God! That is NOT how you treat your human!
Years ago I worked with a senior guy who was very good but very critical of everyone else's code, often for poor reasons. One day I showed him some code and asked his opinion. He starts ripping on it and asks me why I did it that way. I reply "You tell me, this is your stuff from a couple years ago.".
Give him a sandbox to build his own code that does the same thing. Then be objective about evaluating his code.
This. 50K lines code in a modern language is a pretty small project. If that's 50K including lines of test code, it's tiny.
"If you are going through hell, keep going." - Winston Churchill
If he thinks the code is bad, ask him why the code is bad. Ask what his problem is with the code, and what he wants to improve and why. Ask him to be very specific, with examples of what could be improved, why, and how.
If you still disagree about the code and how it works, you can decide to actually let him rewrite a bit. Make sure you both agree on a relatively isolated/small part. Set a time constraint on the task. Then, when he's done, check. If he made better code - great! You might learn something and you have better code. He may not be so bad after all. If he made things worse, or broke them, or even if there it's just a matter of taste- great! He might learn something!
Also what you can do is get another person to look at the code, who you know writes clean code. Ask him what he thinks, and see if it matches the criticism of the intern.
He's an arrogant douche. Get rid of him. Any new kid who has the balls to call existing code terrible to your face is going to be nothing but far more trouble down the line. He already knows everything, and nothing you can say is going to get through to him. It's just not.
Get rid of him if possible, stick him in a little box otherwise. Don't let him work on the good stuff and hopefully he'll leave on his own because he's "awesome". Your bigger fear should be that he won't ever leave...
We have a few of those types in my office, and sadly we don't get rid of them because they have value just being present. It's depressing watching them bounce from project to project because they can't do anything right, and yet think they are god's gift to programming and that we're all just idiots.
Don't take the time to explain jack shit to him. It's been tried here, and they didn't change. People may say I'm too harsh and that everyone deserves a chance. My response is that they don't. People that act like dicks to others like that don't deserve another chance. Their next chance is at another job.
"coding standards" == a set of rules.
You can't run a world of open, evolving, complex systems by rules, that is what coding is, and we know the problems that exist in even our very controlled as-near-mechanism-as-possible environments.
If your 'coding standards' are 'coding guidelines' (they have to be), then both of you will have to think. Which is what guidelines are for.
More thinking, even thinking based on guidelines --> better code.
Quite a while back I came across the following two rules for development:
1. The code written by the guy who came before is junk.
2. Eventually you will be "the guy who came before".
Rule #1 tends to work because it's rare to be unable to find some way to improve code when you come back to it again with more experience or a fresh perspective.
Rule #2 helps keep you humble.
It's also possible the younger coder learned a trick developed since the older coder got his skills fairly solidified, and the older coder never saw, or came up with in his own experiences.
Just because the new guy is disagreeing and less experienced, doesn't make him wrong. Yes, 9 times out of 10, the new, less experienced guy will be wrong, but that 1 time out of 10, makes it worth giving the other 9 times a fair hearing as well.
But the thing is that, unless the code has a testable bug in it then it can only be "right" or "wrong" in the opinion of the person looking at it. All in all, I would quickly trust someone with 10 years of experience to determine what is "wrong" sooner than I would an intern. Sure he might have a good idea, but until that idea is adopted by others and proves itself, it is only "right" in his opinion.
I hate people that think everything they do is perfect and everything else is inferior.
I hate it moreso when I secretly check out their code that no one else ever looks at and see spaghetti code. Don't laugh, I did this recently and the guy is loved by managment. I guess the code gets the job done but if he ever quits, we are screwed. His stuff is totally unmaintainable.
What's "bad". Some things are objectively bad: Memory leaks. Crashes. Slow algorithms.
Other things are SUBJECTIVE. K and R bracing vs. Whitesmiths. Tabs vs. Spaces.
Some things straddle the border between subjective and objective. The first example that comes to mind is "descriptive variable names". Everybody agrees they should be descriptive, but not everybody agrees on how long they should be to accomplish that, whether CamelCase is better_than_underscores, etc.
You're "engineers". Break this problem down. There can't just be "your code is bad". There have to be several or even many things you don't like, or think is "bad". Address each one, starting with what you think is most important. Carve the "bad code" problem into little pieces until it goes away, just like you carve the specification into little modules and functions until it's met.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Specifically the feel/felt/found method (with an added 'f'.)
"Sure, I can see how you'd feel the code is [inelegant, not perfect, a festering piece of crap.]
When I was an [intern,student,temp employee,one-who-hath-not-earned-right-to-criticize], I felt that way about some of the code I reviewed.
What I found, though, was that there are almost always reasons why the code was structured the way it is. And before I, as [an intern, student, new hire, FNG-who-shoulda-known-better-than-open-my-trap] was allowed to criticize it, I had to first understand why it was that way and whether it is actually worth the effort to initiate a change process on it. Sometimes this would result in a change that was positive to the code and our superiors, and sometimes I had to learn that working and functioning code shouldn't be monkeyed with.
Maybe you need to ask more questions about the facts in and surrounding the code before offering an opinion on it."
If this (maybe delivered a little more tactfully) doesn't satisfy, then we must go with the fourth F - find out who is writing that intern's report and inform them they should Fail. Or go to the Intern directly and tell him or her to go F off, you'll pay more attention to what your boss says than a wet-behind-the-ears Intern.
The answer is really simple:
Step 1) Hire a second, unpaid, intern
Step 2) Give all the current responsibilities the 1st intern has to the 2nd intern
Step 3) Have the 1st intern do nothing but beautify your existing code, with the understanding that he can't change how any of it is written.
Your code IS bad. I know this because it doesn't look like my code.
Proverbs 21:19
Encase him in carbonite and mount him on the wall.
You know what else sucks?
Getting put down as a complainer and "not a team player" because management wants us to write new stuff instead of reworking old stuff that works well enough.
Lol, so last week, someone says, on slashdot; "How do I tell an old programmer his code sucks", now the old programmer is coming to slashdot and complaining about the cocky new guy, just lol. I'd put more faith in the season guy personally.
This is the reason most software is terrible.
I love it. They all graduate and think they're code gods with all their new design patterns & coding standards and havent worked a single day in production.
Quality of code has a very significant subjective aspect to it. There is correctness (does the code do what it's supposed to) which is pretty objective , but things like maintainability are not as easily quantifiable. What one person feels is understandable and easy to maintain another might feel is convoluted and hard to understand. It's like food. Some people like italian food and think it's better than chinese food, and vice versa. Almost everyone agrees that french fries are better than dirt, but that doesn't mean it's not subjective.
Also, the fact that I consider code beauty to be subjective doesn't mean that I am not extremely picky about code. I am a code nazi. There is a right way and a wrong way, according to my aesthetics, but there is no objective reason why my aesthetics are correct.
He's going to be gone as soon as the semester's over; don't let him touch anything important. He should be on one-off, throw-away projects. Counting on his coding ability in your bread and butter code is not a good idea. Once he's full-time and has a vested interest in what your team is doing, then his opinion counts.
Now, that doesn't mean he's not right; your code may well suck. But, you're part of the team that's been crafting it for the last 10 years, and you're the team that will be maintaining it next year. Anyone can provide drive by criticism, but as he won't be there to see the fallout of his knee-jerk impression of your code, tell him to STFU, junior.
That this and the linked story are really about the same two coders.
"Tell me something I don't already know" ... goes back to writing horrible code ignoring continued presence of said individual.
If someone has specific cogent points to make by all means listen, learn, engage otherwise whatever is coming out their mouths is most likely not worth your time.
Acknowledge that your code may not be great, for whatever reasons apply. Then use this as a teaching moment to set his expectations for the future. You ALWAYS encounter crappy code, you ALWAYS have to jam a feature into a place that originally was not designed for it, you always have to deal with the fact that the world changes, coding styles change, design philosophies change, technology changes, and your code is stuck at the point where you committed it.
Ragging on your coworkers code is a quick ticket to becoming the least popular guy on the team, and to being blacklisted everywhere. Remind him that constructive ideas are great, whining is a waste of air.
As one of my bosses used to say, "don't come to me with a complaint unless you have a cost-effective solution to suggest." Rewriting your entire code base probably isn't going to be one..
If you think that your code is not bad, but you had to do it a certain way because of a reason, then you should be putting that in your comments.
Those are the kind of comments that make reading a piece of code for the first time easier. I am an intern as well and I never say that code is bad, but I do often find myself asking people, "Is there a reason this code is written this way?" Most of the time they do have an answer, but if that was put in a comment then I wouldn't even have to ask.
In German there is a word for almost everything most English speaking people don't talk about ....
50000 lines? Luxury. I work with about 4,000,000 lines of code in my product (last time I counted). Your newbie doesn't understand that code gets worse over time. This is an excellent chance for him to learn refactoring skills. Assign him a module to refactor. Best case, you get better code and keep an annoying intern busy. Worst case, he learns a lesson in legacy systems.
I think there are only 2 important aspects to code quality: performance and readability (I classify correctness under performance).
Both need a great deal of context to judge, and any judge will ultimately see what they want to see if they want to see it. It is impossible for a developer to judge without preconception. One developer working on highly parallel systems will, if they are predisposed to, gasp at your lack of use of parallelism. Another developer who lives and breathes C++ 11 will gasp that everything lacks move constructors and how your code could be refactored with lambdas.
I remember working in an audio group where I found a long algorithm to do a bit of sound processing. I gawked at how unwieldy it was, and proceeded to hotshot a new implementation that was 1/2 the number of lines. And then I was promptly reprimanded: the original code, ugly as it was, was that way because it was way more L2 cache friendly. I ended up setting the project back with my "less sucky" code. Doing a source diff history, I found a much shorter version as one of the initial versions.
The only rule when working in this industry is: Always be prepared to defend your decisions. If you can't, then either you deserve to be fired, or you're working in the wrong place.
just show him this http://xkcd.com/844/
As any experienced programmer can tell, the way to write good code efficiently is to just hack something dirty together until it works, iron out its kinks, then scrap it and rewrite from scratch, based on everything you realized when hacking together the prototype.
Now the problem is that the "until it works" or at latest the "iron out its kinks" phase attracts management's attention, and the product is shipped and you are put on the next project. One tends to adapt by putting more effort in than the first run actually would warrant. But one can't really beat the thoroughness of the two-pass approach.
The result is that, indeed, your production code is likely bad style and could be improved by a do-over. It is just that you are not allowed the luxury of a do-over, and you are not enthused that a beginner, as a test project, should be allowed to make you look bad.
"what we are doing and how we have pulled it off" is not necessarily very relevant. there may be better ways to do things than the way you've been doing them. in fact, the alternative (that there aren't) is nearly impossible. don't assume that he/she can only learn from you just because they're new to the team. it's almost certain that there are also things you can learn from them. perhaps its wrong to thing in terms of "good" or "bad" code, and more proper to think of it in terms of differentials: "better" or "worse". so then what constitutes better? the most important thing in all writing, code included, is organization. if things can be reorganized to reduce duplication, to make things easier to find, to make it easier to maintain, etc. well then, that's better. as programmers, like doctors put the patient first, we should put the technical operation first. screw egos. it's broken, fix it. it's better to do it some other way, do it that other way. etc. if, on a separate issue, the person just is being disrespectful, well that has nothing to do with code. sometimes its hard to tell the difference, though. in any case my main point is, don't put him off just because he's a new guy, or just because you've been doing something one way for a long time, or just because you're egos bruised. what matters is that the code works well and is flexible and well organized and is easy to maintain. and if you want him to be a valuable asset, you should be encouraging him, not discouraging him. abraham maslow's on management. he sounds self-motivated and driven to constantly improve. that's great! you should encourage that! mastery, self-direction and purpose are the primary motivators and it is a godsend to find talent coupled with motivation like that!
Ask why. Motivate your counter points, and expect him to the same. (!) Argue about facts not taste.
Often the WHY aligns, but each has their own HOW, yet result in the same functionally. To each their own, often with good reason.
Hivemind harvest in progress..
I once walked into a job doing electronics design, not something I had done before in any formal capacity. I was handed a some datasheets and a copy of the nigh-on set in stone master schematic for the current project and told to familiarize myself with it, 2 minutes later I had found a mistake.
Sometimes a fresh pair of eyes and a lack of preconceptions can see things the old hands haven gotten so used to seeing they never bothered questioning why they were there.
I have an app on my cell phone that plays the "wha wha wha wha" sound that the teacher made from the Charlie Brown / Peanuts cartoons that I like to use when people are spouting all kinds of horsecrap I don't feel like hearing: http://www.youtube.com/watch?v=ss2hULhXf04
The trick is to write better code from the original requirements, smeared over years of requirement changes, and not from the existing source code.
Source code is an excellent requirements doc for the next reimplementation. But actually reimplementing it is just stupid. Especially if it works.
The guy is inexperienced and being an ass.
This is the kind of intern who never becomes "employee." He obviously didn't learn any workplace skills in school. You could try to teach him those, or you could wait until you or someone like you is asked, "Should we keep Intern Bob around?" He will then disappear, and harmony will be restored.
Some mornings it's hardly worth chewing through the restraints to get out of bed.
The code did great things, but the writing sucked. Impossible to maintain.
before he catches the ear of non-technical management and ends up as your boss.
I have noticed that whenever I see people approached with comments about the quality of their code (by myself or others) they often say things like "You just don't understand what this code is supposed to be doing."
That is always a red-flag to me. If your code is good the person should be able to tell what the code is doing.
What are this person's specific objections to your code?
There are no absolutes or hard rules and much is subjective and language dependent but as general rules of thumb:
Does your organization have a style guide? Does your code follow it?
Does your code have comments? I like to see at least one comment per functional block of code (function, loop, branch, new level of indent, whatever, depending on language).
Are the lengths of your function limited to no more than a page of text, preferably half a page?
Do your line lengths not exceed 80 columns?
Do you make some effort at making the code visually nice to look at? Is it formatted so like elements line up for easy comparison of lines? I'm a big fan of lining up = and parens etc. to make the code look orderly. It makes it easy to spot differences or errors. It sounds shallow but I also find that when someone has done this it means they care.
Without seeing a sample of your code to tell you if it IS bad there's no way we can advise you. If all you want is a polite way to tell the little twerp to shut up and mind his own business that won't get you fired I'm afraid I don't have much to offer.
Your new team member is most likely right. The code sucks. Especially after 10 years. In addition to the code, the documentation sucks too, as it is incomplete and outdated (which can be deduced from his inability to figure out what the job of a code fragment is). This is your fault, but I have seen no project so far, which is well documented and well written. Therefore, it is also a common situation of a 10 year old project and you are not a lousy programmer ;-)
The best what you could do to teach him what the code does. Let him do some code analysis and bring the documentation up to standards. Most likely he will find abandoned code fragments and methods, API violations etc. which can then be fixed. In the end he knows how the software works and the software will be better coded.
If you have something which can only be understood by a few then it's those few that that "get it." However, the problem for organizations is that they generally have code-bases that no single or few people can maintain so now you're faced with a dilemma...do I put in genius code (which will require very little change), or do I put in mere mortal code (which might change often)? If you setup coding standards, naming standards, and performance thresholds then you typically end-up with more similar code than not since those can be measured/critiqued more easily. If you're faced with choosing between genius code or mortal code I think that mortal code is better, but if you can go between both when required...that is where real genius is.
Wouldn't it be great if this post and the one from last week were from the the opposite parties in the same debate? Knowing this crowd I am sure that they aren't and both posters are correct in their complaints, but how fun would it be if they were posting about each other and didn't know it?
Careers and made and lost by learning to control your mouth.
He's on the leading edge of making or breaking his career.. it can be like watching an accident in slow motion.
It's horrible.. you want to turn away.. but there's this guy yelling in your face.. having a complete meltdown.
Don't take it personal.. one day the legacy code will be his.. but by then he'll be in marketing.
Ha - I was thinking of that exact story. Thanks for digging it up.
We get an Ask Slashdot a few days ago about "How do I tell my co-worker his code sucks" Only to have it followed up with this?
Son, I am disappoint.
You have been at the same company for 10+ years... unless your company is a consulting company, staying longer than 5 years means you aren't likely worth a damn. If you were, you would have found 2-3 jobs between then because you would have gotten 15-25% raises from each move. You are safe where you and don't have to be frightened by interviewing and having a hiring manager tell you the same thing that this kid told you.
Either that, or is a whiny punk...
Or, he is right about your code and is still a whiny punk... that is likely it. Programmers are anti-social and can't put out consistency in their code... it is bound to be the case.
Get the team to praise a section of the code he's harping about. It should force him to revisit his conclusions.
I am John Hurt.
I would highly recommend reading Clean Code by Robert C. Martin http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882. It has a lot of very good ideas on creating clean code that should allow even a junior programmer to understand it without needing to be trained on how it works. This suggestion also assumes that the kids statement may have some truth to it, I doubt he knows everything about well written code, but most code can be cleaned up.
I would focus the conversation on what actions he would like to take to update the code to be "better". Take his suggestions and see if they are valid and show him the amount of effort this project to change the code to his standards would take. I would also validate that there is a coding standard for the project and make sure he understand that first, assuming the code meets that standard.
A co-worked says your code is bad? Believe her. All code is bad.
The skill level of an engineer can be measured as the time between when the code is written and when the engineer realizes that the code is bad.
The best of the best engineers know they are writing bad as code as they are writing it.
They understand that the code has inherent problems and those problems cannot be removed, only traded for other (possibly worse) problems.
What programs are you using today that haven't changed at all since the day they were written?
Why is the CS faculty full of these socially inept people who feel the need to obnoxiously prove how good they are to everyone? What is it about CS that attracts people who lack the ability to perceive social context?
I'm an elec. engineering student and I've taken some CS, business and science courses. Without the doubt the CS people are always snarky, pedantic, condescending and down right rude more than any other discipline by a long shot. They're incredibly annoying to work/study with.
Not to mention they're, well, downright runty. I originally thought its just the insular and challenging nature of CS but that's not true, engineering and the hard sciences are just and rigorous and insular as CS (if not more) and for the most part, they're fill of normal people.
Here is what you can do about it. Go find a cliff or a bridge some where then take your entire fucktarded family. Have all of them jump off to their deaths and after that, jump to yours. Then you won't have to deal with the complaints and we won't have to deal with the bitching from someone like you that is too fucking stupid to even exist let alone use a computer.
He should not have the time/need to look at your code...
He should be busy writing his own code, he might bitch about your API definition, and you have then two choices:
a) tell him to suck it and that "if it aint broken don't fix it", you need the API as they are
or
b) Listen and maybe it will really make future extensions easier, so negotiate...
50K code is actually quite small so although refactoring can always "help" (in theory) but unless you are explicitly trying to win the obfuscated C award it's probably small enough to make it more valuable to add news feature than to "streamline it"...
Unless you hit some roadblock and it is now "too slow", "break randomly", etc.... then you should probably urgently look at it and fix it yourself (after all 10 years o experience with the code base should make this faster for you).
But either he refuse to deliver what you ask, then fire him, or you leave him to much time after delivering his module, and he looks at your code out of boredoom... ... write some specs and you'll get it ...
So the best you can do is tell him : sure our code is crufty, we just hired you so that we can ease the tension and have some time to refactor, so "write you own f**g code, and let us play around with our stuff, or do you need some API that's missing ?
Coding it "properly" may involve redoing significant parts of the codebase due to invalid assumptions made years ago. A hack now may allow it to work for another year or two, thus punting the problem down the road a ways.
Fasten your teeth in his trachea, and pull your head back backward sharply until the trachea comes free from the body.
Have him pick a small section for rewrite. Have him rewrite it. Code review. If he manages to make improvements without adding bugs let him do it a few more times. If he continues to be solid release the chain. If he fails use the reviews to teach him what he is missing, and in the process you'll gain a developer you are more confident about making changes to the code base.
"Tricks" are rarely an improvement and, to get away from that word, the sort of algorithms you see used and useful in real world applications don't change that much for a given language spec inside of 10 years. Odds are quite good the kid is misconstruing not rewriting to use certain trendy language features as the old code being bad, when often they're mathematically equivalent without any significant difference in maintainability.
Then tell him if hes so smart to do it himself while you go clean the blood off your hands.
I believe your intern may be following advice he received from here:
http://ask.slashdot.org/story/13/01/03/1859210/ask-slashdot-how-can-i-explain-to-a-coworker-that-he-writes-bad-code
50K lines of code over 10+ years for (presumably) multiple developers??? Either the team does not have full-time developers or they are really, really slow. 50K is not a lot of code at all.
. If you have 5 lines of code, and it isn't clear how to enter it and begin to understand it, then the code sucks. It might be good in other ways, but in at least one crucial way it's bad.
"First they came for the slanderers and i said nothing."
There is a story around our Office of a new graduate who thought he was high and mighty because he had been very successfully at university and took that perceived greatness into the workforce. I heard one day his leader took him around to meet the many other people who worked in the office who had PHDs and Masters etc. He immediate got the feeling that he was not special but in fact quite normal.
Yes, already at +5 insightful, but this is the number one thing coders need to understand. You are getting paid to produce stuff people other than you want. Satisfying yourself is #6 on the list.
Regardless of where anyone learned to program, I'd ask the kid one question - "You say can't read it, so why should we trust you to rewrite it?" - Then offer him some help to understand it, or sack the arrogant little shit if he's pissing people off with his unwillingness to learn "what is".
I've been in the game for a long while, I have never seen anyone walk in and comprehend the inner workings of a non-trivial source tree in under 3 months, but I've seen plenty of inexperienced people that think they can. The real problem is that code is much easier to write than it is to read. When a coder rewrites something only one thing is certain, it will be an education for the coder. However that coder is now the SME for that application and other coders will have to try and read his code. An old friend of mine, an excellent coder and all round pragmatist, described this phenomena perfectly with the expression; "Source code is like shit, you can't smell your own".
Disclaimer: Self-taught coder, BSc CS/OR, 22yrs commercial experience, 28yrs coding experience.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
As with everything in life, it's hard to admit, and often even harder to see, your own failings. I have no idea what your code looks like, it would have been nice if you'd elaborated on exactly what this intern thinks is bad (architecture, syntax/coding standards, algorithm choices). Maybe there's nothing wrong with it. Plenty of developers are too locked into their own way of doing things and can't get on in a team when the team's way is different to their own.
If this person can specifically come to you and say "X,Y and Z are bad, do A,B and C to make it better" he may have a case, otherwise he's just blowing steam. The worst thing you could do is completely write him off just because he's young. Ask him to come up with an action plan that identifies 2 or 3 key improvements that could be made.
I attended an excellent lecture by a software consultant that was hired by a large financial institution to work on their trading platform. The platform was used internationally across their offices, was in excess of 500,000 lines of code and any attempt to add features was running months longer than it should have done. After 6 months working with his team on refactoring and rewriting large parts of the code the revised platform, with exactly the same functionality, was ~200,000 lines of code and features were on a one month release schedule. Some of the original developers quit as all the code they had written, and based their career on, was deleted.
I'm not saying one or the other of you is right, but neither should either of your opinions be entirely discounted. You have 50,000 lines of code and a team that understands it, you can't change it all overnight, but maybe you can make it better over the course of a few months, there's always room for improvement.
My top 3 practical criteria to judge whether code is "good" or not.
1) Performance. How fast does the application actually run.
2) Complexity. How many layers and levels and do you have to trace down into to debug something.
3) Flexibility. Can it be modified easily as new change requests come in.
AAA did a survey in the US about 20 years ago where they discovered that roughly 80% of people believed that they were above average drivers.
"The plural of anecdote is not data."
Not at all. There are plenty of cases where doing things differently work but can have a massive difference in terms of performance, scalability etc.
Did you try blowing your nose on him, and then throwing him in the garbage can? Because that's really about all interns are good for. You could also ask him why he was looking at code and not getting you coffee. Really. The largest project he's probably ever done is probably smaller than the largest function in your code base.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Some times it just takes a different set of eyes. You get buried in the code and things that are not quite right do not jump out at you because you understand it and know it so intimately that you develop blind spots. A fresh set of eyes no matter experience will see things that you simply accept because it does not trigger your "that does not look right" alarms.
Consider the possibility that the fresh set of eyes on the code might have some valid points. With 10 years, you ought to be able to fully know/understand at least 10K LoC (Lines of Code). The threshold (I've seen) is that about the maximum amount of code that a single individual can comprehend and maintain is around 250K of stable code. Specifically meaning understanding the architectural interactions & consequences of changes. Different developers have different maximum saturation levels. Not a "bad thing", just different. Unless the developer is obstinate (and thus a complete moron)
Interns are NOT coworkers. They are peons. Scrubs. People who work for free (or nearly) for credit or experience. If they knew anything about the job, they wouldn't need to be interns.
It's like a student trying to tell the teacher how to teach. You biff the back of the person head and give them some really demeaning job to do. twice.
Be seeing you...
Personally (if you can stand them) I'd recommend attempting to coach them in how to provide constructive criticism that doesn't piss people off. I'd go for this rather than ignoring them (or worse), as (in my experience) if they care enough to have an opinion then they generally turn out to be good coders and maybe eventually good engineers.
If they were my report I would discuss this in their 1 to 1's and if it was a recurrent theme I'd have a word with the HR department and see what courses they could be signed up for; most HR departments in engineering shops have plenty of experience in smoothing out the social rough edges of engineers, shame not to use it. If they were not my report, then I would talk privately to them and if it kept happening provide feedback to their line manager and maybe drop hints about the courses.
Ultimately most engineering involves working with others, even software development; to be successful it generally helps to be able to get along with folks and most people can learn how to do this better if they choose.
show us some and let us judge it for you.
that will satisfy you and him as to whether your code is good or bad
if you use vi - you are a good coder
if you use emacs - you are a bad coder
let the flame wars begin. hehehe
Wow could you not even be bothered to even read the first sentence of the summary?
A week ago, you read the other side of the same question.
Guess what? Yes, that was the question you linked.
I'm glad someone else was paying attention! I'd mod you up if I had points.. It sounds like he told that guy what he thought of his code, albeit not to gracefully.
No sig for you! Come back one year!
And they may have been right - the really bad drivers bring the average down a lot more than the really good drivers bring it up.
Now if you were talking above *median*, then sure, at least 30% of them were wrong
--- Most topics have many sides worth arguing, allow me to take one opposite you.
OK, granted the guy is green and full of himself... But perhaps a fresh perspective is not all that bad. We KNOW that a lot of the stuff we have worked on and inherited is absolute crap that is very difficult for average human beings to grasp. Here's a human being trying to come to grips with a wicked mass of old (and, granted, battle-tested) ideas.
You are also right that all of us tend to want to greet a problem by trying to bend it into our will so that no matter if the pin is trapezoidal, it will fit (darn it) into our circular world view. And this goes for the new guy as well... We are aware of it, but this new guy may not be aware of it. Explain to him htat he needs to learn to do this as well. Instead of strict adherance to a dogma, a set of programming patterns grows up around a problem space -- not the other way around. Try to help him see the problem and make sense of it first before he triest to tackle the crap with the "new hotness."
So... give they guy a challange. ell him the abovve, and also help him to understand that the code-base is NOT going to take on a revolutionary overhaul overnight. Tell him he can add his new ideas gradually if the new ideas do any of three things:
1) Reduce the LOC's in the program.
2) Measureably improve performance.
3) Measureably improve the code quality (via new introspection/tracing tools, unit testing or algorithmnic proof of correctness).
perhaps your code is bad? Has another senior developer with a varied background looked at it?
Bad is such a subjective word. Bad as opposed to what? Bad how?
To me Bad code is:
Uncommented, obfuscated, sphagetti, poor structure, follows no name or calling conventions, uses unnecessary tricks to accomplish it's goals, uses soon-to-be deprecated functions, code that just plain doesn't work and above all non-portable.
Codifex Maximus ~ In search of... a shorter sig.
If out of the 20 things he complains about, one is a good idea, you should look at it as a net positive.
Id make him pick one or two he is surest about, tell him to make a chart or document explaining whats wrong and how to fix it and make him explain it to you and his peers. Then critique him, accept or reject, and move on.
I was crazy back when being crazy really meant something. (Charles Manson)
There certainly are a lot of respondents here attempting to defend bad code. As a 20-year veteran, I have found that most code sucks and most programmers suck. And it costs companies billions of dollars in unnecessary repairs, re-work, down time, confusion, and lost clients. Do yourselves a favor, folks: Stop making excuses and start doing things right the first time. The old maxim, "Garbage in, garbage out", doesn't just apply to the end users of a program. It applies to the process that creates the program.
Have him write an error reporting code segment or plugin. He has to figure out real learning comes from fixing mistakes not doing things right from the start because right is relative and you never know when a mistake may occur therefor are walking blind. What he is demonstrating is called confirmation bias. He needs to see everything from the macro level not the micro.
Know that this person will be talking behind your back so consider that he never spoke to you and is completely and entirely making up every conversation. Oh and stay away when he has his morning coffee.
If I'm tasked to work on code, and the code is spaghetti, I rework/refactor the code until it is understandable and can be worked on without worrying about unseen dependencies. I never complain or critique, I just explain that a day or two of refactoring will make the code manageable, and to whit: the code as it exists is not manageable. For some reason, nobody takes ownership of code that is known to be bad, mums the word.
Nearly all code is "bad" to one degree or another. There are some very good reasons for this. 1. As Steve Jobs said, "real artists ship". If you're in a research lab it may be a different matter, but in the real world, your code is never perfect, yet sooner or later you need to let real people use it, and either make money or discover that you're trying to solve a problem that doesn't exist. If the former happens, you should try and go back and improve your code. If the latter happens, be glad that you didn't try to design the perfect solution to your non-existent problem and go try to solve real problems. 2. The human race moves forward. Hardware gets faster, cheaper, smaller and uses less energy. Operating systems, browsers, and languages become easier to develop for with new features, and become more efficient with hardware acceleration, various optimizations, etc. You may have written amazing code 10 years ago, but it is "bad" code today because there are now better ways to do things that didn't exist at the time. Over time you should update your code to try to take advantages of this, though you may be limited due to a need to support legacy platforms. 3. You weren't the same person 10 years ago as you are now. We are continuously learning new things, fixing previous mistakes, and making new ones. If you look back at your old code, you should think that it's "bad" at least in some ways. If you don't, it means you didn't learn anything since you wrote it, which is a shame. 4. You don't know everything, and you don't have to. That's why you hire smart people, so you can focus on your strengths while outsourcing the rest, and so that you can learn how others approach problems differently than you. Instead of trying to defend your territory as others have mentioned, I'd ask for ways in which the code is "bad" and can be improved, and then include him in the process of triaging those tasks against the rest of the team's workload.
.... the possibility that your code is in fact terrible? might be worthwhile to examine his assertions.
while the code might work today, it could easily turn into an obscenely unmaintainable pile of spaghetti.
i have witnessed moderately successful start ups get their foot in the door and show promise, only to be immediately
killed off by their own success when they are unable to expand their software base due to pervasive sloppiness
in code that "worked fine but was not pretty".
It's a very personal journey to move from criticizing other people's code to taking the code for what it is. I've been in the industry for nearly 3 years now, and I pride my earlier self on having quickly gotten out of the rut that is "xeno-codo-phobia". Here are my own self-observations.
Stage 0: I don't want to look at other people's code. I'd rather roll my own stuff given the opportunity. If I have to work in larger code bases where reading code is a necessity, I want to just get in and get out without so much as even looking at the decorations or saying hi.
Stage 1: Okay, you've convinced me, Mega Corp X. I've seen some cool things in some code reviews that have been passed around and/or assigned to me. I might be open to taking at look at.. OH MY ***, IT'S ALL TERRIBLE. I NEED TO REWRITE THIS POS! A little, no some, no all of it! Hmm, my lead won't let me rewrite it? Okay, I'll just spend extra long on new features, stage 0 style, or I'll work on other people's code and complain the whole time to them about how they do X, Y, and Z wrong.
Stage 2: Hrmm, my coworkers had wills of steel and could repel my complaints. I didn't change their minds very much. After finding out about the code's history, I almost 100% agree with the decisions that led to the code being the way it is given the constraints upon writing time. The only person I upset by complaining/harboring a negative mental state about the code was myself. Maybe I should just be more constructive with my complaints or not complain at all.
Stage 3: When I see code I don't like, I spend time to first educate myself about it. I add docs/comments when there are none and otherwise make tiny checkins to beautify the code where I can. Sometimes I find bugs this way. Sometimes I simply add clarification (for myself and the next reader). Sometimes it spawns discussions with the original devs about how and why we did things a certain way, and there's almost always a reason. Sometimes it teaches me to avoid that code like the plague as the original dev left and now it's a maintenance nightmare that all devs use to play hot potato. 100% of the time I learn something new. 100% of the time, judging before I do my due diligence results in either a waste of my time or a waste of someone else's time.
Stage 3 is basically where I not only know logically but also believe that:
* I am smart and my coworkers are smart. Given the same inputs, we tend to code the same way.
* My senior coworkers typically have a deeper understanding of the problem space. (they have more input than me)
* My senior coworkers typically better understand the priorities imposed by the business/culture of the company. (they have more input than me)
* Given the discrepancy between my understanding (my input) and their understanding (their superset of input), they are probably making better decisions for the company.
Sure the code might be locally worse because one of the above assumptions may occasionally break. Sure the code might not adhere to some theoretical golden ideal. BUT. I have tremendous faith now that the code is for all intents and purposes in one of the best possible (where best is relative to the company) states it can be in. The deleterious effects of time may have already taken their toll, but at the time the devs made those decisions, they were most likely optimal for the larger organization.
So yeah. I basically had to learn and accept that I was just full of myself and that an open mind trumps a closed one.
My advice? If you like the intern and want them to come back, be patient. Put them in situations where they learn the above, and don't take personal offense as they go through this phase of their professional life. If you don't like them and don't want them to come back, call them out on their pigheadedness so they associate their failure (not getting a return offer) with their close minded values. You probably don't want someone like that on your team (at least in the immediate future), and it will be better for them (and the community) in the long run.
Best of luck!
Back to the time when I gave a shit. Now I just want to get paid and go on holidays.
I bet the guy is dead right that your code is crap.
Sounds like me 20 years ago. My first manager cured me by responding to every bad code issue I raised with this response:
"Great! Thanks for discovering this. When do you think you can fix it?"
After a couple of times I learned my lesson..
Simple. If you are in the position to do so, you fire him. Otherwise, ignore him.
He's an intern. It's not your job to school him.
Most programmers do write fairly shit code, and I can usually enumerate to them exactly why it is shit and what they should do about it. Whether they agree or not is a different matter, and many things are subjective, but many things are not. It is generally because most programmers don't know a lot of fundamentals properly, and most programmers are lazy in the way they write code, but most importantly because most have never put their code up for critiquing by an audience. If someone can point out specific problems with my code and specific techniques for improving it I am very happy, and I love having my code reviewed. But if they just say it is shit and can't tell me why it is shit then it's water off a duck back and their opinion doesn't matter, and because I like to have my code reviewed I'm not thin skinned about criticism. That's what makes it a valuable learning exercise and not a torture.
Step 1 - punch them in the throat
Step 2 - go fix your shitty code
It's probably shit code.
Software maintenance is a fundamental and always-forgotten part of the SDLC.
I'm guessing your 50,000 lines of code have not been maintained, and your intern is calling you on it. As a dev, this is his job.
To all you self-taught coders who hate college-educated kids, I hope you have all your future medical needs taken care of by self-taught doctors. Leave the college-educated docs for the rest of us.
Furthermore, if it bothers you how bad those darn college-educated kids are at coding, why not become a professor and teach them?
If you want to be pedantic, please use correct terminology. First, the median is an average, the arithmetic mean another, the mode another, the geometric mean yet another. You probably equate average with arithmetic mean, but that's not strictly true. Second, the central limit theorem proves that for any random variable that has finite (stable) variance the mean and the median are equal. Not sure if 'driver ability' has finite variance, but if it is anything like IQ, length or weight, then yes, the (arithmetic) mean divides the top 50% from the bottom 50%.
"The boss is interested in the long term effects of having code that doesn't suck, such as lower maintenance time."
In most places where code development happens there is no maintenance time/cost. Lots and lots of code goes into products and when the development of those products is "good enough" management orders production and shipment .... and they build and ship, and build and ship, etc until they discontinue the product either because there is insufficient demand or some component or subassembly is not longer available. Most products with microprocessors in them never get any upgrades or maintenance. Some products that DO get some maintenance are in strictly regulated areas like aerospace or medical in which case only the parts of the code that absolutely MUST be touched are in fact touched .... and any general "maintenance" is out of the question.
The fantasy of a nearly perfect code base with constant maintenance is fine on the college campus or perhaps at a place like Amazon ..... but it's just NOT a general rule that applies in much of the part of the world where microprocessors are used
are the kind of jerk all your co-workers and their wives and kids can end-up hating
In the real world, there are often investors who must (by contract) see a return on their investment by a certain date. In this world, an attitude like yours can lead to a division or an entire company getting shut down for failure to deliver the product in time and that means lots of innocent people who had no control over the situation (like technicians, shipping and receiving people, marketing people, sales people, janitors, IT staff, etc) can end-up unemployed all because some arrogant jerk decided there could be no ugly code in a product where there was not going to be any actual benefit to perfectly clean code. It's impure, and unfortunate, and we may not all like it, but in the real world there really is such a thing as "good enough". Given the choice between "good enough" (and a bunch of happy families who have health insurance, food, rent/house-payment money, etc) or an analysis that says "good code" cannot be ready in time (and a bunch of people with kids on the unemployment line) ..... well just count me as a humanitarian; I'll go "good enough" on the code.
disclaimer: names and specifics removed to protect the innocent from the lawyers
New guy: "this code sucks"
old guy: "how would you have done it?"
New guy: "Like this: {details removed for brevity}"
old guy: "yup, that looks better ... don't do that"
New guy: "why not?"
old guy: "because you do not know the hardware, the regulations, and the environment.
New guy: "but its better and cleaner, so that stuff shouldn't matter"
old guy: "I know, you think that, but we did it your way a while ago, and now we do it this way
New guy: "This way sucks, why'd you change?"
old guy: "we killed a customer
New guy: "oh"
And you think it's his problem?
sounds like the code is missing comments
and some design documentations that explains the design and the reasons behind it
I'd say I know the guy you're talking about, but the industry is rife with this sort.
We give 'em a few months, and if they haven't checked their attitude by then, we fire them before their probation runs out. After a few boots like this, they'll either realise that they're not as good as they think, or they'll leave the industry, grumbling about elitist attitudes or something. Either way, we move on to the next hire and hope for a better one.
Trust me - I've been at enough companies to know. If someone is shaping up to be a problem, you're much better off getting rid of them while you can. The cost of replacement and re-training of a newbie is much lower than the cost of having a problem on staff, pissing off all of your more experienced (and productive) developers.
Well, then he needs to understand your code base a bit better, and gain some experience of coding with other people.
You could schedule an in-depth code review of the main components of the system with him. You get to explain the what and why of the existing code, and he gets to explain what he thinks could be better. This isn't something to do in an hour - schedule at least half a day for this, or even more if you think it will be worthwhile.
He may have some good ideas - but he probably doesn't have the experience to understand why some ugly bits of the code aren't worth changing, or why rewriting everything isn't usually the best policy.
You could also get him to walk you through some code he has written (maybe open source?) which exhibits what he sees as good coding.
The main thing in a coding review is to get people to explain what the defects and behaviours they see in the code are, without reference to style or that it's simply not how you would have written it. I've often found that the "why" of things is often missing in code. Sometimes the outcome of a code review is simply to add a few more comments explaining the why, rather than the what, so others benefit in future too.
Ask him to come up with proposals for improving the code base. With that it should be easy to see whether he is a moron or your code really does suck. Like most people have mentioned, nearly all code is bad, so, unless the guy is a moron you could probably learn a few tricks...
Crosh your enemy, drive him befoah you, and hear da lamentation af his woman.
Is this intern fresh out of school with no previous experience? Just fire him if he has that much audacity.
However if he happens to have a significant number of years of previous experience, perhaps you should hear him out. Who knows, maybe a small bit of that self perceived greatness might be justified, and you might learn something new.
Keep in mind, of course, that the fact that he doesn't understand some code yet does not, in fact, mean that that code is good. Code can be objectively terrible. Not to mention that good code is easy to understand, so this could be a big part of the problem.
The answer to both Questions is use objective Software Metrics.
I don't know how well that translates into American.
To have a right to do a thing is not at all the same as to be right in doing it
Give him one subsystem with clearly defined contracts and ask him as a backburner project if he fancies reimplementing it how he'd like.
Call it a training exercise if you want.
Worst thing that happens is he burns a few cycles learning the subsystem in depth.
Best thing is you get an improved subsystem.
In either case you are now in a position to critique his code. :D
That is, of course assuming the codebase is broken into defined subsystems with defined interface contracts and the company allows guys space to train/learn.
If not, then frankly his critique might have some merit.
What you do is have him IN DETAIL give you all the points where your code "sucks"
then take this report and figure out where
1 He is being a "buzzword jackass"
2 the code actually sucks AND CAN BE FIXED
3 the code sucks because %issue% that needs to be worked around
4 he has actually found a cleaner and stable way to do the code
then if he has more than say 60% in case 2 and 4 keep him around
if he doesn't then well "phone for you its a Mr Piffy he said that Mr BOFH is a bit busy but he has some time to chat with you"
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Sounds like a lot of the "senior" coders here who are all in favor of "putting the newbie straight" in some appalling way forget the following:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan
I've seen lots of legacy code that sucked hard. Mostly due to lack of coding standards and continuing education. Maybe your code does suck and you need to reexamine it!
If you don't have any, write some. If it's crap, improve it.
I have seen good and bad code. I must say that I am extremely disappointed in the lack of security related comments. Good code cannot exist without this feature. There are many other features that are both desirable and needed from code. If the new employee has brought up security issues related to the code, please spend sometime thinking about the suggestions. This extra time could save you company a lot of grief. You won't get paid for it but secure code could be the difference between your company existing and looking for a new career.
One of the things most of us forget is that we've probably never actually seen a 100% pass mark on a student's programming assignment beyond first year (or second year, at a push).
When I was at university, I wanted those As. I was OK with the Bs, but I was really annoyed when I got a C and distraught when I got Ds. In the end, I got a 2:2 for my degree -- a C.
What's my point? My code at university was not spectacularly good code, but it wasgood enough. I passed. I got a job. I moved away from code. And almost a decade later I'm back in the IDE hotseat for a personal project and realising that I understand a hell of a lot about how computers work, and it's all thanks to a degree and results that I previously lamented as "mediocre".
Most of us have a hard time doing it, but we need to accept that good enough is good enough. But at the same time, that's never a good excuse for not improving yourself when the opportunity arises.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Maybe accept that your code sucks. I mean just as bad the guy that goes around assuming everyone else's code sucks is that guy who assumes he is perfect.
I think the only reason why I can consider myself a senior developer is because I learned how to finally accept criticism and improve my coding based on it, and understand I don't know everything out there so every new idea or concept that is introduced to me should be evaluated. If someone shows me a better way to do things, I adapt and bring it into my skill set. Also a senior is not "possessive" of "their" code so should not be offended when someone criticizes it. The code is about the product you are trying to produce, and making the product better, not your personal ego.
If that is not the case then ask him exactly why it sucks. People are reactionary as you said, so if he doesn't understand something and so assumes it sucks, but then can't explain why it sucks, or better yet, explain how to make it better, then he is just an ass that likes to bitch. If he stands there and can't give a reason for why it sucks then he basically sucks as a developer and should probably be turfed.
I haven't thought of anything clever to put here, but then again most of you haven't either.
"Oh, wait, this is my code? Well, I know better now."
Ever looked back at code you wrote a few years ago, and gone "ick!" ?
I know I've had a few moments like this. I've learned new tricks, found new issues, and generally gone back to find that my old code just wasn't up-to-standard several years later.
If the junior guy can point out stuff that can be updated, and a good reason why, then let him demonstrate a solid case and take the advice.
However, "code" is one thing, and "coding style" is another. You can get into huge flamewars about just stuff like indentation (spaces VS tabs) etc. Over time, styles will change. In that case you need to balance necessity against time. Sometimes a style change can make an important difference. Other times it's just not worth the time. If the new guy is arguing that variable names $a, $b, and $c are less readable than say $sAccountName (string), $iAccountID (integer), etc... he would be right. Maybe you don't need the data-type (s/i) prefix, but at least having descriptive variables is an important improvement.
Offer him an aspirin, and suggest he go home and get lots of bed rest.
Newbie: "Your code sucks and you don't know how to code!"
You: "...and your mother smells of elderberries!"
But he's probably to young to get that, so don't use it. Seriously, just as with human relations in general there's no one answer without being there. While something like this is not uncommon, it's still annoying. I just hope your manager is experienced enough to see through him. If not, I hope you got backup from your older colleagues to make him understand what's going on.
Worst thing being naturally is that he is allowed to rip apart working old code. Instead he should be assigned to writing new functionality and be restricted to touch old code unless absolutely necessary. And that's the job of his supervisor, not his colleagues.
If all else fails, pull the plug and get out...
The Life is out there...
So, set up an hour or two, maybe even pull in one or two other experienced people, and do a code review on some of the stuff he's complaining about. Listen to him, then explain why it's that way, and what he's learning in school is not necessarily correct for the real world.
Oh, and I'd look at something he wrote, for things like parameter validation and error handling....
mark
My experience with whiz kids who knock my code is to tell me where I did wrong. To explain to me if there is a better way, in terms of efficiency and maintainability.
Sometimes I learn somethings, and often times the whiz kid learns something. I am open minded. I and he have no exclusivity on being geniuses.
Leslie Satenstein Montreal Quebec Canada
and tap dance on his lungs
The new right fascists are bilingual. They speak English and Bullshit.
First off, kids are cheaper and so eventually they will replace senior workers who are in higher pay slabs. Secondly how you "pulled it off" may not be the only way or relevant now. If he shows promise (as you say) ie. he seems genuine and not just criticizing, then you must try to go down to his level and tell it in his techie terms. OK
Fire him. He'll start telling all his other job prospects how stupid your code was, and then he'll magically discover that he either doesn't get hired because he's a whiny bitch or that only other assholes will hire him, and then poverty, misery, or both will mop up the rest of his attitude by serving as a gentle nudge to stfu and code.
Ask a bunch of random people what the average of five numbers is and you'll be almost guaranteed to get the arithmetic mean, even among statisticians. Therefore, outside of special contexts, arithmetic mean = the average. In fact even in contexts where other types of average are in use it's unlikely that the unadorned term "average" will be used to refer to any but the arithmetic mean, it may even be avoided entirely for the sake of clarity since it is technically non-specific. Meanwhile the difference between the average and the median is something worth drawing attention to precisely because most people only know one mathematical definition, while the colloquial usage ("average Joe") corresponds much more closely to median, and the difference between the two can be very informative about distribution. I'll admit my pedantry is a work in progress though.
As for the convergence of median and mean - that's heavily dependent on a symmetric probability distribution, which is actually not the case for a very wide variety (a majority?) of variables. My statistics terminology is rusty though, so perhaps that's covered in being finite and stable. Regardless of the reality of driver skill distribution, *perceived* skill distribution at least is highly asymmetric. Consider that under normal circumstances there are minimal distinguishing characteristics between a truly excellent driver and a merely competent one - in fact the excellent driver may even be perceived to be reckless if they engage in maneuvers that would be risky for someone less skilled. Meanwhile, idiot drivers have a tendency to make themselves extremely obvious, usually in ways that endanger or annoy those around them, increasing the perceptual weight of their incompetence. The resulting apparent distribution is thus has a relatively hard upper limited near "competent" (probably ~= median skill level), while the lower limit extends.... well quite a distance, and the average will thus be artificially lowered.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Sadly, they get older. Just like code. Tell your lil friend that you can't compare babies to grandmothers, at least on a beauty scale. Also, tell her that there are compensations to being a grandmother, like being able to deal with the world in a rational way...
Go to Heaven for the climate, Hell for the company -- Mark Twain
If he isn't understanding your code, maybe you need better comments in it. Have him write some!
Or maybe your code is complex because it's trying to implement a bunch of complex semi-contradictory requirements that evolved over time, rather than implementing one clear design specification that was available upfront. That also needs really good comments.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I have worked with too many entrenched old-timers lately who use seniority and "it works" as justification for creating huge, disorganized and tightly-coupled messes in the code, and then stonewalling, bullying and intimidating anyone who points out that the industry long moved on past the techniques they are using, and that there are simpler and more flexible ways to do things. So I'm on the kid's side.
The defensive tone of OP is kind of a hint. As are the inherent ad hominem attacks, e.g. "it is simply because he does not have the experience with it to actually understand" ... "his own self perceived greatness." This doesn't sound like an educate/learn situation, but a "I'm going to batter this kid because my feelings are hurt" situation. My guess is that this has been building, with rounds of increasing griping and intimidation leading to a confrontation.
If the code has merit, then there's no point in coming on slashdot and whining about some intern breaking The Rules by expressing what he thinks.
10 years at the company, and I"m faced with a smart new hire that maybe doesn't have my experience and judgment?
If I don't view my job as teaching the new hire what I can, helping to make him great -- somebody should be firing me.
I'd ask him what's wrong with the code. And what he'd do differently. If he's right ... I'd tell him to go do it, and come back and review it with me when he's done.
If he's wrong, it's an oppt'y for me to teach him something he needs to know.
If he's got an attitude issue ... I'll coach him on being effective engaging w/ others ... see if I can help learn this a little faster than I did.
I'll recognize that I used to be him.
And, if I do my job right ... he won't become a 10-year unapproachable, arrogant, know-it-all that keeps chasing away all of our new talent.
If the guy can convince me why it's wrong, then sure, I'll adopt a new way of doing things. That sting you feel? Pride fucking with you.
If the guy is wrong I'll try to explain why. Unfortunately there's thousands of things you learn over the years, what to do and what not to do, heuristics and patterns, and sometimes along the way you may forget the exact reason why you use a certain technique. If you can't come up with a reason why, suggest that if it isn't broken, don't fix it until it is.
Tell him that you think HIS code is shit, and that you don't trust his opinion, and that he needs to defend or back up his remarks.