3 ms·

Speaking from my experience as an intern at Microsoft, I really wish there was more focus on training. I've heard from a lot of praise about the quality of code

by remar 12y ago

Speaking from my experience as an intern at Microsoft, I really wish there was more focus on training. I've heard from a lot of praise about the quality of codelabs from friends at Google and never received anything like that when I was working. I was basically just given a project and expected to pick up things by asking people or reading some half-outdated sharepoint pages. From speaking with other interns it seems their experiences varied entirely based on their teams. The impression I got was that it was really fragmented across teams and that each team felt like it had its own way of doing things. I'm not exactly sure how it is at Google but I've heard from a friend that the entire company works on a single shared codebase. The project I was working on had 3 different forks of the framework I was developing (that I knew of), each maintained by different teams. Basically, the impression I got was that everything just felt really fragmented and that I was only working with my team rather than with an entire company. I should mention that this was my 2nd software development job ever so maybe this is normal for lots of companies and that Google is one of the few companies doing it right, but the experience didn't really leave me with lots of confidence in the engineering environment/culture of the company. I've heard tons of good things about the engineering culture at Google so I'm considering if I should try applying there.

mike_hearn 12y ago
Ex-Google engineer here. The way Google does things is indeed very rare, your experience at Microsoft is more typical. Note that the path Google chose isn't easy! As the codebase got larger and larger they had to basically design and build their own build system, a distributed unit testing engine, custom code refactoring and hyperlinking tools, do major IDE modifications to Eclipse to make projects even loadable, eventually even build their own version control system because no other VCS scaled to the sizes and speeds they needed. They invested a TON of time and gold into allowing a single codebase to scale like that; it's practical if you're sitting on a hosepipe of money and you can hire brilliant engineers then assign them to build tools, but it's probably not practical for most companies despite that the resulting environment was quite pleasant. That said, although the codebase was remarkably consistent, there were still variations. The most notorious was the split between the C++ and Java codebase. Some frameworks were written in c++ and bound into Java using things like SWIG. Others were bound using cross-process RPCs. A lot of smaller libraries were simply written and maintained twice. The culture was different too. Some Java codebases were way over the top of excessive abstraction and use of dependency injection, making them an absolute nightmare to understand or debug for newcomers. Others were simpler and more understandable (typically the older ones). The C++ side felt much more light weight, but on the other hand, it was largely stuck in the 90s, with memory management being entirely manual even in cases where conservative GC could probably have helped avoid mistakes. When I left C++11 was in the process of being whitelisted one feature at a time. The biggest problem with the culture I had at the time I left (and was one reason I decided to pack my bags after 7.5 years there), was that basic tasks were becoming more and more bureaucratic. Often this was due to poorly designed processes put in place in a panic after some PR disaster around privacy or data handling, like Street View or Buzz. Sometimes it was just because some engineer needed to redesign a widely used system in order to prove they were being "impactful" and get promoted even though it wasn't really broken. There was a running joke there that there were two versions of every tool, the deprecated one and the one that didn't work yet. It started out as a lighthearted take on the companies rapid progress and by the end unfortunately just reflected a sad reality. As an illustrative example, around the time I started to step back, one member of my team had spent on the order of 6-8 weeks attempting to simply download a file via HTTP in production, from our own servers (was a self test). This task involved filling out forms, arguing with the owners of the HTTP download service (the old one didn't require this process but was deprecated), discovering that the new version was hopelessly buggy and was breaking random products for end users without anyone on those teams noticing, etc. This is a task that could be accomplished in two minutes with a random Linux VPS and "wget" but turned into an epic struggle against a Kafkaesque corporate disaster zone. The problem was not that one team was poorly performing though: the problem was the company had lost the ability to pre-emptively catch this or even recognise that there was a problem. Most team members were happy to just collect a paycheque each day; if they got paid for filling out forms justifying why they needed the "fast reliable" HTTP download service instead of the "slow unreliable" service, why worry? Best not to rock the boat.

by remar 12y ago

mike_hearn 12y ago

Ex-Google engineer here. The way Google does things is indeed very rare, your experience at Microsoft is more typical. Note that the path Google chose isn't easy! As the codebase got larger and larger they had to basically design and build their own build system, a distributed unit testing engine, custom code refactoring and hyperlinking tools, do major IDE modifications to Eclipse to make projects even loadable, eventually even build their own version control system because no other VCS scaled to the sizes and speeds they needed. They invested a TON of time and gold into allowing a single codebase to scale like that; it's practical if you're sitting on a hosepipe of money and you can hire brilliant engineers then assign them to build tools, but it's probably not practical for most companies despite that the resulting environment was quite pleasant. That said, although the codebase was remarkably consistent, there were still variations. The most notorious was the split between the C++ and Java codebase. Some frameworks were written in c++ and bound into Java using things like SWIG. Others were bound using cross-process RPCs. A lot of smaller libraries were simply written and maintained twice. The culture was different too. Some Java codebases were way over the top of excessive abstraction and use of dependency injection, making them an absolute nightmare to understand or debug for newcomers. Others were simpler and more understandable (typically the older ones). The C++ side felt much more light weight, but on the other hand, it was largely stuck in the 90s, with memory management being entirely manual even in cases where conservative GC could probably have helped avoid mistakes. When I left C++11 was in the process of being whitelisted one feature at a time. The biggest problem with the culture I had at the time I left (and was one reason I decided to pack my bags after 7.5 years there), was that basic tasks were becoming more and more bureaucratic. Often this was due to poorly designed processes put in place in a panic after some PR disaster around privacy or data handling, like Street View or Buzz. Sometimes it was just because some engineer needed to redesign a widely used system in order to prove they were being "impactful" and get promoted even though it wasn't really broken. There was a running joke there that there were two versions of every tool, the deprecated one and the one that didn't work yet. It started out as a lighthearted take on the companies rapid progress and by the end unfortunately just reflected a sad reality. As an illustrative example, around the time I started to step back, one member of my team had spent on the order of 6-8 weeks attempting to simply download a file via HTTP in production, from our own servers (was a self test). This task involved filling out forms, arguing with the owners of the HTTP download service (the old one didn't require this process but was deprecated), discovering that the new version was hopelessly buggy and was breaking random products for end users without anyone on those teams noticing, etc. This is a task that could be accomplished in two minutes with a random Linux VPS and "wget" but turned into an epic struggle against a Kafkaesque corporate disaster zone. The problem was not that one team was poorly performing though: the problem was the company had lost the ability to pre-emptively catch this or even recognise that there was a problem. Most team members were happy to just collect a paycheque each day; if they got paid for filling out forms justifying why they needed the "fast reliable" HTTP download service instead of the "slow unreliable" service, why worry? Best not to rock the boat.