Starting Again

posted on 2014-11-30 21:20:00

A Fresh Start

I've been struggling a lot this year. I got stuck in a hole and it took me a while to find my way out. But I learned a few things along the way and I'm very excited about what's coming next.

I've accepted a job as a Ruby on Rails instructor at The Iron Yard. I'll be training people to become engineers in a very short timespan. For over a year, I've been whispering now and then about an interest in teaching, to Norma and friends. Starting January 5th, I'll have my first students. I'm equal parts nervous and exhilarated. I can't wait.

Learning How to Quit

A lot of my happiness and self-worth is tied up in making visible progress on things I care about. Over the past 10 months I lost faith in what I was doing at work and enthusiasm for my personal projects. Rather than recognizing that I should find a job I was passionate about or spend time on projects that excited me, I dug my heels in. No longer.

At one point, I said a Nintendo emulator was my forever project. I'd still like to see it taken further but I'm not going to work on that now. Belligerently sticking to those guns has been limiting my own potential. The only purpose of personal projects is to learn and to grow. They are mine and no one else's.

So until further notice, the emulator is on the backburner. Coleslaw will still get maintenance work but probably not much feature development. There are new things I'm fired up about and my focus will be on deriving as much momentum from them as possible.

Going Forward

I'm playing with Renoise and trying to pick up some music theory. I'm still not really making songs but I'll get there. I'm continuing to learn melee and now that I have a real training regiment in place I'm seeing much faster improvement. Hopefully I'll make it out to local tournaments every now and then.

I want to become more structured about practice. That includes starting to chip away at the stacks of CS and programming books I own that I haven't gotten around to reading. And experimenting with new tools like Ocaml, OpenMirage, and Ansible. And making room for play where nothing gets done.

I need to learn how to love and care for myself in spite of how much I get done, in spite of visible progress made or unmade. Part of that is going to be taking back my online presence, away from the more cultivated space of the last few years. There's a lot I want to accomplish over the next year or so. I'm sure plenty of what I learn won't be according to plan. But it's time to get going. It's time get organized. It's time to dig in.

Strangeloop Thoughts, 2014 Edition

posted on 2014-09-24 16:05:00

Why do Programming?

After going to Strangeloop for the first time in 2012, I was really fired up about programming. I'd only been out of school a year and was already a full-remote Clojure developer making a great salary. Even better, I had made good progress on my lisp emulation project and received some recognition from hackers I respected for it.

The last two years Strangeloop has been a lot more sobering. I told myself things in 2012 about how fast I'd get better and how good I'd be. Even though my expectations were unreasonable it's taken a long time to not feel bad about my (relative lack of) progress. I've been slow to accept the fact that I don't want to fight my way to being the best in my field.

Strangeloop, 2014

I got in Tuesday night, dropped my bags at the hotel, and immediately ran off to drinks and phenomenal conversation at the Schlafly Tap Room. Many of the best experiences I've had at Strangeloop have been at the tap room. Sure there is excellent food, beer, and technical conversation, but I've always gotten a sense of personal acceptance at gatherings there. Strangeloop is certainly a welcoming crowd.

Wednesday was a blast as well, as any day with a trip to the STL City Museum should be, but more and more I found I cared about personal interactions more than the content of the talks I attended.

By the end of Thursday, I was stressed out. I wasn't even excited about the talks, which isn't to say they weren't good. I hated the idea that I was just an average programmer, that I didn't aspire to more than hacking bog-standard Rails apps as a career, that I'd spent almost $2000 out of my own pocket to come to a conference that someone else might have gotten more out of. I went to bed early that night.

I kept my mindset in check much better on Friday. I reminded myself to be excited about others discoveries and creations, not to demand myself learn every tool or technique. The conference wrapped up well and I particularly enjoyed some of the Distributed Systems talks, a subfield I still have no experience with. Not to say I want to go fight distributed heisenbugs soon or design highly reliable systems. The talks were quite entertaining and informative is all.

