16 ms·

The Best Programming Advice I Ever Got (2012)

• ydnaclementine 8y ago
  I'm just not piecing it together. The author was told: >In the future, stay the Hell out of other people's code. But then says: >Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since. But those words were valuable nevertheless, and I've gone back to them time and again. So was that advice bad and why? Or did it end up being useful, and why?
  • Exuma 8y ago
    This article literally made no sense
    • EliRivers 8y ago
      That's deliberate. It's not meant to be read literally. The author is using the rhetorical device of irony.
      • narag 8y ago
        More than irony, it's a paradox: the advice was so bad that it was useful, because he had no doubt it was bad and it was received in dramatic circumstances so he will always remember to do exactly the opposite.
        • EliRivers 8y ago
          I stand corrected. I read and understand such devices, but it's been so long since I had to formally identify them that I just go for the basics. As an aside, as time goes on, I find myself valuing more and more the ability to read and write beyond the purely literal. The literal can be so inelegant and inefficient, but sometimes it feels like anything beyond the literal can be perceived almost as a foreign language, and if the person with whom one is communicating never learned that language, it's all Greek. I suppose its like an add-on to one's language that's learned in Literature classes, or rhetoric classes, or Classics.
    • moneytide1 8y ago
      I see how it's counter intuitive - almost seems as if the author is contradicting himself. But it did drive a point home, especially that last sentence. This is what I took away from it: You may be able to come up with better ways to do things, but that often means replacing or voiding the efforts of coworkers or bosses. People have fragile egos, and may feel their job is being threatened since you are arranging things more efficiently. This could churn office politics, and cause problems that have little to do with the job itself (emotionally compromised workers and shifting hierarchy). Likewise, it is our responsibility to embrace the skills of fellow workers in order to enhance workflow. There is no such thing as superiority if you're a member of a team. Kill the ego and think about constant improvement for the group
      • deleted 8y ago
        [deleted]
      • Gibbon1 8y ago
        > but that often means replacing or voiding the efforts of coworkers or bosses. Comment: Having a work environment where people up discard and replace the the work other people have done is really really bad for moral. If you let that stuff happen continually you'll end up with a team where no one cares or takes ownership of anything.
  • BeetleB 8y ago
    It was both. The advice was bad. But it was useful in helping him maintain perspective any time another engineer had comments about how crappy his code was. His instinct was to give them the same advice, but his brain would override reminding him of why that's bad advice to give. It also helped him understand politics in a company, and how it gets in the way of certain types of progress.
  • robertAngst 8y ago
    Awful article for this reason. Learned nothing.
    • codyb 8y ago
      Really? It doesn't take much to see that he used the opposite of that advice in order to make sure he was attentative to new hires insights and to criticism's about his own code. Everytime someone comes up and says his code sucks he remembers being a young engineer admonished for making someone's code better, and instead of getting defensive, he listens.
      • robertAngst 8y ago
        Wait, programming=/= engineering One is logic, the other is applied.
        • zbentley 8y ago
          > One is logic, the other is applied. Not according to any formal or colloquial definition I've ever heard.
• perpetualcrayon 8y ago
  I always worked for small companies early in my career for exactly this. The suspicion that large corporations are driven by egotistical sociopaths. Now that I've worked for a large corporation I have proof that I was right (YMMV). Not only that, egos can become such a barrier to progress that projects within these companies become what I would consider criminally incompetent.
• Tomte 8y ago
  The author, Russ Olsen, has written a book, "Eloquent Ruby". It's probably the best programming book I've ever read. It teaches high-level concepts, hard technical stuff about how Ruby really works, and does so in a conversational voice. And in all of those points it succeeds spectacularly. He never sounds arrogant, he never feels colloquial to the point of being imprecise. Just… pleasant. I have cooled down on Ruby and don't have much use for the book nowadays, but if you use Ruby, get this book in preference to all others. Including the "essential" Dave Thomas book.
  • mykowebhn 8y ago
    I second this. I've mentioned "Eloquent Ruby" several times to Rubyists as one of the best books I've read on Ruby. Russ Olsen makes difficult concepts digestible. My only guess as to why it's relatively unknown in the Ruby world is that it's quite old. Perhaps a new edition could have fixed that?
  • scruple 8y ago
    I've had a copy of Eloquent Ruby on my bookshelf for years, just sitting there collecting dust. I picked it up yesterday after reading this comment and, while I've only made it through the first four chapters, I have to echo the sentiment. Once I finish it, I'm going to give it to a junior on my team. I think they're at a point in their journey where the messages in this book will really help them.
• moneytide1 8y ago
  "But the best way to have a future is to be part of a team that values progress over politics, ideas over territory and initiative over decorum." Recently had to quit my job because of exactly this. People will sabotage things simply because they want the useful idea to be theirs.
  • pmikesell 8y ago
    In my experience, the probability of this happening increases proportionally with the size of the company.
    • porphyrogene 8y ago
      Wouldn't that mean that the probability is always 100% because the company is always 100% of its current proportion?
      • m12k 8y ago
        No, "proportional" just means the two things correspond in size, not that the sizes are equal. In other words there is a positive correlation between the values.
        • porphyrogene 8y ago
          According to the Wikipedia page for proportionality[1], the values "can also be viewed as a two-variable linear equation with a y-intercept of 0". Direct (as opposed to inverse) proportionality is a type of positive correlation but they are not the same thing. Because we are dealing with probability percentage as a proportion of the company's size either the size is greater than zero and the probability is 100% or both values are zero. 1. https://en.wikipedia.org/wiki/Proportionality_(mathematics) https://en.wikipedia.org/wiki/Proportionality_(mathematics)
          • EpicDavi 8y ago
            These are the absolutely useless arguments I come to Hacker News for.
