CSC295.02 2013S, Class 13: Wes Beary '05 Overview: Admin: --- Short bio Lived with parents trying to kickstart a video game career. Then tech support, then lots of other stuff. Had a growing commitment to open source. Speaks, writes, and has developed enough a reputation to leverage it for careers. "Call me Wes or Wesley, even though I go be geemus online." --- College * Came to Grinnell as someone expecting to be a CS major * Took lots of courses * Taught himself C++ before coming * Interested in gaming * Landed internship at GarageGames (they made Tribes and Tribes2) * They were licensing their game engine * Ended up creating a Real Time Strategy (RTS) kit (Perspective looking down on troops or whatever) (Units have some autonomy) * No pay, but housing and some royalties (about $100/month for three years), then sold it back to them as a pittance * Worked as TC, too Post College * And he had experience building more game packs so he hoped to do more of that * Assumed that he could leverage his experience with GarageGames to get more stuff * But ended up working at Hunter Technology, a tech support place near home (relatively small place) * Still trying to do game development in his free time, but wasn't as established as he thought he was (it's a *very* competitive industry) * Then on to Quiktron (still in the same town) - a custom fiber and copper wiring company - once again, doing tech support (building on college experience) * Tech support is a lot like fire fighting - if you have a good fire marshall, you don't need to do a lot of firefighting. (And so, as a tech support person, you may not have a lot of work to do.) * Offered to build something to improve workflow. Told no, but built it himself for the learning the experience. Used Ruby on Rails, just when Rails was starting to come to prominance to him. * Built sales app that was useful. * They called him a software engineer, gave him a raise, let him write his own job description. * After 6-9 months, he'd written most of the stuff he could write for them. Got bored. Offered to provide continuing support. * Then on to Principal Financial Group - Also did some rails interning and consulting. Rails was new enough that he could still make contributions. * Chose the job because it paid a lot more, had more benefits, and let him move to another city. * But he was not a good fit to corporate culture. * Recurring theme: Job wasn't deep enough, so side projects kept him happy about programming. * Then on to ImThere. Startup in St. Louis. Idea of sharing things based on physical location. Also able to chat with other folks at the location. Good idea, but everyone was relatively inexperienced. And then they ran out of money (after sending folks to SF). * So, consulting job at LiveJournal attempting to filter the firehose of updates. (Learned that his work ethic was very different than his colleagues) * But the person who hired them started his own place started Plinky * Plinky is a place that inspired you to write 'blog posts and help you to write better ones. * Your post ended up on Plinky (lots of options for automatic cross-linking) as well as back on your main 'blog. * Plinky Needed a team to kick the company off. Hired them as a team (not realizing that they were disfunctional). Company founder figured out what as happening, and hired Wes as first employee (first engineer) and fired the rest. * Wes got to architect system and made decisions about underlying technologies. He chose CouchDb, Merb, and Datamapper * CouchDB - A NoSQL database * We made decision to write a common interface to all of the 'blog technologies, rather than leveraging existing APIs. * Didn't launch to big enough splash * Company name changed to Thing Labs * Thought about new ways to use the things they had developed * They hired VP of Engineering who brought in a Twitter Client in the Browser (written in Python) * Wes had built a reputation in the Ruby community, and thought that he'd be better off elsewhere. (AOL bought them few years later and if he had stayed he would have been a millionaire) * On to EngineYard * Cloud platform for Ruby on Rails * Very active in the Ruby community. Sponsored people to work in open source. * But internally much different than their public persona. * Either you got hired as someone to work in open source, or as a regular engineer. If you're in as an engineer, you can't switch. * Got hired in the middle of a death march. And they were doing the death march on code attached ot a prototype, rather than rewritten from scratch. * Continued in his "fantasy world" of doing side projects. * Cloud computing was early enough and Ruby was early enough that there weren't good tools. (In fact, they were relying on a competitor to develop the tool that they used.) Wrote interface for Amazon SimpleDB, then S3, then EC2, ... * Then RackSpace Cloud launched. And he wrote an interface for that. * Hmmm ... two different interfaces, lots of time doing a context switch. * So he decided to create yet another layer of abstraction so that you could interoperate with them. * He's not sure how much this is useful for the computing side - on that side, it's sometimes important to get down to the nitty gritty * But on the storage space, things work pretty well * Remember: He wasn't hired to work on fog (or any open source); this was kind of a side project, but related to what he was doing * fog had many other services, such as mocking servers - gave you the opportunity to do testing before you got on to the servers * Colleagues weren't enthusiastic about using it * So any time he found bugs that related to the libraries he used, he switched those calls to calls to the fog libraries. * We wasn't happy. Planned to leave. Circumstances led them to say "What would it take to keep you there." He said "I want to work on fog full time." * But the fact that they were going to change what he was going to do didn't change the culture of the company. * Still, he loved fog and wanted to increase usage. Amazingly, that meant that he did less coding - more documentation, more evangalization, ... * About 1.5 years in that position. * He still works on fog, but mostly in a project management role * Started getting really involved in the conference scene - that opened a ton of doors and making great connections * And on to Heroku * Another Cloud Computing / Ruby service * Heroku was much quieter in how they talked about themselves, but at least it seemed more accurate * Heroku was interested in recruiting him; he invented his own job ("I want to work on the command line tools") - whoops that was probably a bad idea. * Having a role that no one was prepared for is awkward * Wasn't clear who had authority on his code * Change was hard * Then his boss left (back to normal coding) * "Go find another team and another manager", preferably this week * "What happens to my project?" Guess what, it's being put in "bug fix only" mode * Moved on to API team (rather than infrastructure team) * Big Rails Legacy API (these days Sinatra is much better) [Side note from Sam: http://www.sinatrarb.com/] * The project had been built somewhat organically - whenever a team needed something, they opened up the project, added something, and then closed it again. * He decided to champion a new API project that they could ship to everyone * And his boss had his back * And he's transitioned more to project management. He does high level design and they implement. * Current side project - lots of random R&D ("this is of interest to me so I'll write a program about it") * He has a github repository called prototypes - easily accessible * Dumps most of his stuff into public repositories * Wes doesn't read articles and take notes, he reads articles and writes code :-) Lessons (from/for Wes): * Avoid * non-tech focus * clock-punching * Seek * open source - great experiences, meet great people, great for his career (last few jobs the resume was an after-the-fact thing - "we've seen your github page; you're good") * flexibility - set location, hours, priorities * trust * responsibility - goes with trust and flexibility; downside is that you're on call Some Lessons [as interpreted by SamR] * Prototypes are great. But throw them away once you decide to bulid the project and architect more carefully. * Try to build a reputation in a community. (How?) * Side projects keep you interested! * Learn to advocate for yourself * Software does not win by merits alone - You have to build a community and evangalize * Through open source, you can build all sorts of relationships, no matter where you are. * In open source, don't fix your own bugs - mentor someone else to fix your bugs. (Most people are quite willing to fix the bugs they've encountered if you give them some guidance.) * Send t-shirts to your contributors :-) * Don't name things "Core" or the name of your company - that's where all the random stuff gets thrown. * Learn to use language that people understand * "Ask for forgiveness, not permission" sometimes works and sometimes doesn't. * In the startup world, there's not a lot of stigma attached to jumping around jobs. Questions * What ever happened to games? * You need a lot of people to connect with - Don't do it in the middle of Iowa :-) * At the time he was trying, you really needed a multi-million dollar budget (as compared to the PhoneApp culture of today) * And the legendary "EA Wife" letters * And, in the end, it probably wouldn't have been good for him at the time * The desire didn't go away - He's still building board games * How do you teach yourself something new? Do you go to the documentation, or to books, or ...? * "I read other people's source code all the time" - E.g., when writing an http livrary, read through the Ruby core, some Python libraries, etc. Particularly useful for edges and corners * Also reads RFCs and other related things * Rails was fresh when you started. What's something that's similarly fresh? * "I'm still a pretty big fan of Ruby" * Remember that Java's great contribution to the world is not Java itself, but the JVM. So maybe Scala or Clojure. * Come people are really excited about Node.js. * [Sam asks about CoffeeScript, a syntax that compiles to JavaScript] Javascript is high level, but it's kind of like assembly in that there are lots of strange gotchas. CoffeeScript inserts those. * [JDS asks about Mozilla's Rust programming language] * Lots of people are excited about Go. (But there's selection bias - colleagues at Hiroku are really excited about it) * Erlang * How did you move into project manager and how does that go? * He doesn't like meetings. (N people x M hours is NxM people hours) * More external constraints - How do you distribute work, how do you know how well you're doing, ... * [Boy, Wes really doesn't like f2f meetings.] * Challenge of different time zones and different times of days * Personally, he could not have vertically scaled any more, so he makes a better contribution by horizontally scaling * How common is the "jump around" resume among your coworkers? * A decent number of people fit into the right startup more quickly than he did. * But it varies * And sense of farm team vs. major league * Jumping around is how you pay your dues * You mentioned your need to have a creative contribution in your coding. How do the people who get to implement your high-level design get to do so some creative stuff? * When working with people he tries being more open ended: "I think you might try this ... what do you think?" Not just "do this". * "This isn't what I want you to implement, this is what I want you to give me feedback on." * Don't declare, inquire * Where does "geemus" come from? * A mispronunciation of "genius" * He chose something that had a personal meaning that was available in a lot of places * Good style of presentation. How did you learn it? * He's using markdown and JSON with showoff * Building a reputation in a community - you mentioned it first in Thing Labs, but clearly stuff was happening before. Tell us more. * How did you end up at ImThere