Even for a seasoned computer programmer, hackathons can be an amazing opportunity to learn, network, and think outside the box. Success stories like GroupMe and the Facebook "Like" button (both of which came from humble hackathon beginnings) may feel unattainable to the average engineer, but that's half the fun! You never know what your team will come up with in the collaborative, fast-paced, rule-bending hackathon environment.
The Los Angeles tech scene is not to be underestimated. Google, Yahoo!, Facebook, Snapchat, BuzzFeed, and dozens of other tech companies have offices in LA — often located in the Westside’s Silicon Beach region.
“When a hot dog expands, in which direction does it split and why?" “Would you rather fight one horse-sized duck, or 100 duck-sized horses?" “If you're the CEO, what are the first three things you check about the business when you wake up?"
For people who aren't familiar with software development, it can be easy to assume that all developers work in the same way. After all, estimations of a task's difficulty (whether you're using days, points, or some other metric) leave little room for distinction between developers. There are junior, senior, and lead engineers, but what about good and bad engineers, and the differences of productivity and quality between them?
Former software developer Piet Hadermann takes on this topic in his blog post "Your Developers Aren't Bricklayers, They're Writers." A good developer, he explains, is not difficult to define: it's someone who writes well, logically, and with very few bugs. According to Robert Glass, author of "Facts and Fallacies of Software Engineering," these good developers can be up to 28 times better than bad developers. How is that even possible? It's simple: better code leads to less pressure on managers and other developers, fewer unexpected bugs, a more reliable product, and a stronger, more productive team.
In contrast, bad developers, can make the coding process way more complex. Not only do they write bad code, Piet says, they spend too much time on illogical code that's difficult to maintain and is riddled with bugs. A single QA cycle with bad code can take weeks and result in an abundance of new bugs. Two or three QA cycles later, the release is late, other departments are unhappy, and the team's productivity has already suffered greatly. When you take this bigger picture into account, it's not hard to see how the quality of a developer can have such a profound effect on an entire team.
Making a distinction between good and bad developers isn't about pointing fingers or shaming certain people. It's about making sure that good developers are celebrated, rewarded, and fairly compensated for the quality of their work. It's also about helping non-engineers understand that every developer is different, every team is different, and trying to force standardization between them can often do more harm than good.
People who don't understand software development often think of it like factory work — as long as you churn out "X" lines of code each day, you're worth "Y" salary. But this simplistic view ignores the differences between how individuals work, and the quality of work they complete. In order to foster a cohesive, productive work environment, it's imperative that non-engineers begin to better understand this concept.
To read more about Piet's experiences with measuring developer productivity, check out his original blog post here.
Working as a developer requires very specific qualifications—a set of norms, priorities, and even languages that are often foreign to non-developers.