Alexander Lotvall:

It’s a typing app specifically for software developers. You type code snippets from real open source projects. It supports inviting your friends to a room and competing in real time against your friends, and you can get your result on the global leaderboard.

I like how it uses code snippets from popular projects. I don’t like how slow I am at writing Rust code! 🤣

Andrew Quinn:

fzf is a bit of a weird program because installing it actually overwrites a whole bunch of keyboard shortcuts, in the interest of making them better. Normally I would hate this. But…

Lots of good stuff in this post 👍

You can think, plan, design & toil away on your project/product all you want, but until you have real people using it… you’re only guessing. Here are 4 things the creator of basement community learned after picking up their first batch of real users:

1. someone is going to abuse your site
2. you need a performance monitoring system
3. your SQL queries need to be optimized
4. your users might have genius ideas

For many hackers, programmers, and computer scientists, having an understanding of graph theory is immensely helpful. But what about those who do not have this background?

This blog posts adapts Scott Young’s Ultralearning approach and applies it to learning graph theory for those who many not have a formal training in maths!

Learning Kubernetes can seem overwhelming. It’s a complex container orchestration system, that has a steep learning curve. But with the right roadmap and understanding of the foundational concepts, it’s something that any developer or ops person can learn.

In this Kubernetes learning roadmap, I have added prerequisites and complete Kubernetes learning path covering basic to advanced Kubernetes concepts.

This was written over a year ago, but since it took Justin Etheredge 20 years to acquire these 20 pithy (his word) pieces of wisdom, I don’t think it’ll be going stale anytime soon. My three favs, as a sampler:

1. The best code is no code, or code you don’t have to maintain
2. Every system eventually sucks, get over it
3. Your data is the most important part of your system

Apropos of nothing, you may be considering starting a new AI-related project. The OpenAI folks inferred this fact and created a repo full of example code and prompts to get started with their API.

After 5+ years working for GitLab, Brendan O’Leary is moving on to his next adventure.

I’m so proud of what we built—and I’m still proud and awed by the remarkable people there. GitLab’s values are the gold standard for what it means to be a wonderful company—for the team-members, for the community, and for the shareholders.

He took a moment to write down a few things he learned while there. The bullet points follow, but you’ll have to visit his blog for all the details:

1. Write down everything
2. Give and accept: ownership, agency, and responsibility
3. Be transparent with a low level of shame

Simon Willison is using this year’s Advent of Code as an opportunity to learn Rust.

He’s using Copilot to help him with syntax/snippets via comment-driven prompting. He’s using ChatGPT as a study partner by asking it questions about how to do things in Rust. Is it working?

So far I think this is working really well.

I feel like I’m beginning to get a good mental model of how Rust works, and a lot of the basic syntax is beginning to embed itself into my muscle memory.

The real test is going to be if I can first make it to day 25 (with no prior Advent of Code experience I don’t know how much the increasing difficulty level will interfere with my learning) and then if I can actually write a useful Rust program after that without any assistance from these AI models.

And honestly, the other big benefit here is that this is simply a lot of fun. I’m finding interacting with AIs in this way—as an actual exercise, not just to try them out—is deeply satisfying and intellectually stimulating.

This might be an early glimpse into the future of AI-assisted learning…

Learning C was quite difficult for Tom M. Thankfully for us, along the way he collected summaries, signposts, and advice for these broader points that made his journey with C and other compiled languages easier. So, if you’re on a similar journey, this page will serve you well on your way.

Adam Gordon Bell:

There are many ways to understand how containers work, but most useful explanations are actually simplifications….

But for me, containers are just chrooted processes. Sure, they are more than that: Containers have a nice developer experience, an open-source foundation, and a whole ecosystem of cloud-native companies pushing them forward. But, let me show you why I think chroot is the key.

I like this framing. It makes a lot of sense to me. More than ‘lightweight VM’, which is how I’ve thought about them previously. The rest of this article is Adam stepping through the process of building a container runtime using only the chroot system call.

Lars Wikman on what it takes to learn software development and how he responds when people ask him how they should go about it:

At the time I was learning, I didn’t have access to any kind of bigger picture. I had limited resources. Limited documentation. I had so many limitations. I ran into them constantly and eventually found the next thing I could use to do cool stuff. If you try to teach someone to use an HTML form today, you will need to decide if you are talking about the basic idea or reality. Do we need to cover CSRF, captchas and how to do it in React? How about the backend? Starting out, I didn’t hear about half of the things I didn’t know; I think that made things easier.

When it comes to the software industry, this is the best of times. There are amazing learning resources available, a vast repository of free code that you don’t have to write, and lucrative job offers on the other end of the chasm.

When it comes to the software industry, this is the worst of times. There are too many learning resources to choose from, a crippling repository of free code that might stumble you, and overwhelming imposter syndrome on the other end of the chasm.

Lars sums it up nicely:

Hand someone a fish and they’ll never know that the ocean is vast. Teach them how to fish and they’ll be forever lost at sea.

Tomasz Cichociński:

It’s completely fine to deepen one technology or one programming language knowledge. It’s totally fine to just have a 9-5 job that pays the bills. But if you aim to level up, I’m highly recommending trying something new to broaden your perspective.

