Hacker News Reader

Comment by marcus_holmes | Hacker News Reader

My love/hate thing with hackathons is how it gives non-coders the idea that you can put together a product in a weekend.

There's a vast difference between hackathon code designed to maybe last for an hour during a demo (with no security or privacy concerns) and production code that can actually support a business model. And it's not just "so... that'll take twice as long to make?". Turning a weekend hackathon demo into an actual production code base can take weeks or months.

But explaining that to a non-coder is really difficult. Hackathons set expectations so high.

View on HN

I got a similar feeling from the last technical test I did.

"It should take two or three hours". The failed me on a long list of nitpicks, including not setting up mocks for testing, not running pylint (I would need to install it on my personal machine) not providing a setup.py (which was never asked for) and numerous other trivial things some of which directly contradicted what the spec actually asked for.

If I had actually done all the things they complained about it would have been closer to two days worth of work. Wankers.

Sounds like your reviewer was incompetent. Those seem like minor nits.

It was less than incompetent. Like I say some of the points went against what was actually written in the spec. They asked for a "page" of data, "no need to style it" then complained that I returned HTML and not JSON data. Kind of pisses me off that I wasted a morning on it.

My experience with professional software development looks like this, in a loop:

Let's add a new button! How many story points is the button? (Insert 2-hour discussion about what a story point is) Okay, "Uncle Bob says" we need at least seven layers of code around it. Someone insists on doing it "TDD", even though the UI framework is not testable. Oops, the Agile Consultant broke Jira, it will be back up in two days. The PR gets stuck for days because of trailing whitespace violations. The button doesn't actually work, but the outsourced developer complains loudly until someone gives in and merges it. Review time!

The code that results from this madness is not better than Hackathon code, just bad in a different way. If anything, my last Hackathon has made me aware of how much I want to work for an effective company at some point in my life, so I guess it was worthwhile.

I feel your pain. But ideally, once the PR code is merged, the end result should be solid code. Anything you write at a hackathon is fake/barely-functional throwaway code that only exists for the demo at the end. There's no architecture, no error checking, and just no time for anything elegant or any real insight into your problem space.

Totally agree that half the fun of hackathons is throwing away all that shit and just fucking building something :)

But I never have to go back to hackathon code 3 months later and fix it. Bitter experience has taught me that at least some of that stuff (like the unit tests) is not optional if I want to stay sane.

Reply on news.ycombinator.com