Not boring, and a bit of a condescending prick
95 subscribers
5 photos
41 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
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 Outtalent.com 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.
I am cautiously optimistic for the world where the reopening does happen, but quite a few people still enjoy working from home.

This would give those of us who are both tech-people and people-people a tremendous opportunity: to live and work literally anywhere, and have business trips of a few days to ~1.5 weeks long once or twice a month.

With all my dislike of the modern corporate structure, if most of my team is remote, we gather often via video chats, and yet some ~half of us enjoy to see each other in person, which we do by gathering in various places for mini-offsites on the company's buck, as the company clearly understands the cost-effectiveness of such an approach ...

... that's the world I might enjoy living in.

~ ~ ~

Although it's all a distant dream so far. As of today, most places can't even be traveled to, and only the most adventurous of us are still up to asking the very "where to work from next month" question.

It is incredibly sad to see how herd-able by fear the people are. But, much like in 2008, a sober reminder is that in Mandarin "crisis" consists of two hieroglyphs: dangerous + opportunity.

Be safe & sane, everyone.
Sorry in advance for Russian, promise to keep this rare — интервью, которые мы с Тилеком Мамутовым (Outtalent.com) записали в Ололо в Бишкеке. Спасибо, было офигенно, и ты отличный интервьюер!
Forwarded from Грамм Тилека
Дима Королёв (@BoreMeNo) - архитектор программного обеспечения в Poker Stars, преподаватель, основатель Systems Design Meetup. Кроме этого он работал программистом в Google, Microsoft и многих других компаниях.

В этом интервью мы поговорим о собеседованиях по алгоритмам, systems design и о том, как можно развивать карьеру программисту.

https://youtu.be/iYvWLflZ9E4
A system design meetup episode on MapReduce: video, slides. Thanks folks!

And sorry my OBS Studio didn't record your questions this time — good thing I have a habit of repeating them from offline conferences :-) also, I should probably not forget to hide the taskbar next time.

#incrementalimprovements #practicemakesperfect #thanksforhangingalong
This important design paradigm has reached me twelve days too late: https://github.com/zhuowei/nft_ptr

Also, copy-pasting and paraphrasing from a private group: The history of C++ repeats itself, the first time as tragedy, the second time as farce, the third as blockchain.
I'm experiencing a rare déjà vu.

As in the dev part of my career is, again, slowly expanding, from encompassing just the realm of C++ before, to now building JavaScript wrappers over it, enabling more and more people access the sacred performance of The Language.

It’s almost like my Java/JNI stint 2.5 years ago, but a lot better actually. Better because JavaScript is in fact a relatively good language to wrap C++ into, at least once the initial blockers are behind.

If all goes well, I’ll be generating (DSL, *.inl) C++ as part of the build step some time in the next few weeks, after which point shipping C++ code as npm modules, bundled with their TypeScript interfaces, may well become my second C++ nature, as long as the tasks I have to work on these days allow us to explore this direction.

Links: experiments, and my clean repo with example usage.

Fun times.
Exactly Once: today's system design meetup video. And the slides.

We covered the narrow edge between the easy problems and the hard one, touched on message sequencing / "serialization", Kafka, Lamport clocks, the CAP theorem (once again), and how to deal with them in practice, not just in theory.

I truly enjoyed it today, and hope the recording captures the spirit well enough 😊