Month: July 2010
More jobs – this time in San Francisco. We recently invested in Triggit – my partner Seth blogged about our investment and the rise of real time bidding platforms and we put up a post about Triggit on the Foundry Group blog.
Triggit is one of a group of recently emerging companies called demand side platforms (DSP) that provide technology to advertisers enabling them to buy display media across millions of websites. Triggit specializes in using a technology called real time bidding where they bid on and run the ads you see in real time as you move across the web. In the milliseconds that it takes your browser to request a new website, Triggit is looking at your ad impression for its customers and determining how much you are worth, what ad to serve, submitting a bid and tracking the results. Even more interestingly they do this billions of times a day around the world.
Needless to say the technology sitting inside Triggit is what engineers would call a nice hard problem. How do you build and operate a system that makes complex decisions in less then 50 milliseconds with a global QPS soon to be measured in the hundreds of thousands? If you are the sort of engineer that gets excited by this type of scale and latency then Triggit is hiring. They are looking for engineers with experience building large-scale, distributed systems in C / C++, data guys and gals familiar with the Hadoop eco-system and a Rails programmer. Bonus points if there are copies of W. Richard Stevens books under your pillow. If this sounds interesting you can apply to jobs@triggit.com or visit Triggit’s website to learn more.
One of my favorite things about the month I spent each year in Homer is reading. We don’t have a TV here and, other than going out to dinner for some extra fresh halibut, Amy and I end up spending almost every evening at home reading, writing, or knitting (well – she knits). I usually consume about a book a day (a few take me two days – so it ends up being five a week, or about twenty over the month.)
Today’s book was Grumby by Andy Kessler. And it was just fucking awesome. On July 1st Andy sent me an email with the following description of the book.
“its a very funny novel set in Silicon Valley (and Wall Street), about a hacker that creates the next great consumer electronics device (believe me, you’ll want one) and then the rollercoaster ride of getting screwed by VCs, hacked, the deluge of orders, Chinese manufacturing, privacy issues and going public amongst the chaos of competition and rivalries. the technology is its own character, eyes, ears, voice and face recognition, GPS, spy software and a wise-ass personality.”
I don’t know Andy very well, although we met last year at Defrag (he was the opening speaker) and our paths have crossed a few times. I’ve read all his books and am a huge fan so rather than wait for him to send me a pre-publication copy, I just went online and spent $7.96 on the Kindle version which is available now.
Andy pretty much nails every aspect of the rise and fall of a garage startup in Silicon Valley. His fiction is great – it’s fast paced (thanks to many short chapters), full of dialogue and great characters, and lots of startup / entrepreneurship / Silicon Valley cliches. He spares no one and there were many times where I cringed in remembrance of something that hit a little too close to home. Way to go Andy – you nailed it.
If you are a fan of my mom’s art (Cecelia Feld), she’s part of an exhibit at the St. Julien Hotel in Boulder called Splash. The opening is this Wednesday July 7th from 6pm to 8pm. I won’t be there as Amy and I are hiding in Homer, Alaska for the month, but my mom is coming down from Keystone and I know she’d love to see my friends if you are around. It’s a real exhibit opening, so there will be food and wine for anyone that shows up!
The Feld job board has one for you today. If you are a sys admin and live in the Boulder area, StillSecure is interested in talking to you. The spec is below – if you fit it and are interested, please email Rhonda Grosz.
StillSecure, a network security software and services company is looking for a Systems Administrator for their Superior, CO office. We are looking for self-motivated, talented individuals who enjoy working in a fast paced environment. This individual will be responsible for managing, maintaining the IT infrastructure of the company and has at least 4 years of experience. He/she should be proficient in Microsoft Exchange, Microsoft Windows Desktop and Server operating systems. Networking, Linux and Mac OS experience is a plus.
This just makes me want to crawl under my desk and cry for a while. Can you imagine how much it would hurt if you threw that at a lawyer or an accountant and actually hit them with it?
Skadden Partner Completes 409A Handbook: “
Regina Olshan
Erica Schohn
Flashback: Regina Organizes Push for 409A Extension”
(Via 409A Dismay.)
More from our friends Nate and Natty at Everlater – this time on debugging.
One of the most important techniques we used when learning how to code is debugging. It allowed us to do two things: fix our own code when it was broken and parse through others’ code to better understand how they were doing things.
From a backend perspective, debugging is essential. When I first started writing code, I would write what I *thought* was the correct way to do it. Ninty-nine times out of a hundred I was wrong and the code would blow up with some ugly exception that I had no clue about. Copying and pasting the exception into google got me decent mileage, but the real silver bullet I discovered was just start from the beginning of the method and step through it using the ruby debugger and figure out where I had gone wrong. Almost always I had forgotten to assign some variable or I was calling a method that did something different than I thought.
The other huge thing that is related is that I read and still read copious amounts of open source code written by other people. I’m better at understanding it now, but at the beginning I would take a debugger and walk through the code myself to try to figure out exactly how their code was working so I could make my own code better.
This is super important on the front end as well. Using tools like firebug or web inspector to take apart existing sites and figure out how they’re doing something or making something beautiful is a great way to learn better techniques for front end development. They’re also essential for figuring out how to fix a layout when it’s broken, or how to figure out why an ajax request didn’t respond the way you would expect.
This is a great, free resource to use when learning how to program and really helped us to bridge the gap from a basic programming book to what current philosophies on development were. A huge hat tip goes out to Jeffrey Kalmikoff for posting a comment on a previous post in this series that made me remember how important this is.
Somewhat related are tools that help you keep your code/team in order. By far the most important is a good version control system. This is something that they don’t ever teach even in college classes, but it’s hugely critical to building a project in the real world. We use git at Everlater and it’s been an amazing choice. When coupled with GitHub, it makes working even in a team of two seamless even if you’re working on almost the same code.
Also important is some way of keeping track of the quality of your code as your project grows. This includes a good issue tracker (we simply use the to-do list feature of the free version of Basecamp), and a good way to know when there’s something wrong in your application (Hoptoad is great for Rails devs.)
When I arrived at my house in Homer, I hadn’t been here for two years. It took me one phone call to get Internet (DSL) working again (ACS had to reset my password) and within about 15 minutes everything was working just fine. Except I couldn’t print. I have an old HP 3330 with a JetDirect USB to Internet print server. The printer doesn’t have many miles on it – I’ve only used it for a total of about three cumulative months. It took me about thirty minutes to fight through all the nonsense of the Internet to figure out how to set it up as a print server for my new Mac (which I’ve never used with it before) and for Amy’s Windows 7 computer. It turns out that nothing really works except hard wiring its IP address into our printer setup. Um – yeah – that’s obvious – especially for someone who doesn’t know what an IP address is.
We had a Pogoplug board meeting at our office two weeks ago. For each company we invest in, we try to have a board meeting with all four Foundry Group partners attending at least once a year. This was our “group Pogoplug board meeting” (although I missed the best part – which is the dinner the night before – because I participated in Governors VC Roundtable at the Governors Mansion.)
At the board meeting, Daniel, Jeb, Brad, and Smitty (actually, mostly Jeb) showed off the new Pogoplug “print anywhere” function. They printed a document from an iPad to an Epson printer. Boom – paper came out of the printer. The Pogoplug had two things connected to it – the Epson printer (via a USB port) and our network (via a 10BaseT connection). The iPad was connected to the AT&T 3G network. Did I mention that they printed a document via the iPad? When was the last time you saw someone do that? Yeah, it could have been a web page via an iPhone also.
My immediate thought was how cool it would be to start printing porn on my partner Ryan’s printer connected via Pogoplug since he’d shared his Pogoplug-connected hard drive with me and would probably share his printer also. But then I undermined my evil plot by mentioning the idea. Oops.
If you already have a Pogoplug, this will be a simple free software update coming later this summer. If you don’t have a Pogoplug, seriously, why not? The thing is magic.
I know it’s been a few weeks since my last Nate and Natty / Everlater post on learning to program. I’ve gotten a few notes asking for more – expect a couple of posts over the next few days. In the mean time, here’s Nate’s view on how to divide tasks between partners – in this case him and Natty.
Having good systems in place around your coding is just as important as the coding itself. Natty and I spent a huge chunk of our time figuring out a great workflow that would allow us to program more effectively, and we think it’s paid huge dividends over the lifespan of Everlater.
The first and most important decision we made was to work together and divide the tasks we had to learn in half. I (Nate) took most of the backend server tasks — everything from SysAdmin stuff to Ruby/Rails and a good chunk of the javascript that interacted with the server too, and Natty took everything that appears to the user — everything from learning Photoshop/Illustrator to HTML/CSS and quite a bit of javascript as well.
Nothing too special about our division of labor, but it bears worth repeating that this worked well because we worked so closely together to make sure that the other person still had an idea about what was going on. I needed to know the basic structures of the HTML Natty was creating so I could work on the javascript, and Natty needed to know a good deal of Ruby for creating and displaying the content coming out of the database. We’ve worked on how we pass work back and forth, and while I believe it’s pretty personal, having some basic workflow where you have several stages of planning, we do something like this:
- Mock up the pages super roughly with pen and paper and figure out the different database models
- Do Photoshop mockups and build the routes and models
- Actually build the pages in HTML/CSS and build out the controller actions associated with each view
- Finishing touches (usually javascript), and testing
At each point in the process Natty and I would sit down and talk about how it was going, and implement our side of the task. It bears repeating that this is also a highly personal part of learning how to program. The following worked very well for Natty and I but other people might be better off pair programming the whole thing, work at completely different speeds, etc. The most important thing is thinking about the workflow in general and making sure it’s a conscious decision rather than something that just happens.