Live data from Hacker News

Hackathon Be Gone

brianchang.info

131–140 of 143 posts

Re: Hackathon Be Gone

#131

>> Salesmanship is rewarded. The rewards are given strictly based on the presentation This is not a bad thing. I've won hackathons partly–but not strictly –because we had a team that could present well in front of judges and an audience. Public speaking, sales, and presenting to others is an important skill in business and entrepreneurship. The author would be wise to convey this to his students. A hacker who can bui…

"Public speaking, sales, and presenting to others is an important skill in business and entrepreneurship."

Not so much with writing software. Communicating with others yes, but not necessarily in a public setting.

Re: Hackathon Be Gone

#132
post #116
post #72

Earlier quoted context omitted.

I hear this is done already with the race thing, I've heard of the "check Hispanic" trick a while back to make it easier to get into collge.

To be fair the American racial categories seem pretty inane to my non-American eyes to begin with. I understand that there is a lot of cultural baggage to the various categories but I can't count how many times I've been genuinely surprised by Americans identifying as black or Latina/o. The most striking ones I think were Halle Berry and Obama -- it took me a while to process that their recognition was genuinely note…

I grew up in Europe and then moved to US. In US, at least in some context (college admissions for example), there is a thing called affirmative action. It seems in order to right a a wrong from the past, or to promote diversity they would sometimes have quotas on how many students from each background to pick. So depending just on race, one could have an easier or much harder way getting accepted. Therefore people would play that card in order to game the system.

Re: Hackathon Be Gone

#133
post #109
post #104

Earlier quoted context omitted.

In what way is it more important? I thought having stable maintaniable applications is pretty useful thing to try to achieve.

My empirical experience is that programmers err too much on the side of doing things right. Most code has a relatively short lifetime; a lot of code simply won't be maintained much, because the first version is used to test a business assumption that often turns out to be false. Stability and maintainability are useful, but rarely as useful as being fast to market.

I'm having trouble finding any numbers that suggest greenfield development is more common than maintenance development. My own experience is that most of my work is done on existing code bases, and I am more productive when the coders before me spent the extra time to make sure the code is adaptable to new situations.

Can you point to some empirical evidence to the contrary?

Edit: I had some more thoughts about this, specifically that there is a survivorship bias to legacy code. Not all projects survive, but when they do that code can live a long life of maintenance. If you are involved in the startup world, it may make more sense to get it done quick & dirty in order to get funding than to write "good" code. That might explain the disparity of our experiences.

Re: Hackathon Be Gone

#134
post #109

Earlier quoted context omitted.

My empirical experience is that programmers err too much on the side of doing things right. Most code has a relatively short lifetime; a lot of code simply won't be maintained much, because the first version is used to test a business assumption that often turns out to be false. Stability and maintainability are useful, but rarely as useful as being fast to market.

I'm having trouble finding any numbers that suggest greenfield development is more common than maintenance development. My own experience is that most of my work is done on existing code bases, and I am more productive when the coders before me spent the extra time to make sure the code is adaptable to new situations. Can you point to some empirical evidence to the contrary? Edit: I had some more thoughts about this,…

> My own experience is that most of my work is done on existing code bases, and I am more productive when the coders before me spent the extra time to make sure the code is adaptable to new situations.

