5 ms·

I used to be proud of many things in the article when working at the G. Not anymore. Let me talk startup anti-Google pattern here. * Most of Google’s code is

I used to be proud of many things in the article when working at the G. Not anymore. Let me talk startup anti-Google pattern here. * Most of Google’s code is stored in a single unified source-code repository, and is accessible to all software engineers at Google This can be the worst nightmare from a management POV in a startup. Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load). The 1% I guarantee all your codebase has just been stolen by an ex-employee with malicious attempt. Instead divide your codebase into different projects/roles and people only gain access when needed. * Software engineers at Google are strongly encouraged to program in one of five officially-approved programming languages at Google: C++, Java, Python, Go, or JavaScript. We use Go for backend programing and vue (javascript) for frontend. Don't use Java if possible, keep away from C++ and definitely never Python which is a maintenance nightmare. * The next step is to usually roll out to one or more “canary” servers that are processing a subset of the live production traffic. Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage. * All changes to the main source code repository MUST be reviewed by at least one other engineer. Same as above. Just build and RTFO.

hoffs 8y ago
Why are you comparing stuff that works at big company with a lot of users and stuff that is pretty much required at a company like that, to a startup?
hknd 8y ago
How does it make sense to compare the processes of a company with >100k people touching code and products with more than 1B qps, to a startup with <5 people touching code? This comparison makes absolutely no sense.
- thetechlead 8y ago
  Because there are people who think things work at Google must work magically for their company. There are many patterns that seem perfect in theory but fail miserably in the real world. Always think different and take nothing for granted.
  - sjg007 8y ago
    "good enough for Google" == "nobody got fired for buying IBM"
quietbritishjim 8y ago
> definitely never Python which is a maintenance nightmare Did you just say that all startups should never use Python? This is such a ridiculous statement I could hardly imagine where to begin with it.
- thetechlead 8y ago
  Yes.
  - hknd 8y ago
    Dropbox started in python (and is still using it a lot) ...and we all know how horribly they failed.
    - thetechlead 8y ago
      Whether a startup will succeed has nothing to do with the language used. Google started with Python and TikTok with PHP (wtf). However when you start, go with the better choice since every line of code becomes a liability later.
      - diminoten 8y ago
        Well this makes me feel good, because I apparently write better Python than the average Googler, since my Python is entirely maintainable. Agree about the monorepo thing though, it just seems like people are optimizing for the wrong things with monorepos.
  - AnimalMuppet 8y ago
    But you also argued that things like canary servers are overkill for a startup - just get the thing built and worry about it later. Well, why not just build it in Python if that gets it built, and worry about it later?
elmozyz 8y ago
> Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage. Being a startup does not excuse this kind of cavalier attitude
- thetechlead 8y ago
  When you face life-or-death scenarios everyday as a startup founder. Not a single startup was killed by software bugs or design faults. Never. Many other things do.
  - withhighprod 8y ago
    Well if you brew an engineering culture like this, it’s no good. When you get 10+ engineers, Code reviews and most best practices are needed. And honestly for a good startup you’ll need a few senior engineers who won’t like the way of roll the fk out.
  - deleted 8y ago
    [deleted]
- matharmin 8y ago
  It actually does - having only 100 users means it's impossible to implement an effective canary system. It also means that your entire system being down affects way less people than an issue on the canary system at Google. You have way more important things to worry about in a startup than optimising uptime.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
badpun 8y ago
Whoa, are you THE thetechlead?
phonebucket 8y ago
>Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load). A developer shouldn't have time to fix other people's bugs?
- thetechlead 8y ago
  Unless you work on the project, report to the owner who has better knowledge of the code and ask them to fix. Otherwise you are not helping them but end up using their time teaching you how the code really works. Not good for the total productivity of the whole team.
  - zbentley 8y ago
    The environment you're describing is more siloed than many 5000+-engineer companies I've worked at or read about. Which is concerning, given that you describe it as a startup.
xenihn 8y ago
What resources do you recommend to new SWE hires with no Go experience in order to ramp them up?
- thetechlead 8y ago
  https://tour.golang.org/welcome/1 https://tour.golang.org/welcome/1 Go through this tutorial and gobyexample.com and they should have enough knowledge to work on a project at the end of day three, because the language is so simple. If not, fire your new hires.
zbentley 8y ago
> Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load). That's a sweatshop mentality. Startup, big corp, whatever: your engineers should have flexibility to work on things that they recognize the importance of. That's not the same as free time or a lack of tasking; that's treating people like adults who might notice things you do not. And if you're intentionally trying to manage your engineers in a way that keeps them from having time to notice bugs in others' work, you're doing yourself a fucking massive disservice: when people have collaborative ownership of something, they get invested in its quality/growth/feature-set, and productivity goes up. "Don't look at other people's code, just keep your head down and churn out the feature in time, ignore the larger picture!" is a recipe for low-output, uninvested, hard-to-reassign, burnt out engineers. Doesn't matter if it's a team of 2 or 2000.
- thetechlead 8y ago
  Your words are sweet, sir.
