Looking for a co-founder - <AUTHOR>

Hey,
I'm looking for a co-founder (ideally technical, with experience in Node.js, PHP or Python and experience in Linux) to build a database as a service startup with me.
If you want more details, or just want to contact me, email me at firstname.lastname@example.com.
Thanks! <comment><USER2> Why do you want to use Node.js?

</comment><comment><USER3> Interesting, but you should be more clear if you want people to contact you.

</comment><comment><USER4> What's the problem you're trying to solve, first off?

<comment><USER5> Not OP. I am guessing a service along the lines of StormDB or postgres.heroku.com.

</comment></comment><comment><USER6> Just curious: why are you using a mailinator account?

</comment><comment><USER7> could you be more specific about the project ?</comment>


Do you want to live for 1k years? - <AUTHOR> https://philandrews.io/post/do-you-want-to-live-for-1000-years <comment><USER2> Would I like time to seem to last longer than it does?

Undoubtedly yes. Life is too short.

Extending life arbitrarily to 1000 years would lead to some very strange outcomes. Presumably reproductive cycles would stay the same length. This would cause an uncontrollable population boom. It would also mean that you'd be living at the same time as your grand-grand-grand-[...]-grand-children. The family dynamic would become totally different, and I'm not sure that would be a good thing.

<comment><USER3> I think this comes with certain expectations that for 3/4 of those years you'll be able to live better than an 80 year old today. We really should define our terms before asking such questions.

</comment></comment><comment><USER4> Definitely not. One of the things that makes existence tolerable for many of us is the assurance that it is ending quite soon.

Although I can see why people would choose to stick around for much longer. I suppose one legitimate reason to live for 1k years is to satisfy one's curiosity about the future and see how it all turns out.</comment>


Innovation Is Required: 9 Lessons Learned Working At A Startup - <AUTHOR> http://www.forbes.com/sites/davidtao/2013/05/23/innovation-is-required-9-lessons-learned-working-at-a-startup/

<comment><USER2> I've watched Greatist transform from a website into a platform that helps an incredible amount of people in a short time. This is a great piece for anybody looking for information on startups.

</comment><comment><USER3> Great stuff from David Tao of Greatist. The guy has a ton of passion and motivation for everything he does, it's great to see him growing as a writer.

</comment><comment><USER4> sweet read, and great lessons especially #4 about the lack of structure in a startup environment.

</comment><comment><USER5> always an enjoyable read from DTT, great work!</comment>


Objective-C Parameter Names Unneeded in Headers - <AUTHOR> In an Objective-C "@interface" the names for parameter variables don't really matter.  In fact, they can all be exactly the same name, and different from the "@implementation", which is useful in header files.
Method names are almost always descriptive enough.  If parameter names are identical, there's less to maintain; I like using a single underscore "_" for all header-file parameters.
Here's an example of a method that has lots of parameters, where the parameter names are kind of pointless:

  @interface UIView : . . .

  + (void)
  transitionWithView:(UIView *)         view
  duration:(NSTimeInterval)             duration
  options:(UIViewAnimationOptions)      options
  animations:(void (^)(void))           animations
  completion:(void (^)(BOOL finished))  completion;

 They could actually have just said this (changing all names to "_"):

  @interface UIView : . . .

  + (void)
  transitionWithView:(UIView *)_
  duration:(NSTimeInterval)_
  options:(UIViewAnimationOptions)_
  animations:(void (^)(void))_
  completion:(void (^)(BOOL finished))_;
 <comment><USER2> If you want to generate documentation for your API, this won't work. Documentation generators such as doxygen require unique parameter names in order to function correctly.

Slightly related, I'd argue that "animations" is very poorly chosen. A plural noun indicates a set or collection of objects, whereas this is a block pointer to be used for... something...

<comment><AUTHOR> It's possible to make Doxygen look at a source file instead of a header...at least in C++ it is.

As for the name, this is Apple's method name from UIView so ask them. :)

<comment><USER2> It might be possible with Objective-C as well, but then you end up with it exposing all your private stuff (unless you manually mark everything internal as "hands off"). Not sure which would end up being more work. Furthermore, it means that the users of your API can't look at the header file (via CMD-click) for an explanation.</comment></comment></comment>


Angel Investors To Startups: Yes, We Charge - <AUTHOR> http://www.pehub.com/52616/angel-investors-to-startups-yes-we-charge/

<comment><USER2> Where exactly is the argument? What I read was this:

The charge: Angel groups charging entrepreneurs to pitch are ripping them off. The incentives are all wrong. You are not getting your moneys worth. It is a scam fuelled by founders desperate to pitch, not a business connecting capital to opportunities. It is similar to modelling/acting agent-ing scams. You can tell it is a scam by the level of secrecy.

The defence: (1) Two of the named companies defend their practices. (2)entrepreneurs have "a sense of entitlement" (3)TechCrunch50 conference makes a lot more money off startups than they do (4)who are chosen to move forward get weeks of free coaching and mentorship on their pitches before they're asked to pay. Also, entrepreneurs don't have to pay — they can drop out if they want. (5)"We are not in this to make money," a (unidentified) spokesman said.

1,2 & 5 do not actually say anything. 3 is neither here not there. No one ever said that startups are a no profit allowed world. That leave only 4, a relatively vague claim that these groups add some sort of value to the process.

