331–340 of 502 posts
We're a regulated bitcoin/ether(/others) exchange in Hong Kong, with many projects in our backlog! We're looking for engineers in 3 positions: a) Devs b) Ops c) DevOps d) Security (+DevOps)
We use Linux&Windows systems. Get in contact to know more at knocte@gmail.com
Plethora | San Francisco, CA | Full-time | ONSITE At Plethora we're building a fully automated CNC milling service so engineers can prototype precision aluminum parts in days, not weeks. We believe in a world of abundance where everyone has access to the powers of creation, for everything from new product development, prototyping, and rapid manufacturing, to scientific experiments, maker projects, and artistic works.…
I sent you an email last week. Are you hiring remote software engineers?
Earlier quoted context omitted.
Performing the task of weightlifting is incredibly different than performing the task of programming. Much evidence suggests that programmers perform better solo because they can more easily reach states of psychological flow, and because they are less inhibited by social interactions which modulate certain parts of our thinking and can inhibit creativity, etc. At the very least, this is more highly true of introvert…
> Performing the task of weightlifting is incredibly different than performing the task of programming. My point was that coaching is coaching. Fast feedback is more effective on great many learning tasks than slow feedback. It's why we obsess over closing loops. > At the very least, this is more highly true of introverted personality styles, and creating mandates for policies like pair programming is extremely insen…
That explains it. We're lucky this thread was merely about pair programming and not about the orders-of-magnitude worse phenomenon of Agile/Scrum.
Parse.ly - http://parse.ly - Fully Remote - Full-Time We are hiring a software engineer to work on our real-time analytics dashboard. Pythonistas and JavaScript hackers especially desired. On the company: We've built a real-time content measurement layer for the entire web. Our analytics platform helps digital storytellers at some of the web's best sites, such as Arstechnica, New Yorker, The Atlantic, The Next Web, a…
Earlier quoted context omitted.
> Performing the task of weightlifting is incredibly different than performing the task of programming. My point was that coaching is coaching. Fast feedback is more effective on great many learning tasks than slow feedback. It's why we obsess over closing loops. > At the very least, this is more highly true of introverted personality styles, and creating mandates for policies like pair programming is extremely insen…
> Pivotal Labs That explains it. We're lucky this thread was merely about pair programming and not about the orders-of-magnitude worse phenomenon of Agile/Scrum.
Though we might have some opinions about scrum in common.
Looking for work that can have a real positive impact? Our projects span software, hardware and geography in effort to increase access to resources that improve the human condition [1], [2], [3]. We're looking for software engineers with full stack knowledge to help us build our platform for sustainable development. You'll be joining an open-minded peer group of hackers and academics working in python, R, javascript, postgresql among other technologies. Experience with design is a plus. Potential for international travel.
Send resume to christian.natali@columbia.edu
[1] Our site: http://sel.columbia.edu
[2] Our solar irrigation work in Senegal: https://www.youtube.com/watch?v=Yjz8ox40YZM
[3] Mapping the grid in Nigeria: http://sel.columbia.edu/nigerian-utility-kedco-maps-10-milli...
Earlier quoted context omitted.
> Pivotal Labs That explains it. We're lucky this thread was merely about pair programming and not about the orders-of-magnitude worse phenomenon of Agile/Scrum.
Again, my experience has been different to yours. Though we might have some opinions about scrum in common.
"Scaling" does not refer to taking some large number and dividing it by 2 (120 engineers -> 60 pairs; 1200 engineers -> 600 pairs). That is emphatically not scaling.
Scaling is about leveraging the expertise of one of your most dramatically productive engineers by dispersing that person's help, wisdom, advice, etc., to more than one other person at a time.
Pairing doesn't scale precisely because the best person you have can only assist the exact same number of people that the worst person you have can also assist (namely, 1 in each case, since they are both part of a pair).
And, as Brooks noted long ago in The Mythical Man-Month, adding more people to a given task often just slows it down. Communication overhead tends to grow as O(n^2) or worse. So if you generalize a "pair" into a "triple" or a n-tuple, the process of pairing suddenly no longer helps and often dramatically hurts.
So when I say, "pairing doesn't scale," what I mean is that the best it can ever provide you is a 2x improvement in information transmission (and often it's far worse than that, and in all the cases I've seen it used first-hand it has actually been less than 1x).
I think it's a little disingenuous to just say, "Hey, we did it with 120 people! So it scales!" That's just not what scaling is about.
By way of comparison, one single, well-written quick-start guide can have almost an arbitrarily large improvement factor in terms of information transmission. You can hire one engineer who is good enough to write that document, and then send it to all of the other 119 engineers.
In my experience, even if that document is just so-so, it's still miles better than having to mentally context switch out of coding mode and into social conversation mode every few seconds to elicit the same info verbally out of a pairing partner sitting with me.
All positions ONSITE, 1 of the positions for INTERNS. Relocation assistance available.
We are a development shop that focuses on software craftsmanship. Our calling is to help companies create amazing, intuitive web applications, APIs, products, and services.
Pair programming, continuous integration & delivery, kaizen, and TDD/BDD aren't just ideas we pay lip service to, but core practices of our day-to-day work.
Open positions in Philadelphia:
- Senior Software Engineer
- Software Engineer
- Senior Front-end Engineer
- Sales Intern
- Senior Software Engineer
More info: http://www.promptworks.com/jobs/
Earlier quoted context omitted.
Again, my experience has been different to yours. Though we might have some opinions about scrum in common.
I also just wanted to clarify about scaling: taking some (semi-large) number like 120 and claiming this means "pairing does scale" seems totally wrong to me. "Scaling" does not refer to taking some large number and dividing it by 2 (120 engineers -> 60 pairs; 1200 engineers -> 600 pairs). That is emphatically not scaling. Scaling is about leveraging the expertise of one of your most dramatically productive engineers…
When I need to learn about a tool or system built by anyone else, the docs are the first place I look. If that doesn't help, I reach out for help.
> So if you generalize a "pair" into a "triple" or a n-tuple, the process of pairing suddenly no longer helps and often dramatically hurts.
Nothing about pairing changes the number of people in a project, or the number of potential pathways between them (some might argue that it halves the paths, but that would be twisting the meaning of pathways).
As I said above, we use pretty ordinary tactics to manage building large distributed systems, such as breaking them down into human-sized chunks of functionality that interact in limited ways.
If you like, I can ask about having you visit an office. It probably won't change your mind, but if you see something we don't, that's useful and valuable feedback.
Earlier quoted context omitted.
I also just wanted to clarify about scaling: taking some (semi-large) number like 120 and claiming this means "pairing does scale" seems totally wrong to me. "Scaling" does not refer to taking some large number and dividing it by 2 (120 engineers -> 60 pairs; 1200 engineers -> 600 pairs). That is emphatically not scaling. Scaling is about leveraging the expertise of one of your most dramatically productive engineers…
As I said further up, nothing about pairing precludes any other channel of communication. When I need to learn about a tool or system built by anyone else, the docs are the first place I look. If that doesn't help, I reach out for help. > So if you generalize a "pair" into a "triple" or a n-tuple, the process of pairing suddenly no longer helps and often dramatically hurts. Nothing about pairing changes the number of…
In pairing, a bi-directional pathway is established between Person A and Person B. This means that, during the activity of pairing, Person A's influence is exclusively dedicated to Person B, and vice versa. If everyone working solo is the baseline, meaning everyone only has the "1x influence" of their own work, then switching to pairing (if it works) increases this to 2x -- yourself and the pair partner.
In a traditional meeting where Person A is the speaker and there are N-1 audience members, Person A's influence is equally effective (ideally) across all N-1 unidirectional communication channels. If Person A is a really great engineer, from whom the other N-1 can all learn a lot, then leveraging just Person A at a factor of N-1 could be vastly more powerful than leveraging everyone but only at a factor of 2.
When you say things like:
> Nothing about pairing changes the number of people in a project, or the number of potential pathways between them (some might argue that it halves the paths, but that would be twisting the meaning of pathways).
it makes me think you misunderstood me, because I never claimed that pairing changes the number in a project or anything else.
However, you can't deny that in an environment where pairing is the expected modality for collaborative work, there truly is an emphasis on precisely the N=2 case, and other forms of communication necessarily have to be reduced to allow for pairing time and consistency in the act of pairing. It's not possible to do all other modes of communication and also pairing, because when you're pairing, you're necessarily not doing the other modes of communication.
My statements are about inherent limits to pairing. You can't extend the concept of pairing (based on 2 people) to triples, 4-tuples, and so on, without it leading to O(n^2) communication problems (e.g. if you tried to put 25 people together in one "mega pair-like group" it would be a big mess).
This is a bad property of pairing; exactly equivalent to saying that it does not scale.
I think the better way of phrasing it from my earlier remark was this:
When Person A is pairing with Person B, Person A is necessarily limited to only helping 1 person. If Person A is your best engineer, this is really bad. Telling Person A to stop doing pairing and to instead do all the same advice/Q&A tasks that would have been done during pairing and do them in some other way that scales (like user guides and SO) would immediately be better.
You can't have it both ways. At a certain moment in time when your best person is engaged in pairing, it necessarily means your best person is being wasted by having merely a 2x impact, instead of being pulled out of pairing and placed into some other activity that has a much higher factor of impact.
In real life, you'll never do any of these things perfectly, pairing or not pairing. But the point is that pairing is inherently not scalable, not even in principle.
It has nothing at all to do with whether your team also writes user guides or also answers questions on an internal SO site when they are not in the act of pairing. It's about the opportunity cost when they are in the act of pairing.