Hacker News Reader

> I occasionally meet people who get this - you know your domain and I know mine, and we can still talk to each other without othering.

This is so true. Many people are all too quick to show off their knowledge at someone else's expense, when instead it could be so much more: an opportunity to share something that will be completely new to that person; to share a passion and give someone a new perspective or idea or experience or whatever and give that person an insight into your domain. That's a wonderful thing and a privilege, and to waste it by instead using the opportunity to "one-up" someone else ("you've never heard of x?! [how stupid can you be?!]") is such a shame.

Relevant xkcd: http://xkcd.com/1053/

Reminds me of Mike Rowe's Dirty Jobs. It's not a show about "getting dirty", really--it's a show about being willing to learn from people who we don't traditionally think of as having much to teach.

This. I used to attribute it to douchiness, and sometimes it can be. Some people seem to feel the need to flaunt some kind of (mostly imaginary) superiority over others. That said, the curse of knowledge is also a good explanation. Some people just assume it is common knowledge because for them and others they talk with it is, so when they encounter someone that doesn't know it, it is easy to think "they must be an idiot". I have heard countless people express this exact sentiment (privately) when so and so doesn't know X, which is odd, since the set of all things one is not an expert in / knowledgeable about generally contains many different Xs.

It's laziness. Instead of recognizing that everyone got where they are now by a different path where they learned different things and appreciating the diversity of knowledge that creates, it's so much easier to say, you should have known that.

It's laziness, and it's also lack of empathy.

I have observed that it is far easier to naturally empathise with one who has many similarities to you rather than empathise with another who is radically different from you.

The latter actually requires conscious effort.

As you note, it's not easy. Nevertheless I believe it is effort well spent.

Nevertheless, it's natural. People expect short inferential distances[1]. In plain speak, we tend to intuitively assume that a piece of knowledge is either common knowledge, or easily explainable from common knowledge.

Like: "there's a tiger behind the bushes!". Not everyone knows that, since the tiger is difficult to spot. Everyone however knows what a tiger looks like, and what danger or source of food it represents. So, anyone who doesn't understand that sentence is an idiot.

Conversely, if someone who tells you that stars are Balls of Gas Burning Billions Miles away[2] is plain crazy… unless it's your which doctor, of course. That one knows ways you don't.

Except that the last two paragraphs are now bullshit. A few centuries ago (very recently, by evolutionary standards), our world became more complicated, and our instincts haven't quite caught up yet.

Laziness? Lack of empathy? Yeah, sure. But the effort required to expect the inferential distances we actually have to deal with is very real. Heck, I wouldn't be surprised if that last paragraph fell short for anyone who isn't familiar with the LessWrong Sequences[3]. Sorry.

[1]: http://wiki.lesswrong.com/wiki/Inferential_distance

[2]: https://www.youtube.com/watch?v=QZDk1cbKp7s

[3]: http://wiki.lesswrong.com/wiki/Sequences

It's not really either of these things. The curse of expertise in a field is you live and breathe stuff so deeply for so long that you forget what it's like to not be an expert in your field. You forget what non-experts, or bystanders, don't know, because it's hard to remember a time when you didn't know these things.

Computer people are notorious for having trouble explaining technical issues to computer-illiterates for this exact reason. It's not that their unempathetic - they are trying to explain so that the conversant understands, after all - but rather, they've been experts for so long, they forget which technical terms the conversant should or shouldn't know, or what does and doesn't need to be turned into an analogy. Overcoming this is a difficult skill.

Was it Einstein who said: "If you can't explain it simply, you don't understand it well enough"?

In any case, I agree that it's hard to explain computer stuff to non-computer people. That does not mean one can then be arrogant toward others.

I used to have that problem about half the time, and the other half of the time, the opposite-- where I'd assume they knew nothing about my field, and elide details they were actually interested in. So now I tend to ask lots of probing questions when explaining things, which seems to annoy people who just want me to get to the point! Surely there is another middle ground; the one I'm trying seems to not work.

> I feel like there is a bigger lesson in this story: I've got to stop making people feel silly for not getting my Star Wars references, and they've got to understand that there's no logical reason I'd know anything about the big names in fashion. I occasionally meet people who get this - you know your domain and I know mine, and we can still talk to each other without othering.

> And that skill - of being able to get along with your PM even though they "clearly don't know anything about code" - is one worth developing.

