Not boring, and a bit of a condescending prick
67 members
4 photos
34 links
Semi-digested observations about our world right after they are phrased well enough in my head to be shared broader.
Download Telegram
to view and join the conversation
I’m wondering why is “Zero to One” such a widely used term these days, and yet its counterpart, one to zero, is hardly discussed.

I want zero extra actions to have to be performed so that:

• the tests are run,
• the code deploys,
• the schema is respected,
• the paycheck is sent,
• the event is in my calendar, with the proper link to join the meeting,
• access permissions are granted upon being asked for, and
• non-engineers are not messing with well-functioning engineering processes.

Each of the above billet points by itself deserves a good book.
The pros and cons of starting a company.

Via Spencer Greenberg.

1. Autonomy
Pro: you're the boss and decide what to do.
Con: you HAVE to always decide what to do. There will be a huge array of options at any given moment, and you'll never know for sure which to work on. You can seek advice, but ultimately YOU are the one who must decide.

2. Lifestyle
Pro: since you're the boss, you'll have flexibility in your hours.
Cons: you'll inevitably be working a lot of hours. It takes a lot of work to succeed as an entrepreneur.

3. Resilience
Pro: it's an incredible way to train resilience, persistence, and problem-solving skills.
Con: the world will punch you in the face between 5 and 100 times, and if you ever give up, you lose. This is stressful, and most humans would give up after 5 or 10 face punches.

4. Expected Value
Pro: if you're well suited to it and work on a good idea, the expected (mean) value in terms of potential impact and monetary reward can be REALLY high. Some companies have truly altered the course of history.
Con: the probability of failure is high, and luck is a significant factor. And unless you have substantial savings, you'll likely be living frugally at first.

5. Learning
Pro: you will learn a tremendous amount. Even if the startup doesn't work out, this valuable experience will apply to MANY other things. I don't know of another way to learn so many things so quickly.
Con: you will inevitably make many mistakes (ouch), and you have to face up to them (double ouch) in order to learn fast enough. It forces you to acknowledge and improve (or develop workarounds for) your weaknesses.

6. Meaning
Pro: you can choose to work on an idea that is DEEPLY meaningful to you. Most jobs don't provide this level of meaning.
Con: if you fail, you will have invested a lot of time in (and then failed at) something deeply meaningful to you.

7. Respect
Pro: many people have a lot of respect for entrepreneurs, and it's considered cool in plenty of circles.
Con: this respect increasingly kicks in as success increases, and before that, some people won't even respect it as a career choice.

8. Relationships
Pro: you will likely meet lots of interesting people and build meaningful relationships with your team members.
Cons: you may have to deal with difficult personalities or navigate complex human dynamics when it comes to employees, investors, and/or co-founders.

9. Responsibility
Pro: it teaches you a deep form of responsibility, which strengthens your character.
Con: you are ultimately, at the end of the day, responsible for everything. You're the captain, the last line of defense, and the goalie.

10. Adaptability
Pro: it hones your creativity and adaptability, and can really build self-confidence and help you develop a sense of how much you're capable of (probably more than you think!), as you figure out solutions for complex challenges, develop new ideas, and map out how to make them a reality. It pushes your boundaries in new ways and makes you grow.
Con: it can stretch your creativity and adaptability to the limit. Plans, essential as they are to make, rarely survive their collision with reality. It sometimes pushes your boundaries more than you would like.

So, why NOT be an entrepreneur? Because it's a high risk, chaotic, stressful, responsibility filled, boundary-pushing, challenging life. And it's hard work.

Not everyone is suited to this path, and it's irresponsible to pretend that everyone is.
BUT, if you're well suited for it, it can be one of the most deeply meaningful, high value, high impact lives to lead. You'll meet lots of people, build resilience and adaptability, push your skills to new heights, and learn a STAGGERING amount.
For some people, it is absolutely their best life path.

You can learn more and get in touch with us at:

From a work chat:

— What is data warehouse? Is it a database?
[ me explaining what MapReduce, Hadoop, HiveQL, Spark, etc. are ]
— Oh, I got it. Mongo can do it, right?

I'm conflicted between thinking whether it's our folks got something very wrong, or the Mongo folks got something very right.

Full disclosure: Religiously, I'm inclined to believe it's the former. Mongo hasn't done much right, to be honest, not to mention their marketing and product placement is misleading to say the least.

But the very fact that in 2020 the new generation tends to view the world of big data from an entirely different point is certainly something to ponder on.
How can programmers keep track of their design decisions?

Let me open up by quoting an okay joke from memory:

If you change random things in your code until it works it’s “bad debugging”, but if you can do it several thousand times a second it is called machine learning and pays three times what you are making now.

