Silicon Beach: Los Angeles booms as startup hub - <AUTHOR> http://www.economist.com/news/business/21709564-cheaper-location-tech-companies-takes-los-angeles-booms-startup-hub <comment><USER2> While many of the established tech companies seem to have clustered around Santa Monica, the younger companies are mostly on the east side (downtown, East Hollywood, Silver Lake, etc), far from "Silicon Beach".

I have been in Los Angeles for 8 years and love it here. When my co-founder and I moved up to Mountain View to attend YC there was no question that we would come back to LA afterwards.

People think of LA as Hollywood/media-driven, but it's also one of the biggest manufacturing towns in the country, the biggest port, an important hub for science/technology (Caltech, JPL, SpaceX, Tesla, etc).

There is a lot of untapped potential for startups here. Not to mention that rent is about half the price.

<comment><USER3> I don't understand why these companies flock to that general area. Traffic is impenetrable from 6:00AM until sometimes 9:00PM. If you need the 405/105/10, etc you are hosed. It can take an hour to do ten miles.

It's horrific and it can't be good for recruiting. I know excellent engineers who have been offered jobs in that area and refused due to having to devote 3 to 5 hours a day stuck in traffic.

To me this means they would have access to a much larger talent pool if they strategically moved away from that impenetrable mess. Lived and worked in the area for years, it gets old.

<comment><USER4> Traffic is a lifestyle choice. There is indeed a small minority of people that have decided to sit in traffic 3 to 5 hours per day in order to live in a large and/or cheap house in the boonies somewhere. But that's crazy, and most people don't do this. You can also choose to not drive, and walk/bike/bus/train everywhere. LA is a real city and all that.

<comment><USER5> People love to say this. But it's total mythology.

For the vast majority of people living in LA, the bus is not an option. Your 30 minute commute will turn into a 3 hour slog.

Freedom of location is severely limited once you have a significant other or kids. School districts in LA are total garbage, and having a significant other means at least one of you is going to be commuting across town and sitting in traffic for 2 hours a day.

> most people don't do this

I guess all that traffic on the 10, 101, 110, 5, and 405 is just some collective hallucination. I was shocked when I found a number of people commuting to Irvine from such places as DTLA. That is, until I found people commuting to San Diego. Those are the rare ones (I hope). But there is a large portion of LA that commutes 2-3 hours a day. Anyone that commutes from the westside to east (or vice versa) is hitting 2 hours easy. I did it for a number of years. And by looking at Santa Monica Blvd, Wilshire, Olympic, etc. _many_ more people are doing the same.

I will never take a job in Santa Monica. Unless you live in SM, it's not worth it.

<comment><USER6> And rents in SM are comparable to anywhere on the peninsula, which negates any cost advantage anyone thinks they might have going south anyway.

This is why I'm sticking to supporting the startup scene around DC instead.

<comment><USER7> Wait what? D.C. Is incredibly expensive and also hasn't some of the worst traffic in the country.

I love D.C. But not sure I'm following your reasoning here....

<comment><USER6> Not as much with cities like Arlington and Tyson's Corner, which is where a lot of startup activity is taking place.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I've been living in West LA since 2008. It's certainly exploded recently in terms of startups as Google, Snapchat, Riot Games and SpaceX have expanded their presences.

The West LA area has always had a strong tech presence from the gaming, advertising, and defense industries though, going back many decades.

<comment><USER9> I was kicking around the idea of looking for a tech job in LA a while back. The names you mentioned seemed to be the ONLY ones worth pursuing. It's just not the same as San Francisco.

<comment><USER10> Yeah, I moved here about two years ago.

The other big difference between LA and SF is like, the penalty for not working close to where you live is absolutely brutal. Taking BART or the subway is moderately annoying, but driving from the Silver Lake to Venice every day is absolutely horrifying.

So in Venice you got Google and Snapchat, although apparently most of Google is getting moved down to Playa Vista, you got a handful of small startups, lots of VR companies led by people with media rather than technical backgrounds (maybe that's fine?), and that's about it.

Nearby you got EA in Playa del Rey (kill me), you got some old companies in Santa Monica and a couple more startups that don't seem interesting necessarily.

Even SpaceX is a pretty far cruise from the Santa Monica/Venice area, but there are a bunch more companies that hire engineers in that El Segundo area, but not necessarily ones that you would want to work at.

It's interesting, certainly, and I think the Snapchat IPO will lead to a lot of rich guys suddenly turning angel and so on. LA has basically never had any real exits until very recently (dollar shave, snapchat), which has limited the development of the ecosystem. Every old guy in LA is like "did you know I founded Myspace?" Based on my time in LA, I would have to estimate the number of founders of Myspace around 3-500. Also stamps dot com.

In summary, I would say LA is pretty much like New York City circa 2005.

The complete secret weapon of LA though is UCLA. The quality of graduates coming out of UCLA computer science is staggering, and from the hiring side, they're not competed for or recruited as heavily as say Stanford kids.

<comment><USER11> Worked in Tech in Los Angeles since 2000. Although lesser known as "tech" companies, there are several companies that have large investments in serious technology in LA:

Disney NBCU (specifically Fandango, parts of former M-Go) Ticketmaster/Live Nation eHarmony Edmunds.com The Honest Company

Other Tech companies left off the list: Hulu Yahoo (much smaller than before) AOL Hyperloop One and Faraday Future are coming up

<comment><USER9> Interesting, they're all media companies.

<comment><USER12> Yes. In LA almost all serious tech jobs are media company related.

<comment><USER13> Factual.com Location Data company with some serious tech chops.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I lived in LA for all my life and have worked at various places including DTLA, West LA (SM, Sawtelle), and even the SFV (Sherman Oaks). But I gotta say working at Venice (right by the beach) was truly an amazing experience. Coming to office with shorts and flip flops is a given, but heading out to the beach while getting some sun in the sands to get some Vitamin D while cooling off your head is pretty much priceless! Venice also has a pretty strong bike culture, which is pretty rare for LA standards, so you see a lot of people bike to work, which is awesome.

And some days, which is pretty much whenever we feel like it, we would just take our laptops and work right on the beach with the sun, with some towels spread out, chilling, swimming, and go for a swim and come back, then go back to work. It made me appreciate just how fun work can be and you don't have to sacrifice quality of your life just because you are working for a startup.

To me, working by the beach is seriously a no brainer, I mean more companies should be doing this! It is really hard to go back to working at an office building outside of it once you've experienced the freedom and lifestyle of being by the beach. Also, there is a big difference working close to the beach (like SM) and actually being ON the beach (Venice). I'll take the latter any day.

<comment><USER15> I don't understand how one can focus in such an environment.

I need headphones, ideally a lot of screen real estate and for nothing to be moving in my periphery.

</comment></comment><comment><USER16> As a Venice OG, I can say they've been ruining what used to make the place unique. Then again, having a Silicon Valley clone has helped my real estate valuation.

<comment><USER17> Question: if other groups are so proud of rejecting people in tech, why should people in tech be expected to be welcoming towards outsiders. The way I see it, if you get to have your cool hip location for yourself, we should get to have our trillion dollar industry for ourselves.

<comment><USER18> Once tech moves in, a place stops being cool and hip. Just like tech gutted San Francisco.

<comment><USER19> Tech built San Francisco.

</comment></comment></comment></comment><comment><USER20> I mod a techLA subreddit in case anyone wants to share news of interest to the community:

[https://www.reddit.com/r/TechLA/](https://www.reddit.com/r/TechLA/)

Some folks also tweet with the #techLA hashtag. (Keep in mind, if you tweet, the #LATech hashtag is reserved for a university in Ruston, Louisiana.)

<comment><USER21> Just joined thanks for the info!

</comment></comment><comment><USER22> Something must be going wrong up there if you're finding Santa Monica and environs cheap, haha.

<comment><USER23> LA and neighbors are somehow becoming the cheap west coast urban area. Seattle is now on par with LA, and Portland is quickly on track to overtake Seattle...

</comment></comment><comment><USER24> If anyone here wants to grab a $BEVERAGE sometime, hit me up. I just moved here and I'm looking for like minded people. Email is in my profile.

<comment><USER25> I too have recently moved to the area and I'm hiring a new team. Any Clojure devs in LA?

<comment><USER26> Me! Shipped one thing in production with clojure but haven't had a chance to do anymore. There were a few startups from LA at Clojure West.

</comment></comment></comment><comment><USER27> Curious synergy between this article and the San Jose Mercury story about SF Bay Area commuter traffic now being worse than LA's.

<comment><USER28> It's nowhere near as bad - I live in the Valley & have a nice 20-30 min commute into the office with otherwise pretty tame traffic around just about every day in my 2 1/2 years in the area. Meanwhile every visit I have had into LA had pretty bad traffic at many times you'd expect it to be normal, including after 10 am on a random Tuesday and ~1 pm on a Sunday.

There is far worse traffic in many of the worst traffic areas in the US than the Bay Area, I'm still confused as to why some try to perpetuate this myth on here.

<comment><USER29> Visitors say this. I don't buy it...I feel like LA natives avoid these kind of traffic disasters by avoiding peak times and knowing traffic patterns.

<comment><USER30> Is 1 pm on a Sunday a peak time for LA?

<comment><USER31> My sense is that 1pm Sunday is when lots of people are either a) just getting out of church or b) just waking up with a hangover. They then try to go somewhere they don't normally go to and don't know the directions to. Normal weekday traffic patterns go totally out the window and it's chaos.

<comment><USER22> Prime time at the beach.

<comment><USER29> Yep, Sunday afternoon in Venice was one of my peak traffic moments.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> Having lived in LA for over 2 years, I doubt the tech industry there would truly rival the valley some day. I am very happy with the emerging tech scene, but when I was in LA, it was all about "the industry" \- which was a reference to Hollywood. Many conversations revolved around what it was like to work in the industry or who knows whom from the industry.