• alexashka 8y ago
  All it reminds me of Steve Jobs saying A players only want to work with A players. B players hire C players, C hire D and before you know it, you have the politics described in this article.
  • BeetleB 8y ago
    It's convenient to try to squeeze his story into Steve Job's mold, but in my experience, it's the A players who tend to be the most guilty when it comes to these kinds of politics. In my company, I've worked in two departments - one full of highly intelligent folks, and the other full of mediocre ones. In the former, these kinds of politics prevailed. I recall a particular instance where one person was working on a library, and he would actively invade other teams to shut down projects that remotely resembled his - even if his library did not supply all the features the others were building, and even though he had not yet released his library. In the latter team, people knew they were mediocre, and were much more open to learn because of it. Pointing out problems with their code never triggered their ego.
    • darioush 8y ago
      Those who I consider A players don't foster insecurities about their coding abilities in their egos.
      • BeetleB 8y ago
        Your thesis is pretty circular. You're not making a statement about A players. You are merely defining them to be that way.
        • ScottBurson 8y ago
          It's fair to define them that way if such people actually exist -- which they do. I've worked with some very smart people who don't have these ego problems. Some do, of course, but I wouldn't call them A people.
        • wtracy 8y ago
• HillaryBriss 8y ago
  it may not be good advice, but it gives you something to think about
  • vubui 8y ago
    Why is it not a good advice? Care to elaborate?
    • mdpopescu 8y ago
      I'll give you two reasons: 1) It's not your code, it belongs to the company. 2) If you can't accept changes to code you worked on (NOT "your code"), you're unlikely to improve. I agree these are not absolutes. It might be that you understand the subtleties of some particular device / library / whatever much better than other people, and their changes to the code you wrote with those quirks in mind are bad because of their lack of depth. Talk to them, or better yet use meaningful names / comments in the code so that they understand why you wrote it that way.
    • HillaryBriss 8y ago
      sorry. i was not clear. i just meant to say that one need not agree or disagree with it in order to gain some value from it. i mean, it's worth thinking about: "some people might get mad when i make a change to this unfamiliar, problematic, buggy code base. but how mad are they going to be? could my boss become angry with me? will i make any enemies? will i be a hero? will anyone even notice?"
• robertAngst 8y ago
  Since the article sucked, I'll give the 2 best engineering advice I've received from 2 different senior engineers: >Remember when you'd go to eat at a restaurant, and the kids menu has that game where 'What's the difference between these two pictures?' That is Reverse Engineering. You have a part that works, a part that doesn't work. What is different? >"You just kind of figure it out". Not sure how to start/solve a problem. Figure it out. This means researching, doing math, proving, and testing. And as I've done this more and more, math is really really useful to prove things.
  • ArchTypical 8y ago
    Already more interesting than the whole clickbait blogspam i just reread (to make sure i didnt miss something the first time).
  • deleted 8y ago
    [deleted]
• Koshkin 8y ago
  The idea (and practice) of "code ownership" is one of the most annoying things. First of all, it creates an atmosphere of some kind of laziness and lack of responsibility on the part of the individual team members (perhaps, not all, but still) for the results of the entire team's work. It also promotes what in my view is a rather insidious habit of assuming that if someone has wrote a piece of code long ago they are still responsible for it and, moreover, they are ready to instantly answer any question about it, as if it is supposed to stay fresh in the developer's mind forever.
• porphyrogene 8y ago
  This article is a great reminder of how to work with others but I think it is unlikely to be received well here. Hacker News loves to dump on junior developers and hates literary subtlety. This article uses the latter to admonish the former.
  • blowski 8y ago
    Your description of Hacker News makes it sound like it's a single person with a uniformly consistent opinion. It isn't.
    • steve_taylor 8y ago
      It’s a mob, reinforced by a system of rewards (upvotes), punishments (downvotes) and the politics of “karma”.
      • busterarm 8y ago
        Some of us don't care so much about the karma. Reactions to my posts are either extremely polarized (one way or the other) or basically neutral. I've even gotten the occasional ban threat from dang when I say something particular unpopular. Occasionally there's still some worthwhile discussion that happens here.
    • WilliamEdward 8y ago
      His description makes it sound like a hivemind, which it is.
  • mykowebhn 8y ago
    Although I tend to agree with you, I do think one has to keep in mind their audience. I typically don't expect to have to read programming blogs several times in order to catch the literary subtleties, whereas I might expect that reading literature or philosophy.
  • zengid 8y ago
    Maybe "hates" isn't the right term regarding literary subtlety. Perhaps, "cannot comprehend" would be better: https://news.ycombinator.com/item?id=18689608 https://news.ycombinator.com/item?id=18689608
• drharby 8y ago
  Cultural fit is now my primary hiring consideration, and this is why. Good advice, quick read, 9/10. Needs more dog
• gweinberg 8y ago
  This a beautiful story, but the title is wrong. It wasn't "the best" advice, it was "the most important advice". Big difference. The advice itself is terrible, but getting the advice, particularly from the top boss, is incredibly valuable.
• curtis 8y ago
  I'm not certain that the title does the article justice. The advice the author received was: > In the future, stay the Hell out of other people's code. However, the author goes on to reject this advice and gives some alternative advice instead.
  • mattnewton 8y ago
    The advice was so bad that it helped him not make that mistake. It was so bad it was good
• preommr 8y ago
  On a related note, can someone elaborate on the performance of using sockets. I would assume given that it's on the same machine that there wouldn't be that big of a performance hit. Especially if the data being passed was done in big chunks to avoid the overhead of whatever protocol was being used. I know it's not the point of the article, i am just wondering about it for curiosity's sake.
  • Matumio 8y ago
    It depends. Any IP-based socket will still go through some protocol stack (routing and filtering). On the other hand, unix domain sockets are optimized for IPC and should perform well. But any socket will require a copy, and thus be slower than shared memory. On the other hand, if you are going to exchange json messages, you can stop worrying about socket overhead.
  • rabidrat 8y ago
    It's the serialization/deserialization that gets you. And not just the actual transformation, but also the fact that you have to turn every operation into some message. What could be a fast loop to read/modify/write the bytes in some rectangle in video memory, now has to read all those bytes into a flat buffer, do the modify (probably with extra code because the layout of the mask and the layout of the buffer are no longer compatible), send through the kernel, and then get unpacked and written to video memory in the other process. For infrequent or batch jobs this might be a well-structured interface with some good robustness features. For user interfaces which should be low latency it takes 10-100x as long and for no actual benefit. Also doing things in big chunks is more efficient, but usually adds latency.
  • sonnyblarney 8y ago
    Well, many systems do IPC and often this is done over sockets. Maybe a better question is, in 2018 why don't we have much better, cleaner, simple, IPC? If the system was slow due to this, it might have been the sheer quantity of data over the IPC/Socket. Looks like they were rendering on one side (i.e. 'making the picture') and then pushing that to a different process to rasterize, i.e. 'draw it on screen' which just seems a little crazy. I'd imagine this was probably due to some kind of legacy thing.
