5 ms·
Platform fetishism[1] and attempts to throw developers under the bus[2] aside, the comment from Nick Kwiatkowski states a much better reason: developers weren't
by strlen 16y ago
Platform fetishism[1] and attempts to throw developers under the bus[2] aside, the comment from Nick Kwiatkowski states a much better reason: developers weren't empowered do their jobs.
The comments state that there was no staging or test environment, no ability to roll back releases, refactoring was a dirty word (engineers wanted to refactor, but couldn't), principal on technical debt was never paid (only the interest in terms of hacks to make the site scale-- again, product organization prioritized new features).
The rest: location, technology choice aren't sufficient to "kill" a company: there are successful companies in LA, there are successful and agile companies using Microsoft stack (where appropriate-- see Loopt and StackOverflow/FogCreek as examples of companies using both FOSS and .NET). On the other hand, they're not optimal either: they aren't what engineers would choose themselves most of the time.
This indicates that the technology and location choice aren't the cause, they're symptoms of company management that doesn't understand building non-trivial Internet applications (what the optimal technology stack for one is; where, when and how to hire developers to build one) and yet maintains authority to make all technical decisions. Contrast this with Facebook, Google et al-- where every process (from corporate IT to production operations to HR and recruiting) is designed with needs of the engineering organization in mind: "Want two 24" monitors? No problem. Want Linux on your laptop? No problem. Want ssh access to production? No problem. Want to fly in a candidate to interview? No problem."
[1] I personally wouldn't touch Windows with a sixty foot pole, but speaking objectively C# >3.0 and (especially) F# are great languages.
[2] "They weren't talented": having interacted with some ex-MySpace engineers, this just isn't -- at least universally -- true. Indeed, here's a secret to hiring in an early (Facebook in 2005) startup: seek out great developers who work for crappy companies, people who have joined "safe bet, resume brand" companies like (post ~2003) Google aren't likely to join you until you've already become a "safe bet, resume brand" company (Facebook in 2008-Present).
- chollida1 16y ago> Contrast this with Facebook, Google et al-- where every process (from corporate IT to production operations to HR and recruiting) is designed with needs of the engineering organization in mind: Completely agree. > Want ssh access to production? No problem. This makes me a little uneasy, I'm not sure everyone should have ssh access to the production server.
- strlen 16y ago> This makes me a little uneasy, I'm not sure everyone should have ssh access to the production server. Every _developer_ should. No question about it. Sudo should given on an is-needed basis, but ultimately, as a developer I can screw up a lot more by simply writing bad code. Simple philosophy: you build the software, you should be involved in running it (including carrying a pager). Amazon's CTO agrees: http://twitter.com/#!/Werner/status/50957550908223490 http://twitter.com/#!/Werner/status/50957550908223490
- chollida1 16y ago> Every _developer_ should. No question about it. Sudo should given on an is-needed basis, but ultimately, as a developer I can screw up a lot more by simply writing bad code. Fair enough. This, more nuanced point, I agree with.
- flyt 16y agoIf you can't trust engineers to work in production, then you can't trust their code. Extensive logging, auditing, and granular access control are also critical to making this work in a large engineering org.
- ianhawes 16y agoI don't think it's a matter of trust but rather mitigating your exposure to hackers.
- strlen 16y agoHow does shutting of ssh for developers mitigate exposure to hackers? Require everyone to use an ssh key with a (strong) pass phrase, require strong passwords and two factor authentication. You already should do so for the operations staff (who needs ssh access), same should happen to developers. Ironically, if you treat production as an alien land developers aren't allowed into (and have no transparency about), you're going to create an environment where developers completely ignore operational concerns like security (e.g., having no authentication mechanism on their own services, as it's presumed production is a "magically secured" environments where no one may connect to in any way).