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?
Mob Programming – The Good, the Bad and the Great
71–80 of 98 posts
Re: Mob Programming – The Good, the Bad and the Great
#72Similar 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…
"dojo"?
Re: Mob Programming – The Good, the Bad and the Great
#73I 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.
Re: Mob Programming – The Good, the Bad and the Great
#74I'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 thi…
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.)
Re: Mob Programming – The Good, the Bad and the Great
#75Earlier quoted context omitted.
(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.
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.
Or just plug in several usb keyboards and mice into one computer so everyone can type without switching chairs or handing the keyboard over.
Re: Mob Programming – The Good, the Bad and the Great
#76FWIW, I'm getting:
uBlock Origin has prevented the following page from loading:
http://underthehood.meltwater.com/blog/2016/06/01/mob-progra...
Because of the following filter
||meltwater.com^
Re: Mob Programming – The Good, the Bad and the Great
#77This 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 anyt…
>>This is an introvert's nightmare. I feel like going to a room and turning off all the lights just reading about this.
Wow! That sounds more like social anxiety disorder than introversion.
http://www.webmd.com/anxiety-panic/guide/mental-health-socia...
Re: Mob Programming – The Good, the Bad and the Great
#78> 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…
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.
Re: Mob Programming – The Good, the Bad and the Great
#79"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 performan…
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'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.
Re: Mob Programming – The Good, the Bad and the Great
#80I 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 wal…
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.