• haxorito 8y ago
  I made same mistake, I saw how old system underperformed and that I could make it better, faster, more stable and bring higher profit. When I presented that my boss, next I know I’m in room with HR, my bosse’s boss and technical lead (who was practically executive director), to my surprise boss started conversation with “your actions concerning me...” they told me to give all the related code, documents and remove everything from my computer. After that incident I never got promoted, my annual bonus was always 50% of everyone’s. No one in the team wanted to talk to me, I was excluded from any design meetings. Eventually my whole team got promoted to principal engineers and all new comers were one level above me. That was the worst 4 years in my life ( I had to work for them because of the work visa)
  • InafuSabi 8y ago
    I do not understand why you were treated as if you wrote viral code which wiped all networked storage of the company. Did anyone ever say why you were treated like an infectuous disease after doing something good, which would benefit everyone?
    • jolmg 8y ago
      The fact that he was a foreigner provides a hint. It seems there's a general fear in the US of foreign workers taking the jobs of citizens. I wonder, is it not possible to switch employers when you have a work visa?
      • iratewizard 8y ago
        Or maybe more realistic and less paranoid: the code he wrote was more performant but significantly less maintainable. Look at it from a director's perspective. Technical debt from an H1b. Is he trying to maintain job security by being the only one who understands how a critical module works?
        • parrot_11 8y ago
          "Technical debt from an H1b." You seem to have jumped to a conclusion rather quickly. Even assuming for a second that the hysteria was because the new function that GP wrote is complex, wouldn't the reaction to that would've been "Can you write it more clearly?" instead of the hysteria and pariah ceremony?
• l0b0 8y ago
  Even on a purely technical level every organization has unprovable things its members believe in. Challenging any of these openly is a surefire way to get told in office-ese to STFU noob. Quietly demonstrating that they were wrong results in at least some cognitive dissonance, with all the mental fallout that gives. Even worse, you've done this after challenging them, and everyone gets defensive. And the absolute worst, as the author experienced, is when money or ideals is at stake, and you unknowingly shift the goal posts. I worked at a place with mostly time-limited positions as my first job, and based on what my original boss said I'm pretty sure the new boss passed over my application because of politics like these. But like the author this only strengthened my resolve to question my own and others' assumptions.
  • busterarm 8y ago
    Very early in my working life I had the misfortune of doing data entry and cashier work where I significantly outperformed my coworkers. I was _hated_ in these jobs. What I didn't realize was that the team's performance was dictated by the top performers and that _everyone_ was intentionally slowing down their work so that they could have a relaxed, easy job. By doing my best work, management set the expectation for everyone to work 10% better than that. What I didn't understand at the time was that several of the folks in that job were lifers and they'd realized quickly that the compounding interest of always having to perform 10% better every month would break them. My eagerness to do good work was quite literally ruining their lives. My take away lesson from this was to always try to work someone with people who are more skilled and more ambitious than you are or with people who want you to help pull them forward.