steelframe 8y ago
+1
elfakyn 8y ago
> * All changes to the main source code repository MUST be reviewed by at least one other engineer. > Same as above. Just build and RTFO. Deploying without review is not only a development nightmare (if you keep deploying without review, you'll eventually break something or introduce security vulnerabilities, unstable code etc.), but it can also get you in massive trouble with your compliance audits. Peer review is very important in production code.
luckydata 8y ago
I would like to know more about your reasons for thinking Python is a maintenance nightmare.

hoffs 8y ago

Why are you comparing stuff that works at big company with a lot of users and stuff that is pretty much required at a company like that, to a startup?

hknd 8y ago

How does it make sense to compare the processes of a company with >100k people touching code and products with more than 1B qps, to a startup with <5 people touching code? This comparison makes absolutely no sense.

thetechlead 8y ago
Because there are people who think things work at Google must work magically for their company. There are many patterns that seem perfect in theory but fail miserably in the real world. Always think different and take nothing for granted.
- sjg007 8y ago
  "good enough for Google" == "nobody got fired for buying IBM"

quietbritishjim 8y ago

> definitely never Python which is a maintenance nightmare Did you just say that all startups should never use Python? This is such a ridiculous statement I could hardly imagine where to begin with it.

thetechlead 8y ago
Yes.
- hknd 8y ago
  Dropbox started in python (and is still using it a lot) ...and we all know how horribly they failed.
  - thetechlead 8y ago
    Whether a startup will succeed has nothing to do with the language used. Google started with Python and TikTok with PHP (wtf). However when you start, go with the better choice since every line of code becomes a liability later.
    - diminoten 8y ago
      Well this makes me feel good, because I apparently write better Python than the average Googler, since my Python is entirely maintainable. Agree about the monorepo thing though, it just seems like people are optimizing for the wrong things with monorepos.
- AnimalMuppet 8y ago
  But you also argued that things like canary servers are overkill for a startup - just get the thing built and worry about it later. Well, why not just build it in Python if that gets it built, and worry about it later?

elmozyz 8y ago

> Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage. Being a startup does not excuse this kind of cavalier attitude

thetechlead 8y ago
When you face life-or-death scenarios everyday as a startup founder. Not a single startup was killed by software bugs or design faults. Never. Many other things do.
- withhighprod 8y ago
  Well if you brew an engineering culture like this, it’s no good. When you get 10+ engineers, Code reviews and most best practices are needed. And honestly for a good startup you’ll need a few senior engineers who won’t like the way of roll the fk out.
- deleted 8y ago
  [deleted]
matharmin 8y ago
It actually does - having only 100 users means it's impossible to implement an effective canary system. It also means that your entire system being down affects way less people than an issue on the canary system at Google. You have way more important things to worry about in a startup than optimising uptime.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

badpun 8y ago

Whoa, are you THE thetechlead?

phonebucket 8y ago

>Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load). A developer shouldn't have time to fix other people's bugs?

thetechlead 8y ago
Unless you work on the project, report to the owner who has better knowledge of the code and ask them to fix. Otherwise you are not helping them but end up using their time teaching you how the code really works. Not good for the total productivity of the whole team.
- zbentley 8y ago
  The environment you're describing is more siloed than many 5000+-engineer companies I've worked at or read about. Which is concerning, given that you describe it as a startup.

xenihn 8y ago

What resources do you recommend to new SWE hires with no Go experience in order to ramp them up?

thetechlead 8y ago
https://tour.golang.org/welcome/1 https://tour.golang.org/welcome/1 Go through this tutorial and gobyexample.com and they should have enough knowledge to work on a project at the end of day three, because the language is so simple. If not, fire your new hires.

zbentley 8y ago

> Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load). That's a sweatshop mentality. Startup, big corp, whatever: your engineers should have flexibility to work on things that they recognize the importance of. That's not the same as free time or a lack of tasking; that's treating people like adults who might notice things you do not. And if you're intentionally trying to manage your engineers in a way that keeps them from having time to notice bugs in others' work, you're doing yourself a fucking massive disservice: when people have collaborative ownership of something, they get invested in its quality/growth/feature-set, and productivity goes up. "Don't look at other people's code, just keep your head down and churn out the feature in time, ignore the larger picture!" is a recipe for low-output, uninvested, hard-to-reassign, burnt out engineers. Doesn't matter if it's a team of 2 or 2000.

thetechlead 8y ago
Your words are sweet, sir.

steelframe 8y ago

elfakyn 8y ago

> * All changes to the main source code repository MUST be reviewed by at least one other engineer. > Same as above. Just build and RTFO. Deploying without review is not only a development nightmare (if you keep deploying without review, you'll eventually break something or introduce security vulnerabilities, unstable code etc.), but it can also get you in massive trouble with your compliance audits. Peer review is very important in production code.

luckydata 8y ago

I would like to know more about your reasons for thinking Python is a maintenance nightmare.