DEV Community: Robin Palotai

How to be a Better Husband & Why it Makes Daily Standups Foolish

Robin Palotai — Thu, 07 Nov 2019 09:55:20 +0000

To the day I remember my turn in a daily standup 10 years ago, feeling quite foolish. As per the book, I should have said something like "Yesterday I fixed the indexer bug and updated the user documentation, and today I'm going to add batch support to the load pipeline."

But in reality, I said "Yesterday I was working on the indexer bug, and I will continue so today.", for the third day in a row.

So was I really working on the indexer bug all that time? Or was I just slacking? How does this relate to becoming a better husband? You will find out after a short detour.

While I don't agree on all of the points delivered in The gender wars of household chores, it is an enlightening read with a practical takeaway.

I'll summarize below, but maybe you want to read it yourself first. If inpatient, jump to the "...when I decide to take care of a simple chore.." part. The header image of this article is taken from that part as well.

(Waiting here for you to return.)

The illustration depicts that usually, when a husband is asked to fill the washing machine, he does so and that's it. In contrast, the wife would pick up all sorts of accidental chores on the way there, like refilling soap, putting away toys lying accross the floor, etc. What started out as a single chore became a bunch of loosely related tasks due to it made sense to batch them.

Now you might suspect how this relates to programming.

Ideally, we are expected to come up with a plan, estimate the time it would take, and execute precisely. But let me tell about my day yesterday (even if it was not a Monday).

While sipping the last drops of coffee in the morning, I drew a small dependency graph of recent tasks, and concluded that working on indexing (again) is the most important. As I reached for the keyboard, an email popped in carrying a UI bug report from a user. As a usability bug trumps backend improvements, I started on it.

(Technical detail): The bug was about some input element acting up after the user tabs away from the browser and back. Indeed, when tabbing, first the element loses focus, then the window, finally they get it back in reverse order. But from the user's perspective, there was no focusing happening, so the action specified in onfocus didn't make sense.

Fine, I started adding a UI test to replicate the behavior. But as it turns out, creating a new tab using puppeteer doesn't trigger the window.blur or focus events. Ok, this is not my fight, so added this test to the list of manual tests.

To fix the bug, I began to add some complicated logic about detecting this focusing situation. But it became nasty quickly, so I took a step back. I started fixing focus, since we used focus in the first place. But I could just change the element to react to click instead of focus. That avoided lots of trouble and made the code simpler.

While trying to run the integration tests, I stumbled upon some caching issue in the build system. I couldn't let that lie around, so took some time to devise a fix.

Time to push a release then! But it would nag the users to reload the UI, and I wanted to do some other UI updates. So it made sense to do those and do a batched release.

I'm not going into further details about those (adding a privacy policy, now that we have a great one, or cleaning some spooky skeletons around session handling). But you can see how a small task snowballs into a set of changes that just makes sense to do while you are there in the context.

So was I slacking back then? Maybe. Probably. But more likely I was stumbling into a cascade of unforeseen issues, reporting other bugs I encountered to be revisited later, running the tests and fixing the test runner, etc.

What are the takeaways?

(Read the free sample of my in-progress book Programming without Anxiety for more tips.)

Unscheduled - or even unnoticed - tasks slow down completion of the original goal. But performing them while in the right mental context pays off on the long run. That said, if you are not in the right context, rather file a bug report about them for later.
When hitting an unexpected task, take a step back and ask: Is there any alternative solution? Is this the right time for this fight? Otherwise, you can be down the rabbit hole quickly.

(Attribution: Hungarian folklore pattern from an artist on Meska, the Hungarian Etsy; Header image from The gender wars of household chores)

Mastering Back of the Envelope Calculation for System Design Interviews

Robin Palotai — Tue, 24 Sep 2019 07:31:01 +0000

Back of the envelope calculation:

~ A quick and approximate calculation that gives us further insight.

It is named so, since you can typically carry out the calculations on the back of an envelope or a napkin. Note: for interviews, these should be called Side of the Whiteboard Calculations.

Why do we need it?

Sometimes we face a choice between alternative architectures. At simplest, we can ask if a single server is sufficient? If not, how many servers would we need? A quick calculation gives us a rough estimate.

Generally, the calculation tells us

if the architecture can fulfill the functional requirements, for example number of supported users, response latency,
the resource requirements.

How to do it?

First, we need to recognize a limited resource in our system, then approximate the actual usage. For example, our servers are capped by 2GHz CPUs, and we would like to know if we can serve all user requests using a single server.

So how to approximate the actual usage? We need to break down the usage to its constituting factors, make a rough estimate of those factors (if needed, further breaking them down), and combining them.

For example, we might expect to have 1K active users, each issuing 15 requests per day. That's 15K requests per day, or 15K/86400 requests per second.

