The Iron Yard or How I Learned to Stop Worrying and Love Code School

Today I celebrate my 29th birthday. “Celebrate” may be a bit of a stretch, though, because I now feel like my 30s are barreling down on me with the momentum of a freight train. Most of my friends have steady long-term jobs where they are successful. Many are married. Several have children. And I have spent much of the last decade struggling to get my life together. There is hope, however. I start my first programming gig at a company called InvestCloud on Wednesday, and I owe that to a coding school in St. Petersburg called The Iron Yard.


I didn’t decide to become a professional academic all at once, but the first domino fell when I became a history major in my second year at the University of North Florida. I majored in history because the Registrar’s office required an official major and those were the classes I most enjoyed. When I specialized in East Asia, it was because the department required an area studies specialization and I was sick of dealing with the U.S. and Europe. I understood that a History degree would not lead me directly to gainful employment, so I double majored, eventually securing a B.A. in Economics. I thought I was being practical. Despite the fact that I had only had one year of Chinese Language before the program was closed down due to lack of interest, I applied for PhD programs in the Fall of my senior year because I was the best student in the UNF History department, and I thought that had to mean something. Even though I was rejected from all the PhD programs to which I had applied, when Columbia University instead accepted me into their Master’s program, it felt like an accomplishment.

I continued to learn Chinese throughout my time at Columbia, and thought in passing that if my academic career didn’t pan out, knowing Chinese was a valuable job skill that could provide me with potential employment in the future. I took my first trip to China in the summer of 2010, and by the time I returned to the U.S. I was brushing up against fluency. Still, I knew that my language skills were a weak point in my academic resume. All of my friends in the East Asian department either were Chinese or had taken years of Chinese instruction at expensive private high schools and colleges, spending substantial time in China on vacation or studying abroad, before they even started at Columbia. That you knew one foreign language when you started at the M.A. level was more or less expected. Really, you were supposed to be starting on your second. When my second round of PhD applications were all rejected in my second year of grad school, I was unsurprised when my advisor told me that Columbia had rejected me because of my lack of Chinese language skills.

I did not let this verdict deter me. Lack of language skills had a remedy. I applied for and received a substantial scholarship from the Taiwan Ministry of Education, and spent the next year at National Taiwan University in Taipei in the International Chinese Language Program, one of two top such programs in the world, and the only one that did not to require me to return to the smog of Beijing. That year in Taiwan was the best of my life, so of all the regrets I have regarding choices I made trying to become a professional academic, I can’t say that enrolling in ICLP was one of them. I returned to the US in September of 2012 a different person. I moved into my grandfather’s old house in Tampa because I had nowhere else to go.

On this round of PhD applications I did everything that you are supposed to do. I flew to California on the pretext of seeing friends to meet with professors at Stanford and UC Berkley. I spent hours crafting each of my applications. I used writing samples from my painstakingly researched Master’s thesis. When the round of rejections came this time, I knew that it was time to give it up. My career as I had imagined it was not going to happen. Some of my problem was timing. Stanford, for example, didn’t take any China people that year for budget reasons. But ultimately, I now believe that no one was going to consider seriously the application of somebody who had gone to college at a state school in Florida. My effort had been doomed from the start, and Columbia had accepted me into their Master’s program not because they saw a potential scholar in me, but because M.A. student tuition were a substantial source of the department’s funding.

Getting out of academia was the right decision. Even my friends who made it into PhD programs are struggling in this job market, or to get tenure. Yet at the time, the decision broke me, and I spent a long time afterwards lost.


In the latter part of 2013 and through most of 2014 I applied for every position I could think of that might match my skills. To the State Department first as a Mandarin Language Consular Adjudicator then as a full Foreign Service Officer. (I actually made it a couple of steps into that process, and to this day have no idea what was inadequate about my Personal Narrative essays). I applied to every community college in the area. I applied for translation and interpreter jobs, but there were thousands of Asian-American applicants that spoke better Chinese than I did, and besides those jobs didn’t pay substantially better than minimum wage. I applied for minimum wage positions, too. I was sending out more than a dozen applications a week and receiving the slightest response perhaps every other month. I was having conversations at parties were someone would ask me something like “You have a graduate degree, right? Why don’t you apply to teach community college?” and I would respond, “I’ve applied to open positions at HCC, PHCC, SPC, and St. Leo, and never heard back even an acknowledgement. Where else would you suggest?”

