|
For a field with such a reputation for solitary, antisocial tendencies, we sure are starting to rely on one another. "Me and you And you and me"
|
|
|
|
|
I tried pair programming many, may years ago. Didn't take long before we were at each other's throats - it is something I will never do again and having seen it happen the same way with other people, I would never recommend it. It only seems to work where you have a dominant/submissive pair.
|
|
|
|
|
I have only found this to be effective in particular circumstances - bug finding and fixing, usually of something old or convoluted.
This is because four eyes are better than one.
It doesn't work for green field development because all necessary design decisions should have been made before coding and thus it just becomes an exercise in minor coding-style conflict resolution which impairs the ability to think clearly.
Of course - segregated pair development (where one person writes the (TDD?) unit tests for the other's code and vice versa) is a different matter.
|
|
|
|
|
Almost like 2 people trying to drive the same car, sooner or later it will...
|
|
|
|
|
It was called "extreme programming" 15 years ago. My experience is that it doesn't really work for new code, but it's great for debugging.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Pair programming?
Is that like when one person does all the work while the other flips around on a smart phone all day? I think that is an industry wide standard now... although it is not always done at the same desk.
Actually, I hate pair programming, it is a very irritating situation of either trying to work while being badgered the whole time, or trying to give input while being ignored the whole time.
Now mentoring... that I enjoy (from either point of view).
|
|
|
|
|
Pair programming and mentoring work really well when there is a specific and obtainable goal, whether it's helping to debug some code, walk through an implementation to teach how something is done, or simply code review.
If you don't state the goal of the PP session up-front, then it's usually a waste of time, as one person ends up watching the other (the dominant/submissive pattern mentioned above.)
Often enough, I end up doing pair programming remotely, which I've found works quite well, and possibly even better than side-by-side PP. The reason being, PP works best when there's a "breathing" motion to it -- for example, when debugging, we may diverge in figuring out why the bug is happening and then converge on the solution. It's a lot easier to do remotely because in addition to the shared screen, we can individually explore different paths as well, whether it's looking at different code, inspecting the database, googling for alternative implementations, drawing out some architecture.
So, the key, in my opinion, to good PP is to avoid the monolithic "let's look at what this is doing together" but rather, "you look at this while I look at that" which brings more information to the problem at hand while simultaneously dialoging about one's findings. I find that to be a very effective and efficient approach.
Marc
|
|
|
|
|
Pair-programming works great, for most people, for short periods of time with focused goals.
Some teams may flourish using the paired approach full-time. I think this would be the exception to the rule.
My #1 rule, there is no silver bullet approach.
Red flags are triggered in my mind when I am in a discussion or read an article where someone makes an absolute statement about a process being the key to success in programming.
On the other hand, mentoring is not a process to create better code quality. It is a training process to train developers in the craft of programming. The quality of your mentor will determine the overall effect the mentoring has on the improvement of that developer.
Here's a key to superior code quality: Write code without mistakes
|
|
|
|
|
ORM is a terrible anti-pattern that violates all principles of object-oriented programming, tearing objects apart and turning them into dumb and passive data bags. "There are as many opinions as there are experts."
|
|
|
|
|
Kent Sharkey wrote: ORM is a terrible anti-pattern that violates all principles of object-oriented programming,
There are numerous, far better ways to solve the problem they were trying to solve with ORM.
Like Flying Cars
Just like flying cars. Oh, when will we get the flying cars?
Flying cars are a terrible idea. Why? Because people would be driving them and people are dangerous enough in 2 dimensions, let alone 3.
Your Reply, Before You Actually Reply
I already know the replies to this: oh, no, we will have computer systems that will pilot the flying cars. Yes, yes. The future is all chrome. I saw it all in the 50s movies.
Let's all just forget about two things:
1. ORMs
2. Flying cars
|
|
|
|
|
Re Flying Cars... I want a flying car, I don't want you to have a flying car. 
|
|
|
|
|
That's funny. you are exactly right about that.
PIEBALDconsult wrote: I want a flying car, I don't want you to have a flying car
|
|
|
|
|
Unfortunately there are many more opinions than experts.
Quote: the entire idea behind ORM is wrong
Yes, yes it is. But "solution providers" need to sell a "problem" in order to sell their product. No problem -- no sales.
Quote: more than 10 years already
Ergo, before generics. Generics are a much better "solution" to this particular non-problem.
I also agree with...
Luca Cavagnoli: SQL-speaking objects is a terrible anti-pattern that violates all principles of object-oriented programming
Indeed. Another particular anti-pattern I hear is "an object should be able to persist itself" -- no, an object should absolutely not
know how, where, when, or whether it is stored; that leads to tight coupling. If it can save itself to SQL Server, can it also save itself to Oracle, MySQL, or XML? Or are those options no longer achievable without a whole ton of refactoring?
|
|
|
|
|
I agree - you need a shearing layer between the data and the business logic.
|
|
|
|
|
The article doesn't address the difference between full-blown wieldy ORMs such as Hibernate or EF, and newer micro-ORMs such as Massive, Dapper or PetaPOCO.
The micro-ORMs remove much of the session management skullduggery whilst retaining the object hydration that removes so much boilerplate code, but are (often) limited to hydrating anonymous types.
However, if you introduce a codegen layer into your build process to generate concrete classes which map the database objects, that issue goes away and you're left with (IMHO) the best compromise : a fast layer that removes the drudgery & maintenance headache of hydrating objects, whose objects don't 'speak sql' (yuk!), but don't have the overhead of the session management of larger ORMs.
We use Dapper and a few Codesmith templates; does a good job.
|
|
|
|
|
While I totally agree with the subject line, I find that the article misses the mark except for pointing out that ORM's turn objects "into dumb and passive data bags". Unfortunately, his alternative approach is actually worse. 
Marc
|
|
|
|
|
That was my impression too - the solution is worse than the problem.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
If it's any consolation, I hit up-vote ten times.
|
|
|
|
|
Systems administrators are urged to install critical patches that address remote code execution flaws in NTP. "The time is gone, the song is over, thought I'd something more to say"
|
|
|
|
|
Microsoft shipped the first version of Windows on November 20, 1985. The company went public on March 13, 1986. That means that Microsoft pulled the trigger on its IPO mere months after Windows was first launched into the market. "It is too early in the life of Microsoft Windows to determine what level of acceptance it will attain in the marketplace."
|
|
|
|
|
Dang! They should have said "apps"! 
|
|
|
|
|
For software infrastructure, it's a big deal. Applications? Not so much. "Talk is cheap. Show me the code."
|
|
|
|
|
CES will include demo of TI's approach to using harvested power. "The Matrix is a computer-generated dream world built to keep us under control in order to change a human being into a battery"
|
|
|
|
|
Is Java a good choice for teaching kids? Doesn't that count as abuse?
|
|
|
|
|
In the same way that Facebook helped the enterprise connect their employees, ephemeral software also points to trends that can boost software in the enterprise space.
Disappearing messages and secretive, morally ambiguous executives? No brainer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