The other issue with the tech industry in LA would be that it will run geeks and nerds out of town. Appearance and looks are far more important in LA than it will be in SF.

<comment><USER22> "The Valley" in LA means the San Fernando Valley, think "Valley Girls."

</comment></comment><comment><USER33> Can we please stop with the Silicon Beach nonsense? The only people who use it in earnest are the yuppies at networking events. It's like calling Seattle the Silicon Forest.

</comment><comment><USER34> Silicon Alley[1], Beach[2], Desert[3], Forest[4], Gulf[5], Peach[6], Prairie[7], Taiga[8], Wadi[9].

To paraphrase a Game of Thrones put-down, if you have to call yourself "Silicon" to say you are like the Valley, then you aren't like the Valley.

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

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

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

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

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

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

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

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

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

<comment><USER35> Don't forget Silicon Slopes: [https://en.wikipedia.org/wiki/Silicon_Slopes](https://en.wikipedia.org/wiki/Silicon_Slopes)

Found the whole list on Wikipedia too: [https://en.wikipedia.org/wiki/List_of_places_with_%22Silicon...](https://en.wikipedia.org/wiki/List_of_places_with_%22Silicon%22_names)

<comment><USER36> funny Seattle only has "Silicon Canal" for the bit around Fremont where Google, Adobe, Tableau, GeekWire, Facebook, etc. have offices. you'd think between Amazon, Microsoft, Expedia, Zillow, Redfin, and the countless other tech companies with headquarters or satellite offices in the area that some nickname would have sprung up for the whole region. "Silicon Isthmus" or something.

maybe we're still riding the "Jet City" thing from when Boeing was here?

<comment><USER37> I prefer "Cloud City"

<comment><USER38> I'm pretty sure my little section of SOMA was called the Cloud Corridor before you guys were being called Cloud City, Joe ;).

</comment></comment></comment></comment></comment><comment><USER39> How unfortunate, hopefully the culture in the city doesn't go stale and homogeneous.

<comment><USER9> My friends who are California natives say LA is what SF was like before tech ruined it. Venice Beach is so chill and laid back, I really loved the culture there. Sad to see it vanishing there, too, and I really empathize with the fact that I'm part of the problem.

<comment><USER40> Your friends just sound like bitter assholes tbh. LA is a sprawling metropolis that makes absolutely no sense to compare to San Francisco. LA as a whole isn't 'like' anything because it has such wildly diverse areas. Do you think Santa Monica has a similar feel to Compton or Hollywood?

<comment><USER9> See, we actually do agree here, given that the SF Bay Area has lost its diversity and become so monolithic that you can no longer draw a comparison anymore.

</comment></comment></comment></comment><comment><USER41> That tells you something about what a clusterf*^k the Bay Area must be at this point if they think LA is attractive.</comment>


Eppenberg SBB Railway Tunnel – From installation to the breakthrough - <AUTHOR> https://www.youtube.com/watch?v=TTnFpKCAJtE <comment><AUTHOR> When I am frustrated by broken software and the general state of our IT industry, watching this video and what they accomplish in tunnel boring restores my faith in humanity. The amount of people involved, the precision, planning and execution are excellent</comment>


Simple description of popular open source licenses - <AUTHOR> http://pbagwl.com/post/5078147450/description-of-popular-software-licenses

<comment><USER2> I would like to see the wording of "Companies that distribute software cannot bring a legal claim against the software users" changed to a non-negative, "Companies that distribute software CAN bring a legal claim against the software users." It may seem pedantic, but the "Yes/No" arrows are ambiguous because if you answer the "question" with arrows, it would be "Yes, companies that distribute... cannot bring a legal action..." just sounds confusing.

Otherwise, awesome infographic.

</comment><comment><USER3> While LGPL and MPL are similar, there are differences and they should not be lumped together.

The biggest difference is that MPL allows static linking while LGPL does not. While in the past this wasn't a big deal, it is important for iOS development since you cannot dynamically link to libraries in iOS apps.

</comment><comment><USER4> WTFPL and other similar licenses seem to belong with the MIT license, but they're just floating off on their own.

<comment><USER5> Agreed. Flowcharts also assume that there is some sort of decision hierarchy that will be followed. Who's to say that derivative works are the most important thing here? Maybe some company/person needs to cover their ass in another way first.

This list is less a description and more a taxonomy, which means that it's not valuable to anyone new to these licenses. When starting a project, it's best to convey the benefits of each license in a straightforward manner to whoever the decision maker is. A tree like this will only confuse and ensure that an ill-fitting license is chosen from the onset.

Simple, written definitions are therefore best, and are similar to the article here: <http://simple.wikipedia.org/wiki/GPL>

<comment><USER6> This would matter if there were more than 12 licenses. As it stands, it takes less than a minute to look at every possibility on the chart.

<comment><USER7> Well, the chart does not include much. For example, i found the ISC licence now. It seems to be equivalent to MIT, but has simpler text.

<http://www.isc.org/software/license>

</comment></comment></comment></comment><comment><USER8> _Code under another license can be freely linked and distributed with software._

This misrepresents the LGPL. LGPL doesn't allow static linking. It's not a small detail.

<comment><USER9> It does allow static linking---from section 4, paragraph d:

"d) Do one of the following:

"0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

"1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."

You just have to allow relinking in some form. Admittedly, this is easier with dynamic linking, but the LGPL doesn't restrict static linking per se.

<comment><USER8> Yes. It's like saying humans can fly, if thrown out of an airplane. Asking developers to distribute all the object files of their proprietary software is not realistic. And even if one developer accepts that condition, most developers won't, sending any open source software that she releases and that depends on an LGPL library directly into oblivion (again, in a context where dynamic linking is not possible).

</comment></comment></comment><comment><USER10> I always think it's unfortunate that posts like this leave out the horror that is Affero GPL[1].

The gist: web apps that use anything licensed under Affero GPL to _serve pages_ would be subject to the copyleft provisions of the license.

[1]: <http://en.wikipedia.org/wiki/Affero_General_Public_License>

<comment><USER11> And why, exactly, is that a horror?

The whole _point_ of the GPL is that if you use software, you deserve to have access to its source code. It originated in an era where there was little software in use that lived on someone else's servers which you never touched. And so ignoring that didn't affect the GPL's intended purpose.

With the rise of the web, it is now very common to be dependent on software that you only interact with remotely, through a website. The Affero GPL returns the original intent of the GPL. It puts websites on the same grounds with respect to the GPL that native applications have always been. Every argument you can come up with against the Affero GPL was already made about the original GPL.

If you don't like the intent of the GPL, don't apply it to things that you create. If you don't like the effect of the GPL, don't use GPLed code in your software. In the meantime don't bother complaining that it does exactly what it was intended to do.

</comment></comment><comment><USER12> funny that even "I don't care" has many implementations: WTFPL, <http://unlicense.org/>, CC0 (which wasn't invented for code), etc.

</comment><comment><USER13> This "simple description" at a glance appears to be just plain wrong. For example, the GPL license is compatible with ASL2.o</comment>


An Open Letter to Peldi Guilizzoni of Balsamiq - <AUTHOR> http://blog.quipol.com/post/12769866834/an-open-letter-to-peldi-guilizzoni-of-balsamiq <comment><USER2> I admit that I'm relieved that this open letter was not another public bashing. I love stories like this and, most importantly, I really love balsamiq. I didn't know anything about its creator/founder, but I'm glad he's as upstanding as the product he produces.

<comment><USER3> Peldi is a class act.

What's admirable here is not that he provided a free $79 license (that's relatively easy). What's admirable is that he responded personally, and irrationally selflessly.

Knowing Peldi, I know exactly why he does such things. In every software entrepreneur, he sees a peer and the potential for someone to build something great.

<comment><AUTHOR> :) He has a long-term vision, which is a trait that you don't see a ton of in a quarter-by-quarter society. I think that's changing, though.

</comment></comment></comment><comment><USER4> I met Peldi a couple of years ago at SXSW and was impressed by his humility. He's personally answered all of the emails I've sent him. Usually really quickly. When I first me him, I was an Omnigraffle user and had paid for Michael Angeles (Konigi)'s UX templates for Omnigraffle.

Peldi hired Mike as the UX Director for Balsamiq. At that point, I knew I should make the switch.

When I heard they were building myBalsamiq, a collaborative tool for wireframes, they solved the problem of versioning wireframes and centralizing the repository. This is a team truly committed to building an opinionated wireframing product. Yes you have to make trade-offs. But you'll build better products. It's worth it.

It's one of very few products I bring up in conversation. Balsamiq is a company of which I'm proud to be a customer. Balsamiq, for everything your team has done, and everything you will do for the UX community and software development, I thank you.

<comment><AUTHOR> Well said. The whole team has been pure class every time I've digitally interacted with them. That's not an easy feat considering that everyone has bad days.

</comment></comment><comment><USER5> About a year ago my wife and I were working on a project together and we had a complete miscommunication about some feature that I was supposed to build. At the time I was doing all of our UI design, so I was the only one who had a copy of Balsamiq. The entire miscommunication could have been avoided if my wife had been able to mockup a couple of wireframes really quickly. She emailed Balsamiq, told them what happened, and asked if they would give us a discount on a second license. They gave us a free one instead. What an amazing team. Peldi's interview on Mixergy was one of my all-time favorite - <http://mixergy.com/balsamiq-peldi-guilizzoni-interview/>

BTW, I've seen several other sites that do social polling like this. I've never had any interest in using any of them, but I just went through every one of your polls. Fantastic design, it sucked me right in. Congrats on your launch!

<comment><AUTHOR> Thank you for the kind words about Quipol and the great story. I think we're seeing a trend here: if you give, people don't forget (and they pay it forward). Thank you, August!

