Ask Slashdot: How To React To Coworker Who Says My Code Is Bad? 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?"
bad code offsets (Score:3, Interesting)
You can always learn, and the world can always stand to benefit from more people offsetting their Bad Code.
A good opportunity (Score:5, Interesting)
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.
Those who are not satisfied with others . . . (Score:5, Interesting)
. . . 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 . . .
Re:Is Your Code Designed to Build Walls or Bridges (Score:4, Interesting)
Re:Tell him to write goddamn login page himself? (Score:5, Interesting)
Forgot to add, this guy put it way better than me a while ago (yes, I bookmark slashdot comments that are particularily helpful.. it comes in useful surprisingly often):
http://ask.slashdot.org/comments.pl?sid=1932550&cid=34743614 [slashdot.org]
Re:Old problem (Score:5, Interesting)
I came into a new position, my first serious one (when I was in my forties, second career field, after a couple years of good community college studies). I have experienced in depth 3-6 (3 thorough exposure, 3 partial/peripheral exposure) different, substantial code bases. Two of them where horrendous ("devil spawn"), one was not exactly a work of art, but manageable, managing considerable (reporting and logging) complexity, and the other 3 were solid to the point of being elegant, and naturally readable. And mind you, this was my first serious in depth exposure, across a variety of development platforms, including both proprietary and open source.
"Man is the measure of all things." -Protagoras
Technical Debt (Score:5, Interesting)
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.
Or... (Score:5, Interesting)
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.
Re:Old problem (Score:4, Interesting)
Actually the Space Shuttle Challenger was a design choice to save on the cost of shipping the tanks to Florida. The alternate one piece design didn't fit through one specific tunnel along the railroad from the plant to Florida, and would have required overland transit. It was well known within the industry. The other tank design was nearly identical to the design used by Russia. I was in an aerospace engineering class when this happened, and we studied the problem. I'm positive my professor already knew the answer, he was part of NASA's team.