Back Home

The main takeaways I've had from Strangeloop have nothing to do with tech and everything to do with me. Strangeloop has, in many ways, been a time for me to reflect these last two years. I'm not sure that's a good way to use the conference but it seems to be what I've done.

The first takeaway that comes to mind is that I need to try and respect myself for just being a decent Rails developer. I'm not great at solving algorithmically tricky problems and my CS background is, frankly, pretty damn weak. But no matter what I shouldn't beat up on myself for being "just a programmer". I need to put in an honest day's work and actually pat myself on the back at the end of it.

The second takeaway is that I need to program for me again. I got into programming mostly because I wanted to know more about how computers work. The emulator and talks surrounding it, some of my favorite work, is really more an investigation than artifact. I still want to support coleslaw. It actually has a few satisfied users and I'm one of them. But the only real purpose of the emulator is to sate my curiosity. Not to become a real thing or be special or groundbreaking.

There is plenty I'm still digesting and plenty I'm still not sure of, both technically and in terms of what I want for myself, my career, my life. But I'll leave that for another day. Cheers.

On Inaction

posted on 2013-03-04 16:28:00

Seeing Value

I've been experiencing the Dunning-Kruger effect a lot lately. At least, I've been feeling like a fraud. And while I could list reasons I'm not a great programmer, asking why I felt like a fraud has led me to something more interesting. I don't think I've worked at a company where I knew "where the money is coming from". What does that mean exactly?

• I haven't worked for a company whose revenue comes from a product I use or want to use.
• I haven't worked for a company in an "obvious" growth market.
• The software I write generates revenue indirectly through customers I never interact with.

All of this creates a surprising problem for me: The value I add is opaque from my perspective. I take it on the word of my superiors and peers that any value is present. This makes it essential that I trust and enjoy working with those people.

The Mythical Customer

It might not be immediately apparent why this is a problem. Find a company with decent people and culture and you don't need to be directly connected to the product or customers. Just churn out code and have fun. Advertisers will foot the bill. While it's true that you can sustain a business this way it certainly isn't ideal. The issue comes from just how decoupled the product becomes from the revenue. When it's time to grow revenue, you have to do it by attracting more eyeballs. Here's how that works:

1. A Product Manager decides on new features or a UI overhaul to increase site traffic.
2. Programmers implement those features with small tweaks and adjustments.
3. The changes are released and traffic is measured for an increase. A good shop will use A/B testing to try and at least ground these decisions in data.
4. Improved numbers are sent to advertisers to garner more customers and/or revenue.

But Product Managers are not users. Programmers are not users. Advertisers are not users. Sure, we use the product some to verify the code works during testing but we're not invested in it. A/B testing is not the same as user input. There is also no requirement that you correlate traffic with actual perceived value. Many companies just read traffic AS perceived value. Frankly, that's bullshit. Our loyalty is necessarily to the advertisers. They pay us...but the users are the real customers. The product just happens to be paid for by collecting data about how they use it.

So What?

Thus far, none of this should surprise anyone who has worked in the tech industry. Hell, this shouldn't surprise anyone with a Facebook account. It points however to a serious cultural problem in many tech companies: not letting (or demanding) your technical experts be, well, technical experts. A friend of mine calls this "{} for $". Many people rant about this as "Taylorism in software". It cannot be overstated that no programming paradigm nor software engineering methodology will eliminate the need to connect engineers to the product. Similarly, letting the engineers take the reigns is not anathema to good product design or improved value to the business. And this is not new. Quoth Don Eastwood in a 1972 Status Report on MIT's Incompatible Timesharing System:

"In general, the ITS system can be said to have been designer implemented and user designed. The problem of unrealistic software design is greatly diminished when the designer is the implementor. The implementor's ease in programming and pride in the result is increased when he, in an essential sense, is the designer. Features are less likely to turn out to be of low utility if users are their designers and they are less likely to be difficult to use if their designers are their users."