For anyone reading this looking into a career in software development, this is incredibly important. You might speak in code, but the people who you write code for will speak in their business. Odds are they're not going to look at your functioning code, but you're always going to need to understand their business if you want to both help it now and prepare for the future.

Absolutely this! I believe lacking the ability to communicate clearly and easily with "non-tech folk" is a significant barrier to many people trying to advance in their careers. Although this is more applicable to some paths than others, it's still an important skill.

An anecdote this brings to mind: I use to work with a lovely lady who managed the running of a large number of training courses. Whenever we were discussing software needs she was always apologising for not knowing or always understanding some of the things we were talking about.

It took me a few weeks of this to notice the pattern, but one day I just said, "You know what? I couldn't do you're job if my life depended on it. Please don't apologise for not knowing every little arcane thing about software development, it's a whole other skill set and expertise. That's why you hired me. I couldn't do what you do either."

She was so chuffed that I don't think her feed touched the ground for several days, and things proceeded apace with a lot less anxiety on her part.

I don't know, I also sometimes work as a programmer with fashion people and I just made some time to learn all the references. These days I work as a sort of fashion person for a chip manufacturer. I can hold a conversation about Haskell and I wear designer clothes to the office.

Do both. When you're being Othered, ask questions, listen, and adapt.

I think his point is that you should avoid mocking people who don't happen to know about your sub-culture.

What I like is when I tell people what I do and they realize it has a direct impact on the economic recovery of the United States, and then suddenly they feel silly for making fun of me for not using decorators in python. At that moment, they realize that their sub-culture, while enjoyable in itself, is not 42.

I liken it to this (perhaps badly translated, perhaps misappropriated) Chinese saying: "If your philosophy does not wash rice, I'm not interested."

In 2003, ESR wrote of this in "The Art of UNIX Programming" (which I have on my desk): http://catb.org/esr/writings/unix-koans/end-user.html

Maybe I missed this somewhere else in the thread but ... what do you do? I feel like I can't quite grok your comment without that context.

I write software automation for the team at a very large bank that processes repurchase requests for mortgage loans issued prior to 2008, aka toxic assets. Our work allows for clarity and resolution of the aftermath of the mortgage crisis. This has a direct impact in the ability of lenders to establish more accurate risk models and re-enter the mortgage lending business. This allows more funds to be available to mortgage-seekers, which theoretically lowers lending rates, allowing more people to refinance and purchase homes, which, arguably, is a major factor in the current economic recovery in the United States.

Does that help?

"allowing more people to refinance and purchase homes" is a big part of what got us into this mess.

That's an oversimplistic evaluation of the situation. We didn't get into the financial crisis simply because people bought homes, we got into it because banks found clever ways to issue mortgages to unqualified borrowers and pass the risk off on someone else.

They didn't find "clever ways to issue mortgages to unqualified borrowers". Simply put the US government guaranteed all the mortgages via Fannie Mae and Freddie Mac by law. The law passed by Congress in 1990s to increase number of homeowners among minorities was to guarantee all the bad loans by the Government. So from a banker perspective it didn't matter if a borrower will repay. Because if he doesn't than the tax payer will by the law. So, ultimately, it's government fault. And democracy fallacy that voters vote for idiotisms like this and then complain that "banks are greedy".

What he's referring to often is not quite mocking. "What, you don't know about ____?" It's more of a slight lack of empathy. I guess what I mean is get over yourself. When I'm in such situations, I get a little embarrassed, research whatever it was when I get home (or even right there with my phone), and try not to make the same mistake again. After a couple of months of exposure, you can be convincingly fluent in any sub-culture.

I'll agree though, people could always be more empathetic.

That's a good insight, and Star Wars is a good parallel. Not knowing a Hermes bag is probably akin to not knowing who George Lucas is. You're aware there are big name designer handbags out there, but never cared about the details. They're entry level bits of geekery, just in different fields.

it's not quite a good analogy. Hermes bag is related to fashion. Starwars in unrelated to computer science.

What you say logically makes sense, but I still don't believe it.

George Lucas is a household name, you would have to be pretty cut off from pop culture to not know who he is. I don't think that's quite an equal comparison to a brand of personal accessories.

Hermes is also a household name, believe it or not.

> because that pretentious image is something we want to overcome

If this is true, you're very subtle about it.

Hah.

Realize that wine is made, literally, by farm boys who spend the year picking and crushing grapes from the field. When you visit a winery you realize how far-removed the winemaking process, which is as down-and-dirty as any other farm work, is from its cultural air.

