This is my personally curated list of books, blog posts, essays, papers, articles, keynotes, talks and any kind of tech-related content that I find awesome.
If you have found something awesome on the internet and want to share with me, sure, I
like learning about stuff! I can easily be reached by the email on my GitHub profile or
on Twitter. But unlike most awesome-stuff repositories this is a personal list so I'll
not really be taking recommendations 😬
-
Autopilot: workload autoscaling at Google · Rzadca, Krzysztof, et al. · Paper
Paper about a vertical autoscaler developed by Google for Borg workloads. The math may or may not interest you but one thing that I liked is their admitance that estimating resources is hard that users are incentived to overstimate workloads.
-
Falsehoods Programmers Believe About Names · Patrick McKenzie · Article
This is just too good to not be here. Names are messy, and very likely any assumption you make about them is wrong. I remember about it every time I have to type my name in an Airline's website and it doesn't fit.
-
So you think you can validate email addresses? A journey down RFC5321 · Stavros Korokithakis · Video
Like the previous article, but instead of being about names, it is about email adresses. The very real answer is "check if there's an
@and then try to send it an email; if it doesn't bounce it's good". And no, regex is not the answer. My takeway is that unless you are the domain expert, make the bare minimum ammount of assumptions and validations on any data you have to handle. -
Queues Don't Fix Overload · Fred Hebert · Article
A convincing article on why queues are not the end-all solution to rate limiting your slow web application. If you do apply it as a staple overload reliability mechanism, you will get much more complex systems that once they fail will fail much harder, so think carefully. It also introduced me to the concepts of back-pressure and load-shedding: "You'll need to pick what has to give whenever stuff goes bad. You'll have to pick between blocking on input (back-pressure), or dropping data on the floor (load-shedding). And that happens all the time in the real world, we just don't want to do it as developers, as if it were an admission of failure."
-
Configuration Is (riskier than?) Code · Jamie Wilkinson · Video
Great presentation! It asks if there are really any fundamental differences between code and configuration (there isn't) and presents evidence that changing what we perceive to be configuration is riskier than code. Ironically, there's much better tooling and rigour involved when working with code, as often configuration won't have tests, static checkers or even any form of version control. I believe Accelerate corroborates this: "keeping system and application configuration in version control was more highly correlated with software delivery performance than keeping application code in version control. Configuration is normally considered a secondary concern [...] but our research shows that this is a misconception."
-
Are We Really Engineers? · Hillel Wayne · Article
Part 1 of Hillel's "Crossover Project". A thoughtful look into the old-age question of "is Software Engineering really Engineering" (which is unfortunately often expressed in bad faith with the intention to to gatekeep). Followed by Part 2 "We Are Not Special" and Part 3 "What Engineering Can Teach (and Learn from) Us".
-
Serverless Computing: One Step Forward, Two Steps Back · Hellerstein et al · Paper
I've read it a long time ago and, being from 2018, some things might be outdated. Some of the things I remember is while AWS Lambda has its strenghts (pay-as-you-go, autoscale), a full serverless architecture presents several I/O performance constraints compare to a more traditional EC2 architecure. Cindy Sridharan has some good highlights on her Twitter. Highly recommend viewing Table 1 (but, again, I can't guarantee it hasn't been somewhat deprecated given the timeframe).
-
Understanding Clojure's Persistent Vectors (pt. 1 / pt. 2) · Jean Niklas L'orange · Article
Interesting articles on Clojure's Persistent Vectors, a data structure invented by Rich Hickey which gives practically O(1) runtime for appends, updates, lookups and subvec. When I first heard about it I thought it sounded weird; what's up with the constant speed (hint: the word pratically is doing a lot of heavy lifting here)? And why the heck so-called Lazy Sequences always return a chunk of exactly 32 values when realizing its value? Well, these misteries are explained in the articles linked above. Also, if you are that kind of person, you can read the paper that inspired Persistent Vectors: Ideal Hash Trees · Phil Bagwell
-
Command-line Tools can be 235x Faster than your Hadoop Cluster · Adam Drake · Article
Well, exactly what the title says! Fun examples of how an intelligent use of basic unix commands such as
catorawkin a modern laptop can yield better results than a much more powerful Hadoop cluster for certain tasks, such as text processing. I mean, check out this quote: for the same amount of data I was able to use my laptop to get the results in about 12 seconds (processing speed of about 270MB/sec), while the Hadoop processing took about 26 minutes (processing speed of about 1.14MB/sec). -
Mailinator Architecture · Todd Hoff · Article
A short article on mailinator.com architecture. Warning, it is from 2008 so highly dated. Yet, it is an interesting story about how a Java App running on a box that's worse than a current-gen t2.micro was still processing 75 reqps, handling DDOS and supposedly had 99.99% availability. Surely the application is relatively simple and most modern business have very different constraints - if nothing else, the right HA architecture can make mantaining your service as a team much easier. At the same time, while it is very hard to compare workloads, I'm used seeing microsservices being provisioned with 10 times as much resources to serve a tiny fraction of the load, so I feel there's still something to learn from this piece.
-
The Problem with the 5 Whys · Alan J Card · Paper
Best critique of the "5 Whys" technique that I have ever read. Essentially, it "insists on a single root cause as the target for solutions and assumes that the most distal link on the causal pathway [...] is inherently the most effective and efficient place to intervene". If nothing else, you ought to check out this outstanding representation of the "causal and contributing factors tree diagram" that different teams might arrive by each applying the "5 Whys" technique independently at the same incident.
-
The Infinite Hows · John Allspaw · Article
If you have enjoyed the previous paper about the 5 Whys and want more, this is a good read. John explains why the 5 Whys also isn't that much of a good idea for Software Engineers working with complex distributed systems, gives you an alternative technique and drops a lot of links so you can spend a whole afternoon reading about the topic.
-
What happens when you add a new teller? · John D. Cook · Article
This article explores a typical example from queuing theory (disclaimer, I didn't really study queuing theory besides reading a few articles such as this one). The whole idea is that, given the problem's constraints, the difference between having a single teller in a bank would make customers wait nearly five hours on average. Add a second teller and the average wait time goes down to just 3 minutes! What? There's some funny math involved but the results can be extrapolated to workers consuming from a queue, and it's something that can happen if the queue is close to saturation (i.e. the processing rate is very close to the consumption rate). I think the conclusions here are a) avoid leaving your queues close to saturation and b) if they are close to saturation doubling your workers might give you a much larger performance boost than expected.
-
My Lessons from Interviewing 400+ Engineers Over Three Startups · Marco Rogers · Article
My favorite article about hiring software engineers. There's a lot to take from it, but my favorite is that, as a hiring manager at a fast growing company, you probably need to be interviewing a lot more. Hiring is a noisy process and the steps at the beginning of the funnel have very low confidence (and, in my opinion, are easier to gatekeep); so if you want to build a strong team you need to create a system that allows the team to interview multiple candidates for each hire. Instead, I have met hiring managers at startups that were more worried about creating barriers to filter out candidates.
-
Tell candidates what to expect from your job interviews · Julia Evans · Article
Well, what's on the title! It helps to "level the playing field", so to speak. I mean, Stanford has a course that prepares students for the standard Software Interview, and students from top-level Universities in other countries will gain similar advantages through networking. I'm confident that a lot of candidates for any given company are either hired because of a referral or will have a friend inside give them some tips about the hiring process. All this means that candidates without a strong networking and/or a non-traditional background and/or URMs (a lot of overlap here) will be at a disvantadge. The solution? Level the playing field by telling everyone what to expect of your process in advance.
-
Salary Negotiation: Make More Money, Be More Valued · Patrick McKenzie · Article
Very good article on Salary Negotiation for Software Engineers. If you read one piece on the topic, make it this one!
-
Sonia Gupta and Corey Quinn - Embarrassingly Large Numbers: Salary Negotiation for Humans · Corey Quinn & Sonia Gupta · Video
Fun video on the topic.
-
Don't Call Yourself A Programmer, And Other Career Advice · Patrick McKenzie · Article
Good piece on the realities of the industry and how to present oneself. Somewhat US-centric but I think it applies to other markets. There are a lot of great advice. Amongst them "Engineers are hired to create business value, not to program things" (which ought to be obvious, but very good to remember) and _"Read ad. Send in resume. Go to job interview. Receive offer. is the exception, not the typical case, for getting employment” (which is not obvious at all for the majority of people).
-
The Holloway Guide to Equity Compensation
A very, very, very long but very compreehensive resource on Equity. Of course some of the information, specially tax-related, is geographically bounded to the US, but I think it is still a very useful read if you might earn or negotiate any form of Equity anywhere in the world.
The references here are mostly kept for their historical significance but likely don't have much application on modern technology.
-
Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO · Steele, Guy Lewis, Jr. · Paper
Keeping this in my pocket mostly in case I ever hear someone arguing that an extra function call would impact performance and I need something to smack the doofus back to the 70's with.
-
Structured Programming with go to Statements · Donald E. Knuth · Paper
The paper that popularized "pre mature optimization is the root of all evil", although there's an earlier source from November. The paper is a discussion about
Structured Programmingand the pros and cons ofgo tostatements so it is very dated. I list it here because of one interesting curiosity: although oft-quoted as a warning against any kind of optimization effort, Knuth's words are very specifically a comment on sacrifing legibility to optimize non-critical parts of the program. In fact, he writes it just after using multiplego-tostatement to increase the performance of a program by 12% and complaining about how most software engineers wouldn't consider such improvement worthy of their attention. He still concludes that "premature emphasis on efficiency is a big mistake which may well be the source of most programming complexity and grief" and that "we should strive most of all for a program that is easy to understand and almost sure to work" but I nevertheless think the original context gives the quote a new meaning.