I settled on going into public education as a last resort. Both of my parents had been high school teachers, and while I thought I wouldn’t be suited for it, I knew it was something I could probably do adequately. There were tremendous barriers there too. No school would accept the application of somebody without teaching experience, no matter their education. Eventually I took a position in the substitute pool in Hillsborough County in the fall of 2014.

The less said about my time as a substitute, the better. The first position I took was for a long term absence, and despite all the encouragement I received about what a good job I was doing and how a permanent position might be in it for me if I kept it up, when I even broached the subject of getting my teaching certificate, I encountered brutal institutional resistance to the idea of anybody not a graduate of a local College of Education getting a teaching position. By the time that long term ended, I knew I needed to find something else, even if I didn’t know yet what it might be.

It was in this situation that I first met Toni, the Iron Yard St. Petersburg campus director. I was still working as a substitute but had taken the day off to go to some entrepreneurial event. I had no idea what I was looking for there. There were some stands along one side of the presentation hall, and I couldn’t help but notice one that read, “Life’s too short for the wrong career. Learn to code. The Iron Yard.” It set my mind on fire with the possibilities. Here was something I could do. I proceeded cautiously. Surely, I thought, something that provided such a clear solution to my problems had to be some sort of scam. I had a cordial conversation with Toni about who the Iron Yard was and what they did. I was reluctant to put my name down on her contact list, but I took her card. I left the event before the first speaker finished. The event was not my scene. But I kept the card.

I have a lot of developer friends, and the first thing I did when I got back was to ask them if they had ever heard of The Iron Yard. Some of them had. I asked the important question: Was it legit? As I sorted out the responses and did some deep digging research of my own, it became clear that it was, or at least as legit as any code school. I went through the motions of research and skepticism for quite a while afterwards, but, really, I knew that I would enroll in the next cohort by the end of that week. I felt direction and purpose seeping back into my life, and it was great. When I resigned from my position as a substitute, by email, by phone and finally by certified letter I never received an acknowledgement. I’m still on their mailing list now.


I’m often introduced as someone who entered into The Iron Yard with no coding experience, but its not entirely true. When I was a kid in the early 90s my dad was a computer science teacher, and he brought home an ancient PC to teach me programming on, writing in BASIC on the old DOS Shell. My parents sent me to computer science and engineering summer camps as a middle schooler. I took advanced math and AP Computer Science classes in high school. It’s just that when I went to college I rejected all of that to go into the humanities because I liked them better.

Which is to say, when I started the Rails course at Iron Yard in May 2015 I felt parts of my mind that had developed and then atrophied from long disuse coming back to life. I’m not saying that the Rails course was easy for me. On the contrary I spent many long night alone at the St. Pete campus bashing my mind against a problem until the problem cracked or my mind did. I guess I learned quicker than others, but I knew by now that that didn’t mean anything in the long run. In the short run, it did mean that I was able to pick up a few more languages and skills than were in the curriculum, for all the good that’s done me. But what I am saying is that, even when I was running over and over against the hardest of brick walls, it never stopped feeling right. This was something I could do.


I was never worried about Demo Day. I had given so many speeches and presentations by this point that they were second nature, and our instructor, Jason, was talented enough that I had complete confidence that the app I was presenting would work fine. What I had been worried about, more or less since the beginning, was finding a job afterward. I knew how brutal searching for entry-level positions was, and though I felt I had gotten an excellent practical education in actually working with code, I was skeptical that tech companies would see it that way. I suspected that hiring managers would look at our lack of experience and the fact that our programming education had only lasted three months and dismiss us out of hand. And really, the entire coding school system only works by exploiting a glitch in the economy where there aren’t enough traditionally qualified applicants to fill open positions for coding, and that glitch would only exist in cities with a thriving tech community that was constantly generating new jobs. Not, in other words, in Tampa.