Earlier in the report, Eastwood says, The system has been incrementally developed almost continuously since its inception. Hello, agile kids. I'll say it again. Any company pretending that software engineering methodology or a given technology replaces the need to connect engineers with what they're building deserves to be skewered. The reason knowing "where the money is coming from" is so essential is that software is different than any other product in history. Because the design in a fundamental sense is the product. If you don't know what I'm talking about, I'd encourage you to watch Glenn Vanderburg's talk from RailsConf 2011. If your engineers don't understand the reason for what they're building, then the product can at best accidentally support the business. If you think you or your company can just scrape by for your whole career without getting eaten, I'd encourage you to reevaluate that assumption.

Finding Alternatives

One big reason most companies are hierarchies more concerned with maintaining market position than creating value is the inherent risk. Real growth comes from bets and empowering people to change what's needed to find "a better way" or "The Right Thing"...and that's terrifying. Few individuals or institutions have the guts, bravery, and stamina for continuous reinvention. It's exhausting. Not to mention that it puts the focus squarely on a company's employees. It seems our best chance at winning big comes from those kinds of risks though. Github and Valve's experiments in distributed management are a brilliant step in this direction.

In the Interim

A lot of what has had me feeling like a fraud is remembering how much I have to learn. Learning is a kind of reinvention itself though and one of the reasons I've loved computers since the beginning. So I'll keep learning and next time I'm in a programming interview, I look forward to asking the other hackers, Do you know where the money is coming from?

This blog covers 2015, Books, Butler, C, Dad, Discrete Math, Displays, Education, Erlang, Essay, Gaming, Gapingvoid, HTDP, Hardware, IP Law, LISP, Lecture, Lessig, Linkpost, Linux, Lists, MPAA, Milosz, Music, Neruda, Open Source, Operating Systems, Personal, Pics, Poetry, Programming, Programming Languages, Project Euler, Quotes, Reddit, SICP, Self-Learning, Uncategorized, Webcomic, XKCD, Xmas, \"Real World\", adulthood, apple, career, careers, choices, clones, coleslaw, consumption, creation, emulation, fqa, games, goals, haltandcatchfire, heroes, injustice, ironyard, linux, lisp, lists, math, melee, metapost, milosz, music, pandemic, personal, poetry, productivity, professional, programming, ragequit, recreation, reflection, research, rip, strangeloop, vacation, work, year-in-review

View content from 2024-09, 2024-06, 2024-03, 2024-01, 2023-12, 2023-07, 2023-02, 2022-12, 2022-06, 2022-04, 2022-03, 2022-01, 2021-12, 2021-08, 2021-03, 2020-04, 2020-02, 2020-01, 2018-08, 2018-07, 2017-09, 2017-07, 2015-09, 2015-05, 2015-03, 2015-02, 2015-01, 2014-11, 2014-09, 2014-07, 2014-05, 2014-01, 2013-10, 2013-09, 2013-07, 2013-06, 2013-05, 2013-04, 2013-03, 2013-01, 2012-12, 2012-10, 2012-09, 2012-08, 2012-06, 2012-05, 2012-04, 2012-03, 2012-01, 2011-10, 2011-09, 2011-08, 2011-07, 2011-06, 2011-05, 2011-04, 2011-02, 2011-01, 2010-11, 2010-10, 2010-09, 2010-08, 2010-07, 2010-05, 2010-04, 2010-03, 2010-02, 2010-01, 2009-12, 2009-11, 2009-10, 2009-09, 2009-08, 2009-07, 2009-06, 2009-05, 2009-04, 2009-03, 2009-02, 2009-01, 2008-12, 2008-11, 2008-10, 2008-09, 2008-08, 2008-07, 2008-06, 2008-05, 2008-04, 2008-03, 2008-02, 2008-01, 2007-12, 2007-11, 2007-10, 2007-09, 2007-08, 2007-07, 2007-06, 2007-05