×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How To React To Coworker Who Says My Code Is Bad?

timothy posted about a year ago | from the very-strong-lye-solution-coffee dept.

Programming 507

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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

507 comments

Tell him to write goddamn login page himself? (5, Funny)

crazyjj (2598719) | about a year ago | (#42548925)

After all, he's fresh from a CS program where they taught him everything.

Re:Tell him to write goddamn login page himself? (5, Funny)

Anonymous Coward | about a year ago | (#42549089)

Code Monkey get up get coffee / Code Monkey go to job / Code monkey have boring meeting, with boring manager Rob / Rob say Code Monkey very diligent / But his output stink / His code not functional or elegant / What do Code Monkey think? / Code Monkey think maybe manager ought to write god damn login page himself....

Re:Tell him to write goddamn login page himself? (5, Funny)

Anonymous Coward | about a year ago | (#42549239)

Code Monkey not say it out loud. Code Monkey not crazy, just proud

Re:Tell him to write goddamn login page himself? (5, Funny)

Anonymous Coward | about a year ago | (#42549427)

Code Monkey regret his lousy placement / Code Monkey recall his mama's basement / Code Monkey's chest still swell with pride / Recalling Natalie Portman statue, naked, petrified.

Re:Tell him to write goddamn login page himself? (5, Informative)

cod3r_ (2031620) | about a year ago | (#42549127)

Exactly. Don't hold the guy's hand. Tell him to waste all his time rewriting everything and see what the company does with him.. In the end the boss man doesn't give a shit about how clean the code is.. he give a shit about how fast the code was written and if it does everything it's supposed to and more. New guys gota learn the game too or they will have a hard life in the world of software development.

Re:Tell him to write goddamn login page himself? (2, Insightful)

Jiro (131519) | about a year ago | (#42549189)

The boss is interested in the long term effects of having code that doesn't suck, such as lower maintenance time. If the boss wouldn't care when directly told this, that just shows he has bad management skills.

In other words, you're basically saying "take advantage of the boss's bad management skills to get the employee fired for doing something that would actually benefit the company".

Re:Tell him to write goddamn login page himself? (5, Insightful)

Anrego (830717) | about a year ago | (#42549281)

As programmers its an easy trap to fall into thinking that better code always translates into those dollars and cents management seems so hung up on. Sometimes it does, sometimes it doesn't. Yes, some bad managers are too short term focused, but being able to do the math and figure out if the cost of cleaning up some code is going to be justified in the long run is part of a managers role.

Telling management you want to re-write everything is a programmers perogative. Accepting it when the manager comes back and says "what we have now works, our customers arn't complaining, the thing is end of life in 2 years, and even if this made future maintenance free it wouldn't be worth it" is a reality.

Re:Tell him to write goddamn login page himself? (0)

Anonymous Coward | about a year ago | (#42549417)

I agree, just tell him to rewrite everything. These little bastards can be found everywhere, and usually they talk more than they code.

Re:Tell him to write goddamn login page himself? (0)

Anonymous Coward | about a year ago | (#42549517)

Turns out his CS program just taught him the theory, but not the actual languages. So he's excellent at pointing out how code doesn't meet Dr. Dipshit's Principles of Quality Code or properly adhere to the latest agile development techniques. But he can't actually WRITE code, you see, or stoop to anything as low as actually doing anything other than run his fucking mouth criticizing everyone else's work.

Easy... (-1)

Anonymous Coward | about a year ago | (#42548941)

That's easy: tell him to fuck off.

Old problem (5, Insightful)

Anonymous Coward | about a year ago | (#42548949)

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

Mod this up! (5, Insightful)

ganjadude (952775) | about a year ago | (#42549003)

Might as well close the forum down, this is gonna be the best answer concerning this issue. if only I had mod points

Re:Mod this up! (2, Funny)

Anonymous Coward | about a year ago | (#42549115)

Mod points are rare these days.

Re:Old problem (5, Insightful)

N0Man74 (1620447) | about a year ago | (#42549425)

Good answer.

Your keyword "deadline" didn't really get the emphasis it deserved. I know that I've been guilty of writing some pretty shitty code (and fully realizing it) because I simply did not have the luxury of the time to "do it right".

Sometimes this is because I made a bad assumption early on. Sometimes there was a surprise change in the specs that didn't mesh well with the design. At times, it is because I'm working in unfamiliar territory and still learning about some aspect of the project. Sometimes it is because I am working with existing bad code someone else wrote (possibly because of one or more of the same previously given reasons), and I have to do my best to work within an existing bad implementation.

In the real world, sometimes you have to make the choice of doing things right, or actually getting them done.

Re:Old problem (1)

znrt (2424692) | about a year ago | (#42549509)

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.

are you implying that those criteria are objective?

sorry for being picky but that's the effect of lately having to comply with lots of this kind of best practices and style guides written by folks who read much and code little. i sure can comply, but don't call that bullshit "objective" in front of me! that's unnecessary cruelty!

(sheesh, now I'll have that nightmare again of decapitating joshua bloch with a swiss army knife)

Re:Old problem (4, Insightful)

LordNimon (85072) | about a year ago | (#42549529)

New guys want to re-write everything and don't understand the value of code maturity

I've been working in this industry for 20 years, and I've never experienced this. Instead, the "new guy" is intimidated by me because I'm constantly explaining things to him, and he quickly realizes that he doesn't know anything.

Possibly related? (-1)

Anonymous Coward | about a year ago | (#42548951)

http://ask.slashdot.org/story/13/01/03/1859210/ask-slashdot-how-can-i-explain-to-a-coworker-that-he-writes-bad-code

Re:Possibly related? (0)

Anonymous Coward | about a year ago | (#42548973)

Did you even RTFS? They linked to it.

Re:Possibly related? (5, Funny)

magarity (164372) | about a year ago | (#42549409)

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.

Re:Possibly related? (1)

Desler (1608317) | about a year ago | (#42549523)

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,

Very simply (5, Insightful)

houbou (1097327) | about a year ago | (#42548957)

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.

Re:Very simply (4, Insightful)

Anonymous Coward | about a year ago | (#42549041)

It boils down to two questions:

1) Does it work?
2) Will I ever touch it again?

If yes to the first question and no to the second, quality doesn't matter.

Re:Very simply (4, Insightful)

Ravaldy (2621787) | about a year ago | (#42549333)

You can never answer #2 with 100% confidence and if you are a seasoned coder, coding it properly won't be harder than hacking it together.

Fakitall (0)

Anonymous Coward | about a year ago | (#42548959)

Just say "FUCK IT ALL AND DO YOUR JOB!" and then turn back to your display :D

Is he right? (5, Insightful)

AdamStarks (2634757) | about a year ago | (#42548985)

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.

Re:Is he right? (5, Funny)

flatt (513465) | about a year ago | (#42549149)

Whether he is right or not is immaterial. Now is the time to assert your dominance. Sucker punch him and urinate on him while he's down to put him back in check.

Re:Is he right? (1)

Jiro (131519) | about a year ago | (#42549245)

That's really the ultimate answer. Legitimate complaints sound identical to illegitimate complaints when posted as Slashdot articles, but the answer depends on whether the complaints really are legitimate. This is something we are unable to determine, and there's no shortcut to you figuring it out.

Re:Is he right? (1)

tooyoung (853621) | about a year ago | (#42549397)

Exactly. Maybe the author could point out a few examples so that we could better understand the issue. The only thing that we have to go off of is the fact that the author is right and the new guy is wrong.

I've found in general that people have a tendency to get way too attached to their code. I love throwing out my code if I can replace it with a cleaner and less error-prone solution. Many people I have worked with have the attitude that "it works for the requirements that I was given, so I am not going to change it". The problem is, their code fits into a massive code base with many people working on it. The requirements may be expanded in the future, or the next person who touches the code may not be the author.

Well, he's young, so you're a moron (2)

mveloso (325617) | about a year ago | (#42549477)

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.

Fire him (4, Funny)

Anonymous Coward | about a year ago | (#42548987)

Firing him might be the best lesson he ever learns...

You Are Not Your Code (5, Informative)

Anonymous Coward | about a year ago | (#42548991)

You Are Not Your Code: http://sstephenson.us/posts/you-are-not-your-code

Looks like that other guy figured out how (4, Funny)

Anonymous Coward | about a year ago | (#42548993)

Get a third party (0)

Anonymous Coward | about a year ago | (#42548997)

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.

timothy is apparently easily trolled (1, Insightful)

MickyTheIdiot (1032226) | about a year ago | (#42549023)

Give me a freaking break...

Re:timothy is apparently easily trolled (1)

tippe (1136385) | about a year ago | (#42549181)

No kidding... that's the first thing I thought when I saw the title.

Next on Ask Slashdot: "How can I tell my Slashdot editor that they're an idiot?"

Re:timothy is apparently easily trolled (5, Funny)

gigne (990887) | about a year ago | (#42549279)

yep.

What next? "I am some code. How do I tell my new maintainers they suck?"

Become Jonathan Coulton v2.0 ? (2)

Qubit (100461) | about a year ago | (#42549033)

< insert witty song about geeky stuff here >

Re:Become Jonathan Coulton v2.0 ? (-1)

Anonymous Coward | about a year ago | (#42549169)

Every sperm is sacred...
Every sperm is good!

I Know Who This Is (-1)

Anonymous Coward | about a year ago | (#42549037)

We just had this story [slashdot.org] , and I think it's too much of a coincidence. Small world.

What to do (1)

Anonymous Coward | about a year ago | (#42549063)

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

4 o' clock (4, Funny)

Anonymous Coward | about a year ago | (#42549101)

outside, at the gate.

bad code offsets (3, Interesting)

themusicgod1 (241799) | about a year ago | (#42549103)

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 [codeoffsets.com]

You can always learn, and the world can always stand to benefit from more people offsetting their Bad Code.

Re:bad code offsets (0)

Anonymous Coward | about a year ago | (#42549191)

Or just kick him in the balls and laugh at his newly-found sterility.

Do you always let interns tell you what to think? (4, Insightful)

jeffmeden (135043) | about a year ago | (#42549119)

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.

Re:Do you always let interns tell you what to thin (4, Insightful)

ByOhTek (1181381) | about a year ago | (#42549211)

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.

It depends on how he goes about it. (4, Insightful)

ByOhTek (1181381) | about a year ago | (#42549131)

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.

Re:It depends on how he goes about it. (2, Informative)

ByOhTek (1181381) | about a year ago | (#42549407)

You should also try to avoid my typos and grammatical errors. Those will not help your case.

I thought... (4, Funny)

SternisheFan (2529412) | about a year ago | (#42549143)

I thought if you were supposed to call in sick if you had a bad code. :-)

*ducks*

Re:I thought... (3, Funny)

Anonymous Coward | about a year ago | (#42549339)

I thought if you were supposed to call in sick if you had a bad code. :-)

*ducks*

I got debug bad.

Re:I thought... (1)

LordKronos (470910) | about a year ago | (#42549473)

I thought if you were supposed to call in sick if you had a bad code. :-)

*ducks*

I've tried that, but every time I call in, they make me return to work anyway.

Is Your Code Designed to Build Walls or Bridges? (5, Insightful)

VoidEngineer (633446) | about a year ago | (#42549151)

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.

Re:Is Your Code Designed to Build Walls or Bridges (3, Interesting)

phantomfive (622387) | about a year ago | (#42549331)

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.

Your code is bad (-1)

Anonymous Coward | about a year ago | (#42549155)

And you should feel bad.

50,000? (0)

Anonymous Coward | about a year ago | (#42549159)

Only fifty thousand lines? Is this really possible?

Re:50,000? (1)

obarel (670863) | about a year ago | (#42549415)

You'd be amazed what APL can do in a single line.
I wouldn't like to read 50,000 lines of it, though.

A good opportunity (5, Interesting)

Anonymous Coward | about a year ago | (#42549161)

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.

any problem here? (0)

Anonymous Coward | about a year ago | (#42549175)

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.

Step One (-1)

Anonymous Coward | about a year ago | (#42549179)

Don't ask on slashdot. There are no coders or technically literate people here. This is just a wank-fest for linux and apple fans.

Don't be a dick (4, Insightful)

uepuejq (1095319) | about a year ago | (#42549195)

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.

How's your documentation? (5, Insightful)

dbc (135354) | about a year ago | (#42549201)

I'm sure if he re-reads your internal design specifications, coding standards, and comments in the code he will understand your design.

Re:How's your documentation? (4, Funny)

Jawnn (445279) | about a year ago | (#42549309)

I'm sure if he re-reads your internal design specifications, coding standards, and comments in the code he will understand your design.

What's the giant whooshing sound? It's as if thousands of blissfully ignorant "senior" coders suddenly missed your sarcasm, all at once. Well done, sir.

correct move (-1)

Anonymous Coward | about a year ago | (#42549207)

Tell him to STFU and get you lunch.

Those who are not satisfied with others . . . (4, Interesting)

PolygamousRanchKid (1290638) | about a year ago | (#42549227)

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

Show him this page. (0)

Anonymous Coward | about a year ago | (#42549233)

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.

Put him in your shoes (2)

kvnslash (2292742) | about a year ago | (#42549265)

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

The most valuable lesson (1)

pudknocker (516571) | about a year ago | (#42549283)

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.

To be 'sensitive' or not to be... (1)

adosch (1397357) | about a year ago | (#42549289)

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.

comments are free (1)

apcullen (2504324) | about a year ago | (#42549291)

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.
 
  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:
 
/* changing to this funky data structure because jerry's an idiot */
 
/*funky data structure description follows:... */

  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.

Re:comments are free (2)

Desler (1608317) | about a year ago | (#42549487)

There is no excuse for anyone looking at your source code to not understand it.

That's a ridiculous statement and standard. Lack of experience or knowledge of the problem domain is often a reason why people won't understand code. Now the code might genuinely be poorly-written, but just because newbie hot shot doesn't understand it doesn't mean it's bad.

Different philosophies (2)

scorp1us (235526) | about a year ago | (#42549293)

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.

Both Stories Start From A Bad Place (1)

ios and web coder (2552484) | about a year ago | (#42549325)

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

Bring in your team lead (1)

mykepredko (40154) | about a year ago | (#42549347)

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

Clarity & Maintainability (0)

Anonymous Coward | about a year ago | (#42549361)

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.

It's the circle of life... (0)

Anonymous Coward | about a year ago | (#42549365)

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.

Stop writing shit code. (0)

Anonymous Coward | about a year ago | (#42549377)

Problem then solves itself.

As time goes on... (1)

CFBMoo1 (157453) | about a year ago | (#42549383)

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.

Re:As time goes on... (1)

CFBMoo1 (157453) | about a year ago | (#42549437)

Not to intentionally reply to my own post but one other thing I thought of.

Code I've looked back on and asked why they did it that way was sometimes greeted with the response of, "Because they didn't have the fancy new way of doing it back then in the development tools." As time wears on better options show up, I especially notied this when my work place finally upgraded the database to one that supported regular expressions.

Give it time (0)

Anonymous Coward | about a year ago | (#42549431)

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.

WYSIWYG (0)

Anonymous Coward | about a year ago | (#42549433)

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.

Admit he's right (1)

bakedbread (2009504) | about a year ago | (#42549441)

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.

He's probably correct! (0)

Anonymous Coward | about a year ago | (#42549443)

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.

Do your code actually suck? (0)

Anonymous Coward | about a year ago | (#42549453)

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.

He has some growing up to do, Knuth (1)

raymorris (2726007) | about a year ago | (#42549459)

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.

You have misdiagnosed the problem. (1)

taustin (171655) | about a year ago | (#42549483)

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.

Simple Solution (-1)

Anonymous Coward | about a year ago | (#42549485)

Slap him.

Maybe you code _is_ bad? (2)

gweihir (88907) | about a year ago | (#42549489)

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.

Define "bad" (5, Insightful)

SirGarlon (845873) | about a year ago | (#42549495)

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.

"Knock yourself out" (1)

AlienSexist (686923) | about a year ago | (#42549531)

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.

Almost all new "smart" guys hide behind egos (0)

Anonymous Coward | about a year ago | (#42549537)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...