The fact that I had my first serious interview (for a Rails position with the Tampa Bay Rays) less than two weeks after graduating proved that, at least in principle, the system worked. They looked at the code for my final project and were more or less convinced that I could code. Still, that job fell through and as weeks of unemployment stretched into months without another company showing comparable interest, it was hard not to become bitter. If there were almost no tech shops in town working in Rails, why even have a Rails program, instead of something more commonly used like C++ or Java. The idea that we had learned code fundamentals and thus had skills applicable to almost any entry level coding position was cold comfort when you were rejected from a Javascript or Python job because your portfolio was mostly filled with Ruby and Rails stuff. Still I knew what applying for jobs before the Iron Yard had been like, and this was not that. I was getting callbacks for almost every application, and had preliminary interviews at least two or three times a week. Having a marketable job skill, even if it didn’t fit neatly into the round hole of current job openings, was an enormous boon. I knew, too, that I was getting a lot of opportunities either directly or indirectly through The Iron Yard’s connections and Toni’s excellent PR work. And despite our struggles with the current job market, those two things more than made up for the price of admission.

When I applied to InvestCloud, I was two interviews deep with another company that was looking for a Rails developer, and more or less dismissed them because were a Java/JVM shop and I didn’t know Java. I did it more out of obligation to Toni’s work of recommending me to them than because I thought I was likely to get the job. The other job fell through on the same day that I had my technical interview with InvestCloud, and it went shockingly well. That interview was the first time I had the experience of somebody asking me to solve a coding problem in front of them, which we had practiced in class, and thank God we had, because it was a harrowing experience. What I remember most about the process with InvestCloud was that I went through so many interviews; a prelim over Skype, a technical interview over Google hangouts (both with the LA office), an in-person interview in the Tampa office, and finally a phone conference with the head of the Tampa office, four a grand total of 4. I didn’t even know you could have that many interviews. Apparently I impressed the developers in that technical interview, and more importantly I realized that I liked them; that this was a company I wouldn’t mind working for. By the end of the 3rd interview I pretty much knew I had the job, of course, but the rug had been pulled out from under me so many times that I couldn’t let myself believe it. Even now I worry that I am going to walk in on Wednesday and they are going to tell me that there has been a mistake and I can go home.

Of the rest of my Rails cohort, only one other has a programming job. Everybody else is still struggling with the market. That said, my experience gives me hope for them. I am confident it is only a matter of time before their ship comes in, and maybe in an unexpected way. After all, I’ve had a greater return on investment from paying for The Iron Yard than on all that I sacrificed for my fancy Ivy League education.


I have a lot of conversations with my friends who have Computer Engineering or Computer Science degrees, and they think I should be called a technician rather than a developer because I don’t understand the tools I am using. I couldn’t, for example, write a relational database like the PostgreSQL I use so confidently in my Rails apps. I respond with something along the lines of “Why would a carpenter need to understand how a hammer is made, if he can be confident that it works?” After all, all but the very top students in those classes are going to be going after the same jobs I am, learning whatever system their company is using, without the opportunity to design it themselves. Still, in my heart of hearts, it bugs me that I don’t have the wherewithal to design a relational database. That my friends who started down this path initially will always be ahead of me because they have such a head start, that I will never be as good at programming as they will. It bugs me not to be the best at things. But I think of this job that I start on Wednesday that looks like it will be pretty fulfilling, and I think maybe mere adequacy is all right.

InvestCloud is flying me out to Los Angeles to spend two weeks learning their system with the developers in the home office. Because they knew this they kept asking me in interviews if I liked to travel. I thought back to my time in China and Taiwan and Japan and Hong Kong and California and Colorado, and said “Sure, I like to travel.”

Posted in Uncategorized | Leave a comment

Using Ruby Slim

In reference to the last post on dealing with git branching, the command to remotely delete your branch on Github turns out to be:

git push origin --delete <branchName>

What I actually accomplished in my last experiment with git branching on Cream of the Crop was converting several of my views from Erb to Ruby-Slim (as well as handling some of the views through iteration). Slim, like Haml, is a templating language that generates html markup. The advantages of using such a language are obvious from looking at my views:

In Erb (I’m just going to go through one iteration; I wrote this without bothering to sit down and figure out how I might iterate through the views):

