I'm biased, but I'd say out of all the "big" tech companies, FB has the best engineering culture.
* With few exceptions, engineers aren't hired for a specific team; they go through bootcamp where they get exposure to all parts of the stack and tasks from different teams.
* Ideas usually come from engineers. Managers are there to be a sounding board/connect you with people resources as needed.
* Moving fast is valued (we used to be famously known for "move fast and break things" but now it's "move fast with stable infra". I.e., our dev infra is developed with a eye towards enabling rapid iteration.)
* Lots of internal knowledge sharing.
* Scale. Probably only Google, MS, Amazon come close.
* With only very few exceptions, every engineer has access to the near-entirety of source code at FB (Oculus, Whatsapp, Instagram...).
* Internal mobility is quite straightforward; after a year you can generally transfer to teams with available headcount without a formal set of interviews.
Of course, it's not everyone's cup of tea and like any big company it's not always 100% perfect and we don't always live up to this in every circumstance, but in general this is what it's like and what we're aiming for.
Even worse, look at their Android app - They made an overly complex open source image loading library which is despised by most quality Android Engineers because it uses parts of memory it shouldn't be using, switching to and from it is terrible, has a big dex footprint and often results in OOM crashes. They use runtime hacks and then complain directly to Android developers when something breaks during updates, their SDK is terrible and pulls a ton of dependencies, they made a "2D physics engine" just to make a bounce animation. Met a dozen of their developers and I have noticed way more arrogance than brilliance. None of them are the kind of people I'd like to work with.
I've spoken to Facebook engineers who work on their internal source control systems, and it was pretty obvious from talking to them that Git wouldn't work for their purposes. There is plenty of writing about this topic that explains in some detail why Git is unsuitable, and why Mercurial was a better option for them.
As for the 18k classes in their iOS app, I don't see why this is a sign of bad engineering? I'd expect that a large number of these are auto-generated, for example from Thrift API definitions, and I'd also expect that what we see as users is the tip of the iceberg in terms of the code needed. There's obviously a lot of analytics code, and also I'd expect the resiliency and reliability needed requires much more code than we'd expect.
As a small-company person who migrated a few years ago to one of the Big Four, I can confirm that almost every time someone tells you about "scale" they are bullshitting you. Most developers on those companies either do not deal with scale at all (anyone dealing with front end stuff) or do so by using abstractions which allow them to ignore scale (99% of developers). But scale sounds sexy so everybody pretends they have something to do with it. And it sounds better than "bloat" which is what they really mean.
The other variant of "scale" is "I have this single-computer application running on X hundred thousand servers" or some ambarrasingly parallel problem of that sort. Then they will claim boldly that something that has a 0,0001% chance of happening "happens multiple times a day here" which sounds impressive until you realize that that thing has no impact on the SLA and you get saved by the load balancer so it isn't particularly important anyway.
The 1% of people who work on real problems in the area don't need to brag on the Internet about "scale" because they are too busy working.
I can't immediately think of any apps that are just as complex as Facebook's, but maybe I'm just not thinking hard enough. Could you give me some examples (honest question)?
Based on their documentation—which, albeit, I know has many classes omitted—Unreal Engine has ~6900 classes. That number probably gets greatly multiplied, though, if you count generated classes.
The light FB app probably does very well by class count metrics, but it's intended for a totally different market. Stateside, much as we may bitch about it, it apparently doesn't matter for an app in FB's position.
The problem of 'scale' they were addressing in the iOS app wasn't scale of users, but rather scale of devs. They have 18k classes because they came up with a rather clever way of allowing many separate developers to all work on different features of the same app, without stepping on each others toes. This might not seem like a hard problem if you've never worked on a non-trivial iOS app, but it is a pretty impressive feat.
Facebook wants the shortest possible time between product idea and real world users interacting with it, which is why they also have a solid CI/CD pipeline. You might not agree with the tradeoff, but the pragmatism is impressive
> They have 18k classes because they came up with a rather clever way of allowing many separate developers to all work on different features of the same app, without stepping on each others toes.
What makes you believe this is "clever" as opposed to a poor engineering decision? I strongly suspect that FB might have delivered a higher quality product through a more traditional team-ownership development model. Throwing large numbers of developers at a single app is unlikely to lead to a well-architected holistic solution.
I'll be very blunt: In situations like this, they are far far closer to the code than an armchair observer like you. I trust their engineers far more than I respect your pithy complaints.
* you decide on a team before you start doesn't seem to be true.
Most of the compliant about Google hiring practice has been along the line of, and I paraphrase "I was promised to be with a team or a position and then I got placed in a totally and differently unrelated position/team"
Unlike most companies you interview for the entire company and not for a specific team at Google. That means you only know what team you are going to be on after you pass the interview. However, you will always know before you start. It mainly depends on what teams have headcount at that time and are a good fit. You can choose to take a pass on a team you are matched with and wait for another match.
>>> Google is trying hard to make it's hiring and promotion process objective and unbiased. That's why they happen by a commission of peers.
How on earth does this follow? I know that peer review is in fashion right now, but without some very strong context, this seems more like a recipe for a Keynesian beauty contest than a useful measure of merit.
It's committee of people from all over the company that don't know the person in question. The candidate prepares a document that shows their contributions with some quantifiable metrics.
There has been research that showed that this kind of decision process decreases bias.
It means that Google often passes on opportunities to make more money if that would hurt or mislead users, advertisers or publishers.
Google's search rankings are unbiased. The ads team is separated from the search team. It's business model benefits from and supports an open internet, unlike other companies which lock users into their ecosystem.
Google is very transparent internally for a company it's size.
Google releases large of amounts of open source software and publishes research. For instance Google published a paper that explains in detail how it's Machine Translation system works.
You should get the YouTube developers in on this, because their ContentID system is about the LEAST ethical piece of software in common use.
In my 2 dozen or so ContentID flaggings, maybe two of them have been by parties with a legitimate claim to the material. All the rest have been fraud.
My most recent "pleasant" experience with ContentID was some scam copyright company claiming they owned the soundtrack to Elder Scrolls: Morrowind. The beauty of this system is that not only are they fraudulently claiming they own that content, but to get my video published I have to swear that I'm not stealing the content they actually stole.
How do I report this scammer to YouTube? Well you can't. There's no automated way, and there's no support whatsoever. They can just scam in peace for years and years and nobody can do anything about it because nobody at Google cares.
Of course you can DISPUTE the claim. And in fact actual scammers will release the claim right away because they make all their scam-dollars off old videos where people don't check the ContentID status every week.
But there's no way to tell Google, "the guy making this claim doesn't own the content, he's a scammer". That's the feature I need.
I am 100% certain that the company claiming to have owned Morrowind's music:
1) Is not Bethesda (the developer of the game)
2) Is not affiliated with Bethesda in any way
3) Has no right to the music
But I have no way to communicate my research to Google. Because, guess what, those "ethical" Google employees make money off the scam, too! They take a percentage of all ad revenue, even if it's a ContentID scammer's ad revenue.
I am assuming you are talking about privacy issues. Google collects a lot of data, but is very thoughtful about how they use it, who has access to it and gives users options to view and delete it.
That is what I was referring to.
They take measures like you said, but do non-technical people even know about it? It is not advertised as far as I know.
> Google is trying hard to make it's hiring and promotion process objective and unbiased
Google tries very hard to appear to be ethical, unbiased, responsible, and generally virtuous. Sometimes this attitude results in good work. Other times, and I think more often, it amounts to empty posturing and counterproductive gestures. In the social sphere, this "be seen as good" attitude manifests itself as annoying virtue signaling, speech policing, and other behavior that you also see on American college campuses. This behavior is annoying, but very common in tech and easy to ignore.
The "be seen as good" attitude also manifests in technical culture, however. There's this weird attitude inside Google that what is painful must therefore be right, as if difficulty were its own reward. While it's true that the right thing is often painful, the converse does not hold, so Google makes some bad decisions.
Google's attitude toward developer friction is, "This process is slowing you down? Too bad. That's how responsible engineers work." This hairshirt-loving attitude leads to large teams, moving slow, and general risk aversion, and I think it leads to bad engineering-cultural choices.
Google: "This language feature causes problems? Let's ban it. We'll add headcount to make up for the productivity drop."
Facebook: "This language feature causes problems? Let's add tooling to warn developers about the dangerous usages and make sure we can quickly find bugs."
I've worked at a lot of tech companies. I don't think the people at Google are actually any more or less ethical than the people at other top-tier tech companies.
> moving fast is not valued as much
It's important not to underestimate how much moving fast makes you happy and how unhappy you become when moving to a slow environment having worked in one that moves fast.
Facebook's elevation of moving fast to a first-class goal goes a long way to slowing the kind of decay that Google has suffered.
They must have a great culture. Look what FB did for the JS ecosystem just recently—yarn, React, React Native, Immutable. Really excellent stuff which you not only need superb people but also a good culture.
So, I'd say that excellent products, both the commercial ones but also open source, are a good indicator for 'culture'.
> With few exceptions, engineers aren't hired for a specific team; they go through bootcamp where they get exposure to all parts of the stack and tasks from different teams.
How is that good? You essentially don't know what you sign up for.
I'm assuming that after the bootcamp they would put you on a team based on your interests and aptitudes. For me, having a choice - or at least feeling like I have a choice - over teams and projects is empowering and exciting.
In other companies, you have that choice during recruitment. Here, you need to basically trust that they won't screw you over ("Look, it turns out that the only opening we have that matches your skills is maintaining this internal CRUD app for HR - but no worries, stick with it for a year and maybe something better comes along!").
But that would be evidence of a bad engineering culture. Which is United has said is not true. So we can probably assume they meant FB's bootcamp is more about placing their engineers on teams they would enjoy and are good at, most of the time.
Having worked in a bullpen style office (I now work from home), it wasn't the open floor plan that was a problem, it was the number of people management crammed into that open floor plan that became problematic.
At one point, we had completely outgrown our space and we were constantly tripping over one another. It was miserable and everyone was constantly sick. Eventually, we got more real estate and everyone was happy, more productive, and less ill.
As long as you have the real estate, open floor plans are nice and help you feel less imprisoned than cubicles imo.
> and help you feel less imprisoned than cubicles imo.
That's not help. I don't feel imprisoned in a cubicle. I like walls, the taller the better.
I'm currently in a short-wall cubicle farm where we have enough space to not to all get sick, and even there the cross-talk from multiple conversations can be completely distracting.
While management/facilities ignorance can definitely make open plan offices worse, I think they're still not for everyone. Some people seem to not mind being distracted, other people are really sensitive to it.
> * With only very few exceptions, every engineer has access to the near-entirety of source code at FB (Oculus, Whatsapp, Instagram...).
Sorry, this could be slightly off topic for this thread. I'm curious if this kind of access also applies to all the data that users put up on the platforms? To put it in other words, how does FB prevent or work to prevent LOVINT [1] like cases? If it's the same kind of access, wouldn't working in the company make the employee uncomfortable that there are people who can look at all information?
P.S./disclaimer: I personally dislike FB as a platform and as a company for privacy and other policy reasons I don't agree with (like "authentic names", for one). So my bias may be showing in my question, although it's intended to know more and not meant as an attack.
I've interviewed at Facebook 2 1/2 years into my career and have an open invitation to interview whenever I want without having gone to a tier 1 university for undergrad or grad (although I went to a prestigious program for grad math, UIUC) - my education turns out to be a poor indicator of what I can do.
A caveat is that I originally entered FB's pipeline through a referral from a friend who interned and works at FB right out of CMU computer engineering. Referrals are often enough at these big tech companies.
I'm quite sure it's not true. There are at least 2 engineers from the React team who have dropped out of "normal" schools/colleges in their first years.
I think the author meant that the exceptions were Oculus, WhatsApp and Instagram. This would make sense given that they are acquisitions and appear to have separate offices, deployments, datacenters, etc in some cases.
Data point: I read it the other way, that all employees could look at all of those things, and that the exceptions were un-named.
I'd imagine the exceptions are some small black boxes that try to catch abuse/spam/etc in various ways & places, or are closed off to prevent a code leak from exploiting a loophole in said software. Defense in depth, and all...
Google has an unique software engineering culture that was built and designed by the first engineers. Many of the practices show deep understanding of the challenges that growing an engineering culture faces.
A few examples:
There are clearly defined initiation rites for new employees that make them familiar with the engineering practices.
Focus is on a few key languages (C++, Java, Javascript, Python, Go) and code reviews are practiced over the team boundaries. This makes the knowledge transfer inside the company faster.
Changing your team and role regularly is encouraged.
Single, company-wide code tree and build system makes it easy to switch teams and make it possible to build very efficient tooling.
Coding style is strictly enforced to avoid petty fights and Google's very good coding styles guides include reasoning why certain choices were made.
He may be referring to the on boarding process + first commit. Generally you'll have a few classes that introduce you to Google's build tools and any technologies that are relevant to you/your team. Then you'll start work and go through your first code review. This is probably what is refereed to as 'initiation rites'. Depending on the size of the change you may get a handful of comments or quite a few. After going through the code review process you will have successfully internalized Google's commitment to code quality. Generally you'll get a bunch of comments and suggestions that seem nitpicky but help keep things consistent and a few that are eye opening and help you become a better engineer.
I'm guessing he means readability. Google fetisihizes consistency, even at the cost of ingenuity and productivity. Heroism is a virtue at some other companies; at Google, it's a sin.
> Heroism is a virtue at some other companies; at Google, it's a sin.
This is not entirely true. I've seen many people being promoted for "jumping on grenades", especially in SRE. A culture of heroism is unsustainable, but individual acts of heroism (when required) should always be appreciated.
Python and perl are very very similar. Python prioritises expressiveness over uniformity, perl is the opposite. Perl's original OO mechanism was stolen from pythons, but due to the greater flexibility it means that there's a lot of choice and perl's extended OO capabilities exceed that of python. Personally I hate the way that the python people keep bagging out perl when it's clear they know little about it.
I don't have preferences as such. My main problem is that over the past few years my perl skills have been in such high demand that I haven't had much time to do substantial other programming stuff (this is a class of problem you want to have). I have been playing with python's maths libraries (particularly sympy) lately, and along with jupyter it's pretty neat stuff.
There is no universal scale. Some people prefer to work at big companies such as Google, Microsoft, Facebook... some at smaller fast moving startups and everything in between.
There are for sure better and worse companies in each category, but even within big companies there is huge variance and it depends what you are looking for.
Though some generic observation:
1. Product companies tends to have better culture than software consultancies.
2. Companies which got strong technical leadership and software is a key component rather than add on (e.g. some banks).
3. Good litmus test is to ask employees, do they have hackathons/educational budget/internal tech talks.
4. Another litmus test is to ask how hard is to push feature to production/release or about developer tooling. Good companies tend to have convenient tools.
> Good litmus test is to ask employees, do they have hackathons
I'm a designer rather than an engineer, but I've always been a bit puzzled by the popularity of intra-company hackathons. It seems like a great way for management to keep employees working longer hours for less pay – an overnight hackathon that results in, say, 80 hours of additional work from a small team only costs the company some pizzas.
Have you ever wanted to collaborate with a coworker on something outside of your job, but can't ever find good time outside of work to schedule it? Our company did a hackathon (time limit of 24 hours, but no one stayed overnight) and I got to work with one of the senior tech leads on a HipChat bot. I found that extremely fun and rewarding.
Some people like 24 hour raves too. I personally can't understand it. A good hackathon is a party for people who like to party that way. If you have colleagues that you truly enjoy hacking with, it's awesome.
Plus I like pizza.
I understand that some people don't enjoy these kinds of things the way I do (and to be honest, I can't do 24 hours of anything any more). As programming jobs become more integrated in society I find that hacking culture is changing. There are many more 9-5ers these days than when I first started. As much as I understand it, and as much as I think it isn't necessarily bad, it makes me a bit sad.
it depends on what hackathons are geared to doing - if it's _actual_ client/business work that they'd be doing normally, then it's not a proper hackathon, and just an excuse to get more hours out of the employees.
But if it's a free for all, do anything you want style, and participation is optional (truly optional, not fake-optional via management peer pressure), then it's a good sign.
My hangup is that in either case, it's still extra work that benefits the company rather than the employee. It's performed on company premises with company equipment - gamified overtime, essentially.
I suppose there's an argument to be made that a good employee can make it mutually beneficial (use the time to learn a new, marketable skill that can get them a raise or a better job), but still...
In the situation the parent described, I find it hard to construe it as benefiting the company over the individual (other than naturally making the company more attractive to work for).
We did this when I was at Guidewire and it was amazing. I explored Event Sourcing during a hackathon and eventually went on to build it into a product using those skills - it's a really happy memory. In another hackathon I built easter eggs into our internal seating chart application - the vibe of everyone hacking together was great.
This was a hackathon where it was broad enough that "reading an interesting programming book" counted, and nobody really bothered you if you did something completely different.
Explain simply how building something the company won't use or learning something new on company time is essentially gamified overtime when doing this on normal company hours.
We had an internal hackathon at my company recently. It was a Thursday/Friday + optional weekend thing, but nobody was pressured to work excessive amounts of hours to get their project done.
Sometimes hackathons are for a social cause (i.e. not tied to a company's products). Even in those cases, they strongly suggest using the company's tools/products to solve said social problem. I see it as a win-win. You get to use your tech skills to solve a social need for some nonprofit (they are not required to buy anything for this solution) and the company gets some publicity.
The company I work for runs a week long "hackathon" each quarter during business hours. Generally, you aren't allowed to work on anything but your hack week project.
They are merely X days provided by the company where your regular duties are no longer your priority. Instead you are encouraged to learn and/or create.
Some may work more hours. Some may work the normal hours. That's it.
If it imposes restrictions on what can be worked on and limits creativity and doesn't put learning first, it's really not a hackathon.
>Some people prefer to work at big companies such as Google, Microsoft, Facebook... some at smaller fast moving startups and everything in between
On of the "in between" things I really like is working in the IT department of a non-tech company. In that space, there's opportunity to do really well, even if you aren't in the top echelon of tech talent.
Typically, that's not because these companies don't care about technical expertise, but because they want developers with a good balance of tech expertise and business expertise. Someone that's willing to spend enough time with the the business side of the house and listen to their views is highly valued.
>Companies which got strong technical leadership and software is a key component rather than add on (e.g. some banks)
This is so crucial. I currently work at a bank and it is frustrating. The business side forces technical decisions on you, is generally not very understanding of technical challenges, is micromanaging, etc.
Could someone explain to me why so many people on here fetishize scale? Scale is a constraint on a problem, and it affects the solution you come up with. I don't understand why solving problems around that constraint is considered cooler than solving problems around other constraints like uptime, performance, memory cost, etc. Does "Our API serves 234 million requests" hold more cachet than "Our medical device firmware runs 24/7 without crashing and takes up 12 MB of RAM"?
This is just a guess, but I suspect that "scale" also generally correlates positively with compensation. A medical device company with 50 employees just doesn't have the same resources as a company with 1M+ users, for example.
Following from that, compensation is one of the easiest ways to measure professional "success", which is why large, highly-compensated companies are commonly viewed as the pinnacle of software engineering.
Whether that's a fair or accurate assessment is a different question.
Scale is also scarce. There are few companies operating at Google or Facebook or Amazon scale. You can't just create a product at scale if you want to gain the experience of scaling a product, you have to be working somewhere that grows tremendously.
Scale is something of a measure of popularity. If our API serves 234 million requests per day, then presumably we're running something pretty popular and widely known.
Because of the democratization of "big data" and the (relatively) recent uptick in large internet services, serious scale is an engineering challenge that a few have been tackling for awhile, but many are facing for the first time. Think any company that has recently realized their data needs are bigger than what Excel can handle.
In my experience it's a fun problem to solve. An engineer gets to design complex architectural solutions, acquire hardware, work with various database solutions, and generally work on larger problem domain than the problems you mentioned. Uptime, performance, and memory are all very important problems but you rarely get to venture outside of the current code base when solving those problems.
The joy I get from writing software comes from creating and using good abstractions. When optimizing for these things, you have to hang up all the fun toys, bring memory bookeeping to the forefront of the codebase, and abstain from nice language features / write things in obtuse ways to squeeze out performance.
I'd much rather solve distributed systems problems with channels and futures and maps at my disposal, than make a C program even less readable for 5% more performance.
Just taste, I guess. Distributed systems are a more interesting problem domain, to me, than throwing away all the nice stuff that's built for us and writing hand-tuned use-case-specific reimplementations. I'm sure both can be (and have been) taken too far.
I am surprised that no one mentioned Microsoft so far. These days they are professional, innovation-driven, and do not bring in much of the unnecessary cult that comes with companies like Google. They are more open than Apple.
Also from a personal experience I think their interviews / hiring methods are better than all of the other big players.
But are their engineering practices better? They used to take test seriously, but then they fired all the testers and quality of basic things has slipped. They don't even hire for dedicated testing roles any more.
I get that devs are supposed to test their own code, but they are surprisingly bad at it overall and unit tests, despite being a great meme, just don't cut it.
Some examples of quality issues: new limit to how many items can be in the start menu. I see bugs/rendering issues in Word for the first time ever (Windows and Mac). Edge is glitch when opening/closing tabs.
That's interesting to hear because I was reading the Software Project Survival Guide and it said that, at the time, Microsoft knew the value of quality because their tester to developer ratio was 1 to 1. Higher quality code had a ratio of up to 4 testers per developer. Low quality code is usually the opposite ratio, 1 tester for every 3-4 developers.
A problem with assessing Microsoft's engineering culture and practices is that at Microsoft is there is no consistent unifying set of engineering practices. Product teams need to comply with some standard processes around security and the like, but as to how they run their teams they are allowed to chart their own course, more or less.
Microsoft is one of the few places where you can pretty much switch to using any part of your CS degree just by making an internal transfer. Operating systems? Compilers? Consumer applications? Cloud infrastructure? Search engines? Games and console development? Embedded devices? Database engines? CS research? All there in one place. Only Google and Amazon come close but Google is 90% search and ads and Amazon is 90% cloud and retailing with all other areas being small side projects for them.
The downsides are the mega-corporate culture, with all the bureaucratic dysfunction and vicious internal politics that entails (it's not quite IBM but not for lack of trying), that its famed private offices are gradually shrinking / going away, and the pay is decent but not amazing. And obviously if you rabidly dislike the MS software stack, you won't like it there.
This is a fairly hard question, and inherently ha bias. What I will say is this, I believe every company from Google to the startup down the street will have some fault.
However, one of the largest faults I've seen in my years working is the arrogance. I have personally found startups to be some of the most humble in that regard, they'll push you to make design choices other shops won't have you make, and if you mess up, your job is much more on the line. This humbles many engineers, and in my opinion creates a better culture.
Larger companies breed arrogance, people learn their niche, there's "in breeding" so to speak. Engineers learn and specialize, and believe they are the smartest or most knowledgeable. This will create arrogance. Where as startups will train everyone to be tricks of the trade, masters of none. And people will learn to improve generally.
Not universal, but I find most startups I've interviewed with extremely arrogant. The nicest workplaces for me have been the old and steady companies with boring software.
Things I see a lot in startups:
Lack of real world business experience, so terrible management.
"we're the best" attitude pervasive in everything.
Hyper focused on the technology used over the job at hand.
Unrealistic expectations in general.
I'm gonna be rich because I'm awesome founders club.
That's my perception of startups too. Some of them pretty much require you to believe the company is the best, and if you express moderation, it is a sign that you are not going to give your all to make the company succeed.
You know, the faulty "If you don't think you're the best, then you never will be" advice everyone seems to believe (not just in startups).
Etsy. I don't work there, but I've interviewed there twice and know lots of contacts who work there, and it's a great engineering culture.
The overwhelming majority of the company are engineers, and they have a large commitment to OSS, which was one of the initial selling points for me. Not to mention, Rasmus Lerdorf works there, and several of their engineers contribute to HHVM.
I'm a former Etsy employee. The engineering culture is awesome there, but I feel the need to point out that the majority of the company are not engineers. Even when I joined in 2013, we were about half the company. By the time I left (June 2016), we were around 1/4 or so.
In regards to mega companies, it's hard/impossible to talk about culture in a meaningful way because the organization is so large. For a personal example, saying "I work at IBM" is not terribly informative because IBM has more employees than most island nations have citizens, and its branches and divisions are extremely different. Some are doing really cool, cutting edge work, some are doing uncool, arthritic, blue-polyester-suit-style work. And the culture may not be homogenous across those either. Considering two "uncool" divisions, maybe one, despite being uncool, has a really innovation-oriented exciting culture and the other has more of a who-took-my-stapler vibe. Maybe the same holds true for divisions doing cool work.
I would venture to say that this more or less applies at any company of a sufficiently enormous size. It's just hard to generalize.
I will definitely agree with posters here who have said different strokes for different folks. Megacorps of all kinds, regardless of internal culture, are just different from startups.
The Spotify app for macOS has a habit of eating 100% for no reason, even when no music is playing. I habitually quit Spotify every time I leave the room. I hate coming back from shopping only to realise that my laptop fans have been running for hours. Poor machine.
These kinds of problems with Spotify, SpotifyHelper, SpotifyWebHelper etc. have been well-documented for years. It would kill me to work for a company with such low engineering standards.
According to Newell[1], Valve aggressively fires as it hires. It's not based on stack-ranking bullshit - more of a cultural and disciplinary fit. If you have the right personality you could thrive there, but if you need a manager to help you shine it's best to look elsewhere.
It's based on capricious and cliquish factors that aren't documented anywhere. Having the "right personality" to thrive there means knowing who to ingratiate yourself with.
The "culture" part might be good, but the end-result is Steam-- lousy software which has been lousy for decades at this point, and is unlikely to ever improve.
Long time lurker. First comment at HN. Apologies if this sounds too HR.
I had a year stint at Cloudera working remotely, meeting up with our distributed team 3-4 times/year. I was smitten with the approach they took in implementing 18 different open source project into enterprise big data offerings. They had proper software development lifecycle. There was/is lots of talent and maturity. I absolutely loved my team, the maturity and the culture at Cloudera.
Reading the Netflix engineering blog now and then, I do appreciate how many of their engineering decisions also take into account the effect it will have on their colleagues, i.e. "does this change affect how quickly/independently our engineers can do stuff"?
Netflix's stack ranking is a huge turnoff though. Netflix's philosophy is that it has no loyalty to employees and expects none in return. Regardless of Netflix's other attributes, this policy is a huge turn-off.
If I wanted great pay and cutthroat competition, why wouldn't I just work in finance? The finance industry isn't stupid. They have developer efficiency teams too.
Every company has no loyalty to its employees, they just pretend they do and thus expect loyalty from their employees. At least Netflix is honest about the lack of loyalty being a two-way street.
I think it is more enjoyable to work with people who are competent and performing well, so keeping poor performers around hurts the morale of other employees. Plus, the caliber of people Netflix hires can easily find another job where they'll be a better fit, so showing them "loyalty" by keeping them around probably hurts them as well.
How does loyalty even work? Let's you'r a valuable developer, but your performance dropped significantly for 6-12 months because you got a baby. The company should stick with you not because of loyalty, but because it's good business - they know you will bounce back once you start getting enough sleep.
Another example - you were a valuable developer, but got a crippling, chronic disease which makes it harder to concentrate. There is no hope of your productivity ever going back to "reasonable" levels. What is loyalty in this case? Should they still pay you for the years even though you can't contribute?
Your first example relies on the tired employee have specialized skills. Instead, if the tired employee were easily replaceable, then loyalty would be sticking with that person despite the fact that they could be easily replaced.
For your second example, loyalty would be working with the employee to find a more suitable position in the company (or outside of the company) and helping with medical bills and any rehabilitation.
I've read that that's how it pretty much works in a lot of Japanese companies (i.e. even when you're pretty much of no use because of bad luck (illness, accident), they give you for example a janitorial job where it's understood that little is expected of you).
That's completely at odds with Western individualistic culture though hence it's rare here. Netflix is not really an exception - if you are the "weakest link", they will just fire you after your yearly review instead of waiting for a panic fire of bottom 10-20% of staff when stock price plummets (like most other corps do).
I see the same with StackOverflow. Most of the engineering decisions they take are widely discussed on podcasts and blogs by the employees and they try to write detailed writeups of why they do what they do and how. I think it has carried over from Jeff Atwood and Geoff Dalgas when they started out on stackoverflow.
Valve's dev culture is quite good. Teams are very small and each developer can get a lot done. You decide which team you're on and what work you do. There's no manager on a dev team; there's a team lead but the role is taken on as more of a service to organize discussion rather than dictate the team's focus.
It's a very collaborative environment and requires that each person is good at figuring out what's important to work on. For those suited to it, it's a hard place to beat.
I know some people are going to be looking at this list to find potential places to go to. I urge some of you to be the change you desire. You might not be at place that currently have a great engineering culture, but you can become the origin and catalyst of that change. Read engineering blogs, papers, get new ideas and bring it forth to wherever you want.
Without cross-company exposure it's hard to answer this question, but for me, Netflix is very good at projecting good engineering culture. The fact that they build engineering tools that work in general contexts, that they write blog posts describing them, and that they open source these tools impresses me. When I read their blog posts, I see a company that's effectively solved a particular problem in a very general way that works well in specific cases too. I love it.
The degree to which Twitter open-sources its work is another thing that I like.
Biased as well, but for that other side of the world: Atlassian Engineering culture is amazing, and repeatedly ranked best place to work in Australia. Atlassian is also very actively hiring in Sydney with great relocation experience (feel free to poke me on that).
Sourcetree is a pretty crummy product regardless of how maintained it is. It reveals a culture that seems to hold basic usability testing & concepts almost in contempt.
They have amazing engineers, contribute a ton to open source, their devs travel around the world, write blogs and generally do really cool stuff. They put emphasis on clean code, maintainability and testing.
Pair programming all day, every day I thought I could handle. Turns out, I'm in no state to interface with any other human being, including my SO, at the end of a day of that. I think it's a good fit for a select group of folks who are both extroverted and technical. I also prefer having a tiny corner of my own space at work. It's comforting. At the office where I worked, everyone shared desks (you sit wherever your partner for that project is sitting at the moment) and nobody had their own space. It may be different at other Pivotal offices, but I didn't enjoy the short time I was there.
In fairness, pairing is not for everybody. We fret about whether we select for extroverts. In my experience, no, but pairing certainly takes a lot out of me.
On the flipside, we absolutely smash out the work here. I love being able to finish stuff every day, every week.
Pivotal is the first company I've worked at where I genuinely felt like I was engineering.
Most places you work have one or two people who really care. They care about people. They care about process. They care about technology, software design, about doing the right thing the right way.
At Pivotal that's everyone. I've yet to meet a single example of the shrugging "eh, it's just a job" archetype I've previously found elsewhere.
It's so incredibly hard to create this kind of a self-reflective, self-correcting culture. Pivotal's done it and under conditions of enormous growth.
Really. It's the best job I've ever had, by a country mile.
Edit: one more marker.
People come back to Pivotal. It's the first company I've seen with reverse attrition. It's common for Pivots to head to other companies and then come back in less than a year. There's no bridge-burning: if you head out from Pivotal to do something new, you leave as a friend and you can return as one.
I worked for a public healthcare company with a lot of red tape and new development in Visual Basic as recently as 2012, that also had developers leave and come back.
I got referred to Pivotal by an employee I used to work with. After passing the pairing interview it seems that I was denied further hiring progress because of a nonpoaching agreement with my current employer (a competing consultancy).
I'd love to work there but dont know what I can do.
...(Pivotal Tracker) which predates Trello by some years!
That said, I never much enjoyed using Pivotal Tracker, and Trello seems to do more or less everything it does but in a nicer and more client-friendly way.
Yes, because they do 100% pair programming. When you rely on someone else being there at the same time as you, you need predictable hours. It's possible they don't need to be as fixed as they are, but that's how they've chosen to do it.
I don't think there's a faster way to send me running away screaming. I'd actually take "100% Visual Basic" over "100% Pair Programming" if I had to choose one at gunpoint.
> Basically they hire 2 people to do 1 person's work.
Pivotal is a for-profit company. We pair program because we think it's more effective for most engineering activities (not all: most) than soloing.
I'm vastly more productive in a pair. I don't take 3 hour "5 minute" Facebook breaks. If I get stuck, my pair usually has an idea, so rather than spending a day fighting I spend minutes. Usually the discussion with a pair comes to a better design, sooner, than nutting it out by myself. Working with a pair makes me accountable -- I am far less tempted to take shortcuts with tests, code, readability, design or other important properties.
Many folk will say well gosh, they don't need a pair for these things. I envy you, brave superhuman. I have ADHD and the crippling disability of being merely mortal, so pairing is awesome for me.
I'm genuinely wondering: is pair programming better, compared to doing the design in pair, going to work on your own, then reviewing each other's code?
As an introvert I don't think I could handle the "pair all day" approach.
> is pair programming better, compared to doing the design in pair, going to work on your own, then reviewing each other's code?
The literature is, I believe, pretty thin and equivocal. However the suspicion is that pair programming is pretty much the core loop of bouncing back and forth, reduced to the smallest possible size.
It also avoids some of the antipatterns I've seen with code reviews -- widely distributed patches, reviews getting stale because they were too hard for a Monday, then a Tuesday... then a Friday ...
> As an introvert I don't think I could handle the "pair all day" approach.
You can take a break if you need one. Lunchtime is fixed at an hour. I typically go and spend it alone with a book.
There is sometimes a confusion between intro/extraversion and sociability. I'm quite sociable, I genuinely like talking to people, but it drains me because I lean towards introverted. So the lunchtime recharge is very helpful.
At some point you're going to need more than one person to understand the code and they either go through that learning process months down the road or right now when they can be most useful in shaping that code.
Facebook --- far and away the best engineering culture I've ever seen, and I've been programming for 20 years. Other companies aren't even in the same league.
Facebook has an incredibly high hiring bar. I never once met someone who I didn't feel was qualified to be there. I was seldom the smartest person in the room.
The high average engineer quality allows the company to give developers almost complete autonomy. At Facebook, you not only get to choose your team, but once you're on that team, you, not some PM or manager, decide what to work on. You're evaluated on impact twice a year, and Facebook has an expansive and nuanced understanding of "impact" that rewards things like developer productivity improvements, side projects, and removal of bad code.
Facebook encourages cross-team collaboration in a way that Google only dreams of doing. There's a single codebase unified under "fbsource", of course, but also a lack of OWNERS files. That means that it's your job as an engineer to decide what code to add, not some team of blessed approvers. There's no readability process. Teams are trained to expect people from all over the company to contribute code. It's a dream job if you want to wear lots of different hats, or if you have a maniacal obsession with following a problem to its root cause and fixing it.
One engineer famously traced a sporadic failure to a single bad register on a single core on a single server. He was recognized for it too: Facebook has a "fix of the week" program that highlights heroic fixes and clever hacks.
Facebook management "gets it" in a way I haven't seen anywhere else. Developer productivity is paramount. When something goes wrong, management doesn't overreact. The general ethos is to apply tooling to make developers better, not to add process to make developers slower.
Best of all, Facebook is fun. The code review tool, Phabricator, has built-in meme support! The internal Facebook groups are full of interesting discussion and trolling (of the good sort). The people there all feel like, well, characters. They're memorable in a way I haven't seen at other technology companies.
Best of all, at Facebook, there's none of the insufferable technical grandstanding you see at other companies. It's hard to describe --- at other companies, people with just enough competence to be annoying regularly create elaborate word-salad design documents that would fit right in at /r/iamverysmart. At Facebook? People say what needs to be said.
The most striking thing about Facebook is how it does more with fewer developers. At Facebook, you feel incredibly productive. There's always enough to do. Teams are much smaller than equivalent teams at other companies, but somehow move faster. Management trusts you --- I never once heard "you can't check that in: the technical risk is too great".
Oh, and the pay is fantastic, especially if you demonstrate extraordinary impact.
Is Facebook perfect? Of course not. After all, I'm not there anymore. Some people ragequit. The company is growing more corporate over time, little by little. Traffic in MPK is nasty. Traffic in SEA is worse. The tooling has some room for improvement --- but you're welcome to send patches! The playfulness isn't for everyone. The open allocation policy sometimes leads to duplication of work, forcing people to discard their hard work. There are few hard rules, and sometimes you don't know where you stand in the power structure.
All that said, I'd go back to Facebook in a millisecond if circumstances lined up. Despite Facebook's flaws and its inevitable slow decline, it's still the best fucking engineering culture on earth right now.
Facebook engineering is probability based. If you hire enough engineers and produce enough code, eventually some people are good and some code is good. The culture seems laughable.
How is their remote/work from home policy? How are the offices? Are they massive refurbished warehouses where hundreds of people constantly distract each other?
I'm not aware of any remote work policy, but there are the occasional remote people. Every big tech company will make exceptions for their top people and accommodate unusual arrangements, even Microsoft.
> massive refurbished warehouses
I wouldn't say "warehouses" --- the visual design is quite good, with a modernist bent. Frank Gehry designed the last few new offices.
But yes, the offices are very open. Fortunately, you don't have to be there in order to code.
What are the realistic expectations of in-office presence? Are there core hours when everyone is more or less expected to be present? Or is it accepted to hop in to the office every other day for a couple of hours of sync, and code from home otherwise?
I've worked in both modes. I've never heard of anyone being chastised for not being in the office enough --- but of course, that kind of feedback would be given in private.
I think the expectation is that you just be an adult about your work habits. Make sure that you're not slowing down the people you work with. It's up to you to figure out how to do that. One strategy is to just be in the office, but there are other options too.
(I'd say "teammates", but close collaborators aren't necessarily teammates at FB. You might work closely with someone every day and share only Zuck as the lowest common manager.)
It's whatever you want it to be. You're responsible for the impact you make, not how long you're at your desk. Facebook has high impact expectations, but if you're smart, you can have a big impact and still have a life.
Facebook culture also has a big social aspect. I think I made more personal friends at Facebook than I made in the entire rest of my career. One downside (according to some people) of this effect is that Facebook tends to become your social life. Personally, I appreciated the personal relationship formation, since it's rare to see so many smart people in one place.
I actually made a website that attempts to answer this question. My site, Devstop, provides a resource for developer certified reviews of companies' software engineering practices. The idea is to help software engineers identify the best companies to go work for. Check it out here: http://devstop.io/
You do know that there is no Yammer or Skype in London anymore? (we did have a fantastic culture though, so great it has been recognised. source: ex-Yammer.)
simply depends on how you measure/see 'best'. In some ways my tiny company is 'the best' simply because how the 3 of us design and define it. Want a different process, suggest it. Want a useful tool, build it. In some ways the 'best culture' is the one in which you follow all the rules, build foundational code, limit your hours and contribute back to open source frequently while at a giant company whose existence seems a certainty. The experiences are so varied situationally, compensationally, etc. I'm starting to think on a remote island as a nomad freelancing and/or working on your own projects. You live in a beautiful place, its often affordable, interesting cultures, etc.
I worked at Quicken Loans before, and I would have to say the culture there was one of the best I have seen/heard of. An allowance for time to work on personal projects, a healthy work/life balance, and the usual job benefits were incredible.
Be aware that the culture of an organization has little to do with the software it produces.
Actually, I haven't seen many poor organizations produce good software, lots of good organizations produce bad software.
For example, when I worked for IBM in the 90s, the organization (in Austin anyway) was great, but they couldn't get anything to market that wasn't garbage.
Why not broaden the definition of "company" to include open source software projects? If we do that, I would suggest that the Linux kernel project probably has a very successful engineering culture. I'm basing that opinion on the quality of their work, their longevity, and the incredible success of Linux as a server OS.
It's also extremely progressive. Last I heard, they had managed to hire 40% woman engineers in recent cohorts. Compare this to a ~10% industry average.
If you've worked w ThoughtWorks, I'd love to hear your experience. I'm a few floors above them in Chicago but haven't had the pleasure of chatting with anyone.
I work at TW (formerly in Chicago). We really care about doing continuous delivery well, which means a lot of automated testing, and ensuring good infra.
People give regular tech and non-tech talks, at weekly and monthly events. There is a lot of good stuff given by smart people.
The engineering culture here has been formed by years of bringing modern software practices to clients in industries where quality is important, like banks, airlines, government. There's a lot of great knowledge here, although sometimes I feel that it's a bit too inward facing. For example many many talks are given internally but not so much in the wider community.
Yep, it's an amazing place. Freedom to do stuff is enormous. They are not listed on any stock exchange so they have no fiduciary duty to generate profit. It's an amazing place full of smart people.
You've posted plenty of unsubstantive comments to HN. We eventually ban accounts that do that, so please only post civilly and substantively from now on.
Ah, Infosys! My only experience of dealing with them stands out as one of the more amusing of my career. I was contracted to lead a team for a digital agency to rebuild the front-end of one of the UK's largest supermarkets; Infosys already had an existing contract to handle the back-end and integration; the supermarket had just a couple of (not very) technical leads (glorified project managers, really) to steer everything from their end.
About monthly, the supermarket's tech leads, myself, a project manager working with me, and anywhere up to about ten Infosys employees would meet up physically in the supermarket's offices. Only one of the Infosys employees would ever address the table, and rarely at that. The others all had identical laptops (perhaps even identical clothes?), and all took notes during the meeting, but never spoke, apart from just occasionally to mutter quietly to each other.
It was absolutely surreal. Needless to say, the integration did not go especially smoothly.
* With few exceptions, engineers aren't hired for a specific team; they go through bootcamp where they get exposure to all parts of the stack and tasks from different teams.
* Ideas usually come from engineers. Managers are there to be a sounding board/connect you with people resources as needed.
* Moving fast is valued (we used to be famously known for "move fast and break things" but now it's "move fast with stable infra". I.e., our dev infra is developed with a eye towards enabling rapid iteration.)
* Lots of internal knowledge sharing.
* Scale. Probably only Google, MS, Amazon come close.
* With only very few exceptions, every engineer has access to the near-entirety of source code at FB (Oculus, Whatsapp, Instagram...).
* Internal mobility is quite straightforward; after a year you can generally transfer to teams with available headcount without a formal set of interviews.
Of course, it's not everyone's cup of tea and like any big company it's not always 100% perfect and we don't always live up to this in every circumstance, but in general this is what it's like and what we're aiming for.