h1karu

Here's an example from the viewpoint of someone doing the hiring. Lets assume your goal is to hire the top 5% of technology X programmers in America.

The first 5 people you hire are all early to mid 30s white guys who go out drinking together, get together to play paintball every few weeks, etc. Then the 6th person you need to hire is a Bangladeshi woman aged 42 who doesn't drink at all and of course doesn't play paintball. Well it's not a big deal at all, the team welcomes her, is very professional around her, recognizes the difference in culture and age so they don't give her a hard time for not participating in the drinking and paintball culture. So far no problems..

The 7th hire is another white guy, aged 31, but the difference is that this 7th hire also doesn't want to drink socially or play paintball. Unlike the Bangladeshi woman he has no convenient excuse to not want to do those things, so therefor even if he's very friendly, professional, and competent on the job he is ultimately labeled as "distant" by the other coworkers his age, and over time the rest of the team will grow to resent him for not "trying harder" to become friends outside of the office. People will assume that he thinks he's "too good for us", but those same people will not make such assumptions about the attitude of the Bangladeshi woman.

The Bangladeshi woman's choice to not try to become close personal friends with her coworkers is well respected and is not a problem at all, she is given all the space she could ever want socially and is only judged based on her contributions to the company. The young white guy on the other hand is held to a different set of standards, for him to not actively try to become personal friends (outside of work hours) is something that could cause him to be perceived as not a good cultural fit and possibly cost him his job in the long run all due to a hidden expectation linked to his skin color and age.

This is the kind of drama that can crop up in a real office which just completely disappears once a company "goes remote".

You're right. If you've done open source work you know that of course there's a huge amount of space for personality conflicts to arise even when working remotely, but at least those personality conflicts are usually centered around differing views about the project vision or how best to implement it and not based around office politics having to do with who's dating who, who's drinking buddies with who, offline politics having to do with the developer's wives being friends and then no longer being friends (see github drama), etc etc.

I think that going to the office every day jobs are definitely healthier than sitting alone in front of your keyboard with no social contact at all slaving away on a codebase. You need a social life I'm just advising that for me it's nice to keep that social life completely decoupled from my financial situation, and that is really hard to do in a normal office environment.

When I clicked that I wanted to go from Austin TX to Portland, OR it said "pack your plaid". This is just a poorly done rip-off of hipmonk's messaging. It's just going to confuse people who aren't familiar with silly internet-meme based stereotypes about whatever city it is they're choosing. It's just a bad idea. Portland's message should have said something about roses, or Mount hood, or even make reference to the fact that it rains a lot there, but not some fuzzy stereotype about how a certain age group tend to dress.

This is why "work remote" jobs are so fantastic if you can get them. You don't have to worry as much about politics. In an office environment you have to worry about if you're getting along well enough with people on a personal level and this nebulous "I enjoy working with him or not" factor might make or break your career. At an office job you need to put in hard work to "become friends" with everyone otherwise some people will bear a grudge. Sometimes this is not easy depending on the situation. There are too many "social factors" in office jobs which can make or break you and that have nothing at all to do with your ability to "get shit done". Not so with remote working. All that matters is your ability to be productive.

https://37signals.com/remote/ weworkremote.com

The cost of living in the tech-scene areas are outrageous and skyrocketing, those are the facts. The sun-shine California lifestyle can be quite nice you'll need to be prepared to pay out the wazoo. Don't believe it ? Prove me wrong, start looking at the Bay Area rental market.

Why would any privacy related service provider operate within the United States of America ? It's one of the worst jurisdictions for that kind of thing.

To me that makes no sense whatsoever, so this start-up was doomed from the very onset.

HIKARU!!!!!!!! NO GO!!!!

http://www.youtube.com/watch?v=E-LHI1MC6Gc

I thought life is all about launching a minimal viable product, tweaking it to narrow in on product/market fit, and then scaling up. You mean there's more to life AFTER that ?! oh brother. I'll worry about that once I get there

Stay out of the pathologizing paradigm. Explore non-duality perspectives, Zen, meditation. With these modalities you can learn to relax into whatever seems to arise or whatever seem to dissolve.

