I've done a lot of hackathons, and even the most high profile ones usually suffer from one of the following:
1. Internet and Working space
If you're expecting a high turn-out. Make sure the facility has a comfortable work environment and enough tables and chairs for everyone to work in. Ensure that the internet will not overload due to too many connections. This is a very common problem
2. Judging
Different hackathons have different purposes, and make sure the judging aligns with it. Some hackathons focus on business-viable projects, while others aim to build something "cool". Make it clear what the criteria is. If you're looking for cool projects, make sure the judges don't elect a winner because their project made the most business sense, especially if it's just a front-end hack, where the back-end doesn't even work (very common).
Have a way to check that projects weren't built ahead of time. Fraud is a major problem in hackathons.
Concerning judging, I advise everyone to… just drop it!
We started dropping it when we launched Museomix[1] as it made no sense for the mood and culture we wanted to create: inclusive, cross-disciplinary, community building oriented.
Back in 2010 and 2011 with the first ArtGame Weekends we had a jury and a small money prize. Most people didn't in fact care for both of them: it was just not an integral part of what motivated them.
On the other hand, jury and competition induce several issues. One is explicitly stating from the get go that only some teams and projects will have merits. Another one is falsely relying on the prizes as the solution to what happen next (we gave you 5000€, now go build v1).
Jury and winners in hackathons are event a PR trap! With a winner, you now have to focus your post-event PR solely on the winner, loosing the possibilities of picking and talking about the right project to the right person.
So, I now advise my community friends and my corporate clients to not have a jury in their hackathons, but to instead have, for example, a Mentor panel. They are not there to elect a winner, but to close the event, create a demo goal, and most importantly use their knowledge of the ecosystem(s) to trace a path for the teams to pursue their project (by for example referring them to the right persons or organizations).
One of my very clever client decided she would instead of having a single prize just give away all the tech she bought for the participants to hack with during the event -- using what would have been prize money! Estimotes, micro video projectors, WeIO and Arduino boards… to all participants. ("Come back home with your project"). It makes sense, and can cost the same. [3]
In a Museomix edition the reward is intrinsic: you live, build and show your prototype directly in a museum for 3 days. And everyone get to share this reward, organizers included!
As collective / co-creative events organizers, ask yourself if you really need to add more selective competition in a world where there is already so much of it, and ask yourself if having a jury really align with the culture you want to create. Do you want to create/mimic an academic/school culture? If not then maybe you just don't need jury.
I wanted to say something very similar about the judging. At hackathons with prizes the criteria really needs to be very clear upfront and strictly adhered to. Everyone works really hard during the event, and if the attendees feel the judging is poor, people will leave upset. For example, if people think a working prototype is important, and the judges instead go with a polished presentation with nothing behind it, that can be very frustrating.
"...weren't built ahead of time." Where's the line for this? Surely I'd be permitted to reuse libraries (that I've written; that I got from github; whatever) and perhaps the "project" is a smattering of glue. Am I disqualified because 99% was written "ahead of time"?
libraries are fine of course. in higher profile and more competitive hackathons, i've seen quite a few teams who complete the whole project (or re-use the same project from another hackathon).
I didn't go to Waterloo, but I predominantly hire from them, and I work with their graduates on a daily basis.
Yes. They get the best work experience. They will have no problems finding a secure job in engineering.
A problem I see is their lack of "university experience" and social growth. For some people with natural social abilities this is not a problem, but for others, university is a once in a lifetime experience to cultivate all aspects of personal growth.
This is very important especially for engineers, where the majority of us are introverts. I was one myself, and I learned invaluable things in university not related to work or school.
These days, it's actually quite easy to find a good job in engineering, no matter what school you're from, as long as you're smart enough to pass technical interviews.
For the previous owners there was never a point in taking the company public because they didn't need additional funds and it allowed them to do things that public companies like party gaming could not do for legal reasons.
Another reason for the sale was the fact that they were never able to convince US regulators that isai Scheinberg had nothing to do with the company anymore ( mark had taken over on paper ) which prevented them from getting a new jersey license.
There are 10X programmers.
I'll give an example. If you take an average programmer and "the best of the best" and ask them to build a relatively complex iOS app, of which neither has previous iOS experience, the best programmers WILL finish the task up to 10x faster than the average.
This is because the average programmer gets stuck on bugs, solving problems, complexity, and is slower at learning new things. The better programmer has a combination of skills that allows him/her to do the correct research and solve the problem at a much faster space. The rate of which grows as the complexity of the task increases. Thus reaching 10X.
Actually I believe almost everyone who is reading hacker news is a 10x programmer. It's really quite simple, the average IT person, especially in "enterprise" has very limited knowledge, but they do know some programming. Either in Cobol, Basic, ASP or Excel. Their job is to solve problems, but they're not really interested in their work. A job is a job, not a hobby. They have never heard about system automation, still thinks Linux is evil and a bedroom project and believes VMWare is a coming revolution for system administration, which they're gonna start to use soon.
I don't agree, if only because I'm the anecdote. I'm trying to pick up Rust and mess around with app/net security, but at my job, I feel like I'm in the middle of the pack. There are instances when I quickly fix stuff but also take forever to find a simple problem. To be fair, we do have a very extensive app with 15 years of code rot and only 2 members of the original team to guide/teach. But a guy that started a month after me is already 2x what I am in LOC/fix time. (I know, I know, LOC is a poor metric)
This and "if you read books, you're already way ahead of the pack" or similar statements are just feel-good statements. It's very clear that the other guy and the two original team members are way more productive than I am despite me trying to hit all of the recommended reading books and reading HN/subreddits/blogs/etc.
You can read HN/books/stack overflow and be really good as long as you take advantage of the information and actually practice it in the real world. But until you go and actually measure real things like LOC/fix time/projects completed, the signals "reading HN/books/whatever" are just cultural signals.
The attitude you have is the one that eventually drives you to be a 10x. If you think you are awesome at what you do, that is when you probably are not.
Here are some observations that may or may not help you:
Average programmers tend to:
* like new projects
* want to build "new things"
* not like fixing bugs
* not like reading code
* not like to redo their designs/code
* think their code is as good as it gets
Good programmers on the other hand
* tries to find joy in thr task at hand
* thinks their old code is bad
* aren't invested in their own designs
* don't fear trying solutions
* reads code rather than docs about the code
* don't mind fixing bugs
* happy when the code quality goes up, hates it when it goes down.
In other words - good coders CARE, average coders just want to have fun and build stuff. This means the latter group doesn't build the understanding of how to build good, bug free code. They prefer to build themselves into a corner rather than throwing out their designs. Thus they get less practice.
I wish it would be like that but my experience is that even average IT people are quite interested in what they do. (I'm still a student so my sample size is not that big).
I find it's heavily dependent on the company. Companies that see IT as core to a successful business tend to attract 10x programmers. If you are still in school then my advice is to learn to interview a company while you are interviewing for a job. Find the place that's going to push you more, regardless of pay.
The problem with the 10X label is that it models the productivity as linear relationship, when it's not, as you allude to.
A bad programmer can do simple tasks nearly as fast as a good programmer.
But at a higher level of difficulty that difference might be 10X. Hell, it might even be infinite.
For example, the best NFL QBs will win 10X as many games as the 3rd string backups. But you wouldn't call them 10X better. In fact they are probably only 10% worse than the elite QBs in their completition percentage.
Or if you raised the height of the hurdles 4 inches in hurdle racing, some of the racers wouldn't be able to jump over it any longer.
In this particular case, isn't "10x" just a factor of IQ then? Smarter programmers get complicated things done faster. That seems like a no-brainer. Problem is, how many of those people actually exist in programming? A much smaller subset than exist in the world, which is already a small subset of the general population. Hinging your company on hiring nothing but 10x programmers is like trying to hire a unicorn.
In that case, there are "InfiniteX" programmers. The worst programmers will get stuck on complex problems and may never complete the task without help. It all depends on the task.
And I say "average" programmer because average is fairly bad if you look at the workforce on a global scale.
Maybe these 10X programmers can quickly solve bugs and problems because they have faced similar issues before and spent the time nesseccary to understand the problem. In that case the important lesson is to limit the amount of novelty in your work so that you are mostly building on technologies you understand well.
In which case you'll probably inevitably end up building something with a suboptimal stack -- and limiting novelty also means you won't learn anything _new_, which sounds more terrible to me.
I am not arguing that you should elimate novelty completely. Just that the amount of time you have to learn new things is limited and needs to deliver returns.
Take the iOS app development. Consider someone who has never used Objective-C but has lots of experience doing client side web development. It would probably be faster for them to develop using a tool like Phonegap and use existing skills. It is theporetically sub-optimal to native code but surely the time spent learning phone gap will produce faster results than trying to learn an entirely new stack.
1. Internet and Working space
If you're expecting a high turn-out. Make sure the facility has a comfortable work environment and enough tables and chairs for everyone to work in. Ensure that the internet will not overload due to too many connections. This is a very common problem
2. Judging
Different hackathons have different purposes, and make sure the judging aligns with it. Some hackathons focus on business-viable projects, while others aim to build something "cool". Make it clear what the criteria is. If you're looking for cool projects, make sure the judges don't elect a winner because their project made the most business sense, especially if it's just a front-end hack, where the back-end doesn't even work (very common).
Have a way to check that projects weren't built ahead of time. Fraud is a major problem in hackathons.
Good luck