</comment><comment><USER3> Have any of these groups ever funded anything of note? Top Valley angels not only don't charge but are insanely helpful for free even if they don't fund you (if you're not a jackass that is).

<comment><USER4> Moreover, they are usually very transparent about their investments.

</comment></comment><comment><USER5> "We are not in this to make money." Well _that's_ a sentiment that doesn't entirely inspire confidence.

<comment><USER4> They could have been talking about their returns on past investments.

</comment></comment><comment><USER6> _They said some entrepreneurs have "a sense of entitlement" and believe that whatever they do is worth a hearing._

this sounds like something an unenthused teacher would say about an enthusiastic student

<comment><USER7> They are right. I've met ton's of "entrepreneurs" who knew nothing about business or even technology, but think the world owes them something for their magical idea. Regardless of how cool the idea really is, it must be very hard to work with these people without first teaching them the basics.

Obviously this doesn't apply to anyone who follows a relatively "lean startup" mentality [like those here], but there are orders of magnitude more people who do it the old fashioned way.

<comment><USER2> What exactly are you saying? They should be ripped off to teach them a lesson?

<comment><USER8> I know the sort of person he's talking about. If you don't explain up front what you want from them, they'll assume you were put on earth to help them in their glorious venture and complain endlessly about how you don't appreciate their genius, are only interested in money, etc. This is the sort of entrepreneur who budgets a fat salary for themselves from day 1. I've had people like that bellyache about how they can't afford to pay me more than peanuts despite the fact that they own 7 cars or a 40 ft yacht (actual examples from real life).

Edit: I have no opinions about the angel firms or their charging methods. I just got Trapper's point above.

<comment><USER2> When you say you got his point, did you mean you get how his point is related to charging people to pitch? I am completely willing to grant that such people exist and are unpleasant, but what relevance does that have here?

<comment><USER8> No, the point about how some entrepreneurs have a sense of entitlement. I think people reacted poorly to that here because they interpreted it as 'how dare you ask angels for investment', which would be offensive considering how many people struggle just to become ramen profitable, often for a long time before cashing in, if ever. Then there are other people who want to be compensated on the basis of projections rather than receipts. It's a blurry line since we know some companies where the founders make $$$ long before reaching positive cash flow.

As far as the 'pay to pitch angels' go, maybe they'd be better off describing themselves as a capital sourcing service or enterprise microcredit bureau or something, since people take 'angel' to mean someone willing to help when you've got nothing. I empathise with the tedium of dealing with self-promoters who think they're god's gift to business despite having money; on the other hand surely the payoff of being an angel is having founding capital in the one project out of 50 or 100 that hits the jackpot and eventually goes public.

</comment></comment></comment></comment></comment></comment><comment><USER9> This author seems to be trying to make the point "We are legit and we charge". But he never gets around to the "We are legit" part.

</comment><comment><USER10> They can say whatever they want, but it still sounds like paying your salesguy a salary instead of a commission. Coffee is for closers.

</comment><comment><USER11> I am certainly curious what PG's and YC's take on this discussion is.

<comment><USER12> Well, 4 years ago pg said, in one of his articles:

"Some angel groups charge you money to pitch your idea to them. Needless to say, you should never do this."

from <http://www.paulgraham.com/startupfunding.html>

So there you go.

</comment></comment><comment><USER13> For the most part, the only thing angel investors have is cash. They have nothing you should pay them for. Fred Wilson's support for Jason Calcanis' position is particularly telling, given that Union Square provides a great deal more than cash (I've seen them in action). If you have to pay to get a potential investor to listen to your plan, you either need a new plan or a new investor.

Paying angel investors for access is only one step removed from wiring money to Nigeria in a 419 scam.

</comment><comment><USER14> I don't understand why publicly lynch some company? why not market let work out its dynamics -- if it is not worthwhile people won't buy it. I am saying this because I have attended Keiretsu forum meetings and these are very nice people.. they maintain office/staff/provide food at events and put in lot of efforts to promote startups..If you have not attended meeting then please do so..They seem to be not making profits by charging startups but covering operational costs (I don't know financial details but this is my guess). Now question is who pays for the services - I feel it is not at all outrageous for companies to pay here because the companies they select are generally already revenue generating companies, many of the companies are not in related field to a particular angel..as a matter of fact they advice you not to invest for quite a few deals when you start so you learn ins and outs..If they start charging more to angel members then the number of angels who engage in the process might drop ..may be you will say those are not right kind of investors who you want but be careful what you wish for. There are number of people in the group who are rich enough to sponsor whole thing but again, that's another model..sponsorship has its own strings attached. Coming back to my first point - just having different operational model does not equate to scam and people without getting facts falling for propaganda is no good

</comment><comment><USER15> One of the lessons I've learned in the few years I've been in business is this: sometimes you do everybody a favor by charging them. While I'm not necessarily in favor of this practice for angel investors, I'm not going to condemn it either. If I was going to "pay-to-pitch" I would make sure 1) the concept is marketable (investigate competitors, keep my ear to street, etc) 2) that I had a damn good pitch. Unfortunately, some startups don't take the time to due these things or even think about the investors time. The fact is they do feel entitled. By charging a fee you eliminate the half-hearted and at least ensure that the start-ups pitching understand the importance of the situation. The companies named apparently provide a service that these entrepreneurs can not provide for themselves. They bring in the money. Therefore, they should get paid. Does anyone know if the angel investors get any of this money? Look if it's a scam it should be stopped, but if it's bad business it will stop itself.

<comment><USER16> > The companies named apparently provide a service that these entrepreneurs > can not provide for themselves.

Do they? What have they funded? What success has followed their coaching?

> They bring in the money.

Do they? Again - what have they funded?

And even if they do, lots of folks have money. If they're admitting that they're dumb money....

</comment></comment><comment><USER17> oh yeah.... here are some smoking guns (or "part two of angels that charge") <http://bit.ly/URKMR>

:-)

</comment><comment><USER18> Frankly I do not see how charging entrepreneurs to pitch is different from charging entrepreneurs for the TC50 demopit.

How?

<comment><USER4> I thought about this too and what it boiled down to is _who_ is getting the money?

If the fee is going to investors, I think it's bad.

If the fee is going to organizers for logistical expenses or heck even profit, I think it's usually fine.

1\. In TechCrunch50's case, it _is_ going to organizers.

2\. I don't think TC50 makes most of its money from entrepreneurs looking for funding. They make a lot of money from rich execs and VCs. Contrast the angel groups and they make almost 100% of the money from entrepreneurs. This is a _huge_ differentiator for me.

<comment><USER2> I don't think it matters who gets the money or who is charged. There is nothing wrong with the service at face value. Startups want to pitch. Here is a service to help them do this.

The problem with with the incentive structure it creates. If you are paying investors directly, its like paying someone to listen to a sales pitch. You will not get the same result as you normally do with your sales pitch. If you are paying organizers, you have to think about how the incentives work too. It may not take much to get investors into a room. Dinner, networking. You may be simply paying them indirectly. A startup has no real way of knowing if they got a bang for their buck.

If investors were paying, they would know. They won't be visiting very often at a high price tag if the pitches aren't good and if the chances of closing a deal aren't good.

<comment><USER4> _If investors were paying, they would know. They won't be visiting very often at a high price tag if the pitches aren't good and if the chances of closing a deal aren't good._

That's my point. Most investors have to pay a couple grand to attend TechCrunch50.

<comment><USER2> That is OK. Investors can't be conned very easily. They can tell if they got value from the event. The existence of a chance of being funded is more opaque.</comment></comment></comment></comment></comment>


The same high-speed user-space network driver written in different languages - <AUTHOR> https://github.com/ixy-languages/ixy-languages <comment><USER2> dup: [https://news.ycombinator.com/item?id=18788069](https://news.ycombinator.com/item?id=18788069)

<comment><USER3> Thanks!</comment></comment>


Why calculating is better than scheming (1987) [pdf] - <AUTHOR> https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf <comment><USER2> I've skimmed this article a few times now, and something I've always had trouble with was this:

 _"…problem like this are damaging if one is trying to present programming as a discipline subject to mathematical analysis."_

because _in general_ programmers steadfastly refuse to subject their discipline to mathematical analysis, and continue to look for some aesthetic balance between "enough abstraction" and "enough whitespace".

Here is a program to sum a list of numbers:

        +/

This definition is even less cumbersome than the Miranda or the Lisp, but it's unclear what the author expects us to conclude from this. _And yet_ I think it's perfectly reasonable to posit that shorter programs are better. Shorter programs have less bugs[1], and run faster[2], and yet for some reason there are a lot of programmers who believe their job is to produce _more code_. Fuck those guys. Seriously.

[1]: See Code Complete and Software Estimation: Demystifying the Black Art, by Steve McConnell.