</comment></comment><comment><USER6> I'm also a huge fan of Peldi - I love that he personally responds to emails and tweets and seems to actually give a shit about his customers. (Very refreshing after my stint at Google, which is severely lacking in that department :).

I also love Balsamiq - I use it both to prototype web/mobile apps and also for diagrams in presentations (<http://client-side-apis.appspot.com/>). The sketchy feel makes the prototypes feel more flexible, perfect for encouraging iteration.

I've been using myBalsamiq (the online version) for a while, and though it is Flash-based, and Flash is the devil, it works pretty well and I recommend it.

<comment><AUTHOR> Agreed all the way. The fact that you can email him and expect to hear back is too cool.

I've used Balsamiq for design projects, too. It just feels authentic.

</comment></comment><comment><USER7> Congrats on launching!

One small UI suggestion: put thumbs-up on the right and thumbs-down on the left. About 90% of the population is right handed and the word "sinister" originates from the Latin word for "left" [1]. Generally speaking, people associate the right side with good and the left side with bad. :)

[1] <http://en.wikipedia.org/wiki/Left-handedness>

<comment><AUTHOR> I've never heard the sinister meaning! Truth be told, we originally had the buttons reversed, but our customer development group consistently said it should be on the left. I have two theories for why:

My far out theory: Microsoft's dialog boxes always had the OK button on the left and Cancel on the right.

My sane theory: People read left to right, and they think "Yes or No." You rarely hear people say, "No or Yes."

<comment><AUTHOR> Oh, forgot one important thing: thank you for the kind words!

</comment></comment></comment><comment><USER8> Peldi is a great guy and Balsamiq is turning into a reference example on how to run a successful software business with integrity.

<comment><AUTHOR> Couldn't agree more. He makes it look easy.

</comment></comment><comment><AUTHOR> Hey all: I'm shocked by (and so appreciative of) the responses to this. Thanks for directing the much-deserved love toward Peldi, too! He's seriously my entrepreneurial hero.

</comment><comment><USER9> Aww shucks everyone, what a nice day to start the week. :)

OK, back to work! :)

Peldi

<comment><AUTHOR> :) Good luck!

</comment></comment><comment><USER10> I had a very similar experience with the Balsamiq crew. Early on I didn't have much to offer other than this budding Web testing service I was working on. As it turns out, they have a Web site and saw value in it and accepted my barter offer. I was completely shocked. The outcome was two fortified notions: it never hurts to ask and the Balsamiq guys are great.

<comment><AUTHOR> Yeah, the Do-Gooder notion was the thing that gave the the guts to even consider asking for something free. I think every company should have a Do- Gooder policy!

</comment></comment><comment><USER11> Great design. And it's nice to take time to thanks Peldi.

But why would a mockup software be so important to one's business?

Anyone could do a mockup with PowerPoint and yet I see mockup softwares popping up every week.

I respect Peldi for everything he has done in the entrepreneur community so I am not after him, I just feel I am missing out on something.

Thanks.

<comment><USER12> Mockups with PowerPoint are just not effective. Also, with apps that are more than just a couple pages, it quickly becomes cumbersome, even inside Photoshop or Illustrator.

With Balsamiq, you're able to think out loud and get more decisions made faster. Also, when you're working in a team and not 100% clear on what the solution you're building will end up becoming, it helps a lot with the communication.

Lastly, when you know what you're building, it takes a lot less time building it (at least for me it does.)

For example, we're about to build and launch a new product in the next couple weeks. By spending some time creating a wireframe prototype that the whole team can click around in ([https://volcanic.mybalsamiq.com/projects/customerloyalty/gri...](https://volcanic.mybalsamiq.com/projects/customerloyalty/grid)) we've been able to tweak what we want version 1 to be and narrow our scope quiet a bit to just the essentials.

I'd say wireframing, particularly with myBalsamiq, is very beneficial for web app development.

<comment><AUTHOR> Agreed. It helped me get Quipol pared down to just the must-haves in a very short time.

</comment></comment></comment><comment><USER13> Balsamiq is a good piece of software but I wouldn't put an effort to ask for a free copy of especially when I'm broke. Instead, I would rather use pen and paper.

If you feel you really really need the software to aid you in building your product then be a good customer and pay the license.

<comment><AUTHOR> Fair enough!

</comment></comment><comment><USER14> Congrats on the launch of Quipol!

Peldi started Balsamiq on nights and weekends, and now it's supporting half a dozen families. If that is not a real, tangible definition of a successful business is, I don't know what is.

Also, one of my favorite product names (shows the founder's background/personality).

<comment><AUTHOR> Yeah, I think that's the coolest thing about starting a tech business: you get the opportunity to support other people through both software and jobs. Peldi gets to go home at night and know that people are eating well because of a little idea that he turned into a great product.

</comment></comment><comment><USER15> This was a heartwarming story. Peldi sets a very high standard. I am excited to check out Quipol and use it.

<comment><AUTHOR> Completely agreed! Thank you for checking out Quipol :)

</comment></comment><comment><USER16> What a beautiful design on your site Quipol!

<comment><AUTHOR> Thank you! The early design of it can be found here: <http://blog.quipol.com/post/9624246432/prototyping>

My how things change!

</comment></comment><comment><USER17> This was a nice read, congrats to the author, and I always had a good feeling about the balsamiq creator.

<comment><AUTHOR> Thank you!

</comment></comment><comment><USER18> Sounds like a great story and a great guy.

But damn, I hate to see anything popularize AIR apps. Also consider OmniGraffle if you are looking for prototyping :)

Really don't want to rain on parades. Just want to make sure people know there are (IMO better) alternatives.

<comment><USER19> OmniGraffle isn't remotely as good at what Balsamiq does as Balsamiq itself. You might just as productively compare Adobe InDesign to Emacs.

<comment><USER18> I disagree. You can make and download and share stencils. There are great sets for different UI systems...

What am I missing?

<comment><USER19> This is the kind of comment you write when you've never actually used Balsamiq. I use and adore OmniGraffle (though I'm back to doing more technical illustration in Illustrator), and it is nothing like Balsamiq. It's not a difference of stencils or downloading or anything like that; they are simply very different applications altogether.

<comment><USER18> You don't know that.

I have used both. Though I only used the Flash version of Balsamiq, since my AIR installation refused to work.

<comment><USER19> I'm inclined not to believe you, if you need someone to argue with you that OmniGraffle has a similar approach to UI mockups.

Perhaps you downloaded it, dragged some things onto a canvas, and then never picked it up again. You missed a lot of great stuff. It's a thoughtfully designed (and very nerdy) app.</comment></comment></comment></comment></comment></comment>


How Hibernate Almost Ruined My Career - <AUTHOR> http://ggajos.com/how-hibernate-ruined-my-career/ <comment><USER2> The idea of "use Hibernate so you don't have to write SQL" while being objectively wrong, also hits on an antipattern I've noticed over and over again. The "\- so you don't have to -" anti pattern. Such as "we will configire this in xml so you don't have to write more code". Or "put some code in the database so you don't have to do a deployment process to make changes."

You always end up having to do the thing you were trying to avoid plus deal with the middleman abstraction you introduced trying to avoid it. Anytime I hear someone say "\- so you don't have to -" I wince and anticipate upcoming technical debt.

<comment><USER3> I'm not sure "so you don't have to" is the problem; it's that do X so you don't have to do Y is only helpful if X costs less than Y.

So use an ORM so you don't have to write and maintain SQL is bad, because writing and maintaining SQL is not expensive, but using an ORM is (at least in my experience: I've run into many cases where the ORM generates pathological queries that aren't fixable without throwing away all the code that was calling into the ORM; where a bad query in plain SQL is usually readily accessible).

On the other hand, use Erlang's hot code loading so you don't have to restart nodes to update code is not bad: hot code loading isn't super expensive (you have to do a little bit of planning for some types of changes), but restarting nodes is (first you have to move all the traffic, then you have to actually restart it, then you have to move the traffic back).

<comment><USER4> my take on hibernate, or ORMs in general, is really to abstract the _differences_ between vendors' sql implementation (including creation, and upgrading of schema). If you have to ship a product that have to work under all database vendors, an ORM like hibernate is the only choice - otherwise, you'd have to write separate scripts for each vendor, and that just makes the job at least 5x harder (or more, assuming you go for more vendors).

Not kwowing how to write proper SQL is a problem, and ORM won't solve that for you.

<comment><USER5> Doesn't seem like that common of a problem to have to ship code that has to work with different databases. But if I ever had to do such a thing I would just stick with ANSI SQL.

<comment><USER6> There's no such thing as ANSI SQL for real world applications on real world databases. Even something as simple as limiting the number of rows returned varies widely (TOP vs LIMIT vs rownum).

The correct answer is to forget about database independence and double down on just one[1] so you can use it to its full potential.

[1]: _And obviously it should be Postgres..._

<comment><USER7> and you missed "fetch first" which is the ANSI thing

</comment></comment></comment></comment></comment></comment><comment><USER8> Hibernate didn't ruin his career, SQL did. If he'd actually worked with Hibernate, rather than abandoning it for SQL at the first opportunity, he would have got a system that performed well for less effort, was database- independent (which makes it easier to e.g. have a better test suite, because you have a wealth of in-memory options for testing so you can afford to run more tests on each build) and was more maintainable. All too often I've seen it play out like this:

1\. Hibernate system working great

2\. Idiot notices that one of their queries is slow, blames Hibernate

