Show HN: Subscription based suite of ML APIs from Google/MSFT/AWS, any feedback? - <AUTHOR> https://dataturks.com/ <comment><AUTHOR> For anyone wondering what it is:

A service to compare and integrate all the world's best ML/AI APIs from one place.

Allows transparent connection to more than a dozen ML API providers like Google, Microsoft, AWS etc such that for any use case say, image moderation, you can move from one API provider to another in a whiff with no code change since we provide a common response.

Also, you can configure to mix match response from multiple providers to suit your needs.

<comment><USER2> I don't understand the whole "a Netflix for machine learning" bit. If you have to explain what your tagline means, you should probably change your tagline to something that makes more sense. Netflix immediately makes me think movies.

<comment><AUTHOR> Just curious, how would you describe this? May be would help me to put in a better way.

<comment><USER2> A subscription with a suite of ML APIs, maybe? Idk, but the Netflix bit is really confusing—I mean you had to explain what your product actually is in your OP because the tagline tells you nothing. "Netflix" doesn't make me think "pay as you go API suite/marketplace/thing."

<comment><AUTHOR> Thanks for the feedback, I guess that makes more sense.

</comment></comment></comment></comment></comment><comment><USER3> This is similar to what Cloud Elements offers for other types of APIs. Take a look how they market it.

<comment><AUTHOR> Thanks. We had looked at what they were doing, similar as a concept but quite different in use cases. CE is mostly to support multiple platforms like Magneto/Shopify or other business integrations etc with just one integration, we are making it for developers and teams to integrate and iterate faster..similar to what Segment does for Analytics.</comment></comment>


GaryVee Is Still Preaching the Hustle Gospel in the Middle of a Pandemic - <AUTHOR> https://marker.medium.com/garyvee-is-still-preaching-the-hustle-gospel-in-the-middle-of-a-pandemic-b033b25f0dc <comment><USER2> How fragile is your world view that the writing of someone else who's giving non violent advice is "dangerous".

Every person who holds an idea you don't like is not "dangerous".

People who hurl epithets at free speech are a lot more dangerous in my mind.

<comment><USER3> Just to pile on this, Gary Vee bettered his life in an ethical way. And then he shifted what he was talking about to things like picking up free furniture and selling it for a small profit because that's what people needed to hear to get themselves on their feet. Guiding other people to be successful in a way you know is not dangerous...

