“Why does {company/app} have more than X engineers?” where X typically greater than 20/50/100.
Here’s how and why this makes sense for *the company* from a business-point of view. A thread.
1. What you see as “one app” is indeed, a lot of small parts that all contribute to the company making money.
Take the Twitter app. Almost all functionality (timeline, lists, profile, moments etc) are here to drive engagement. Then there’s ads and ad tools (I’m simplifying ofc)
2. A company never asks “how many engineers do we need overall?” They look at business cases.
“If we hire 4 engineers, we can build Lists. We expect to reduce churn by 4% annually which results in $15M/yr revenue. The cost of this team is A LOT less than this.”
3. Engineering gets funded based on business cases like this. All of it needs to make (some) financial sense. You might have loss-making units that move long-term/strategic metrics (growth, market share, coverage etc)
4. Eventually, all companies need to become not loss-making. All decisions take this into account. Engineering will ply a part in this, and large teams not contributing to the business according would get trimmed or re-allocated.
5. Companies/apps that seem to have overly large teams to *you* are either a lot more complex (Uber) or profitable (Twitter) than you think, or are investing strategically for long-term gain (Amazon, Gojek).
Took me years & making cases for team headcount to appreciate all this.
Thread on 7 things I now have more appreciation for, having experienced them first hand.
1. Marketing. "Build it and they will come" is not how products (or books) are bought. You need a marketing plan.
I put one together late: and delayed the launch to get some of the marketing ideas going. It was worth it, in the end.
2. Media exposure. My own "marketing network" was far smaller compared to exposure on a large publication (like HN). You can't really plan for or rely on this as marketing, but these are bigger waves than one can expect. @philip_kiely has a similar story.
I'm going to attempt to summarize the AWS outage on 25 Nov that impacted a good part of the internet in 6 drawings (from the 2,000+ word detailed postmortem by @awscloud at aws.amazon.com/message/11201/). A thread.
1. Meet AWS Kinesis, the realtime processing backbone of AWS:
2. Incoming requests hit the FE fleet. Each FE machine maintains a shardmap to BE clusters. Machines in this cluster do the realtime processing.
Classic setup. Except for the scale, which we can assume is massive. That "frontend fleet" is likely large. The BE fleet? Gigantic.
3. New FE machines were added to the FE fleet as per usual. A few hours later, things start to work odd. The team investigates and another few hours later they realize the root cause. It's to do with how the FE fleet works.
Each FE machine has a thread open to sync in the fleet:
I've been helping a bootcamp grad frontend dev friend prepare for interviews - they worked as a jr dev for 2 years after the bootcamp. But were out of a job the past 6 months.
They just got an offer as a JS engineer!
Thread on 10 prep resources & job market observations.
1. Interviewing for frontend positions today is HARD. IMO the web is the most in-flux in terms of interviewing approaches between backend and mobile.
You get a huge variety of interviews. Some places dive into React hooks. Others ask vanilla JS. Others algorithms / DS.
The book @intensivedata has got to be the most information-packed one I've read. Summary of all major DB storage techniques, explained in 35 pages in the book. Thread.
1. "Plain old" key-value store in a textfile 2. Indexing a key-value store (e.g. a CSV) with hash indexes (1/6)
3. Segmenting files as they grow via compaction 4. SSTables - sorted string tables (sentence of key-value pairs sorted by keys). 5. LSM-trees (Log-Structured Merge Tree) 6. B-trees: standard storage in many relational/non-relational databases (2/6)
6.1 B-tree reliability & optimization (write-ahead-logs, latches, copy-on-write) 6.2 B-trees vs LSM trees 7. Other indexing approaches: clustered indexes, covering indexes, fuzzy indexing, in-memory DBs (3/6)
18 things that companies with a good developer culture (mostly) have. A thread.
First, some basics. 1. Psychological safety & a blameless culture. You can be yourself without fear. 2. Fair compensation, roughly on par with the market. 3. Common-sense flexibility w working hours.
Next: clarity & collaboration 4. Understand the "why" before starting work. 5. A backlog that devs also contribute to. 6. Communicating directly with others, not through e.g. managers 7. Working with other disciplines (e.g. product, UX) 8. Celebrating that people take initiatives
Sustainable engineering culture 9. Functionally complete != production ready 10. Code reviews and testing are part of the everyday dev process. 11. CI and CD. 'nuff said. 12. Healthy oncall. Fixing poor oncall has priority over product work. 13. Internal open source model.
"Can you summarize this 200-page dev resume book in 7 tweets or less?"
Challenge accepted. Here we go.
1. Know what the goal of your resume is. This is what most people get wrong. It's not about your professional history. It's to get that next call with the recruiter/HM. (1/7)
2. Understand how the hiring pipeline works: who will read your resume, and what your competition is at smaller, vs larger companies.
Know that an employee referral *dramatically* increases your chances of passing the resume screen round. (2/7)
3. Use an easy-to-scan template. Recruiters do a quick scan, then a thorough scan (if they find key details in the quick scan). Make this "quick scan" as easy as possible.