The code culture problem • Hacker News Board

Re: The code culture problem

#141

Post by acjohnson55 » Thu, Sep 05, 2013, 5:53 PM UTC

badman_ting wrote: post #42

How about a culture of "stop fucking up". (I admit I stole this from Ted Dziuba, but it has stuck with me.) People who are willing to call things "shit" instead of being nicey-nice at least give a shit. But it is important to be intellectually honest, and not be egotistical about one's own code, which could be shit just like anyone else's.

If someone's "fucking up" repeatedly, either constructively work to remediate them or replace them. But simply being a jerk does not prove or disprove that you "give a shit". It just means you're not very good at articulating what's actually bothering you or separating the actual problem from your frustration.

Re: The code culture problem

#142

Post by droidist2 » Thu, Sep 05, 2013, 6:53 PM UTC

corresation wrote: post #91

loup-vaillant wrote: post #56

Earlier quoted context omitted.

Have you never seen a piece of code that sucked so much that you could shrink it by a factor of at least 2? You lucky swine… Much (possibly most) code I have had to deal with was that ugly.

I don't know whether code verbosity is a measure of shit (indeed, that is one of those arguable points where one guy likes the single line ultra-functional version, and the other likes the same split into 20 lines). I'm not disagreeing on the notion that there is some shit code in the world. Of course there is. But if anyone thinks that all or most code is shit, it often says more about the speaker. And I don't mean…

I like your driving analogy. It's very true. Those who talk the most shit often are shit, like how some men call women bad drivers even though women are actually less costly to insure.

Bad driver stereotypes piss me off because they often work under the assumption that cautious drivers are bad drivers and aggressive drivers are good drivers. Hell I bet Asian women are really the safest drivers.

Re: The code culture problem

#143

Post by elliottwilliams » Thu, Sep 05, 2013, 7:12 PM UTC

fogus wrote: post #47

In my time as a professional programmer I've come to notice a trend. It's true that there is a lot of bad code in the world and much of it is worthy of derision. That said, time after time I've noticed that when confronted with a smelly codebase junior and/or less-skilled programmers are quick to blame the code and the person who wrote it while more senior and/or highly-skilled programmers will start by placing the b…

It sounds like junior devs are applying an attribution error: http://en.wikipedia.org/wiki/Fundamental_attribution_error

Re: The code culture problem

#144

Post by DominikR » Thu, Sep 05, 2013, 7:48 PM UTC

twistedpair wrote: post #129

DominikR wrote: post #63

Earlier quoted context omitted.

So what exactly is the point you are trying to make here other than that you are the smartest guy? The article is not about the existence of shit code, the amout of shit code produced per year or how much shit code the average developer will see in his career. It is about teamwork, and what kind of culture poisons the atmosphere in a company. Not about shit code, which by the way everyone here has produced at some po…

The point can be that the team can do it BETTER. If you run Sonar on a codebase and get 10K serious findings... then the code certainly is not optimal. There is no upper limit on how optimial it can be, but you'll certainly have an easier life and a better end product if you've followed best practices as opposed to "just getting it done" by the most junior, lowest payed code monkeys possible.

Then by all means improve or replace bad code and create an environment that will encourage devs to learn from previous mistakes and improve.

All I am saying (and I think the author tries to make that point) is that it is questionable that you are going to create such an environment by pointing fingers and treating devs bad.

My very limited experience (I am the mobile lead in a company) has taught me, having done all of that myself in the beginning, that I wont achieve anything this way.

What I saw is that people got defensive by default, protective about their work (so no one can attack them for errors they made), the company started bleeding talent (what person is going to like working in such an environment?) and so called "code monkeys" never improved, because they didn't believe that they could achieve anything meaningful by themselves.

For some companies this might work in a way that I can't understand, but I changed, because frankly I didn't like to work in such an environment myself, and it did have to some degree positive effects.

People share more information, there's less pressure generally and there is more trust in general that everyone is doing their best, and if unable to complete some task, will ask for help.

By the way, here's a Google I/O talk from 2010 about engineering leadership that covers the problems mentioned in the article - I cannot recommend it enough: http://www.youtube.com/watch?v=skD1fjxSRog

Re: The code culture problem

#145

Post by latenite4 » Thu, Sep 05, 2013, 7:48 PM UTC

see a great Dilbert cartoon about a similar subject http://tinyurl.com/av3ennj

Re: The code culture problem

#146

Post by acjohnson55 » Thu, Sep 05, 2013, 8:32 PM UTC

wnewman wrote: post #137

acjohnson55 wrote: post #125

Earlier quoted context omitted.