If you’re writing JavaScript, try some functional language like Elixir or ReScript. If you’re already familiar with high level, garbage collected languages, try something low level like Rust or even C/C++. Play with different concurrency model like coroutines or actor model.

You don’t need to change your job, you don’t need to ship products with it. Try to create something fun. You’ll thank yourself later.

This is awesome — Brandon, please write down more lessons learned, even if they’re just something for you to reference later on.

I’ve been doing this “reliability” stuff for a little while now (~5 years), at companies ranging from about 20 developers to over 2,000. I’ve always cared primarily about the software elements I describe as living “outside” the application – like, how does it get its configuration? What kinds of instances does it run on, and are those the best kinds to use? What steps does it take on its path from “code in a repository” to “running in production”? And I’ve always kept track of what I liked – which mechanisms allowed fast iteration and which caused frustration, which led to outages and which prevented them.

… So! With that out of the way – this is how I’d rebuild it all from scratch if I could.

An actual card game to teach actual kids how to actually combine unix commands with pipes.

task: print the most common line from a file, we need to first cat the file (in our case the file is card 03.txt), then sort it, uniq count it, then do numeric sort, then tail -1:

answer: cat 03.txt | sort | uniq -c | sort -n | tail -1

Print it yourself or… actually it’s sold out for now so you’ll have to print it yourself.

If Stable Diffusion has you using metaphors like wizardry, spell casting, and the like, maybe this excellent, illustrated explainer by Jay Alammar will help you distinguish it from magic. 🪄

Johannes Schuck holds the opinion that state machines are underrated. So he wrote this:

The goal of this list of facts is not to teach you what state machines are or how to use them; there are plenty of other resources for that. Rather, the goal here is to motivate their usage and to highlight things about them that are frequently overlooked, but nonetheless relevant.

This looks awesome:

We are a group of programmers helping each other build new things, whether it be writing complex encryption programs, or simple ciphers. Our goal is to work together to document and model beautiful, helpful and interesting algorithms using code.

We are an open-source community - anyone can contribute. We check each other’s work, communicate and collaborate to solve problems. We strive to be welcoming, respectful, yet make sure that our code follows the latest programming guidelines.

Here’s Paul Graham with some wise advice he’s learned from YC’s users — this also tees up a large conversation on this Friday’s episode of The Changelog (talk to your users).

I recently told applicants to Y Combinator that the best advice I could give for getting in, per word, was. Explain what you’ve learned from users.

Here’s why that makes sense.

That tests a lot of things: whether you’re paying attention to users, how well you understand them, and even how much they need what you’re making.

But giving this advice made Paul consider what he has learned from YC’s users (the startups they’ve funded). This one is almost cliché at this point, but still quite true.

Focus is doubly important for early stage startups, because not only do they have a hundred different problems, they don’t have anyone to work on them except the founders. If the founders focus on things that don’t matter, there’s no one focusing on the things that do.

We’re currently refurbishing 🙃 our authentication stack at Back Market, and we need to onboard our developers and teams to various OAuth2 concepts. Here’s our take on OAuth2 (with cute shapes.

Dan Hollick nerds out on the history and anatomy of a QR code. This bit at the end is super cool:

Perhaps the coolest thing about QR codes is that Denso Wave, the company that invented them, never exercised their patent and released the technology for free!

It’s easy to fool ourselves into believing the world is normal, sensible, and without rare-but-undeniably-valid edge and corner cases. Maybe you’ve done this to yourself with email. I’m guilty.

One example, we do email-based authentication (no passwords!) because I believe(d) this particular falsehood:

Emails will be received soon after they’re sent

I wish it were always true! Thankfully, there’s a lot of things on the linked list that I don’t believe. Do you?

Every so often, engineers need to pick up a new language. After ~6 years of professional development using Java, with a bit of Ruby sprinkled in, coming to Deliveroo meant that I’d be starting to work on some Go codebases.

So when it came to accepting the offer, I ended up thinking about getting started with learning Go, so I could hit the ground running. In this post I share different ways to get practical experience of the language, as well as thoughts on what Go is like to a newbie

A 12-week, 24-course curriculum covering:

• Different approaches to Artificial Intelligence, including the “good old” symbolic approach with Knowledge Representation and reasoning (GOFAI).
• Neural Networks and Deep Learning, which are at the core of modern AI. We will illustrate the concepts behind these important topics using code in two of the most popular frameworks - TensorFlow and PyTorch.
• Neural Architectures for working with images and text. We will cover recent models but may lack a little bit on the state-of-the-art.
• Less popular AI approaches, such as Genetic Algorithms and Multi-Agent Systems.

Not every hash algorithm is appropriate in all scenarios, and in fact, very few algorithms are usable in more than a couple of situations. Even worse, using the wrong algorithm will lead in the best case scenario to performance problems, but in the worst case scenario to security issues and even financial loss. Thus, knowing which algorithm to pick for which application is crucial.

Therefore I’ll try to summarize how I approach the topic of hashing, including use-cases, recommended algorithms, and links to other articles.