Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Old (github.com/raganwald)
83 points by raganwald on Jan 21, 2009 | hide | past | favorite | 18 comments


What makes me feel old is seeing people using github as a blog :/

I know this is off-topic, but isn't there a way to just link to the content? When I click on this, I can see a screen full of random bits and pieces which are completely irrelevant, then just at the bottom of the page, I can see one line of the post...

Guess I'm just getting old also...


Good question. There's probably a way to link directly to github's representation of the post, in which case you can read it in markdown syntax rather than look at the fancy formatting.

TBH, what I like about how much github sucks as a blogging platform is that it discourages words and encourages code. There is a "pages" feature that publishes things as HTML pages with templates using Jekyl, but that is a slippery slope. I know this doesn't solve your problem, but keeping it raw and nerdy encourages me to maintain a certain words-to-LOC ratio.

Sorry about that!


What if there was a "chrome"-less view for Markdown files? Just a quick Firebug mockup: http://skitch.com/defunkt/bb6p7

Btw, the raw is pretty readable: http://github.com/raganwald/homoiconic/raw/master/2009-01-21...


There's probably a way to link directly to github's representation of the post

I don't know about that, but there is a way to pre-scroll the page to the content, so that the top metadata blocks are hidden: Just add #readme to the URL, as such: http://github.com/raganwald/homoiconic/blob/master/2009-01-2...


There must be some reason that arrow keys and the space bar don't scroll on GitHub. It's probably not a very good one, though. This makes scrolling tedious for many users, including me.


It's a bug that snuck in this afternoon. We have a fix we'll deploy soon.


Great, thanks!


Though not the focus of the topic, I did catch this comment.

You catch more flies with honey than vinegar, an old saying that seems to be even more relevant in the age of the Internet.

Honestly, from my experience, the complete opposite is true of the internet. Though I guess the type of flies you are trying to catch does come into play, more of than not, you'll get a much stronger reaction from a more heated, confrontational approach than a mellow and reasonable one. Not that I endorse the "linkbait" approach, but hey, the word exists for a reason.


I suppose if your only goal was to get traffic then a confrontational approach might work - certainly enough blogs out there attempting to do such a thing. That's about it, though.


The voice that says “Putting several programmers in an open room where they can interrupt each other doesn’t work, we tried that at Bell Labs in 1973” is the voice of someone who cannot appreciate that circumstances have changed, and that if you change a bunch of other things at the same time, putting an entire team in a single room can be more productive than putting them in offices with doors that close.

What would make this work now if it wouldn't work then?


Good question. I have met some teams that insist on private offices, and some that get very good results with "project rooms," where everyone in the same room is working on the exact same project.

A lot of things have changed since 1973, but also don't forget that this straw-man argument is being made by someone with a sample size of one. Sometimes when people say "We tried such-and-such and it failed," they are not describing something that always or even usually failed, just that they failed when they tried it once.

Somebody else may have tried it in 1973 and gotten wonderful results. Who knows?


My sample size is also one. This isn't arguing against your main point, I just had to chime in, as it's one thing I've disliked about my company moving to an Agile methodology. I personally find it very distracting, but that may just be because we're doing "team rooms" wrong.


...on the exact same project.

I think this is the key. Are interrupts to one person also usually of relevance to another? Does the early knowledge of others' ideas, completions, and course corrections make up for the distractions? If so, a 'war room' arrangement may work.

On the other hand, mixing people on uncoupled projects, with different deliverables, whose interrupts are irrelevant to each other: distraction disaster.


If they took programmers from offices, and made them sit together in a room together all of a sudden, then you might just be measuring how upset programmers get when you make them move desks! You could probably get the same result in reverse and conclude that less communication hurt productivity.

You're changing more than one thing at once, so you can't guarantee a causal relationship between the result and the thing you intended to change.


Old and cranky: remember failures with a single 'fail' bit.

Old and wise: remember failures in context, with a mental model of what factors could change to make them a success.


...and that if you change a bunch of other things at the same time, putting an entire team in a single room can be more productive than putting them in offices with doors that close.

Could not disagree more.


Can someone provide a link to the reddit article he mentions at the end? I'd like to know what old, unfinished idea might still be useful.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: