don’t hire me to build stuff for you. i’m more in it for the money than for the vision you have. i will do the least amount of work acceptable to get my pay. i won’t write tests if i don’t need to. i will push back when i’m told to make a change to a feature even if it’s obviously necessary.

if text needs to be changed, i will bitch and moan that it wasn’t in the spec and that it’s taking time away from ‘development’. if you want to add an extra text field to edit a property, i’ll bitch and moan about that too. i will try to do as little work as possible and try to squeeze as much money as i can out of you because honestly, the stuff i’m doing for you is not worth my time and the trouble is not worth the money you’re paying me.

instead, find someone that is just as excited or more excited about the vision you share. someone that cares so much about the product you’re building together that he’ll be ok with acting as a sounding board at 3 a.m., rebuilding things when you inevitably change your mind two or three times, or hopping online in the middle of the night in order to fix a bug. find someone that believes in your shared vision so much that he’s willing to work for little to no pay (relatively). find someone that will finish a feature, step back, and be proud of what he’s written because all of his passion, hope, and dreams are going into that code.

find someone that will stay with you for the long haul rather than peace out after receiving the paycheck. find someone that will be the constant thread throughout the development of your product because transitioning codebases to another team will often cost you just as much as building a new feature. and goddamn it, set reasonable deadlines.

grumpy freelancer


I’ve read a ton of commentary on the series finale of Breaking Bad over the past 24 hours, both praising and haranguing the final plot choices of AMC’s darling drama. There are numerous great write-ups by fantastic fans about all the implications and the beautifully wrapped up story-lines woven by Gilligan et al. Go ahead and go read those easily found via a Google search or by checking Twitter; I’m not really here to argue whether or not it was good or bad. To be honest, I couldn’t have cared less what happened to the survivors of Gilligan’s modern take on a Shakespearean morality play, because after the final conversation between Skyler and Walter, I hardly cared. I was already happy after Walter said those lines:

"I liked it. I was good at it. It made me feel alive.” 

Read More


I’ve been thinking a lot lately about what I strive for in my own code, what I respect in that of my colleagues, and what I look for from potential intern candidates. I can’t say I know very much about programming or have very much experience in the field, as I’ve only been coding since May of last year. So, knowing next to nothing about programming, two qualities I truly value in my current stage of development are simplicity and precision.

On Simplicity: 

One of the most frustrating things as a developer is to inherit code that requires line-by-line reading or, worse yet, a verbal explanation from its creator on how the method in question works. The more I write code, the more I notice that a lot of programming consists of repetition and reorganizing of standard practices. More often than not, there is no need to reinvent the wheel; the majority of problems can be solved with a very basic understanding of the library.

An hour spent trying to find your footing in someone else’s code is an hour lost getting a new feature deployed. I respect those that can write stable, well-tested code using simple and well-known methods. There’s usually no need to bust out an obscure method from the depths of the Ruby library. It really should be absolutely necessary (or easy to understand after RTFMing), otherwise you’ll end up wasting the time of the next person that comes along to look at that line.

On a similar note, I have related qualms about meta-programming, which is all the rage among RoR developers as it is so easy to do. There’s a time and a place for it, but don’t get all meta for the sake of showing the rest of your team how slick you can get. You’ll just end up causing headaches for whoever has to build a feature related to that method in the future.

On Precision:

Oh man, do I love a programmer that can go in and solve a problem with a few lines of code. I like hackers that think like surgeons, who treat their code like a scalpel. Coding really is about finding the perfect tool, the perfect combination of callbacks and methods and solving a problem in a clear and concise manner without any collateral.

TL;DR I suck at coding so stop fucking confusing me.



Alex poked fun at me today about how hard it is for her to keep track of the sheer number of test accounts I have riddled in production. The fact of the matter is that I really love playing with features that the Artsicle team has built. As we continue to iterate on Artsicle, it’s fascinating to me how there can be so many different types of users, from a casual that may only sign in once a month to the power user who is constantly curating his collection and getting deep into features that most users may never even stumble upon.

To me, playing with these accounts a few steps removed from the code accomplishes a number of things (aside from the obvious debugging of production code). 

  • It reminds me of the types of users that we may have. It reminds me that I should always prioritize keeping features easy to use but also find ways to make these features exciting and enticing to master for those who truly want to engage.
  • On a more selfish note, it reminds me how far I’ve come. Back in February, Scott’s first assignment to me was to figure out how to allow an artist to choose his/her default artwork — the one that would be shown first and represent an artist’s style and body of work.
    I spent almost a whole week learning how to write the code and spent nearly another week banging my head against how to write a simple javascript response to show a little Artsicle teal checkmark in the top-right corner of the designated artwork. What literally constituted maybe less than fifty lines of code took two weeks and was broken in a number of ways upon shipping.
    It’s the most satisfying feeling to sign into jenniferlawrence@artsicle.com and click a few buttons and say “holy shit. i built this. and it still works.”
  • It reminds me of how much more there is to do. I’m immediately inundated upon signing in with ideas about how to improve a minor feature. It’s refreshing and invigorating to ship something that you may have agonized over for weeks and to come back months later with a clear picture of ways to improve.
  • Finally, it’s really fun to interact with your user-base. I built the barebones of a messaging system for our artists a few months back, mostly for inquiries about their artwork, potential commissions, or even just general encouragement. We’re only now slowly rolling out ArtsicleOpen accounts to artists and we already have some incredible new artwork being posted on our site. It’s pretty cool to drop by and say how much I like a particular Argentinean’s art and have him respond with so much appreciation for… my appreciation (or maybe he was just happy to get a message from Jesse Pinkman?). It’s just great to put a face in front of the rather amorphous conception of our ideal user so I know who I’m building awesome new things for every day.

Michael: (to George Michael) I’m gonna give you a promotion. Welcome aboard, Mr. Manager.
George Michael: Wow! I’m Mr. Manager!
Michael: Well, manager. We just say manager. And you can hire an employee if you need one.
George Michael: Do you think I need one?
Michael: Don’t look at me, Mr. Manager.
George Michael: Right. It’s up to me now. I’m Mr. Manager.
Michael: Manager. We just say, uh —
George Michael: I know, but you just said —
Michael: Doesn’t matter who


As I learn more and develop more skills, I’ve become incredibly passionate about my work at the computer. I guess it’s symptomatic of working with as small a team as Artsicle, where nearly any input I may have about our product more often than not finds its way into the app in some way, shape, or form. So as more of my ideas or suggestions come to fruition in production, I’m finding myself getting sucked in more and more, almost feeling insulted when my code comes out with flaws, css doesn’t cooperate with me, or if I leave work with a bug unsolved overnight.

Team trackers are great to keep everyone organized and from stepping on each others toes (merge conflicts can once in a while be a huge headache). They also can help light a fire under the dev team’s ass during a tough push week; no one wants to be the weak link. However, as the past weeks have sometimes found me in huge holes poking around in the depths of someone else’s ruby gem for days on end, it’s been hard not to feel guilty that I’m not squashing bugs left and right and delivering tons of stories to the tracker like my teammates.

Things I have to be more mature about:

  • No one’s judging (hopefully): As long as you’re competent, bring a different skillset to the team, and don’t step on anyone else’s toes, no one really gives a shit how many hours you’re in the office (within reason).
  • Stop comparing my volume of work to others: Everyone is working on different problems and sometimes a deep hole can take days to dig yourself out of, but solving said bug may be a huge windfall for the stability and functionality of the product. Don’t feel bad if you spend days trying to find the right place to put one extra conditional, when your teammates are kicking ass on front-end and pushing multiple stories a day.
  • Welcome to Whose Commit Is It Anyway? The Management Tool Where Everything’s Made Up and the Points Don’t Matter: Our generation is one that loves their internet presence, gamification, and internet points. It’s really easy to read into the nonsense that is the points that you assign a story, or the number of commits that were pulled into the central repository that day. No one gives a shit as long as long as your code is solid.
  • Resistance is Futile: Sometimes when you just don’t get it, you just don’t get it. Step away. Take a breath. Play with puppies. Sleep. We sometimes make substance abuse analogies to programming. When you’re in that deep hole at 9 p.m. and you’re absolutely burnt out, there’s a need to keep slogging through it, even though you most likely aren’t thinking clearly at that point. That reward of solving a problem at the end of a long day is so gratifying that the urge to get that fix can sometimes end up destroying you for the rest of the week.
  • Marathon, Not a Sprint: I think we, as startup people, are all on our own self-destruct timers. We are so passionate about our work that it’s hard to step away. Things that bother us can end up taking over our lives for the day, week, or month. When explaining my reason for leaving jazz, I used to cite the fact that a regular day job was way more relaxing because you could step away from it at the end of the day, whereas jazz was a constant pursuit eating away at you in the back of your head. The fact is that if you’re passionate about your product (and you should be; if you’re not, you’re working on the wrong thing), then it consumes your thoughts. I need to continue focusing on being healthy, happy, and refreshed (and slightly overcaffeinated), every time I step into the office to setup my laptop on my desk.

