161–170 of 319 posts
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
You can call it a psychological problem if you want but calling names is not a solution, nor does it really provide a good path to finding a solution. The labor market being what it is, people will leave steady jobs with good pay for more exciting work with riskier prospects and less pay. This happens all the time. Bug fixes and incremental features will generally not get you promoted for good reasons, we expect seni…
> Bug fixes and incremental features will generally not get you promoted for good reasons. This is exceptionally bad, but sadly true. If you have an engineer who can unblock teams and fix issues in an hour that others take a week or cannot fix at all, they are gonna jump ship if they can't be recognized. At that point you've lost a valuable resource.
If I can do that without it being a fluke, they’d better bump my salary.
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 h…
> 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 m…
Earlier quoted context omitted.
Sure, so here is a challenge for you. Original file: a = 1 Contributor X: a = 5 Contributor Y: a = 0 Both contributors created a pull request and submitted it. In the description they both state that the new value should be the one they put it. How would you resolve this issue in a timely fashion making sure you do not take down a service accidentally and do not slow down development too much. I intentionally gave yo…
What does google do? You’re working on a line of code and the trunk changes. Your local no longer aligns with it. You have a conflict. Someone’s changes get committed first. That’s a business decision, not a code tooling one. Second pr has to adjust. Same on both mono and poly repo, just using different words. At least branches let you have the choice, which cannot be said for branchless.
Effectively this workflow means everyone is working on the same branch and the first commit to pass review gets in. The next guy will have to rebase.
In the end one wins as you said, but the level of detail is rebasing individual commits, not merging entire branches.
So this ends up being the age-old rebase vs merge discussion.
Earlier quoted context omitted.
Yes. Blaze is the name of the binary inside Google. 90% of the code is in common. Differences are 1. integration with Google-internal tools, and 2. legacy misfeatures we plan to remove. (I work on Bazel)
What kind of internal integrations, if I may ask? Does it automatically deploy code for you on a successful build or something like that?
"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?
I had this when I worked at a large enterprise several years ago. If I recall correctly we had to state goals for each of 5 major categories and another set of 5 supplementary categories. The categories were things like - deliver customer value, enhance team work, collaborate well across teams and various other enterprise buzz words, I forget exactly.. As a coder, my goal was pretty much to write good code and avoid…
Other than the 20 percent free time, compensation and offices, the engineering culture at Google doesn’t seem to have anything special based on this well written pdf. It is in fact very similar to other large tech companies. Just in case you were still wondering what really attracts great engineers.
Also: having a FAANG company in your CV makes it super easy join any other tech company.
Earlier quoted context omitted.
> 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.
...and we all know how horribly they failed.
Earlier quoted context omitted.
Ah yes! It's not enough if you're great at your job, or even if you do other people's jobs... Instead you have to have this checklist of your quarterly goals, on which you can go through with your engineering manager on biweekly 1-on-1 meetings! And of course you should make a nice spreadsheet and a confluence page documenting your progress, since we're data driven :) Did you fix a major fuckup in some legacy compone…
> Did you fix a major fuckup in some legacy component? What if that legacy component was no longer in use? Is there some bigger picture in play? I've been at bad companies before, so I understand being cynical. But, having people just do whatever they feel like also does not work. From the outside it looks like Google has quite a bit of this, so they are clearly trying to get people on some path. The messaging app si…
He was actually assigned by his manager to investigate the problem. Source: am a programmer.