moss

Thanks for this -- I can't speak for the person you're responding to, but I had the same confusion and it was definitely because I was thinking of Cringely.

I'll often use sequence diagrams or entity relationship diagrams when I need to explain how a piece of code works (or even just visualize it for myself). I don't tend to be very pedantically correct about it, but having a picture makes it a lot easier to follow how different pieces fit together. I generally leave out a lot of the less important details when doing this.

I wouldn't generally use it to design code that hadn't been written yet. There's a lot you only discover once you get something working, and that needs to inform the design.

All the time. Many times per day. I've been programming for fifteen years, and I think my willingness to Google things has only gone up over that time. There are a lot more things that I know off the top of my head now than when I started, but I've got way less tolerance for wasting time trying to figure out weird problems when there's already an answer online.

This article is from a year ago and change. Have there been any recent developments? I've seen the link going around lately, but I can't tell whether it's because there's news or just because it happens to be going around again.

Having lived through this winter in the Northeast, I can promise you that SF is beautifully warm all year round. Case in point: it is a place where people use the word "freezing" to describe temperatures 10-20 degrees above the melting point of water.

::cries::

There are so many things to love about this speech, but I think my favorite part is this: "the only thing that actually works is not ideological, it is impure, has elements of both arguments and never actually achieves any kind of partisan or philosophical perfection."

That's an extremely cogent observation about capitalism, but it would be just as relevant in a discussion about FP and OO, or about team social dynamics. Across the board, I see people doing better work when they spend less time seeking philosophical consistency and purity, and more time responding to real observed situations.

Pairing with other experienced programmers works very well for me, and has made me more effective as a programmer. I've also seen our junior developers learn a lot from pairing with each other. In my working environment, with other people who enjoy that style of work, we think it's pretty great.

It obviously doesn't work well for you, so I strongly recommend not doing it.

Why is it so terrible that people are playing with interesting, creative, sometimes crazy new ideas, and sharing their results?

The article's link to the original paper doesn't seem to be working. Here it is: http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pd...

My understanding is that the Promiscuous Pairing idea was started by real developers working on a real project with tight deadlines. The point of the paper is that, counterintuitively, the approach worked very well _in practice_. So I wouldn't be so quick to dismiss it based on first principles.

That said, it certainly depends a lot on context. My team at work has tried full on switch-every-ninety-minutes Promiscuous Pairing a couple of times. Once, it worked really well: everyone started knowing the code much better; we got more done; we spent less time stuck and confused and more time producing quality software. Another time, it was a nightmare: everyone felt rushed and confused; it seemed like we were constantly being interrupted; we never felt like we were getting anything done.