My experience is that efforts by previous developers are often counterproductive (they designed for adaptability, but in the wrong direction), and certainly that designing for adaptability in general is less efficient than designing for specific adaptations for those specific adaptations (and therefore it's more efficient to defer work to the point where you know exactly which adaptations you want to make).

> Can you point to some empirical evidence to the contrary?

No - just my own experience (I was using empirical in a negative sense - contingent is perhaps closer to what I meant).

> Edit: I had some more thoughts about this, specifically that there is a survivorship bias to legacy code. Not all projects survive, but when they do that code can live a long life of maintenance. If you are involved in the startup world, it may make more sense to get it done quick & dirty in order to get funding than to write "good" code. That might explain the disparity of our experiences.

Indeed. My experience is that probably >50% of code dies before ever being used productively, and so any designing for maintenance before the code has been demonstrated to provide business value is premature.

Re: Hackathon Be Gone

#135

Earlier quoted context omitted.

Where do you advertise them? How do people find them?

We used journo-tech communities like Hacks/Hackers, college boards, company mailing lists (ie. the post design group), or directly in touch with influencers (ie. NYTimes technical evangelist).

I ask because I feel like I keep up pretty well with tech news, reading multiple news aggregators every day - and yet I am clearly not connected to whatever information channels people are using to promote hackathons, since I never hear about them. I have no idea whether I'd want to participate in them even if I did hear about them, but it makes me aware that there must be some avenues for tech news communication that I am totally missing out on.

Re: Hackathon Be Gone

#136

Earlier quoted context omitted.

Just exploit the identity-political zeitgeist that's overtaken universities lately: claim yourself genderqueer, non-binary presenting as male. With the right incantation, the organizers will fold like a house of cards, lest they suffer the blowback to excluding a "righteous" participant.

It actually turns out that cargo culting the language of social justice works about as well as the sovereign citizen idiots that cargo cult legal jargon -- both of these phenomena exist in a broad, clear social context and it's laughably obvious when someone who doesn't know what they're talking about, like you, attempts an "incantation" with the idea that it's magic words because they don't or can't understand what'…

I know what's up. That why I made the comment. It's more about what is said than the actual content of the statement itself.

If I did the above, and someone made a stink, I'd hit 'em with "Are you denying my lived experience?" and then reaffirm the validity of my self identity (which is what matters) over what I actually am to observers (which is immaterial and doesn't matter).

Re: Hackathon Be Gone

#137
post #97

Earlier quoted context omitted.

Just exploit the identity-political zeitgeist that's overtaken universities lately: claim yourself genderqueer, non-binary presenting as male. With the right incantation, the organizers will fold like a house of cards, lest they suffer the blowback to excluding a "righteous" participant.

I love collecting geek t-shirts. Once I asked for one but they said: - "Well, but they are for girls only." - "Do you have something against cross-dressing?" - "Nope. Sure, take one!"

Hacking the hackers

Re: Hackathon Be Gone

#138
post #124

Earlier quoted context omitted.

> So I read that your employees actually do have family (which makes the thing about staying late worse) I think you're being overly negative. Nobody is forcing anyone to go to these things. If you have other stuff to do, fine. If, like some people, you actually enjoy it, you can go. Maybe you even have an understanding husband/wife who understands that once in a while you might be out as late as 11:45pm

I agree that we shouldn't always be so quick to judge, but my sibling posters have a point. How about the company throws this "hackathon" during company time? That would demonstrate commitment towards whatever the event is supposed to achieve.

That's exactly what we did. We committed an entire week of company time to our hackathon. People can stay late if they so choose.

Many did not and made amazing things thanks to the commitment by KA to use company time.

Re: Hackathon Be Gone

#139
post #134

Earlier quoted context omitted.

I'm having trouble finding any numbers that suggest greenfield development is more common than maintenance development. My own experience is that most of my work is done on existing code bases, and I am more productive when the coders before me spent the extra time to make sure the code is adaptable to new situations. Can you point to some empirical evidence to the contrary? Edit: I had some more thoughts about this,…

> My own experience is that most of my work is done on existing code bases, and I am more productive when the coders before me spent the extra time to make sure the code is adaptable to new situations. My experience is that efforts by previous developers are often counterproductive (they designed for adaptability, but in the wrong direction), and certainly that designing for adaptability in general is less efficient…

If you find the efforts of previous developers counterproductive then they aren't doing it right. An over engineered application can be as bad as an under engineered one. It takes experience to know how to put the right amount of flexibility to code. YAGNI is a common enough principle.

Re: Hackathon Be Gone

#140
post #139
post #134

Earlier quoted context omitted.

> My own experience is that most of my work is done on existing code bases, and I am more productive when the coders before me spent the extra time to make sure the code is adaptable to new situations. My experience is that efforts by previous developers are often counterproductive (they designed for adaptability, but in the wrong direction), and certainly that designing for adaptability in general is less efficient…

If you find the efforts of previous developers counterproductive then they aren't doing it right. An over engineered application can be as bad as an under engineered one. It takes experience to know how to put the right amount of flexibility to code. YAGNI is a common enough principle.

I think the correct amount of flexibility is zero so overwhelmingly often that it's not even worth trying to figure out whether this time is one of the exceptions. YAGNI is indeed a common principle; I think hackathons are one good way to learn to apply it.
Post reply on HN