How Bullshitters Not Just Survive But Thrive (2016) - <AUTHOR> https://www.linkedin.com/pulse/how-bullshitters-just-survive-thrive-until-atul-mathur <comment><USER2> I mean, I feel like everyone hating on this article either:

1\. has never had the misfortune of working with one of these people. "poser" devs who care more about "communicating up" and making a show of their (often quite trivial) contributions

2\. has worked with people like this, but doesn't perceive the behavior described in the article, for whatever reason.

A couple times in my life, not just in software, I have worked with people who are _exactly_ like the article describes. The work they do is all perception- management stuff. Shuffling around work tickets, setting up/attending meetings, etc., when they are supposed to be individual contributors. Meanwhile, they contribute nothing. I've even had a coworker -- a peer -- come to me to ask me to do a task when they were assigned to do it. Because they were busy organizing work tickets.

Don't get me wrong. You have to toot your own horn when you do something that should be noticed. Your boss won't always recognize when you've made a meaningful contribution, so saying, "Hey I did this and it's pretty good, and it adds value to our org in these ways" is not inherently bad.

It's when that autotooting is to bring attention to stuff outside what they're _supposed_ to be contributing that it should raise red flags. Or when they start trying to delegate work to their peers. I'm really glad so many of you find this article so awful because it means you've never felt the frustration of watching someone like this get praised for and advance by essentially doing nothing.

edit: I don't know how to explain it to someone who hasn't ever noticed it. The behavior pattern in the article is not something a lot of people notice. But among people who do notice -- at least those I've talked to -- it's very obvious and really bothersome.

That said, most of the time coworkers -- even really smart, kind, hard-working coworkers -- either don't notice or don't care. So it's not surprising to me that commentators here think the article is BS. You've probably sat next to people like this but you didn't notice. Good on you.

<comment><USER3> I remember the first time in my career I encountered someone like this. I thought I was mistaken or crazy, or just naive since I was new to corporate work. This person MUST do something or he'd have been fired! But after watching for weeks, then months, as he literally accomplished nothing, instead spending all his time self-promoting, taking credit for other people's accomplishments, and "managing upward", I was convinced I wasn't crazy. His official job was to write code, but his real job was shaping the perceived reality of his boss and his boss's boss, and he was very very good at it. This person has, since, gone on to be rather successful (at least a successful sounding title at a well-known software company).

<comment><USER4> In my experience small companies, which can't afford to carry dead weight, are pretty intolerant of these kinds of people. But at a large company someone who does this well will be there as long as he wants. I work with one who's been at our company for at least fifteen years.

My favorite trick is the Strategic Vacation. Somehow he always has a long vacation planned months in advance that allows him to dump whatever he's been tasked with onto someone else (like me, for instance).

"It's basically done, but I haven't added Y or Z yet" is always the prelude to receiving something he's been "working on" for three months and actually put in, charitably, two or three days of actual work.

But he's a good looking, personable kind of guy. Everybody likes him, particularly the managers, as a person. So while nobody wants him on their team he's managed to avoid getting a reputation that would keep him from moving to other teams.

<comment><USER2> > "It's basically done, but I haven't added Y or Z yet" is always the prelude > to receiving something he's been "working on" for three months and actually > put in, charitably, two or three days of actual work.

I am familiar with this one as well.

</comment></comment></comment></comment><comment><USER5> Ironically, this article also reeks of bullshit.

The massive characterization: the sloppy nerd (W-S), the consummate bullshitter (S-W), and the "rare" real talent (W+S). Which sets up the classic, "you're successful, so you must be a bullshitter" (because those S+Ws are _sooo rare_ ).

The "CB's" he's describing are so incredibly transparent, they might as well be strawmen.

<comment><USER6> > The "CB's" he's describing are so incredibly transparent, they might as well > be strawmen.

Strawmen or not, I've worked for two. Those aren't fond memories.

<comment><USER7> Yup. It takes a while to see the abstract pattern underlying their behaviour. Once you see it, its very clear. But for a long time you're distracted by the details of day-to-day events and you think they're just another co-worker with some annoying habits.

I'm confused why so many commenters are quick to shout "B.S" on this article (are they BSers in hiding?) but maybe he is oversimplifying too much. True S-W types are pretty rare and are probably evidence of some extreme psychological disorder. (E.g., malignant narcissism or sociopathy. Robert Hare is a researcher in criminal psychology and wrote a book on such people: [https://www.amazon.com/Snakes-Suits-When-Psychopaths- Work/dp...](https://www.amazon.com/Snakes-Suits-When-Psychopaths- Work/dp/0061147893)).

<comment><USER5>
      maybe he is oversimplifying too much

I think that's it. Even distilled down to two variables ("smart" and "work"), you're talking about three "extremes": [1.0S,1.0W], [1.0S,0.0W], and [0.0S,1.0W]. Most people are probably in the 0.25-0.75 range on both variables.

There are almost certainly more variables, and "smart" and "work" are _terribly_ named.

<comment><USER8> I agree, and add that sometimes people who have a tendency to BS can surround themselves with more grounded people, so that the whole package works. Their confidence and superficial knowledge can even make them seem more relatable to customers than a deeply knowledgable specialist would.

In other words, an individual's value is context-dependent. It's really hard to make such crisp distinctions as in the article.

</comment></comment></comment></comment></comment><comment><USER9> A better article if you're interested in this type of analysis, done well: [http://www.ribbonfarm.com/2009/10/07/the-gervais- principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or- the-office-according-to-the-office/)

<comment><USER10> I went to a meetup and ran into the author of that piece. I asked him a question (I forgot what) about it, and he groaned, because it's pretty much the thing everyone always asks him about.