I'm not entirely sure what made the difference. Our going explanation is that, the second time around, we had a higher baseline level of interruptions already, so the constant switching just added stress and made it impossible to focus. We haven't tried switching that aggressively since then (although we've been considering it lately, as the circumstances seem better for it--that's why it's on my mind right now). On the other hand, it's still rare for us to switch less than once a day, and that's been absolutely great.

You're proposing what sounds like a pretty novel interpretation of the first amendment. Do you have any evidence that it's widely accepted, or that it's correct?

To push the metaphor a bit too far, I think it's more about people realizing they just don't want cake that much.

As you say, it's perfectly possible to build a good community if you're willing to put some work into it. People who run community-oriented sites mostly know this by now.

But a lot of sites pick up communities accidentally. Blogs tend to have comments enabled by default. Adding a forum to a site sometimes seems like a simple idea that will make users happy. Social networking features seem like a must have for some kinds of web apps, even if they aren't the main focus. And of course, these accidental communities inevitably decay until the reek of them spreads through the whole site.

I think a lot of people are remembering that they didn't actually want to run communities in the first place. They added community features because it was the path of least resistance, and now that they've seen where it leads, they're turning them off rather than sinking a lot of effort into making them work.

I'm pretty happy with the development, personally. The communities I like are going to stick around, and as for the others, well, there are more than enough places to have flamewars already.

(Disclaimer: I turned off comments on my own blog a couple of months ago. It's made me a happier person, but I may be projecting just a bit.)

This is really slick! It's the first realtime, WYSIWYG tool I've used that still feels like a Wiki.

Consider saying this explicitly during the sign-up process! I avoided using my Google account to log in, but I probably would have gone ahead and done it if I'd known that you weren't going to email my contacts.

* There are memorable keyboard shortcuts for everything. * It can generate comparatively more code for you. * It's faster, though I fear it's working on losing this advantage. * The autocomplete is smarter, and has a few different options.

I started using IntelliJ a few years ago, when I came onto a Java project after several years using vim and Python, and I'm convinced it made the transition a lot less painful.

The difference between IntelliJ and Eclipse may be smaller than it feels to me now--IntelliJ is what I'm used to, after all, so using Eclipse involves adjusting to a subtly different interface--but I'd still say it's worth a try. There's a free version, so there's not really anything to lose.

Much of the time, I'd agree. But working on a large system in Java, I repeatedly see a few places where Java's boilerplate overwhelms the code I actually care about.

Operations on collections:

  List<String> result = new ArrayList<String>();
  for (String word : words) {
    result.add(word.toUpperCase());
  }
  return result;

Accessor methods:

  private String name;

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

And arithmetic on user-defined types:

  new Dollars(15).plus(new Dollars(25)).times(new Percentage(80))

This bulky, uninformative, junk code is a real barrier to readability, and these are just simple examples. Sure, it's possible to work around it, and to keep the badness contained, but it still means time wasted for anyone who needs to maintain it.

We started writing some code in Groovy on our large Java project at work a few months back, and it's been a revelation. Groovy feels like a bit of a hack in all kinds of ways, but we're still delighted with it, because being able to say:

  return words.collect { word -> word.toUpperCase() }

or:

  String name

or:

  (new Dollars(15) + new Dollars(25)) * new Percentage(80)

just makes it _so much easier_ to see what's going on at a glance. Maybe if I were on a different sort of project -- one where I spent less time maintaining old code, or working with collections of data -- reducing boilerplate would seem like less of a big deal. As it is, though, it has seriously improved my quality of life. If Xtend can bring that kind of improvement to more people, I'm all for it.

It's suitable, not suitible - normally I wouldn't be so pedantic, but in a thread around the idea of people having to prove they know meanings/spellings/etc, it seems apropriate.

The building I work in once had a contest: whichever floor recycled the most paper in a month got an ice cream party.

Tempting, but the system's only covered by end-to-end tests that take years to run. I'm afraid to change it!

This is delightful. What I'd really like to see now is one that could learn from people's reactions to it: pay attention to which of its tweets were retweeted or favorited and try to generate more like those.

I think I'm blithely misreading the article here, but I'm inclined to take it as advice about how to do TDD, rather than an argument against it. Specifically: if a class has lots of tests, this is a sign that the class is too complicated. Refactor until it is simple enough not to require as many tests (possibly by narrowing its interface, possibly by breaking it up into multiple classes, possibly by rethinking how it's implemented).

My favorite thing about this article is that it made me stop and think through why the bug would actually exist in so many browsers.

I can make sense of the IE bug: "" doesn't start with a protocol, like "http://, so it's not a full URL. It doesn't start with "/", so it's not relative to the server root. Therefore, it must be a relative URL, and the browser tries to download the image named "" in the same directory as the page.

But the Safari and Chrome problem baffles me. To have happened in Safari, Chrome, and Firefox, it must be a pretty straightforward mistake, but I just can't see it. Anyone else have guesses?

(Safari and Chrome admittedly use the same rendering engine, but still, Firefox doesn't.)

It sounds like your philosophy of testing is about what mine was a year ago. Since then, I think I've modified it in two big ways:

1) I've found that potential bugs, and design problems, are often easier to spot at a lower level. Because of this, I've started using more integration-y tests to build out my initial implementation, and more unit-y tests to fill out additional details.

2) I've found the GOOD use of mock objects: when I have a class that wants to expose its data by calling a method on a narrow, well-defined interface, rather than by providing it through a getter, I'm happy using a mock version of that interface.

I wouldn't advocate it as The One True Testing Dogma, but I thought I'd share it in case you find it useful.

If you clicked that link, you have not actually disabled your public profile.

Sane people do not always have sane exes.

What is the proposed benefit of publishing badly researched articles making weak arguments for both sides?

You're right: calling it "very easy" was overstating things to the point of absurdity. I do think Java's behavior has a big advantage in being easier to understand than the theory behind it is ("less than 10%"), but I had completely glossed over the "roughly half" point the first time I read this, and it really hurts my claim that Java's approach is trivial to understand.

That said, I stand by "not requiring that knowledge". Java's behavior is understandable without having to know about value and reference semantics. That doesn't mean it doesn't require any knowledge. Specifically, I think it requires two points: (1) Variables are just names, so reassigning a variable doesn't change anything else in the system; (2) When you call a method on an object, you might change that object.

In support of this: I've also been doing a lot of interviews recently. In my (admittedly limited) experience, the people who have had trouble with Java's parameter passing behavior are more experienced developers who've done a lot of work in other languages. Their confusion isn't from Java's behavior, it's the caution about pass-by-reference that they've brought over from C and C++. I don't really see junior people making this mistake. So I suspect having just a little knowledge of the value vs. reference issue makes Java harder to understand, by bringing up new and confusing possibilities.

But, like I said, my experience is limited. If you do see new developers being confused by this aspect of Java (or Python, Ruby, or other languages with similar semantics), I'd be interested to hear about it.

What iron_ball said, plus a share of "I agree so strongly that I almost want to just repeat everything you said".

Alternately, it could mean: "I was reading LiveJournal five minutes ago, and haven't quite finished switching over to the Hacker News house style." ;)

This.

Java sets up an environment where the parameter passing behavior just isn't surprising. If you've been programming in Java for a little while, it's very easy to have an intuitive feel for how parameters will act, without having to go back to theoretical principles.

Knowing about the theory behind pointers, pass-by-value, and pass-by-reference will still make you a better programmer. But Java's a stronger language for not requiring that knowledge.