Hack to the Future

Why today’s high schoolers have me optimistic about tomorrow

As the founder and president of a growing enterprise technology company, I’m always evaluating our recruitment strategy and assessing which candidates can help to accelerate our business. Given the cutting-edge nature of our work, top prospects are hard to find and our filling our pipeline with qualified applicants is an important part of our management team’s efforts. For entry-level candidates, though, we usually begin the recruitment process on-campus, at select universities, where we frequently have success extending full-time offers to interns that have proven themselves to our team  technicallyand, more importantly, culturally,for the rigors and mores of our firm.

Uniquely, I recently had an opportunity to catch a glimpse of a possible tomorrow -- for our firm and our nation -- through my participation in a local hackathon, which left me feeling highly optimistic about technology literacy in the U.S.A. and America’s role in the future of technology.

For the uninitiated, a hackathon is akin to a rave for software developers. Groups of talented individuals come together in a physical location and compete to develop and present a technology product under time constraints -- usually eight to 24 hours, with a winning team emerging by dawn’s light. Hackathons have become more popular over the past decade, with a range of institutions sponsoring them, sometimes corporations tasking talent to think through a brand-specific challenge and other times more of a general celebration of creativity and innovation bound by time.

In this case, Union County (New Jersey) high school students participated in the second annual occasion of HackUC II. As a resident of the community, an event sponsor, and a judge, I had several roles to play. I was excited but also curious:

  • With all of the talk about how young people favor indirect and impersonal means of communication, how well would these digital natives work together?

  • How well-prepared are today’s high school students for being tomorrow’s software engineers?

  • Finally, how would a bunch of pre-college kids deal with unknowns, deadlines, and stress?

HackUC kicked off on a Friday night, and for the next 24 hours I endured what might be a nightmare for most people: being locked inside with 150 teenagers hopped up on caffeine and hormones. To my pleasant surprise, I had an incredible time mentoring numerous teams, working alongside the hackers, observing how they organized themselves and articulated ideas, and witnessing how creative figments rapidly morphed into actual software products.

By the end, as a winner emerged, I found myself inspired, impressed, and hopeful. From my many takeaways, here are three: 

  • Email is dead, but teamwork isn’t.

I don’t recall seeing a single team use email. I didn’t need an energy drink to stay awake: for me, this was eye-opener enough. Instead, most used some form of instant messenger for all communication, e.g., Slack and Facebook Messenger. The students chatted internally via text and messenger with their teammates and peers less than three feet away. (Now that I think of it, most of our engineers do the same!) What I learned is that email is too slow for the pace of today’s technology projects.

Somehow, in addition to modern forms of communication, the hackers ably worked together -- something I’d also assumed is learned by young professionals, not high schoolers. These kids  were naturals: they assembled into teams within the first 30 minutes, in many cases working with hackers they’d never met before. Quickly, they assessed one another’s strengths and weaknesses, and formed whatever hierarchy was necessary to get projects moving along. I witnessed some teams with identifiable leaders driving progress, while others functioned more democratically. Overall, I was bemused by how these teenagers outdid many adults by putting their energies toward solving problems and not squabbling over whose direction to follow. 

  • Are WE ready for THEM?

Beyond instant messenger communication platforms, these hackers are far more advanced than many of their much older, already-professional counterparts. For starters, teams worked in real-time on code editing in multiple languages, developing and documenting websites, and presented using professional tools like Adobe Creative Suite, Github, and G Suite.

It’s not simply that these students know how to code and use tools that today’s developers are using in labs and studios around the world; it’s that some have even built their own desktop computers from spare parts! With university still ahead of them, will we even be able to teach them anything by the time they join the workforce?

  • The future’s fast-failers are free-wheeling forward-thinkers.

The start-up mentality of “iterate and fail fast” has become pervasive and entered the non-technology lexicon as an approach to general innovation. This idea, and how the hackers harnessed it, was perhaps the most impressive of all -- particularly their ability to expound on ideas and to fail quickly when an approach headed in the wrong direction. The tenacity required to get through a 24-hour hackathon with a working demo at the end is challenge enough; but, consider that most of the teams came to the hackathon without a plan for what they were going to build. (Many teammates didn’t even know one another, either!)

Further, these students showed amazing research skills in identifying what they were going to build, what tools or web services or sponsor’s APIs they needed to build them. And then they did it, employing common start-up approaches to developing a Minimum Viable Product (MVP); monitoring progress in real-time and course-correcting when approaches led nowhere. In some cases, teams abandoned their original ideas and went back to the drawing board completely (e.g., “pivoting”).

This last example is, perhaps, the most useful takeaway for “grown-ups.” In the professional workplace, we frequently stand to gain the most long-term success by making small, fast, iterative decisions that build on earlier decisions. By embracing failure, and eschewing fear-based over-analysis of prior decisions, we can develop end products that are better, faster, stronger.

Tomorrow’s software engineers have a lot to learn. Yet, there is much that they can teach us today and even more we have to be hopeful about the future.