You might try MDMA based therapy if you need a quick fix. Oh and exercise

You're kinda all over the place with your question. I disagree with the idea that you can form any assumptions about what is happening broadly in the tech community based on frequency of certain types of posts appearing on HN, reddit, etc. After all there are many well funded organizations out there with their own agendas who post stuff regularly to try to influence certain demographics, and the tech sector is a particularly high value target I would imagine.

I would argue that Zen buddhism is not a religion, and vipassana/samatha meditation practice isn't in any way religious, as in there's nothing you're being asked to believe outside of what you can absolutely confirm for yourself in your moment to moment experience.

ROFL I just glanced @ your blog. I see you've made the most of the situation

Or you could teach your children something like Zen buddhism or Theravada vipassana meditation so they can learn to slowly and methodologically take their bubble apart and put it back together with each session of sitting practice. This way they don't get whacked over the head with it all at once and run screaming and crying to some form of fundamentalism, an extremist cult, or end up committed to some state institution.

https://en.wikipedia.org/wiki/Vipassana

Serendipity doesn't mean you're crazy, some people experience it more than others. Just relax. If you think that every time you experience one it means you're going mad then maybe you really will :)

All the existence of serendipity points to is that mainstream science doesn't fully understand how the universe works, it doesn't mean that you're crazy.

"Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick

See Phillip K Dick

Yea performance is the thing. You're correct that most of these queries can also be expressed in a relational DB.

The underlying data structures involved in Neo4J do help with performance on these kinds of queries, but in addition to that I find that for me the Cypher query language feels like a more concise and elegant way to ask for the data.

With RCTE it feels like I'm first asking the DB to construct a custom data structure, then I'm asking the DB to query that custom data-structure.

With Cypher it feels like I'm simply asking for the exact data I need by specifying the relationships and attribute characteristics that I care about.

This might just be a matter of taste, but if you start playing around with Cypher it just might grow on you.

I love remote companies because they can afford to give their employees the freedom to have drug habits or kids who demand a lot of attention or whatever else. There's no pressure to "keep up appearances" so as long as his communication on git and hipchat is professional and his code quality is high.

In real offices there is too much wasteful drama/noise around 'perceived slackness' that often does not correlate with the actual facts. In a remote environment everyone is being judged on the same time-scale by the same exact criteria which has nothing to do with their age, sex, lifestyle choices, sleep habits, etc.

The approach I like is to use a key/value document store as the system of record (SOR). If any data conflicts arise between Redis, the document store, and the graph database, then the SOR wins. A good SOR should contain all of the data necessary to rebuild any other data source in its domain.

Graph databases can scale write throughput fine when those writes are being fed to it from a single source so it's best to have a service who's sole purpose is to keep the graph database in sync with the SOR. The graph should only store the data you actually need in order to get the queries that you want.

The specific queries in my domain are exactly the kind of thing I'm not supposed to talk about, but I will say you can do things like:

Give me 50 users who who live near me (lat/long bounding box), who I'm not already following, who I have not already sent a message to, who have at least two friends who also live near me, and who have matching tags, order by number of followers.

there are a bunch of great examples in this awesome book: http://www.amazon.com/Graph-Databases-Ian-Robinson/dp/144935...

that's exactly how I design the parts of my app that need a transactional nature. Map/reduce views make it a breeze to query for a consistent aggregate view of the world.

This is not something new it's a well established technique from the relational world called "event sourcing"

http://www.martinfowler.com/eaaDev/EventSourcing.html

when everything is a write you don't have to worry about conflicts or locks, so that's nice, plus couch is really good at scaling write thoughput with small documents.

NDA and all of that, but if you pick up this book:

http://pragprog.com/book/rwdata/seven-databases-in-seven-wee...

and grep for the phrase "polyglot persistence" you'll find some great information to get you started.

a video promo for the book: https://www.youtube.com/watch?v=bSAc56YCOaE

My NoSQL store of choices gives me document-level ACID semantics along with eventual consistency, MapReduce, and replication.

