The Road to Making - From Starter League to Developer

In college I studied economics. I recommend it to anyone who feels comfortable with the idea of knowing a lot about the world's woes and having very little ability to do anything about it. When I graduated, applying for jobs introduced me to a harsh reality, I had a lot of ideas but my tradecraft was lacking. I'd been huffing the sweet ethers of theory but yearned for the sobering oxygen of practice.

After college I caught a break and landed in the field of business intelligence (BI) before it really had a name other than "IT". Everyone has a different definition of BI, but here's mine: BI is the art and craft of persuasion using data. That's it. However you do it, be it graphs, regressions, tables, art, words, it doesn't really matter. It's the message that's the thing not the medium. Your job as a BI analyst is to gather and present the best version of the truth that you possibly can given an imperfect model of what you're trying to represent. You solve puzzles using the scientific method. It's a discipline where you strive for objectivity asymptotically.

I designed models that priced risk, but I also spec'd out the feeds that transmitted data and drew the diagrams showing how data would be related, stored and retrieved. Only, I didn't really build any of it. I was an analyst. It was my job to derive the logic, design the spec, write the requirements. We called ourselves designers and architects because that's a pretty good analogy, but our jobs stopped at the blueprint and the craftsmen took over from there. Analysts wrote the spec, developers built the product. If you're good, you know how to find the sweet spot between too much and not enough detail and you know the dimensions of a 2x4. But at the end of the day, I was still the guy who took the requirements from the customer to the developers, a people person dammit.

But I wanted to make things. Knowing how to design something that works isn't exactly the same as knowing how to build it. After designing the inputs and outputs of BI systems for a while you develop theories about how it could be done better. You think to yourself that given a chance to build it yourself, you can do it fitter, faster, more productive. This is the worst sort of hubris of course and the gods are laughing at you while you put your boots on but I'll come back to that. So after being an analyst and researcher for almost 10 years I decided I had to learn some tradecraft. I had picked up SQL and R along the way... how much harder could app development be i asked myself? My mom and friends already thought I was building apps like Zuck. How hard could it be? Damned hard, it turns out.

I enrolled in the second class of the Starter League during the winter of 2012. Starter League is the world's best learn-to-code school and is located in Chicago. It teaches web app development in 12 weeks. Starter League recently partnered with 37signals and is changing lives, I've seen it. All that said, everyone in my class completely sucked at web app development when we started. With no exception, we all struggled to grasp the fundamentals. Even the CS graduates didn't have a professional quality app ready by graduation. There were no "naturals". With time, many of us got better and went on to good jobs. But it was easily the hardest thing I've ever done. What programmers forget, but what is obvious to someone coming from functionally siloed enterprise work is that these "easy" web development frameworks are polyglots of various languages, DSLs, domains, competing theories and disciplines. You have to know a ton of stuff to build anything useful. Here's a short (incomplete) list of what you need to know to launch the simplest rails app:

- Ruby (and its gems, many of which are are themselves domain specific languages)
- Rails
- Javascript
- HTML
- CSS
- Unix
- SQL
- Database Administration
- Dev Ops
- Application Architecture
- QA methodology

So after the Starter League, I was still just getting started. I spent a year after that working on projects with friends while working full-time in BI. During that time my wife and I had a child and I did my coding during my spare time. I spent 10-20 hours per week at night and on weekends building apps and "rm -rf"ing them just as quickly. The funny thing about building these toy apps is that I learned to love doing it just because. For the same reason my dad takes apart lawnmowers and rebuilds chainsaws, programming is absolutely wonderful work.

Then, after practicing for a year, Adam Siegel, Inkling Markets' CEO, sent me an email. He was looking for a BI guy with rails experience! I was honest and up front about my abilities. I told him that I was not a pro. He was willing to hire me anyways because he believed I could learn and because he wanted to build out his reporting and analytics. He also wanted someone that would be interested in prediction markets. Perhaps an econ background has some use after all! It sounded like a perfect fit. I believe the cliche that luck happens when preparation meets opportunity, so I did not hesitate to take the job.