3\. Idiot writes their query in raw SQL because hurr durr SQL is faster than Hibernate. (Bonus points for never benchmarking anything. Extra bonus points for switching to SQL and adding an index at the same time, observing this makes it faster, and deciding it's probably the switch to SQL that made the difference)

4\. Idiot notices their query is getting results that are inconsistent with recent changes that went via Hibernate.

5\. Rather than making any effort to fix this properly, idiot disables all caching in Hibernate. There, I fixed it.

6\. Idiot notices that Hibernate queries are now slow (gee, ya think?) and uses this as a reason to migrate all other queries to raw SQL.

Hibernate doesn't save you from having to design a good data model, nor from having to tune it for performance. You can't turn off your brain when using Hibernate, you do still have to figure out which entities own which side of their relationships, and when you get to a scale where performance becomes an issue you do have to spend a bit of time doing performance tuning, _just as you do when using SQL_. It does genuinely simplify a lot of things and save you from writing a lot of boilerplate. But if you spend a week tuning your SQL query and no time tuning your Hibernate query and use that as your benchmark, no shit the SQL will be faster, and if your first resort whenever you hit a slow query is going to be to bypass Hibernate rather than working with it then yeah you probably shouldn't be using Hibernate in the first place.

<comment><USER9> By reading this I have the feeling it's like saying "You have to know every technical part of your car in detail before you drive it". I'm thinking that in a complex project you don't have time to do that... some people just want to drive but not think about it too much. Seems Hibernate has too many pitfalls if you are in hurry to develop something and you are not doing performance measuring (and beeing able to tune it) in every step of development.

So don't use Hibernate if you are not an Hibernate expert?!

<comment><USER8> For a fixed amount of effort, you'll do better with Hibernate than without. But if you're an SQL expert and a Hibernate novice you should probably stick to SQL, or else accept that you're going to have to take some time learning (just as if you were to start using e.g. Cassandra you wouldn't expect to immediately be as effective with it as you were with SQL).

And don't expect to mix SQL and Hibernate operations freely in the same code, any more than you'd expect to freely mix e.g. encoding-aware String operations and manipulation of the underlying bytes. It's possible to make good use of the fact that Hibernate is implemented in SQL, CQRS-style: use Hibernate for your "live" operations in your application, use SQL for reporting/aggregation and ad-hoc querying, playing to both their strengths. But don't try to interleave them, especially in the same transaction.

</comment></comment></comment><comment><USER10> > We're always struggling with lazy/eager fetching problems. At one point, we > decided to do everything eagerly, but it seems suboptimal, and besides, > sometimes it's not possible to access some fields because there is no > session, or something like that. Is that normal?

WTF. No concept of the N+1 problem.

> We're still struggling with which database engine to use for the final > deployment. I thought Hibernate was portable, but we have some native > queries that use some MS SQL magic, and we'd actually like to go with MySQL > in the production

WTF. Why are you developing against MS-SQL then?

> Sometimes we spend days looking for errors. It seems like we have to analyze > Hibernate-generated SQL because we have no idea why it's not working as > expected and it's producing unexpected results.

WTF. If you don't understand your ORM you won't understand the queries it generates.

> Can you help me understand how Hibernate cache works? I just don't get it. > There are some first/second level caches. What is this all about?

WTF. No concept of using transactions.

I've used ORMs longer than the term ORM existed. I've never once thought it as a replacement for SQL. It's a supplemental tool.

<comment><USER11> > WTF. No concept of the N+1 problem.

Huh? I feel like I'm missing something. Eager loading, done right, is how you avoid the N+1 problem.

In ActiveRecord, _Customer.includes(:orders).where(customer_name: 'Fred')_ would execute, at most, two queries even if there are many Freds with many orders.

The only real ORMs I've used are ActiveRecord and a tiny bit of EntityFramework.

Is this kind of eager loading not common? Or did I misunderstand your remark?

<comment><USER10> The N+1 problem is caused by lazy loading. It's when you have an entity, e.g. Customer which has a property Orders with a foreign key relationship to Customer. The property is not materialized until it's accessed, causing an extra (N+1) query to be run.

This can be avoided with something like e.g. EntityFramework which is based on the IQueryable interface and expression trees. In EF it would be

        var query = DbContext.Customers.Include( c => c.Orders).Where( c => c.customer_name == "Fred");

The value of query is an expression until it is iterated or converted to e.g. .ToList(); The expression is built using the relationships defined in the mapping which allows EF to use a proper SQL join, avoiding two queries and the N+1 problem.

</comment></comment></comment><comment><USER12> I used to think I needed to learn an ORM to be able to write maintainable software.

However time taught me writing maintainable SQL with good migration story is way better. ORMs make porting queries to another project that needs to use the same database difficult. It's less obvious what is really happening and the performance usually isn't as good as hand written SQL. Hand written SQL also means fine grained control over prepared queries, access to vendor specific features (advisory locks, LISTEN/NOTIFY, triggers), materialised views etc.

You could argue these should be domain of DBA but in my opinion all devs should atleast know SQL at this level.

<comment><USER13> ORMs also increase the cost of change, thwarting code evolution / refactoring.

<comment><USER14> I'd definitely disagree there. It's a lot easier to refactor code than to refactor a multitude of sql statements.

<comment><USER13> How about when refactoring your database? How does that impact your mappings, DAOs, testing regiment?

</comment></comment></comment></comment><comment><USER15> Straw man script about what happens when you "blindly use Hibernate." I suppose there are lots of people in the world who do that. I would think that Hibernate isn't the sole problem in those cases.

<comment><USER16> 'How selecting a tool without understanding if it was the right tool to use was the wrong decision'

<comment><USER17> "this just works, nobody needs to know theorical stuff anymore"

</comment></comment></comment><comment><USER18> I suggest a better title for that article: "How I blame technology X of almost ruining my career when I am the only one to blame because I did not understand what I was doing"

<comment><USER2> I sort of sympathize though because there is overwhelming pressure to use the latest fad in software engineering. At one point Hibernate was the cool new thing, so cool that even non technical managers heard of it. And you really don't want to have to explain to ever busybody non programmer why you aren't using the cool new thing they are reading about. Even if you do explain yourself well, there is a chance they won't understand and will just assume you are incompetent or behind the times for not using Hibernate. Much easier to just use the damned thing and hope for the best.

If you doubt me on this, I challenge you to go to a typical enterprise and develop a web page with vanilla js or HTML forms today. Or build a data project without using something like Spark, even if you only have a few hundred MBs of data.

<comment><USER19> > If you doubt me on this, I challenge you to go to a typical enterprise and > develop a web page with vanilla js or HTML forms today. Or build a data > project without using something like Spark, even if you only have a few > hundred MBs of data.

No, that problem is called "having shitty people skills that are so grave that you can't sell the benefits of mature technology and experience to people who leave and breathe cost-benefit analyses".

The only common theme is developers who can't interact with non-technical staff.

Most people out there are actually working with relatively mature and effective tools, it's just that the only way you notice people _not_ catching on to fads is the dead silence of keeping your head down while solving real problems.

</comment></comment></comment><comment><USER20> This doesn't look like it was a problem with Hibenrate, more of a "wrong tool for the job"-scenario. Reposting what I recently wrote on Reddit on a similar Hibernate discussion thread:

In my experience, ORMs and specifically SpringData-JPA-Hibernate occupy this weird niche in the enterprise spectrum. They are an overkill for small projects and they become a hinderance for large projects, so they sort of sit there for medium projects. If you start with an ORM on a medium size project and it becomes a big project you can sometimes find yourself in an awkward spot where you are writing a lot of SQL (and not of the JPQL kind). With Hibernate/JPA specifically there are so many things that are broken that they just start getting in the way if your schemas become large enough. To me this is really just a manifestation of Behavioral Problem (Martin Fowler, Enterprise Patterns), where relational databases don't really map to objects at all when you get down to it.

Basically, if you are going to do quite a bit of SQL, any ORM will just in the way. Should be plainly obvious to anyone with experience.

<comment><USER21> It depends a lot of the ORM. SQLAlchemy allows you to ditch the ORM when you need it. But instead of going back to raw sql, you just get a DSL like LINK, which is very flexible and can express most of the stuff you could do with manual SQL, while still retaining many benefits of using a wrapper.

It's my understanding that Hibernate doesn't allow this.

> Basically, if you are going to do quite a bit of SQL, any ORM will just in > the way. Should be plainly obvious to anyone with experience.

This is the problem you see : a lot of project don't have somebody very experienced with SQL anymore. Because they need to know a bit of sysadmin, and front en dev, and deployment, and CI, etc. So an ORM helps a lot in that regard, and will help most projects because the problems it causes are smaller that the ones it solves:

\- it forces people to put the schema, migrations and validation code in a centralized place.

\- it let you reuse your API knowledge instead of having to relearn the stuff for SQLite/Postgres/MySQL/Access.

\- it enforces good practices on security with data escaping and cleaning.

\- it let you benefit from your language tooling (analytics, linters, completions, doc, shells) to write queries that otherwise would be plain text in the middle of the file for most people.

\- it gives a structure to DB operations, so if you look for something, you know where and what to look for.

\- it gives you an event system to decouple queries and their effect.

\- it gives a common API so you can write easily libs targetting the ORM. This is why the django ecosystem is so rich : you can write an auth backend or a tagging system and know other people will be able to just plug it in.

\- it comes with tooling: auto generated admin, forms and APIs, migration manager, paginators...

It does have a cost in perf and sometime flexibility. But for anything that doesn't have 1 million of users yet, it's worth it. Especially in a world where a daily salary can be more than a year of server time.

I cache everything anyway :)

<comment><USER22> And it allows you to write specific queries that can then be post filtered / ordered / paginated by a more general mechanism.

Or you can write queries and play around with loading strategies later / change them over time as the shape of the data changes without having to change any other code.

Every time the ORM thing comes up on HN most people jump on the ORMs are evil bandwagon. I think sqlalchemy is probably a bit of an exception in terms of just how flexible it is, however in my experience you get all the benefits with next to no downside (performance overhead being the most obvious). I generally wouldn't start a project without it these days.

