SheHacksATX: a hackathon done right

Hackathons can be a good change of pace for us developers because they force us to experience software development in a different way. At our day jobs we often work on a feature for weeks, because it needs to meet complex requirements that are often subject to many unknowns and last minute changes. But a hackathon can make it possible to implement not just one feature, but an entire prototype, or minimal viable product, in a day. It depends on how the hackathon is run, and just as much on preparation of the teams.

If your team has the right skills, or at least has researched in advance how to implement various moving pieces (for example, OAuth authentication using your chosen programming language), then a hackathon can give you a concentrated dose of accomplishment you often don't get at work. But if you approach a hackathon unprepared, and have to research those technologies as you're trying to use them, you will just spin your wheels. You might waste that day just scratching the surface of technologies you may or may not ever use. (I doubt that most projects started at hackathons ever get worked on again.)

Developers socialize in the morning before the coding starts. Left to right: Kathy, Stephanie, Ruby, Dallas, Nari. More pictures from SheHacksATX are in my photo gallery.

At SheHackATX, a women-only hackathon that took place on April 26, 2014, teams had not been formed upfront. Developers were matched with projects at the beginning of the hackathon. Each project was a woman-run startup (most of them local to Austin) that needed programming help, such as to add some features to their app or website. In the morning, developers wrote down their preferences of apps to work on, and the owners picked programmers they wanted on their team. Hopefully everybody got at least their 2nd or 3rd wish.

Since the teams were formed on the spot, they could not coordinate and learn complementary skills in advance. So it was all the more impressive that half of the teams were able to accomplish the tasks that startup founders wanted in the the time provided (from around 12 to 7 pm of one day). Those startups were Girls Guild, Groove, Yoga Recipe, and Bound Round. In my opinion, they were successful because their founders were able to correctly estimate tasks that might take about a day, and went with small'ish, manageable enhancements for their applications; nothing grandiose.

An example of that would be Girls Guild, a website that matches girls who want to learn hands-on skills (e.g. chocolate making, jewelry making, leather working or photography) via apprenticeship, with "makers", i.e. experts in that area. Both the makers and the apprentices are girls or women. One of the features Girls Guild founders wanted to have added to their app had something to do with being able to delay a payment until another event occurs (the details escape me). They also wanted ability for a maker to schedule interviews with a prospective apprentice through the website, as opposed to a manually emailing back-and-forth. The Girls Guild team succeeded in implementing both features.

Girls Guild and Hearth teams at work. Sitting at the table, left-to-right: Bethany (developer), Diana and Cheyenne (Girls Guild founders). Standing behind them, the Hearth team: Nari and Monisha (developers) and Florence (founder). More pictures from SheHacksATX are in my photo gallery.

Bound Round coders didn't have time to implement a 3D spinning globe (in Javascript, I guess) that the owner wanted, but they implemented a zoomable map that shows different levels of info depending on the level of zoom. Quite impressive for such a short time. Yoga Recipe wanted to integrate their website with Facebook, Twitter, and Instagram; "integration" meant ability for yoga instructors to share the "recipes" (sets of instructions for yoga classes) on social media. They succeeded with Facebook and Twitter. They also implemented ability for yoga teachers to put together playlists for their classes using Spotify.

My team also did well with our application, Groove. More about it in the next blog post, where I'll talk about what we did and how we did it, highlighting the obstacles that a programmer might experience during a hackathon.

Some other startups set their deliverable for this hackathon to be not code, but ideas. The founders of Our Desired Future and Hearth came here with just some ideas for their websites -- some better hashed-out than others -- and asked for technical advice on how to best implement them. Our Desired Future wanted to put together a series of multimedia presentations to tell interactive stories about water usage and water resources of Texas; in case of Hearth, what the owner really needed was to winnow down a number of her eclectic ideas about promoting volunteering through gamification, to something that could serve as minimum viable product. The result of her brainstorming with her team was a landing page for the website. In the process, one of the people on her team concluded that her calling in life was product management. So in these two last cases the product wasn't tangible; the real product was refinement of initial notions into more concrete ideas.

Revenge of flowcharts

My other gripe regarding automated job search application goes towards Texas Workforce Commission. It makes you fill out an enormously long profile that lists various aspects of a programmer's work, and asks you how much experience, if any, you have in each of them. Then it matches you with jobs based on how much overlap there is between tasks you are experienced in, and ones required by the job.

One minor imperfection of the Texas Workforce Commission job match system is that sometimes it sends you email notifications of job matches, but when you login into the system, it says you have no new matches. It's a bit annoying. Occasionally, though, it's possible to find the missing job posting by searching the TWC site. One time I was able to find a .NET developer job it notified me about, but didn't show in my job matches. When I viewed the posting, it said I wasn't qualified for this job. I was surprised, because on the surface there were no requirements I didn't meet (such as programming languages or business areas I haven't worked in). But there is a button that lets you compare your qualifications to the ones required by the job. Clicking the button revealed that I am not qualified because I checked "none" in the profile box asking for years of experience in... creating flowcharts.

I thought creating flowcharts was something my mom's generation of programmers (hi, mom!) did before they punched holes in the cards to feed to a machine. :-) I haven't had to create a flowchart in my entire 13 years in the industry. Well, this job is at a government agency, but still... If they use .NET there, they can't be complete dinosaurs.

And then flowcharts had their revenge on me. I am volunteering for a nonprofit that want developers to do some coding -- for free, of course, but the developers benefit by having something to put on their resumes, learn new skills, make networking contacts, etc. So far I haven't done any coding yet, because project managers (who seem to be overrepresented among the volunteers) are still setting up the infrastructure for the group communication, collaboration, sharing documents, etc. We have not yet written specifications for the piece of software we will be writing, but one of the project managers has created -- you guessed it -- a flowchart of users' expected actions when they login to the website. So... I don't know. The person who wrote it was half a generation older than me, but maybe flowcharts still have their uses?

Quirks of automated job search

In my job search I've run across not just one, but two big companies that use the same resume-parsing application. The existence of such applications is new to me -- they weren't there when I was looking for a job 9 years ago. This piece of software parses your resume after you upload it to the company's website, extracts relevant information from it, and converts it into its own format. For example, it will recognize your address, phone number, and email address, and put them in appropriate fields. It will also recognize Summary Of Qualifications, Objective, and perhaps some other sections, and put those paragaphs in appropriate boxes.

Further than that, things get tricky. It tries to recognize names of companies you've worked for, and does it with only a varying degree of success. The name of my pre-previous company, i2 Technologies, has the power to throw the parser off. It may be the lowercase i that trips it, but both times it parsed it as "Technologies". Fortunately, the system lets you correct this stuff manually.

And boy, is there lots of tedious manual correcting to be done. The parser doesn't handle bullet points very well -- it lumps them all in a big single-paragraph mess. Cleaning it up once is tedious enough; doing it twice, even more so. Doing it on a netbook, which has little vertical screen space, is even worse. Doing it on a netbook on a web page where the editing window, embedded between an immovable header and footer, is about an inch high... that's just UGH.

If I had known that these parsers were used by more than one company, I would have copy/pasted and saved the formatted text in a file. But, as Murphy's law would have it, I might not come across another company that uses it. :-)