The secret guild of Silicon Valley
medriscoll.com
medriscoll.com
I hate articles that make it seem like there is some magical cult of amazing engineers that have an untouchable and unattainable aura. I remember how intimidated I was after I graduated college and was coming into the workforce due to it.
Well, I used to work with the men and women who "who keep Google’s servers running" and at one point in time I was one of them. I can tell you that none of the stereotypes listed apply to any sizeable percentage of them, and their variety and skills were incredibly diverse. Some had years of experience and were grizzled veterans, some of them were right out of college. Some of them lived in the south bay, some lived in the city. Some dressed more fashionably than others. Some were men, some were women.
They, like many, liked working on interesting problems. They, like many, cared about engineering and improving their skills everyday. But, there was no magical guild which encompassed them. It is just a bunch of engineers with different skills, different interests, different personalities, who all just enjoyed engineering. Just like you and me. Your company doesn't need people from this magical guild to succeed, because this magical guild doesn't exist.
I certainly agree that any engineer would like working at a place where their work will have a huge impact and will be appreciated, but who wouldn't? If your company is marginalizing some percentage of your employees, whatever their job title is, then you certainly aren't going to be able to attract quality candidates for that position. That really has nothing to do with engineers or some magical guild though.
It's a response to the effect the consumer web has had on silicon valley, namely the tabloidism, the hollywoodization, and the explosion of self-promotion. The bloggers, the pundits, "brogrammers", "ninjas", etc.
When you read articles about using Github as a way to screen prospective employees, or not hiring people who don't have a blog, you realize that the core practice of software engineering that underlies all the most innovative aspects of what's happening in tech today has the potential to get lost in a sea of signaling.
The delivery of this message may not be the most tasteful, but I think it's a point worth making.
I think that the point is that typically in startups, people revere the company founders, the MBAs, the VCs, etc. and not the quiet experienced engineers that just make things happen. You're right that it isn't a secret guild, however there is a range of experience and talent, and some are on the higher end of that. Not everyone can easily attain the level of experience and talent that some of these people have; it is a mix of education, natural ability, hard work, and luck. But, you are right that getting a lot closer to the level these people are at is not impossible.
I disagree. I think that engineers get a huge amount of attention, far more than they would in any other industry. But at a base level you need to be outgoing and sociable- it seems that proportionally fewer engineers are, when compared to MBAs, VCs and the like.
People talk. Not really too surprising but Silicon Valley, like Hollywood, or Washington D.C., or any community being warped by a common theme, is at its heart people. And I don't know it if it part of our genetic heritage or what, but many people love to talk about other people, and so there is the undercurrent of a social fabric (made more visible by LinkedIn or Facebook but its the same fabric).
What Hollywood, Silicon Valley, and Washington DC share is a very low viscosity when it comes to job change. People move around, some move around a lot, and so the stories of people, and opinions about people, move with them.
Finally there is an external valuation that gets applied to folks, that is part who they are, what they are doing, what they have done, and who they have helped or hindered.
This isn't rocket science, but its good to be aware of it if you're working here, or thinking of working here because it can and does affect how you experience things.
So a new college graduate goes to work for a company. They come to know the people around them, and may develop opinions about their relative value to the company. After a few years they move on. The next company is looking for help and they ask you to 'reach out to your network' meaning "Let's see if we can poach the 'good' people from your previous job." This cycle repeats ad-infinitum.
Within that repeating cycle you will discover a truth which I learned from Bob Lyon at Sun which is this "There are no bad employees, only bad fits" which you may or may not believe, but it is true, that people who perform poorly in one environment can be superstars in another. And the flip side is "There are no good employees, only good fits." which is a scarier thing. At some point you will experience hiring some person who was a superstar at X and they join your company/group and don't get anything done.
Over time, and we're talking decades, you find people who are good to very good in most environments, and those who are poor to very poor in most environments. The latter tend to move on (either out of the valley or into different roles), the former become 'targets' for being recruited.
The interesting aspect though is that someone has done well in a wide variety of roles, that usually means there are lots of people who know them from interacting with them. Further they often know others who are good in a wide variety of roles. Sometimes it seems like there is a secret society somewhere, but there isn't.
When you encounter this phenomena for the first time, you might feel like they are a secret guild, folks who know the other 'good' people who can get things done. And yes, they can demand, and get, a higher than nominal salary (see today's front page story on 'pay'). But that comes from the probability they will do well, regardless of their role.
Three things to take away from this:
1) If you think your co-worker is a 'loser' consider they may just be in a bad role, if your managing them put them into a different role to see if they are better.
2) Track records can only be created over time, so don't worry that you're not 'a superstar' in 3, 5, even 10 years. Get to know people, try different things, test your own boundaries.
3) Recommendations and criticisms of someone by a former co-worker who has only seen the subject in one role, can be misleading. It only tells you about them in that one role. If several people have worked with a candidate in different roles and you are getting feedback that is both 'great' and 'skip this one' consider the roles at the time and weight based on your proposed role.
1) First version of the app is built in Ruby, Python, or PHP and the lightweight stack helps the business stay nimble as it finds its market position/niche. During this time, there are a LOT of inexperienced, younger engineers working on the code.
2) Once the right market position is found, the app takes off and scaling problems abound as the lightweight stack starts to fall down at massive scale.
3) Funding is secured and more experienced, older talent (the Guild) is brought in (at much higher salaries) to help fix the hot spots. This is usually done using a combination of using the JVM or unmanaged C/C++. The engineering demographic often switches here as you see a lot of 30-something veterans from Yahoo, Google, etc come in and bring their tools with them.
4) Scaling isn't an issue anymore, but the culture has changed a bit as the business has become more established. Many of the early folks have moved on or gone into leadership roles. A few have been absorbed into the Guild and will move on.
It's very interesting. I've worked mostly in the midwest and the South during my career, and this lifecycle of talent is not something I've really observed outside of the Valley.
I suspect that this "lifecycle of talent" is a part of SV's secret sauce. As manufacturing becomes even more amenable to rapid prototyping, this sort of culture could be applied to that domain. (Is it already?)
I've wondered the same thing about whether this is a differentiator that makes SV companies successful. Observing it is part of the reason I'm even interesting in speaking to these companies, despite the unrealistic outlook I have on actually living there.
I do wonder if the Makerbot/3D Printing thing will lead to the same thing. I certainly think it could, but it'll be hard to make shippable products using 3D Printing at home. The production cost for volume will be too high to leave it to the consumer based machines.
Most startups don't attract these people because when you approach a great engineer when you want something, they can smell it on you. They don't need your job and they don't want to work for someone who sees them as a means to an end.
Words of wisdom for a founder who wants to establish a culture of "Good People."
Then I thought we managed to get such amazing people because we were lucky. That explained some of it, but nowhere near all of it.
Now I realize that great people are attracted by something they can believe in.
Definitely, maybe, and absolutely not, respectively.
> They wear ironic t-shirts, and that is the outer limit of their fashion sense
True.
> They’re not hipsters who live in the Mission or even in the city; they live near a CalTrain stop, somewhere on the Peninsula
True.
> They meet for Game Night on Thursdays to play Settlers of Catan
False. SoC is for hipsters. The neck beards are playing something much more obscure, which probably hasn't been translated from German yet.
> They are passive, logical, and Spock-like
Logical, absolutely, but they are anything but passive. It's just that the set of things they really care about has almost zero overlap with the set of things that you really care about, which looks like passivity to you.
If you have such a bias against any language that delivers the goods in the real world like Java does, you're probably not a systems guy. Let me guess, you have a problem with some clumsy aspect of the language or other? As if C is graceful?
I'm primarily a Java guy but am capable of switching to C, writing decent code there, and making decisions like that. Someone who refuses to use Java because it's too "corporate" might be a better C programmer than me but they're not a better programmer.
Take a look at the code in java.util.concurrent sometime, specifically the inner Sync classes. If that's insufficiently "hardcore" for you, I don't know what to say.
Look, I get that there are people who really like Java, and that you've had to defend it for years against (often bogus) claims that it can't be used for x and y. I am not making any claims of the sort. Here is what I claim, put absolutely precisely so we can stop this nonsense:
The intersection of the following sets
1. engineers who I know
2. engineers who think deeply about performance
3. engineers who choose to write Java
That's it. I haven't claimed that writing Java makes you uncool. I haven't claimed that it's impossible to do anything in Java. I haven't claimed that Java is unsuitable for any task. It's entirely possible that I simply don't know the right people, and that even though the intersection of the first two sets is large, it's not large enough. I certainly don't know everyone.
I've seen a lot of cool things done in Java. I don't mean to imply otherwise. I've also seen a lot of really cool things done in Fortran and COBOL, many of them by unquestionably full-on neckbeards.
That said, within the population of people I know well, the experts who really understand low-level details of computing do not chose to write Java.
For web apps that scale out to a certain level, Java + Spring + Hibernate + Tomcat works boringly well. That is Java's niche. As you inferred, I wouldn't use it for much else.
Above a certain scale, you're back to C++, of course.
This is spectacular in its depth and brevity.
Moreover, once you scale, you get big money, and then you hire IBM or Oracle or whoever to come in with consultants and give you the bespoke blessed Java stack. I have a friend in ecommerce right now (who is also an excellent low-level neckbeard) and his company bought top-of-the-line storage and things just to support the log spew from this stuff.
This isn't wrong, mind you...it's just that, at some point, it's better to just spend money on bigger iron, and then the neckbeards say "Fuck, this is boring and dumb" and leave for a challenge elsewhere.
The ASF has a ton of stuff based around the idea of "libraries rather than frameworks".
Again, I'm not bashing Java here. I think it's a good language, with a some cool things.
But, if you hire a neckbeard to code for you in Java, and they start messing around with java.net.blah and java.io.blah, and you're doing a webstack or something... I'm going to wonder whether or not they're mad. If they were doing this in C, that'd be par for the course and perhaps worth the effort. If you're in Java, though, why aren't they using the established libraries?
Anyways, again, consider the other issues for things like SOAP, XML, etc. Everybody ends up using the massive tooling stuff for that, and we're back to my original observation.
Reminds me of one Korean woman I knew in South Carolina. She would start cooking at a restaurant and it would flourish. Then the owner would alienate her, and she'd leave and the restaurant wouldn't be so popular anymore. Eventually, she started cooking Korean food at her husband's cuban sub shop and the sub shop became one of the most popular places to get Korean food. Seriously, the place was often packed with Korean students from the university.
However, the sort of insider culture described in the article makes me think of the insider culture portrayed in the beginning of "Moneyball." I suspect that, given more open statistics, the industry would benefit from a more quantitative evaluation of technical people, as opposed to the stone age reputation mechanisms of Homo sapiens at play during shop talk. (Which work pretty well, but we can do better.)
This is one place where large companies currently have an advantage over the market at-large, as they can gather this sort of quantitative information about their own population of employees, with a uniform set of standards to enable measurement.
An organization like Y Combinator could do something similar. Even better, startups and incubators in worldwide could start doing this.
I've advocated "guilds" here in the past, and HN members have downvoted me. Really, that's just poor marketing, as what I was advocating wasn't anything like a medieval guild. What the industry needs more of are 1) mentoring at levels above the "pop-culture" of programming 2) better and more open quantitative measures.
Really, 2) is the same thing as pro athlete's stats or MPG figures on a car's sticker. Better flow of information would result in a better market.
Every software project tends to be different. Lots harder to quantize.
We do not prefer C, C++, and Java over Python, Ruby, JavaScript or any other cool language of the week.
We LOVE to build things and solve problems. We LOVE to start with nothing and end up with something USEFUL to much more than ourselves.
In order to achieve our goals, we will pick up any technology or tool available, based on their suitability to the task. Coldly.
But, yes, we smile a lot when we see the way the business world and entrepreneurs repeat the same mistakes over and over.
I have serious issues with labeling people according to their tools of choice (disclaimer - I'm a known pythonista with a rather strong opinion on both C++ and Java). A good software engineer will use the right tool for a job much like a mechanical engineer will pick the right material for the job. The analogy above shows an engineer with a preference towards titanium, A53 steel and lead.