So here I am finally making stuff. Practicing my new tradecraft, learning the superpowers of the programming elite and earning a good living. They even call me padawan. Now back to the part of the story where the gods laugh at my foolish pride. Working at a software shop is sacred. I wear my hoody with respect because you wield the power to create, destroy and hurt yourself. It is as intense as being handed the keys to an F-14 and told, "don't crash it kid", and it is challenging. Everyday more challenging than the last. Since joining Inkling, I have written code I am proud of but the learning curve has been steep. My predecessors are YC grads, 37signals employees and Accenture Labs guys. The code is dense and deep. I came in wanting to design the ultimate end-to-end real-time BI solution in D3 and Ember but have spent much of my time preparing for that day by writing tests, migrating reports to email and climbing the very steep D3 learning curve. Another cliche I believe in is crawl-walk-run. After a couple of months, I now think I'm starting to walk and the road is high. All-in-all though, it has been worth it every step of the way.

If there's anything I can pass on to would-be-makers that I've learned, it's this:

Doing analysis, reading hacker news and conducting research is good at teaching you where you're headed before you get there but it's not the real thing. If you're a good developer, respect what analysts bring to the table; if you're an analyst trying to become a developer, try to unlearn what you've learned (not that one is better, it's just a different mindset).

Don't write any code you don't understand (you'll get less done, but you will learn better)... unless you're using a gem... then that's half the point. You'll get faster.

Don't overshoot your abilities too much in job interviews. The demand for developers is good enough that if you work hard to learn your craft, you'll find a job eventually. A good employer has the long view and will hire you because they believe your good ideas will soon be met by your ability to realize them.

Pat Carolan
Engineer and Data Analyst
Inkling Markets

New Report Features

Today we made some updates to the ‘All Trades’ and the ‘Price Changes’ reports which site administrators can begin using right away. Here is a list of the changes:

All Trades Report:

   added: stock status
   added: market status

Price Changes Report:

   added: price status
   added: stock status
   added: market status
   added: market type
   added: price id

The ‘All Trades’ report now has two new columns: stock status and market status. The ‘stock status’ column will show you the current status of the stock (also known as your possible answer) for every trade. When an answer is resolved, it will flag all trades for that market in the report as either ‘closed’ or ‘open’ depending on whether or not the question has resolved.This may be different than the status of the market (the question you’re asking) in the case where multiple answers may be correct, or if the possible answers are independent of each other (for example, in the question “What will the closing price be on these days in 2013 for Google?”, the stock for the answer last day in March (0LDIM) may cease trading at the end of march, while June, September and December stocks continue active trading).

The ‘market status’ column, similarly, will tell you the status of the market (also known as your question). We had users coming to us requesting these new columns so they could better understand what was happening with trading in their active markets or when they needed to run historical analyses only on their closed markets.

We also added five new columns to the ‘Price Changes’ report. The price changes report shows every prediction on a site and is often used to answer time series questions about Inkling data. The new columns are: price status, stock status, market status, market type, and price id. The price status column, tells you how the price was generated in the market. When you create a new market an initial price is set by the user who generates the question. This is the question originator’s prediction and will be flagged with a status of ‘initial’. This status may be useful if you do not wish to include the starting price in your analysis. A status of ‘market’ indicates that the price was derived via a trade in an active market and a price status of ‘final’ tells you the price set when the answer (stock) was resolved. Final prices are set to either 100 or 0 and are often removed when analyzing price movements. A status of ‘final: no trades’ is set when the answer was resolved without any trading having occurred for that stock.

Because different market types have very different characteristics, as a site administrator you may want to perform your analysis on only certain kinds of markets. The market status column will give you what type of market the prediction occurred in. For most of Inkling’s markets, this will be one of the following: Binary (yes or no answer), a DateMarket (what specific day will something happen), a DateRange (between what range of days will an event occur), Futures (the answer is a number), or Options (multiple choice).

Finally, we added the price id to give you a unique identifier for every prediction on your site, this is typically useful when you are doing analysis where you need to drill down on a single prediction or join data sets together relationally.

These changes lay some of the groundwork for some exciting features on the horizon in our graphing and reporting capabilities. Check back often to see what we’re doing to try to make Inkling’s data more accessible and insightful.

Pat Carolan
BI Specialist
Inkling Markets