<div class="row">
	<div class="box">
		<div class="col-lg-12">
			<h2 class="text-center">
				<strong>Your Wrestlers in the Main Event! </h2></strong>
				<h3 class ="intro-text text-center"><u>Babyfaces (Tecnicos)</u> </h3>
			<%unless @main_event_babyfaces.blank?  %>
			<% @main_event_babyfaces.each do |wrestler|  %>
					<div class="col-sm-4 text-center">
						<%=image_tag wrestler.image.url, class: "img-responsive"  %>
					<div class="btn-group pull-right wrestler-options-group">
						<button type="button" class="btn btn-default dropdown-toggle" data-toggle="dropdown"
										aria-haspopup="true" aria-expanded="false">
							<i class="glyphicon glyphicon-cog"></i>
							<span class="caret"></span>
						<ul class="dropdown-menu">
							<li><%= link_to 'Wrestler Profile', wrestler%></li>
							<li><%= link_to 'Change Details', edit_wrestler_path(wrestler) %></li>
							<li><%= link_to 'You\'re Fired', wrestler, method: :delete, data: { confirm: 'Are you sure?' } %></li>
						<h3 class="text-left"><%= %></h3>
					<%end  %>
			<%else  %>
				<h4 class ="intro-text text-center">
				You have no babyface wrestlers able to compete in the Main Event! <%= link_to 'Hire a new wrestler', new_wrestler_path %><br>
					Turn a heel face! Turn a face heel! Promote somebody! Alternatively
					<h1 class="text-center"> SHOVE THAT CONTROL INTO A NOSE DIVE!!!</h1>
			<%end  %>

Versus the Slim version:

- (0..4).each do |position|
						h2 Your Wrestlers in the #{@positions[position]}!
						- (0..1).each do |alignment|
							- index = (position*2 + alignment)
										u = @alignments[alignment]
									- unless @wrestler_categories[index].blank?
										- @wrestler_categories[index].each do |wrestler|
												= image_tag wrestler.image.url, class: "img-responsive"

													button.btn.btn-default.dropdown-toggle type="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"
														li = link_to 'Wrestler Profile', wrestler
														li = link_to 'Change Details', edit_wrestler_path(wrestler)
														li = link_to 'You\'re Fired', wrestler, method: :delete, data: { confirm: 'Are you sure?' }
												h3.text-left =
									- else

											| You have no babyface wrestlers able to compete in the Main Event! #{link_to 'Hire a new wrestler', new_wrestler_path}
											| Turn a heel face! Turn a face heel! Promote somebody! Alternatively
										h1.text-center SHOVE THAT CONTROL INTO A NOSE DIVE!!!

The limitations of WordPress, make it a bit hard to tell, but the second one is much simpler.
A couple of tricks that I eventually picked up:

  1. You can chain classes together with ‘.”s. This is crucial because having a class on the same indent level closes out the previous div, so if you need something with multiple classes that’s pretty much the only way you can do it.
  2. Anything you do with a rails helper, like ‘image_tag’ or ‘link_to’, you have to manipulate it’s class in the old way, i.e. ‘, class = “”‘.

One last point is whether to use Slim or Haml. Haml is more popular, and that’s kind of an argument in and of itself. As far as I can tell, the only substantial difference between Haml and Slim is that Haml has a ‘%’ in front of all the templating commands. It’s a small difference, but if we are trying to make our code minimal and increase readability, then surely Slim’s lack of a ‘%’ everywhere accomplishes our goal better than Haml does.

Posted in Uncategorized | Leave a comment

Git Branching

I was searching for topics to blog about and realized that I could get a lot of material out of the projects I have been working on since leaving the Iron Yard, and might even provide some insights for prospective readers, so here goes.

I am juggling a lot of different projects, including trying to learn Node.js and basic Python, as well as trying to improve my fundamental coding through exercises. I have some internal debates about whether I should be doing this or focusing exclusively on improving my Ruby and my Rails. The question is one of breadth vs. depth: are you more valuable as a programmer if you know how to do a bunch of things sort of well or if you know how to do one or two things really well? I’m trying to hit a compromise.

The crux of that compromise is that I am working on that other stuff at least a bit every day, but focusing on adding features and tooling to my Demo Day app, Cream of the Crop. This is a calculated choice as well. Shouldn’t I focus on building new and different apps instead of simply adding features to my old app? For one thing, I feel like I have enough experience creating new basic apps for the nonce. It’s true that making different kinds of apps provides you with experience with different code, but I feel like adding more complicated features to Cream of the Crop accomplishes more or less the same thing.