Up until the past month, I constantly wanted to “get better” at coding. I didn’t know how, I didn’t know exactly what, but I just knew that I wanted to get better. I felt slow. I felt like I didn’t know enough. I often felt overwhelmed by the problems that were presented in front of me. It seemed like “getting better” would solve those problems; would make me a better programmer; would make me more valuable to my co-workers and friends.

Rather unfortunately, the concept of “getting better” waved a lofty, and rather ephemeral goal above me. It was utterly discouraging to me and was becoming an increasingly unhealthy obsession as I didn’t know where exactly “getting better” started and ended.

"Rome wasn’t built in a day", and as cliche as that sounds it’s absolutely imperative to keep in mind when trying to improve something that is as taxing and difficult as programming. I realized recently that just like I did when cycling, I needed to set checkpoints that I could see and immediately gain gratification from. However, the philosophy of "getting better" doesn’t really lend itself to concrete goals.

Lately, it’s all about doing less stupid shit. Doing less stupid shit meant constantly reassessing my weaknesses and focusing on eliminating them one at a time. Keeping a checklist of my past mistakes in my head, doing less stupid shit made me feel better about myself as I checked each stupid action of the list. Sooner rather than later, these minute details added up and made me more efficient.

Lately, my focuses have been:

  • to write fast tests with great coverage
  • to DRY up my code and be more surgical when solving problems and refactoring
  • to constantly be researching for better tools (scalpels vs. hammers)

I feel more calm lately. I know I have a long way to go before becoming the engineer I want to be, but I also know I’ve come a long way from the guy that was doing a ton of stupid shit a year ago.


The Internet Will Not Ruin College (Salon)

"Education, I’d argue, has always been the most likely sector of society to get transformed by the Internet, because the thing the Internet does better than anything else is distribute information. Distribution is not synonymous with learning, of course, but how could anyone argue against the premise that our ability to educate ourselves, on just about any topic, has vastly expanded in tune with the maturation of a global network of computers? It’s kind of amazing that it’s taken this long to start figuring out how to offer truly high-quality college level courses over the Web — isn’t this exactly what the damn thing is for?”


It’s fascinating to me how often the unemployment rate of my age group is cited in the news. And while I can understand that it is a big deal and a fairly reasonable indicator of the health of our economy, I often wonder if we, as a whole, are too focused on the numbers and not focused on the larger implications around unemployment among post-grads.

My parents were the first of my family to arrive in the United States. Where my parents and my friends’ parents experienced the alienation and struggle of carving out new lives in an entirely foreign country, we reaped the benefits of their struggles with our pampered and structured lives. Early on, we were asked (or in some cases, told) what we wanted to be by our parents, who promptly provided the financial support necessary to reach our goals. While we lived very comfortably, we were set down a straight and narrow path, often not given any room for exploration.

Read More


 As any cyclist that spends long hours alone on the road knows, my time spent on the saddle takes my mind to weird places. These places are more often than not the best places for introspection and problem solving. As race season nears and with programming now a priority in my life, my thoughts on the road have been a bizarre amalgamation of applications I’ve been trying to debug and cycling thoughts. While it may seem weird to associate programming with the struggle of cycling, there is a certain similarity between the two endeavors.

Read More