Live data from Hacker News

How Completely Messed Up Practices Become Normal

danluu.com

231–240 of 267 posts

Re: How Completely Messed Up Practices Become Normal

#231
post #84

Speaking of completely messaged up... I had to add max-width, margin, and font-size styles before I could even attempt to read that page. For all that markup, there sure wasn't any attention payed to readability.

It's just plain HTML. That your browser doesn't display it readably is a good example of a completely messed up practice that people have come to believe is normal.

Please don't write off somebody's lack of attention to typography as a virtue and clever design. It's not. Browsers display it how they are told to display it. Maybe your system could use better fonts or line spacing by default, it's arguable, but it definitely would be stupid and unreasonable for browser to enforce less than maximal width for some of your div's if not told otherwise. If anything, they already enforce more than they should (that's why normalize.css exists).

And, by the way, it's not like there's no css at all in the source. It's just UX-ignorant, so to say.

Re: How Completely Messed Up Practices Become Normal

#232

Earlier quoted context omitted.

Not sure why you are getting so many replies disagreeing with you. Narrowly-defined roles are indeed the norm, even in the tech world. When I was an "individual contributor" I'd get frustrated with Worst Practices all the time, but was told that I was hired to write code not to change our infrastructure or suggest different product features or improve our testing practices--MANAGEMENT makes those decisions. But even…

I really disagree, strongly. It takes time and perseverance, but you can spread better ways of working.

The job would really need to be worth it to work against pushback from above.

Re: How Completely Messed Up Practices Become Normal

#233

Earlier quoted context omitted.

>You're not going to get fired or anything. You won't get fired, but what might happen is that you get a reputation for being "that guy". The "guy who's always complaining about unit tests". Or, "the guy who emphasizes process of 'agility'". What then happens is that the moment you speak up, management tunes out. They know what you're going to say. They know what you're asking for. And they've already told you no. At…

That depends entirely on how you do it. If you're upset that there's lousy test coverage, and you respond by complaining, that's not useful. If you respond by making the test suite run faster; creating better mocks; writing docs; making the test results more visible; teaching others how to write (better) tests... that's a different story. The trouble comes when you think that pointing to a problem is, in and of itsel…

    If you respond by making the test suite run faster; creating better mocks; 
    writing docs; making the test results more visible; teaching others how to 
    write (better) tests... that's a different story.
The trouble with that is that you only have a limited amount of time. If you're spending time writing tests (even if those tests save time in the long run), it's going to eat up time in the short run, which cements your reputation as a "troublemaker". Namely, your boss is going to wonder why you're taking extra time to write tests and create mocks when your peers are cranking ahead with features.

Yes, in theory, you get to say, "I told you so," when your peers' features are found to be bug-ridden pieces of crap that have to be reworked two or three times before they can be deployed. In practice, a boss whom you can say, "I told you so," to is a boss who'd have listened to you in the first place, making the whole exercise moot.

Re: How Completely Messed Up Practices Become Normal

#234

so many of these problems have the same root cause: we don't have an effective data driven reputation system. we use gameable heuristics to track social capial. when metrics for evaluation are flawed, people behave in ways that exploit the flaws even if they increase the likelihood of failure. "we are not rewarded for necessary grunt work as much as shiny advances", for example. That's a failure of the reputation sys…

In the past few years I have been building up good reputation at various stores both online and offline. It bothers me I cannot use that reputation. For example a major supermarket chain here in The Netherlands rolled out self scanning from 2006[1]. They do random checks at the checkout, and for many years now they know I never forget to scan something. This resulted in the amount of random checks going down for me. That should mean something, and I should be able to use this trust/karma elsewhere. All these companies building data on me, and I can't use it myself.

[1] https://www.youtube.com/watch?v=orjo0uNZFsk

Re: How Completely Messed Up Practices Become Normal

#235

Earlier quoted context omitted.

Everything is a system—and some systems are markets. A market is also a system. This is why it's important to know how to think in systems, and about psychology, statistics, variation, knowledge and everything else that influences systems—if you want to work in one. There's more to most systems than just incentives. They are a small part of what goes on.

Can you recommend some books on this? I have been trying to learn to think in systems, and find that to be the most useful skill to have.

If you want something more academic I recommend Measuring and Managing Performance in Organizations by Robert Austin [1]. There is a sample that is a pretty good introduction as well [2].

This was the only book worth reading when I was researching metrics for our team at work.

TL;DR: Don't use performance metrics for human beings. You almost certainly won't get what you want, and you'll probably get nasty side effects instead.

[1] http://www.amazon.com/Measuring-Managing-Performance-Organiz... [2] http://ptgmedia.pearsoncmg.com/images/9780133492071/samplepa...

Re: How Completely Messed Up Practices Become Normal

#236

Earlier quoted context omitted.