One way to understand this joke is to appreciate the power of the simple idea that in the right environment, that embraces natural selection, a bunch of well-tested heuristics generally do the job quite well.

If the above does not look anywhere near the answer you are looking for, kindly allow me to rephrase it in the following way:

• Design decisions are what shapes the implementation in code.

• Good design decisions are the ones that yield implementations that last.

• People with good design decisions get to make more of them later on.

Still not looks like an answer? Okay, let me set the record straight.

It’s not that programmers contemplate a lot on which design decision to make, then make this decision, and then adhere to it. The real world works pretty much the other way:

• The process of settling on a design decision involves multiple proposals and multiple arguments pro and against them.

• Throughout making the design decision, the proposals that were countered successfully are eliminated, with all the arguments against remembered by everyone involved.

• Ultimately, one proposal remains, and is being executed upon. If multiple competing proposals make it to the final round, an authoritative decision is generally being made, with people not agreeing with this decision often times leaving the team or the project or the company.

• It is at this point, when the decision is largely made, optionally, the design doc is written. It may well share some 90% of the contents with what it was during the proposals phase, but, generally, when the design doc is being finalized, the decision has been already made, and, often times, the work has already started.

Now, I hope, the above paints a clear picture that does constitute the answer to the original question.

Software engineers (a.k.a. programmers) don’t really keep track of their design decisions. They don’t have to, because given the information they have obtained during all the discussions before the decision was made, they would make the same decision right away in an eyeblink.

And someone with a strong opinion against the decision that hasn’t been made has either already changed teams, or remembers very well what exactly was the decision they disagreed with, and yet chose to stay on the team despite.

The beauty of engineering, and, especially, software engineering, is that the designs tend to get battle-tested. There’s a real-life feedback look. There’s Skin in the Game, to quote Nassim Taleb.

Software engineering, generally speaking, is no peace-time policymaking game, where arguments are about as strong as they sound to be. Software engineering is closer to a series of war-time campaigns, with the enemy being the laws of nature, systems complexity, and the strength and the dynamics of the team working to implement and later support the designs based the decisions made.

So, most of the time, there’s really no need to keep track of design decisions. What works a lot better is to surround oneself with experienced people who can readily provide plenty of arguments that both stick to everyone’s mind right away, and explain beyond reasonable doubt which decision is and remains the best one given the constraints.
"Read the last line of a huge text file" is my new favorite coding task for those who self-identify as system programmers in Python.
Our first system design meetup video is now up.

I enjoy interviewing, and enjoy helping people prepare for interviews. This year I realized the system design format is taking off, and I especially like conducting interviews of that kind. At the same time it appears there's not much quality content available online, so, without further due, we recorded this piece and are presenting it to you.

Kudos to Tilek Mamutov and the team for helping to make it happen.

The format is similar to the practice sessions we ran before, with a few tweaks to make it more relaxed. It still is an experiment, to the degree that I haven't even wrapped my head around whether it should be called a session, a colloquium, or a meetup. Let me leave it for you guys to judge, and hope you like it.

I plan on making this a regular thing, and if you want to join one of the next ones, here's a form for us to pick the best date and time.
Thanks for all the interest to the previous post!

I've put together a Slack "workplace" (here's an invite link to it), and a Twitter handle. We are planning to host the next event this coming Friday or Saturday.

I also did some magic with the "connected discussions account" here on Telegram, so, if we're lucky, from this post on there'll be comments enabled here.
Next meetup video: Designing user authentication as if it's 1998 (spoiler: not really 1998).

I've enjoyed it quite a bit — thanks everyone who joined and helped! — and am looking forward to the next ones.

As a friendly reminder, here's our Slack, and here's an invite link to it.
Web Crawler: today's #meetup video.

With interesting detours into message queues and brokers, as well as into whether Redis can be used as a queue, and if FIFO is that important when it comes to managing the crawl queue.

(Let me know if you'd rather not have me post these links in this channel, still calibrating on this social media thingy. Thanks!)
And our next system design meetup video: designing WhatsApp / Telegram / FB Messenger.

With online whiteboards this time, hope you enjoy it! We had a lot of fun for sure, and, as always, we've learned something too.

As a fly in the ointment, my Ubuntu screen recording at 60FPS stared dropping frames, effectively freezing the video in the last quarter or so of the recording. The audio is fine. Lesson learned, I hope to do better next time.
And yesterday at the meetup we talked about reactive streaming.

I'm experimenting with formats tirelessly =) and this one was not really about discussing the design of a particular large-scale system, but more of a casual conversation on one of the important topics in modern software architecture.
Glad we're back to the TSLA curve from what seemed to be stalled as the gold one for a bit.

Wondering how would my Go career exit. Casually become a dan-ranked player around my retirement age would be close to how I approach life in general, and one's Go does resemble their life quite a bit.