When combining the parts, a trick is to round aggressively. Noone wants to divide by 86400. So let's round to 20K/100K, leaving 0.2 seconds time available to serve a single request. If we know that a single request roughly takes 0.7 seconds to serve, we need to bring up at least 4 machines. Of course you don't want to live on the edge, so let's add some buffer and make that 10 machines (which is also a nicer number).

On quick operations

Prefer using small numbers along with abbreviation for magnitude (or, if needed, exponents) rather than writing out a full number. 10K instead of 10000.

If given a large and overly-precise number, for example 7432, instantly convert and write it down as 7K. You are approximating anyway.

Having numbers in this form makes multiplication and division fast. K*K is M. G/M is K. 4K*7M=28G. To work with larger numbers, round both of them towards a small multiple of a power of 2 or 10.

27*14 ~ 30*10 = 300.
6500/250 ~ 6400/256 ~ 100 * 2^6 / 2^8 ~ 100 / 2^2 = 25.

Dimensions to approximate

Find typical limited dimensions, along with exercises below.

Network bandwidth

Assuming 1Gbps link per machine, if we want to crawl 70TB of websites every day, how many machines would a crawler system need?

Storage space

How much space would it take to store the contents of 100M web pages? What if we substitute each word by an integer index? How many machines of 64GB SSD would it fit?

IO throughput

You store fetched web pages on a mechanical hard drive, with limited random access speed. Users issue requests with 100 query per sec (qps), each request typically returning the content of 20 pages. How many hard drives would you need to keep request latency low?

Engineering effort.

You need to deliver a new feature. There are 5 programmers and 40 tasks. How many weeks until possible launch?

Money.

A user pays $10 a month for your image store service, storing all their photos, each downsized to 3MB. During a month a user fetches 1K photos. Find the pricing page of your favorite cloud provider, and calculate the cost associated with each user. How much is your revenue per user? Check for different assumed photo counts.

Others include CPU time, RAM size, latencies of various kinds (disk access, RAM access, network), thread count.

Where to start?

Enumerate typical use-cases of the system and determine the most critical resources they need. A document store will need lots of storage. Guesstimating document sizes and counts is a good start, but further details will depend on usage. How often are new documents added? Are the documents searchable? Do we need any indices? Is it a write-heavy or read-heavy store?

Different use-cases will likely need very different shapes of resources. For example, serving the documents might need lots of RAM but not CPU, while preprocessing of new documents just the other way around. Hosting all those services on homogeneous machines would waste both CPU and RAM, since you need to get machines which are maxed on both dimensions.

Such differences indicate those features should be split to different services, hosted on independent sets of machines.

Real data

Outside of system design interviews, you can reach out to actual data. Spend some time mining the monitoring dashboards to get usual CPU usage. Perform a load test to measure peak RAM consumption. Run a SQL query to get the average number of photos stored by user.

It doesn't need to be an either-or. Complement assumptions with data-backed facts if needed.

Useful resources

A summary of numbers every engineer should know. Or know where to look up ;)

Note: Originally appeared at https://treetide.com/posts/back-of-envelope-calculation, which I wrote in response to a mentoring session I held at CodeMentor.io. I'm available for 1:1 sessions there.

Your Textbooks Might Be Outdated

Robin Palotai — Mon, 09 Sep 2019 11:52:07 +0000

Originally appeared as part of Getting the Max out from Education on treetide.com.

As Paul Graham puts it in his excellent high-school graduation speech, even college textbooks are bad.

When you get to college, you'll find that (with a few stellar exceptions) the textbooks are not written by the leading scholars in the field they describe. Writing college textbooks is unpleasant work, done mostly by people who need the money.

Here's my take on how to get the most out of your education by finding the best material. We'll take the Operating Systems class as our scapegoat:

Don't assume your textbooks or curriculum is of the best quality.

What textbooks do people advise on forums? A search on reddit can be insightful. Ask around in your private student group as well!

What do other institutions teach? Google "operating systems cs inurl:edu$".

Try to get hold of a heavy book.

Books take effort to write, and are hard to update. These makes it likely that the content went through proper editing and lays out time-tested foundations. Amazon seems to have a nice selection here.

Once you have the book, don't hold back. Pop it open at interesting chapters, use the highlighter, scribble your questions and ideas all over the margins!

(If you like these tips, subscribe to TreeTide articles)

Complement solid material with a peek into research.

Your class materials are likely behind state of the art. Look around for survey papers on Google Scholar or Arxiv.org.

For the Operating Systems class I would search for "Operating Systems Survey". Even a peek at the results indicates an emerging trend of embedded/IoT OS research, which might be useful insight. It's ok if you don't understand most of a paper, but you will draw inspiration and see contemporary problems.

(Image credits: Tom Murphy VII / Wikimedia Commons CC BY-SA 3.0)