I actually come across this scenario quite often in retail outlets with poorly designed queue layouts (e.g. an H&M with with 2-4 registers behind a long counter and a single ad-hoc queue lined up in front of one of them). My reasoning is a little different (and a little more charitable I suppose in its generalization about human nature): I don't want to go step in front of the register with no one waiting in it becau…

Actually, scientifically, one queue for all registers is the superior solution. It reduces wait times for customers in general vs. one queue for each register (where one of the lines might get stuck for a long time). That's why you find banks and other places are all setup to have one queue used by all the clerks. The only real problem with H&M is that they haven't put stuff in the way of people forming multiple line…

Could average wait time be increased, as the distance from the front of the queue and the checkout in a single queue solution is longer, between 2 and 5 meters for a 4 checkout setup. This distance and walking the 2-5 meters to the checkout increases time total checkout time.

Re: How Completely Messed Up Practices Become Normal

#237
post #70

Earlier quoted context omitted.

So, characteristic X is so common that it does reveal the identity of company Y . Yet the author is surprised that many companies think X is normal?

There are two points I'd make: 1) Maybe yes. If the practices are really bad, it could be surprising that they're widespread and that people don't see a problem. 2) In general, when someone is pointing out something bad, saying "you're surprised?!" is counter-productive. You don't have to be surprised to call something out (I'm not surprised anymore how much our government spies on us, but it seems bad).

He writes it as if he is suggesting that 99% reliability is just bad, period. If his point was to say that 99% is bad in this specific use case, he should have made that more clear.

Re: How Completely Messed Up Practices Become Normal

#238
post #202

Most of what the author is complaining about boils down to business needs being more important than the needs of the engineering team. To be blunt, they're paying you to do a job, not to make the organization better. That's what they pay the leadership for. You want to be part of the leadership, work your way through the ranks or start your own business. My life got much, much easier once I learned to stop straining…

I would strongly disagree with you on both points -- that you're getting paid to do a job, and that you have to be paid to be a leader. For one, you don't become a leader by being paid to be a leader. That's how you end up as an incompetent manager. You become a leader by taking responsibility and doing what you can to ensure those responsibilities are taken care of. One of those responsibilities is to make your orga…

> that you're getting paid to do a job, and that you have to be paid to be a leader.

I did not mean these things the way you seem to think I meant them.

> What I'm getting paid for is to take my employers priorities and goals into consideration, and the strength of that consideration is proportional to the pay. If you don't pay me very much, my priorities will be considered first, and one of my priorities from a workplace is to be comfortable and happy within a good organization -- I will work to help and support my friends and coworkers.

I use a similar rubric to decide how to prioritize my time. My defined role comes first over everything else. Because I am accomplishing my role extremely efficiently my company sees me as a very good employee.

What I do with the rest of my time I consider to be my sole discretion. If I have an idea for something I'd like to build for the company, I'll go over it with my manager to gauge interest. Sometimes he's interested, sometimes he's not. I do not sweat lack of interest, I am an idea machine, I can come up with new ones.

I look at this surplus time as the primary benefit I receive from getting better over time at my job. I spend maybe a couple hours per week on defined roles, the surplus time I mostly re-invest back into my own capabilities. This helps both the company and me, but mostly me. The company simply isn't set up to be able to utilize my talents effectively.

Re: How Completely Messed Up Practices Become Normal

#239
post #53
post #37

Earlier quoted context omitted.

I think it corresponds to a lot of normal practice - even if you don't use @flaky, if one build fails and you run it again and it passes, what do you do? It's very possible to build tests that will pass sometimes if the code is correct and fail always if the code is wrong (e.g. test where there are race conditions in mock initialization, test that asserts that rows come out of a database in the same order they were p…

> if one build fails and you run it again and it passes, what do you do? I run it a third time, to start.

What do you do differently based on the outcome of that? The only scenario I can think of where that makes sense as a first step is if you're happy to ignore a 1-out-of-3 failure but feel the need to investigate a 2-out-of-3, which seems like an odd position to take.

Re: How Completely Messed Up Practices Become Normal

#240

Earlier quoted context omitted.

I've long held the theory that humans have differing degrees of rudeness because it breaks deadlocks like "after you", subdivide-or-finish the divisible food item, and who takes the last piece. (In places that were too polite, I have seen the last piece of a cake go stale uneaten.)

My friend and I used to have a serious case of "after you" deadlocks during our studies; we would get stuck in front of a door insisting the other goes through first. We eventually figured out a simple solution - if we found ourselves about to get stuck in another "after you" loop, we'd play rock-paper-scisors, and the loser had to go first. It quickly became almost a second nature for us, and it looked pretty confus…

I live by the rule that I never follow an "after you" with a "no, after you" without good reason. If they want demonstrate their politeness, why compete?
Post reply on HN