Learn Icon

Learn

Learning to code, leveling up, building your skills. Expand your résumé and pursue a fulfilling developer career.
337 Stories
All Topics

Alex speedtyper.dev

SpeedTyper – type racing for programmers

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! 🤣

Learn basementcommunity.bearblog.dev

4 things I learned after getting users

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

Kubernetes github.com

A roadmap to learn Kubernetes from scratch

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.

Learn simplethread.com

Things I've learned in my 20 years as a software engineer

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

GitLab blog.boleary.dev

What I learned at GitLab that I don't want to forget

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

Rust simonwillison.net

Learning Rust with ChatGPT, Copilot and Advent of Code

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…

Adam Gordon Bell earthly.dev

Containers are chroot with a marketing budget

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 underjord.io

Complex systems all the way down

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 cichocinski.dev

How trying new programming languages helped me grow as a software engineer

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.

Brandon Willett willett.io

How to build software like an SRE

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.

Unix punkx.org

The UNIX Pipe Card Game

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.

The UNIX Pipe Card Game

Learn github.com

Facts about state machines

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.

Learn the-algorithms.com

Algorithms & data structures implemented in many programming languages

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.

Paul Graham paulgraham.com

What I've learned from users

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.

Learn beesbuzz.biz

Falsehoods programmers believe about email

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?

Player art
  0:00 / 0:00