1,727 karma · joined March 28, 2007
If some of the stuff in the letter sounds familiar it's probably because you've read it before in PG's recent fund-raising articles (recommended reads for everyone raising capital):
* How to raise money: http://paulgraham.com/fr.html
* How to convince investors: http://paulgraham.com/convince.html
* Investor Herd Dynamics: http://paulgraham.com/herd.html
Sadly, there's not a lot of public information about how Keychain works so I can't say for sure if we're doing the exact same thing. I do think we're seeing the same problem though: the last big change in cargo logistics was the introduction of containers for transportation (and that was decades ago). We can do better.
[0] http://venturebeat.com/2012/08/21/keychain-logistics-truckin...
It's long and detailed because we're tired of "elevator pitches", we want interested people to know as much as they can about our company and what we're aiming for. We feel this is more responsible (you as an investor know upfront what you're dealing with) and it's more time-efficient (we don't have to spend 20 minutes explaining what we do at the beginning of every call (that's actually BS, we still have to do this :P)).
The reality is that we think Uber is a whole lot more than a simple "Connect X driver to Y passenger". They've created a mesh of human transport infrastructure that can take you from point A to point B in the most efficient way. Trust me, the technology behind this is not trivial and their system is almost like a living being, constantly changing itself to meet demand. We're doing the same with trucks and commercial cargo. We don't have the "I need a ride now" problem (although we do have schedules to follow) so it makes it a bit easier for us.
On the tech side this means that we have to predict supply/demand for the products we move. We also have to take the 2000+ trucks we have and treat them like a big pool of resources so we can get volume pricing, make good use of deadhead miles (done with location/route info.) and optimize underperforming routes (by getting more customers A -> B/B -> A.
Please don't take this personal, I'm not a US citizen and I don't like the NSA capturing and archiving my personal, "private" information either, but what do we get from just venting our anger in an online forum?
What do the presentation (or our discussion) gain from the fact that Brad is a super smart guy "much more capable than the 'typical' programmer"? Why are we even bringing up that point? :)
Having said that, I personally still see value in some of those old practices. As [lukatmyshu] mentioned in this thread:
Think of [PMs] as oil in an engine. The best ones know how to communicate extremely well, are paragons of organization, and know how to facilitate decision making.
Instead of getting in the way they make life easier for everybody. I do understand that's not the typical experience for most people in our line of work.
I think your comments are targeted more towards having someone "illiterate" steering the ship and that is a whole different thing that's not mentioned anywhere in the article. I won't argue anything in this regard since I think it's really dependent on the person and not the abstract role, but it seems (judging from the other comments in the thread) that most people have been burned by people with no knowledge giving direct orders on how to proceed.
The author and yourself are talking about entirely different things. Decoupled design and APIs won't help you manage tens or hundreds of developers, it won't help you guide a team towards the same goal. It also won't help as a communication buffer between all the different areas/developers. This is where the PM comes in. The author's thinking _above_ the code level. With his 105 developers, even if they're all producing amazing software, you still need to setup a comm. and product guidance machinery [0].
> Don't add people who cannot code and hope they will improve things.
I'm sorry to nitpick this specific phrase from your comment but a lot of people has expressed this "people who can't add code won't add value" thinking. The reality is that the author never mentioned bringing non developers to do the job (but from the comments on this thread it seems this has been a recurring theme for many people).
Speaking from my own experience, the best PMs almost always started as developers. You don't have to bring an outsider with no technical knowledge, you can just find the right team member who's already starting to take over this and then make it "official".
This prevailing "but he can't code" ideation shows that most people's experiences with PMs has been bad and us developers bring it up because code is where we excel, it's what we can understand and fix. The reality is that if the PM failed to do his job correctly it was most likely not related to his coding skills (but again, we frame it in terms of what we understand, code).
[0] Keep in mind that this does not mean you need to add more layers to your company structure. Empowering current employees seems to be working just fine for companies like Valve and GitHub.
1. Be thoughtful and patient: Instead of writing down whatever comes to my mind, I try to take a couple of minutes thinking about the ramifications of what I'm doing before writing the actual code. In some cases I'll mock several ways of doing the same thing and try to get a "feel" from them [0].
2. Know and use your tools! Unit testing, debuggers or code analyzers are there to help you. You don't need to use all the tools all the time but by becoming proficient with them you'll make your life easier and you can get a deeper understanding of what you're doing.
[0] My "feel" might not be your "feel", it's probably not even the right way of doing things in many cases, but with enough time programming you tend to recognize what "feels" good and what doesn't.
* Basic HTTP Server in X language (Go in my case)
* Controversipedia: Take a dump of Wikipedia, publish only the controversy/criticism of entries.
I try to keep my following list < 50. It's usually a mix of real life friends, interesting people on Internet and services I rely on. A couple of those should not be there but my current client (Tweetbot) allows you to mute them.
Their strategy required the user to manually call each service provider to change the physical address to PayMyBills' so they would receive all the paper and process it. This created huge barrier of entry (who wants to call every single provider to change their address?). At the same time, if you end up signing up you're likely to stay in because of the time it took you to go service by service to change your address again.
FWIW I don't know what happened to PayMyBills but today their site redirect's to one of Intuit's service.
[0] Or maybe not. Your non-core [2] apps that run on 1.8.7 will still work tomorrow. Most of these applications are internal too so the risk is even less.
[1] There's almost always a 3rd party vendor who'll take advantage of a situations like this. They will make it your life easier and they'll charge you accordingly. See http://railslts.com/ for another example.
[2] If the applications that are putting the food on your table are running in an environment where no one thinks about this kind of stuff, then maybe it's time to take the wheel and start educating your team on why this is important.
If you were responsible you went through several patchlevels of Ruby 1.8.7, you're using the latest release (to fix security issues if nothing else) and you had five years to migrate to 1.9 (which most likely meant changing nothing in your code, just testing it).
If you were not responsible and you're running on something different to the latest patchlevel version then you're already running on faulty/unsecure software. Killing support upstream (again, after five years!) is not likely to change whatever you were [not] doing.
PS: Please don't refer to people like the ruby-core team as "cool kids who easily get bored". We all have our biases but name-calling doesn't add anything useful to discussions.
The iframe transport method for uploads is useful for browsers that don't support XHR file uploads (basically IE < 10). You can read more a bit about how it works in: https://github.com/blueimp/jQuery-File-Upload/wiki/Frequentl... or directly in the source: https://github.com/blueimp/jQuery-File-Upload/blob/master/js... (it's pretty small).
We're looking for a junior Rubyist who's comfortable working both in the backend and frontend of our application; we're a young startup and you'll be expected to do all sort of things. We don't have office hours and you'll choose where you want to work (either from home or from our offices in Medellín and Buenos Aires), so we expect you to be smart about how you spend your time.
Most of our software is written in Ruby/Ruby on Rails and Javascript, but knowledge of other languages and frameworks is a bonus. Open source contributions are a huge plus.
If you're interested please email Federico (federico@micarga.com) with a link to your GitHub account and tell us a about yourself. Links to any interesting software you've written in the past will be appreciated.
Edit: As orangethirty mentions, you're probably too late to start promoting this if the event's 4 days away. Good luck anyway! :)
One problem I've seen in big tech. companies (especially Google) is that most employees hate doing interviews, they think it's worthless and a waste of their time. They don't seem to realize that this is a necessary part of the job (especially with a company that went from 20 to 20000 in such a small amount of time). In the end, would you rather have your co-workers be interviewed by yourself (or another technical fellow) or by an uninformed HR department?
Having said that, I would've loved to work with Rachel. I have a deep fascination and respect for responsible and involved people who can pull the weight of an entire team when everyone else ain't doing shit.
In general, this is aligned with the author way of thinking and it also applies to stuff like languages (think C vs. Java) or even window/desktop environments (Fluxbox vs. Gnome).