That said I finished my first major addition to the app today (converting many of my views to Ruby-Slim, on which more later) so I am an a perfect place to talk about the stuff I learned working on it.

While it isn’t Rails specific, the first thing I learned working on this project was advanced Git, specifically branching. I remember working on group projects at The Iron Yard and simply pushing to Master and hoping that nobody would generate a serious merge conflict.  And obviously you can get away with it, because we did. That said I can see where that would be a major problem in a situation with multiple people all making commits. Where it became an actual problem for me was when I tried to convert to Slim the week of Demo Day and needed to make a change to my webpage to test something before I was done. Ultimately I git checkout’d and lost a lot of work.  Hence when I went back to the Slim problem after Demo Day the first thing I wanted to do was learn branching.

A resource that I found very helpful was this page. The crux of it is this:

git checkout -b branchname

creates a new branch and switches to it

git checkout branchname

switches back and forth between branches, with their own commit systems

git checkout master

git merge branchname

git commit -m “message”

git push

when you are done with your branch and want merge it into master (you might have to deal with merge conflicts).

Finally, when you are done with the branch entirely

git branch -d branchname

will delete the branch.

All of this works fine as is in your local git setup. When you start pushing to Github though, there are a couple of wrinkles. Your Github repo is set up to only acknowledge your Master branch. You can commit as normal, but to actually put stuff up on Github you have to

git push origin branchname

and you have to do it every time you want your branch commits to show up on Github. I found this page helpful in explaining how that works.

One final wrinkle is that none of those commits to a branch show up on your official commit stats on Github until you merge back into Master. So, for example, this afternoon when I merged my Slim branch, which had 17 commits, it jumped my total commits on the app from 88 to 105, retroactively inserting them into the proper timeslots. Weird, but not really a problem unless you are obsessed with maintaining Github streaks (which I totally am).

Oh and one final thing. I haven’t figured out how to delete the Github branch from the command line. Obviously you can’t git push origin branchname from a branch that you’ve already deleted locally (wait, can you? will have to try that next time), so you have to go in and delete it through Github’s website.

Posted in Uncategorized | Leave a comment

To Tinker or Not to Tinker

I’m using a natural language parser in one of my development branches of my Cream of the Crop app, to make a user typing something like I want to have a show “next Tuesday” mean something in my actual data. I’m using a gem called Tickle which relies on another called Chronic. Every time I boot up my app, I get these warning messages:

15:24:24 web.1  | * Environment: development

15:24:38 web.1  | /usr/local/lib/ruby/gems/2.2.0/gems/tickle-1.0.2/lib/numerizer/numerizer.rb:5: warning: already initialized constant Numerizer::DIRECT_NUMS

15:24:38 web.1  | /usr/local/lib/ruby/gems/2.2.0/gems/chronic-0.2.3/lib/numerizer/numerizer.rb:5: warning: previous definition of DIRECT_NUMS was here

15:24:38 web.1  | /usr/local/lib/ruby/gems/2.2.0/gems/tickle-1.0.2/lib/numerizer/numerizer.rb:30: warning: already initialized constant Numerizer::TEN_PREFIXES

15:24:38 web.1  | /usr/local/lib/ruby/gems/2.2.0/gems/chronic-0.2.3/lib/numerizer/numerizer.rb:30: warning: previous definition of TEN_PREFIXES was here

15:24:38 web.1  | /usr/local/lib/ruby/gems/2.2.0/gems/tickle-1.0.2/lib/numerizer/numerizer.rb:40: warning: already initialized constant Numerizer::BIG_PREFIXES

15:24:38 web.1  | /usr/local/lib/ruby/gems/2.2.0/gems/chronic-0.2.3/lib/numerizer/numerizer.rb:40: warning: previous definition of BIG_PREFIXES was here

They are just warnings, and they don’t actually interfere with the running of my app, even when i am using the parser functions (calling Tickle.parse), but those warnings still bug me. It’s enough to make you wonder how much effort it would be to just go into the gems and fix whatever the conflict is. Maybe submit a Pull Request. The problem seems to be trivial, but once you start mucking around in somebody else’s gem there are all kinds of potential unintended consequences, not to mention that I would have to make sure it passed their testing suite before I submitted the request.

For now, though it’s probably a higher priority to actually write the code that uses the gem before I start worrying about the error message produced by it. Add that to the list of tinker projects.