I then spoke to him about this piece - [http://www.ribbonfarm.com/2015/03/19/the-art-of- gig/-](http://www.ribbonfarm.com/2015/03/19/the-art-of-gig/-) which I think is hilarious.

</comment></comment><comment><USER11> As an S-W character myself currently struggling to transform into the mythical W-S in academia, is there any simple ways to just focus and get work done? I find it almost impossible to focus on one thing for more than a few minutes.

<comment><USER12> The pomodoro technique is quite popular. Also, goals, systems, etc. There are a few subreddits that focus on things like this.

<comment><USER11> I've tried the pomodoro technique. It's very good for deadlines. Academia doesn't tend to have genuine deadlines at the junior researcher level so it's basically just a matter of finishing the work whenever you can.

What would be nice, is if there was a way to somehow gain intrinsic motivation to do stuff that interests you? I get extremely excited about projects at first and then tail off.

I'm not a "finisher", and I would give a large chunk of my salary to someone who enabled me to become one.

<comment><USER13> I had this problem when i was a PhD student. Towards the end of my time, i started doing something which fixed it, and which i could have been doing all along: make a list of the figures for my paper, and do whatever bit of work moves the next most important one towards being finished.

I should mention that i was working in cell biology; in cell biology, you earn career points by publishing papers telling a new story, where papers comprise a series of figures, each one showing results which demonstrate some point of your story. Papers also have an introduction, description of the results, and discussion, but those are pretty much filler. The smart scientists i know read the title, the figures, and the materials and methods section. Perhaps not every field is like this.

So, to make a good paper, you have to come up with a series of good figures, which means (a) finding a story you want to tell, (b) working out what points you want to make, and (c) getting results which make those points. Having done that, there's the technical work of making up the figures (learn to love Illustrator), and some writing, and you're done.

Finding the story is usually the easy bit. Your supervisor usually has some untold ideas for stories floating about, or there will be some variation on an existing story that people will enjoy hearing. Or you might just need to spend a year or two trying stuff, which can be fun until it suddenly isn't.

Working out what points you need to make takes time, but once you know the story, is usually not too hard. Crucially, you don't need to know up front that these points are all true. As you work towards them, if you find any that aren't true, you just throw them away, and either replace them, do without them, or change the story a bit.

It's getting the results which is hard. That is the actual work in scientific research. Designing, performing, interpreting, and refining experiments. Finding, preparing, and characterising materials. Learning or inventing techniques. Spotting weaknesses and plugging them with control experiments. Endless, seemingly incessant, tea breaks.

Having a concrete list of the figures you need helps you keep going at getting results, and helps you do the right ones. Before i had a list of figures, i did all sorts of experiments because they seemed interesting, and connected to what i was doing, but which could never have contributed to my paper.

<comment><USER11> This is such a wonderful reply. Thank you so, so much for this. It's so clearly actionable in my day-to-day life, too.

Hopefully you've saved my career before it implodes!

</comment></comment></comment></comment></comment><comment><USER14> I am the company owner. I had the bizarre experience of net productivity going UP by firing the warehouse manager. Apparently he had the habit of telling the same long-winded story to each of his 8 co-workers, individually.

Once he got done telling them all about the strawberries that were 50 cents a pound underpriced at Safeway, `15 minutes later they could get back to work. He not only wasted his time, but also his co-workers.

Productivity noticeably went up after his departure. Nobody had complained about his time wasting stories until AFTER he left. Somehow they assumed I knew everything but didn't care (bizarre, since I am fairly frugal) .

So as the Boss in this scenario, sometimes it is hard to tell what the truth really is. My staff was trying to be nice, and not cause problems in the workplace. Thus causing a problem in the workplace.

Occasionally I do the Toyota 'stand in a circle' exercise in the factory to get a real sense of how people move around, how they spend their time. It is always surprising how my assumptions are often wrong.

[http://theleanthinker.com/2007/07/09/the-chalk- circle/](http://theleanthinker.com/2007/07/09/the-chalk-circle/)

I also watch for the "delegate to peers" routine. If I assigned it to you, I wanted YOU to do it. If I wanted your co-worker to do it, I would have assigned it to THEM.

</comment><comment><USER15> There are four reactions to this article that I can see right now:

1\. It is incorrect, and the author misunderstands the nature of management

2\. It is neither correct, not incorrect, but is vapid and superficial

3\. It is basically correct, but poorly written and reasoned

4\. It is correct

Let me respond to category #1 and #3, and try to unpack the claim made in the article.

I assume that there is no debate that some people do not add value.

Most people may also agree that there are some people who do not add value _on purpose_. That is, they are not interested in adding value. What might be more controversial is that there are many such people, and they are successful.

If you believe that there are people who purposefully don't add value but exist and thrive, then who are they, how do they thrive and why aren't they caught?

I think you will end up with some version of the argument presented here.

</comment><comment><USER16> In my experience the S-W/CB are very rare, rarer than the W+S type. I've worked with one or two over the course of ten years, but they tend to gravitate into project management or BA positions in a short amount of time.

The most common type of developer is the fourth category, missing from the article: the -S-W type. Not really all that good, and with little to no political acumen. They fill most roles at medium-to-large IT companies.

And having known many (a lot of them are nice people otherwise), I can tell you that each and everyone of them thinks they personally are a W-S type. They think their uninspiring, slow, painful expertise (if its hard for them its because it must be a hard problem, right?) makes them top of their field, and that when other developers are the 'superstars' its just because they are better at politics.

The biggest truth, the most important truth that the article seems biased against, is that unless you live in a cave working on software with two other like-minded hardcore devs, 50% of your job is communication! Not being good at communication makes you a bad developer, regardless of your technical abilities.

</comment><comment><USER17> The lens the author is looking through is missing the other side of the coin.

Communication:

Regardless of how smart you are, if you can't communicate it to others, then then value of your intelligence is limited to an individual role. People who can't/won't communicate make terrible managers. The people above them have no idea what's going on in their team. Poor coordination with other teams creates issues outside of their team. Their own team members will fail to understand what role they are playing in a larger effort. The non-communicating manger will know (because he's in the meetings), but will fail to pass that information to their team. As you move up the chain of command, communication becomes more important than what you as an individual can produce.

Confidence:

Your car breaks down. It's critical you have it working tomorrow. Two mechanics show up.

\- The first mechanic says: "This is really tricky. I don't know if we can get this fixed tomorrow. It may take a week. I'm not sure"

\- The second mechanic says: "This is no problem. I'll have it fixed by tomorrow".

Which one are you going to hire?

Perception:

The hardest pill to swallow is that upper management is very aware of what's going on in a team, especially when the manager is a problem.

      - upper management has usually seen it all before.  So any behavioral issues are easily spotted.
      - Team members complain to people on other teams, and word gets around.
      - Team members will request re-assignement or discuss quitting.

There are a lot of ways to handle a bad manager, some good, many bad. The more professional you are, the easier they are to handle (i.e. be honest, don't participate in rumors, don't complain about others, own your responsibilities, be transparent, and communicate with facts)

Performance over Perception:

Performance is always more important than perception. The issue is a lot of employees don't understand what the priorities are for their organization.

The priority is almost always. How efficiently and predictably does the job get done. Efficiency also includes how much hand holding someone higher up has to do.

</comment><comment> loup-vaillant > _Can you see a cow?_

Looks like a blurred Japanese painting. I see 2 samurai, one standing on the left, one dead on the right (face down, you can see his hair). I can't explain the horn helmet the standing samurai is wearing, though.

> _If you still can 't see the cow, please search "visual intelligence cow" in > Google images_

Oh. A cow indeed. (It's head, facing the camera.)

<comment><USER18> Is this a notable photograph for visual elicitation? I saw a cow immediately so I thought the references were some weird sarcastic humor...

(Not bragging about recognition by any means. Grew up in dairy country so I probably see _too many_ cows in things overall!)

<comment><USER19> Yes, it's famous. I remember seeing it as a child and taking ages to see the cow, and feeling a "hidden picture" sensation when it finally popped out. Now, decades later as an adult, it immediately and unambiguously looks like a cow. I wonder if that's due to 1) learning the picture, 2) learning more about cows, or 3) learning more about high-contrast images.

I do remember hearing that it's one of those things you can't ever "unsee".

</comment></comment></comment><comment><USER20> I am happy to work at a tech company where your BS can be easily surfaced using pure logic. If you can't code and don't do good coding or designing then it does not give you enough leeway to BS.

<comment><USER21> Yes, perhaps more than some other fields. However don't underestimate the number of decisions which must be made with less than adequate information and sometimes multiple outcomes can be chosen which are supported by available data. Also there are times when someone's experience can help them understand how a stream of data will change over time and they can use that to get ahead of the change rather than being purely reactive.

I'm not disagreeing with you entirely, just proposing that it isn't usually so black and white in our industry.

</comment></comment><comment><USER22> I comfortably and certainly fall into the first category. I'm not ever more than 90% confident...if you ask me directly what my confidence level is. I tend to be one who is labeled as not "smart".

<comment><USER23> You're not alone.

To make it worse I tend to start stuttering when asked things on the spot, even though I know the answers or could easily look up whatever info was asked for. I'm painfully aware this makes me look like I don't know what I'm doing. People generally don't have the patience to let me gather my thoughts and give a coherent explanation/answer.

<comment><USER22> Exactly. I think that is actually their own failure and not mine. About 50% of the time thinking fast just gets you a rushed answer which is likely not to be the correct answer. My manager literally said he can't trust me with on the spot questions. I'm like well duh. You shouldn't trust the off the cuff for certain types of questions. I try to actively limit the amount of company specific information that goes into semi/long-term memory.

</comment></comment></comment><comment><USER24> Not a link to an article, just the linkedin signup page.

Too bad linkedin has declined in usefulness, it was almost getting good.

Anyway, pure political posers are nothing new.

Not everybody has it in them to actually make worthwhile efforts, or make efforts worthwhile to anyone but themselves.

Plus most BS proponents are not in the pure category, with significant to considerable raw ability but who still draw from the BS deck when threatened or with opportunities that might fall to truly higher quality operators instead.

Often motivated most strongly by greed, and without real value-creating talent or productive performance to fall back on, there's not much else they can do to survive.

A great many have been this way for life, and know it well, therefore have a lifetime honing their survival skill. Some get especially good at inserting themselves into the background BS of particulary vulnerable or susceptible bureaucracies, where they can often thrive (exclusively to their own advantage). They sometimes accomplish this without becoming a destructive enough parasite to be well recognized by those who should care. And sometimes those who should care, actually don't care to begin with, or have had their doubts diverted by carefully crafted BS fields.

For technical or scientific concepts to thrive instead, there must be none of these BS operators between the technical creators and the resources the creators rely on (such as funding resources from capitalists, income from clients, or customers).

</comment><comment><USER25> I think people should stop trying to put others into categories to feel superior about themselves. People have a range of talents and shortcomings. No one is perfect.

<comment><USER26> So you are saying there are two sorts of people, those who put people in categories and those who don't, and you are the latter type. Ok.

</comment></comment><comment><USER27> The sad reality is that all too often these people end-up in management position. I've worked for at least a couple of such folks. They were technically incompetent yet could say enough in meetings to appear like geniuses to upper management and non-technical folks. Master manipulators at all levels. It is interesting to note this is the very thing politics is about.

</comment><comment><USER28> To say this article misses a bit of nuance is a major understatement. The descriptions (w+s, s-w, etc.) are limited, and where people fall on the spectrum (even on this limited black/white list of personality types), ebb and flow on a daily/weekly basis.

</comment><comment><USER29> I kept waiting for a resolution to his anecdote about waiting for his boss. It sounds like his boss was doing work. How was that an example of a bullshitter?

</comment><comment><USER30> I know a EVP who is #2. He is worthless as they come, knows far less than he claims, and soaks up mad resources. He's hated by everyone below that level, but very popular with his peers because he hires very competent people and rides on their accomplishments. And he has a great managerial presentation and personality. Ugh.

</comment><comment><USER31> Fake it 'til you make it!

The problem becomes more pronounced the further we abstract away from Assembly and memory management.

</comment><comment><USER32> Ayn Rand wrote about the W+S crowd leaving this world behind because they couldn't tolerate the evil bullshitters.

I guess that's a more interesting story than W-Ss that 'disappear' after they get burned by the corporate environment.

</comment><comment><USER33> _Not only that, we also sometimes worked on public holidays when everyone else was enjoying with their families_

This part is illegal as hell and pretty much sums up why a union is absolutely needed in some workplaces; to curb this kind of crap.

<comment><USER34> If it's in the US, it is by no means illegal to have employees work on public holidays.

</comment></comment><comment><USER35> How come Elon Musk never says the names of any of the engineers working on products when he makes announcements on stage? The answer is because he doesn't want to share credit.

</comment><comment><USER26> I wonder why the higher-up managers aren't able to spot bullshitters, and if they could be trained to do so. It would certainly benefit their organizations.

<comment><USER36> IMO, they don't care enough to spot this. As long as deliverables are met, there is no incentive for them to dig around the roots. But I think once the "ponzi scheme" is exposed by having good talent refusing work in that toxic environment. shit gets really real, fast.

</comment></comment><comment><USER37> This is all just delightfully postmodern.

</comment><comment><USER38> sheer bullshit.. this article..

<comment><USER39> I disagree with you.. the article is 100% relevant and it happens

</comment></comment><comment><USER40> How is the Gervais Principle from Ribbonfarm any less BS than this article?

</comment><comment><USER41> Is this backed by research or is it just anecdotal evidence?

<comment><USER42> Management Theory\Organizational Behavior are taught in university but this is a terrible article.</comment></comment>


Ask HN: Do startup founders print biz card?  - <AUTHOR>

do they still do it? is it too old fashion? do VCs take biz cards? <comment><USER2> Biz cards are useful when you need to give someone your phone number and/or email address.

Thing about it. What's quicker? Pulling a piece of cardstock out of your jacket, or each of you firing up phones, and trying to either dictate an address or line up for a QR code.

Stick with the tried and true. They're only $12.</comment>


Embarrassing Flaws That Made My 'Weekend' App Possible - <AUTHOR> http://yieldthought.com/post/1345897970/10-flaws-that-made-my-weekend-app-possible <comment><USER2> "While thinking about this on a plane to England, my mind makes the natural leap from my motley collection of python functions to turning down acquisition offers from Amazon and being invited to talk at Davos."

haha happens all the time, who else suffers from this?

<comment><USER3> [One of my favorite excerpts from _Why's (Poignant) Guide to Ruby_ ]

Today I was at this Italian restaraunt, Granado's, and I was paying my bill. Happened to notice (under glass) a bottle of balsamic vinegar going for $150. Fairly small. I could conceal it in my palm. Aged twenty-two years. I've spent a lot of time thinking about that bottle. It is often an accessory in some of these obsessive fantasies. In one fantasy, I walk into the restaraunt, toss a stack of greenery on the counter and earnestly say to the cashier, "Quick! I have an important salad to make!"

In another, related fantasy, I am throwing away lettuce. Such roughage isn't befitting of my new vinegar. No, I will have come to a point where the fame and the aristocracy will have corrupted me to my core. My new lettuce will be cash. Cold, hard cash, Mrs. Price.

Soon, I will be expending hundreds for a block of myzithra cheese. My imaginations have now gone beyond posessions, though. Certainly, I have thought through my acquisition of grecian urns, motorcades, airlines, pyramids, dinosaur bones. Occassionally I'll see wind-tossed cities on the news and I'll jot down on my shopping list: Hurricane.

But, now I'm seeing a larger goal. Simply put: what if I amassed such a fortune that the mints couldn't print enough to keep up with my demand? So, everyone else would be forced to use Monopoly money as actual currency. And you would have to win in Monopoly to keep food on the table. These would be some seriously tense games. I mean you go to mortgage St. James Place and your kids start crying. In addition, I think you'll begin to see the end of those who choose to use the Free Parking square as the underground coffers for city funds.

You've got to hand it to fun money, though. Fake money rules. You can get your hands on it so quickly. For a moment, it seems like you're crazy rich. When I was a kid, I got with some of the neighborhood kids and we built this little Tijuana on our street. We made our own pesos and wore sombreros and everything!

One kid was selling hot tamales for two pesos each. Two pesos! Did this kid know that the money was fake? Was he out of his mind? Who invited this kid? Didn't he know this wasn't really Tijuana? Maybe he was really from Tijuana! Maybe these were real pesos! Let's go make more real pesos! I think we even had a tavern where you could get totally hammered off Kool-Aid. There's nothing like a bunch of kids stumbling around, mumbling incoherently with punchy red clown lips.

</comment></comment><comment><USER4> In the very oldest version of digg to be found on the internet archive, if you view source there's an sql query inside an html comment. Embarrassment, trapped in amber forever.

<comment><USER5> <http://web.archive.org/web/20041209040106/http://digg.com/>

<comment><USER6> Proof that The Internet does indeed hate you, and wants everyone to remember it forever, even if you don't.

</comment></comment></comment><comment><USER7> "If I'd played around with every piece of technology I should be using whether I felt like it or not, I'd never have got anywhere."

I feel like this all the time. Sometimes it's better to do a less-great job in a language you know backwards and skip the learning curve of a new tech.

The site works really well btw: after entering a handful of my favs it took my a while to get through all the games I already like to find new ones - so it's doing something right :)

Thanks for the interesting read.

<comment><USER8> Great, I'm glad to hear it's proving useful! I'll do a follow up with how well my NoDB implementation stood up to the pounding it's getting at the moment later in the week...

<comment><USER9> Here's a feature suggestion for you from a fellow BGGer: Allow users to restrict the search to games from with specific amounts of players.

<comment><USER8> Yeah, #players and playingtime are both on my list of things to optionally filter. Just need to find a nice way to do it without complicating the initial user experience.

</comment></comment></comment></comment><comment><USER10> I haven't looked at this data to know if this would fit, but SVD worked really well for the Netflix prize.

When I first heard its use in recommender systems I laughed and then thought... wow, that's kind of perfect.

Here's a good explanation if you're not familliar with it, and very accessible to those who haven't studied linear algebra (or haven't thought about it in a long time) <http://journal.batard.info/post/2009/04/08/svd-fun-profit>

<comment><USER11> +1 to this... I've had _very_ good luck using SVD/LSA-ish approaches for building recommendation engines.

HOWEVER- the big catch with naïve (i.e., simple to implement and understand) approaches to LSA are that every time you add a new datum, you have to recompute the SVD of your data- which is time consuming, and raises some interesting logistical challenges when done in the context of a web app (i.e., how you persist your matrices, etc.). There are more sophisticated LSA approaches that get around some of these problems, but they're more complex to implement.

Nothing insurmountable, but kind of a pain nonetheless, and w.r.t. the system described in the parent post, I'm not sure how well they'd integrate with GAE- can you use NumPy/GSL/etc. on GAE? Or would you be stuck using some sort of Java numerical computing library?

<comment><USER12> I'd love any resources you could point to that were helpful to you when builder your recommendation engines (also, do you have links to the actual engines?). I've been going through a tutorial to understand how SVD works [1], but it would be nice to find something that will help me deal with implementation details. I thought I might just use Gensim [2] for now, but the authors of that tool themselves say that Gensim is more of a framework to learn about these things rather than a production-ready tool.

[1] [http://www.miislita.com/information-retrieval- tutorial/svd-l...](http://www.miislita.com/information-retrieval-tutorial/svd- lsi-tutorial-1-understanding.html) [2] <http://nlp.fi.muni.cz/projekty/gensim/index.html>

<comment><USER11> Sorry for the delay, I just now saw that somebody had replied. Regarding links to the systems- the only one that was ever publicly accessible was for a Facebook app that I wrote some years back that was let researchers post links to their publications on their profiles, and also featured a recommendation system to find other users of the app that had "similar" publications. It's unfortunately fallen into a pretty sorry state of disrepair, as I haven't had any time to devote to maintenance in more than two years and Facebook's APIs have changed quite a bit since then. I described the underlying system a little bit in a conference paper: <http://view.ncbi.nlm.nih.gov/pubmed/18999247>

The other systems I've used the approach for have all been along either bibliometric/bibliographic lines, or have been relating to content-based image retrieval. It's a pretty robust approach, but can take a little bit of tuning to get just right- coming up with a good evaluation strategy is important to getting the most out of it, I've found.

As far as references that were useful:

Ilya Grigorik has a very accessible getting-your-feet-wet tutorial on his site: [http://www.igvita.com/2007/01/15/svd-recommendation- system-i...](http://www.igvita.com/2007/01/15/svd-recommendation-system-in- ruby/)

It might be a little dated w.r.t. specific libraries or APIs, but the basic technique is there. For a more comprehensive look at the SVD-IR approach, take a look at:

Berry et al. Using Linear Algebra for Intelligent Information Retrieval. SIAM Review (1995) vol. 37 (4) pp. 573-595

The SVD approach falls in the same family as Latent Semantic Analysis, which is a whole black art unto itself- I'd actually suggest going back to the early papers by Landauer, Dumais, etc. if you're really interested- those guys did a great job writing up what was at the time really novel stuff.

My contact info should be in my profile, drop me an email if you have any more questions (or to let me know what you end up doing!).

</comment></comment></comment></comment><comment><USER13> Another great story on 30 days to an "overnight success". Launching a product, even a "weekend project" is just damned hard to get right, end-to-end. Harder than you think out of the gate. I love how this puts things into perspective.

<comment><USER14> Actually I think this just raises the bar - "Look, it only took 2 hours * 2 weeks to make something useful."

Now everyone who has been slaving away for >24 months to make their own end- to-end power monitoring solution feels slightly lame.

Look ma - power monitoring in only 1200 hours! (<http://gridspy.co.nz>)

</comment></comment><comment><USER15> I've used that same template before. Opened the article and was like "oh god, is this about one of my embarrassing weekend projects?"

</comment><comment><USER16> "I remind myself that pride is another I Ain't Gonna Need and get on with it." YAGNI applies liberally.

</comment><comment> brown9-2 Anyone know which analytics tool is generating these graphs? <http://media.tumblr.com/tumblr_lai5rgUrSd1qd3z7l.jpg>

<comment><USER17> <http://www.analytk.com> [http://www.analytk.com/view/?url=http://yieldthought.com/pos...](http://www.analytk.com/view/?url=http://yieldthought.com/post/1345897970/10-flaws- that-made-my-weekend-app-possible)

<comment><USER8> Ah, my other unreleased side project has come to light. Time to add some login screens, then :-)

<comment><USER8> Actually, forget the login screens, it can stay public. This is the first time I've ever launched a site in a 4th level comment, though.

Analytk's a pet real-time blog tracking site I wrote because I was thoroughly dissatisfied with the typical ones. It tracks each post individually, updating every minute to begin with (exponential backoff after 1 hour, not truncated). It also picks up HN and reddit ranks and scores, and tweets. It's only half- finished. Please be nice.

<comment><USER17> Whoops, didn't mean to out your pet project. I enjoyed your post and I too was curious which analytics script you were using so I checked the page source to see what was going on. I wondered about the lack of documentation on the homepage...looks cool though.

</comment></comment></comment></comment></comment><comment><USER18> There was a time in my life where I really thought I needed to keep up with the latest and greatest technologies, libraries, et cetera. As the author discovered, you don't need to. I can now sleep easily knowing that I 'marked as read' the newest no-sql magix and do x y & z gems that I really didn't mind to read about. Great read.

</comment><comment><USER19> moconnor: did you keep a journal while you were building this app?

I'm thinking to myself as I am reading this that there's no way you could have gotten from A-Z, then only after that started filling in the blanks accurately about what you did on day #X. (Heck, I can't remember what I ate yesterday!)

Motivational, good stuff, thanks for sharing.

Now I'm thinking of an app for HN'ers who just need a little help getting something like this off the ground: An app that lets you chronicle every day a short paragraph of what you did to move the ball forward.

Plus, there will be a nagging^H^H^H^H^H^H^Hpeer-accountability feature built- in. Your progress is public and other HN'ers can "tap" you on the shoulder if there's a lack of progress and say "what's up with this?"

<comment><USER14> Personally, I keep a timesheet on when I started and finished working on something, for instance

Tue 19/10/2010 | 15:40:00 | 17:10:06 | 1:30:06 | Looking at admin interface for sensor daetails. Trying to fix None issue, seems to be related to subclassed models. Adding code to twisted for CT settings

Turns out that one of my Django models is breaking the Django admin interface, and also that I have to have calibration details for the Current Transformer sensors we use (<http://gridspy.co.nz>)

Another one

18/10/2010 | 8:50:00 | 9:56:36 | 1:06:36 | Server maintaince, removed orbited, checked memory usage. Killed backup scripts, installed python 2.7

Naturally it is all in an Excel spreadsheet. :)

<comment><USER19> Do you find that it helps? The closest thing I got that looks like what you got above there are my git log messages!

<comment><USER20> Seconded. Using distributed RCS, you commit often and therefore have a pretty good log of your daily activities.

<comment><USER14> I don't commit anything with

"Talked to client" "Wrote email" "Made blog entry" "Spent 60 minutes wasting time doing X"

Also, the gaps in the timeline are just as telling. I always feel that little bit guilty returning from HN and seeing a 1hr gap where I could have worked.

</comment></comment></comment></comment></comment><comment><USER21> AppEngine is amazing. It's free web-hosting, that also happens to include everything you need to make webapps.

 _The man who never made a mistake never made anything_

</comment><comment><USER22> "Day 5 - Embarrassing Flaw #3: Making a stupid business plan, then ignore it anyway"

Awesome! (I lol'd) I love inventing. It's only recently that I've started to add business logic to my imagination, I'm no Jedi in this capacity, but the force was strong at startup school; and I want to train!

</comment><comment><USER23> I just put a Flash game into the sponsorship process today. I made the initial game in 48 hours for Ludum Dare some months back. Then I returned to it and put in approximately another 72-96 hours(real-time, not work-time) of effort, spread out between Thursday, Monday, Tuesday, and this morning, to rework the theme, polish everything up, and bulk out the content.

Its obvious flaws are having no animation to speak of and minimal tutorialization, but in comparison to the bloated things I've worked on in the past, it was a breakthrough performance. A game in five-six days of work. I'm going to start on another one, now... hopefully I will finish around the 25th :)

</comment><comment><USER24> Nice writeup. Did you consider using Google's Prediction API before rolling your own recommendation system?

<http://code.google.com/apis/predict/>

<comment><USER8> No. I thought about Directed Edge, but playing with recommendation algorithms was the raison d'etre of the project. I didn't want to make a web site and throw some amazon referral links at it, I wanted to play data miner!

<comment><USER25> That's great! [http://techcrunch.com/2010/09/15/hunch-taste-graph- business-...](http://techcrunch.com/2010/09/15/hunch-taste-graph-business- model-api/) is another alternative. Maybe you could try tweaking your algo continuously and comparing with how well hunch recommends stuff. The advantage of the hunch api is that it is able to use a lot more info about the visitor to make more awesome predictions. Just curious to see how far it goes!!! <http://hunch.com/developers/v1/>

</comment></comment></comment><comment><USER26> A while ago I did a somewhat similar board game web app. I wanted to find a better ranking than what is on boardgamegeek.com Alas another weekend project that hasn't really gone anywhere.

<http://icefox.net/picktheboardgame/>

Based off of an older (more fun) app I wrote a long time ago: <http://toybin.org/pickthetransformer/>

</comment><comment><USER27> This convinced me to use AppEngine for a tiny little project I've been thinking of this past week. It'd be useful to me, probably others, but knowing that I wouldn't have to worry about anything on the hosting side (be it bandwidth, uptime...) would be nice.

Actually, I'm looking forward to have some time soon to get started...

<comment><USER28> also www.heroku.com

<comment><USER29> I really wish they'd show me what I can run on Koi (links to current sites). I know they make deployment a snap, but I worry that I'd be forced to add more and more resources to keep my site running as I'd hope.

<comment><USER30> The only difference between Blossom and Koi is the size of the database. The only way to improve performance is to increase the number of dynos or workers you use.

<comment><USER31> This is actually possible to do dynamically[1] so you can keep your costs down. I found this post last week and implemented it over the weekend, and it's pretty neat to watch it work. So far I've only implemented this for workers, but it's certainly possible[2] to implement it for dynos.

[1]: [http://blog.darkhax.com/2010/07/30/auto-scale-your-resque- wo...](http://blog.darkhax.com/2010/07/30/auto-scale-your-resque-workers-on- heroku) [2]: <http://github.com/ddollar/heroku-autoscale>

</comment></comment></comment></comment></comment><comment><USER32> get it done; make it right; make it fast

</comment><comment><USER33> Munich? cool, I'm probably not so alone :)

<comment><USER8> Call in at <http://combinat56.com> sometime; there's always a couple of devs doing interesting stuff there.

<comment><USER33> I know about combinat56 but their website and their self presentation turned me a bit off.

<comment><USER8> Shame, it's a really nice place to work. Nice Sumo sacks, too. There's a couple of HNers work there; I'm around most afternoons.

</comment></comment></comment></comment><comment><USER34> Wow, great idea. I am envious.

</comment><comment><USER35> So I take it from the comments that, "We'll be back shortly. Our servers are over capacity and certain pages may be temporarily unavailable. We're incredibly sorry for the inconvenience." is not the embarrassing flaw?

<comment><USER13> Why do these observations of a site being down get downvoted so harshly? The observation is accurate for him, and it _could_ be for everyone...

<comment><USER36> Because they're trite. For example, it seems like whenever somebody posts an article about databases, there's a comment saying, "Whoops, looks like your database doesn't scale after all! Haha". Similar versions (such as this) for web hosting, etc.

If you're going to take the time to post a "hey is this down" comment, at least link to the site's google cache or something. Otherwise it's just noise.

<comment><USER8> Especially when the blog's hosted on tumblr and the app on GAE ;)</comment></comment></comment></comment>


The Education Visa: It's Everywhere We Need It To Be - <AUTHOR> http://mattmaroon.com/2009/04/11/the-education-visa-its-everywhere-we-need-it-to-be/

<comment><USER2> >"Startups often make money primarily by reducing costs, and cost reduction nearly always means job reduction."

This is an old, old, old mistake people make when talking economics. "The Luddite Fallacy" - to be exact.

Yes, technology that reduces costs and automates production means the loss of jobs. However, it also increases the total production of society, which increases demand for other jobs.

We used to be a nation of 90% farmers. Now about 2% of workers are involved in agriculture. What happened to the other 88%? They aren't unemployed. Rather, they are employed in other jobs that never would have been created if those agricultural jobs were not destroyed by technology.

<comment><USER3> While your statement is true long term, short term there's still lots of pain from adjustment.

<comment><USER4> And when you build your economy on the short term, rather than the long term... well... look around you.

The long term has a way of happening.

</comment></comment></comment><comment><AUTHOR> I think the missing piece of his essay is that the ultimate goal is not job creation; it's for everyone to be better off. That is accomplished by increasing productivity.

Increased productivity doesn't necessarily imply fewer jobs. It might mean that everyone works less hours. There hasn't always been a 40 hour work week. It's only that low due to society's increasing productivity.

</comment><comment><USER5> This essay is internally contradictory.

"Startups often make money primarily by reducing costs, and cost reduction nearly always means job reduction."

"If a company hires an employee whose efforts earn the company three times their salary, that gives said company the cash flow to hire two more people."

So basically, creating www.replace-your-secretary-with- web-2point0-technology.com and selling subscriptions destroys jobs. Probably true. But writing replacethesecretarywithvisualbasic.exe for a salary creates them?

The only real difference I see is that a startup will (hopefully) have a bigger impact.

</comment><comment><USER6> _Will "startup investors" discover a lucrative black market in selling H1-Bs? Rich foreigners could pay them $200k under the table to invest $100k in their new startups, thus buying citizenship._

Just following up on this particular point, what would be the problem with letting rich foreigners buy American citizenship?

Personally I think Paul's startup visa is a great idea, but orthogonally to that, I just don't see a problem with letting wealthy people buy their way into the US.

<comment><USER5> I've often thought this might be the best way to select immigrants. Pick the number of immigrants we want, and distribute green cards via dutch auction. We can give bonuses to areas of national interest, e.g. nurses.

Doing this, we import people who are most likely to be productive. To allow high human capital pople to compete, we could allow the immigration fee to be paid out over 10 years with a nation-dependent down payment required up front (e.g., $75k for brits, $10k for indians).

Of course, politically this is a no go. Politicians push immigration as a way of importing people to vote for them (e.g. dems want poor Mexicans and reps want skilled former Soviets); the good of the country comes second.

<comment><USER7> So you're saying importing more people like those that worked in Bear Sterns would have been in the national interest? This sounds completely backwards to me.

Besides, with your particular method, how do you prevent people from over- bidding and then being unable to pay the fee?

No, whatever algorithm is used to select immigrants, wealth surely is not the thing to use.

<comment><USER5> Based on our knowledge back when Bear Sterns was still alive, yes. It would have been our best guess as to what is in the national interest. It turns out that the best guess would have been wrong, but that's unavoidable. Perfect information isn't available, and people make mistakes. Our central planners didn't know any better than the markets (Bush, Clinton and various other politicians tried to inflate the housing bubble).

As for those who don't pay up, immediate deportation without the possibility of re-entry. Combine this with a policy of enforcing immigration law, and we might get a workable system.

<comment><USER7> Given how many startups fail, you don't think "life without parole" is a bit harsh? It certainly will prevent them from trying again...

I also think that if you average over a long enough time span, it seems that those that hit the moon, money-wise, at one particular time barely break even over the long run. (Except they've already taken home their _own_ salaraies, of course.) That's what I meant by it being a bad idea; at any given time the highest earners will, by selection effect, be those with the riskiest, most highly leveraged strategies. I can do without those, I think we need people that create wealth, not concentrate it into their own hands.

</comment></comment></comment></comment></comment><comment><USER8> The book Illusions of Entrepreneurship claims that existing companies create more jobs than new companies. Starts at page 153: Here's the google books link: <http://bit.ly/m4vXV>

<comment><USER9> I don't see how this is an argument against entrerpreurship. Every existing company started out as a new company at some point. If anything this is an argument _for_ entrepreneurship.

</comment></comment><comment><USER10> Poorly written response with as many bad arguments as good ones, but I agree with the sentiment. The startup visa idea strikes me more as one that comes to you and seems good for the first hour until you come to your senses, than one that is well thought out and backed by good data. Luckily I haven't yet started to blog, so I don't need to back that feeling up with good data or reasoning of my own. :)

</comment><comment><USER11> Here's why the current government won't back PG's startup visa idea: Walmart is hated by too many in the Democratic party. A program to create a bunch of Walmarts owned by foreigners will be even more hated.

A distinguishing characteristic of a start-up is that it has the potential to make big profits for its owners: either by creating an new technology (like Google did), or by drastically reducing the cost of an existing technology (like Microsoft did). Walmart is an example of a company that made its founders rich by reducing costs. Walmart is also hated by many Americans and their elected politicians because it causes many employees of its competitors to lose jobs. I don't think that a government program that encourages foreigners to come to America in order to create businesses that make its owners rich by drastically reducing costs (including labor costs) will be any more loved by the Walmart-hating crowd.

</comment><comment><USER12> "Startups often make money primarily by reducing costs, and cost reduction nearly always means job reduction."

It seems that is the crux of your argument against Founders Visa.

(1) The flaw of course is that you are only looking at job reduction--and not the jobs that were created as a result of blogs and online news.

And even if the jobs created were fewer than jobs lost, that is free market: sooner or later it had to happen. The worst thing we can do is be delusional that it won't happen. The best thing would be to figure out jobs that are not going to exist and re-train those people for more sustainable jobs.

(2) You don't seem to be so much against Founders Visa as against startups in general. You might as well be arguing against ALL startups--not just those started by immigrants--using this line of argument.

</comment><comment><USER13> Unless you have about the education of a PhD in economics and have studied the impact of the US economy by allowing more visas (e.g. will the median income of Americans increase?), then I don't think an essay or a blog post will have much influence.

 _what we need now isn't another Google, it's another Wal-Mart._

Add the adjective "vertically-integrated" before Wal-Mart and you may have something.

</comment><comment><USER14> Another 3 cheers for HN!

Obviously, this place is full of PG worshippers. Therefore, the fact that this article made the front page, while disagreeing with PG, _suggests_ that lots of people vote up based on thought-provoking-ness, not on agreement.

And if so, that's cool. :-)

<comment><USER7> People like a good target... ;-)

</comment></comment><comment><USER7> _... what we need now isn't another Google, it's another Wal-Mart._

Yeah, because Wal-Mart is known as a big net job-creator...

</comment><comment><USER15> Probably won't go over too well on HN lol. You can't go against pg for goodness' sake!</comment>


Gamify your development projects - <AUTHOR> http://www.gitpoints.com/

<comment><USER2> "Gamify all the Githubs."

Using a terrible meme as your company slogan is ill-advised.

<comment><AUTHOR> Not sure how the product is, just requested an invite. But gamifying development does sound interesting. Although I would be interested in knowing how much does it effect the team spirit and does it encourage individual contributors over team players.</comment></comment>


Not going dark (ruby metaprogramming) - <AUTHOR> http://weblog.raganwald.com/2008/06/not-going-dark.html <comment><USER2> I think this would be easier to do if they would improve Ruby's syntax to have all expressions be enclosed in 2 delimiter characters of some kind (the first would signify the beginning of an expression and the second would close it). Expressions can of course be nested. For calling functions, the first element in the set would be the symbol the function is bound to, and the other elements would be its arguments. This way functions and data would have the same notation. These simple changes to Ruby's syntax would make rewriting or generating expressions, whether at compile time or during run time, much more graceful.

<comment><USER3> Sounds like a brilliant Scheme to me.

<comment><USER4> Liking interesting syntax proposition.

</comment></comment></comment><comment><USER5> Rewrite, for people who are more comfortable having their code parsed to an AST, modified, and recompiled, by a third party library, than they are with making sure they don't pick stupid method names for Object extensions.

<comment><USER6> I think some of the suggestions around namespacing methods would also help, and would help in a very clean fashion. But as long as extending core classes happens in a single global namespace, there are going to be problems.

Although it wasn't mentioned in this particular post, the problem is acute for people using extensions for their own third-party libraries. If you install gem foo, and it uses something with "stupid method names for Object extensions," your code is now infected with stupid method names for Object extensions.

What happens if you use gems foo and bar and they conflict with each other? Even though you went out of your way to eschew Object extensions, the authors of gems foo and bar may not have been so hygienic.

My hope is that _some_ mechanism for avoiding this problem becomes popular. This may not be it, but crossing yourself and hoping nobody else uses your method names or conflicts with each other does not scale very well.

<comment><USER7> Part of the problem is Ruby's hackish module system. When you include a module, you are taking everything, whether you like it or not.

I have created a library to help manage includes, and make them more like imports in other languages that have real modules. (You can selectively include methods from a module) <http://github.com/gregwebs/module-import/>

blog post [http://blog.thoughtfolder.com/2008-03-11-real-modules-for- ru...](http://blog.thoughtfolder.com/2008-03-11-real-modules-for-ruby.html)

If this used some of your ruby parsing magic to analyze dependencies, it would be a lot better.

<comment><USER5> I totally don't see how this is a win. The monkeypatch problem is that multiple people are competing for the same names on Fixnum, String, Array, Hash, and Object. To solve that problem, your code would need to allow a Fixnum to support Numeric#to_asn1 in _my_ code, but pretend not to have it everywhere else.

<comment><USER7> This is not a solution to the problem, but it picks away at it. The goal of this is to prevent unnecessary namespace pollution. So if in your code you say

      class Object
        import MethodChain, :tap
      end

You will never import MethodChain#chain or any other methods into Object, and you will never have to worry about re-writing those methods.</comment></comment></comment></comment></comment>


Your Twitter bio sucks - I think I can fix it - <AUTHOR> http://swizec.com/blog/your-twitter-bio-sucks/swizec/1914

<comment><USER2> Interesting. Besides the "dynamic" thing, it would be great if this can be a service like Gravatar but for "About" profile.</comment>


Mob Programming – The Good, the Bad and the Great - <AUTHOR> http://underthehood.meltwater.com/blog/2016/06/01/mob-programming/ <comment><USER2> Upvoting because it's a fascinating idea.

I find it weird they didn't really point out any down-sides, possibly because it's a corporate blog and marketing wouldn't let them.

Off the top of my head though, I'd be worried about:

\- No time to think. I find I solve solutions by thinking about them, and I can imagine mob rule would lend itself to less thinking and more doing (fastest solution that sounds half-right gets done first). Similarly…

\- Biggest personality wins. I'd worry that whoever had the largest personality would drive everything, leading to people being disengaged. Especially when it comes to engineering / structural decisions, if that person thinks they know whats best you're not going to have the chance to try something (and maybe fail) and grow as a developer

\- No personal space. You know, maybe it's because I work from home, but sometimes my fiancee messages me a video of a cat being cute, and I might just take 2 minutes off working to watch it, because I'm a human being and not a sack of watery meat sacrificed to the gestalt. I could imagine it would be very awkward to do anything at work that wasn't explicitly working, which sounds pretty suffocating to me.

\- Constantly bringing people up to speed. Maybe this is actually a good thing? IDK, but I think if some people are faster than others, or people wander off to make a coffee or whatever, or come in at different times, or leave at different times, you may spend a lot of time going over the same decisions and working through the same problem spaces over and over again. This could be a good thing, or it could be OK that some people know about component X and some know about component Y and there is little overlap.

If anyone from Meltwater is reading this I'd be interested to know if you had any problems (these ones or other), because it sounds like-- ignoring the first month-- this plan has no flaws. Which seems hard to believe.

<comment><USER3> I believe another reason to not pointing out the flaws come from mob thinking. It becomes very hard to criticize "the collective".

And yes, I think you have a great point on Biggest personality wins, that is already a problem on meetings. Lot's of amazing developers I've worked with had a hard time speaking in meetings...

<comment><USER4> I wonder if you could set up a round robin programming order. Something like switching which is typing every day. So like whole team puts input while one person types, then delegate one person to drive the discussion. I don't know if that would help much though or just put it back into pair programming with extra overhead.

<comment><USER5> (Author here) We do round robin for keyboard input, but a lot more often than that. We try to switch a couple of times each hour.

We do not have a particular person driving the discussion though, I do not see that that would help us in any particular way.

<comment><USER6> In my limited experience pair programming it usually went like, "How about if we combined these and frobbed _before_...aww, let me drive and I'll show you." Who had the keyboard might stay the same for hours, or might switch every 15 minutes, depending.

<comment><USER7> Or just plug in several usb keyboards and mice into one computer so everyone can type without switching chairs or handing the keyboard over.

<comment> yoz-y From the photos it does look like they did just that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This is an introvert's nightmare. I feel like going to a room and turning off all the lights just reading about this.

I'm glad it seems to be working for them, and I'd be willing to give this a try for a week, but I'm not even sure if I'd wait 'til I had a job lined up before giving my two week notice.

If I have to spend eight+ hours a day doing nothing but talking to people, I'm going to have no energy left for anything else. If I were single and childless, I could maybe manage this for a month, but with a wife and child, the amount of stress would be insurmountable.

<comment><USER9> My first thoughts exactly. I'd be very surprised if there were not at least one introvert on that team (there's an awful lot of us!) and would love to get their perspective.

Introversion isn't always obvious. I'm guessing in that situation, I'd seem perfectly fine during the day while I'm there, but totally unable to sleep when I got home because of all the talking swirling in my head.

<comment><USER8> Weird, when I'm in that sort of situation all day, I usually feel like doing nothing but going straight to sleep.

</comment></comment></comment><comment><USER10> I'm an agile coach and my clients won't stop talking about this.

Here's the deal, some 70%+ of developers are introverts. Mobbing can be great for fixing a bug or mentoring more than one person at a time but mobbing is not how you should expect your devs to work all day every day. This is probably not lost on fellow HN'ers but OMG the cargo culting amongst managers. Do not let them see this article.

Lastly, watch this time lapse video of a team mobbing and pay attention to the body language. Who is plugged in, who is checked out, who is talking the most? I think this says it all. [https://youtu.be/p_pvslS4gEI](https://youtu.be/p_pvslS4gEI)

<comment><USER11> When studies show pair programming is less efficient than individual programming for senior developers, and a wash for intermediate developers, I have to assume this is a crutch for a room full of junior/poorly-skilled developers who are helping each other get work done.

Put me with a junior developer to just "pair program" and I'll be doing all the work. I've done this before as a training exercise; I think in about 12-16 sessions, each from 2 to 4 hours, the person I was paired with made one suggestion. And I still wasn't 100% efficient because I stopped a lot to explain what I was doing.

Put me in a mob programming environment with junior developers and it will be spectator programming, or I'll be wasting time "navigating" for a junior developer and cutting my productivity by 80%. I can't help but think that even teaching could be done better than that. (For reference, the person I paired with above insisted that it was extremely helpful and educational, even though it seemed hard for me to believe.)

<comment><USER12> Can you cite the studies of which you are referring? I had not heard that the efficacy of pair programming is correlated with member seniority prior to this comment.

<comment><USER11> Sorry, last time I looked for references I couldn't find them. But I did read of at least one study to that effect. To me it seems like proving the sky was blue, though.

Remember, to be efficient, pair programming has to produce more correct code than two developers would have done programming individually. Mob programming would need to produce 5x the correct output of 5 developers. It just seems insanely unlikely that me and another developer pairing could be more than 2x as efficient as me on my own. I just don't miss that many things or get stuck almost ever.

People come to _me_ for design advice, so I don't think having someone there to work with me on the design side would be useful either; I don't spend a lot of time flailing, I just write out really solid code, really quickly. Aside from that: I am fully in support of design meetings to sketch out architecture.

Today in ~6 hours of programming so far I would have saved about 4 minutes tracking down something that I typed wrong and that broke the tests that a second developer might (probably would) have caught. But another senior developer could have written code for 6 hours as well if they hadn't been watching over my shoulder. If we're talking about senior developers, how can you _not_ assume they'd be able to create more code with a keyboard and no interruptions?

It really just _doesn 't make sense_ that experienced developers could possibly be more efficient if only one person is typing. Junior developers? Sure, at least that's a reasonable assumption. They have so little idea what they're doing, putting two inexperienced brains together on the problem might mean they produce more than twice as much, because they collectively know enough to work far more efficiently together.

But for experienced senior level developers? I think the burden of proof is on the advocates of pair programming. Extraordinary claims and all.

The main exception is when you have two distinct subject matter experts working together on a problem. Even then I like to have two keyboards, so it's not strictly pair programming, but collaborative/synchronized programming, with expected frequent questions and back-and-forth. I did that once recently when connecting a C/C++ low latency video and audio streaming library to Unity3d and C#; I worked with a Unity expert and while he wired up the Unity side I wired up the C++ side. I laid out what the Unity part needed to look like, and he told me how Unity interfaces to DLLs on Windows. We frequently bounced ideas back and forth but were working on different parts of the code. Worked great; had the integration working in a couple hours, plus or minus.

<comment><USER13> > to be efficient, pair programming has to produce more correct code... how > can you not assume they'd be able to create more code with a keyboard and no > interruptions

I measure efficiency by less code not more

<comment><USER11> >I measure efficiency by less code not more

Really? So if I produce _no code at all_ or just delete code, I'm being the most efficient, even if the goal is to add new features?

If you're going to pick on semantics, you shouldn't do it with a statement that's blatantly false on the face of it.

By "correct code" I mean code that is:

* Properly designed, refactored if necessary

* DRY

* Robust

You can't add features to "correct code" while strictly removing line count. No one is just counting lines of code here; your point is specious.

</comment></comment></comment></comment></comment></comment><comment><USER5> Hi guys, one of the authors here. Wow, the interest was a lot higher than we expected

Since you all have been asking, here's a negative excerpt from an earlier version of this post, which unfortunately got cut before the final draft. I'm starting to feel like we should write a follow up post now, but in the mean time, here's this:

"It was not all positive. Finding a smooth way of working took a long time, and we lost team members along the way, presumably at least partly because they did not enjoy this. Personality differences became painfully obvious, and a lot of time was spent talking openly and honestly to each other on how to stop rubbing each other the wrong way.

Taking on new people is both easier and harder in this setting. The bonus is that they will come up to speed with the work a lot sooner. The drawback is that you have to redo the personality resolution dance before work will run smoothly again."

My take on the introvert/extrovert thing:

I'm definitely one of the extroverts on the team (even though I, like introverts, get completely exhausted by too much interaction). I thrive in a communicative environment. We have a pretty fair mix of people on the team, and we've spent some time trying to find the balance of that, leaving room for people to leave the mob when needed etc. We usually do not mob for eight hours a day - reality hits, someone comes in early, someone likes to work late, we attend meetings, we are all parents and sometimes have to work from home, and we try to encourage each other to leave the mob at times. My guess is that we mob approximately 70% of the time. My impression is that our introverts, while finding it tiresome, are a lot more expressive and take up more social space in the group than before. The extroverts have worked hard on stepping back and leaving space. We still have ways to go, but we're getting there.

We are just one team in an organization of many teams working on different parts and features of the same system. We do not feel that we need to understand 100% of everything all the time, but our general knowledge has most definitely improved, and rapidly so. We all feel more comfortable around our own components than before.

</comment><comment><USER14> "Here's the crux of it, typing isn't the bottleneck in software development"

This isn't a good argument for mob programming imo. This argument pretends as if the only reason programmers would ever work individually (or in pairs) is because more keys can be mashed in less time.

In reality, we work individually (or in pairs) so that work can be completed asynchronously. I can fix a UI defect while Jim fixes a performance issue, and Sue adds a new feature being requested by a potential client.

Having worked on a large team, and being an introvert - mob programming would have been a disaster. We had one or two extroverted personalities on the team, and they would have driven the entire effort while the majority sat and watched.

It's really cool that this works for someone. Great teams adapt and find a process that works. However, I would advise leadership at any company doing mob programming to carefully observe the more introverted personalities on the team. They probably won't say anything, but they might be dusting off their resume.

<comment><USER15> It's not about sync vs async. It's about performance. People who take up pomodoro-type work tracking are surprised at how hard it is sometimes to get 25 minutes of work done.

I know many people who perform their best when they are training somebody in a system, or are recording training, or doing a webinar. Pair programming evokes the same improvements, and it lasts.

When you're being watched you're more present, and you perform better. I would say that pair programming, assuming no huge personality friction, is more than twice as effective as single programming. There are some companies that only do pair programming, most likely because of this realisation.

<comment><USER14> You're making arguments for pair programming which is different than mob programming. Pair programming is fine. I did it for two years. Like everything in software, there are tradeoffs, but I had no major complaints.

</comment></comment></comment><comment><USER16> > Work never stopped.

It shouldn't stop anyway. This way just seems like work got a lot more inefficient.

> Knowledge sharing increased

Sure... But I imagine it's hard to keep track of it all.

> The overhead got removed.

And a lot more overhead just got added.

> Anyone could go to any meeting.

Where is the win? Meetings should be targeted problem solving sessions anyway.

> Our tooling improved. When working together like this every minute is > precious, and laborious manual procedures that you just buckle down and get > done as an individual can no longer be tolerated.

I can see this being useful.

> Individual weaknesses could be overcome.

And individual strengths could disappear.

> Interpersonal issues and friction had to be resolved.

For me it just seems like they would grow and destroy the team.

> Stress levels dropped.

As an introvert I can't imagine a more stressful environment.

> We became more daring and forward.

A fear is that you resist change more and you become less forward.

> We became friends.

I don't think I would in an environment like this. But anyway, what relevance does becoming friends have with being productive and running a successful business? It's super good not to hate each other but everyone being _friends_ might even be counterproductive.

Why oh why did you list 10 positive things but didn't even bother listing the negative aspects? I dunno like this completely destroying your productivity or it being a completely horrible working environment for introverts?

<comment><USER17> Meta comment: I really hate it when people quote multiple individual sentences and respond to each one separately (usually with a single sentence of their own). It sounds flippant and juvenile.

<comment><USER16> Interesting, I haven't thought about it like that. It certainly wasn't my intention.

</comment></comment></comment><comment><USER18> I have not had the chance yet to use mob programming on a real project. But I have used it when teaching workshops and trainings. And it worked pretty well.

The first thing I noticed is that no-one tuned out. When I organized my trainings so that participants do the exercises alone or in pairs, some would just not do them. They might have too much problems to even get started. Or, when pairing with a better developer, just let them do the work. In the mob, paid attention everybody joined the discussion. [1] Also, I think there was a better shared understanding of the examples and the solutions after the mob programming. When working in pairs, I had to monitor 5-8 pairs in parallel and give them hints and explain stuff. With the mob, I could concentrate on one screen and join the discussion all the time.

And: Others were helping me out. At one point, a participant said: "I don't want to take the driver seat, I am no programmer, just a manager". Before I could even say something, someone else from the audience said: "Come on, try it. We tell you what to write, and after 10 minutes, we'll change again anyway".

So, to recap: I really like mob programming for teaching. I think it could also work well when a team wants to learn something new, has a hard design session or wants to bring new team members up to speed. I even think it could work during day-to-day work, but I have never tried that.

[1] Maybe I was just lucky and had a great group when we were duing mob programming. But I doubt that.

<comment><USER19> This is a really good idea: for workshops.

I don't know about day-to-day or in a classroom setting though. Whenever I did pair programming in college, one of the partners would often be overpowering in terms of skills and intelligence, and would spend most of the time getting the other up to pace. Which is great, except the laggards would often pretend to understand in fear of being looked upon as stupid.

As someone who's been on both side of the dynamics, yeahh, not sure about classroom settings. I would love to attend your workshops though!

</comment></comment><comment><USER20> Similar experience here at our dojo.

Mob programming is great : we've had people working effectively in languages they don't know. And so we've had product guys sit with us and practically transformed them into programmers, able to fulfill their vision.

Issues get identified much faster, and design decisions are quickly discussed and tried. Because we're able to get feedback on why we're developping, it's much easier to make the right choice for the right situation.

Test code is much more relevant, and it's much more expressive, too.

> \- Biggest personality wins. I'd worry that whoever had the largest > personality would drive everything, leading to people being disengaged.

Honestly, we didn't run into this problem at all, maybe because it's a dojo setting. Since we're used to mobbing, people will usually be extra careful about it. When there are many people, setting up a fishbowl is a good exercise to teach people to leave more room to others. I've had deadlocks happen during pair programming, but in a mob, it's much rarer. Also faster experiment time leads to much more tries.

> \- Constantly bringing people up to speed. Maybe this is actually a good > thing?

Definitely a good thing. People asking question is a good predictor of hard- to-maintain code.

<comment><USER21> "dojo"?

<comment><USER22> I assume they have a kickass system for scheduling sessions and visiting instructors. I worry about their technique, though, if the spend their time programming rather than practicing martial arts... /S

</comment></comment></comment><comment><USER23> I used to use the term "mob programming" to describe a phenomenon I saw at a shop where I used to work. Officially, the process was Extreme Programming, but the physical layout worked for more. There were two "islands" of workstations with five workstations each - two of the largest monitors we could get those days (24"), room for two seats, and spare chairs. Developers each had small private cubes on the outside walls for email, phone calls, and such. Coding work was done at the islands. In theory, it was "pair programming".

What happened in practice was that any number of programmers might be gathered around a workstation, from a single programmer for a straightforward bit of coding, to a half-dozen gathered around for a thorny problem or a coding/discussion session. It was extremely effective!

<comment><USER14> I worked on a team that was set up exactly like this. Like you said, it was really effective for some ad-hoc discussion about tricky problems. The knowledge sharing was fantastic and I learned a ton.

The major downside was the chaos. If you were the team expert in some domain, you usually had someone asking questions about that domain every 20 minutes. Sometimes programming takes 4 hours of uninterrupted concentration. That work was very difficult to accomplish.

A small group of us ended up bringing in laptops and separating from the group multiple (sometimes 5) days a week. We found ourselves having to choose between finishing our own work, or helping other people finish their work.

</comment></comment><comment><USER24> I was kind of hoping this would be about calculating loss ratios on protection rackets and coding rigged numbers games.

<comment><USER25> I'm open for all kinds of new things. What are you talking about? I guess it's an investment topic? I really don't understand at all what you are talking about, but I'm curious.

<comment><USER26> mob as in gangsters.

</comment></comment></comment><comment><USER27> I think this is a fantastic as a 2-3h team activity happening every couple of weeks, if there is a clear feature/bug to be taken care of. Also, great for introducing new team members or non-engineers to the codebase. Doing it full- time does sound weird though.

</comment><comment><USER28> The one thing that is never mentioned, and that I'd like to see the difference for, is cost to the business.

</comment><comment><USER29> Perhaps this is good for feature development, or maintenance, but, what about contracts that deal with wholly new development of a complex system? It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. Perhaps I am being disingenuous.

I do love the idea of being able to not let the numerous tedious meetings interrupt progress.

[edit] Thanks everyone for adjusting my perspective. I am sure junior engineers (and seasoned stubborn ones) would learn a lot with cradle to grave development in such a fashion [/edit]

<comment><USER30> Having spent thousands of hours pair programming I would assume that this is were mob programming is especially valuable. The decisions you make early on are the decisions that everyone on the team will have to deal with. So if you do nothing else as a team this should be it. I actually recently had a client who was lukewarm about pair programming. But they mob programmed on new laying foundation work fit new services. We pair programmed on three new services together at the same time. So much syncing had to happen afterwards that mob programming the foundation would easily have been more efficient and effective.

</comment></comment><comment><USER31> Jesus fucking nope. This is a good approach for some problems, and it may work for this team, for now, but I doubt that this is either sustainable or scalable.

<comment><USER32> This.

I've done mob programming a lot and it always seems to break down into either a few developers working while explaining what they are doing to others or a developer just typing what other devs tell them to type.

It does work well for knowledge sharing, but that is about it, IMO.

Also, its biggest proponents (where I worked) always seamed to be the devs who didn't actually do anything and had no real desire but learn. I'm guessing it is easier to sit in the back of the mob then fake work somewhere else. Always seemed to have a meeting when there turn got close.

</comment></comment><comment><USER33> How big is the mob? I don't think you want to do this 20 or more programmers (the more people you have, the more formalized communication structures you typically need).

I could imagine this working with four or five people, and I'd be worth the experiment, but I don't think I'd want to do it all the time.

<comment><USER5> (Author here) The team in this post was six when we started, four now (five if you count our coach who's actually worming himself into the mob now ;) ).

I would definitely not do this with 20. Then again I really wouldn't want to work in a team of 20 no matter the method.

</comment></comment><comment><USER34> I've desire to want to try exactly this. No more 2-week long code reviews, where 2-3 reviewers debate (slowly) over Github about the naming of a local variable. No more drawn out A vs B problem solving. No more 2x a day sync ups. Just put all the stakeholders in a room and crank it out together.

<comment><USER35> You'd still want to do code reviews after mob/pair programming though, because:

\- the whole team might not be here and needs to review the changes to catch up.

\- doing the wrong thing as a mob is still doing the wrong thing, and you may need more eyes on your code to spot that (especially if everyone during the session was convinced that what was written is right)

\- IMHO, even if 10 persons were involved in writing it, a later review of the code can still improve quality (because people will actually be reading the code rather than writing it, which will expose other kinds of issues)

<comment><USER36> Who reviews, if the mob consists of everyone? If I participated in developing a thing, I would have probably already made the oversight, wouldn't see an issue.

That raises an interesting idea, you split the team, the mob and non-mob, like learning vs testing data. Dedicate some fraction of the team to the mob, then rotate out members. It seems like most of the benefits are realized, if people need skills or compassion for other roles of the project expanded, they get their turn. If the team is large enough that the mob is a minority, you minimize the effect of downsides.

</comment></comment></comment><comment><USER37> FWIW, I'm getting:

uBlock Origin has prevented the following page from loading:

[http://underthehood.meltwater.com/blog/2016/06/01/mob- progra...](http://underthehood.meltwater.com/blog/2016/06/01/mob-programming/)

Because of the following filter

||meltwater.com^

</comment><comment><USER38> I think if you are passionate about a methodology then you'll make it work. To truly measure the efficacy of a methodology you'll need some reasonably unbiased observers from outside the group.

</comment><comment><USER39> @teams that have tried this,

Do you find problems with bridging background knowledge across roles?

For instance, you have programmers with 5+ years experience reading/writing code. They understand basic data-structures & design patterns through second- nature. Does this create conflict and/or dis-engagement between the programmers & the non-programmers (management, QA, etc)?

Typically, I work on teams with scarce technical employees. Most of the team are there offloading work that doesn't require the coding background.

</comment><comment><USER40> I think the idea from mob programming and pair programming in general is that a single programmer working on a piece of code is a liability. Everyone is prone to making mistakes and taking shortcuts especially when rushing for a deadline or when tired. More people means reduced risk especially if the skill set is diverse. Though if bugs in the code aren't much of an issue (ie fixing it quickly results in no repercussions) then one person should be good enough.

</comment><comment><USER41> I'm having a hard time seeing this as a win. Maybe I not understanding it. You say 70% of your time is spent this way. Just looking at my own coding there's just sooooooo much busy work. Add this field on that dialog, pass this variable to that other class, write that test, etc ... my point being 5% of my work is thinking about the problem an 95% is typing, testing, iterating. Maybe I'm doing it wrong?

</comment><comment><USER42> Intriguing concept, but I find a balance of solo work and group collaboration to be the most effective method to accomplish goals. That's why our team invests in weekly or daily (if deadlines make them imperative) reviews of our successes, key updates, and distractions. This forces us to review and reflect on work, receive good feedback, and pushes each member in the right direction.

</comment><comment><USER43> I propose that this be codified as Borg Programming.

A more amoeba like approach could also be an interesting experiment, allowing for teams to split off and regroup as problems fall into specialty areas, regrouping to handle tests, acceptance, training, etc. For a smaller team this may not be feasible, but for a larger group it could be really interesting.

<comment><USER44> HA HA! Author here.

Our team name is "The Borg"

</comment></comment><comment><USER45> This looks superfun, can't wait to find a team to try it with someday.

</comment><comment><USER46> We would spend to much time arguing until it's just a one man show at work because one of us believes they know it all.

<comment><USER46> Annnnddddd you lose out on trash talk #personToMyLeftIsAJerk

</comment></comment><comment><USER47> While it sounds like they made this work for their team, I can't help but be reminded of the Borg..

</comment><comment><USER48> how did they even manage to stay all awake?

</comment><comment><USER49> No one is as dumb as all of us.

</comment><comment><USER50> Mob programming because they don't trust the individual developers to deliver by themselves, mob programming because no one has a clue there and they hope there is wisdom in the crowd, and mob programming because they had nothing else to do.

<comment><USER36> > individuals don't deliver > no one has a clue

Welcome to Earth.

Most teams are not able to attract or retain talent, so they have to focus on maximizing and concerting effort instead.</comment></comment>


Killing the Hydra (2013) - <AUTHOR> https://markhkim.com/blog/mathematics/killing-the-hydra/ <comment><USER2> I don't understand the game rules fully. What happens if a head is cut off which is connected directly to the root? Rule (2) says

 _Go to the node right below the node connected to the severed head—labelled in purple in the diagram—and reproduce n copies of all the nodes and the segments above the selected node. Here, n is the number of times Hercules has attacked the Hydra thus far._

But if we cut off a head connected to the root, there is no node below the root. So then what?

<comment><USER3> I don't even see a way to reach a point where Hercules could cut off a head directly attached to the root node without having already created more necks and heads than what he destroyed. I'm probably missing the larger point of this, but I don't see how the hydra can ever be killed.

I imagine a simple example of 2 necks of length 2 connected to the root. If Hercules cuts off one head then at least one new neck of length 2 will grow in its place, always creating a scenario worse than before. What am I missing?

<comment><USER3> I looked around online and the description of the game in this article is inaccurate. When a head is severed the only node that is duplicated is the parent to the head (along with all its remaining children). I originally believe that all children of the head's grandparent were to be copied.

 _Go to the node right below the node connected to the severed head—labelled in purple in the diagram—and reproduce n copies of all the nodes and the segments above the selected node._

Compared to [http://googology.wikia.com/wiki/Kirby- Paris_hydra](http://googology.wikia.com/wiki/Kirby-Paris_hydra)

 _We start with a finite rooted tree T. Call its root R.

Jonathan picks a leaf vertex of the tree and a natural number N. Call the leaf A and its parent B:

A is deleted from T.

If B = R, nothing happens. Otherwise, let C be the parent of B. Consider the subtree consisting of B and all its children; copy this subtree N times. Attach all these copies to C._</comment></comment></comment>


Rails 3.0: Release candidate - <AUTHOR> http://weblog.rubyonrails.org/2010/7/26/rails-3-0-release-candidate <comment><USER2> "We'll be making sure we get performance of Active Record back to at least 2.3 levels before release." Why call it a Release Candidate if you still plan on tweak more stuff?

<comment><USER3> Because we're not going to change the interface to make the internals faster. And we might as well spend the time that the RC is out there looking for bugs to make things faster as well.

<comment><USER4> This may be a source of confusion. In most circles, release candidate signifies that this should be the final release, and will only be changed if new bugs emerge.

<comment><USER5> The exact meaning of terms like "beta" is subjective, but "release candidate" has the it right there in the name.

It's not a release candidate if you literally state that it is not a candidate for release.

<comment><USER6> Exactly. Not to mention if you know you're going to be working on it, there's always the chance new bugs can emerge as a result.

If I install the final version I'd expect that means it's the exact same version as the most recent release candidate and no critical bugs were found during that period. _Not_ the most recent release candidate, plus a bunch of tweaks that were made while everyone was testing. And if you're already assuming there will be another release candidate before a final, then this isn't a release candidate.

</comment></comment></comment></comment></comment><comment><USER7> For new RoR programmers, is it recommended to just start in with Rails 3, or stick with Rails 2 until Rails 3 "stabilizes"? There are a bunch of Rails 3 books out there; do they generally line up well with this release candidate, or are they full of old information that a new RoR programmer would stumble upon and not understand how to fix?

[EDIT] The three books I saw available that specifically mention Rails 3 in the title are available for pre-order, so hopefully they will be pretty up-to- date.

<comment><USER8> The most up-to-date book is the free Rails Tutorial <http://railstutorial.org>, which will be updated to Rails 3 soon after it's final is released.

If you have an older book using an older version of rails, DON'T use Rails 3, use the version used in your book (DHH mentioned this on an episode of coderpath <http://coderpath.com/posts/1>)

<comment><USER9> There's actually a semi-secret version of the _Ruby on Rails Tutorial_ book already updated for Rails 3.0.0.rc:

<http://railstutorial.org/book?version=3.0.0.rc>

Shhh... Don't tell anyone! :-)

(The official release of the _Ruby on Rails 3 Tutorial_ book should happen some time in the next couple weeks, probably slightly ahead of the official Rails 3.0 release. Of course, the tutorial will also be updated after Rails 3.0 final drops.)

<comment><USER10> Now I have to start the tutorial all over again...but thanks! This should be a lot easier than looking up for myself how Rspec 2 works and so forth.

<comment><USER11> Just so you know, Rails 3 RC plus all the associated dependencies with rspec now core dump on integration ('requests') tests even though controller testing works fine. It looks like there is a webrat/rspec usage issue. I assume they'll get it fixed in a few days.

<comment><USER9> I'm glad to know it's not just me. The tutorial book pins RSpec down to 2.0.0.beta.18 for just this reason. (It looks like 2.0.0.beta.19 is the one that has the problem.) Of course, I'll update the tutorial with the latest RSpec version once they fix this issue.

<comment><USER11> Here's the rspec ticket to keep an eye on:

<http://github.com/rspec/rspec-rails/issues#issue/140>

<comment><USER9> Thank you—this is _very_ helpful.

<comment><USER11> While you're here :) I wanted to say that your book/tutorial is really well done. I was working through the 2.0 version and simply figuring out what needed to happen for 3.0. Thanks for the link to the 3.0 version. I'll let you know if I any problems or confusing parts.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I haven't had a look at 3.0 yet. What's the effort like to upgrade? I have this suspicion that it's basically going to be a major rewrite for most of my projects with all the new apis and deprecation. It's almost as if it were a completely separate project that offered some degree of Rails compatibility to help people transition. _However_ , that's the impression I get from reading things - how is it in practice for those who have updated significant code bases?

<comment><USER13> The core Rails APIs are mostly the same, though you'll have to basically rewrite a couple of files in config/. I'm currently porting a moderately large application from 2.3, and few of the remaining unit test failures have anything to do with the Rails core.

Your biggest problem will be that a number of third-party gems have been heavily updated for ActiveSupport 3.0, including RSpec, Devise and Mongoid, and these may cause more headaches than Rails itself. Figure a few days of updating stuff and staring at unit test failures if you rely heavily on these gems.

Of course, all bets are off if you use a lot of dodgy, unmaintained gems that heavily monkey-patch Rails. We have a pretty strict policy against using dubious minor gems that stick their fingers deep inside Rails, after some bad experiences over the past couple of years.

</comment></comment><comment><USER14> What's the upgrade path like from Merb?

<comment><USER15> Quite simple, I rewrote a medium sized app in about a day, and actually fixed a few things too.

I found it really easy to upgrade from either rails 2.3.x or merb.</comment></comment>


Regulating Facebook will be one of the greatest challenges in human history - <AUTHOR> https://www.theguardian.com/commentisfree/2019/apr/28/regulating-facebook-will-be-one-of-the-greatest-challenges-in-human-history <comment><USER2> > "Regulating Facebook will be one of the greatest challenges in human > history"

Somehow, I don't think that regulating a single company (or even an entire industry) compares with challenges like:

\- Landing the first humans on the moon

\- Defeating Nazi Germany and its allies in World War II and rebuilding Europe in the aftermath of the war

\- Eradicating infectious diseases like smallpox, etc.

\- Enacting civil rights legislation in the U.S.

\- Toppling Apartheid in South Africa

The EU has already made progress in regulating the advertising/surveillance industry by enacting GDPR. If the U.S. summons up the political will to enact a similar law, Facebook will have been substantially reined in.</comment>


Show HN: Express Web Components - <AUTHOR> https://github.com/scramjs/express-web-components <comment><USER2> Guess we've made full circle back to the 90's with the Classic ASP.NET runat="server" crap.</comment>


Bloglines On Life Support. This Story Needs An Ending  - <AUTHOR> http://www.techcrunch.com/2009/08/10/bloglines-on-life-support-this-story-needs-an-ending/ <comment><USER2> I'm a Bloglines user, and it never really occurred to me that there were any problems. Sure, they've been calling their latest release "beta" for a couple years, but that's nothing in this post-Google age. I have no idea what their revenue is like, or even what their business model is, but I sure am one satisfied user.</comment>