People plan and think before they code.
People are rewarded for impact, not for landing useless code.
Code is carefully designed and tested, or it doesn't land.
Impact rules all, not velocity.
Well good for you. Either one of us has had an anomalous experience, or...
> People plan and think before they code.
"Planning and thinking" != design process. Of course people plan and think. I plan and think before I go to the grocery or hardware store. Of course it's only for a moment, and the typical process I've seen at FB is a lot closer to that than to the design processes I've seen elsewhere in nearly thirty years producing software.
> People are rewarded for impact, not for landing useless code.
Again, you're playing extremes against the middle to paint a picture more favorable than accurate. Very little code is totally useless. However, I've seen plenty of "impact" awarded for code that made a very tiny increment in functionality, far outweighed by the missing/misleading metrics or spurious alarms or outright bugs in something even the author knows will be replaced next half. Every day I encounter stuff that's broken as a result. This morning it was a distcc script that nuked a build, because someone's desperate to get their impact in before the end of the half. I can't count the number of times I've followed the trail back from an incident to a diff with "test in prod LOL" or some such for its test plan. So "carefully designed and tested" just isn't true in general. The common case is very far from that.
When it comes to software design though, the design of your infra is what matters most, since everything else is built on top of it.
Genuinely curious.
Their approach is almost certainly not the right approach for you, because you are not Google ( https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb ). That said, if you are looking for a position at these places, then the blogs might help you, in a number of ways. If you want to work there though, focus on the sound engineering techniques applicable anywhere (maps, hashing, trees, graphs, algorithms) and build a reputation through Open Source contributions to the projects the companies are involved with.
* Tim Bray / Amazon / https://www.tbray.org/ongoing/
* Steve Yegge / Ex-Googler / https://steve-yegge.blogspot.com/ and https://medium.com/@steve.yegge
* Facebook Engineering Blog / https://code.fb.com/
* Google Developers Blog / https://developers.googleblog.com/
- No waterfall-ish process where design is handed down from architects to senior engineers to juniors. The same people do design, implementation, ops and so on.
- Measure everything and always. People are encouraged to define metrics and goals and create dashboards before writing code
- Simplify: decreasing complexity is taken more seriously than in other companies. Do not use a database when you can use a file, or a message passing library when you can use a socket, or 200 lines of code when you can for out to "grep | sort". This can be surprising to new hires.
kindly explain that logic
The design process at Google started with a design document. There was a template that I think was available online a long time ago but (ironically) I can no longer find it. The template was relatively lightweight and had some headings like so: Introduction, Goals, Non-goals, Overview, Detailed design, Security, Privacy, Testing. Compared to other design doc templates I've seen it wasn't heavy on software engineering theory. Of course the bulk of the writing would be in the "detailed design" section and subsections.
Good design docs were very detailed. One I wrote ended up being, I think, about 40 pages by the end when printed out, and that was not an especially large or unusual document. Design docs for critical systems could be larger still, or more frequently, split into many other docs. The quality of writing was generally high and they were maintained in version control. There was a mailing list where design docs were posted for company-wide review, though by the time I was there, this process had degraded quite a bit and a lot of stuff was done in team-specific design docs in Google Docs, with relatively minimal or no peer review. I felt that it was common for the less "serious" teams to do this, e.g. teams working on the latest chat product or on Google Apps itself. Those docs tended to be shorter, only partly filled out, or non-existent. The closer to the metal, older-school stuff was all hand-written HTML.
Good design docs would be kept up to date as the design evolved, although I'd say that was the minority. Most designs were the work of a small number of people or just one person. There were not many design review meetings that I recall, though probably that varied a lot by team.
Diagrams were minimal, possibly because there weren't any good diagramming tools available internally (well, there was graphviz and TeX).
Data structures would often be designed up front as long as they were either protocol buffers (i.e. inter-server comms or long term data storage), or fundamental to what the system did as with BigTable, indexing, index serving, ad serving etc. Systems where the data structures weren't fundamental to the design didn't necessarily plan out every structure in advance of course, by no means. For many products the user interface or network protocols were more important, so that's where the design docs would dwell.
The most senior engineers were very familiar with the performance costs of things, e.g. the cost of an L2 cache miss vs a disk seek, and that deeply informed the design of many systems.
That's about it.
"Show me your flowcharts and conceal your tables [i.e. data structures], and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
A tech firm is most easily defined as a company founded and run by a software or hardware engineer. The only exception I can think of is Apple, but Jobs was immersed in engineering culture from the time he was a teenager - he was sort of a sphinx in that regard. Even so, it's fair to say Apple under Jobs is maybe more of a high-end design house than a traditional tech firm: their in-house talent struggled with online services and anything involving complex computer science R&D, e.g. their AI / mapping efforts were weak sauce compared to Google.
My previous projects were me coming onto an existing project, or were small enough that I had 50% of the code done before the next person helped out :)
i'd say it comes down the maturity of individual engineer or group how they'd approach a problem. some problems are worth spending time most aren't and every problem is not at global scale trust me.