Posted in Uncategorized | Leave a comment

On Coffee Shop Tech Meetups

I got an email yesterday from a woman I met at a tech event who works for the Hillsborough County Chamber of Commerce that there was a tech meetup of some sort happening this morning. I’m an aspiring web developer, so tech meetups are the kind of thing I need to be on board with, so I get up early on a Friday to go. The meeting is in a coffee shop at a mall near the university before the mall technically opens, so one has to enter through a special entrance and be directed by mall personnel to the shop itself.

I enter the shop, buy a large regular coffee, and sit down in one of their plush armchairs to watch people start to come in for the meeting. As person after person, almost universally older, sharply dressed men, obviously businessmen and county bureaucrats, enter the coffee shop I slowly realize that I am the only actual techie at this tech meetup. As the eighth person stops to take a selfie standing in the coffee line with other business people, I become convinced of what I had already suspected: that this is not the place for me. As I stand up to leave, though I bump into an acquaintance from the coding community, blessedly wearing a “Browncoat” t-shirt. There were then two of us, the only people with facial hair in the room, and this gave me the strength to at least stay and try to network a while.

I am not good a hustling. I realize that this is, in many ways, a career handicap, but I am also unapologetic. If I had wanted to know how to hustle, I would not have dropped out of the UNF business school to change my economics major from a BBA to a BA back in, like, 2007. The other programmer is huge help though. He has an idea of whom to talk to, and we maneuver through the dark and stormy social currents together, as the programming block.

I hear somebody congratulate the organizer on the “great achievement” of getting such a large and diverse group of people together for this meeting at a coffee shop in the mall. And perhaps that’s the crux of the problem. The meeting is not happening in order to accomplish anything tangible. It is there for a PR opportunity. For businessmen to take coffee line selfies. And that explains the relatively low position of programmers on the tech totem pole. Engineers are by nature results oriented. Yet at an event like this, a question like “Fine, but what does any of this actually accomplish” is as unwelcome as someone spitting in a bowl of soup.

I think about this, and the relationship between people who actually produce tech and the people who have made their livings middle manning it, every time somebody we are conversing with pivots away from us the second someone more important walks by. We’re talking about bringing tech startups to North Tampa after all. Surely low level city bureaucrats are more vital to that process than techies.

But I am looking for a job after all, and the game is played how the game is played. And I do have a certain investment in this neighborhood that I have lived in for the last three years, and in which my family has lived since 1953. So, arming myself with my sheate of business cards, I go forth into the crowd.

Posted in Uncategorized | Leave a comment

“You’re coming on Wednesday, right? So there’s no need for goodbyes.”

Graduating from the Iron Yard yesterday feels like the end of an era. A very short era, since in the grand scheme of things 12 weeks is not that long. In subjective time, though, it seems like I have been learning with my classmates for and endless period. Yet I have been through this kind of intensive program, with its bonding experiences, before, and I know that one of the immutable rules of the universe is that good times will pass, no matter how much you might wish to hold on to them. Now there is sadness, but there will be more good times in the future. This sadness, too, will pass.

Posted in Uncategorized | Leave a comment

Construction and Tech Companies

This is the end of week 11 at The Iron Yard in St. Pete, and our entire academic experience has been characterized by ongoing (and very loud) construction to the building around us. This is because, like a good tech company, The Iron Yard moved into a neat old building downtown, but of course to have real tenants in a run-down old building you need to spend time and energy refurbishing it.

I had the opportunity this week to see a couple of these new Tampa Bay area tech spaces, from a Python meetup on Tuesday at the new Tampa Bay Wave space at, like Kennedy and Morgan, to a Ruby Brigade meetup in Carrollwood, to the downtown St. Pete building now hosting One Million Cups, and they all share that ongoing construction characteristic.

There’s a metaphor about the way that new tech disrupts and builds at the same time in there somewhere.

Posted in Uncategorized | Leave a comment

On replacing bookshelves

Last week I received a rather large book on learning Python (which I am working on in my spare time from The Iron Yard). Along with a huge book on CCNA routing I bought some time ago (on the advice of one of my sysadmin friends), my books on computers now account for almost a fourth of a bookshelf in very scarce space. To fit them in, I had to take a hard look at my bookshelves and decide what to replace. Do I want to get rid of a few fantasy series? Not really. Comics? Nope. My general histories or philosophy or literature? Well, any day now I might actually sit down and read one of those.