This is my experience with many wine professionals - people who procure, ship, or teach about wine for a living. There is a valid criticism of sommolier culture (which is only one facet of the industry) of propagating pretentiousness. But perhaps you need that air when selling a $300 bottle of wine, but you want to market yourself as "just a beverage" when selling a $10 bottle.

This reinforces my original point! There's more to $topic than your perception of it. There is more to fashion than "pretty people who are arrogant." There is more to IT than "Star Wars references." There is more to wine than "pretentious people with their cellars."

I found wine-types much easier to deal with once I learnt that there's a bunch of chemicals which cause tastes in wine, and there's a list of recognized names that people use to describe those tastes.

Still, I would strongly prefer any tasting sessions and reporting to be done double blind. With only a sub-editor knowing the name of the wine and putting that in at the last minute.

Wine-types are always much easier to deal with after your second glass.

The right approach to someone who says they have a particularly delicious bottle of wine is always "let's talk about it after I've had a couple glasses".

I think there may be some overexposure issues in some parts of wine as well: if you work in a popular place like the Napa Valley, it's easy to slip into the equivalent of the jaded tech-support worker who assumes everyone they talk to is going to be a total idiot, and isn't going to be very subtle about that assumption.

One way to avoid that is to go to places that aren't over-exposed. I did a short driving tour of Texas wineries a few years ago, and it was quite low-key and pleasant. People were pretty friendly and wanted to explain things. Some people were actual wine makers in the literal agricultural sense, but even those who weren't—mostly semi-retired people who decided to run a winery in their late-middle-age as kind of upper-middle-class dilettantes—were pretty friendly.

> I feel like there is a bigger lesson in this story: I've got to stop making people feel silly for not getting my Star Wars references, and they've got to understand that there's no logical reason I'd know anything about the big names in fashion

Not convinced by this: you work in the fashion industry. Sure, not knowing that in 2003 rustic/peasant chic was big (again!) would be acceptable, but not knowing the big names? Surely a certain amount of domain knowledge ought to be expected from you?

Okay, but I've met people who don't know anything that I don't apart from private gossip (and I'm not what you would call very intelligent) so I guess part of what she was trying to say is that people sometimes feel that they can't share anything with anyone around them because they're just not interested in anything meaningful or interesting. (all of that sounded pretentious and wrong)

I'm interested in working for a fashion company in tech, do you happen to work for one of the really great ones like Warby Parker? Any tips?

Hahaha, I am the lead engineer at a Brooklyn startup called Classic Specs. We do vintage-inspired eyewear, but our real business is that we work with other fashion brands who want to get into eyewear and design the frames, build their website, etc. We just launched eyewear for our first brand a few weeks ago, and we have several more in the pipeline for the rest of this year!

Send me a note if you are interesting in writing Python!

YHBT HAND

See you at Grey Bar.

Please consider pivoting into time travel.

Then can I tell my past self to buy three spare Big Bodhi frames (from LA Eyeworks), which are now discontinued. I can't even get spare/repair parts any more.

More seriously, I wish there was a better way to find glasses that work. I've got a big head with a big nose. Very few options. And the manufacturer dimensions (specs) aren't helpful. The bridge size should be pad to pad, not frame to frame.

My one great hope is to have a 3D head scanner coupled with custom built glasses, just for me.

http://pict.com/

These guys have recently pivoted into something a bit less fashion-specific but are still oriented on that industry. Drop me a line if you're interested, email is in my profile

The problem isn't PM's know jack about code. The problem is the set where a PM would even be required. That means there's a structural flaw in your process.

The idea of having a project manager is ridiculous. People _should_ manage themselves and take ownership of the project. Making the PM useless.

There's a place for PMs. If you're willing to step into shoes other than your own, start by reading PeopleWare [1]. And then dig into the origins of self-managing Scrum and have a read through Takeuchi and Nonaka's paper[2].

When you're done, I'd love to hear your thoughts on PMs, and why we're still making the same mistakes we made, and wrote books about, 30 years ago.

[1] http://www.amazon.com/dp/0932633439/

[2] http://hbr.org/product/new-new-product-development-game/an/8...

Works great on small projects, does not scale to very large projects. There is a non-zero amount of communication, scheduling and cross-team coordination that needs to happen. If you want developers to do it, that is fine, it just means less development time. If you have never met a good PM it is easy (but intellectually lazy) to write off the discipline. Once you have worked with a good PM you realize by off-loading that drudgery (well, drudgery from a dev perspective) everyone wins.

