|
That's correct. I have done a fair bit around this already.
This space for rent
|
|
|
|
|
C-P-User-3 wrote: If there's a better place here on CodeProject to ask this question, point me.
The Quick Answers[^]? 
I'll go get my coat
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
There are plenty of articles here on CP on that subject, two of the most eminent ones are to be seen here[^] and here[^].
The first one is a bit old, but explains the principle quite well, the second one uses what seems to be the most common library at the moment.
|
|
|
|
|
|
|
A colleague has just attended a conference for open source .net and was speaking to some people who have gone beyond pair-programming to mob-programming. They have 2 60" screens, 2 devs, the project owner and a designer all working as a team with one person driving the keyboard.
The company seems to feel that the ROI makes the process worthwhile.
Not sure this would be for me; I don't like rigid pair-programming but am OK with opportunistic-pairing where it makes sense to solve a specific problem on a short term basis.
Anyone tried mob-programming? How did it work out?
|
|
|
|
|
R. Giskard Reventlov wrote: Anyone tried mob-programming? How did it work out?
Work out?, you seriously expect it to work out?
|
|
|
|
|
It's like in Warhammer when the Orcs drive a battle wagon. You need at least three, two younger ones and an older, more experienced one. The older one drives while the other two fight over who gets to drive.
And red ones always are fasta.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I'd be bored rigid.
Watching someone else type is one of the most tedious jobs on the planet.
I guess it would get entertaining when the 1TB fan types and the K&R devotee tries to tell him what he's doing wrong, and as for Mr var meeting the Hungarian namer I would have to bring popcorn. And bandages, obviously - but mostly popcorn.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
I always lose my patience and snatch the keyboard. Can't bear to watch one fingered typists at work...
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
I do not even touch the keyboard if someone stands behind me quietly... No way of pair (or mob!) programming with me...
Do you want to exchange ideas - write it down or invite me to meeting...
Do you want to do some code review/improvements to my code - you are welcome by all means...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Back in high school, when using a Commodore PET at a friends house, we would take turns working on code, but not exactly 'pair' programming or 'mob'.
One of us would start writing code for 15 minutes or so, then walk away.
The next person would have to come in, read what was written, and proceed.
After 15 minutes or so, swap out again.
There was never any dialogue, no discussion as to what was planned... just try to figure out based on what you were doing, did they understand and continue building or do you have to move forward with their design as best you can...
The results were amusing.
|
|
|
|
|
Yeah I remember those days....
The ones before porn on the internet.
|
|
|
|
|
F-ES Sitecore wrote: The ones before porn on the internet.
FTFY 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
When teaching programming at college level, I once in a last-year course tried organize the practical exercises, which was a farily big semester-length group project, in four stages. At the end of each of the three first stages, the results so far would be rotated among the groups, so that each group would take over that which was done by another group.
The idea was to let the students experience taking over someone else's work, which is very common when you get job as a programmer, but not during your study years. Second, and equally important: You can't keep secret what you do. It is not just an internal secret between you and your professor (or boss, when you get a job); your colleagues will see your code, and will judge you by how you have done your work. Get used to it!
Nice ideas don't always work out in practice. The students hated me for this setup! I forced them to reveal their innermost programming secrets, and to take over this horrible code from someone else, which was so useless that it would be much better to replace it all with the high quality stuff they had produced themselves in the previous stage. (They ALL though so...) They did NOT thank me for letting them try out a real-life-like work situation while still in school.
|
|
|
|
|
Well, real life isn't exactly like that. At least, not in my experience.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I can understand if you're mocking a UI up, or tweaking a workflow, or working through something like a database schema. You have all those invested sit in a room, you slap together some models, mockups, some diagrams or whatever and talk through the use cases and design until everyone's good to go.
But then everyone leaves so the dev can actually get the work done.
cheers
Chris Maunder
|
|
|
|
|
|
Is it a bad sign when the devs are the first to run out the door?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
|
Sounds like the typical development shop - 1/2 written specs, lets get coding!
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
charlieg wrote: 1/2 written specs
I like your optimism!
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
It sounds like a golfer, his caddy, and a couple of commentators... 
Caddy: I think this calls for a foreach loop.
Golfer: Not for something this critical; hand me the for loop.
Commentator 1: Interesting choice there, Bob, what do you think?
Commentator 2: Well, Bob, he's had good success with the for loop before and he tends to shank the foreach, so this should be a good call.
|
|
|
|
|
If they, in dead earnest, argue in a mob which loop construction to use, then it is completely crazy.
I have had much more fruitful mob work in the early design phases, when data structures and breakup into subsystems and functional modules are discussed.
Obviously, that is a remenant of the riverfall model, from the ages when you tried to identify and describe the problem before you started programming. Today that is old-fashioned - the agile way is like "Ok, so you have a problem that can be solved by a program? Let's start with "int main(argc, argv) {return 0;}" ... Now that is in place! The next to do is for you to tell me about your program, and I will fill in code between the braces as you explain your problem to me...". In that style of work, there is not much room for mob data design or mob modularisation.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
