Radical Swiss financial reform campaign faces defeat - <AUTHOR> https://www.reuters.com/article/us-swiss-vote-sovereign/swiss-vote-on-whether-to-introduce-real-money-plan-idUSKBN1J60C0 <comment><USER2> I wonder about the translation, is "real money" an accepted economic term for this concept? Because "Voll" as a prefix usually means complete or whole, rather than "real", as in "Vollmilch" (whole milk) and "Vollkorn" (whole grain). (Source: I'm German.)

<comment><USER3> I think it´s the german version of the 1932 Fisher Full Reserve proposal.

<comment><USER4> *Swiss version

<comment><USER5> German as in language, not German as in the country. Vollgeld as a term also appears in German economic discussions (though mostly on the left, not so much in the mainstream).

</comment></comment></comment></comment><comment><USER6> Looks like it was voted down: [https://www.ft.com/content/686e0342-6c97-11e8-852d-d8b934ff5...](https://www.ft.com/content/686e0342-6c97-11e8-852d-d8b934ff5ffa)

<comment><USER7> Yeah

>just 26 per cent supported plans to strip banks of their ability to "create" money

<comment><USER8> Sadly unfair, I would also like to earn X and hold 2% reserve, ie. have 50x money to my disposition. My investments yielding 1% would effectively have 50% return. Magic.

</comment></comment></comment><comment><USER9> > Contrary to common belief, most money in the world is not produced by > central banks but is instead created by commercial lenders when they lend > beyond the deposits they hold for savers.

Sounds like an attempt to keep the loan-deposit ratio (LTD) at or below 1, so that the bank is only lending money that it actually holds in the form of deposits.

I'm told by a lot of experts that this is a bad idea and it will hurt the entire industry and contract the economy, but I'm wondering if it's possible to put a soft lock (like a semi-fixed-deposit) on portion of a customers deposits and use that to finance lending. As a customer, I personally wouldn't mind being able to put soft locks on parts of my savings in return for a higher interest rate (preferably through an online interface).

<comment><USER10> _I 'm told by a lot of experts that this is a bad idea_

That probably means it's a good idea ;)

Full reserve banking isn't quite what is being voted on here, but if it were to be implemented it wouldn't be so different to what Switzerland already has.

I have a Swiss account with UBS. Interest payments on my accounts are effectively zero. Not quite zero but so close it makes no odds. I am happy about this because the SNB is actually trying to force interest rates negative - like most banks, UBS is shielding me from negative interest rates (i.e. direct confiscation of savings) using its own profit margin.

However, the issue remains that I get no yield on my money. Or, no, wait, actually I do, because my banks also offers many different kinds of investment funds with high degrees of liquidity, transparency about what they do, their performance and their different degrees of risk. So I put a big chunk of my money into these sorts of funds (and yes yes, I know, there are better funds out there, I don't _only_ use UBS).

I think this approach is better for two reasons:

1\. It's always clear how much of my money is effectively risk-free deposits, and how much is "working at risk".

2\. It divorces retail banking services from investment services. For instance if I happen to like a banks customer service, e-banking portal, mobile app, credit card offerings or whatever, I can benefit from those, without needing to take it as a bundle with perhaps riskier lending practices.

The low risk funds I use are mostly short-medium term loans to Swiss business, but I could invest in mortgage funds if I wanted to.

It seems to me that if all banks in Switzerland had to go full reserve, then it'd mean relatively little change for people like me. Some bank customers who don't explicitly invest their money would now have to, if they didn't want to lose yield, but inflation in Switzerland is quite low so I suspect some people would be happy with just knowing their money is where they left it and is going to stay there. Investment isn't for everyone.

<comment><USER11> > > I'm told by a lot of experts that this is a bad idea

> That probably means it's a good idea ;)

This is just pure contrarianism. Experts also say it's a bad idea not to have clean drinking water, reliable electricity, and seatbelts in cars.

And believe it or not, there is a huge amount of data on what kinds of policy in banking work and what don't, leading experts to conclusions like these. We're not talking about a few naysayers, either. The Swiss National Bank themselves, who will be put in charge of all lending if this is implemented, say this is a bad idea.

<comment><USER12> > This is just pure contrarianism. Experts also say it's a bad idea not to > have clean drinking water, reliable electricity, and seatbelts in cars.

Difference: There's scientific evidence for the experts opinion in all these cases. Economics? That's more or less just crystal ball reading with a scientific shim on the top.

<comment><USER13> The line of thinking here deserves expounding. The discipline of economics is very important, but there needs to be some care about trusting the opinions of economists.

The opinions of an economist are worth very much, because listening to them sets up situations were it is easy for someone with an economics degree to push an agenda. But economists do have a lot to offer with observations like "this is very similar to the [suchandsuch incident] of [1887] in [Somewhere]", which is worth listening to. The limitations that surround economic 'experiments' are so severe it should be treated more like history and less like physics. Thomas Piketty with Capital in the 21st century is a great example of what I'm thinking - more history and data than theory, but some theory to provide structure to the data.

If science has a measure of quality, then that quality is the accuracy of its predictions. That ties in very closely to the ability to conduct experiments and collect accurate data. Economics as applied is a highly political process, which hampers both the perceptions and reality of how fair the experiments are.

<comment><USER14> The "discipline of economics" has no predictive power whatsoever. All it offers are "explanations" that can't be translated into actionable policies.

<comment><USER15> Oh, it has plenty of predictive power, it's just not evenly distributed. When economists weigh in on contemporary politics, there are usually a lot of assumptions that doesn't quite make it into the soundbyte (and I don't want to pin this solely on the press, there are plenty of economists that are happy with this situation, as long as "their side" gets a boost). This, however, is the case for all members of the "political" sciences.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> There is also a vote against online gambling which is bad for net neutrality.

It was brought up by local gambling interest but sold as protecting gambling addicts.

<comment><USER17> How is that bad for net neutrality? It would be a law, the same way child porn is illegal...

<comment><USER18> ISPs will be forced to block a blacklist of gambling sites.

<comment><USER19> That's not strictly necessary, the implementation and enforcement could be entirely different than that.

<comment><USER16> I hope so

</comment></comment></comment></comment></comment><comment><USER6> I don't really understand how this would work. If this passed and I was a Swiss person wanting a mortgage, where would I go to get one?

<comment><USER20> It's not a ban on loans, it's a ban on commercial banks creating money from nothing when they make loans.

<comment><USER3> However, effectively it would remove at least half the total loan supply, which would probably not be a good thing.

<comment><USER10> Why not?

Was the last global financial crisis not caused by idiotically lax lending conditions, made possible by - amongst other things - the fact that loans were far too abundant and cheap? And that was in turn because banks can lend deposits without blocking access to that same money by the depositors?

If the loan supply was significantly tightened, this would be "bad for the economy" in the sense that there'd be less economic activity. However that's not inherently a bad thing. Digging holes in the ground and filling them up again is economic activity, but it's still a waste of time.

<comment><USER21> Because borrowing money is often a good thing. Most people borrow money when they're younger, because their earning power is smaller, and they know they can repay it in the future. E.g. to finance their education. Most new businesses start off by costing their owners tons of money and not earning them anything, but again, some of them end up being an overall economic success.

Sure, if you're rich enough, you can self-finance your education or your new business, but if not, a loan is what you're looking for.

<comment><USER10> _Most people loan money when they 're younger_

I think you mean borrow. Loan would be the opposite.

You're arguing that loans are useful. Nobody is arguing the opposite. Yes, loans are useful, but when the people making them have nothing at stake because they are creating the money from nothing, you get a lot of low quality lending to low quality investments that are unlikely to pay back (put another way, are bad investments).

<comment><USER15> They're not creating money from _nothing_ , hence _fractional_. And to the extent they don't have anything at stake, it's because they get bailed out, which is a different concern altogether.

<comment><USER22> > They're not creating money from nothing, hence fractional.

No, banks do create money through loans - lending occurs first, then reserve requirements are met afterwards. See for instance this research paper from Standard & Poor's:

Repeat After Me: Banks Cannot And Do Not "Lend Out" Reserves

[https://www.kreditopferhilfe.net/docs/S_and_P__Repeat_After_...](https://www.kreditopferhilfe.net/docs/S_and_P__Repeat_After_Me_8_14_13.pdf)

The idea of "fractional-reserve banking" isn't accurate when it comes to modern banking.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> This would give the central Bank more control over monetary policy using the franc, but would also probably decrease demand for the franc, and slow down Swiss economic activity.

I would imagine banks would start issuing non-reserve-backed loans in other currencies, and it would make lending just marginally more expensive (exchange rate is now an extra barrier to getting a loan).

</comment><comment><USER24> I was under the impression that central banks regulated the banks to control the creation of money, if this passed wouldn't they just print what they would have allowed anyway.

<comment><USER25> There's a reserve capital requirement at the moment, but it's not one-to-one.

More detail: [http://www.batz.ch/wp- content/uploads/2017/10/Vollgeld_Summa...](http://www.batz.ch/wp- content/uploads/2017/10/Vollgeld_Summary_en.pdf) ; the implementation is not just a 100% reserve requirement but a limitation on interbank lending.

</comment></comment><comment><USER26> I wish this article would take a more scientific tone. It seems assert a lot of things about what are "likely" and "could" happen, in economics, which I understand to be a non-objective non-science.

I'd be content if they threw in little tidbits about "No economists can accurately predict recessions and thus economies are very poorly understood. One theory is..."

</comment><comment><USER27> > The latest polls showed the initiative unlikely to succeed with 54 percent > of respondents opposing the plan and 34 percent in favor.

So, nothing is going to happen.

<comment><USER28> Studies shows determined 25 percent can change the result.

<comment><USER29> Not in a vote - that's about changing the attitudes of the rest of society over time.

</comment></comment></comment><comment><USER30> > dangerous experiment

It's also an easily reversed experiment, which suggests that the naysayers may fear success more than failure.

<comment><USER3> Well sure. The history of economic experiments is that they do end up eventually getting reversed. After a period of death and destruction, revolution, economic collapse, starvation and dictatorship.

If there´s one lesson we really need to get over to the Economists from Computer Science it´s that they have to stop experimenting with the production system.

<comment><USER31> Inflation of the money supply allows governments to finance war[1]. Reducing inflation would have the opposite effect. It would lead to greater savings, which would lead to lower interest rates, which would lead to more investment, which would lead to more productivity, prosperity, and wealth.

[1]: [https://twitter.com/ydemombynes/status/985560599248756736](https://twitter.com/ydemombynes/status/985560599248756736)

<comment><USER32> The Swiss Government going on a war-declaring spree using loans from private banks is not a credible threat to the Swiss economy.

Massive instability in the lending market and a higher average cost of borrowing because of frequent short term credit crunches as the money supply is delinked from borrower demand is.

<comment><USER31> I'm not a finance expert, but my intuition is that the market is already good at smoothing out this kind of instability. This is what market makers [1] do and there is no requirement that a market maker needs the ability to make money.

Borrowing costs may be higher because this proposal removes some "free" money that banks can currently lend out. But maybe interest rates will stay the same and instead checking account fees will rise. This could induce some checking account holders to move some of their money to term loans to the bank which the bank could then lend out. It is not clear that interest rates have to rise.

> the money supply is delinked from borrower demand

The money supply available to meet borrower demand need not be created. It already is partially provided by people lending their money for a term to the bank. This proposal merely says that the bank may not use checking account money to meet borrower demand, i.e., it may not represent to a checking account holder that his money is available when in fact it has been lent out to someone else.

[1]: [https://en.wikipedia.org/wiki/Market_maker](https://en.wikipedia.org/wiki/Market_maker)

<comment><USER32> We've tested the ability of the market to smooth out instability caused by attempting to artificially fix monetary aggregates. We got high and wildly fluctuating interest rates and record levels of unemployment. And that was a _looser_ policy regime than the one being proposed.

Market makers do not sit around with huge piles of uninvested cash waiting for the day that loan demand to exceed its supply on loanable funds, and consumers with interest-free deposit accounts are not exactly the ideal people to make markets. And _of course_ when loan demand exceeds the amount of cash available to be loaned at that point in time interest rates rise. That's Econ 101.

</comment></comment></comment></comment></comment></comment><comment><USER33> Interesting. I wonder how the markets will take it in case it passed. Because THAT is the only test that counts...

<comment><USER34> The exact day it passes, the Swiss banking stocks would likely crash because their ability to be in control and pass the risk to the central bank (as the lender of last resort) is a big portion of their value.

But, what happens in the long run to the Swiss markets? I would suspect it's not good either, it mirrors how the money worked while on the gold standard too much for my taste in that rapid responses to recessions becomes much more complicated.

<comment><USER35> I don't see how it's similar to the gold standard; the central bank could still print money.

<comment><USER6> You're correct. And conversely as well; during the gold standard banks could still lend money from deposits.

<comment><USER36> Absolutely that is what 100% reserve people don't understand.

The money supply under the gold standard was highly flexible.

Banks depending on demand (or velocity) automatically raised or lowered their reserves.

Meaning that if velocity is slow, banks would automatically lend more and create stable monetary conditions. Basically what central banks now do by having a bunch of burocrates look at statistics.</comment></comment></comment></comment></comment>


The Debris From the Mobile Photo Explosion - <AUTHOR> http://chrysbader.com/the-debris-from-the-mobile-photo-explosion

<comment><USER2> TOTALLY OFFTOPIC: I am so sick of articles like this that end with "Follow me on Twitter!" Why? Just because you wrote ONE article I found interesting? (And it was a good article)

I even looked at his Twitter and it's about as interesting (to me, I stress) as biting my toenail.

Imagine you're at a party and someone tells a joke. You laugh. He then walks up to you and goes "Hey you laughed at my joke, we should really be friends, please give me your phone number so I can text you when I want to!"

EDIT: I notice the text of the article has now been changed so that the "Follow Me" link is now separate. Before the edit the article said "I can't give it all away at once so be sure to Follow Me on Twitter" as the single finishing sentence.

EDIT2: Turns out the reason for this is explained to me here: <http://news.ycombinator.com/item?id=2392935>

<comment><USER3> I think you are making a big deal out of nothing.

There is no social pressure to actually follow them on twitter, no one will be offended if you totally ignore the sentence on the page.

Where as in your example it is socially awkward to refuse to give your number to some guy asking it because they want to be your friend.

<comment><USER2> True, my example in reality doesn't really match with an article.

And yes, I am probably making a big deal out of nothing. My reason for posting this comment was to see if others felt the same way, it appears they don't. My bad. I'll end with this: The people with large follower count's aren't the same ones that have to go asking for them.

<comment><USER3> No problem. Actually just in case chrysb's answer is too vague, the reason you see this pretty often is that Dustin Curtis ran an experiment a couple of years ago, which was heavily discussed on HN, in which he concluded that adding the sentence "You should follow me on twitter here" made him get the most click through rate.

[http://www.dustincurtis.com/you_should_follow_me_on_twitter....](http://www.dustincurtis.com/you_should_follow_me_on_twitter.html)

<comment><USER2> I hadn't seen this. Thanks for the link.

</comment></comment></comment></comment></comment><comment><USER4> So if you truly believe you have what it takes to disrupt the mobile-photo- sharing space why did you decide to join Google?</comment>


The Best Programming Advice I Ever Got (2012) - <AUTHOR> http://russolsen.com/articles/2012/08/09/the-best-programming-advice-i-ever-got.html <comment><USER5> 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_."

<comment><USER6> Yep, seeing so many people with reading comprehension problem here at HN is surprising.

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

</comment></comment></comment><comment><USER8> 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.

<comment><USER9> >>There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency..

I don't think anyone argues with that. It's just that sometimes some of the biggest impostors hide behind "boundaries".

>>This will continue to be a problem for the next 100 years until we figure out the right way to make good software.

A lot of people figured it out already.. but those are a minority and the field is fueled continually with poorly instructed people. The Business can't distinguish quickly between these two categories and often it does not even bother (good interviewing is hard or expensive) because (in Europe) it's not the software efficiency or other quality making the profit.

<comment><USER8> > A lot of people figured it out already..

You'll have to expand on this for me, because I find this claim shocking. Who figured it out, and what did they figure out?

<comment><USER9> Software is not the first industry to deal with systems complexity or large teams management but (in my part of the world at least) it's the first to expect engineering-like results from non-engineering workers and managers. There are developers who have noticed the similarities between creating/assembling/testing components & modules in other industries and software and borrowed practices before software had a name for them. It's just that these people are dispersed in a sea of devs tuned to Microsoft Framework Factory or busy building castles on Javascript Frameworks Sands.

<comment><USER10> What other industries should we learn from?

I know big construction projects often suffer from similar problems, and they don't seem to have figured it out.

<comment><USER9> Auto.

I find it quite strange that you are not aware about how much more reliable & secure is the product of the construction industry compared to software.

<comment><USER10> One-of-a-kind construction projects are notorious for cost overruns. It's ridiculous, just like enterprise software projects.

<comment><USER11> Same with civil engineering. They're building a new mass transit and it's 5 years late. Oh well.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> 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".

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

<comment><USER14> > Good organizations value good ideas, irrespective of who thought of them.

Ideas with only upside and no downsides may be trivially executed. The problems come with ideas where costs are certain and up-front, while benefits are medium-to-long term, and the transition may carry risks of its own. Big changes and ideas usually are disruptive and the best organizations may still struggle to pull them off.

In my experience even in good organizations people may have different assessment of what's a good idea precisely for these reasons, and getting people aligned behind such changes is what leadership is all about, and does need patient groundwork.

<comment><USER15> Even downside-less ideas bear some opportunity cost, no matter how trivial the change (or intangible the cost). I agree with everything else you said.

</comment></comment></comment></comment><comment><USER16> 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)

<comment><USER17> When you presented _what_ to your boss, exactly?

Did you suggest "I can make it better, faster, more stable...?" or did you go ahead and make the change and say "see?" Were you in a position where you should even have been thinking about this system?

I wonder what steps in this story you're leaving out?

<comment><USER18> +1. The fact that HR's involved strongly suggests that OP was messing with something he had no business to touch.

<comment><USER19> I don't understand this, or the linked article. Can someone explain to me what _possible_ reason there can be for responding with disciplinary action when someone proposes an improvement?

<comment><USER20> An easy reason that often gets left out of these stories is that someone spent weeks on a rewrite without authorization rather than working on burning priorities.

<comment><USER21> That's a real problem, and quite common. I think it's important, when confronting or correcting someone doing that (whether they're your employee, colleague, superior, team lead, etc.) to emphasize that they're not being punished or thought poorly of because of their ingenuity or initiative, but because they're wasting time and need to stick to the plan. Otherwise, initially headstrong but very capable people are often ground down before they have a chance to get used to the roadmapping/planning/etc. process at a company. This is especially true with new engineers.

I have no idea if the GP post you're replying to is someone rationalizing being in that position as being "disciplined for touching the wrong code", or whether something actually screwy was going on. I just wanted to mention that distinction because it was important to me when I started out (if people had come down on me for having ideas, instead of for wasting time, I'd be in a much less useful, happy, and capable place today).

</comment></comment></comment></comment></comment></comment><comment><USER22> 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.

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

</comment></comment><comment><USER24> 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.

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

</comment></comment><comment><USER25> 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.

<comment><USER18> 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?

<comment><USER26> You kick the hornets nest.

<comment><USER27> "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.

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

<comment><USER29> "I want your opinion on...." for me is a potential landmine. Such questions can be used to detect potential troublemakers.

[https://en.wikipedia.org/wiki/Hundred_Flowers_Campaign](https://en.wikipedia.org/wiki/Hundred_Flowers_Campaign)

In college 10 years+ ago, one of my roommates had a laptop with 500MB ram and took a 500MB ram chip from anther room mate's laptop to speed up a game he was playing.

He did this without the knowledge or permission of the laptop's owner who was sleeping and forgot to put it back.

Morning came, owner woke up to a laggy system. Discovered the cause and went straight to the culprit. Instead of an apology, he got insulted and reported to school authorities.

Culprit panicked and threw his own ram into another room mate's locker - <USER2> knowing that rams have brand names and serial numbers. The owner refused the found chip and after a search, found it in the culprit's laptop.

Case over right? Wrong!

We all got called up to an office and asked, "Who do you think took it?"

I naively answered with all the logical evidence. The "judge" accused me of slander. And warned me not to talk about it any longer or face disciplinary measures.

I later discovered that the culprit's father visited the official and our meeting's true purpose was a coverup.

In other words, be wary of higher-ups who ask for critique, advise, improvements, ideas...

<comment><USER30> I've always been wary of one-to-ones with the manager for the same reason. Is it ever good to talk about problems with a manager, especially regarding other people? It's like the prisoner's dilemma. I still don't know what's best for me to talk about in this setting.

<comment><USER31> If you have a good manager, yes, it can be. A good one will often have years more experience at navigating tricky social and political situations than you do and will be able to help you work through any difficulties you're having with coworkers.

Good managers are far rarer than good programmers, though.

A decent litmus test for whether your manager can help with these kinds of problems is whether they've been on lots of productive projects and whether everyone likes them.

If both things are true, they likely are quite good at navigating interpersonal conflicts and arriving at win-win outcomes. It's nigh-impossible to achieve both those outcomes in a large organization otherwise.

<comment><USER30> I've given up on the idea of good and bad people. I myself am good or bad depending on how it suits me. How could I do anything else?

From my experience a manager will choose the option he thinks is most beneficial to his continued employment in the company. This includes maximising team support/influence over for instance making a change in a product with measurable benefit to the company, a change which even he himself might agree is a good idea. Who could blame him? Any manager who didn't act in this way would surely be naive and idealistic.

Assuming this is true for managers, what benefit could possibly be had from complaining about other colleagues. It could only serve to reduce his trust in me, and increase his fear that I would do the same to him.

It is very difficult to balance things like team support, ensuring that I have interesting work to do and also ensuring continued employment. I have been too naive and idealistic, and now I am looking for a change of strategy.

It's all well and good to be aware of these realities, but much more difficult to put the conclusions into practice. Sometimes I think you're just born with it.

<comment><USER31> A further reply, beyond my simplistic defense of my use of the term "good manager":

It sounds like your "naive and idealistic" manager overlaps with my "good manager".

I will argue that a manager's principle responsibility is actually to be a maintainer of relationships. Her responsibility is to maintain her relationship with each of her direct reports first and foremost, next to help them maintain their relationships with each other, and finally to help them maintain relationships with the other employees/teams in the company as necessary.

Managers do have some logistical tasks they have to take care of, but mostly they "manage" humans, and that is fundamentally about keeping the relationships healthy and functional.

It sounds from your description like you've never had a good manager, and I'm sorry for that. The good ones definitely are idealistic, but they're not naive.

They are, as I mentioned earlier, in much shorter supply than good programmers. I've worked with far more decent programmers than I have decent managers (though since teams have N programmers to 1 manager on average, that may just be sampling bias).

I should also note that when I'm having trouble with a coworker, my default is a one-on-one attempt to resolve the issue(s) directly. If that fails (or in the rare case where I think it's a bad plan), I don't go _complain_ to my manager as such - I ask for their help in mediating conflict and negotiations. Because a good one focuses on relationship maintenance, they're often better at handling those situations than I am, and at helping the different members of the conflict understand each other and resolve their disagreements amicably.

Again - good ones are rare. I'm sorry you haven't gotten to experience one, from the sound of it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> 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.

</comment><comment><USER33> "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.

<comment><USER34> "People will sabotage things simply because they want the useful idea to be theirs."

Not just that, they will sabotage things if it makes them more profitable, which probably happens in thousands companies worldwide everyday.

1\. Get a contract.

2\. Sell some crappy software to the customer.

3\. Wait for them to ask for more speed.

4\. Complain it's their fault because their hardware is too old.

5\. Offer to either install new hardware or rewrite the software.

6\. Profit!

Guess what happens if someone makes the software perform optimally at step 2.

<comment><USER35> The way capitalism is supposed to work is you quit this job and open a shop which does the same thing as the existing company but doesn't artificially reduce speed, using that as a competitive advantage. The end result is that the first company is required to either adopt your strategy or fail, either solution leading the consumer to a better result.

<comment><USER36> Which is why the no-compete was invented...

<comment><USER35> I've read that those may be illegal or unenforceable according to the law. Check your jurisdiction.

</comment></comment></comment></comment></comment><comment><USER37> "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.)

<comment><USER38> I highly suggest you go back and re-read the text :)

</comment></comment><comment><USER39> 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.

<comment><USER40> 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

<comment><USER19> It's fine if you yourself want to take blame for some code you wrote. It's not fine if someone else wants to blame you for it. You wrote it, but someone else reviewed it, and (probably) still someone else tested it and yet someone else released it. It's a team effort.

</comment></comment></comment><comment><USER41> 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.

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

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

</comment></comment></comment><comment><USER43> 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?

<comment><USER44> This article literally made no sense

<comment><USER33> 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

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

</comment></comment></comment></comment><comment><USER46> 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.

</comment><comment><USER47> 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.

</comment><comment><USER48> 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.

</comment><comment><USER49> (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.

</comment><comment><USER50> 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.

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

</comment></comment><comment><USER52> 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.

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

</comment></comment><comment><USER53> 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.

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

</comment></comment><comment><USER55> 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.

</comment><comment><USER56> 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.

</comment><comment><USER57> 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.

</comment><comment><USER58> 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.

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

</comment></comment><comment><USER60> 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.

</comment><comment><USER61> 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.

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

</comment></comment><comment><USER63> 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.

</comment><comment><USER64> > 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."

</comment><comment><USER65> 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.

</comment><comment><USER24> I also believe smart people will do dumb things from time to time - <USER3> 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...

</comment><comment><USER66> 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.

<comment><USER30> What was your strategy in one-to-ones, and what would you have changed?

<comment><USER66> I suppose someone would say that I could have been more diplomatic, but someone needed to voice a differing opinion. Unfortunately, there was just no way -- diplomatically or otherwise -- I was going to be allowed to influence the culture or the process. Too many other people had built their careers on the back of a 30-year-old process. It was, as they say, entrenched. Sometimes, you just get dealt a bad hand, and you can't draw into a winner.

</comment></comment></comment><comment><USER67> > 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.

</comment><comment><USER68> 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.

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

</comment></comment><comment><USER70> 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.

<comment><USER71> The advice was so bad that it helped him not make that mistake. It was so bad it was good

</comment></comment><comment><USER42> 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.

</comment><comment><USER72> 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.

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

<comment><USER73> I think a common approach for IPC these days is to use named pipes. Chromium uses it and I've used it in one of my projects. You still have to deal with serialization and deserialization overhead but its usually pretty quick.

[https://www.chromium.org/developers/design- documents/inter-p...](https://www.chromium.org/developers/design- documents/inter-process-communication)

<comment><USER42> Funny you should bring that up as I'm just looking into that on Node.JS - <USER4> was your experience using pipes? Any warning signs / pot holes?

</comment></comment></comment></comment><comment><USER74> 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.

</comment><comment><USER75> People keep saying, "this is bad advice." But this an article on software corporate politics, with a facetious title.

</comment><comment><USER76> 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)

</comment><comment><USER77> The best programming advice I've gotten is from Tron: "fight for the users".

</comment><comment><USER78> 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.

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

<comment><USER78> Yup, my fault. I exploded too quickly, probably because recently had a similar discussion related to my own work.

</comment></comment></comment><comment><USER79> Some people just scan the content, I actually read the full article!

</comment><comment><USER80> it may not be good advice, but it gives you something to think about

<comment><USER81> Why is it not a good advice? Care to elaborate?

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

</comment></comment></comment><comment><USER83> 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.

</comment><comment><USER84> Anybody who agrees with this advice works in a shitty company with bad culture.

<comment><USER85> Downvoting not because I agree or disagree, but because I think the generalisation does not help the discussion.

</comment></comment><comment><USER86> "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" \- Upton Sinclair

</comment><comment><USER87> 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.

<comment><USER88> Your description of Hacker News makes it sound like it's a single person with a uniformly consistent opinion. It isn't.

<comment><USER89> It's a mob, reinforced by a system of rewards (upvotes), punishments (downvotes) and the politics of "karma".

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

</comment></comment></comment></comment><comment><USER90> 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.

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

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

</comment></comment></comment><comment><USER91> 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.

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

<comment><USER93> Those who I consider A players don't foster insecurities about their coding abilities in their egos.

<comment><USER92> Your thesis is pretty circular. You're not making a statement about A players. You are merely _defining_ them to be that way.

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

</comment></comment></comment></comment></comment><comment><USER95> 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*.

</comment><comment><USER96> Cultural fit is now my primary hiring consideration, and this is why. Good advice, quick read, 9/10\. Needs more dog

</comment><comment><USER97> 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.

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

</comment></comment><comment><USER99> 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.

<comment><USER100> Sounds like you didn't read the article :)

<comment><USER99> I did and I know the author says "actually it is a terrible advise" but he also continues to soften his statement

</comment></comment></comment><comment><USER101> 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.

<comment><USER102> Already more interesting than the whole clickbait blogspam i just reread (to make sure i didnt miss something the first time).</comment></comment>


A tutorial on active learning (2009) [pdf] - <AUTHOR> http://hunch.net/~active_learning/active_learning_icml09.pdf <comment><USER2> Great tutorial. I see active learning as a halfway house between supervised learning and reinforcement learning, because requesting labels is an action (as in RL), but of a very limited, predefined type.

A lot of problems which we initially model as supervised learning are in reality, in a live situation, more like active learning. Going the whole hog to RL may be unnecessary. But still, bandit-type models may be the right fully general setting.

These topics are very much in the air at the moment with a lot of new interest in bandit models and algorithms.

<comment><USER3> Are there decent recent implementations in python of these? Or tutorials of some sort?

<comment><USER4> The vowpal wabbit library provides an active learning setup [https://github.com/JohnLangford/vowpal_wabbit/wiki/active_le...](https://github.com/JohnLangford/vowpal_wabbit/wiki/active_learning.pdf)

I think you launch an active learning server, and the Python application interacts with it.

You may be able to run everything in Python [https://github.com/JohnLangford/vowpal_wabbit/tree/master/py...](https://github.com/JohnLangford/vowpal_wabbit/tree/master/python/examples).

Here's further description [https://github.com/JohnLangford/vowpal_wabbit/wiki/Command-l...](https://github.com/JohnLangford/vowpal_wabbit/wiki/Command- line-arguments#active-learning-options)

</comment></comment></comment><comment><USER5> Does anyone know what are the pros and cons between this and "online learning" ?

<comment><USER6> They are difficult to compare because they are intended to solve different problems. Typical learning algorithms have access to the entire, pre-labeled training set, which they can repeatedly iterate over.

Online learners are still trained using a completely-labeled data set, but they cannot access the entire data set at once. Instead, examples arrive one at a time and cannot be saved or replayed.

In active learning, the labeled data can be processed in batches, but the learner either has access to additional unlabeled data or can generate new examples itself. During training, it can request that some of these examples be labeled. Imagine asking a teacher for help.

Online learning makes sense when you have so much data that you cannot possibly store it all; active learning makes sense when you have less labeled data and the labeling step is expensive.

<comment><USER5> Sorry I have only just seen this. What a fantastic answer, thank you so much I completely get it now.</comment></comment></comment>


Ask HN: What websites do you read every morning? - <AUTHOR> I like to read Hacker News for tech news, Mangapanda for mangas, Dezeen and Dribbble for design, and sometimes NYT and WSJ, although they're mostly boring news.<p>I'd love to hear about new architecture/design websites that are worth checking out. <comment><USER2> HN, dribble, techcrunch, designmodo, stackoverflow, medium ... I find that flipboard on my phone introduces me to sites I wouldn't normally visit with content that is very top of mind for me. I tend to find myself re-visiting many of those sites afterwards

<comment><AUTHOR> I used Flipboard years ago, nice to see they're still around! Their website seems quite usable too.

</comment></comment><comment><USER3> HN, Lobsters, and a lot of independent blogs, all through my ttrss instance.</comment>


Ask YC: Anyone have a good implementation for multiple database support in Django? - <AUTHOR>

We're looking at Django, and while we love most of what we see in the 1.0 release, I'm a bit worried about the lack of multiple database support.
Has anyone here implemented this (basic usages for mysql master/slave(s) replication)? I'm not too concerned with sharding at the moment?
If you have done this, care to share ideas? Thoughts? Code?
Thanks all! <comment><USER2> Don't do this in Django. Just don't.

This should be done with a database proxy server. With MySQL, you can use MySQL Proxy and PostgreSQL has pgpool-II.

Yes, you could hack the Django code to solve your problem. Why do that when there is a very simple and tested product that already does that transparently? For me, supporting multiple databases in a web framework is akin to writing an HTTP server into your web framework. Maybe you should do it for testing purposes, but not for production.

<comment><USER3> There are reasons why mysql_replicated backend was created and used successfully in production instead of MySQL Proxy.

For example, MySQL Proxy knows nothing about transactions.

</comment></comment><comment><USER4> Just after DjangoCon there was a long discussion on django-dev about implementing multi-db support in the upcoming releases:

[http://groups.google.com/group/django- developers/browse_thre...](http://groups.google.com/group/django- developers/browse_thread/thread/9f0353fe0682b73)

Also, according to JKM, Django 1.0 _does_ suport multi-db, it's just undocumented and at a lower level:

[http://www.reddit.com/r/programming/comments/6zbos/django_10...](http://www.reddit.com/r/programming/comments/6zbos/django_10_release_candidate_now_available/c05a68v)

HTH.

<comment><USER4> Followup (better late than never, right?) --

A few days after my post, Eric Florenzano put up a how-to for multi-db support in Django:

[http://www.eflorenzano.com/blog/post/easy-multi-database- sup...](http://www.eflorenzano.com/blog/post/easy-multi-database-support- django/)

</comment></comment><comment><USER5> At DjangoCon I heard Pownce was doing that internally, you might want to ping them.

<comment><AUTHOR> Good idea. I'll send Leah an email...

</comment></comment><comment><USER3> MySQL master/slave replication is implemented:

<http://softwaremaniacs.org/soft/mysql_replicated/en/>

I'm not sure whether authors are here or not.

</comment><comment><USER6> Unless my memory fails me, in the "What Ponies do you want in Django?" session, this one came up quite a bit. Adrian and Jacob said that this was one of their top priorities, and suggested that it might make it into Django 1.1.

You could probably get a better response on the Django-users or Django-dev mailing lists.

</comment><comment><USER7> do you agree that good database design means good database implementation?

</comment><comment><USER8> bmk

<comment><USER8> i'm just trying to bookmark this article so that it appears under my comments. if anyone can suggest a better way (and bookmarking on the browser is not good enough, as i move around computers all day)

<comment><USER9> If you upvote this article, it will show up under "saved" in your member profile page.

<comment><USER8> ah thanks. is there a limit?</comment></comment></comment></comment>


GitHub Contest Winners - <AUTHOR> http://github.com/blog/489-github-contest-winners

<comment> brown9-2 <http://contest.github.com/> no longer explains what the contest actually is/was.

Can someone summarize?

<comment><USER2> The original description is here: <http://github.com/blog/466-the-2009-github- contest>

"Today we're announcing our 2009 GitHub Contest. Since the Netflix prize is now over, we figured you guys needed something to do. Here is your chance to contribute to the open source canon, make GitHub better, and possibly win some of the best prizes probably ever offered by a contest ... the problem is that we want to recommend repositories to you when you log into GitHub that you'll love...we figured perhaps you can do this better than we can. I extracted a dataset of all the repository watches in our database – close to half a million – and withheld a sample of them. I then created a test file listing the users I held watches back from. If you can write a program to analyze our dataset and best guess the watches we held back, you win our amazing prizes."

</comment></comment><comment><USER3> The contest winners are just awesome, their _right guesses_ achieved as high as 56.91%. See <http://contest.github.com/leaderboard>

</comment><comment><USER4> this is awesome. i recently tried to use GitHub for finding fun hacks, but i just couldn't find stuff very well. i'd like to find a community of hackers and startupy folks actually working on open source code, and i think this will help. more community connections would help, too.</comment>