But my bookshelf full of academic Chinese histories? Dog-eared, notated, and full of sticky-notes as it is, am I really ever going to need to reference a passage in Rebecca Nedostup’s Superstitious Regimes? Or Guy Alito’s biography of Liang Shu-ming? They may have formed the inspiration for my Master’s Thesis on Feng Youlan, but I don’t suppose that I will ever need to reference that again either. So into storage they go, and the computer books replace them on their fourth of the academic histories shelf, a physical manifestation of the vagaries of my life and the way life evolves unexpectedly.

Still, I can’t help but wonder: what will be on that shelf five years from now?

Posted in Uncategorized | Leave a comment

The Cream Rises to the Top

I am pleased to announce that an alpha alpha (pre-alpha?) of my Iron Yard demo day app is currently live on Heroku here.

A couple of notes about it:

  1. All it does right now is take a roster of the user’s wrestlers and organize them based on card position and alignment, and then “generate card!” button creates a list of matches between random heel and face wrestlers at particular card positions (1 each for the Main Event and Undercard, 2 each for the High Card, Mid Card, and Low Card).
  2. Since an entire card is eight matches, this means that you need at least 16 wrestlers loaded into the app for the match generation to work properly. While you might have fun inventing that many wrestlers (and I certainly will for my demo day), if you want to see how the app works RIGHT NOW, I’ve created a user that has a random assortment of 30 wrestlers already. You may sign in as Ulrich User  with email “”  with password “ulrichuser”.
  3. The google oauth works, but I would suggest that you create an account with your real email first, and then sign in with the ouath, since the sign up page allows you to enter your name and the name of your wrestling promotion
  4. Alternatively, feel free to sign up with a fake email address as long as it is of the form The only drawback to this is that my password recovery *does* work, and *does* require a real email address to send to.
  5. Everything about the app is still a work in progress, but especially the front end CSS stuff. I know a lot of it is ugly, it is being worked on. Suggestions are super appreciated though.
  6. Don’t get too attached to anything you save only in the database; I’m probably going to have to introduce the database to little Bobby DROP_TABLES a few times before this is over.

In general, I welcome your questions, comments or concerns.

The source code is available at Github.

Posted in Uncategorized | Leave a comment

My Letter to Toptal

July 12th, 2015

Dear Toptal:

I am interested in working as Ruby developer for the Toptal web developers community precisely because I want to work with the best. Toptal appears to be a company created by software engineers for software engineers, and as such would hopefully value quality of work over the more malleable attributes valued in many more corporate companies. As someone devoted to producing high quality work, this appeals to me. Additionally, the job notice suggested that Toptal would allow me to work in pure Ruby, and I love to work in straight code, the more abstract the better.

As with any applicant to this position, I bring to bear a passion for programming, as well as an extensive practical knowledge of the Ruby programming language as well as the Rails framework. I am a recent graduate of the Ruby on Rails program at the Tampa/St.Petersburg campus of Iron Yard tech school where I wrote roughly 20 unique rails apps at various levels of complexity. Between my training at Iron Yard and previous experience as a computer hobbyist, I have also developed a working knowledge of common Internet technologies like HTML, CSS, SASS, AJAX, Jquery, MySql, Postgres, Github, and Heroku (along with OMG, LOL, and TL;DR). I am also comfortable writing Javascript code.

My real potential value to your company, however, lies precisely in the fact that my background is not in tech. In a former life I was a graduate student in Chinese History, with a Master’s degree in East Asian Languages and Cultures from Columbia University. As a result, I have extensive travel experience in East Asia, am fluent in Mandarin Chinese, and have tremendous experience as a writer and speaker. Additionally, I am a Florida native that grew up outside of the tech communities of California or the Northeast Coast. For your company this means that in addition to being an excellent developer, I have the ability to better communicate with customers than many other developers, and further that I will able to consistently approach problem solving in a different way than many who have spent their lives in tech. Between these two sets of skills, I believe that I would be an ideal choice to work for your company.

I am enthusiastic for the opportunity to work for your agency, and look forward to hearing from you. I also thank you for considering my application.


Michael Earl Nash

Posted in Uncategorized | Leave a comment