I'd much prefer to have GP on my team than you, frankly. I think companies are much more productive when they have people willing to learn from and teach one another rather than bringing negativity.

"rather than bringing negativity" That seems like a false dichotomy. Someone who's a pollyanna even about horrendous abominations is a problem in one way, someone who's indiscriminately contemptuous of reasonably useful code is a problem in another way. Software projects (or teams, or companies) can bog down or die in more than one way. Driving off people who are doing reasonably good work is one way, tolerating unre…

My dichotomy was between the parent and the grandparent.

I totally agree that not addressing issues and not bring (constructive!) criticism is a poor strategy. But your persons A and B have the same problem: they're critical without being providing any actual information. Person B just compounds it by also being a jerk.

As a programmer/businessperson, I'm not interested in making people feel good about poor quality work. I'm interested in people who want to improve themselves and the overall product, and ideally, enjoy the process. I just don't see how insulting code or people helps. I think it's perfectly possible to hold high standards on code and respectful conduct, and it's perfectly possible for people to rise to those standards, guided by constructive criticism.

Re: The code culture problem

#147

Post by swalsh » Thu, Sep 05, 2013, 9:17 PM UTC

Kind of reminds me of a story from today. I have about a 70 page design document, laying out exactly how a new system i'm building will work. I've built something very similar in the past at a previous company, so this design is coming from a few years of learning what doesn't work.

As I was trying to explain some of my, well non conventional ideas, another coworker pokes his head over the cube, and calls the design crap. This of course is nothing new, its almost a game for this particular engineer. In the end, I walked away trying to avoid the conversation. It felt emotional though, and frankly hurt my confidence (while probably inflating his own)

It kind of made me think of the phrase "no one ever got fired for choosing IBM" I could have chosen the obvious design, and gone forward. No one would have debated it. However I've done that in the past, and I've seen the terrible problems that come from it. My new design is an attempt to avoid those problems. The attitude really pisses me off though, and I find it extremely counter productive.

Re: The code culture problem

#148

Post by RogerL » Thu, Sep 05, 2013, 9:47 PM UTC

gruseom wrote: post #139

consultant23522 wrote: post #94

Earlier quoted context omitted.

As a coder the best compliment I've ever gotten was from a consultant. It was basically something like, "Hey, you're the [my initials] that wrote a big chunk of [system]? I can really tell the parts you wrote from the rest, it's so much easier to follow and understand." I had written the original code for that project solo and then it was passed on to another team for maintenance. That, to me, is the best thing a fel…

Persons { String[] first_name; String[] last_name; String[] address; } Are you sure they didn't do it for performance? That is a well-known pattern for getting better data locality ("structure of arrays" vs. "array of structures").

I was thinking the same thing; in such a case a // coded this way for cache coherence goes a long way.

Re: The code culture problem

#149

Post by johnjlocke » Thu, Sep 05, 2013, 10:36 PM UTC

etjossem wrote: post #138

BasDirks wrote: post #79

This piece reminds me of Linus Torvalds. He's the kind of guy that lives these truths. Always respectful and constructive, never saying code is shit, etc etc. We need more developers like him.

Are you kidding? Read this, it's a commit by Linus Torvalds: https://lkml.org/lkml/2013/7/13/132 We need more developers like Torvalds - not because he's nice, but because he's terrifyingly experienced and completely honest in his feedback. I couldn't think of a better mentor.

Just because Linus can get away with treating people like crap, doesn't mean everyone can get away with treating people like crap.

Re: The code culture problem

#150

Post by ser0 » Thu, Sep 05, 2013, 10:44 PM UTC

swalsh wrote: post #147

Kind of reminds me of a story from today. I have about a 70 page design document, laying out exactly how a new system i'm building will work. I've built something very similar in the past at a previous company, so this design is coming from a few years of learning what doesn't work. As I was trying to explain some of my, well non conventional ideas, another coworker pokes his head over the cube, and calls the design…

I think you can use the co-worker to your advantage. One thing we must all learn is how to defend and justify our decisions. This can either be done before or after implementation, which is what I believe the post is talking about. That is, people criticising others' implementation decisions with limited context. Most of us have read stories of Gates or Jobs dressing down employees that are unprepared. You could consult your co-worker before presenting in the future; assuming you can develop your relationship with him to the point where there is no malice in such an interaction.

On the other hand, I do also recognise that some people just like to mess with others. In such circumstances, if there are no other political concerns, I would simply ask the person the come up with an alternative solution, then argue the alternative on its merits vs. what you have designed. Given your 70 pages of documentation, a simple pros vs cons list that takes into account goals of the project for various timeframes and scales should result in a clear winner. Or should both designs be of similar value, then there is little point in changing your documentation anyway.