Here's an example that explains how to get transaction-like guarantees from this kind of NoSQL data-store:

http://guide.couchdb.org/editions/1/en/recipes.html https://en.wikipedia.org/wiki/BigCouch

These are all scams. No amount of VC money can solve this problem because it's not a technology problem it's a legal and political problem centered around the legal definition of 'money laundering'. See e-gold, liberty reserve, etc

That's a fair point. If you need highly relational queries within a given shard then using a relational database there can make sense, but for many apps the kinds of queries that are used are not highly relational in nature so using a NoSQL store could have reduced the need for all of that app-specific sharding engineering while still allowing for all the queries that were needed by the app.

I personally find that SQL relational databases are not flexible enough for my application so I go with a polyglot persistence architecture that ties together a nosql key-value store with a graph database technology. This way I can use the cypher query language to access data relationally across all my shards while scaling writes and Big-data horizontally.

To each his own.

Like I said because the relational database doesn't scale horizontally you are forced to build a sharding layer into your application which introduces complexity into the application layer and limits your ability to use the relational features of the relational database. At that point you might as well just be using a key-value store that does the sharding for you and offers greater flexibility.

AdWords was designed with sharding built into it's application layer. This essentially means that the developers were forced to implement a custom app-specific persistence layer that rides on top of MySQL.

This limits your ability to write SQL queries because you can only query within a particular shard and that decreases the usefulness of mysql and makes it feel more like a nosql data-store. At that point you find yourself asking why didn't we just use a NoSQL store ? And often times the answer is "because we wanted to use something we were already familiar with". Sometimes people are willing to add a lot more complexity to their application just to allow themselves to avoid having to learn something new.

Relational databases don't scale horizontally. That's still as true today as it was a decade ago. Therefor engineers who need to cope with Big Data and Web Scale will continue to migrate away from relational database solutions towards persistence technology centered around distributed systems. It's as simple as that.

If you build your app around a relational database and you need to scale up big then at some point you're going to hit a brick wall in terms of scaling out storage and/or writes. You either have to build sharding logic into your relational db app from the beginning(which is a pain that NoSQL saves you from), or else you have to re-architect your entire app when the time comes that you need to deal with scale. Many shops end up borrowing VC money to build out a team to re-architect their systems to handle web scale, but this can be avoided by thinking about data access patterns from the beginning and choosing a technology that can handle your future needs.

https://en.wikipedia.org/wiki/Scalability#Horizontal_and_ver...

Agreed.

This is one of the reasons why I like remote work so much. If most of the work conversation is happening in a basecamp or hipchat which is logged then if a particular team member is phrasing his communication in a demeaning way or doing anything else to discourage others from group-learning then that behavior pattern will be discerned by everyone else relatively quickly and it can be dealt with. In an office team people can get away with being a dick for years without anyone being able to call them on it to correct the situation.

more on these themes here: http://37signals.com/remote/

If you're not careful your shop can become a drinking fraternity first, dev team second. What happens when someone who does not drink wants to join the team ? Well just the fact that he doesn't drink can make the rest of the team feel like they're having less fun and that they "can't have as much fun drinking now" so they might (subconsciously) decide that the highly qualified non-drinker is not a cultural fit. That's fine in an environment where new qualified recruits are easy to come by.. but is that the world we live in ?

> If someone knows less than you about something, you should not mock that person or make them feel inferior, you should help them. That is the right thing to do, irrespective of the gender of the person you're dealing with.

Why do you assume that merely telling someone that they are not qualified is the same as mocking them ? Sometimes the best way to help someone is to let them know that they're going to need a year or more of disciplined study in a particular area before they'll be capable of contributing in a meaningful way to the given project. It's better to tell them that up front than to string them along under the false pretense that they'll be able to "pick up" what is needed along the way

women bought into stereotypes 10 or so years ago which prevented them from learning the key skills. Quite recently geek has become sheek so those stereotypes are no longer a barrier to entry, but never the less the belief in those old stereotypes already skewed the numbers heavily in the favor of men. Programming just has not been "cool" long enough for enough women to have learned the skills... it takes years, perhaps decades to become a strong developer