Hacker News Reader

> 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.

Your words are sweet, sir.

> 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.

Yes.

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?

Dropbox started in python (and is still using it a lot)

...and we all know how horribly they failed.

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.

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.

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.

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.

"good enough for Google" == "nobody got fired for buying IBM"

> 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

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.

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.

> * 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.

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?

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

>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?

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.

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.

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

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.

Whoa, are you THE thetechlead?

+1