All of these ignore files exist to work around other packages it's not git or docker or dropbox's fault that some tool you use contaminates your working directory. But you can compare this to something like go, which puts all modules in $GOPATH/pkg/mod and if you want to check in your modules, you run "go mod vendor" and it creates a vendor/ directory in your working directory to check in. It is reasonable to check in your dependencies, in which case node's strategy is fine. To summarize, I think the problem is that node puts packages in your working directory instead of some other location, causing you to have to ignore them.
OCI container builds ("docker images") are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm/container, copying a working directory into the container, and running random shell commands). Thus there are no artifacts to gitignore. If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). I think the problem here is poor tooling that contaminates your working directory. Maybe it's more important to take longer to build stable, complete features instead of shipping as fast as possible Maybe the urgency to keep improving your product disappears after you feel that you've made it Maybe developing features takes longer because there's more process: security/legal/ops needs to review it, several layers of management need to approve it, it needs to work in multiple countries, etc Instead the new engineers work on important, but auxiliary things, like dev tooling, security, infra, ops, etc Maybe the engineering division grows substantially, but the number of people actually working on the product doesn't change much.
Maybe the company leadership's focus shifts from building a great product to scaling as fast as possible. After a product is "done", adding more functionality makes it worse, not better. You'd think that with more engineering/PM/design talent the product would get better, and faster.Īnyone have any insight into why happens? I've never worked at a early stage startup but here are some hypotheses: It's strange to me that Dropbox has thousands of employees, people have wanted this for a _long_ time, and yet this hasn't been built.
It's unfortunate that as startups get larger, the speed of improvement on their product often gets slower.
0 kommentar(er)