</comment></comment></comment><comment><USER23> I don't understand why SQL is avoided so much. Yes it can be a pain to get/transform types depending on the driver/adapter, but to me that's the whole of a thin wrapper. SQL is just code, not another API to learn, is typically just as self explanatory if not more, let's you use vendor-specific features easily, removes any voodoo so it's clearer what's going on, and isn't that hard to begin with.

</comment><comment><USER24> Look, if you write clear sql anyone will be able to read it. ANSI sql can be read by people even from other languages. You need to wrap it layers of bizarre abstraction and tape on language specific orms. How else will you keep your job?

</comment><comment><USER25> This article: [http://blogs.tedneward.com/post/the-vietnam-of-computer- scie...](http://blogs.tedneward.com/post/the-vietnam-of-computer-science/) is 10 yrs old. It is clear and to the point. ORM is a bad choice. Take a little time to Learn SQL basics, it is easier than any programming language.

</comment><comment><USER26> I supported a deals site that used Hibernate with JBoss. We went through several years of scaling pain until a consulting engineer found that the Hibernate cache settings were left at their defaults.

</comment><comment><USER27> Frankly, I've never understood the real-world utility of ORMs such as Hibernate. As far as I can tell, their purpose is to "abstract away" a database. But why?

SQL isn't hard. Learning database optimization is nontrivial but doable for anyone. Why do we need ORMs? Why is it better to replace a "WHERE ..." clause with ".where(...)"?

My personal impression is that these frameworks were developed for people that know how to write code in some language but don't know how databases work and want something easy instead of learning how databases work. It really feels very lazy to me.

If you have a library or framework thatproperly prevents SQL injection attacks, why use an ORM unless you feel too lazy or scared to learn how to use a database properly?

<comment><USER19> SQL cannot be trivially composed. If you want to dynamically build a query you're better off using a query builder to generate that SQL than trying to play around with strings.

SQL lacks support for some pretty basic things like query aliases. Try writing 5 nested queries vs using variables to store the different criteria.

SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY should be irrevant. Join syntax is frankly horrendous. It's difficult to autocomplete.

Embedding SQL in your code is a recipe for disaster. Your compiler does not understand it, therefore refactoring means going over every query you have and manually looking to see what changes to do. It cannot be validated in compile time. SQL strings have no knowledge of the backing domain until they're actually run.

And finally, 99% of the time you _really do_ want to fetch and object with relations from the DB, not simple maps of field names. Aliasing field names in SQL from joins is a waste of my time. Making the returned data map to whatever object actually contains the business logic I'm interested in gets old, fast.

<comment><USER27> >SQL cannot be trivially composed. If you want to dynamically build a query you're better off using a query builder to generate that SQL than trying to play around with strings.

SQL isn't supposed to be composed. It is a query language for a relational database structure. What composition is to run of the mill programming languages is what relations are to databases, roughly speaking.

>SQL lacks support for some pretty basic things like query aliases. Try writing 5 nested queries vs using variables to store the different criteria.

"Basic things" that are basic things for programming languages. SQL has support for what it should have support for - having intermediary variables (in the sense that general purpose programming languages have variables) is not one of those things. This comment belies a lack of understanding of how databases work and why.

>SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY should be irrevant. Join syntax is frankly horrendous. It's difficult to autocomplete.

The decision regarding where to order is absolutely relevant and is strongly dependent on your data model. Join syntax is a syntax to accomplish joins, which are fundamental to modeling of relational data.

And, frankly, if autocomplete is a criteria for you, then, in the context of these tools, you are not a developer, you are an end user.

>Embedding SQL in your code is a recipe for disaster. Your compiler does not understand it, therefore refactoring means going over every query you have and manually looking to see what changes to do. It cannot be validated in compile time. SQL strings have no knowledge of the backing domain until they're actually run.

This statement makes it clear that you have not seriously developed an application that is strongly dependent on a serious database. At least almost everything you said here is "not even wrong": [https://en.wikipedia.org/wiki/Not_even_wrong](https://en.wikipedia.org/wiki/Not_even_wrong)

>And finally, 99% of the time you really do want to fetch and object with relations from the DB, not simple maps of field names. Aliasing field names in SQL from joins is a waste of my time. Making the returned data map to whatever object actually contains the business logic I'm interested in gets old, fast.

I suggest you take a look at database design and relational information modeling. You really seem to not know what the problems are that relational databases solve, how to use them, or how to use them well.

<comment><USER19> > SQL isn't supposed to be composed.

How do you build a filtered search system? Query languages can _definitely_ be composed. Look at Codd's relational algebra operators; they can most definitely be composed.

You _can 't_ do this in SQL:

base_query = get_base_query()

if condition:

        query = base_query.filter(condition_a)

else:

        query = base_query.filter(condition_b)

This idiom happens _all the time_ in code with dynamic queries. It's handled trivially by any decent ORM. There's absolutely no excuse since you can do the same thing in relational algebra.

> SQL has support for what it should have support for - having intermediary > variables (in the sense that general purpose programming languages have > variables) is not one of those things. This comment belies a lack of > understanding of how databases work and why.

Um, no. In fact the WITH statement was added in the latest SQL standard to help with this because, well... it turns out writing 5 nested queries _is_ a pain.

> And, frankly, if autocomplete is a criteria for you, then, in the context of > these tools, you are not a developer, you are an end user.

And you've never heard of data analysts who literally spend all day doing nothing but running queries and reports? You've never run drafts of queries to see if you're doing reasonable things?

> I suggest you take a look at database design and relational information > modeling. You really seem to not know what the problems are that relational > databases solve, how to use them, or how to use them well.

If you're going to lecture someone when you have no proof of backing your assertions with real-life use cases then I suggest you actually go read Codd's original paper on relational algebra rather than praising SQL as something handed down from the gods. It's an imperfect representation of the tree structure of relational queries composed of projections, joins, and selections.

If you're going to be cargo culting SQL, at least actually understand what the original was. SQL was the 70's idea of a "natural-looking" language to model relational algebra. And relational algebra is only one way to understand relational data stores (tuple calculus is another decent formalism for understanding it as well). And relational stores are only one of many different data modeling tools.

There is literally _nothing_ in SQL that you cannot do more ergonomically with most query builders, since everything boils down to the same thing: an abstract tree of query expressions that can be understood by a DB engine and manipulated through basic relational algebra rules to optimize according to heuristics.

</comment></comment></comment></comment><comment><USER28> If you need to map relational database to objects and don't use an ORM, you will eventually reinvent it, in a bad ugly and buggy way. ORM is hard. Hibernate is a fantastic robust thoroughly tested and massively successful framework. But as any power tool, in the wrong hands can be a disaster.

[https://martinfowler.com/bliki/OrmHate.html](https://martinfowler.com/bliki/OrmHate.html)

</comment><comment><USER29> For our API, I've rewritten probably 2/3 of the public endpoints to use raw SQL. I'd like to rewrite the other apps as well. The non-ORM app has no issues whatsoever. I estimate probably an eighth to a quarter of the time I've spent in the last three years has been dealing with completely avoidable ORM issues. Yeah, I can relate. At least it wasn't my choice to use them. It's a minor consolation.

</comment><comment><USER30> Shameless plug: if you're looking for a no-dependencies Java 8 JDBC wrapper, we have been using [https://github.com/pyranid/pyranid](https://github.com/pyranid/pyranid) in production for a number of public-facing projects over a couple years and it has worked very well for us

</comment><comment><USER31> > I had to learn Hibernate architecture, configuration, logging, naming > strategies, tuplizers, entity name resolvers, enhanced identifier > generators, identifier generator optimization, union-subclasses, XDoclet > markup, bidirectional associations with indexed collections, ternary > associations, idbag, mixing implicit polymorphism with other inheritance > mappings, replicating object between two different datastores, detached > objects and automatic versioning, connection release modes, stateless > session interface, taxonomy of collection persistence, cache levels, lazy or > eager fetching and many, many more.

Welcome to Java …

I generally find that an ORM makes easy things easy and difficult things indescribably hard or impossible. Honestly, the relational model is great, and it's worth understanding well. Frankly, if you're a software developer and you can't learn SQL … you're not really a software developer.

<comment><USER14> > I generally find that an ORM makes easy things easy and difficult things > indescribably hard or impossible.

I agree, but raw sql makes the easy thing hard (or at least cumbersome), so the nice middle ground is to use hibernate for the easy things and sql for the hard things.

<comment><USER31> With respect, I just don't find SQL that difficult, _especially_ for the simple things that an ORM does a nice job with. "select foo, bar, baz from quux where uuid = '8bd67f1e-6bb8-4ccb-8ad4-fa631b36ab8e'" is _easy_.

</comment></comment></comment><comment><USER32> Maybe this is out of inexperience, but having worked with Rails' and Django's respective ORMs, some of the things, about Hibernate, from this article like, lacking migration support seem a bit strange. And never having used it, feel like I am not seeing the complete picture.

Anyone with having worked with both, care commenting ?

</comment><comment><USER33> In this story, Monica was able to actually get to year 4. What's to say that if she went with raw SQL, the team never would have been productive enough to match their run rate. For every story there is of a successful team who rues using an ORM, how many teams are out there who are lost to the obscurity of failure thanks to not choosing a fast over correct solution.

Now, this is not a judgment for or against SQL, given there are plenty of users of Hibernate, it has clearly worked for some teams. Equally, given people _still_ write SQL, I am sure it has worked for many people.

Fundamentally there are two questions to my post:

1 - how much could have been saved in this scenario by a better team

2 - how often is it that the right solution now becomes the wrong solution later?

<comment><USER25> "raw sql"? SQL is not assembler. SQL is a descriptive lang a few steps higher in the abstraction ladder from any algol-derived lang as C,java,etc.

If they had chosen to go with plain SQL, maybe the project would be finished successfully by year two.

</comment></comment><comment><USER34> > Software Architect

I found the problem.

</comment><comment><USER35> A long time ago, in a programming language now forgotten (gosu) some interns and I created a SQL typeloader that allowed you to define your domain in SQL DDL files and then write query files in SQL that were accessible, type safe, directly from Gosu:

[https://github.com/gosu-lang/ragnardb](https://github.com/gosu-lang/ragnardb)

[https://github.com/gosu-lang/ragnardb-test](https://github.com/gosu- lang/ragnardb-test)

No codegen, just made SQL resources a top level type safe resource you could work with.

I liked the idea a lot.

</comment><comment><USER36> Having built my own ORM and my own distributed key/value JSON store with index over HTTP I can say SQL is the problem, SQL databases are older than the internet, they have not evolved since the 70s. You need async on the network preferably over HTTP (to be client agnostic) and almost no database provides that today. Heck no programming language provides multi threaded non blocking IO with shared memory, only C++ (and maybe modern attempts Rust, Go, Swift etc.) and Java (C#) are capable languages.

</comment><comment><USER37> A major red flag is if you hear any developers saying things like: "The ORM will abstract access to the database so that it's like everything's in memory."

</comment><comment><USER38> "To get a report, we have to wait two days!"

Who in their right mind would use Hibernate (or any other ORM for that matter) for reporting?

<comment><USER6> I think JIRA uses it. I vaguely remember the query format for it being a form of JPQL.

<comment><USER39> Funny that. The larger our (not particularly large) JIRA account gets, the slower it performs. Very noticeably so.

</comment></comment></comment><comment><USER40> Why does SQLAlchemy feel so much nicer than Hibernate? Is there something equivalent in the Java world?

<comment><USER41> Im a fan of JDBI [http://jdbi.org/](http://jdbi.org/)

</comment></comment><comment><USER42> I knew that ORMs where a bad idea since the first time I saw one many years ago. It never made any sense to me. I don't see how they simplify anything; even in the early stages. SQL is actually a really simple abstraction for fetching relational data.

</comment><comment><USER9> Currently dealing with a simple user database in a backend, Play Framework (Java) for a website. After reading this I'm worried doing this with EBean ORM is not good. Any advice/comments from experts?

<comment><USER14> Do you know sql/databases well? If not learn that because you'll have to anyway. Then learn how your ORM works and what problems it solves (and what it doesn't).

</comment></comment><comment><USER43> This page will serve as a very useful "Who not to hire" page.

</comment><comment><USER44> "ORM" means "snake" in Swedish, and will bite you.

</comment><comment><USER45> Does Java not have a good Micro ORMs (like Dapper, NPoco on the .Net side)? They can be a wonderful middle ground between completely custom sql and a full blown giant like Hibernate.

</comment><comment><USER46> I'm using scala Slick for huula, should I have this concern too since the development there seems really like just a one company effort.

</comment><comment><USER47> Java circa 2005 had a whole lot of problems, but if you ask me, the biggest problem of it all was that many of the 'solutions' to the problems were worse than the disease.

Back in the day, a friend of mine brought me in to write business software in Java for a small retail company. They didn't have much money, but they also didn't have any management that cared about our technical decisions, so we had a freedom that helped our careers tremendously: Nobody is making any less than 3x what they did then. But along with that freedom came the responsibility of getting the decisions right.

Hibernate was a great improvement over the awfulness that was naked JDBC, but the risks to bad performance were so terrible that we ended up just writing some decorators to make JDBC usable instead. Years later, I went to a big enterprise place, and saw what happens when developers stop learning SQL, and use hibernate to run complex queries.... and then I learned how big of a bullet we dodged.

Hibernate wasn't the only bullet though: One that Java is still suffering from is Spring. We decided that exchanging boilerplate you compile for XML was not a good tradeoff. Later they added annotations, but still, handing all of that wiring to the runtime is just not a good idea. Spring also taught people that it's easy to just have objects that can be constructed in ways that are broken (zero param constructors were easier to use), made application startup slower than even EJB, produce error messages that make the Clojure compiler seem friendly, and added all kinds of insane nonsense that made Rod Johnson quite rich, but didn't help Java itself move forward. Java 1.4 and java 5, out of the box, are like a person with a broken femur. Instead of fixing the bone, most of the ecosystem was just feeding the patient oxycodone: The result was that the patient still had a broken bone that was setting incorrectly, and the patient was now addicted to opiates. And yet, the people that wrote the bad tools that caused this have nice houses in Nob Hill and get to try to build new startups, now selling us their magical solution to the microservice problem.

The Java ecosystem only started to move forward when Ruby on Rails came to town, and, despite all of it's own problems, made it clear that the whole thing had to move forward. Now the JVM has far better languages than Java, and Java itself has actually improved in important ways, but that was due to competition, not bad solutions to problems.

I think we are back in the same boat with NoSQL databases: The companies selling tooling that did well didn't do so on good engineering, while the companies that did the best engineering struggle. But is the whole movement a good idea, or are we just going to see something like Spanner come in and the technologies that people got so excited about were just low quality solutions to problems that most of the time we didn't even have?

I think there's more to learn from the pattern of how developer tools succeed (and fail to deliver), than from just the lesson of Hibernate's tremendous shortcomings for anything complicated.

</comment><comment><USER48> I think ORMs are fine for greenfield CRUD apps done with code-first. SQL is the assembly language of the backend.

</comment><comment><USER49> SQL is an amazing and very useful tool to work with. I will never understand why people want to abstract it away.

<comment><USER50> "SQL seems hard" "Here's a tool that makes it so you don't have to use SQL" "Great! Let's use that" \- without having done the work to determine if that tool is actually any simpler (hint: it's not)</comment></comment>


There have almost been as many mass shootings in the US as days this year - <AUTHOR> https://en.wikipedia.org/wiki/List_of_mass_shootings_in_the_United_States_in_2019#Statistics <comment><USER3> When you use a definition like "two or more people shot in the same incident", _of course_ there's going to be a surprising number of incidents - <USER2> that's not what most people consider to be a mass shooting.

<comment><AUTHOR> In most other (Western) countries, "2+ shot in one incident, _excluding the perpetrator(s)_ , at one location, at roughly the same time", would be seen as a mass shooting and probably reach national media. There's a reason why the US has the highest gun death-rate per capita in the "developed" world [1]. The problem is the high gun-ownership rate [2] - other countries also have bad mental health care, a strong media focus on suspects, or high depression rates but America's gun culture is quite unique

[1] [https://en.wikipedia.org/wiki/List_of_countries_by_firearm-r...](https://en.wikipedia.org/wiki/List_of_countries_by_firearm- related_death_rate) [2] [https://www.vox.com/policy-and- politics/2017/10/2/16399418/u...](https://www.vox.com/policy-and- politics/2017/10/2/16399418/us-gun-violence-statistics-maps-charts#4eVoZS) (and the following chart)

<comment><USER3> > The problem is the high gun-ownership rate [2] - other countries also have > bad mental health care, a strong media focus on suspects, or high depression > rates but America's gun culture is quite unique

This is such a trainwreck of an argument - first you exclude 'non-western' nations, and by doing so acknowledge that there are factors _besides_ gun ownership rate that influence gun death rates (Which include gun suicides, and so probably shouldn't be included here!), and then say that "America's gun culture is quite unique" while ignoring the fact that the highest rates of gun homicides in the US occur in cities with extreme restrictions on gun ownership.

Finally, gun _ownership_ rates are not as different in Europe as you'd think - US gun ownership rates are only slightly higher than those of Europe. (Not guns per capita, % of population owning guns) Most of Europe and the anglosphere ranges between 20 and 30 % gun ownership. For instance, Canada has a gun ownership rate of ~26%. The US? ~33%.

If you want to discuss gun _homicide_ rates, fine. If you want to include countries that the US _borders_ like Mexico, great! But comparing gun deaths (since suicides make up 2/3 of US gun deaths) against a cherrypicked subset of countries is really disingenuous.

<comment><AUTHOR> > first you exclude 'non-western' nations, and by doing so acknowledge that > there are factors besides gun ownership rate that influence gun death rates

Of course, they are. If you live in an active conflict zone or in a country with a weak state, then surely that influences gun-related deaths (e.g. armed conflict doesn't require a lot of civilians to have guns. It's hard to control for all these variables. However, this doesn't detract from the fact that, among somewhat similar countries, gun ownership is a very strong predictor of gun-related deaths. It also doesn't detract that, amongst all nations, the US is still a leading country regarding gun deaths

> Which include gun suicides, and so probably shouldn't be included here!

No, they should be included, because gun ownership makes suicide more likely and much easier (see charts 11-13 in [2]): Most suicides are very spontaneous (see effectiveness of suicide fences) and guns make suicides quick and easy.

> gun ownership rates are not as different in Europe as you'd think - US gun > ownership rates are only slightly higher than those of Europe. (Not guns per > capita, % of population owning guns) Most of Europe and the anglosphere > ranges between 20 and 30 % gun ownership

I couldn't find data confirming that. However, there's an interesting bit on Wikipedia on research showing the correlation between gun ownership and violence [3]. Also, this doesn't change the association between number of firearms and gun deaths: More guns also means easier access to guns. Also, owning a gun in Europe is very different: you have to meet very stringent requirements, go through various trainings, and store your guns safely.

It should be obvious that having two deranged, murderous individuals, having easier access to guns, increases the likelihood of a murder.

> If you want to include countries that the US borders like Mexico, great

I'm not sure why that should be important, but just note that it is the availability of weapons in the US, smuggled over the border, which fuels the drug war there.

[3][https://en.wikipedia.org/wiki/Gun_ownership#Association_with...](https://en.wikipedia.org/wiki/Gun_ownership#Association_with_rates_of_violence)

<comment><USER3> > > first you exclude 'non-western' nations, and by doing so acknowledge that > there are factors besides gun ownership rate that influence gun death rates

> Of course, they are. If you live in an active conflict zone or in a country > with a weak state, then surely that influences gun-related deaths (e.g. > armed conflict doesn't require a lot of civilians to have guns. It's hard to > control for all these variables. However, this doesn't detract from the fact > that, among somewhat similar countries, gun ownership is a very strong > predictor of gun-related deaths. It also doesn't detract that, amongst all > nations, the US is still a leading country regarding gun deaths.

I think "a leading country" here means "behind most of central america and the caribbean". The US has a lot of cultural overlap with those areas, and there is a significant racial and cultural component to homicide rates. (For instance, approximately half of US murders are of and by African American men. Exclude African Americans, and the US basically hits the EU average)

> > Which include gun suicides, and so probably shouldn't be included here!

> No, they should be included, because gun ownership makes suicide more likely > and much easier (see charts 11-13 in [2]): Most suicides are very > spontaneous (see effectiveness of suicide fences) and guns make suicides > quick and easy.

Europe has essentially the same overall suicide rate as the US. Regarding effectiveness of suicide fences, do they actually reduce suicides? Wikipedia seems to suggest otherwise. [0] This would seem to indicate that if suicides _are_ in fact very spontaneous, there are other easy routes to take.

> > gun ownership rates are not as different in Europe as you'd think - US gun > ownership rates are only slightly higher than those of Europe. (Not guns per > capita, % of population owning guns) Most of Europe and the anglosphere > ranges between 20 and 30 % gun ownership

> I couldn't find data confirming that. However, there's an interesting bit on > Wikipedia on research showing the correlation between gun ownership and > violence [3]. Also, this doesn't change the association between number of > firearms and gun deaths: More guns also means easier access to guns. Also, > owning a gun in Europe is very different: you have to meet very stringent > requirements, go through various trainings, and store your guns safely.

That section doesn't say what you seem to think it says. "the highest-quality studies show that gun ownership does not increase homicide rates." "The availability of illegal guns, but not that of legal guns, is associated with higher rates of violent crime." "An international study by UNICRI researchers from 2001 examined the link ... There were no significant correlations detected for total homicide and suicide rates, as well as gun homicide rates involving male victims." "The association between gun ownership and homicide rates across nations is dependent on the inclusion of the U.S." "Studies in Canada that examined the levels of gun ownership by province have found no correlations with provincial overall suicide rates." "A 2011 study conducted looking at the effects of gun control legislation passed in Canada and the associated effects in homicide rates found no significant reductions in homicide rates as a result of legislation." "A case-control study conducted in New Zealand looking at household gun ownership and the risk of suicides found no significant associations."

Thanks for making my argument for me, I suppose?

Also, I think you might be interested in rates of _illegal_ gun ownership in Europe - compliance rates are far lower than you'd think [1], and unregistered gun ownership rates far higher [2]. There's been tens of millions of weapons left in the dirt on that continent over the past century - were they all supposed to have disappeared into nothing? This makes the "But there are higher restrictions on gun ownership!" argument fallacious - when two thirds of the guns in Germany ignore those requirements entirely, perhaps they won't have much of an impact.

> It should be obvious that having two deranged, murderous individuals, having > easier access to guns, increases the likelihood of a murder.

But it does not follow that gun control reduces the chance that deranged individuals have access to guns, among other things.

> > If you want to include countries that the US borders like Mexico, great

> I'm not sure why that should be important, but just note that it is the > availability of weapons in the US, smuggled over the border, which fuels the > drug war there.

Are you sure it's the availability of smuggled weapons, and not the economic incentives caused by prohibition mk 2, that fuels the violence there?

Finally, I think I should include an article of my own, as a counterbalance to that Vox idiocy: [https://slatestarcodex.com/2016/01/06/guns-and- states/](https://slatestarcodex.com/2016/01/06/guns-and-states/) Note that he still concludes that Australia-style gun control in the states could reduce murders/year by as much as 2000 - about 25% of gun-related homicides. But that would still leave a major homicide rate gap between the US and other western nations - because a very large component is cultural.

0: [https://en.wikipedia.org/wiki/Suicide_barrier#Efficacy_of_su...](https://en.wikipedia.org/wiki/Suicide_barrier#Efficacy_of_suicide_barriers_for_saving_lives)

1: [https://reason.com/2012/12/22/gun-restrictions-have- always-b...](https://reason.com/2012/12/22/gun-restrictions-have-always-bred- defian)

2: [https://reason.com/wp- content/uploads/assets/mc/2012_12/SAS2...](https://reason.com/wp- content/uploads/assets/mc/2012_12/SAS2.2.gif)

</comment></comment></comment></comment></comment><comment><AUTHOR> Also, think about the fact that there is a Wikipedia list for mass shooting in one country _this year_. Most countries don't even have a list of mass shootings, let alone one for each year. The Utrecht tram shooting was for _weeks_ in the media all around Europe (even in the US) and only 3 people died. This was an unprecedented event in the Netherlands. However, this year, the US had 20 shootings with the same number of fatalities or more

</comment><comment><USER4> When it comes to gang shootings in the inner city, it's way more than what's in this list.

</comment><comment><USER5> Yet more people die from falling in their bathrooms every day than each year from shootings. #bathroomcarpetnow

Don't base your politics on a rounding error.</comment>


The Platinum Rule - <AUTHOR> http://robertgreiner.com/2014/04/the-platinum-rule/ <comment><USER3> The Platinum rule does however require that you know someone else's preferences, which is harder when you are not married to them.

I default to treating people how my mental model of a "normal person" wants to be treated. For example, most people in most circumstances want minimal interaction with strangers. I then modify that by what I can vaguely infer about their preferences based on their background. For example, women going to be not just annoyed, but creeped out by random strangers. I then modify that based on setting: at a conference, people are far more interested in meeting new people. I then try to pay attention to their body language, tone of voice, and words to see if I can read anything about them as an individual. If a person looks alert and open-stanced, they are probably more interested in meeting people. And of course, if it is non-awkward, I'll just ask them about their preferences.

<comment><USER4> The idea behind DISC (as referenced in the article) is that there are four behavioral axes, and that by learning to understand which a person ranks highest and lowest on (via reading body language, speech patterns, expressed preferences, etc), you can modify your behaviors in context to them in such a way that the way you treat them is the way they want to be treated.

The core thesis of DISC is that there is not a "normal person" (even though we intuitively think there is). Rather, there are normal archetypes of people, and understanding those archetypes makes it easier to interact with them. You assert that "most people in most circumstances want minimal interaction with strangers", but this is wholly untrue (and indicates that you are a relatively low "I", which is fairly typical of tech types). Some people actively seek out interactions with strangers (strangers are just friends they haven't met yet!), and understanding that makes it much easier to interact with and communicate with them. High-I types actively seek and crave social interaction. They may modify their behavior to the situation, but they are most comfortable when they're socializing; in fact, the further someone's adapted (environmentally-imposed) behaviors are from their natural (preferred, given a lack of other constraints) behaviors, the unhappier they tend to be. While it may be culturally verboten to strike up a conversation with the person next to you on the subway, the high-I would like nothing better than to chat about their day with the person next to them (and the low-I wants nothing more than to be left alone).

Since there are only these four major attributes to learn, you can read people that you don't know intimately - sometimes from across the room!

For example, if you can recognize a high "D" personality (which is frequently easy to recognize, but also relatively rare), you will make them feel most at ease by not having to be in charge of an interaction - behaving cooperatively and deferentially will make it much easier for them to feel comfortable with you than if you are attempting to be in charge. This doesn't mean to be a doormat, but simply that if you can give up some non-critical control, they will feel that the interaction is much more "natural".

By the same token, interacting with a low "D" requires you to step up and take the reins. Being assertive and confident with a low D will result in a smoother experience, because their natural tendency will be to be deferential and unassuming, and it's actually more comfortable for them to be given some direction and to have someone else make the decisions.

Think about the age-old "where do you want to go for lunch?" question. When interacting with a high D, make suggestions, give input, offer opinions, but try to let them make the decision. When interacting with a low D, you might need to be the one to define the boundaries and make a decision about where you're going to go. The high D doesn't like other people making decisions for her, and the low D doesn't like having to be the one on which the decision rests. Understanding that lets you interact smoothly with both of them, even though they require diametrically-opposed approaches.

</comment></comment><comment><USER5> The "Platinum Rule" is already implied by the Golden Rule, unless you're saying that you would normally _want_ people to ignore your preferences.

<comment><USER6> The "Platinum Rule" is wrong because it is impossible to follow. Even if my ethicals _only_ included "do unto others as they want done to themselves" how would I resolve two fighting men each asking for assistance in subduing the other?

The reason the golden rule works is because it places you in the position of the other. If I accidentally killed someone due to carelessness, I would want myself to be imprisoned for some time.

<comment><USER3> If you intentionally killed someone due to racial hatred, you also wouldn't want yourself to be imprisoned for some time either. Nor if you recklessly killed someone due to tiredness and a desire to get home earlier.

<comment><USER7> You wouldn't want someone else to kill you due to racial hatred, so that immediately doesn't follow the Golden Rule.

<comment><USER3> Indeed. My point is that both metallic rules are insufficient to address conflicts with serious consequences. The only rule I know of which is both simple and sufficiently broad to deal with any conflict is the Iron Rule: "The strong do what they will and the weak suffer what they must". Yet that is utterly amoral.

</comment></comment></comment></comment></comment><comment><USER8> The problem with the platinum rule is that we have no clear and unambiguous language for advertising how we would like to be treated.

In _This Alien Shore_, by C.S. Friedman, one planetary culture, the Guerans, is essentially a human colony, but one where gestational biochemistry has been mutated to the extent that every adult exhibits at least one type of human mental disorder. They adapted by adopting a system of face markings so that people don't make simple but potentially dangerous mistakes--like hugging someone with an autism spectrum disorder, or holding eye contact too long against someone with a dominance disorder.

The point is that you would really have to either put extensive research into the preferences and personalities of everyone you know, or everyone would have to write key information across their foreheads every day.

Our society, lacking a dire need, does not care to invest in that level of effort and openness. It is far easier to follow the silver rule (don't do things you don't like to others) and the golden rule (do for others what you would like them to do for you), because those do not require extraordinary knowledge of other people's preferences.

In the age of social network oversharing and augmented reality, perhaps we can run an application that will superimpose another person's preferences over their faces automatically. But for now, the platinum rule is going to be pretty hard to use outside the bounds of your own family.

<comment><USER9> "we have no clear and unambiguous language for advertising how we would like to be treated"

Which is why being actively assertive is a good choice to make. Not sure how someone wants to be treated then ask them. What if the don't want you to ask them? Then they should have been actively assertive and wore a sign/shirt that says "Don't ask". (I realize that doesn't help the blind). Also, perhaps we should rephrase "how someone wants to be treated" to "how someone prefers you to act toward them"?

<comment><USER8> But that wastes time in comparison to the interactions of two people who both subscribe to the same prenegotiated etiquette.

</comment></comment></comment><comment><USER4> I actually used to work for a company that developed tools for administrating and interpreting DISC assessments. It's actually really interesting stuff - <USER2> all tend to have some assumption at some level that other people think like us, value the same things that we do, and have the same reactions to a given situation that we do. DISC asserts otherwise - just because I want to be treated one way doesn't mean that you want to be treated that way, and by understanding those differences, we can eliminate friction in communication.

Once you can learn to read how others want to be treated and know how to modify your own interactions with them accordingly, your ability to successfully interact with a wide variety of people vastly improves. It seems obvious and handwavey, but in my experience, the vast majority of tense relationships or awkward interpersonal interactions are because of a failure of two people to understand each other. Even if they're both behaving in the way they'd want to be treated, that doesn't mean that they're treating the other person as they'd want to be treated.

<comment><AUTHOR> I think you might enjoy Personal Styles and Effective Performance. It's a dry read, but reinforces the things you discussed above.

[http://www.amazon.com/Personal-Styles-Effective- Performance-...](http://www.amazon.com/Personal-Styles-Effective-Performance- Merrill/dp/0801968992)

<comment><USER4> Heh, I suspect it's much of the same stuff I learned on the job. My former employer's products centered around understanding behavioral styles (natural vs adapted) and their impact on job performance and interpersonal relationships. Super interesting stuff.

</comment></comment></comment><comment><USER10> To me the WHOLE POINT of the Golden Rule is that there ISN'T a whole bunch of introspection / analysis / etc of the other person.

You just use yourself as the litmus test - i.e. "would I like this?" is waaaaaay easier to answer than "would they like this?". The former is an immediate gut-reaction; the latter requires a certain amount of empathy and insight.

<comment><USER11> Which is why the golden rule makes more sense for strangers and the platinum rule makes more sense for people you know. (to some degree)

</comment></comment><comment><USER12> This is a poor rule and I'll explain why.

In Reciprocal altruism [http://en.wikipedia.org/wiki/Reciprocal_altruism](http://en.wikipedia.org/wiki/Reciprocal_altruism) there must be a way to detect "cheaters" otherwise you will spend your life breaking your back for others and have nothing to show for it except the feeling of being abused. Sure, if everyone did it, that would be great. But the more people who use the "Platinum Rule" the more advantageous it is for some to abuse the system - criticizing others for not doing enough for them while never doing a darn thing for anyone else.

If you follow this rule, you are a total sucker, but hey you live like you want to live. It affects everyone else, however, because it creates an environment where unethical bullies and liars can thrive and gain power.

<comment><USER13> I strongly disagree. The platinum rule as stated in the OP is not the same as reciprocal altruism. In the example, he would not be reducing his fitness by treating his wife like she wanted to be treated. Not all interpersonal relations are a zero-sum game. Your position assumes that your preferences are unambiguously best in all situations. I'm sure we all would like to think that is the case, but that's a pretty arrogant attitude.

You can respect people and treat them the way they want to be treated without being a sucker.

<comment><USER12> I didn't want you to disagree with me!

<comment><USER13> Precisely my point! :)

<comment><USER12> So your position is inherently hypocritical; evidence for my hypothesis that it represents a 0 sum game. A proponent of this rule is not egalitarian but means to treat those above him or her in the social hierarchy they way he or she thinks their superiors wish to be treated, while expecting those he or she thinks less of to treat him or her they way he or she wishes to be treated.

Extrapolating from this, we can surmise who wears the pants in OP's relationship.

<comment><USER13> > So your position is inherently hypocritical; evidence for my hypothesis that > it represents a 0 sum game.

The position is not hypocritical. It just doesn't expect that one should mindlessly apply one rule in all situations. Life isn't that simple. People aren't that simple. Also, hypocrisy has nothing to do with whether something is zero-sum.

> A proponent of this rule is not egalitarian but means to treat those above > him or her in the social hierarchy they way he or she thinks their superiors > wish to be treated, while expecting those he or she thinks less of to treat > him or her they way he or she wishes to be treated.

This is a straw man. Proponents of this rule can easily apply it equally to everyone regardless of authority or power. Doing so doesn't make one a sucker because they can easily decide to stop applying the rule to a particular relationship if it becomes apparent that the other party is using it to bully/manipulate. Just because it's not a black and white thing doesn't mean it's not egalitarian.

> Extrapolating from this, we can surmise who wears the pants in OP's > relationship.

Funny how you pay lip service to egalitarianism while revealing your actual view of relationships to be far from equitable.

<comment><USER12> That fact that people are mired in a constant struggle of dominance and submission has very little to do with my own opinion of how things should be, it simply reflects my observations of human social interaction. Honestly if you see all human relations through the filter of pecking order, little of it seems mysterious or complex. War, inequality, charity, abuse, politeness, castes, genocide - they are all just displays of dominance and submission.

Hypocrisy is not required for something to be zero-sum, but it is a common symptom. I said it was evidence, not proof. Zero-sum games always require a winner and loser and therefore a double standard - what is good for one is not good for the other. It's a stretch, I know. It's probably too weak to make a good case for.

I don't think my argument is a straw man - I do believe that there is inherent inequality (and therefore hierarchical jockeying) when one moves from the treatment like oneself in the golden rule to the "special treatment" of the platinum rule. Again, I can't think of a way to make a strong case for it at this time.

I vehemently disagree with your claim that it is simple to stop this policy if it is clear a person is abusing it. Because the test depends on the desires of another person, and that cannot be measured, it is not easy to know if they are being sincere or manipulative. Only after a many experiences could one make that assessment and by then you have lost so much or worse, married them.

<comment><USER13> > I vehemently disagree with your claim that it is simple to stop this policy > if it is clear a person is abusing it.

Ok, I'll give you that, having been in situations like that myself. Remove the word easily from my above statement. So it's not always easy to stop applying the policy, but I believe (at least in my life experience) that the benefits of intelligent application of the platinum rule outweigh the costs imposed by those who abuse it.

> Because the test depends on the desires of another person, and that cannot > be measured, it is not easy to know if they are being sincere or > manipulative. Only after a many experiences could one make that assessment > and by then you have lost so much or worse, married them.

The test only depends on you. Applying the platinum rule depends on the desires of the other person. But deciding when to stop applying it does not. I firmly believe that you cannot effectively help other people unless you yourself are healthy (not in just the medical sense, but the whole life sense). So it's your job to decide on the application of the platinum rule based on the dynamics of each relationship in question.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I really hate putting people into these quadrants. As if that would be possible. It is certainly not possible for me, so why should it be possible for most other humans?

<comment><AUTHOR> Interesting perspective. There is quite a bit of research on the subject and most people typically have a dominant trait. Although, everyone can express behaviors in any of the types at any time, we typically "default" to a single one (sometimes two).

Have you taken a DiSC assessment? I find they are accurate for me and the people I work with who have taken them - anecdotal I know.

<comment><USER15> The problem with these traits is that they're so broad and vague as to be almost meaningless. Might as well use a horoscope!

</comment></comment></comment><comment><USER16> Another way to look at the two types of behavior is "maximizing" vs "satisficing":

[http://en.wikipedia.org/wiki/Satisficing](http://en.wikipedia.org/wiki/Satisficing)

This is covered here:

[http://en.wikipedia.org/wiki/The_Paradox_of_Choice](http://en.wikipedia.org/wiki/The_Paradox_of_Choice)

</comment><comment><USER17> "Do unto others as they would like done unto them." Is a pretty common restatement of the Golden Rule. While I agree with your premise, there's no reason to rename it.

<comment><AUTHOR> I think you have a point here. I was just using what Tony Alessandra already made popular: [http://www.alessandra.com/abouttony/aboutpr.asp](http://www.alessandra.com/abouttony/aboutpr.asp).

</comment></comment><comment><USER18> I don't like this because, as a massive weirdo with an above-average level of control over my own emotions, the golden rule basically gives me a free pass.

</comment><comment><USER19> Myers briggs, this dcis thing, astrology, meh. All gobly gook. People dont fit in to easy clearly definable categories. People dont make decisions based off of clearly definable categories (even if they did exist, they're not relevant). So its all silly to even talk about.

</comment><comment><USER20> Massive apologies in advance for my immature nature, but who on earth let a quadrant for describing human behaviour that spells out "dicks" get past copy editing? I can it describe all people? If so, I guess that means all people are...

<comment><USER21> It's supposed to be read in a clockwise fashion. Also, in the theory, the archetypes have the hardest time working with the archetype that is directly across from it, so there is a reason for the graphical representation.</comment></comment>