• InclinedPlane 8y ago
  This article is at best half useful, and missing the other half is potentially quite dangerous (to organizations, to people's careers, etc.) What's missing is a discussion of power and power dynamics (and healthy vs. unhealthy versions of same, let alone how to work effectively in either or drive change). Partly this comes down to a failure on the author's part to care about power dynamics or look at their own power. In this case the author was able to just blindly drive change by charging in like a bull in a china shop and the only consequence to themselves was a very minor verbal admonition, that's an indication of their level of power and where they sit in the overall power structure of their org, not every dev. in a similar position would see the same results, however. Many people would have to navigate that problem much more cautiously to avoid becoming fired or ostracized. (Edit: and indeed I see another comment in this thread about someone who did exactly the same thing as the article's author and it turned out very poorly for them because they lacked the power the author has/had.) Additionally, the author completely ignores the value of "soft skills" and implies that all that's necessary to have a positive impact where you work is to blindly seek the technologically superior choice whenever possible, ignoring politics, power, and ego (yours and others) along the way. There's value to that, but there's also great potential for that sort of mindset to lead you astray, because it's often difficult to know "what's best" in every situation. In the article's example the pros and cons were fairly straightforward, but most of the time the situation is likely to be a lot more complex or a lot more subtle. And it may be easy to make the wrong value judgment (and consequently fight the wrong technical fight) based on ignorance. On top of that, this story is very frustrating because it only concerns itself with technical problems. At the end of the day the organization was still just as dysfunctional as ever even though it grudgingly fixed a technical problem it found it couldn't ignore. The author helped fixed a defect in code but they did almost nothing to help fix a much larger and more serious defect in the organization they worked in.
  • watwut 8y ago
    I would not expect junior to fix large organizational issues. Not much possible. Also, while I strongly believe in treating people with respect and using social skills to the extend one has them, sometimes the right action to take is the one that makes people angry. When your relationships make it impossible to solve technical issues, it not junior who inadvertenly fixed issue who is not displaying social skills. It is whoever feeds the power struggle between departments.
• georgebarnett 8y ago
  Killing sacred cows in software dev is a crucial part of the overall process if you’re going to keep a product alive long term. Learning HOW to kill a sacred cow without pissing everybody off around you is a crucial part of learning to become a senior leader. Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team progress”.
  • darkerside 8y ago
    Where can I subscribe to your newsletter? This is a skill I think we all need more of, not just in software but in all aspects of life.
  • avinium 8y ago
    > Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team progress”. You're not wrong, but equally I'd argue that if you need a huge amount of groundwork to implement change, you're probably in the wrong organization. Good organizations value good ideas, irrespective of who thought of them.
    • georgebarnett 8y ago
      I'm not disputing that and in general I think that holds as a good litmus test. If you're always having to push crazy hard and nobody listens, one party is failing here (its either you or the company, situation dependent). That said, my experience tells me there's a lot more to it in some cases, org dependent. For example - all teams (even great ones) go through phases where they can tolerate more change than at other times. Why that's true is itself a huge list of factors ranging from what the org is doing as a whole, all the way down to the team itself and how they're currently working. It also matters how the idea is spread among a group. If the idea has legs, theres going to be a lot of broken telephone if you haven't correctly setup the context with thought leaders (which may be different people to the managers, who also need to know what's coming). This gets more challenging as the number of people involved gets larger.
    • 8y ago
• andrewstuart 8y ago
  The conclusions I completely disagree with. If you discover a way to make the system 100X faster, and the reason is someone else's code, then tell that programmer, and only them, and tell them gently what you found and leave it with them to be the person who implements it, or offer to implement a solution together if they want to. They may or may not take sole credit but it doesn't matter. Definitely do not sneakily try to let people know it was really you who is responsible.
  • usawco 8y ago
    Maybe Russ wasn't sneaky - especially since he said it was early in his career? Maybe he fixed it thinking everyone would 'high-five' him for the win. Unfortunately, he didn't understand the political ramification at the time. I've tried your approach. In my experience, the outcome depends on the person who has created the mistake - not the person who fixed it. Yes, be gentle with the solution, but that will not solve the problem if the person you are dealing with does not share your sentiments.
  • darkerside 8y ago
    It depends what one's goals are. Improve the system? Build good working relationships? Make yourself or your team look good? In many cases similar to the one you described, the other programmer has already heard what you are trying to tell them and chosen to disregard it, for reasons good or bad. You have outlined a good starting point, but if you stop pushing, you are likely going to maintain the status quo.
  • robocat 8y ago
    The whole point of the article was that there was no one you could "tell" - the problem was political not technical. "I've realized that there were probably a dozen programmers on that ancient project who knew why the system was so slow and how to fix it".
  • hutzlibu 8y ago
    "They may or may not take sole credit but it doesn't matter." If you improved something greatly then it is your credit and it matters that it was you and not someone else. IP conflicts are a different story, one that I would like to see avoided with OpenSource becoming standard.
• usawco 8y ago
  I had a similar experience and similar results. Someone wrote code to perform 1000 queries to pull back 1000 rows in a specific order rather than issue one query and let the Java collection order the results. Amazingly, another person wrote more logic to add a switch to skip this step because it literally took 10 minutes for the app to start when connected over VPN. The fix was trivial and startup time went from 10 minutes to 300 milliseconds. Being the new guy coupled with the fact they had actually lived with this for years, I was immediately hated.
  • hashhar 8y ago
    Oh man. I am so glad that I had the opportunity to work at an organisation that actually celebrated a few such improvements i made. There was a data ingestion job which inserted 4 million keys into Redis. It was awfully slow. I sped it up a lot using the Redis protocol format and redis-cli --pipe. They praised me for that. There was a dashboard which queried data from a MongoDB collection and calculated some counts. I changed the design so that the service itself would update the counts so as to avoid costly queries. I brought down build and deploy times for a service by removing unused gradle dependencies, structuring the build to allow using parallel builds and removing unnecessary configuration generation using templates and the entire team was glad that I solved a major pain for them. Sorry you had a bad experience but I think this is what we mean when we say company culture.
  • koala_man 8y ago
    I don't know whether to laugh or cry.. You work at a better place now, right?
  • bestCauliflower 8y ago
    This is making me angry. How come people are so stupid?
• jeklj 8y ago
  I did something similar once but failed to glean such a valuable lesson from the experience. My takeaway was, those people are touchy so leave their shit alone. Not because it’s right but because I’m just trying to get through my day, and i don’t need more politics in my working life. People can be assholes, it’s just how it is sometimes so let them be. Among my own team, if I raise points or ideas that get disregarded in this manner (as opposed to more thoughtful demurrals), I let it go and don’t push the issue. I’ll speak up if I think I have something worth considering, but I’m not going to beat you over the head to see things my way. Still, the takeaway regarding being on the other side of that table is really important. Once you start feeling that indignant reaction or “yeah right newbie”, listen harder.
  • darkerside 8y ago
    I've fallen in the same trap. And you're right, you can't fight every battle. But I think the best approach is not to make it a battle in the first place. Sometimes bringing things up in the right way and with the right energy helps people be more receptive to your advice.
    • jeklj 8y ago
      I don’t want to fight battles, at all. At least not in my working life but really not anywhere else either. I’ve seen a lot and done a lot in my career, and I don’t feel I have anything to prove to anyone anymore. On the other hand I do find it enjoyable to discuss ideas in a collegial environment where people really are trying to figure out what’s best. If we can agree on ideas as equals and proceed then great. If not, I’ll live. If someone gets mad because I had an idea to improve something I’m not going to get too twisted up about it. Life is too short for all this stuff, and it isn’t important in the scheme of things.
• ken 8y ago
  There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life. In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Correct Answer, so it becomes a political question. When my electrician has a power supply over here and needs power delivered over there, we all know he's going to use wires, and he knows the right gauge to use. He's got a book somewhere with the answer, and there's a regulation somewhere that says what he's required to use. But I just trust him to use the right cable, because that's his specialty, and I've never seen him make something that was an order-of-magnitude worse than was required, or that I could do on my own. Respecting boundaries is a lot easier when you can trust that other people are generally competent. This will continue to be a problem for the next 100 years until we figure out the right way to make good software.
  • hutzlibu 8y ago
    " There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Correct Answer, so it becomes a political question." When foo and bar both solve the job and equally fast, then yes. But in the example of the article the other version was much faster. So faster (assuming no bugs got introduced) means clearly the correct answer here.
    • ken 8y ago
      That's not clear at all to me. This system sounds extremely complex (which could be one of the causes of the problem!), so I don't see how we can assume that no bugs got introduced, nor that execution speed is the only metric that matters. Perhaps the existing socket-based solution simply used a bad timeout, and instead of a weekend of work to completely change the architecture of the system, it could have been fixed by changing one number in a configuration file. That would have been much lower risk, and not affected any other functionality, test suites, debugging practices, support procedures, etc. Software is still a young field that celebrates youth, and single combat warriors, like "Mel". It reminds me of Tom Wolfe's "The Right Stuff", about the U.S. space program back in the 1950's. One person could and did go do crazy heroic things that helped a single flight succeed. Eventually, space flight grew up, and NASA today barely even mentions the names of their contributors and collaborators. They'd never put up with cowboys like that any more. That's not how you achieve successful, repeatable results in complex systems. Or maybe I'm just getting old.
• astazangasta 8y ago
  There is an entire world to be dissected in the final few paragraphs. The essence of the error the author made (and we know he made an error because he ended up in the head boss's office being chewed out) is to imagine that a successful project is founded on good technical grounds; not true, or not only at least. The author's presumption here is that the advice was bad, and he learned the opposite lesson (don't accept social boundaries). But the advice WASN'T bad, because the organization doesn't consist of just code product, it consists of a set of programmers, managers, executives, users, customers, etc. The important question this article raises is: WHY do people write code? What makes someone want to write good code? What motivates them to do work? What motivates them to wish to cooperate with others in their effort, to communicate their problems and insights, and contribute to the greater health of the product? This, more than anything else, kills projects. The smartest people on earth can accomplish nothing if they petulantly refuse to cooperate, and in order to accomplish that you need to pay attention to more than what is merely technically best, you also need to pay attention to the people in your organization. What do they WANT? If they are anything like a normal human being, they want - to appear successful, to be valuable, to have their skills be seen as valuable, to have their ideas and work be appreciated by others. We can, of course, dismiss this as "ego" or "politics", as the author does, mere cruft that gets in the way of the ur-goal of the organization, a beautiful product. But if we do so we're really ignoring what people want - and that is NOT to merely be a gear slowly ground down in the service of the greater good, eventually worn out and replaced by a newer, better gear. Such advice, that we should ignore the very normal (and yes, egotistical) motivations of ordinary human beings at work, is perhaps not the best advice you could get.
• aj7 8y ago
  People keep saying, “this is bad advice.” But this an article on software corporate politics, with a facetious title.
• usawco 8y ago
  I also believe smart people will do dumb things from time to time - especially under the pressure of deadlines. It's always good to assume they were having a bad day. I know what does not work - printing out a "team-mate"'s code and pinning it to your cube wall w/o even asking a question about it. That goes in the bucket of things I thought I'd never see in the workplace. Truly amazing...
• hashhar 8y ago
  Oh man. I am so glad that I had the opportunity to work at an organisation that actually celebrated a few such improvements i made. There was a data ingestion job which inserted 4 million keys into Redis. It was awfully slow. I sped it up a lot using the Redis protocol format and redis-cli --pipe. They praised me for that. There was a dashboard which queried data from a MongoDB collection and calculated some counts. I changed the design so that the service itself would update the counts so as to avoid costly queries. I brought down build and deploy times for a service by removing unused gradle dependencies, structuring the build to allow using parallel builds and removing unnecessary configuration generation using templates and the entire team was glad that I solved a major pain for them. Sorry you had a bad experience but I think this is what we mean when we say company culture.
  • jpatokal 8y ago
    It's not about the tech, it's about the politics. If everybody agrees Redis is the way to go, sure, go ahead and optimize it. But what if there's a VP who's been arguing that using Redis is a mistake and you should be switching to MongoDB?
    • Aeolun 8y ago
      You kick the hornets nest.
      • JimmyAustin 8y ago
        "If you come at the king, you best not miss." If you criticize a seniors ideas, and they interpret it as you coming after them, you better destroy their reputation, or they'll destroy you. It's hard to destroy someones reputation within an organization, and most people get defensive when newcomers (especially juniors) come in with suggestions, so it's typically not worth kicking the nest.
        • Xcelerate 8y ago
          > most people get defensive when newcomers (especially juniors) come in with suggestions Reminds me of that quote "science progresses one funeral at a one". I had a good boss at a previous company. Shortly after I was hired, he scheduled a meeting with the rest of the team and said, "We want to get your opinion on this thing X we've been working on for over a year. Since you're new, you may have some fresh perspectives about what can be done." I generally think that's the right approach. Judging by the number of systems in different fields that have been overhauled by outsiders to the field, I imagine real innovation has less to de what thinking of new ideas and more to do with navigating the minefield of human psychology.
• williamdclt 8y ago
  Office politics or not, you have a problem when people start referring to parts of prod systems as "my code" or "your code". For me, from the point you opened a PR it's the team's code, not your own anymore. Everybody should be able to happily edit this part of the code without even thinking about asking for your permission (though asking for your input would probably a good idea), first to avoid this kind of nonsense and second because it avoids having people that are single points of failure (only one to work on this part of the code). I would consider toxic a work environment where somebody would talk about "my code" after it's been merged.
  • Silhouette 8y ago
    That's an idealised position, but not always a realistic one. Having specialists who understand certain parts of a complicated system better than anyone else is often valuable. Beyond a relatively small size of project, no-one can be an expert on everything, and a "shared code ownership" strategy where all code is communally maintained may leave you with no true expert when you need one. The underlying problem here wasn't really that someone "owned" that code, but that when someone else did have a useful suggestion to make, politics overrode technical merit. Clearly that had been happening for a long time and resulted in several other potentially useful contributions by others being wasted as well. This seems to be a problem of toxic management culture, not a flaw in the technical processes.
    • rileymat2 8y ago
      Don't projects like Linux use a system of module ownership/lieutenants?
  • dktp 8y ago
    Say that a bug occurs in the code that I wrote and I'm more familiar with than anyone else on my team. I'll gladly say "I wrote this, I'll fix it". In a perfect world, we'd all understand every part of the project as well as the next coder. But in my world shipping features on time is often more important. I do not consider my work environment toxic at all. Just an agile startup
• SagelyGuru 8y ago
  It reminded me of how I once got into hot water with the Boss over introducing a binary search into their huge customer file search and update operation, which used to take three hours to run. When the program stopped in five minutes, everyone was mortified that I had broken it.
• Cpoll 8y ago
  > I had supplied a war winning weapon to one organizational faction and the other factions were not happy The real problem is that there are adversarial relationships within the organization. It can be an ego issue, or perverse incentives, or conflicting departmental objectives, or short-term thinking. Anyone who doesn't spend their time focused on politics or covering their ass will still have their motivation sapped, and soon no-one will care about making the product better. The non-dysfunctional response is "great initiative, we'll get a meeting together and discuss the pros and cons of implementing your spike."
• kingofhdds 8y ago
  It's not a programming advice. Similar counsel is dispensed in various tech, and non-tech fields, because it's about relations with other people which sometimes could be more important than efficiency for one's career, or comfort. However, to discourage from thinking about improving other programmers code, and call it "the best programming advice"? No way.
  • avinium 8y ago
    You didn't read to the end. The author recognizes this as patently bad advice, and was glad to have received it so he was conscious of what not to do.
    • kingofhdds 8y ago
      Yup, my fault. I exploded too quickly, probably because recently had a similar discussion related to my own work.
  • Gibbon1 8y ago
    I've never worked in a software only organization. But instead in smaller teams of specialists. Usually there is an process where if you have an issue with something you work with the person who's responsible to fix it. You just do not go in and change things. You never go in and change things without telling them. Friend of mine talking about how he fixes bugs. Most of the time he tries to figure out where the problem is and and then writes that up. Then uses blame to figure out who wrote the code and reassigns the bug to them. Him: I Eddy, hey think there is a problem with this condition in this function. 15 minutes passes Eddy: checks in bug fix closes ticket
• AnAnonyCowherd 8y ago
  I got hired at a Fortune 250 to rewrite a system, from the ground up, that had been running for 5 years. I rewrote it in about a year and a half. Huge success; 1000 happy users. What I learned over time was that "the" person responsible for the group that was _supposed_ to be writing this sort of software in the company had been trying, for 10 years, to make something like it, with a whole team of contractors. In fact, it was his initial failure that caused my boss to write the first version of the program. When they saw that my boss had hired me, they doubled their efforts. Their version of the idea was total garbage. Nobody would use it. It was terribly slow, clunky, and had a fatal flaw that would have caused people MORE work than just not using their program. The boss of their group managed to get one of his underlings moved above my boss. He told us to stop working on my program. We did. They brought it Microsoft consultants to try to make their version suck less. It didn't work. I suggested many things to work together. Rebrand. Code features they needed. Use some of their software. Whatever. All rejected out of hand. We BEGGED our boss to IMPLORE the other manager to AT LEAST fix the "fatal flaw" of the other version. He agreed to, but we knew he wouldn't. We released a bug fix for production. The other manager lost his mind, and got our manager to force us to hand over the code to his group. It took them TWO YEARS to make a single change. My program happily ran like a clock during the interim. They finally gave up on their version. My boss was put on a PIP. I was put on the tiniest project possible (which was completely doomed anyway), and forced to write what should have been a quick and dirty web app as a corporate, Java monstrosity. (But I repeat myself.) In my first meeting, the other manager's toady told me to my face that he was going to kill the project I was hired for. In 4.5 years, I never even met the other manager, though he sat 50 feet away from my last cube. There was no winning. My boss was very politically savvy, and just plain nice. There was nothing he could do. I stayed completely out of it. I did the job I was hired to do, and embarrassed the wrong people. He was written up. I was put out to pasture. You can say that I should have done things differently. Maybe. Maybe not. What it tells me is that I was in the wrong company. Which sucks, because I could have written LOB tools like this for the rest of my career there. But this sort of dimness of vision is rampant throughout the company concerning anything related to IT. According to them, the only way to write software is to follow a strict waterfall methodology, in Java, with overseas contractors. Making the company suck to work at, and the act of wasting millions of dollars, because it helps you build a political fiefdom, is an idea that needs to be rooted out and eliminated by the C levels. Why does this not happen? Instead, one of the C's just did a "post-mortem" on this whole fiasco, and the result was that IT needs to be "more aligned" with the business, and have better "communication." Really? That's the level of acumen of our C-levels? They can't smell the metric buttload of BS that was shoveled in that meeting? OK, then. Good luck in the future! I start a new job on Monday. Crossing my fingers that they will be open minded. I wonder if my old company will still be viable in 10 years.
• TwoBit 8y ago
  Anybody who agrees with this advice works in a shitty company with bad culture.
  • lucb1e 8y ago
    Downvoting not because I agree or disagree, but because I think the generalisation does not help the discussion.
• z3t4 8y ago
  Communications! Don't stomp on other people to get to the top, instead get them to boost you up! Example: Make the changes to see if it works, but instead of showing it to your or his boss, you tell the one who wrote it that, "hey I got an idea on how to make this 100x faster". Only when he/she says your idea will not work, you say "actually I did test it, see". And you might get valuable information like for example the political status.
• sonnyblarney 8y ago
  This is the fault of the higher level executives. Clearly there was no oversight, no ability to discern what's going on their teams. And it's actually ok that there was much more spent than they planned for on something, this is the nature of development, even that there were competing ideas, even groups ... this is normal. But that there was no accountability for obviously bad actions - not good.
• swframe2 8y ago
  I suggested to my engineering director that we pivot our dev effort to avoid what I thought was a pending disaster. He responded that as long as he was director he would never make the change I suggested. Six month later the CEO replaced him and the new director announced he was going to make the pivot I had suggested. The old director resigned but advised the new director that it was not worth keeping me in the org because I was a trouble maker. Since helping people in a position of power over you is often perceived as threatening, just let them fail and focus on moving up in a org outside their reach. I would suggest moving to the competition and working to crush your old group.
  • sonnyblarney 8y ago
    Let's also consider that the worker is not always correct, and that managers might face such advice all day long from various sources, often by highly passionate devs who also assume they are right. In this case, it seemed that the director was 'wrong' but I don't think that there should be any inherent assumptions that an arbitrary engineers advice on pivoting is somehow the 'better' path. Also, there's a huge difference between being 'wrong' on a technical opportunity, and 'negligence' (i.e. not doing research, observing facts) or 'malfeasance' (i.e. willingly doing the wrong thing for the advancement of self etc.)
    • swframe2 8y ago
      My advice applies to the worker who has done enough research to feel confident that they've found a vastly better way that is likely to meet with resistance.
• philipyoo 8y ago
  Politics makes me sad. My main interest in wanting to become a developer was to have the ability to build improvements. I want the company to do well. I want the team to receive recognition. I want the people around me to be happy and to be working on a product they care about.
  • WilliamEdward 8y ago
    It's funny, because I wanted to be a developer for the exact opposite reason: to develop what I wanted, for myself not for a company. There's few other fields where you can be this creative, where there's infinite potential and infinite niches available. Why waste it all and get tied up in politics? I sincerely thought the ability to do anything was the reason people became developers in the first place.
• ape4 8y ago
  The change made the program faster but nothing is simple. When the GUI and backend were different progresses there was memory space separation. It was impossible for a stray pointer in one to klobber the other. Also there was a protocol between the two - which could be used over the Internet.
  • gitgud 8y ago
    That's what I first thought too. There's was obviously a decision to separate the processes, but the performance gain of combining them was probably more meaningful in the end...
• cleandreams 8y ago
  This is weird info right now because after an acquisition I got a big promotion on the technical ladder so that getting into other people's code and rewriting it is now a big part of my job. It's fun but I would not want to do this without a lot of management support. Also I work hard at relationship maintenance and buy-in.
• juddlyon 8y ago
  "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" - Upton Sinclair
• kazinator 8y ago
  What a bizarre story! Of all the people in the org chart, the "Biggest Boss of All" should be most concerned with the company bottom line, and least with protecting individual developer egos from each other. The wretchedly slow performance of the CAD system could easily have cost that organization customers. Just, wow.
• edw519 8y ago
  "Stay the hell out of other people's code." Great advice if you want a miserable 40 year career as a team player in mind numbing corporate work prevention departments. Bad advice if you want anything more out of your programming career. Horrible advice if you want to make a difference by sharing your gifts with those who need them. You don't get that many chances to do what OP did by jumping in and making dramatic improvements. The only reason I have ever avoided staying the hell out of legacy code was when opening that can of worms was just the wrong thing to do for everyone. Otherwise, I got the hell in there. Sometimes I was thanked. Sometimes I was reprimanded. Sometimes I was fired. Always I learned something, usually the best learning I ever had. (And as for getting fired, I wouldn't have changed a thing. This is actually a good thing. Better to push the limits, find out who you're dealing with, and move on quickly rather than being miserable for years without ever understanding why.) The Best Programming Advice I Ever Got? ... Always Do the Right Thing. (Even if it takes a lifetime to figure out what that is.)
  • gcb0 8y ago
    I highly suggest you go back and re-read the text :)
  • dkrikun 8y ago
    "Great advice if you want a miserable 40 year career as a team player in mind numbing corporate work prevention departments" This
  • hacym 8y ago
    I got some good advice that I will never forget: Always make sure you understand what is being said before you respond.
• romeisendcoming 8y ago
  Depends on your model. In a small business where you have a couple experts in different domains it makes perfect sense to talk about individual ownership. It's not toxic: it's forced practicality. In larger environments with close skill parity it doesn't make sense and hurts morale.
• crimsonalucard 8y ago
  No human is perfect and people inevitably make mistakes. Including big mistakes. Imagine this scenario. You created something very complicated that you're proud of. You spent a lot of time on it and your integrity and reputation rely on this thing you built. Little did you know that what you built could be done in a way that is easier and 10x better. The foundation of your reputation is in shambles. What would you do? I can tell you what I've seen from experience. The very people who tell you that bias doesn't affect them or complain about how politics always trumps technical problems are the very people who will FOLD when the same problem hits them in the face. No one is perfect and there will be a time that this happens to most people... a time when that person will be utterly and completely wrong about something they've advocated for so long. It's trivial, easy and immature to advertise and complain about the weaknesses in other people. I want to see a blogpost about a programmer coming to terms with their own grave mistakes... their own imperfection. Once you realize how hard is to do that, then you will know know what to do when this problem infects your work place. First and foremost you must introduce change without hurting peoples' pride. You must be empathetic and take into consideration how other people will feel if you try to pick them apart. If you take steps to do that, people will return the favor in kind. If you attack the scaffolds supporting the reputation of your peers, expect everything that you've built to be attacked as well. Remember. No one is perfect. The original poster is as responsible for creating a toxic work place as the people he's complaining about. I'd bet he'd react the same way if the tables were turned.
• dang 8y ago
  2014: https://news.ycombinator.com/item?id=7774016 https://news.ycombinator.com/item?id=7774016 2012: https://news.ycombinator.com/item?id=4366110 https://news.ycombinator.com/item?id=4366110
• fleshfly 8y ago
  This is a complicated and fascinating topic. I wish there were more case studies and frameworks about how to navigate these problems.
• tinkerteller 8y ago
  This is mind numbing article and probably not worth anyone's time. The so called "best" advice is: Stay the hell out of other people's code*.
• dkrikun 8y ago
  Could not disagree more. The author most probably freed the company from its dysfunctional stagnation due to some political issue. It is thanks to his ignorance that he resolved an issue, something that had to be done. In general, staying out of other people code is a bad idea. It promotes lack of transparency and agenda proliferation. This is because the owners of the code start being a "monopoly", can work less hard, provide exaggerated estimates etc. When people know that others can read there code, maybe hack on it, make something faster or simpler -- well they work harder and tend to be more transparent.
  • wmichelin 8y ago
    Sounds like you didn't read the article :)
    • dkrikun 8y ago
      I did and I know the author says "actually it is a terrible advise" but he also continues to soften his statement
• eranation 8y ago
  Did anyone really read this till the end? If your conclusion is that the best programming advice the author ever got was to “stay the hell out of other people’s code” please try to read it again... that was exactly the opposite of what he meant. Best advice I ever got: always read things ten times before responding. > “Actually it was terrible advice, advice that I've gone out of my way to ignore in the years since. But those words were valuable nevertheless, and I've gone back to them time and again. Every time some annoying new-hire comes to me with a dumb idea that is obviously not going to work, Stay the Hell out of other people's code plays back in my head and I listen harder. Every time some other engineer has an opinion about my code, I remember what I thought of the idea that you should mind your own technical business and I try to disengage my ego.”
  • gdy 8y ago
    Yep, seeing so many people with reading comprehension problem here at HN is surprising.
    • bartread 8y ago
      I know, and it's not even like it's a long article. They must have got to that sentence and then just rage quit or something. It amuses me, but I won't say I've never done it myself, particularly when I'm already tired and irritable, and I'm reading a piece by an author who's taken a provocative stance without quickly getting to the point. Tough to make that accusation stick here though.
    • redisman 8y ago
      At least they skimmed instead of just reading the title. Looks like it did more harm than good though heh
  • Asooka 8y ago
    True, but with so many people with reading problems, it would behoove any author to state his thesis simply and plainly in the first paragraph, in straight text, with no sarcasm, allegory or metaphor. Otherwise you run the danger of bringing upon us another Waterfall^1 situation. When giving advice that could be read and acted upon by managers, please try to make your text's meaning resilient against shortening. That is, it should be possible to cut out any amount from the end of the text and end up with either the intended meaning or no meaning. ^1 - The original Waterfall paper describes Waterfall as what NOT to do, but this becomes apparent about halfway through and then goes to suggest something very close to Agile. Unfortunately, if you just read the start of the paper, maybe if you're a pressed for time manager, all you're left with is an impression of how great Waterfall is.
• sbmthakur 8y ago
  I work in a small team. I occasionally find a thing or wrong in my teammates code. But instead of changing things I simply talk it out with them. Requesting them to try the change also ensures that they've their sense of ownership. It has worked nicely for me till now.
  • Vektorweg 8y ago
    I think, that is a bad argument, but a good practice. Always have the devs fix their own mistakes, so that they can learn from them.
• darrenhobbs 8y ago
  In 1999 my boss's boss loved Silverstream.* It stores code in the database! Anyone still using files for code is obsolete! We had 12 beefy servers powering our site. So I rock up and realise we're not using any of Silverstream's features, and its just acting as a servlet container. Big boss had moved onto bigger and better bossing by now so wasn't around to stop me. After a couple of weeks of investigation, we demonstrated that Caucho Resin is better in every way. Fraction of the cost, starts super fast and runs like lightning. Great. We happily switch over and all was well for almost a week. A few days in the head of Ops barrels up and demands to know if this was all my fault. "Ummm, yeah?" "Great. What the fuck am I supposed to do with the other 11 servers??" I think they'd had to fight for budget for enough hardware to run the site with Silverstream, and young me had just made them look incompetent. They forgave me eventually... * I actually like Silverstream's core ideas. It was just a little ahead of its time, and stored code in the db. And was 12x too slow.
• jondubois 8y ago
  The problem nowadays is that software engineering is mostly about politics - Especially in big corporations. Corporations use extremely inefficient tools and processes but because they have a monopoly over some area of the market, they can easily survive in spite of very poor technical decisions. What happens is that engineers who work for these companies learn a lot of bad habits and tools which slows them down; they become overly focused on risk mitigation instead of productivity. I'm starting to think that this is intentional; corporations want their engineers to get stuck in a technological rut; that way they can't leave and start working for a startup which will disrupt them later. Even some corporations which seem innovative, are not actually innovative at all; their entire ecosystem of tools is extremely inefficient once you step back and consider the big picture.
  • Lio 8y ago
    I don’t think it is intentional or malicious. I think it’s more likely that in big bureaucracies management is seen as the most important function of business. Managers see their work as “important” and not just the admin that supports the real function of the delivering product. If you’ve ever sat in a meeting where management spent the whole time talking, instead of asking the team that does the work how could we improve our current processes, that’s what’s happening. You’ve run smack bang into the collective ego of multilayered management. Small startups succeed in part because the lines of communication are small. The ratio of those “ordering” the work to those “doing” the work is low and feedback is possible. In big enterprises outsourcing looks like a great idea because value only comes from management and workers are just a cost centre. Cheap is better than expensive if you think everything is a commodity.
• russolsen 8y ago
  Now that my job resembles the 'biggest boss of all' more than the young developer that I was all those years ago, I often think about what I would have said to that young man. If it were me I would thank that young developer for all the hard work and offer a few bits of advice on getting things done without pissing people off. And then I would get all of the leads together and have a serious talk about how we can take care of all of our people while at the same time producing the best system humanly possible. Good developers work hard and care harder and, being human, they have egos. But everyone has blind spots and everyone makes mistakes and the essence of a good organization is that it blends the strengths of all of its members.
• luord 8y ago
  The best programming advice I've gotten is from Tron: "fight for the users".
• techbio 8y ago
  > They knew, but they kept it to themselves because in that organization, there were some things that were more important than making the system better. Hope this isn't the best advice I ever get. I do like that it wasn't the biggest-boss-of-all's words that mattered, but how the words made him feel: never be this guy.
• thr0w__4w4y 8y ago
  (background: my expertise/degree is microprocessor design and digital logic, although I've done a butt-load of firmware in C and C++ in my career) One time (long time ago) when I worked at Motorola (this was back pre-2K when working at Moto actually meant something). There was a systems level problem, and I was brought in as a systems engineer to diagnose a problem (think "big system with tons of FPGAs, fiber optics, embedded CPUs, firmware, etc.) Pretty soon I delivered my suspicion that the real issue was a hardware problem (this after looking at network data on a capture) The hardware director said (I wrote this down in a notebook, I'm quoting verbatim): "I stake my career that this isn't a hardware problem. It's either a firmware problem or a misunderstanding of the requirements." It was a hardware problem. I demonstrated it a few weeks later and the chip vendor confirmed it (it could take up to 2 weeks to reproduce the problem) After that my name was shit. That's when I learned that office politics are very fucking real, and sometimes you have to decide if you want to be a lifetime corporate employee. I left less than a year later, hung out a shingle as a consultant and life has been great since then. You can try to bend the world (or your employer) to your will, but it isn't going to end well. If my life goal had been "work for Moto for 40 years then retire", that wouldn't have worked out so well, for multiple reasons. I'll always bet on myself before I'll bet on BigCo. I'm contacted every month on LinkedIn by Google, Amazon, etc. (I've trained lots of their employees) and my answer is always the same: "thanks but no thanks" Apologies if this sounds self-aggrandizing. 100% not the intention. Just a lesson that you gotta look out for yourself, and the real world is complicated. Own your career, don't put it in the hands of BigCo. BigCo doesn't give a shit about you.
• stefek99 8y ago
  Some people just scan the content, I actually read the full article!