Hacker News Reader

Comment by stillworks | Hacker News Reader

Interesting to note how different people are indeed.

I am fine with white board type situations, don't worry about writing code without IDEs etc (in my very first job vi editor was the only thing we had to write code so I still have instinctive memory to be resourceful without an IDE but I love IntelliJ for most things). Happy to discuss/draw out ideas/solutions on whiteboards.

But find it very seriously annoying talking or being expected to talk while I am writing code !

I think the internet-access requirement depends on the problem. If I am expected to solve a problem by first-principles on a core CS topic then I guess internet is of no use ? Online Java Docs for e.g. may not serve a purpose here.

If the problem requires using many different tools/APIs for the solution then I guess you are right, internet access adds value.

View on HN

Indeed interesting how different people are.

Here, I'm like you. But it carries over to normal job - I work best when left alone. Especially when I have a tough problem to solve, just having people sitting close to me makes me frustrated, and if they're talking, then I won't be able to concentrate at all. It takes a lot of energy for me to be able to work in the presence of other people.

I understand where you are coming from...

I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. The consulting companies or body shops were happy since they could bill 2x the number of heads for the same amount of time. The "buy-side" of Pair Programming were happy because the KoolAid evidently worked.

Don't get me wrong, I am all in favor of getting my code eye-balled by anybody because I know I don't write perfect code 100% of the times and always open to critique and learning.

Here's a thought experiment. Have two teams A and B. A are pair programmers i.e. |A| = 2*|B|.

Now make team A don't do any unit testing, let them purely rely on pairing to ensure quality.

Enforce team B to do TDD to the best of their efforts.

I would be personally very interested in knowing where the consumer of the code and writers of the code have more confidence on code quality and functional completeness.

Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay.

I'd love to see that experiment, as I'm actually more inclined to believe in (occasional) pair programming (by the virtue of enforcing some focus) than in TDD.

> Open-plan offices are hip and in Europe maybe even a requirement due to space constraints but I'd personally choose a cubicle over higher pay.

Yeah. When I was still a high-schooler and later a university student, I used to laugh at cubicles. Oh, the corporate culture, oh, the rat race, etc. Now that I spent some time in this career, I would voluntarily go to cubicle and even take a pay cut. I now understand that cubicles were a good idea of solving the space/cost constraints.

Hell, every now and then I think about building my own cubicle out of pizza boxes, but I'm pretty sure the management wouldn't be happy about it. Over-the-ear headphones suffice for eliminating sound for now, but I still can't focus when I have people walking behind my back.

What works for one person doesn't work for everybody. I feel that it does work for me - it keeps me focused on the problem at hand without getting distracted, over-engineering the solution, or yak-shaving.

It's also interesting that the pair vs TDD divide is often based on the solution space.

Service/backend programmers often extol TDD because it is easy when working in a single language where your only IO is strings (i.e. Undergrad CS)

Front-end programmers may use TDD in certain established contexts, but pair may be more important when there are numerous integrations across unsupported toolchains. For example, when was the last time you used TDD with CSS? Oh? Too hard to verify that the CSS for a page makes it so that you can't click a button or print a page? Oh? Market bug isn't your responsibility?

Yeah, I see a lot of defensiveness when TDD is impossibly hard, so it's not "all that". But, use it if it makes sense. Know your tools and use the right tool for the job.

> I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid.

Not sure what you mean. In 25 years, my latest job is the only one that pair, and even then it's only a few teams in a very large organization.

I don't think your AB test makes much sense. The two practices are orthogonal. Complementary, but orthogonal.

If I had to take one over the other, I'd to TDD, or at least strive for excellent test coverage over pairing, but they really don't have anything to do with each other.

> Not sure what you mean

Try enlisting services of a consulting company such as ThoughtWorks, Accenture etc. Talk to the people who are already using such consultancies.

Every single job interview I have had this year involved a pair programming session and lists pair-programming as a "culture-fit" requirement.

The very latest one I had to go to, I had already warned the recruiter that that is not my strong point but he still sent me in anyways !

>But they really don't have anything to do with each other

I was trying to propose that maybe enforced pair programming is actually of no real value or very little value it at all and hence pair-programming has nothing to do with anything actually.

I value formal code-reviews. I have ZERO love for being forced into pair-programming be it in a real job or during an interview.

Somehow pair-programming caught on because KoolAid happens.

Pair programming neatly sidesteps a number of problems, when done well. For a team, it helps to spread knowledge among the team, encourages people to follow the team discipline, gives a second pair of eyes on any bugs and gets people up and running faster.

done well is the tricky bit. You need people who get on ok with it, social skills need to be developed, and you need discipline around not committing code which hasn't at least been reviewed. Social skills is the hardest part IME: knowing you can ask for a break, some time to think, or to split for some research before resuming work as a pair.

Some of that really depends on the problem and the language. I program Java full time, yet I'd be useless with vi. I lean heavily on the IDE. I've done this a long time and I firmly believe that I should use the best tools available, not just a text editor or a TEXTAREA, even with syntax highlighting.

Having suffered through a couple code interviews in Java, I now pick Python when allowed to pick a language. It seems like the language for me that allows me the best chance of coding effectively without an IDE.

I just did a phone screen yesterday that was extremely painful. After 45 minutes of fumbling around the thing mercifully ended and I googled for a few solutions. According to what I read on stack overflow, the problem is unsolvable with the constraints given. I expect to get the "no thanks" email from the recruiter soon and I plan on asking him what the proposed solution to the problem was - not out of spite, but because I'm genuinely curious. Maybe I misunderstood the problem statement.

Just out of curiosity, between Eclipse and Netbeans which IDE do you prefer for Java and why?

I prefer IntelliJ, with Eclipse a distant second (I know I'm not the comment author, but I spend 40+ hours a week slanging Java)

Hey, you can take the words out of my mouth. I like IntelliJ as well.

Reply on news.ycombinator.com