</comment></comment><comment><USER4> So many things today are described as 'dangerous', especially ideas and information. What is truly dangerous is the idea that some information and thoughts are so dangerous (stuff we don't agree with) that they ought to be censored, deplatformed, banned from the internet, whatever.

I try to remind myself that people say crazy stuff for clicks all the time and that they probably have a more reasonable and nuanced opinion in person. Even so, I'm scared that the zeitgeist is moving towards absolutism, intolerance, censorship, etc.

</comment><comment><USER5> I believe a lot of folks are upset at "hustle culture" in the sense of overworking as exploitation. If you want to hustle and work hard for yourself, that is an amazing and aspirational model for many other people- but make sure you are hustling for your own success, not for someone else's success.

<comment><USER6> In addition to the "hustle" motivation, he also evangelizes not treating your employees or team like crap, and espouses the "be a leader not a boss" mantra. Nothing I've seen from him advocates using other people for your own success without making sure you are also considering _their_ success as well. He actually speaks against exploitation like that.

</comment></comment><comment><USER7> He preaches the so-called Hustle Gospel because Belarus, the country he is from, severely persecutes followers of the the true Gospel -- you know, the one about peace with God through faith in Jesus Christ?</comment>


Ask HN: SF startup meet up / happy hour tonight - <AUTHOR>

Just wondering if anyone was going to be attending any startup events in sf today. If there's a better place to find this kind of event, I'd appreciate to hear about it here as well.<p>Thanks in advance! <comment><USER2> To find events, try <http://startupdigest.com/>

As for organizing events, it works better to set a time without any consensus/asking and let people know that it will be happening with enough notice.

</comment><comment><AUTHOR> Let's plan one here. I'll start by suggesting a time: 8pm tonight. Anyone interested in coming?</comment>


Why develpoers spend tons of time working on open source projects - <AUTHOR> http://www.businessinsider.com/why-developers-contribute-to-open-source-projects-2015-6?utm_source=mobilesrepublic&utm_medium=referral&utm_term=mobilesrepublic

<comment><USER2> I wrote a couple nifty After Dark screensavers back in the day, as well as a test harness that made it easier to debug them. I released the source code for all of them.

My former employer, Dave Johnson of Working Software, repeatedly urged me not to write any software that I was not paid to write.

I wrote those screensavers, and gave them away because I enjoyed the experience.

I still have a shareware CD from Japan, its shrinkwrap unopened, that came with a cover letter that said "Dear Great Soft-Maker".

That one letter made it all worthwhile.</comment>


Show HN: Meetingplace.io – An Alternative to Meetup - <AUTHOR> https://meetingplace.io/ <comment><AUTHOR> Hi HN! I started MeetingPlace 2 months ago after Meetup's $2 RSVP pricing test announcement, which didn't sit well with me at all as a group organizer: [https://www.meetup.com/lp/payment- test-20191016](https://www.meetup.com/lp/payment-test-20191016)

In just two months 65 groups have gone live, with over 450 people signing up - which I think is pretty awesome!

From a technical side, it uses Rails 6 with React for the tricky UI parts. ActionText is probably my favorite new rails feature for the rich text boxes - it was super easy to set up!</comment>


How to Write a Ray Tracer Intuitively - <AUTHOR> https://blog.scottlogic.com/2020/03/10/raytracer-how-to.html <comment><USER2> There's no need to involve rotation matrices (or any kind of matrices at all) for basic ray tracing, it's just a basic exercise in vector arithmetic.

<comment><USER3> There's no need to differentiate between vectors and matrices in this sort of work, other than as shorthand for dimensional information. [0] is another example of a ray-tracing tutorial which, by virtue of using GLSL, doesn't draw a hard line between matrices and vectors.

[0] [http://jamie-wong.com/2016/07/15/ray-marching-signed- distanc...](http://jamie-wong.com/2016/07/15/ray-marching-signed-distance- functions/)</comment></comment>


Apple is either terrible at designing charts or thinks you won't notice - <AUTHOR> http://qz.com/138458/apple-is-either-terrible-at-designing-charts-or-thinks-you-wont-notice-the-difference/

<comment><USER2> It's marketing; trying to convey an emotion, an experience, of how much apple is the popular kid and you should all be part of it. It's taking off! It's all about preaching to the church of Apple.</comment>


Launch HN: Aquarium (YC S20) – Improve Your ML Dataset Quality - <AUTHOR> Hi everyone! I'm Peter from Aquarium (https://www.aquariumlearning.com/). We help deep learning developers find problems in their datasets and models, then help fix them by smartly curating their datasets. We want to build the same high-power tooling for data curation that sophisticated ML companies like Cruise, Waymo, and Tesla have and bring it to the masses.
ML models are defined by a combination of code and the data that the code trains on. A programmer must think hard about what behavior they want from their model, assemble a dataset of labeled examples of what they want their model to do, and then train their model on that dataset. As they encounter errors in production, they must collect and label data for the model to train on to fix these errors, and verify they're fixed by monitoring the model's performance on a test set with previous failure cases. See Andrej Karpathy's Software 2.0 article (https://medium.com/@karpathy/software-2-0-a64152b37c35) for a great description of this workflow.
My cofounder Quinn and I were early engineers at Cruise Automation (YC W14), where we built the perception stack + ML infrastructure for self driving cars. Quinn was tech lead of the ML infrastructure team and I was tech lead for the Perception team. We frequently ran into problems with our dataset that we needed to fix, and we found that most model improvement came from improvement to a dataset's variety and quality. Basically, ML models are only as good as the datasets they're trained on.
ML datasets need variety so the model can train on the types of data that it will see in production environments. In one case, a safety driver noticed that our car was not detecting green construction cones. Why? When we looked into our dataset, it turned out that almost all of the cones we had labeled were orange. Our model had not seen many examples of green cones at training time, so it was performing quite badly on this object in production. We found and labeled more green cones into our training dataset, retrained the model, and it detected green cones just fine.
ML datasets need clean and consistent data so the model does not learn the wrong behavior. In another case, we retrained our model on a new batch of data that came from our labelers and it was performing much worse on detecting "slow signs" in our test dataset. After days of careful investigation, we realized it was due to a change to our labeling process that caused our labelers to label many "speed limit signs" as "slow signs," which was confusing the model and causing it to perform badly on detecting "slow signs." We fixed our labeling process, did an additional QA pass over our dataset to fix the bad labels, retrained our model on the clean data, and the problems went away.
While there's a lot of tooling out there to debug and improve code, there's not a lot of tooling to debug and improve datasets. As a result, it's extremely painful to identify issues with variety and quality and appropriately modify datasets to fix them. ML engineers often encounter scenarios like:
Your model's accuracy measured on the test set is at 80%. You abstractly understand that the model is failing on the remaining 20% and you have no idea why.
Your model does great on your test set but performs disastrously when you deploy it to production and you have no idea why.
You retrain your model on some new data that came in, it's worse, and you have no idea why.
ML teams want to understand what's in their datasets, find problems in their dataset and model performance, and then edit / sample data to fix these problems. Most teams end up building their own one-off tooling in-house that isn't very good. This tooling typically relies on naive methods of data curation that are really manual and involve "eyeballing" many examples in your dataset to discover labeling errors / failure patterns. This works well for small datasets but starts to fail as your dataset size grows above a few thousand examples.
Aquarium's technology relies on letting your trained ML model do the work of guiding what parts of the dataset to pay attention to. Users can get started by submitting their labels and corresponding model predictions through our API. Then Aquarium lets users drill into their model performance - for example, visualize all examples where we confused a labeled car for a pedestrian from this date range - so users can understand the different failure modes of a model. Aquarium also finds examples where your model has the highest loss / disagreement with your labeled dataset, which tends to surface many labeling errors (ie, the model is right and the label is wrong!).
Users can also provide their model's embeddings for each entry, which are an anonymized representation of what their model "thought" about the data. The neural network embeddings for a datapoint (generated by either our users' neural networks or by our stable of pretrained nets) encode the input data into a relatively short vector of floats. We can then identify outliers and group together examples in a dataset by analyzing the distances between these embeddings. We also provide a nice thousand-foot-view visualization of embeddings that allows users to zoom into interesting parts of their dataset. (https://youtu.be/DHABgXXe-Fs?t=139)
Since embeddings can be extracted from most neural networks, this makes our platform very general. We have successfully analyzed dataset + models operating on images, 3D point clouds from depth sensors, and audio.
After finding problems, Aquarium helps users solve them by editing or adding data. After finding bad data, Aquarium integrates into our users' labeling platforms to automatically correct labeling errors. After finding patterns of model failures, Aquarium samples similar examples from users' unlabeled datasets (green cones) and sends those to labeling.
Think about this as a platform for interactive learning. By focusing on the most "important" areas of the dataset that the model is consistently getting wrong, we increase the leverage of ML teams to sift through massive datasets and decide on the proper corrective action to improve their model performance.
Our goal is to build tools to reduce or eliminate the need for ML engineers to handhold the process of improving model performance through data curation - basically, Andrej Karpathy's Operation Vacation concept (https://youtu.be/g2R2T631x7k?t=820) as a service.
If any of those experiences speak to you, we'd love to hear your thoughts and feedback. We'll be here to answer any questions you might have! <comment><USER2> I'm an Aquarium user. There are two ways Aquarium provides value to my company. First, we improved our model performance. Second, I spent less time and less clicks curating my dataset.

Regarding model performance, I used Aquarium to improve the AUC for my model by 18 percentage points (i.e., comparing the AUC for the first model trained on my new dataset to the AUC for my production model).

Regarding dataset curation efficiency, I spent much less time curating my dataset using Aquarium than I would have spent using our own in-house tooling. For example, the embedding-based point cloud allowed me to identify lots of images with an issue at once, rather than image by image, click by click.

This thread has been mostly focused on improving model performance (i.e., my first point), but Aquarium is also valuable for improving model curation labor efficiency (i.e., my second point). For the business owner, dataset curation labor efficiency means less money wasted on having some of your most expensive employees, ML data scientists, clicking around and writing ad-hoc scripts. For the ML practitioner, dataset curation labor efficiency means fewer clicks and less wear on your carpal tunnels.

The founders, Peter and Quinn, didn't ask me to write this. I chose to write it because it's a great product that I think can help a lot of businesses and people.

<comment><USER3> To second your comment, I think non ML folks don't understand how much of an impact dataset curation can have on model performance. More high-quality data will outshine clever network architectures with less data. I've seen it again and again. But the thing is, it's so hard to really curate your data once the dataset has a lot of "dimensionality" to it (sorry couldn't think of a better word...). To be honest, if I were to pick an area of dev-tool I'm most excited about over the next 5 years, this area is probably it.

<comment><USER3> Btw, for anyone interested, here's a good/quick talk by Andrej Kapathy on what it will take to build the next software stack. [https://www.youtube.com/watch?v=y57wwucbXR8&t=3s](https://www.youtube.com/watch?v=y57wwucbXR8&t=3s)

</comment></comment></comment><comment><USER4> Hey! DVC maintainer and co-founder here. First of all, congrats and let me know if we can help you or you have some collaboration in mind! A few questions - how does workflow look like - do you expect users to upload all data to your service? How can data then be consumed from the platform?

<comment><AUTHOR> Thanks!

We don't expect users to upload all data to our service - the type of data we're interested in is "metadata." URLs to the raw data, labels, inferences, embeddings, and any additional attributes for their dataset. Users can POST this to our API and we'll ingest it that way.

If users don't provide their own embeddings, we need access to the raw data so we can run our pretrained models on the data to generate embeddings.

However, if users do provide their own embeddings, we would never need access to the raw data - Aquarium operates on embeddings, so the raw data URLs would be purely for visualization within the UI. This is really nice because it means that we can access restrict URLs so only customers can visualize it (via URL signing endpoints, only authorizing IP addresses within customer VPNs, Okta integration) and Aquarium would operate on relatively anonymized embeddings and metadata.

</comment></comment><comment><USER5> Thanks for all the hard work and congrats on your launch!

I will definitely check this service out for a side project I'm working on that combines basketball and AI ([https://www.myshotcount.com/](https://www.myshotcount.com/))

<comment><AUTHOR> Yup, I saw your form submission through our site! I reached out to you over email, I'm confident we can help out :)

</comment></comment><comment><USER6> I think is a great idea because as you mentioned quality Datasets can make your model work or not at all. However this is not addressing the big elephant in the room. Which is: no matter how much you curate or clean the data, you are limited to the dataset that you have. The big answer would be, how can you get more and better datasets. I think tooling is super important, but the big difference will be, how to collect/generate/capture reliable, defendable, datasets moving forward. I think your idea is complementary to this other project: [https://delegate.dev](https://delegate.dev)

<comment><AUTHOR> I absolutely, 120% agree on the importance of adding the right data. Aquarium helps you with: "what data should I be collecting to improve my model" and "where do I find that data?"

For the latter, Aquarium treats the problem of smart data sampling as a search and retrieval problem. You want to find more examples of a "target" from a large stream of unlabeled data. Aquarium does this by comparing embeddings of the unlabeled data to your "target set" and then sending examples to labeling if they're within a defined distance threshold in embedding space. We don't actually do the labeling, but we wrap around common labeling providers and can integrate into in-house flows with our API.

<comment><USER7> Other founder here! For a high level overview of this framing of the problem, I recommend reading this Waymo blog post [1].

One nice feature is that by using embeddings produced by a user's model, which has been trained in the context of their domain, we can do this sort of smart sampling in domains we've never seen before. Embeddings are also naturally anonymized, so we can do this without access to a user's potentially private raw data streams.

[1] [https://blog.waymo.com/2020/02/content- search.html](https://blog.waymo.com/2020/02/content-search.html)

</comment></comment></comment><comment><USER8> Dear @pgao thank you for the long intro with references and explanations. I went to your website and noticed the "getting started" is a contact form. Curious -- are you making a product to do this, or is it more consulting/advisory? I'm currently creating some fun datasets for public usage and i'd love to be a test rat for your software.

<comment><AUTHOR> Hey there, it's a product right now! Our goal is to make it self serve, but we're currently onboarding people one-by-one manually until we can streamline the onboarding flow and build out a self serve process. Feel free to DM me or fill out the form and I can send you our public demo!

</comment></comment><comment><USER9> Thanks for sharing @pgao! This tool looks really valuable.

> Since embeddings can be extracted from most neural networks, this makes our > platform very general. We have successfully analyzed dataset + models > operating on images, 3D point clouds from depth sensors, and audio.

Are there any types of datasets/models that this tool would not work well with that you're aware of?

<comment><AUTHOR> Thanks a bunch!

I think the biggest issues with this approach is the requirement for embeddings. It's hard sometimes for a customer to understand what layer to pull out of their net to send to us, so sometimes we just use a pretrained net to generate embeddings. One net for audio, one net for imagery, one net for pointclouds, etc.

I'd say that it's harder for this tool to work with structured/tabular data for a few reasons.

One, most structured datasets are domain-specific, so it's not easy to pull a pretrained model off the shelf to generate embeddings - typically we would need a customer to give us the embeddings from their own model in these cases.

Two, neural nets actually aren't the best for certain structured data tasks. Tree-based techniques often get better performance on simpler tasks, which means there's no obvious embedding to pull from the model.

Three, an alternate interpretation is that a feature vector input for structured data tasks is already an embedding! When the input data is low dimensional, you can do anomaly detection and clustering just by histogramming and other basic population statistics on your data, so it's a lot easier than dealing with unstructured data like imagery.

So I wouldn't say that our tooling wouldn't work for structured data, but more that in those types of cases, maybe there's something simpler that works just as well.

</comment></comment><comment><USER10> If I understand correctly, it sounds like your platform is primarily intended for improving awareness and understanding of the data a team has, so they know which features to focus on and emphasize.

Do you think you'll get into synthetic data generation as well? In other words, improving dataset quality additively, not just curatively.

<comment><AUTHOR> Yes, your interpretation is correct. I don't think we're going to get into synthetic data generation in the near term, mainly due to the amount of effort required + questions about domain transfer. However, we do improve dataset quality additively by sampling the best data to label + retrain on to get the best performance.

Said another way: once you've found "I do badly on green cones," we use similarity search on the embeddings of known green cone examples to find more instances of green cones in the wild. We pick the right examples from streams of unlabeled data, then send it to labeling + add to your dataset so it does better the next time you retrain.

<comment><USER11> I like this much better than synthetic data augmentation actually. I think synthetic augmentation, like with GANs is actually a failed concept.

There has long been theoretical limits around how much you can gain by ensembling with a model of known limitations, and this is all that synthetic training data is at root.

You can't "make up" training data that allows you to escape the ceiling of performance implied by whatever generator process you use for the synthetic data, no differently than you can't learning a better regression just by bootstrapping a large sample of data from your existing training set.

Algorithmic synthetic data is a big type of fool's gold.

</comment></comment></comment><comment><USER12> Have tested the tool a little bit for audio, and see a potential here. Especially useful for anyone who has a relatively large amount of unlabeled data, and want to be efficient in terms of what samples to spend resources labeling.

<comment><AUTHOR> Thanks for the shoutout! We got connected to jononor through our previous r/machinelearning launch: [https://www.reddit.com/r/MachineLearning/comments/hjbl4h/p_l...](https://www.reddit.com/r/MachineLearning/comments/hjbl4h/p_launching_aquarium_understand_and_improve_ml/)</comment></comment>


Octopoda might be Aliens!?! - <AUTHOR> https://www.sciencedirect.com/science/article/pii/S0079610718300798?via%3Dihub <comment><USER2> I have seen octopuses, octopi and octopodes, but never "octopoda." I think any one of the first three would have been more correct than the last :)

EDIT: I'm the dunce, turns out octopoda is the scientific name. TIL! Guess I was thrown off by the plural "aliens."

<comment><USER3> Its Greek, right? That sounds like octopuses should be the normal plural.

Anyway, octopoda is the biological classification order that the octopus belongs to. So its a little iffy if the 'might be' is appropriate. Maybe "Octopoda are Aliens" would work better? Or "Octopoda is alien"?

<comment><USER4> Our current system of taxonomy assumes common ancestry. So, technically, if octopuses do descend from from aliens, the classification "Octopoda" is itself erroneous.</comment></comment></comment>


Bad Decision there mate - <AUTHOR>

After reading Junk Yard Sam's post at http://www.junkyardsam.com/blog/2015/4/15/foursquare I was wondering if there should be a site dedicated to people who's actions have been disastrous to tech companies. A bit like glassdoor.co.uk but for people.<p>Staying away from the obvious (review verification, tit-for-tat threads and litigation), is there a need for such a site? <comment><USER2> Such an idea would sell better if it was marketed under comedy and not necessity.

<comment><AUTHOR> Some people have a lot of money ridding on comedy ;)</comment></comment>


Don't work "remotely" - <AUTHOR> http://blairreeves.me/2018/11/09/dont-work-remotely/?resubmit=hn <comment><USER3> I usually appreciate a good semantic argument, but not really sure what it adds in this context? I think the root of every conversation on "remote", "distributed", or "agile" working is not how it's perceived from a nomenclature perspective, but that it's something that _has_ to be open to everyone. You need to work somewhere where the default is non-location, only- core-hours specific, otherwise it falls down.

Am fortunate to work in a place that offers "agile" working (it's not a developer focused environment, so that word isn't loaded for us). You go where you need to to get the job done, within a set of core hours work how you need to. You can work from home independently for days or weeks on end, or you can turn up to a desk every day, or you can collaborate in a meeting room, on Skype, or in a cafe.

We have an HQ, but not enough desks for everyone to turn up every day, so there's an expectation of being fluid in how you work. Every meeting has a video conference link, and very few decisions are made by the proverbial watercooler. It takes time and discipline to make it work, but that's spread by default and expected across the entire workforce.

<comment><USER4> As a long time remote worker, I've found that what seems like a hair-splitty difference can actually be a deep insight into the company's culture, and how it will affect your work experience.

Distributed teams develop a culture of communication that does not rely on frequent face-to-face contact. I personally suspect that they tend to be even more productive than completely co-located teams, because, based on a sample size of one, I've seen that the communication methods they develop will require fewer person-hours to share more information at higher fidelity.

"Remote" tends to imply a large chunk of the team is co-located, and one or more of the members are not. My experience here is that the remote people tend to not get the memo, or people fail to invite them to meetings because they don't want to bother with the conference room's videoconferencing equipment, or they _do_ invite the remote folks but then the first 15 minutes of the meeting is devoted to figuring out how to work the Polycom system, etc.

I had the pleasure of working on a distributed team that became a team with remote workers as a result of being acquired by a company that decided to only hire new people to work in their home office. It was impressive how quickly things fell apart after that.

(Edit: This isn't to say that P's team isn't working well with a flexible approach, but it sounds like there's a big difference between it and many other non-distributed teams that have remote work: Everyone is in it together.)

<comment><USER5> I've seen it even within teams in the same corporation: some are used to working distributed, for whatever reasons (e.g. working on truly open-source projects/ with external collaborators); others highlight the "efficiency" of co-location, and try to get everybody working on the same project in the same office.

In my experience, the former is far more effective, for a very simple reason: informal communication channels quickly break down. In the latter approach - you have decisions discussed between some people, with others not informed, not documented properly, forgotten after a while, shifting agreements etc. Because the team can be more "agile" it's less structured, and while on the short term it may seem to be a good thing, on the long term it really hurts it (working on the wrong things/ on things that are not needed anymore, constant overhead for on-boarding new people, loss of team knowledge with every "old" team member that leaves, etc).

I'd say the distinction between "remote" and "distributed" workers is on how serious the team is about enabling remote work. If it treats remote workers as a secondary, "extension team" \- things don't work well. If that's the primary mode of operation - things actually end up working _better_ than in co-located teams, in most situations(read: as soon as the team/product grows big enough).

<comment><USER6> There's not enough pressure to prevent tribal knowledge from becoming the pattern. If you have to write everything down at least once, you're part way to solving the problem.

</comment></comment></comment></comment><comment><USER7> It all comes down to 2 things:

\- If you're single, working at an office is good for you. Surround yourself with people who share a common interest. Yeah, it's work, but I'm sure you'll meet people who have similar interests outside of work. Go share a 2 bedroom apartment with someone else in downtown and enjoy the social life.

\- If you're married (or even with kids), remote work is what you should be looking for so that you take away the bad energy you collect at the office and you don't bring it back home. You can spend more time with your family which is what matters the most. The bad energy includes a long commute to get to work since you can't afford living next to the office. Competitive environment and politics. Dress code, loud open space environments where you can't get anything done, constant distraction, having to fake working 8h straight sitting in front of a screen while anyone can look over your shoulders. You need to be able to afford a bigger home to host your family so you need to move far from your office.

You can get flexibility in both, not only remotely. As long as you're not forced to commute more than 30 min to work, usually Tech giants are flexible companies in terms of hours, etc.

<comment><USER8> This is bad advice because each and every pro listed when you're married is also a pro when not married. So I guess I don't get it. Also, there are a million ways to meet people and from my experience meeting people through work is really one of the worst ways to go about it (if you're looking for a relationship). Go join a singles club or something.

<comment><USER9> For many people, their coworkers are their main group of friends. I personally would have fewer friends if I worked remotely. If I was married, I would prioritize my family over my friends, and would likely prefer remote work.

<comment><USER10> > For many people, their coworkers are their main group of friends.

From what I've experienced, this is true only until your late 20s, or about 20% of your career.

<comment><USER7> +1

This is really true. I made amazing friends at my first 2 jobs and since then, nothing but work. The culture has changed as well for the last 10 years. Colleagues don't even say "hi" anymore. When you're already established in your life you usually don't have time to make friends at work.

</comment></comment></comment></comment></comment><comment><USER11> The primary difficulties i have with remote work are linked:

1\. I usually wind up alphabetizing my socks at some point.

2\. a lack of face to face contact and the setting of being in my own space keeps me in a semi-permanent doubt/guilt cycle about my work quality and how my effort and reponsiveness is being perceived.

<comment><USER12> I've been working remotely for just a few months shy of 5 years. I've moved from coast to coast in that time. I've held 4 different positions in the same company. The _only_ thing that has worked for #2 is relying less on Slack and email and more on phone calls. It completely eliminates the guilt factor. I encourage everyone on my team to be more open to phone calls during the day. No real work gets done on slack. Call each other.

<comment><USER13> I'm not somebody who likes or needs phone calls. They disrupt any flow I've got and require time coordination. So I definitely don't appreciate it when a manager forces me into them when that is something that suits his personality and management philosophy.

Since I'm not forcing him to meet my emotional neediness, why should he force me?

<comment><USER14> Does Slack not disrupt your flow? Or putting an email together?

<comment><USER15> Personally I find that they can, but they don't have to. I can put off Slack/email until I hit a stopping point, or I can wedge it into the middle of a long-running process (start a build/test-cycle/deployment, then go answer Slack). At the very least I can finish the chunk of code/whatever I was working on. Phone calls and in-person talking are a hard interrupt, drop all my context on the floor and get nothing else done.

</comment></comment></comment></comment></comment><comment><USER16> I feel like the post is a 25 cent practices discussion wrapped in a $25 semantics discussion, with the added injury of a click bait title.

<comment><USER17> I was expecting something interesting about the problems of working remote. Just closed the article when I realized the main point of the article was to keep doing what you are doing but call it something else.

</comment></comment><comment><USER18> The most annoying thing about the tech giants that askew remote is that they also choose to locate themselves in the most expensive cities in the country.

Here's a tweet today from the creator of Babel on how he is moving to the east bay because housing is more affordable. [https://twitter.com/sebmck/status/1064252136349822977](https://twitter.com/sebmck/status/1064252136349822977) .

If someone who's created that much value is not able to afford an area then it's insulting that tech giants expect us to move there (or have a 2 hour commute to somewhere affordable).

There's this terrible myth that I want to kill; that software engineering is a well-paid field. That's a lie.

Here's something pharmacists, account managers, farmers can afford: 3 bedroom, 2 bathroom houses near where they work.

We can't. We're asked to live in apartments in Jersey and commute 45 minutes to Manhattan every day.

Or we work remotely and are expected to take a smaller wage, where the company can't wait to get big enough so that it can force us all to move.

<comment><USER19> > There's this terrible myth that I want to kill; that software engineering is > a well-paid field. That's a lie.

For me it's been very profitable.

> Here's something pharmacists, account managers, farmers can afford: 3 > bedroom, 2 bathroom houses near where they work.

I can easily afford that. Most software engineers I know can afford that.

> We can't. We're asked to live in apartments in Jersey and commute 45 minutes > to Manhattan every day.

I don't live in NYC. I work from home or from an office 5min away from my home.

> Or we work remotely and are expected to take a smaller wage

I work remotely and earn more than most engineers in SF. I save 300-400% more.

> where the company can't wait to get big enough so that it can force us all > to move.

I've never experienced this.

<comment><USER20> All of your points here are "me, me, me". Well, good for you? The fact that you, a rich guy working from home, who never experienced these issues is merely an anecdote. It doesn't contribute anything to the discussion, it just states your own dissatisfaction with GPs comment to which I would reply with "so what?"

<comment><USER19> GP's experience is also anecdotal because software engineering clearly is a well paid field, AS IN better paid than the majority of other fields.

Feeling victimized because you have to commute for 45 minutes, do your cushy job, and get paid incredibly well compared to most of your fellow citizens is just sad.

This mentality does not represent the majority of software engineers. Most of us are (among other things) grateful and content, thank you.

<comment><USER21> Science has shown commuting to be quite bad for health: [http://time.com/9912/10-things-your-commute-does-to-your- bod...](http://time.com/9912/10-things-your-commute-does-to-your-body)

</comment></comment></comment></comment></comment><comment><USER22> As somebody who is currently working remotely, I think this is a decent take. A distributed culture can definitely get better results than a remote one. But there's something in the section on collaboration I want to take issue with:

> Product Management is mostly about consistent execution of plans, not > painting high-level visions.

It's a common view that software developers are an output device, like a printer. You tell them what to build by sending them very detailed instructions. They follow the instructions to the letter, and their work is judged by compliance. Perfection is perfectly conforming to some one else's plan.

I think this is bunk. It might have made a little sense when releases were every 18 months to 3 years. But in an age where companies are releasing dozens of times per day [1], it's foolish. Perfectly following a plan means you believe nobody will learn anything during the time it takes to follow the plan. But if you are releasing early and often, you can learn a ton from users. You can be much more innovative and much more effective than competition.

That only happens, though, if you treat team members not as rote plan- followers but as creative professionals who are deep collaborators. Where vision isn't something a few HiPPOs hammer out in exclusive twice-annual sessions, but where everyone constantly participates and refines it. If a company's process has already shut down collaboration, then of course the difficulties of remote collaboration aren't a problem. The challenge -- still unsolved, I think -- is how to maintain both a high level of collaboration and fast iteration without having to have everyone together.

[1] E.g., [https://www.infoq.com/news/2014/03/etsy-deploy-50-times-a- da...](https://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day)

<comment><USER23> He goes in more details about product management here: http ://blairreeves.me/2018/10/16/whats-a-senior-product-managers-job/

I don't believe his view conflicts with yours.

I think it's very possible to have someone present to help define value and priorities, and focus on the people part of getting shit built, while giving engineers a lot of creative involvement and ownership.

<comment><USER22> I agree it's possible. I disagree it's compatible with seeing product management as being about consistent execution of plans.

<comment><USER23> Ah, I read that phrase differently, but think I see your point now. There's definitely a type of "plan" that can be very micromanagey, and problematic.

I've lucked out and most plans I've worked with are super, super high level and gives everyone a lot of freedom.

</comment></comment></comment></comment><comment><USER24> I absolutely detest every single aspect of remote work. Every time my coworkers or I wfh (and all companies I worked were very lax as to when you can wfh) small, tiny communication problems start occurring that bite us in the future. I find it easier to motivate myself in the office, with people, free snacks/food. I don't think slack/hangouts is a replacement for face-to- face conversation. I cannot even imagine working remote full time. It's not just that I don't trust myself, I don't trust other people too.

<comment><USER20> You are getting a barrage of comments telling you that _you_ are the problem, so let me just say I completely agree with you.

I have multiple colleagues who just casually disappear from the office (sorry, "work from home") for days to weeks and it's beyond irritating and disruptive to the rest of us.

<comment><USER24> I think it's irrelevant if I'm the problem or not. I'm still hired for the job and given (1) I have no communication problem when we're face to face and (2) when people wfh I observe people other me also have communication problems, the only way this can be relevant if my employer is willing to fire me -- and nobody else -- for having communication problems when people other than me disappear (I never ever wfh unless I'm sick so I have a potential to make other people at work sick).

> I have multiple colleagues who just casually disappear from the office > (sorry, "work from home") for days to weeks and it's beyond irritating and > disruptive to the rest of us.

I cannot agree more. I would also add that (you might not agree with this) this is not just a tiny, minor problem, inconvenience, I think this can possibly cause major problems, especially in the design phase of systems. If the design is not communicated _perfectly_ there _will_ be problems and the only way to ensure this is to communicate face-to-face long enough that all engineers agree design is impeccable. Call me old school.

<comment><USER25> If faces are that important to your design process, you can use video chat. There is nothing that can be communicated in the same room but not over video chat. I don't know what the problem you're encountering is — whether you're the problem or your work has implemented remote work poorly or your coworkers are just weird and pathological — but it really seems like you're misidentifying it.

<comment><USER26> Smells are key to the design process.

</comment></comment></comment></comment></comment><comment><USER27> Maybe I'm just a grouch in general, but I pray for a time when we have sufficient data available that this ceaseless and monotonous drone of posts about whether remote work is the best thing since sliced bread or if it's the 7th sign of the apocalypse can just all be replaced by "here are the data and there are some pretty clear conclusions that answer questions X, Y, and Z".

Anyone who knows more about this than I do, are we close to that day?

<comment><USER28> Since, I suspect the answer tends tobe driven by the culture of an organisation, and within individual teams within it, and by the proclivities of individual workers, I fear you may be waiting a long time.

<comment><USER27> That's true of any kind of success in any organization, yet there are still studies that show that certain types of traits indicate success at certain types of organizations, etc. Even in a general sense, I'd be happy if these types of conversations could have data-driven discussions.

<comment><USER29> You need to be careful of cargo culting though. There have been a lot of "traits of successful organizations" types of books and papers over the years. And it often turns out that there are unsuccessful organizations that often have very similar characteristics and successful organizations that take the opposite approach.

<comment><USER27> Well that's fair. If it's all unknowable anyway, I'd be happy to know that. Anything that lessens the blogspam on the topic!

</comment></comment></comment></comment></comment><comment><USER30> I'm convinced it's possible for a business to work in a distributed manner, but I think there are certain business scenarios (and/or persons' personality types/collaboration styles) where it's problematic. Anecdote:

I've been in two startups, one working remotely ("distributed") and one working in the room with the CEO.

The degree of situational awareness was very different.

When I was sitting 5 feet from the CEO, I knew the company was in the tank and in grave danger of going under. We turned it around.

When I was remote, based on the daily/weekly phone calls I knew the project I was working on was in trouble and way behind, but had no idea till the CEO drove up to meet me that he and the other execs had no salary for 3 months and the company was out of money. (They found a buyer for a pittance within a year to save face.)

I had a sense of urgency in both cases... but the urgency was different when in-person. And the awareness was WAY different.

<comment><USER31> Real questions from someone who has been leading remote teams for awhile:

Which one helped you better focus on your role and deliver what you needed to help the company?

Hearing all these things in-person can definitely be good context, but there is also a risk that you hear something wrong, succumb to gossip, or lose focus based on worries that may not be necessary. (Of course I'd argue it's best for the employee to judge rather than be left in the dark, but I'm curious here specifically)

Part of this comes down to company culture as well - getting remote comms channels down is really hard, and takes a LOT of effort from senior management, especially for things that are nuanced or may change. How do you not panic anyone but also let them know there may be a need for urgency, etc (in-person works well for that)

When you were remote, was the CEO remote as well, or just you?

<comment><USER30> It's an interesting question- which one helped me focus on my role and deliver? I can see in the abstract that distributed work can both demand and benefit from strong focus. In my case, when I was a "distributed" worker I had a much narrower scope of responsibility and along with that, less ability to gauge whether something was "good enough" to ship and perfectionism/procrastination and poor remote communication on my part really hampered my work. As an in-person worker, when we were betting the company I was able to constantly assess all work being done by all the company and pivot us and others to what was the most risk-mitigating thing we needed to do. When distributed, I suppose that was the role my Engineering VP was supposed to do and I was just focused on my narrow domain, but overall the company wasn't able to leverage my problem solving and triaging strengths and I was just a remote coder/designer resource with a task. When it was late, I knew it was bad, but I didn't have a sense of the consequences to the broader team (just my own job). In hindsight I think management was trying to shelter me from the stress and I respect that but I was really stunned at the end of the day how out of the loop I was. I was East Coast, CEO was East Coast but four hours away, some execs were West Coast, Engineering Lead was UK. I did a great job for them with engineering for in-person clients, but when I switched to being managed from overseas it really didn't work out. I always didn't want to interrupt the UK VP since he was so busy and/or because I was behind but the communication dynamic was ultimately dysfunctional for which I take more than half the responsibility. (I have since been on the flip side of that coin with a remote worker! It's an interesting challenge.)

<comment><USER31> Thanks for these answers - super interesting and helpful. Much appreciated!

</comment></comment></comment></comment><comment><USER32> Yeah, this is actually a really good point and I didn't notice it before - "remote" is a relative word and implies there is a place that you're _not_ which is considered the center of action.

But whatever word is used.. maybe it won't matter for that much longer? I think another thing that will be interesting to watch is if/how quickly the extra word "remote"/"distributed"/etc disappears because it becomes redundant or outmoded.

Think of the internet: every service on the internet was once "e-{service}". Over time that mostly just became "service", because the fact you are on the internet is now assumed, and doesn't have to be qualified. Indeed, if you're _not_ on the internet _that_ might be the thing you have to qualify now.

Will we see job listings in 10-15 years with "Engineer (Colocated Office)"?

<comment><USER33> I think yes. Just as horseless carriage became car, remote will become norm in a few decades.

</comment></comment><comment><USER34> "...That said, I just don't encounter the need for deep strategy and vision- setting sessions with cross-functional teams of my colleagues on a frequent basis. ..."

And you won't, either.

I think this is very simple. Either you are a distributed team working on digital artifacts that live primarily online .... or you are a cross- functional team trying to creatively solve a problem for somebody.

If you know what you're doing, the solution is locked in, and all you're accomplishing by showing up somewhere is moving cards around on a wall? Stay home. If you don't know what you're doing -- requirements are in flux, the customer can't decide, the project is high-risk/high-stress, etc? Show up where the other people are.

And it doesn't have to be one way or the other. I've worked great projects where we all co-located, got into a groove, then finished it up from home -- only to repeat when the next big hunk of problems showed up.

So many of these tech essays seem to based on turning the contrast way up, insisting that the answer must be X or Y, then defending it. Why can't it be both? Seeing success in teams working both ways, wouldn't the more logical position be that in some cases each has its advantages?

<comment><USER35> I read the post as venting disappointment towards the strong anti-remote-work bias, for what it's worth.

</comment></comment><comment><USER36> Remote (or distributed, as article is advocating to call it) work will not fit everyone's style. It requires certain level of self discipline and recognition that the one needs to develop certain habits in order to be able to efficiently deliver work while doing this remotely.

What I noticed is that in early days of my startup when I was working remotely I was able to contribute much more than now, when I'm required to work from the (open plan) office. Working remotely gives flexibility on work hours (i.e. I could do normal 9-5 and then in the evening I usually checked in to add some extra but I could do that as I did not have to wake up early in the morning in order to commute to the office).

Working remotely makes it more challenging (for some) to resist temptation to procrastinate. And also it requires leaders to understand how to measure the output (although, of course, leaders need to understand that despite the fact where does the worker deliver their work from).

</comment><comment><USER37> That floating header on the site is amazingly annoying.

Reading, and scrolling down a bit on the mouse, so the content I'm reading reaches the top of the page. Maybe a second after I stop scrolling, boom, suddenly the header re-appears out of nowhere and covers right what I'm reading. I actually gave up reading the content, not because I wasn't interested, but because that damn header kept hiding the content.

<comment><USER38> Save this as a bookmark and click it to eliminate floating headers: javascript:

      (function()%7B(function%20()%20%7Bvar%20i%2C%20elements%20%3D%20document.querySelectorAll('body%20*')%3Bfor%20(i%20%3D%200%3B%20i%20%3C%20elements.length%3B%20i%2B%2B)%20%7Bif%20(getComputedStyle(elements%5Bi%5D).position%20%3D%3D%3D%20'fixed')%20%7Belements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B%7D%7D%7D)()%7D)()

</comment></comment><comment><USER39> Remote work is fine if you dont mind being pigeon holed into one range of tasks, paid well relative to your cost of living, have no career advancement, and want to wear whatever you want at work.

<comment><USER40> I've been working "distributed" (per the article) for about 17 years. My range of tasks has been across the board (engineering, support, presales, ops, etc). I've had quite a bit of career advancement (although I don't really care about titles).... and I get payed CA salary while not living in CA.

Just wanted to post so folks understand there is a range of opportunities out there... you just need to find them...

<comment><USER41> I have a very hard time believing a real CA salary is being paid to remote workers. For engineering at leading companies, seventeen years of experience would be over 400K TC. However, I could believe someone paying a remote worker on the low end of entry-level compensation of around 120K for remote work.

<comment><USER42> It's not at all hard to believe _some_ people are receiving CA salaries (and note, your 400k TC line only applies to a relatively small group of companies and senior positions).

On the other hand, I agree it is unlikely for the majority of remote workers. Depends a lot on your skill level and how rare/in-demand it is I suppose.

<comment><USER40> Ska's spot on here. We're not paying high end CA wages to _everyone_; however, our remote employees are making _much_ higher than the norms in most of their areas. We require a lot of breadth/depth for the main remote position. If you were to look at glassdoor, comparably, or paysa .. they would suggest this position for our company pays on average of 145 to 150k salary (w/o bonus / RSUs .. which would significantly raise that num obvi).

At most places the "talent is your #1 resource" is bullshit. Ours is not and is a key to us being profitable (it's actually rolled into our comp model).

</comment></comment></comment></comment></comment><comment><USER43> I've ran a distributed company for about 6 years now.

We started as a conventional company located in San Francisco.

For some context - we're [https://www.datastreamer.io](https://www.datastreamer.io) ... we provide data feeds around blogs, news, and social media to search engines, and data analytics companies. We have about a petabyte of content in our index now.

Our SF location was SWEET. Downtown. 100 year old building. Brick walls, super nice place - until they tore it down to build the new Transbay terminal.

Long story short but at that point we decided to give distributed work a try.

Back then there weren't many companies doing it but I decided to embrace the benefits of it in terms of what it could do for my company.

This isn't discussed often but there are actually PERKS to distributed work.

If your team is in different timezones. This means you can coordinate ops so that if there's an emergency no one actually has to wake up.

This has massive long term implications for morale and hiring!

You can now hire ops people and tell them that they never have to be woken up in the middle of the night.

We will often have issues with data indexing of sites at odd hours. We can't control when a site being indexed breaks so it can happen at unusual times. Usually at 5AM when I'm sleeping.

One downside is that each country has its own hurdles for hiring.

My advice is find 2-4 countries (including your own) that are close to your timezone. You will have banking, political, and infrastructure issues so limiting the number of distinct countries you work with reduces your risk.

We prefer the US, Poland, Germany, Spain, and Brazil.

It definitely takes some re-thinking in terms of tools. Lots of video conferencing. Lots of slack. Lots of email. Lots of Github issues.

I think it's worth it though.

Also, don't rule out being a hybrid company. If you have a central office (or offices) you can have the benefits of both worlds.

<comment><USER44> I've been remote for a few years and it's been a very frustrating experience for me, one that had turned me off developing in the end. hearing from you how it can be done right is very enlightening and encouraging at the same time - <USER2> wish i had found such a carefully crafted work environment! mind if i drop you a line in private?

</comment></comment><comment><USER45> I wrote something similar over the weekend about how remote teams are great for people on a maker's schedule, but people on a manager's schedule tend to dislike it.

[https://fridayfeedback.com/p/how-to-make-remote-work-more- co...](https://fridayfeedback.com/p/how-to-make-remote-work-more-common/)

I think finding this balance is the crux of the remote work experience. Meetings are necessary, but where is the line drawn? Collaboration is important, but do you need to have whiteboarding sessions to get things done?

<comment><USER46> Really well put. And I want to add another anecdote: when remote working, I used to do pair programming through Skype, with screen sharing. And I couldn't really feel any difference than doing this in person (it was a half remote/half office type of job), apart from the fact that we were not bothering anybody and there wasn't any other noise around our work. So it actually felt better than pair programming in presence.

</comment></comment><comment><USER47> The article looks at the benefits of distributed computing and makes the case that similar benefits could apply to distributed working (eg. scalability). Then it is only fair that we also look at other aspects of distributed systems and try to identify constraints on this model. I can think of:

1\. Just because a system is distributed does not mean you have a lot of very small machines (eg. a system with 10 machines each with 1MB RAM will beat one with 1000 machines each with 10KB RAM). Similarly, having 5-10 distributed offices could net all the benefits mentioned in the article while avoiding costs of having 500 employees working from home/wework/...

2\. Just because your system is distributed, you don't locate one machine on each continent. Machines are still arranged in proximity and having cross datacenter communication significantly erodes performance. Similarly, having distributed offices in far away timezones (eg. US west coast and India) imposes tremendous costs on collaboration. Having office in nearby timezones would be much better (eg. Seattle, Denver, SF). One particular case where far- away timezones help is ease of having 24-hour oncall support.

3\. Different machine profile in your system, or different composition of your clusters, makes it harder to tune the system for performance or quality. Similarly, having employees in vastly different jurisdictions would mean you have additional costs on compliance / regulations / etc.

4\. When you are prototyping or bootstrapping a new product, you do that quickly over a small setup (one machine). Similarly, it might make sense to bootstrap your startup in your garage (or a single city) until it is ready to scale.

</comment><comment><USER48> Working remotely for many years is the greatest perk for me, this is the only thing keeping me at this job... To booth, the team I am managing is across the country, so no point going to the office anyway - I only go few time a year to pickup my boss to go for lunch/informal chat...

</comment><comment><USER49> Never heard of the assertion that VCs hate remote teams. Anyone care to expand on that?

<comment><USER50> Definitely my experience; one of the first things that happens after an A-round is all the remote workers get asked to move near HQ, and can't, so they have to resign with no severance. And the standard startup recruiting playbook is to say "we will consider remote for the right candidate" when inquired, but all their hires seem to come from the same central California town the company founders live in.

<comment><USER49> What's the reasoning for that though from the VC perspective?

<comment><USER51> They want to come in and see the monkeys working at the zoo.

<comment><USER52> I wonder if readers will take this comment seriously, but it very much sums up the reasoning based on my experience. And some CEOs think that too.

I've been part of startups where VCs would stop by to pat on the CEO on the back, take a little tour of the office, happy to see 15-ish bozos banging on the keyboard. Sometimes they would invite some of their buddies to show off their monkeys. I don't know, maybe it was the VC version of a dick fight.

<comment><USER53> I have seen that too. It's especially important to show off someone from MIT or Stanford when the VCs do their rounds.

</comment></comment></comment></comment></comment></comment><comment><USER54> It is possible but takes the right team. Lots of people are perfect for it. It really depends on the lifestyle you live. If you are running it you have to replace people pretty quick if it doesn't work out and you'll probably end up with a pretty good team. When I was young I started out contracting remotely from home. That blows if you don't have some reasonable guarantee of steady hours. It can get hard to enjoy free time when your home is your office and you are hungry for work. If I was ever going to go back to hit or miss income I'd only do fixed price projects with nailed down scopes.

</comment><comment><USER55> In my limited personal experience:

pro of "decentralized" work

\- no itinere ⇒ no travel cost, wasted time, bad weather...

\- comfort at work

cons:

\- tech limitation, you are often forced to use bad proprietary software that really suc*s

\- if your partner also work from home maybe more family stress being more time together

\- a tendency of work more while being rewarded less

Other things balance, for instance connection problems may cost you but that's the same for protest or adversity on roads. You pay less for travel but you generally pay more for "personal hardware" etc.

</comment><comment><USER56> At first glance this seems semantic, but I think it hits on something that really makes a huge difference between my current work situation and my previous remote work experience.

I naturally gravitate to remote work -- it works for me. Where it's tough is at the edges of "my" work. What is mine, and how does it interface with everyone else's? This was a constant struggle with distributing the work at my old company (and this was prior to Slack's ubiquity, which doubtless would have helped).

My current company uses Holacracy as its organizing system, and even besides the fact that the tools are better now, the role clarity and distributed authority provided by Holacracy make an absolutely massive difference. From talking with friends at other Holacracy-powered companies that aren't remote, the difference is still big there, but a lot of the highlights are extra- highlighted in a remote setting. Things really get "distributed" in a meaningful way.

</comment><comment><USER57> I recently did a job search in SF and very few companies were hiring or open to remote. I agree with the author that it's very ironic that tech gives us the tools to work remote but yet most tech firms insist on working face to face. Certain functions may be more conducive to it or more in demand to consider it.

</comment><comment><USER58> I've worked from my house for 8 years now.

It saves gas, etc. I don't need the social aspect of work (I'm introverted). I really, really like working remotely.

But it's not for everybody. Sub-par performers especially will drag down productivity

So it's a mixed bag, IMHO. But for me, I love it.

</comment><comment><USER59> If you like to work in an office, work in an office.

If you don't like to work in an office, then don't.

For whatever reason.

</comment><comment><USER60> Cool, Russ Olsen used this remote/distributed workers analogy back in july 2016 here [http://blog.cognitect.com/cognicast- transcripts/104](http://blog.cognitect.com/cognicast-transcripts/104)

</comment><comment><USER61> If you know precisely what to do, then remote work is ok. However, once you need to communicate with people _and_ problem solve with them, all forms of digital communication are inferior to face-to-face.

<comment><USER35> Only voice works just fine and has worked for me for 8 years now.

<comment><USER61> I suspect that (1) you don't have strong relationships with the people that you've only communicated with via voice, (2) if you do, then it took a very long (multi-year) time to create that trust: significantly longer than through face-to-face communication, (3) you do not do a active, engaging brainstorming and problem solving sessions (e.g. whiteboarding) with your colleagues that you communicate with voice only.

<comment><USER35> I see some sort of assumption in your comment that I should be bonding with people I work with -- and by "bonding" I mean stepping outside the of work relationships. I don't aim for that. If it happens naturally, I welcome it. But I don't actively pursue it.

But your assumptions are mostly false: I've actively brainstormed and planned with people in voice-only sessions -- and they rarely exceeded 25-30 minutes. And that went on and on for the 1-year contract, every week or two, and only once did we have trouble getting a message across.

Building trust can take anywhere from 2 to 8 weeks if you are a down-to-earth productive programmer -- which I am. Not sure where your multi-year idea of building trust comes from?

I am not attacking you. But I can't stand behind this very widely believed legend that face-to-face trumps everything. That's provably false in literally half my work relationships during my 17-year-long career.

When people have common vision and are working honestly for the interests of their employer -- and are professionals -- things go pretty smoothly and the machine gets oiled _fast_.

</comment></comment></comment></comment><comment><USER62> I've never worked on a distributed team. While I can see how it works effectively for collaborating between senior contributors, how do you effectively mentor in a distributed environment?

<comment><USER63> Using Slack/email/whatever, mainly.

I think it works just fine when the domain in which you're mentoring is like software engineering.

It's not like you need to show them the proper technique for wielding an axe or anything else with a lot of physicality to it.

</comment></comment><comment><USER35> Remote / distributed requires discipline and wearing different hats while you sit in the same physical chair (if you work at home and not in remote co- working spaces). And you must be damn good at distilling your thoughts into a succint text -- in short amounts of time.

Fail these two and of course you will think remote/distributed doesn't work.

It's not for everybody. I only find myself improving all the time by working at a home office.

I respect the people who dislike it but they rarely return the favor.

</comment><comment><USER64> >Teams hold more meetings when they don't have enough important work to do otherwise.

This is... quite the statement. Teams hold more meetings as the size of their organization increases and any one individual cannot complete the work on their "shared digital artifact." This horrific, pre-digital concept termed "teamwork" emerges and the team discovers the most effective form of getting work done, as a _team_ , is talking to one another.

</comment><comment><USER65> Remote working = "Cast Away" by Tom Hanks. At some point, even the best of us need the human interaction or we start losing our other needed skills. (My 2c anyways)

<comment><USER66> You're allowed to have human interaction outside your company, ya know? :/

</comment></comment><comment><USER67> Remote may not be ideal for everyone. Some prefer office setting. It all boil down to individual needs and preferences.

In my case, I chose Remote option as a necessity when we had our kids. Due to the necessity, the client agreed for a partial remote work arrangement. This gave me a sense of satisfaction and balance in work/life.

After this experience, I continue working with other clients with option of partial remote work.

</comment><comment><USER68> > "few people want to move there".

It's like that Yogi Berra saying, "Nobody comes here anymore. It's too crowded."

<comment><USER69> But it's true. No one moves here anymore because it is crowded. People moved before it was crowded.

</comment></comment><comment><USER70> Any suggestions for remote brainstorming with whiteboard and all that?

I would like a large-ish collaborative drawing surface, and ability to see the faces of my collaborators (2-3 people), as well ability to request and grant control of the board.

So much of our design came out of impromptu design sessions, I don't see a future without it.

</comment><comment><USER71> Partial remote is optimal for me, both in quality and speed of how I work. Even if it wasn't at home, I can't stand being in the same physical space for that long, I burn out. Kinesthetic learning something something something productivity efficiency sh ./buzzwords.sh

</comment><comment><USER72> To me if you are in the bay, and have one office up in SF and another one down in PA, you are still "distributed" / "remote" or whatever you want to call it. Once you have two offices, it doesn't matter if its 50 miles or 500 miles.

</comment><comment><USER73> Misleading clickbait title - pretends to be against remote work, actually promotes a different form of remote work.

</comment><comment><USER74> blairreeves.me uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is only valid for . Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

</comment><comment><USER75> ITT: people who didn't read the article beyond the clickbaity title. ITA: someone's trying to coin a new buzzword.

I don't even mind the buzzword, it maybe even captures the point of companies such as 37 Signals better than "remote." But I am bothered by the "fault tolerance" section. Because it pretty much boils down to "it's easier to find a scab." In fact, the term might be a bit unfair to the "replacement" worker, as it's unlikely they have the means to find out that the previous employee has left for reasons they're comfortable with.

This is just another time when I'm worried that "distributed" work might be a double-edged sword if it ever becomes truly common. I still think it's worth it — as an autistic person I _really_ appreciate being in control of how and when I socialise and the amount of stimuli I receive — but it's not all roses.

</comment><comment><USER76> Exactly, remote from where? Working from home is a better term.

</comment><comment><USER77> Doesn't matter what you call it, eventually you'll find yourself being left out of some decision making if you're remote.

Accept it as the trade-off like I have. It's just the cost of doing business.

<comment><USER78> > Doesn't matter what you call it, eventually you'll find yourself being left > out of some decision making if you're remote.

the only companies where everyone is involved in every decision they want to be involved in are <3 people.

<comment><USER77> That number is more like 7 in my experience.

</comment></comment></comment><comment><USER79> Semantic pedantics and the developers who love them

</comment><comment><USER80> No, it isn't simply bad or unworkable. It's a _tradeoff_ , with both positive and negative aspects to consider.

<comment><USER81> Actually the tl;dr for me was "focus on distributed work, not remote work".

The name matters.

</comment></comment><comment><USER82> I've been remote:

1\. I now get more sleep

2\. I see my kids playing, i often take 5 minute break to watch them play and this motivates me more

3\. I usually bring down my pace upto the 5th slowest employee in the team. (40 people in our team)

4\. I don't try to do a lot. If a task is estimated as 2 hours and i did that in 10 minutes, i go to gym or roam around the market, till 2 hours have gone. Then i report the task as completed.

We use discord, somtimes i record the "i am working noise, keyboard chatter etc.." on a recorder and leave it on my desk playing when i leave.

People end up thinking that i am at the desk working.

This motivates other people to work, so don't seee anything wrong with this

<comment><USER83> Hope it's for a big faceless company who you hate, then? You can't imagine how wilfully disruptive, disrespectful and generally dickish this comes across. I'd urge you to get a job you actually like or try to make a difference in the world. What a waste. So rude, disrespectful, dishonest. Why? Edit: re-reading this, it sounds fairly rude in itself. I admit I was dumbstruck by this but don't mean to cause as much offence as came across. Isn't it so incredibly offensive to do this to a team of people who are labouring to build something great (presumably)?</comment></comment>


Target's website crashes - <AUTHOR> http://www.businessweek.com/ap/financialnews/D9PNOC3G0.htm

<comment><USER2> Websites crash under unexpected traffic all the time. Why should we care about this one?

<comment><AUTHOR> From my perspective, I find it interesting when a high profile website goes down for an extended period of time. The cost of downtime for a retailer like Target is high so I would assume that they put proportionately high resources in place to protect against it.

This is not a blogger's WordPress site that went down due to a viral post. So to me it's newsworthy.

Some HN readers may be trying to manage hosting resources for their online businesses, so I was hoping it would offer a little perspective to them.

</comment></comment><comment><AUTHOR> Currently down. Here's the error page: [https://s3.amazonaws.com/resultcaptures/77c40fdfb3e0b314a29b...](https://s3.amazonaws.com/resultcaptures/77c40fdfb3e0b314a29bc8fb27f46ab3.full.png)</comment>


Ask HN: Technology Stacks, 2013 edition - <AUTHOR>

These days, there is an absolutely huge number of technologies available to build software. Some of them are proven, others are very much on the bleeding edge to the extent that you can even consider them to be technology showcases.<p>What are the technologies and underlying system components that are being used in 2013 by startups to build their software ? Let's discuss everything that makes up a full technology stack, from client-side technologies, over programming languages and their libraries to the backend systems. <comment><USER2> Well, lately I've seen Haskell being pushed more and more in the industry and at startups and it makes me truly excited. We need stronger type systems and better static checks!

</comment><comment><USER3> Among many other things, we have a particular love for redis over at <http://enigma.io> \- So much so, every single page's metadata is bootstrapped from redis, never needing to go to our persistent datastores that sit deeper in the stack. Since our site is really read only (we are big public data provider), we can afford to provision redis in a pre-defined workflow.

</comment><comment><USER4> I'm a fan of Meteor, though I think it's too early to use it in production. It's notable for being most of the "things that make up a full technology stack" by itself, along with node.js and mongo.

<comment><USER5> Agreed! It's killing me that its not production ready as I have an idea that work so well with it.</comment></comment>


Hacker News CSRF Vulnerability - <AUTHOR> http://www.tjosse.me/articles/csrf-on-hn/ <comment><USER2> When it comes to security vulnerabilities, please remember when reasoning about their impact there's a good chance you'll miss something critical. Arrogance and vulnerabilities are a bad mix.

Even innocent looking "low impact" issues can be used as stepping stones to something much worse.

Creative exploitation can make two or more low impact vulnerabilities into a very serious compromise. Some of those vulnerabilities might be in a completely different system.

<comment><USER3> This should be required reading for anyone submitting vulnerabilities to bug bounties.

<comment><USER4> _> This should be required reading for anyone submitting vulnerabilities to bug bounties._

In my experience, people submitting vulnerabilities to bug bounties tend to incorrectly estimate in the _other_ direction, since they have financial incentive to do so.

You replied to a comment indicating that even minor bugs can be serious -- which they can -- but many researchers will find _actually_ minor bugs (nginx version disclosure, existing account enumeration on signup page, etc) and claim they're critical.

There's a balance there, and it can be tough to find. In any event, my stance is that if there's a security bug, you should damn well fix it :)

<comment><USER2> > In my experience, people submitting vulnerabilities to bug bounties tend to > incorrectly estimate in the other direction, since they have financial > incentive to do so.

A good point. There's definitely motivation to exaggerate the impact.

However, could there be a flip side to this as well?

People _not_ reporting vulnerabilities _they_ consider minor, thinking they'll get no financial gain. No money or fame, so why bother?

Some of those unreported issues could be very critical when connected with something else minor or perhaps even something that's not a bug at all.

Perhaps some of bug bounty funds should be retained for awarding any reported issues that turned out to be a (part of) critical vulnerability in the future?

Retroactively awarding issues that became more critical later on should encourage reporting of _maximum_ number of bugs. Even those the discoverer considered insignificant.

As a result, everyone involved would be better of. More bugs would get reported and their discoverers properly compensated.

> ... minor bugs (nginx version disclosure, existing account enumeration on > signup page, etc) and claim they're critical.

Wouldn't you agree it's preferable they're reported regardless, no matter how minor they may be? For example unintended version disclosure could very well make targeted attack a successful one. Account enumeration disclosure could conceivably be used to attack the account holder in some other way, including social engineering attacks.

</comment></comment></comment></comment><comment><USER5> Although I can totally see how this is a vulnerability, the implications are quite limited. Basically you can log people out for fun, and you can log them in to an account of yours, which I think would be noticed quite soon.

<comment><AUTHOR> The implications depend on your app. If the user doesn't notice being logged into a new account, they may go on to create data in the attacker's account that they expect to be private (e.g. YouTube watch history).

On e-commerce sites, they might add a credit card - thereby allowing the attacker to use it.

Fortunately, HN doesn't have these risks, but it's a good illustration of how CSRF works in the real world.

<comment><USER5> Good points indeed. I never thought of adding anti-CSRF measures to login forms, only while logged in, so I'll start doing that :)

<comment><USER6> Another good reason for login CSRF tokens is to prevent a malicious page from submitting lots of invalid logins and getting an account / IP locked or rate limited.

</comment></comment></comment></comment><comment><USER7> Both Michal Zalewski[1] and Chris Evans[2] have commented on this, and I tend to agree with them. The actual implications for a CSRF like this are very minimal.

[1] [https://lcamtuf.blogspot.com/2010/10/http-cookies-or-how- not...](https://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to- design.html) [2] [http://scarybeastsecurity.blogspot.com/2010/01/logout- xsrf-s...](http://scarybeastsecurity.blogspot.com/2010/01/logout-xsrf- significant-web-app-bug.html)

<comment><USER8> The implications for HN are minimal, but this is a login CSRF, not a logout CSRF. Like session fixation, login fixation is a serious flaw.

Believe it or not, there have been apps with serious flaws stemming from logout fixation --- but those flaws were notable because they weaponized logout CSRF. :)

<comment><USER9> What exactly is "logout fixation"? Session/login fixation makes sense, but I can't really imagine what logout fixation would look like. Google was of no help, either. Do you mean a logout function which doesn't properly log you out, or logout CSRF?

<comment><USER8> Sorry, that's a typo. I meant "logout CSRF".

<comment><USER9> Gotcha.

</comment></comment></comment></comment></comment><comment><USER10> I disagree with those saying that the impact of this type of attack is minimal.

Depending on the application it could significant implications. Imagine for instance if this was possible in an application, and after switching to the attacker's account the victim was tricked into doing an OAuth to some third party service.

</comment><comment><USER11> Interesting. Is this why login is usually on its own page, rather than right on the main page? CSRF seems to limit your ability to cache any pages that contain forms.

<comment><USER12> you could have an API that returns a CSRF token.

</comment></comment><comment><USER13> Whether or not the implications of this particular CSRF vulnerability were serious, the developers should be commended on implementing a fix quickly.

</comment><comment><USER14> Nice find it goes to show you that nearly everything has some sort of vulnerability. Adding anti-forgery tokens to my login page now...

</comment><comment><USER15> Would this still work with 3rd party cookies disabled?

In the years I've used uMatrix[0] I can't remember a single case where sending a cookie with a 3rd party request was needed. Why do browsers do this still?

0: [https://github.com/gorhill/uMatrix](https://github.com/gorhill/uMatrix)

</comment><comment><USER16> I'm not too well versed on netsec; how do you fix something like this?

<comment><AUTHOR> To mitigate CSRF on a form, send the user a randomly generated, long, unique token every time the form is rendered. Put it in a hidden input.

Your server must expect the POST to answer back with a valid csrf token. Otherwise, the request results in an error and doesn't go through. Attacker pages won't know anything about the csrf token, so they can't forge the form.

<comment><USER17> That's actually not always enough. For example, to fix this login CSRF on HN, you need a per-visitor secret an attacker can't read (like a cookie) plus a form value _based on that secret_. Note it can't be tied to the user account, because the visitor hasn't logged in yet.

A random CSRF token on a login form is easily defeated - the attacker just requests a valid one and uses it when submitting the CSRF form.

<comment><USER18> > the attacker just requests a valid one

How?

<comment><USER17> wget, curl, whatever. If I'm the attacker, I ask for a new one from my server each time and put the result in the form I serve your browser.

<comment><USER6> The CSRF token should be tied to the user session, so you'd need to perform session fixation for that to work.

<comment><USER19> Tying to the session is a common practice but not necessary. You can do non- session-tied CSRF tokens so long as you don't expose your cookie.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> So what was the fix? I don't see a CSRF token in the login page, so I'm curious what their patch was.

<comment><USER21> The logout link is rendered with the token in its query string

<comment><USER22> Wouldn't this still allow logging in without consent if they aren't logged in?

<comment><USER23> It does. We haven't rolled out the fix that Nick described ([https://news.ycombinator.com/item?id=11178922](https://news.ycombinator.com/item?id=11178922)) because it will probably break a bunch of the third party apps and scrapers that give people alternative interfaces to HN. Those have value and I'd rather not make their lives more difficult unless/until it's necessary.

<comment><USER24> Finally, some clarification on which hacker news it is. I care less about the hacker news with the "the"

</comment></comment></comment></comment></comment><comment><USER25> Ah, CSRF, the irritatingly low-hanging fruit that every would-be security researcher pre-emptively attacks for attention.

<comment><USER26> I don't understand the negative response towards CSRF exploits. They are real and they are dangerous.

<comment><USER27> If this had been reported in any other web application, everyone here would be calling the developers morons.

<comment><USER28> If it's such a low-hanging fruit why don't you prove it?

<comment><USER19> It's more that if literally any other site on the internet were found to have any type of CSRF vulnerability, people here would be going on and on and on about how this is web dev 101, only a complete idiot wouldn't know about/secure against CSRF attacks, etc.

Whereas here, when it's HN with a CSRF issue, "eh, it would break some third- party clients if we patched this".

<comment><USER23> Tell me more about this world in which HN's users shield its developers from criticism.

We fixed the reported vulnerability and have a fix for the remaining issue ready if it's needed. There's no "eh" here; it's a question of what the right tradeoff is.

<comment><USER19> Well, I don't see people insulting you the way they would if it were another site...

And I don't see people calling out the "breaks third-party clients" justification for not rolling out the full fix.

<comment><USER23> Since you're a "people here", your comments disprove themselves.

A phrase like "calling out" assumes that it's obvious what we should do. It's not obvious; the parts that were obvious are done. Our goal is to do what's best for the community, not to avoid getting criticized on the internet.

<comment><USER19> _Since you 're a "people here", your comments disprove themselves._

If I were going to respond to you the way I feel HN would generally respond to a CSRF hole in a major non-HN site/service, I'd say something like "Well, that line shows you're as good at formal logic as you are at preventing/patching CSRF holes".

You know the same as I do that HN's getting light treatment from its users in this thread, compared to how security issues in other things typically get received. It's OK to admit that.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


With $42M more, 10gen wants to take MongoDB mainstream - <AUTHOR> http://gigaom.com/cloud/with-42m-more-10gen-wants-to-take-mongodb-mainstream/ <comment><USER2> What an amazing amount of money. Apparently they have got $70m+ in total. Our small/mid sized company with about 20 employees could operate for about 50 years with that amount of cash...

An apparently they already pay for themselves: ""Business is fantastic," 10gen President Max Schireson told me. "We keep outperforming every goal that we set for ourselves and the market just feels like it's huge." In fact, he said, new sales people pay for themselves almost immediately upon joining the company."

So I wonder what they are going to do with that huge pile of cash? R&D for a single DB surely can't be that expensive (or at least it would be difficult to get that many people to suddenly work on productive things that would actually improve the product and not just make it bloatware).

Apparently the hype works, for a DB that is about scaling but doesn't scale yet? "Just another $100m and we'll get there"?

How many people actually need a DB that "scales" better than mysql/postgres which are much easier to use and better supported and understood?

" Among other things, it has been criticized for being rather difficult to manage at scale. This is somewhat ironic, as scalability, along with the flexibility that comes with being schemaless, is among the driving factors behind the NoSQL movement. One would expect the most-popular of the bunch to scale with ease."

<comment><USER3> disclaimer: I used to work for Couchbase, and am still involved in the CouchDB community

'Magic Scaling' isnt the only reason people use alternative data stores such as Mongo (or Couch), in fact as shown it can often turn out to be a really bad idea to do so. I wouldnt still be interested in CouchDB if it was just 'do stuff a bit differently from mysql and everything will work at scale' type database.

Schemaless, Native JSON, master master replication, HTTP API are all features which can be hugely beneficial to particular applications over tradition RDBMS' (those were only a few features and they were probably bias towards CouchDB because I know that better)

<comment><USER4> Right, the schemaless and native JSON are the main reason I switched my products to MongoDB. Scalability is not an issue for 99% of the projects i've worked on.

Easier mapping between my domain model (I mainly use Smalltalk) and the persistence is a huge win.

</comment></comment></comment><comment><USER5> Now is the time to buy stock in mug manufacturers, seeing as I'm already awash in MongoDB mugs everywhere think how many more $42M can buy....

<comment><USER6> But the important question here is: How big is the mug market? Every developer, I know, has a MongoDB mug already. This makes me question, how their mug strategy is going to be with this new investment?

<comment><USER7> I ended up sharding my mug :(

<comment><USER8> Despite their claims, MongoDbMug is clearly not web scale.

<comment><USER9> Cut a hole in the bottom. You can put _tons_ of stuff in there now! ;)

note: be sure to hold it over the sink while 'filling'

<comment><USER8> Ah, the pipe to /dev/null solution. Now _that_ is web scale.

</comment></comment></comment></comment></comment></comment><comment><USER10> > 10gen has invested heavily in ease of use and functionality early on rather > than just speed and scalability. Because it's so easy to use, MongoDB has > attracted lots of web developers who don't mind working around its > scalability shortcomings

followed them from pretty early on, and I found the opposite was the case, with their heavy emphasis on the easiness of sharding, as well as coming out the gate with 'safe writes' turned off.

</comment><comment><USER11> "cement MongoDB as the NoSQL database of choice for businesses of all types and maybe even make it a household name"

The hype is ridiculous. You mean like Oracle DB is a "household name"? No, I didn't think so.

<comment><USER12> It sounds like they've let their ego overtake their product.

</comment></comment><comment><USER13> Congrats 10gen! Its pretty awesome to see a company built on open source technologies doing so well. The community wins & the VCs win.

<comment><USER14> That's a web scale investment!

</comment></comment><comment><USER15> Great news for business models based on open source! However i would much rather like to see Riak as the NoSQL db of choice.

<comment><USER16> How do you feel about the open core nature of Riak? I mean, I would jump to it for some of my uses in a second, but I find that the lack of multi-dc replication support in the open source edition is kind of a killer for my use case. I have the reliability need, but I don't really have the heavy usage to support such an endeavor (as it's something of a personal project).

</comment></comment><comment><USER17> Let's face it, most companies are still built on relational database systems. I'm assuming that a lot of this money will go forward to changing this "culture" and injecting NoSQL into tech industries that have yet to adopt it.

...or they could just wait for the next generation of young developers to take leadership roles at BigCorp.

<comment><USER18> For years intel claimed that developers would never port their code from x86 to a different archiecture. The recent wave of mobile devices for iOS and Android has shown this to be completely wrong.

In the future DBA's that only know how to use a relational database will be obsolete, because younger developers that know how to use mysql and various nosql solutions will take their jobs.

</comment></comment><comment><USER19> But keep in mind that's really only $40M after data loss.

<comment><USER20> I was going to say "why, were they paid in Bitcoin?" but then I thought this story was a bit too meme-heavy already.

</comment></comment><comment><USER21> I'd really love to be using MongoDB... but we're a Solaris on Sparc and IBM on Power shop. No support for either one of these, sadly.

<comment><USER22> Goal 1 of the financing was funds to accelerate r&d, to hire engineers to do things like the ones you mention above; in addition more r&d just pushing hard to maximize overall product quality, stability, etc. not sure if those exact things will get done and exactly when yet. I'd definitely like to see the solaris build get some attention. dwight/10gen

<comment><USER23> a patchset for non-Intel CPU support was around for years, and you guys completely ignored its existence. As well as all the critics towards non-word- aligned data structures and in-memory presentation.

how about redesigning the whole product with all that cash?

</comment></comment></comment><comment><USER24> How long before Oracle buy them

<comment><USER25> They already have a very similar BerkeleyDB, don't they?

<comment><USER26> berkeley db is not similar, mongodb allows you to store json, and create indexes on many parts of the json, and query on those as well. with berkeley db you have to build that in yourself in the application, not in the database.

</comment></comment></comment><comment><USER27> $42 million is nice and all, but the real question here is: will it scale? Stay tuned until next week folks when we find out, "IF IT WILL SCALE!" _cue crowd cheer_

<comment><USER28> If only "Will it scale?" was as entertaining as "Will it blend?"

</comment></comment><comment><USER29> I am surprised Clustrix (YC) hasn't gotten more attention. They rewrite SQL databases and claim to be able to scale them. Maybe the up front cost scares people.

<comment><USER30> And because Clustrix is only available via an appliance.

</comment></comment><comment><USER31> As long as 10gen doesn't turn into Oracle, I'm fine with it.

</comment><comment><USER32> Would love to know what valuation, they raised at.

</comment><comment><USER33> All the best to them.

I hope they continue to market MongoDB on its merits and not as some replacement for SQL databases. Both models have their place and there are plenty of use cases where one or the other is more suited.

<comment><USER34> Marketing it as a viable alternative seems right to me:

<http://www.10gen.com/why-mongodb>

</comment></comment><comment><USER35> hope they get rid of that global write lock first...

<comment><USER36> Version 2.2: <http://news.ycombinator.com/item?id=4013953>

<comment><USER37> Yes, we saw, the _per-database_ write lock. It's _soooo_ much better.

Come on, guys. They have _real_ NoSQL datastores out there... with more sophisticated strategies than "keep it all in memory and let the operating system swap everything to disk" to boot.

<comment><USER38> not sure what you're going on about.. what you're characterizing as "punting" to the OS was a carefully thought through decision, along the same vein as the one phk of FreeBSD and Varnish fame made[1]

[1]: <https://www.varnish-cache.org/trac/wiki/ArchitectNotes>

<comment><USER39> _carefully thought through decision_

Varnish is a carefully tuned piece of machinery that consciously leverages the page cache because that happens to be a great fit for the access pattern that you'd expect in a _cache_.

Mongo is not a cache. It generates quite a different access pattern and it's widely documented what happens when your working-set exceeds RAM or when you put it under anything but the lightest write-load. A single bulk update literally halts the world.

Comparing Varnish to MongoDB is quite an insult, akin to comparing a Swiss precision Rolex to a plastic Mickey Mouse watch "with many advanced secret- agent features" from a gumball machine.

</comment></comment></comment></comment></comment><comment><USER40> Bravo!</comment>