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.
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?
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.
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.
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!
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!
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.
You'd be amazed what APL can do in a single line.
I wouldn't like to read 50,000 lines of it, though.
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.
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.
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.
stare him directly in the eyes and, in an outrageous French accent, curtly state "MIND YOUR OWN BUSINESS!"
Karma: NaN
There are no coders or technically literate people here.
Incorrect.
"You dare insult my code!? I'll kill you where you stand!"
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.
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.
Incorrect; the only way to solve the "problem" of ten years of legacy code -- bad or not -- would be to refactor all of it. New Guy is obviously full of idealism and wants to do exactly that, while the OP just wants New Guy to go back to his desk and get some real work done.
Obligatory personal anecdote: On my current project, my supervisor (who is also a developer) has specifically stated that refactoring is not our priority until the deadline is met. Of course, everyone knows perfectly well that the next deadline will almost certainly be just as much of a pressure cooker as the current one -- which means that refactoring very rarely gets done at all, unless the old code is so bad that it hinders further progress. (I just finished refactoring some of our code for that very reason.)
Moral: If it ain't broke, don't fix it. If it is broke, don't hesitate to acknowledge it, and do something about it.
...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.
Oh... and the ultimate irony in all of this is that my current project is, by definition, an entire refactoring of a legacy project, which is no longer maintainable going forward. Life as a developer...
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.
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
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.
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.
(everyone who's working on it has a PhD, while I'm an undergrad
There's your problem. PhD's don't necessarily know how to write good code. They spent all their time learning and not applying.
They can certainly take very advanced concepts and make a program that does it. It just won't be very pretty or maintainable.
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"?
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.
This is the reason most software is terrible.
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.
...everyone who's working on it has a PhD, while I'm an undergrad...
Oh. Dude. You're so screwed. No matter how over-inflated their egos, you'll always be "the one with the ego problem"!
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/
"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..
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.
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.
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.
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.
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.
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.
. 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."
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.
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...
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).
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)
You can do ANYTHING in three lines of APL.
Unfortunately, each of those lines is known to only one of the three remaining APL programmers.
And they don't play nicely together.
Not everything that can be measured matters; Not everything that matters can be measured.
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!
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%.
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"
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.
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
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
If you don't have any, write some. If it's crap, improve it.
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.
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