[2]: [https://stacresearch.com/m3](https://stacresearch.com/m3)

Then we have the pursuit of "traditional mathematical notation": I don't think it produces better programs or better programmers. Computers do not execute mathematical notation, and mathematicians can't agree on their notation to enough specificity to permit as much useful computation[3]. It is clear that notation is important[4], but there is frighteningly little real research in this space. Zero-cost abstractions still take up source code, and yet many programmers think this is _given_ as a good thing, despite Dijkstra's wonderfully succinct observation:

 _"…the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length."_

[3]: See Whitehead and Russell, Principia Mathematica

[4]: [http://www.jsoftware.com/papers/tot.htm](http://www.jsoftware.com/papers/tot.htm)

Lazy is also bad. Computers aren't lazy. Starting off by thinking about them as lazy puts programmers on that path for total abstraction. So much energy has been put into trying to hide concurrency-problems[5] that it's no wonder most big-data programs generate so much heat. The real value in Scheme Streams is that they're explicitly concurrent, and other languages that have optimised for those constructs[6] have discovered a great deal of utility.

[5]: [http://hadoop.apache.org/](http://hadoop.apache.org/)

[6]: O=spawn(fun(P)->P!{f,self(),F()} end,[self()]), receive{f,O,X}->X end.

It's almost like we've plucked some ideas, said they're important, and then used them as a lens to study our languages without even doing _the first thing_ by showing how we can know they are important to the point of excluding everything else.

About the only thing I really like about Miranda (and Haskell, etc) is the pattern matching, which is dope. Seriously good stuff. I don't know how to square that with array languages, but I think it's worth thinking about since they (array languages) seem to have otherwise sorted out program length and notation.

<comment><USER3> > Shorter programs have less bugs[1], and run faster[2]

I'd heartily disagree with that statement.

Short programs can run faster, but that entirely depends on the implementation of the language/architecture that they're running upon.

Consider the following:

        struct {
          char msg[400];
          double d;
          int i;
        };

        struct {
          double d;
          int i;
          char msg[400];
        };

The code is nearly identical, only the order is different, but the second uses far far less memory than the first.

Secondly, shorter programs can be bug free, but that depends on the level of abstraction exposed, and how that translates into language that can be understood by those using it.

There's no shortage of regex bugs in the wild, and its a fairly concise language.

Perl has often been criticised for having too concise a language, leaving it prone to code rot.

However, all that being said, I think there needs to be a balance between abstraction, and mathematical analysis, and I would also say there hasn't yet been enough actual research into the effect of syntax, rather, syntax has been a result of the abstraction its presenting, or the underlying implementation the language relies upon.

We do need abstraction, parsing mathematic notation or estoric languages like Malbolge are difficult for the human brain, even with experience.

I mean, Brainfuck isn't that far from what a processor actually runs, being registers and jump statements, but...

        ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.</comment></comment><comment>.</comment><comment>--.>+.>.

We don't need a Turing Tarpit.

But neither do we need the insane amounts of boilerplate that Java forces upon you to do even the simplest things that Java is meant to be good at.

I think that in recent years, mathematics has given us the tools to build better syntaxes:

* Better type inference

* Better proofing of type safety

Though I think Scala's syntax is still overly verbose, DOT calculus is a great step in the right direction for being able to create a syntax with both zero cost abstractions, type safety, and a more concise syntax.

<comment><USER4> With GCC, both those structs seem to have a size of 416 bytes. Can you elaborate on what you meant?

<comment><USER3> 32 or 64bit GCC?

I was referring to Struct Padding[0].

Assuming a 32bit GCC, then the first would be padded with 24 bytes, the second with 16 bytes.

This padding doesn't show up under size, but does affect speed in small ways, and available memory (yay for dealing with memory constrained systems!).

[0] [http://www.catb.org/esr/structure- packing/](http://www.catb.org/esr/structure-packing/)

<comment><USER5> You seem to be misunderstanding how padding is applied. As your link says regarding structure alignment:

 _In general, a struct instance will have the alignment of its widest scalar member._

...which is d if we assume sizeof(double) == 8, so the total size will be rounded up to a multiple of 8. Both your structure examples will be exactly the same size:

        0 msg
        400 d
        408 i
        412 [+4 padding]
        416 TOTAL

        0 d
        8 i
        12 msg
        412 [+4 padding]
        416 TOTAL

<comment><USER3> > On some processors, the addressing of a member is more efficient if its > distance from the beginning of the structure is less than 128 bytes.

> In the first example, to address the d and i fields using a pointer to the > beginning of the structure, an offset of at least 400 bytes is required.

> Instead, in the second example, containing the same fields in a different > order, the offsets to address d and i are of few bytes, and this allows to > use more compact instructions.

</comment></comment></comment></comment></comment><comment><USER6> In case anyone is unfamiliar with the author Philip Wadler, he went on to be a key figure in the design of Haskell.

<comment><USER7> In particular the language Miranda he discusses here was a direct predecessor to Haskell.

</comment></comment><comment><USER8> this critique seems to be of the kind of lisp you find in introductory textbooks on scheme

most lispers like to play around with syntax, doing that in haskell usually results in write-only code

<comment><USER9> Yes the critique is from an educational perspective. Many, especially in academia, view syntactic abstraction as a method of last resort, so it doesn't feature in the courses. So one might ask why then suffer the syntax of scheme if macros are never used?

</comment></comment><comment><USER10> [https://www.reddit.com/r/lisp/comments/d177c/a_critique_of_a...](https://www.reddit.com/r/lisp/comments/d177c/a_critique_of_abelson_and_sussman_or_why/)

[https://www.reddit.com/r/programming/comments/ujj3/a_critiqu...](https://www.reddit.com/r/programming/comments/ujj3/a_critique_of_abelson_and_sussman_or_why/)

[https://www.reddit.com/r/programming/comments/13gfqt/before_...](https://www.reddit.com/r/programming/comments/13gfqt/before_we_all_get_too_excited_with_lisp_i_suggest/)

</comment><comment><USER9> All ancient history now, I heard that MIT now teach Python.

<comment><USER11> MIT uses Python now yes, but Scheme's offspring (Racket) is popular at a few universities. I've found Python easier to use though.

</comment></comment><comment><USER12> That critique had a lot of observations of the form "lisp is less good because I am not used to it". From the point of view of something with more lisp experience, quite a number of these observations would go the other way.

</comment><comment> white-flame This article needs a (1986) in the title, at least according to the handwriting on the 1st page.

<comment><USER13> It says "received". That often happens before a paper is published, but we want the publication year. That was 1987 according to Wadler's CV: [http://homepages.inf.ed.ac.uk/wadler/vita.pdf](http://homepages.inf.ed.ac.uk/wadler/vita.pdf).

<comment><USER14> > … we want the publication year. That was 1987 according to Wadler's CV ….

Or just to the ACM: [http://dl.acm.org/citation.cfm?id=24706](http://dl.acm.org/citation.cfm?id=24706) .</comment></comment></comment>


An open source rendering engine using WebGL to help discover the world of 3D - <AUTHOR> https://github.com/Donorhan/Lemon-JS <comment><AUTHOR> The goal of this repository is to get a clean start to learn 3D concepts like:

      - <USER2>
      - Rendering core (Material, Geometry, etc)
      - <USER3>
      - <USER4>
      - Model loading
      - How skyboxes works
      - …

Of course you can use this library to create 3D scene, all calculs and WebGL calls are put in a cache to get better performances.</comment>


Court rules "Dueling Dinos" belong to landowners - <AUTHOR> https://www.sciencemag.org/news/2020/05/court-rules-dueling-dinos-belong-landowners-win-science <comment><USER2> What were the legal arguments which swayed the minority of judges to vote for fossil rights falling under mineral rights?

<comment><USER3> You can read the full court finding here: [https://www.courthousenews.com/wp- content/uploads/2020/05/Di...](https://www.courthousenews.com/wp- content/uploads/2020/05/DinosaurFossils-MontSC.pdf) (linked from the article)

The concurring opinion delves into the common and dictionary definitions of the word "mineral" for the purposes of mineral rights and finds that fossils, in general, are not valuable because of their mineral content, so they should not fall under mineral rights laws.

The dissenting opinion cites previous cases the same court had handled in mineral rights disputes and further notes that the legislature had already passed a law clarifying fossil rights with the exception to any fossils currently involved in court cases, so the question at hand was whether this particular fossil was considered a mineral under Montana law. The dissenting opinion also points out that diamonds, composed entirely of carbon, pass the ruling's "rare and exceptional" test for value, despite being composed of something that's neither rare nor valuable. So why are these fossils being treated differently from diamonds?

As a fossil nerd I'm glad the ruling landed the way it did, but as a totally- ignorant-of-jurisprudence-layman, the dissenting opinion is more compelling and seems better written.

Since it was a 4-3 decision I was a little curious about the political leanings of the justices, but that data doesn't appear to be available.

<comment><USER2> Thanks. That's so interesting. I couldn't think of any legal reason to support the suit, since parties to a "mineral rights" contract are obviously thinking in terms of mining, and a valid contract must involve a "meeting of the minds." But it seems as though to some judges the words of the contract matter more than the parties' intents.

</comment></comment></comment><comment><USER4> Does anyone else think it's insane that you can own the land your house is on, but not under it?

Is there a good reason this exists? Is it like that in other parts of the developed world?

<comment><USER5> I mean we can get into the philosophical/legal nuances of what it means to "own" something. In NYC, there are air rights which partitions ownership of the literal air above you.

Should "owning" a piece of land entitle you to everything from the earths core all the way into deep space?

<comment><USER6> _Cuius est solum, eius est usque ad coelum et ad inferos_

Traditionally it goes further, all the way to heaven and hell. But in modern times, air rights are limited to what you can actually use from the surface; airplanes don't trespass, etc.

[https://en.wikipedia.org/wiki/Cuius_est_solum,_eius_est_usqu...](https://en.wikipedia.org/wiki/Cuius_est_solum,_eius_est_usque_ad_coelum_et_ad_inferos)</comment></comment></comment>


Bootstrapped, Profitable, & Proud: Braintree - <AUTHOR> http://37signals.com/svn/posts/2800-bootstrapped-profitable-proud-braintree <comment><USER3> _He took a few days off work and flew out to Utah, where his old customers resided. He asked them if they'd switch their processing to his new company, Braintree._

Every company I've worked at has strictly forbidden this kind of thing via a noncompete agreement. Essentially, it's in the name: "Noncompete Agreement"

Be careful what you sign, and be mindful of what you have signed in that past!

<comment><USER4> This is Bryan from Braintree. I was working for a different company at the time I visited my former customers. I honored the one year non-compete I had with my former employer.

<comment><USER3> Out of curiosity, did you catch any flak from former colleagues? I can imagine many people would still be quite angry, even if you fulfilled your legal obligation.

<comment><USER4> No, I didn't.

</comment></comment></comment></comment><comment><USER5> For anyone who hasn't used them yet, it's the one-stop-shop and their API that really sets them apart from the competition. You submit one set of paperwork and they take care of all the accounts: merchant, gateway and api. No need to chase down different accounts and get them all working together.

The fantastic API literally saved hundreds of hours of integration and build time, as the recurring billing, discounts and everything is completely programmatic and just works.

I just signed up within the last few weeks and throughout the whole process I could tell they built it up with developers in mind, not as an afterthought.

<comment><USER6> Well, the convenience sure does sound nice, but the rates are staggeringly high:

V/MC Non-Qualified: 2.89% + $.30

Cybersource+WFB clocks in at roughly half that for V/MC( although Amex rates are around that level ), with per-transaction at 10 cents or less.

<comment><USER4> If that's the case, they're losing money on your account because that pricing is below the wholesale bank costs (which is the same for everyone). You probably want to check the fine print or your monthly statement.

Our (Braintree) pricing is actually very competitive. It may look higher because we disclose all our fees. Nearly every provider we know obscures fees both during the sales process and in the monthly reporting statements so merchants never really understand what they're paying. Here's an example of pricing trickery [http://www.braintreepaymentsolutions.com/blog/Costco-your- ma...](http://www.braintreepaymentsolutions.com/blog/Costco-your-marketing- department-has-gone-rogue)

</comment></comment></comment><comment><USER7> "Who are the customers Braintree decided to write off? "It was a fool's errand to try selling medicine to those who hadn't yet experienced pain. Payment processing is complex. It's difficult for inexperienced merchants to recognize value. We'd spend countless hours trying to explain 'pain' and our cure but some just didn't care because they hadn't felt it yet...'"

That's money right there. And noted for the future of my business. People will pay for you to take away the pain of their bad experiences with an inferior service/product.

<comment><USER8> Perverse idea/thought experiment: what about creating two versions of some service X which are ostensibly competitors; one is a free/cheap version A with no support and one is a much higher-priced, supported and professional version B. The answer to support requests on A would mostly be "no", with the occasional "if you want that, use service B". Sort of an extreme take on freemium/market segmentation. A acts simultaneously as the top of a funnel for B (users who actually need the service and have experienced the pain of a bad offering) and as a screen for bad customers (the ones you'd "fire" for consuming more than their fair share of your resources).

<comment><USER9> I vaguely remember that in my previous career in grocery management that diaper companies did something similar. I don't remember the brands/companies, but one brand would be positioned at the high end while another was at the low end. The high end had all the 'features' - moisture sensors, velco tabs, etc. This allowed the one company to garner more shelf space, and thus eyeballs, which brought higher market share.

<comment><USER10> Market segmentation is a common tactic. Different consumers want different things and are prepared to pay different prices. They will however lump together anything under the same name.

So, for example, Cheap'n'Nasty Nappies Co may have done very well in the bottom market segment. It will now struggle in the higher segment unless it invents a new brand, say Bling Slings Nappies, with some ostensible differences ("6 layers of plastic!") and a much higher price.

You will see this practice in every industry with large firms. They will own multiple brands in multiple market segments.

</comment></comment></comment></comment><comment><USER11> Oh how I wish Braintree was accessible in Canada. We've haven't been very pleased with our payment processor as of late.

About a year ago I actually managed to get someone from Braintree talking with someone from Chase Paymentech Canada (since Braintree supports Chase Paymentech). Unfortunately, BT is integrated with CP Salem whereas CP Canada only processes through CP Tampa.

If anyone has tried to do this in the last year and succeeded, please comment.

<comment><USER12> We (Shopify) use braintree and are customers of Chase Paymentech. This is how we collect all our fees.

<comment><USER11> But I imagine you have a US domiciled merchant/bank account correct?

If you're doing that with a Canadian based merchant account, please send your account rep's info at CP or BT.

<comment><USER13> beanstream in canada is actually quite good, easy to setup, low fees, and has a good api (credit card data stored on their server). i looked at braintree, but couldn't use them b/c of canadian merchant. beanstream also lets you do funky things with canada/us currency (collect and settle in us funds, settle in US banks, etc.)

</comment></comment></comment></comment><comment><USER14> I'm excited to give Braintree a go someday, but what I really wish is that someone would come up with a system that was orthogonal to and independent of the existing banking system.

The banks and the regulations make all real credit card processing a major PITA, and while Braintree eases the process, they are not an exception as far as I can tell. They still have to underwrite and they still have to vet accounts for underwriting. If you have bad credit or anything else that would prevent you from getting a loan, you're not going to be able to process cards without PayPal, which means it's difficult to bootstrap yourself out of a bad situation.

One of the main reasons I think Bitcoin is cool is because it's a great experimental platform for this kind of stuff.

<comment><USER15> True, banking fees really do take up a significant post in the P/L, and the smaller you are, the more you're paying, why it's not optimal for startups. A startup bank would be a cool idea.

</comment></comment><comment><USER16> These guys are awesome—they power all our payments. The one thing I wish they could somehow add support for is outgoing EFT/ACH transfers.

We do have one funny story about them from Getaround... one night, early in the morning, we got a call directly from their CEO. Apparently we had written some bad code that was just hammering their servers—basically, we were accidentally DoSing Braintree.

Got it fixed up quickly, and have loved them and used them ever since!

</comment><comment><USER17> Love me some Braintree!

Their API & API Documentation are fantastic.

</comment><comment><USER18> While this is valuable, it is really a company that shouldn't exist - <USER2> needs to be forced to use a standard API and be barred from abusing their government monopoly.

</comment><comment><USER19> Am currently in the process of an application, so far their speed and quick understanding in meeting the needs of my solution has been first class.</comment>


Ask HN: Scale of 1-10, how much did you trust Cloudflare before and after ban? - <AUTHOR> <comment><AUTHOR> Just curious. Cloudflare published this a while ago: [https://blog.cloudflare.com/why-we-terminated-daily- stormer/](https://blog.cloudflare.com/why-we-terminated-daily-stormer/)

What is the temperature, though?

Scale of 1-10, how much did you trust them before the ban, and how much currently?

</comment><comment><USER2> 10 before the ban, 4 after the ban.</comment>


Show HN: Akayame, Yet Another Markdown Editor - <AUTHOR> http://akaya.me/

<comment><AUTHOR> What it does:

\- preview in context: the paragraph being edited is kept into view

\- converter: converts HTML or rich text TO Markdown, to import legacy content

\- document manager / library: stores documents and versions

Everything works locally, no login necessary, and no round trip to the server for save or download (documents are saved to the server as a backup, but it will be possible to turn this off).

Browser support:

\- tested successfully in most recent versions of Firefox, Chrome and Safari

\- actually works in IE8 too, but the UI is broken because of CSS misunderstandings (this will be fixed)

\- Opera almost works but the download function (which uses Downlodify / Flash) doesn't work, and hangs the browser if used. Not sure how to fix this.

Immediate next steps:

\- RTF export (in the works)

\- offline operation (almost done)</comment>


Ask HN: Has anyone earned any money on Binpress.com? - <AUTHOR>

I am building a JavaScript component for content management. I am not sure if I should consider Binpress as a viable way to earn money from it or I should focus my energy elsewhere and use Binpress as a tool to get additional revenue.<p>I have googled and found no numbers about revenue from the service. <comment><USER2> I've put up a Python component for sale there a week ago (no sales yet). It's still featured on the BinPress homepage, and in the past week I've got 230 views (highly irregular tho - half of them were on the first day and yesterday).

I imagine JS/PHP components might be more searched for, but overall, I don't think they have a big userbase yet. I imagine that's why they haven't publicized the numbers.

So to answer your question, don't try to offer the component exclusively there, but there's no reason for not using it as an additional sales channel.</comment>


Ask HN: Examples for badly designed (web) APIs - <AUTHOR> For a workshop I want to give some negative examples of badly designed APIs so that groups can work out the negative parts and how to improve them, anyone has some examples? <comment><USER2> I am not sure if its fit in the "bad design" category you look for but OpenStreetMap API has various usability problems.

[https://wiki.openstreetmap.org/wiki/API_v0.6](https://wiki.openstreetmap.org/wiki/API_v0.6)

The main issue has I see it is that all API functions accepts only XML as content-type. There is no way to use JSON, which is rather standard by now. Even GET serves only XML.

Another issue is that the error messages for non-conform requests are not informative enough. This is emphasize in the doc ("unfortunately error messages are not consistent").

Finally, in my opinion, the doc do not provide simple and clear overview of the API.

<comment><AUTHOR> Thanks a ton!</comment></comment>


Shared scooters don't last long - <AUTHOR> https://oversharing.substack.com/p/shared-scooters-dont-last-long <comment><USER2> This does not spell doom for these companies to me.

1\. These companies are focusing on growth, not cutting costs. Which is normal, rational and understandable. They can afford to lose huge amounts of money with the funding they have and the cost of not expanding as quickly as possible means automatic failure

2\. Clearly there is a lot of demand for the scooters. So if they can design a scooter with better durability and lower cost (becomes easier at scale) they can get the profitability up pretty quickly

3\. There may be other revenue opportunities down the line for the company who wins the market. Monetize customer data, ads on the scooters, maybe businesses would pay to have scooter hubs around them etc etc (I don't know exactly but it's not hard to imagine that these companies will find other ways of upping revenue per ride)

4\. Once there is less competition and more consolidation in the market they can potentially raise prices, if only slightly

<comment><USER3> >So if they can design a scooter with better durability and lower cost (becomes easier at scale) they can get the profitability up pretty quickly

Only to highlight how this appears like a pure truism: renting cheaper and longer lasting products (at the same fee/price level) increases profitability ...

The 28/32 days lifetime sounds more than a tad bit "off" by _any_ possible standard, particularly if the 3.49 trips by 1.63 miles are accurate.

30x3.49x1.63= 171 miles lifespan?

or - maybe easier to evaluate - 30x3.49x18 minutes=1885 minutes or 1885/60= 32 hours lifespan?

</comment></comment><comment><USER4> > In October, The Information reported that Bird was spending $551 per scooter > with a goal of reducing that cost to $360.

The full article is gated, but I'd be interested to know where that figure came from. It is possible for a private individual to buy the same scooter tax and import duty free for the lower of those two prices. I would _hope_ that multimillion dollar companies like Lime and Bird would be able to secure better pricing than that.</comment>


Grubhub Stock Just Lost a Fifth of Its Value. Yes, It's Earnings Were That Bad - <AUTHOR> https://www.barrons.com/articles/grubhub-stock-plunges-after-earnings-sales-were-bad-guidance-worse-51572298004 <comment><USER2> Good. Unfortunately we need more high profile flops in the public markets to get valuations back in line with actual business fundamentals instead of hype.

</comment><comment><USER3> For an outlet you can subscribe to [Barron's], you'd really think they'd have a copy editor.</comment>


Ask HN: My employer hacked/accessed by email and recalled email. What do I do? - <AUTHOR> I work in an academic establishment in the UK and recently, I have started to have some issues with my manager. To cut the story short, In an exchange of emails, I had pointed out how incompetent he has been and I had copied 3 of my team members in this email, (while I was away from my work place - accessed from my iPhone.) Workplace uses office 365 email service. Now, my manager or 'someone' at work, has got into my email box and 'recalled' this email I had sent. Obviously, it didn't work. As a result, all my access has been blocked (I presume my password got reset? I am not sure) and now, I am not able to get into my emails or the office 365 service. Currently, I am away from work, and will return on Thursday. I have a few questions to this end: (1) how can I conclusively prove that my manager or someone at work has gone into my email and recalled my email? (2) how did I approach this problem?<p>It is pretty depressing for me that an educational establishment has done such a nasty thing. <comment><USER2> You'll be wanting to talk to your union rep.

<comment><AUTHOR> I don't pay into the union - will I still be able to access them?

</comment></comment><comment><USER3> Are you sure you still have a job?

<comment><AUTHOR> No one from the educational establishment has contacted me to say I am not employed anymore... I don't have access to my emails and my colleagues say that they recieved an email saying my previous email was 'recalled' \- but the recall did torn since the emails had been opened by then..</comment></comment>


Pair Programming Economics - <AUTHOR> https://wiki.c2.com/?PairProgrammingEconomics <comment><USER2> I spent the first fifteen months of my current job on a 100% pair programming team before transferring to a more traditional scrum-based team.

Some observations: team cohesion on the pp team was much higher, code quality was higher. Flexibility, not surprisingly was lower: we had a very fixed schedule: "Stand up" at 8.06 (despite the name, it was unrelated to the scrum event, instead it was more time for sharing news and interesting things before the workday started), team stand up immediately following (this was closer but not quite the same as the scrum stand up), then breaking into pairs and working until noon, then an hour for lunch, then working 1-4 then an hour for individual work like training, administrative junk etc. Remote work was not typical although there were two or three remote team members who lived elsewhere and tele-paired three weeks out of four.

I'm hard of hearing so this was a somewhat draining experience for me thus my switch to my current team. Here, team members typically work remotely 1–2 days per week (largely a consequence of corporate policies which have fewer desks than employees). Each team has 2–3 offshore teams that we work with. It seems like we spend an inordinate amount of time in meetings (my calendar has 11 hours blocked off for meetings in a "normal" week and more is not uncommon). There's a tendency for information to only be passed on orally which isn't great with my hearing loss.

It's not strictly a comparison of PP vs non-PP but overall, I would return to the PP team without hesitation.

<comment><USER3> I have some hearing loss as well, and this clearly would kill it for me, even if I thought it was a good idea otherwise. I actually walked through the programming floor of what might be the largest pair-programming operation in the US and was shocked to see (and hear!) that it was concrete floors and ceilings with no sound treatment. Awful.

My suspicion is that the jawboning about pair programming has more to do with the fact that it's a legal way to weed out older programmers than for any real economic benefits. We're more likely to have hearing loss, and will _seem_ like poorer programmers in a pairing situation. Plus, we're overall less likely to put up with trendy bullshit like PP.

<comment><USER4> Is PP "trendy"?

The "extreme programming explained" book that (afaik) popularized it came out more than 20 years ago.

<comment><USER3> It was trendy then, and it's trendy now. It's a recurring fashion. Penetration in the real world is almost zero, and for good reason.

</comment></comment></comment></comment><comment><USER5> Personally, I dislike PP

\- hard for remote teams. Only good if everyone on the team can easily pair up.

\- only good if everyone follows a strict schedule

\- only good if everyone understands the problem and solution space equally. If one of us needs to go into a cave for an hr to read documentation or experiment, it all falls apart.

\- very mentally intense. You're always on. Can only keep it up for a few hrs without some massive mental drainage.

Overall I like PP for small problems to help teach someone. I dislike it for day-to-day.

<comment><USER6> I find it really hard to try things I'm not sure will work, or noodle around, or feel my way toward a solution, when someone's watching. Just incredibly uncomfortable. Since those sorts of things are where a lot of my value comes from, count me out on PP. It's fine in very small doses for specific purposes when both people want it and are already comfortable working together but I'd go fucking crazy being forced to do it every day on a schedule.

<comment><USER7> I like PP when I am working on an established code base making changes. If I'm working on a PoC or something, I spend more time with pencil and paper up front than I do at a keyboard, so PP is out.

</comment></comment></comment><comment><USER8> > A pair works at the speed of its slowest member, so it take at least 8 hours > for them to finish the "easy" coding.

Not necessarily. I pair with a guy who's probably 10 times as productive as I am(I really try, but I understand that I'm relatively slow), and he'll ask me to pair with him because I might come up with an idea for something that even he is stuck on. I often do, despite the fact that I'm much slower than he is at implementing things.

So while I do think that it can often be the case that a pair will only work as fast as its slowest member, most likely when tackling a large problem or even doing something tedious, that doesn't mean that there aren't times where a more productive member can value from pairing with a less productive member.

EDIT: This is entirely from my point of view, so it's possible that this person I mentioned feels differently. However, even if they were frustrated by my slow performance, I don't think they'd inquire my assistance on problems if they thought they wouldn't benefit from it.

<comment><USER9> And you will be better in the future paying interest for years.

He is forced to stretch himself and expressing ideas and concept one level clearer than otherwise. This helps him to move on another level skillwise.

</comment></comment><comment><USER10> I work at a company that does full-time pair programming whenever possible. There can be drawbacks for sure, but overall, I love it. However, one caveat is that our hiring process places emphasis on finding people that are collaborative and easy to work with as opposed to know-it-all "rockstar" developers. We also do test-driven development, so in addition to the most common pattern (driver / navigator) we sometimes do it a different way wherein one person writes the failing test, then their pair writes the implementation to get the test to pass along with the next failing test. Rinse, repeat.

I generally find the axiom "If you want to go fast, go alone. If you want to go far, go together." applicable to this context.

\----

Benefits of pair programming (IMHO):

* It eliminates the need for code review (most of the time) since another dev is providing input as you write.

* Pairing senior and junior developers is an excellent way to build the abilities and confidence of the latter.

* Pairing decreases siloing of knowledge and one individual's "ownership" of a particular feature or system. You much less frequently see things like "Oh, you have a question about our Widget Framework? Go ask Sally, she's the only one who touches that part of the code."

* You're less likely to implement hacky solutions just to get something to work because someone else is working alongside you. (At least, I am.)

* It's easier to find and fix bugs (in my personal experience) when you have two sets of eyes on the code.

* You have to slow down and explain your ideas before immediately jumping in and implementing them. I generally find that reaching consensus with my pair about the strategy to solve a problem helps surface edge cases I might not have thought of alone.

<comment><USER11> I've seen the following from pairing Junior and Senior engineers:

* Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing.

* Middle of the road junior engineers can be stunted and continually depend on the decisions / skill of the more senior pair. Pairing them more frequently with same level or lower helps. Sometimes this doesn't happen because this lower quality pair goes significantly slower and the result may need some code review/cleanup cycles, but it's a worthwhile investment.

<comment><USER12> I completely agree, with the right people, pairing to train is 10x faster. For the wrong people, it's 10x slower.

</comment></comment></comment><comment><USER13> Pair programming can be very useful when you're training someone new or starting up a new project and want to spitball ideas.

I was offered a position with full-time remote pair programming. That sounds like a nightmare to me and opted out of that one.

<comment><USER14> I said no to an opening like that as well. I have no problem doing it from time to time, doing it every day sounds like a total nightmare

<comment><USER15> It could work out if you split the work. You work in the am I'll take the pm. Half days.. not bad.

</comment></comment></comment><comment><USER16> Some people hate pair programming. I happen to be one of them. It kills my personal job enjoyment/satisfaction and if I was coerced into pair programming too often, I would find a job elsewhere.

So, the cost of losing one or both of the programmers in the process must be considered too.

<comment><USER17> True. It's also true a lot of people hate solo programming, and do not want a non pair programming job.

My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you'll most likely end up with two annoyed programmers, and not great code.

<comment><USER18> _My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you 'll most likely end up with two annoyed programmers, and not great code._

This is a popular argument among pair programming enthusiasts, which suggests there may be some merit to it. How do we reconcile it with another popular argument, that many programmers will naturally pair up on an ad-hoc basis when they're working on something challenging and/or interesting?

I can't imagine not wanting a second opinion from time to time, and I've certainly missed having one sometimes when I've been working solo on something and there was no-one else to talk about it with. But personally, I also can't imagine being comfortable in a full-time pair programming culture with necessarily restricted schedules and limited solo time. Sometimes, I just want to do some research or think through some ideas or play with quick and dirty prototypes for a while, even if I might be very interested in discussing my results or initial conclusions with other interested developers afterwards.

<comment><USER17> > _How do we reconcile it with another popular argument..._

I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :)

I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things.

Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros!

I've _never_ learned so much about programming as during my first ~6 months working together with people and learning their wisdom and tricks.

You're right that the restricted schedules are a downside.

<comment><USER18> I've literally never worked for any employer in any development role where spontaneous pairing or larger group collaborations didn't happen often. It's just human nature. I see others commenting in this very discussion with similar anecdotal experience, so apparently I'm not just completely weird in this respect.

I don't doubt that you can learn a great deal and obtain other benefits as a result of pair programming. I'm just questioning whether making it a formal, quasi-full-time arrangement is necessarily better than the ad-hoc version I see happening all the time for similar reasons and with similar benefits.

<comment><USER17> We may just mean different things by pairing.

Sure, people help each other in various ways in most places. But that's the solo programmer on a task asking someone else for help. Two people work on a something together, from start to finish, is a quite different thing

<comment><USER18> Just to be clear, I'm talking about two (or more) developers, gathering together to solve a problem collaboratively, with the end result that the code to do so is written or at least the significant questions have been answered and what remains is little more than a mechanical exercise. But I'm talking about that happening spontaneously, and not necessarily starting from a complete blank slate, being done on a specific schedule or according to any specific process or using any specific tools, or being required as formal policy.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Pair programming can be fantastic in short burst. The other day me and a coworker were working through a difficult solution and having another set of eyes was needed.

Maybe its just because I get along with my coworkers, but when working on something difficult we naturally collaborate and end up in an unofficial "pair programming session"

<comment><USER20> Over the last few years I've come to this exact realization as well. I used to think about it as a couple devs sharing a keyboard for interminable stretches and it made my skin crawl. Watching someone "drive" fumbling for buttons in the IDE and not using shortcuts makes me want to shoulder them out of the way and take over.

However, for short bursts (10minutes to max about 90) that are focused on a particular goal makes me feel both re-invigorated and more satisfied with the completeness of the ideas.

The re-invigoratation (for me) comes from not having to run my brain at 100% for the duration. In auto racing terms, my partner and I can take turns drafting off each other's thoughts, increasing our mental efficiency.

When differences arise I love hearing their thoughts and finding ways to merge the best of both ideas- or completely tossing my own because theirs are better. I've heard it (no clue where or from whom) described as idea sex. I'm very okay with my ideas being promiscuous and having lots of better little idea babies.

I still haven't figured out how to keep my skin from crawling watching people fumble around their UIs though...

<comment><USER21> I have worked in 100% pair programming environments for 5 years now, across 2 different employers. I feel like what you've just discribed is a good example of the beniefts of pair programming along with the downsides of not doing it all the time.

Your skin crawling while your pair is fumbling for buttons in the IDE is likely displayed by you physically as well, maybe holding your breath or twitching your hands towards the keyboard, your pair is probably then also thinking "what are they thinking but not saying, have I just done something really stupid" which leaves everybody feeling very uncomfortable, and is unproductive. However if people are comfortable with each other and importantly, open to being shown something new, the whole situation is fixed with a simple "hey, did you know there is a shortcut for that". Over the weeks simple interactions like that add up to mean the whole team is using all of the keyboard shortcuts. The same is true of software patterns and useful library functions, they spread like gossip in the group because everyone is excited to show the next person.

I totally understand that pair programming isn't for everybody in fact I think it is only for a specific type of person and group. Pair programming only works in groups where each member has high levels of empathy and trust is high within the group. Everybody on this thread that turned down pair programming jobs because they thought it sounded awful were definitely right to do so. But for some it can be an extreamly productive and fun way of working and learning at the same time.

</comment></comment></comment><comment><USER8> My experience pair programming:

\- Pair programming works better remotely than people say, in my experience.

\- It is a great way to share unwritten/unspoken information and best practices.

\- PP is excellent for team cohesion and allowing engineers to get to know each other and their strengths.

\- Not every engineering problem warrants PP.

\- Some problems are better solved by one person as it can take too much time to get the other person up to speed with the issue.

\- Pair programming often leads to better code, but you have to balance that with the overall reduced amount of work being done at once. If two people are working on one issue, you have to balance the benefit of that versus two people working on two problems.

\- I'm more effective when I can focus, and sometimes I need to spend an hour deep-thinking about a subject and perhaps pseudocoding something. Pair programming with someone remotely and having long periods of silence would be... weird.

\- People seem to view PP as a measure of success. The more a team is pairing, the more success being experienced. Right?

\- If someone isn't into pair programming often, that's seen as a negative.

\- 95% of people who pair remotely need better microphones or accoustic environments. I wish remote companies would ship their employees a pair of AirPods, a Yeti mic, and some acoustic foam squares.

\- Pairing is more consistently useful for reviewing large code changes where it can be difficult for a reviewer to reason about the work that was done. Going through it with the author and doing a screen share can make all the difference.

My conclusion is that pair programming can be good for some things, but I would consider it a red flag if a company highly emphasizes pair programming or coerces people to do it. Treating pair programming like a panacea dismisses the fact that people of different personality types have been writing perfectly good software without pairing since time immemorial, and that there are other ways to improve code and product quality. What I think can be nearly as effective as pair programming is getting code reviewed early and often. I'm not the best at this yet, but I've noticed that life is just better when I don't do a ton of work and wait for it to be reviewed when it's "done".

</comment><comment><USER22> There is a construction site in front of my office. When I walk close by, I always see a guy working and another one standing next to him apparently checking if he is doing correctly the job. Wondering if this is the equivalent of pair programming in the construction industry.

Anyway, I've done some pair programming when I was younger, and I like helping some new folks with a 1-hour pair programming sometimes, but I don't think I could stand having someone pairing with me all day. Furthermore, there are other ways to keep code quality high (code reviews, tests and so on).

</comment><comment><USER23> I imagine this could be chain-gang hell for introverts.

I've always wondered if the people who move into decision-making spots are extroverts, who then go on to make decisions affecting introverts, like open- plan seating.

<comment><USER24> It definitely is. What happened is software paid so well that people who can talk more than think, which is the vast majority of people, crowded it out.

<comment><USER25> I've also noticed this. It became so bad in my current company we have teams which consist of:

1 Manager 1 Scrum Master 1 Team Leader 2 Regulars 1 Expert

TL;DR Experts quit max after one year and teams are left with 3 regulars dying inside to keep stuff working.

ps. When mentioned that we have too many middle managers - instant push back - coz they all cover each other, fearing someone will fire them if not. Worst part is those people have zero technical knowledge and make stupid decisions based on things they have seen on PowerPoint presentation. Last such a stupid idea was to move our platform from stable AWS environment to crappy/buggy Azure ecosystem. (simply because one of managers most likely got paid under the desk to push company into this direction). After losing over 1Million Euro on Azure we scrapped this idea..

</comment></comment></comment><comment><USER26> Like a lot of discussions of programmer productivity, it's hard to measure, so nobody bothers and we talk around the issue without any hard numbers.

<comment><USER27> I'm pretty sure it's not that nobody bothers, it's just that there is well over a decade of research and literature strongly suggesting that it's either (a) impossible to do this kind of direct productivity measurement accurately, or (b) gives the wrong idea, creating wrong incentives that generally fail to improve outcomes (or worse, that the measuring directly hinders many positive outcomes.)

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

Outcomes are hard to measure, so we measure productivity instead. At least that's how it goes in my organization (and it does not turn out well, as suggested by the literature.)

Edit: but we are for the most part not developing software as our core competency in this company, so it turns out that fixing this is a pretty low priority...

</comment></comment><comment><USER28> In my experience some people use "pair programming" to hide their insecurity and incompetence.

<comment><USER29> Absolutely true. In my experience, some people use "bashing pair programming" to hide their insecurity and incompetence.

</comment></comment><comment><USER30> I think PP is great; however, I do not like to use it as an educational practice. Why boils down to two ideas - a) you are not hired in teams, so you cannot rely on classmates; and b) we've made students so scared to help each through fear of academic integrity and copyright violations that we had to create a special activity centered around looking at someone else's code.

The first idea is rather obvious - the teams you build while learning may be enjoyable but that does not directly translate to hireability. PP Exercises are still scored primarily through correctness over contribution, so a slacking student can do less and potentially learn less without fear of too much penalty to their course grade.

The second idea is more an opinion about the state of CS ed. In an English class, if I wrote something that wasn't good, I could rely on peers to help. If I need help on my weight lifting form, I can show my form to others for advice. In CS, how dare you show your code to anyone because Copy and Paste are so easily done. I've literally had students swear off StackOverflow and helping peers for fear of being labelled a cheater. PP to me seems like its trying to solve that fear rather than deal with the cause of the fear.

</comment><comment><USER31> Being forced to pair program all the time blows (IMHO). It's just too rigid. I was recently paired with another guy way below my ability. Great for him, not so great for me. PP is amazing when you and a co-worker decide to pair because it's the perfect approach for a problem you're trying to solve, or because one of you needs help figuring something out.

<comment><USER15> You are doing it wrong. You need to drop to his level in order for harmony to exist. He can't just jump to yours.

Better yet tell him to just stay home and get the job done right.

</comment></comment><comment><USER32> I'm seeing an error when I try to view the site that looks like this:

"Trouble Encountered [https://c2.com/wiki/remodel/pages/PairProgrammingEconomics](https://c2.com/wiki/remodel/pages/PairProgrammingEconomics) can't fetch document

See github"

I'm guessing the site is overwhelmed with more traffic than it can handle.

</comment><comment><USER33> This sentence from the blog is key, "Caveat: Pair programming is a learned skill. It takes time and work to do it well."

Pair programming sounds great and all but if even one person from the "pair" is not good at it, everything falls apart. Also, the pair's chemistry has to be on point like Jeff Dean and Sanjay from Google :p

</comment><comment><USER34> Pair Programming is a complete crock of shit. If you hire someone to do a job, either they can do their job, or they cannot. If you cannot trust someone to perform and deliver work up to a certain standard, do not hire them. Is there any other industry where you hire two people to do one job?!

Now there are certainly times when it is very valuable to do collaborate, such as rubber duck debugging [https://en.wikipedia.org/wiki/Rubber_duck_debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging) or mentoring or simply doing a 'desk check'. But these are the exceptions, not the rule. Having someone breathing down your neck or be a back seat driver all day is at best a waste of productivity, forcing the driver to think at the pace of the observer, and at worst, a complete waste of time and effort.

</comment><comment><USER12> I'm one of the right people, I love pairing and have been doing it for a decade full time. That being said, I'm also very much aware 80% of developers will never want to do it, and that's okay. Even though it's a skill to learn, and I'd guess a good many of those 80% would come to enjoy it with more practice, it's ok to not like it.

Even if it was scientifically the fastest and best way to program (engineer productivity is unmeasurable so we'll never know) there's still a huge number of developers who will hate it for a number of reasons. They are all valid and no one should be forced to do things they hate if they can add similar value some other way.

</comment><comment><USER35> My experience pair (and mob) programming for the past months has been very positive, both with in loco and remote peers (sometimes mixed). New hires feel they get a lot of context faster, and experienced peers feel it improves quality, as it forces code to be understandable.

I believe it's instrumental that the entire team is at peace w/ some working agreements to make it work:

\- Splitting work between pilot/guide(s) (otherwise, it turns into a monologue)

\- Rotating roles often

\- No pressure to stay or having to leave for a while

\- Have adequate installations (quiet space, standup desks, large screens, 40"\+ displays if possible, ambient sound for remotes to join in the session)

\- Naturally leads to egoless programming

</comment><comment><USER36> The economics of pair programming is twice the price for half the productivity.

<comment> house9-2 It depends on how you measure 'productivity' I guess.

<comment><USER15> You know things like finishing work.

Pair programming is about the relationship first. Code second. Overall system quality last.

</comment></comment></comment><comment><USER37> Through a lot of experimentation I found that pair programming _can_ help in many cases: onboarding, code reviews, design & architecture and others ([https://www.togetherwecode.com/articles/seven-ways- explore-p...](https://www.togetherwecode.com/articles/seven-ways-explore- power-pair-programming/)).

It doesn't always work for me, but I found that it offers a surprising amount of benefits.

</comment><comment><USER38> Many previous threads going back 12 years, for the curious:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=comments%3E3%20%22Pair%20Programming%22&sort=byDate&type=story&storyText=none)

</comment><comment><USER39> This is a wiki that only serves user-agents that are capable of executing JavaScript. Weird.

<comment><USER40> What's worse is that it didn't used to. The current version is a rewrite, based on a wiki-interop framework (developed by the original wiki's creator, so it's not a hostile takeover, but rather an attempt to do stuff that wasn't possible originally).

</comment></comment><comment><USER41> For those who don't see the value in pair coding, there is an alternative with less overhead - code review.

Just emphasize to everybody to keep it friendly, and make an effort to +1 ASAP every time.

</comment><comment><USER42> What is that website by the way? There is a lot of good content on it but it's quite unusual. It's becoming a go-to of mine

<comment><USER43> It's the first wiki. Made by Ward Cunningham who was one the original agile people.

</comment></comment><comment><USER44> In pairs:

\- 2 seniors tackle hard problems

\- 1 senior and 1 junior is good for teaching the junior

\- 2 juniors together is a recipe for disaster.

</comment><comment><USER45> > The underlying assumption is actually, For any two programmers, no matter > how good he or she is, if we get them to sit together, the value of their > work will be greater than if they sit apart.

Yes, an ASSUMPTION. Not proven. Not studied. An assumption.

> There's an implicit assumption there that all bugs take the same amount of > time to fix.

No there isn't.

> Now, I'm about to make a crucial assumption: that Alice and Bob's "difficult > tasks" are disjoint, such that what's difficult for Alice is not necessarily > difficult for Bob and vice-versa.

... Followed by some anecdata to validate the assumption, followed by "calculations" using hand-wavey numbers.

The rest of the article is similarly filled with hand waving, assumptions, strawmen, and outright fabrications. If you have a valid point, use valid reasoning to argue it.

<comment><USER46> While it's easy to through around words like anecdata and poke at this article for not having hard data, I simply don't think you'll be satisfied because measuring productivity and value delivered are incredibly hard to quantify. I think this article is wholly reasonable in it's approach as attempting to show with some back-of-the-envelope math and some hand wavy explanation that it is, in fact, possible for the economics of pair programming to work. Having another person try and explain the many complicating factors is exactly what I need someone to have if I want to convince my organization that it is perfectly reasonable to try and no you're productivity won't be cut in half.

I did pair programming at two different companies full-time, one was over 200 people and that was one of the most productive companies I've ever worked at, hands down. That is also highly anecdotal, but I know it's true because I did it for 5 years and also have seen what it looks like without it for at least as many. It doesn't work for everyone. Some organizations just attract better people and that is a confounding factor. Remote pairing is hard. All these things are true, but if I want to try it at my next company, as I'm doing right now, I need articles like this to prove I'm not crazy, and yes, it's worth trying if you have problems with communication, or want to train young developers, or learn something new, or reduce bug rework from poor code reviews. It's a very useful method of developing software and I'm happy this guy made an attempt to quantify it, however poorly, because software is just a hard thing to quantify.

</comment></comment><comment><USER47> My experience with pair programming in ML modeling:

\- ML involves making lot of assumptions. That created some fatigue in me, and it helped to have someone giving out their thoughts actively. Even when not aligned on a common view point, simply going by one's approach first based on ease-of-implementation sounds practical. we could try other ideas always right..

\- Creating bugs became more apparent. i.e., every software bug is someone's creation, and pair programmer would actively think about what's going on, makes the code less buggy

\- Software architectures and designs are easy to justify at the end, because you've one more already on board, at least to some extent. If the person isn't aligned with the other's thinking, its very easy to pin point the item. Usual management style is, someone with different eyes (managers, tech leads) review once its gotten to some place.

\- What was mild inconvenience was: my pair programmer was Vim guy, I'd like sublime text. Our style of thinking was also different. It made few things better, but ultimately you are asking someone to push their approach onto you. Some adjustment needed.. but okay. I'd prefer reading papers in depth before finding a common theme to implement, they'd prefer jumping into code, and then tweaking and hacking. My motivation/internal agenda is to write novel work, they'd want to simply get best numbers out. Aligning on something at this high level I thought has pros and cons..

\- Overall, pair programming really helped me see myself. Its like getting active feedback, but not in the formal feedbacks designed in companies. If both like to some extent doing it together, its a good way to grow as a person and engineer.

\- In workplaces there persons would not say I don't like pair programming with this person, unless do/die situation, at least in small companies. This pushes everyone to learn some people skills to see how things are going on.. I felt some discomfort at this aspect, but okay.

\- I always had some insecurity about whether I am good enough for my goals or current project. I admired how many things are done by my pair programmer, and that made me feel whether they like working with me. It was always running on the back of my head. I think this dragged my personal contributions..

I'd always suggest someone try pair programming, see how it goes.</comment>