Agreed. However, I think a lot of the PM hating arises due to PMs who think that just because work flows through them to the customer, it's ok for them to take credit for it. I've dealt with inefficient PMs, and I can live with such people, but PMs who use their job as an expression of their inner narcissism are a different story. I think the latter motivates people to take up torches and pitchforks more than the former.

That's probably why, when building a skyscraper, modern construction practices dictate that all the subcontractors just "do their own thing" and sort out with each other when it's OK to put in walls, pipes, wiring and structural alterations.

The N^2 communication overhead is OK, because PMs are just useless overhead anyway.

I heard sometimes building projects fail because the PM only understood what was supposed to be happening and who was responsible for what, as opposed to having advanced plumbing, HVAC, electrical and structural engineering knowledge.

</sarcasm> (I don't usually resort to it... promise...)

That would be great if software were exactly analogous to building skyscrapers, and developers were idiot construction workers who do nothing but put the sheetrock and nails where they are asked.

(Note: I am not saying that construction workers are idiots, I am saying that programmers are not idiot-construction-workers.)

There is not just one way to organize a project.

Construction workers and programmers are both tradesmen, for most values of the word. I know you added a disclaimer already but I figured I'd just emphasize the point.

Code is the sheetrock and nails of software business.

PM is a team function, that of (in a nutshell) managing and tracking resources and tasks. It's also a field of study, and optionally a job title.

At the level of abstraction of PM, software is exactly analogous to building skyscrapers, building a rocket, producing a theatre production or capping deepwater horizon.

You are right that there is not just one way to organise a project. However, if the project is being organised at all, at least one person is doing project management.

It's just that the acting PM(s) may not be formally trained it in, or have "PM" as their job title. That's fine.

Programming is a lot closer to drafting a design for a building than actually constructing it, which is more akin to compiling.

That might work if the "project" is full spec'ed and defined as if it were the output of a Waterfall design process. I can't imagine that most projects are actually like that, though.

Having a good PM ensures that when ambiguities arise, they can be solved in a single way to allow those doing the coding to continue on unaffected.

Having 10 different people "take ownership" of a single project is itself a recipe for a different type of disaster.

Perhaps he's referring to a product manager - who if he's doing his job right is the guy with the deep domain expertise who spends his time talking to customers instead of dealing with project-management administrivia.

I do know lots of developers who don't think there should be product managers either - but in my experience they either have incompetent product managers or are working on a developer-centric product where they themselves have the domain expertise they need.

Speaking as a technical lead with a decade and a half of experience shipping web products solo and with small teams never exceeding 10 people, I can assure you that there very much is a place for a product manager in a great many products. In fact we just hired a product manager and it's a huge weight off my shoulders. Requiring all developers to be responsible for strategic thinking at all times is at odds with low-level focus needed to ship great software. A good PM is someone developers can trust to have the high level picture in mind at all times so the devs can focus on the necessary details.

I believe he's referring to project managers, not product managers. The latter certainly have a crucial role in understanding how the product fits into the market, and undertaking the kind of strategic thinking you're talking about. The role of the former, however, is usually to manage work scheduling and intra-team coordination, which, the OP is arguing, is something that programmers can generally handle on their own.

I used to have this attitude and then I realized that the vast majority of people cannot manage themselves.

If you have a small startup you can probably only hire people who can manage themselves. But as soon as you want to grow big, that becomes very very difficult.

Unless you're Valve, who apparently has been able to do it =)

How the project outputs will be produced (the supplier in PM lingo) is only one aspect of the project. Projects typically have an associated business interest, and users who will use the products produced by the product.

Certain resource roles (e.g. business analysts, UX specialists) can provide advice on the impact of decisions on the business case and the users, while others provide technical input, but project decisions typically cut across more than one of supplier / business / user interests, and it is in the interests of the business to ensure that someone can integrate the requirements of all three.

Having a project manager (or equivalent role such as an agile 'Scrum Master') is not incompatible with employees taking ownership of the project - decisions that only affect the supplier, or fall within ranges that the business / user is happy with can be taken by the suppliers. Often, the PM's role is to facilitate agreement between the different stakeholders.

It is possible for the PM role to be shared amongst the suppliers, but it is not usually a good idea for a big project, because being a PM is a specialist area in its own right hat developers have to learn separately from their specialist technical skills, and spreading the role across too many people can mean that context switch inefficiencies mean the PM role doesn't get carried out.