Your reading list grows faster than you do

Pick a normal week. Two tools you’ve never heard of are trending. Your cloud provider shipped eleven things, and a dependency cut a major release. Someone on your team wants to know whether you’ve looked at the new service mesh. You have maybe four hours of learning time, and most of it goes on whatever broke on Tuesday. The feeling of being behind is constant, and it has little to do with whether you’re good at your job.

The usual response makes it worse. You skim more titles, bookmark more links, and retain less of all of it. Meanwhile someone has already solved the problem you’re about to solve by hand. Their solution sits three clicks away, in a list you never opened.

So: where should the inputs come from, and what does each one cost you? Feeds, paid platforms, books, conference hallways, and time at a keyboard with something half-broken in front of you. We don’t use the same ones, and we don’t agree on how much of the news you have to read. The disagreement is the useful part.

Keeping up is the wrong goal

Start with the belief sitting underneath the anxiety, because it’s the one worth testing.

Do you have to follow what’s new to stay good at your job?

Not for most of it, and believing you do is probably costing you more time than anything else on this page.

Our version is blunt: you could spend a year without opening the news and still be okay, because the pace things are supposed to evolve at is partly a myth. You’d catch up the same way afterwards, and skip some of the fluff on the way through, since fluff is the part that doesn’t survive a year. That holds for general technology news. A specialty you’ve put your name to is a different pile.

So why follow anything? For the ideas, mostly. Watching an argument happen about a new technology tells you where things are going and what might be worth betting on. Tooling is a small slice of that, next to how teams are organised and how systems are designed. The one dependable return is narrower than it sounds: you occasionally find out that a thing exists which solves a problem you were about to solve yourself. Imagine writing Terraform from scratch before you provision anything.

A better question than “how do I keep up?” is “what do you want to learn?”, and the reason you’re learning picks the approach. Solve a problem that’s in front of you and you go deep, ship it, then stop reading about it, because it isn’t a problem any more. A specialty runs the other way. If you’ve told people you’re the AWS security person, you follow that area as part of the job, because they come to you expecting you to already know. Most weeks hold both, and neither is a reason to read everything.

Start from a problem you already have

If “keep up” is the wrong instruction, something must replace it, and the work in front of you usually volunteers.

What’s the best reason to start learning something?

A problem that’s already on your plate, because it tells you when to stop.

Terraform arrived because there were VPCs, subnets and a cluster to provision, and it fit better than the configuration management tools we’d used before. Ansible still has work inside the server, but once most of that moved into container images, Terraform plus containers covers a lot before you reach for a third tool. The longer version is Infrastructure as Code.

The part people miss: the modules are already written. Search GitHub and the registry first: terraform-aws-modules/vpc/aws gives you public subnets, private subnets with NAT gateways in front of them, and a database tier. Read that tier before you call it isolated. create_database_subnet_route_table defaults to false, so the database subnets sit on the private route table and inherit its egress. Turn it on and they get their own table. Trust the source of the version you pinned over the flag names. In v2.33.0, create_database_internet_gateway_route writes its default route to the database table, and create_database_nat_gateway_route writes to aws_route_table.private. Every route table carries the local route, so there’s a path from the rest of the VPC either way. What crosses that path is a separate decision, made by your security groups and by the network ACLs on the subnet.

The second example started with a compliance requirement for access audit reports, and became research into how anyone gets answers from a pile of S3 access logs. One of us is building the pipeline you’d expect for logs in general: collect centrally, push into Elasticsearch, query there. For access logs the answer came out different, a couple of Python scripts aggregating everything with pandas, and that code is published, still short on documentation. Application logs are where that pipeline earns its keep. Before you promise completeness, AWS says server access log delivery is best effort: a record “might not be delivered at all”.

A third route starts in someone else’s problem. You hear what a colleague is stuck on, go looking for how people solve it, and come out with tools you’d never have searched for. Then they go on the cluster at home: spin it up, fiddle until it works. Reading about a tool tells you what it claims. Running it tells you what it does when you hold it wrong, and for some of us that’s the main way in.

Pick the feed, then pick how fast it arrives

Once the work decides what you learn, the only question left about the news is how quickly you need it.

How much of your input has to arrive in real time?

Less than you think: keep one fast channel for the thing people expect you to know first, and put everything else on a delay.

This is where we split hardest. Julien follows more than a thousand accounts on Twitter and uses it as a trend sensor. The barrier to sharing is low, so developers post work there that never becomes an article. Anything moving shows up to chase or ignore. Andrey rarely reads Twitter and mainly uses it to post. Anything that matters arrives one way or another, and being first to know isn’t worth the attention it costs.

What replaces it is plumbing. RSS feeds and newsletters go through IFTTT, get tagged, and land in Pocket, which gets opened once or twice a week. AWS announcements arrive as a Telegram channel. Where Twitter is unavoidable, TweetDeck lists keep the posts in the order people posted them instead of the order an algorithm prefers. A lighter version of the same idea also works: a Feedly channel for Kubernetes catches the larger announcements, and the rest arrives through conversations and links posted on Reddit.

The failure mode in all of it is the title you never click. It lands anyway, and it carries none of the story behind it. The framing goes in regardless, which is the mechanism that makes fake news work on people who would never fall for the article itself.

When you do want the edge of one community, follow the people doing the work rather than a hashtag. The Kubernetes SIG list names the chairs of every special interest group, with their Slack channels and meeting times. Don’t rely on a Kubernetes-focused feed for front-end coverage; these communities cross-reference each other rarely.

Audio is a channel too, and it has the largest capacity in a week, ten to twenty hours of podcasts and audiobooks while walking, cycling or on an easy run. Not everyone can take content in while doing something else. Technical books don’t survive the format either, because diagrams and code listings want eyes. Biographies, history and fiction do, and they’re the break from technology rather than more of it.

Where it’s still worth paying

Free material gets you oriented. It tends to thin out at the exact depth where you needed it.

Is a learning subscription worth the money?

For going deep on one topic, yes, and the price does roughly track the quality.

O’Reilly’s learning platform is pricey for what it is, and it keeps earning it. You get books, video, recorded conference sessions, and titles pulled in from other publishers such as Manning and Packt. It’s strong on front-end and machine learning and only okay on cloud. For cloud the better courses were elsewhere. Linux Academy was the pick for Kubernetes, and that’s where one of us took a Kubernetes certification. A Cloud Guru covered AWS and the basic Linux material, and it had expanded into GCP, Azure and Kubernetes.

Late 2019 rearranged that shelf. A Cloud Guru announced it was buying Linux Academy in December, and a month earlier O’Reilly acquired Katacoda. Katacoda is the one to notice. It spins up a container and hands you a terminal in the browser. You type real commands at a real environment instead of watching someone else do it. Google Cloud’s self-paced labs take the other approach, and we’ve run them in our own project. Our experience was that these labs cost very little, roughly cents. A few of them used features past the free tier, so read what a lab provisions before you start it.

Free depth exists if you can handle being out of your depth. YouTube has the conference talks, and InfoQ carries a lot. Little of it is beginner material. That’s useful if you treat not understanding something as a pointer to the next thing to look up. Starting from zero on a topic, the awesome lists on GitHub are the best free entry. Each one is a curated set of projects, articles and documentation, maintained by people who use the thing. sindresorhus/awesome indexes them, and we maintain the Docker one, five years of curation that renders as one static HTML page with a little CSS and no JavaScript.

A person is still the highest bandwidth channel

Every channel so far is one-directional. The one that isn’t beats all of them on detail per hour.

What’s the best hour you can spend at a conference?

Not in the big room: find someone who has already done the thing and talk to them for half an hour.

Thirty to sixty minutes with the right person gives you the details that don’t survive the trip into a blog post, including the parts they’d never write down. Meetups are better ground for that than conferences. A gathering of twenty to forty people after work lets you talk to a good share of them. Speakers constrain themselves less because there’s no stage to live up to. At a hundred and fifty it’s a mini conference wearing a meetup’s name: people cram in, listen, and spread out again.

At a conference the small rooms at the back are where the newer projects and the deeper dives go. That’s where a tool you’ll use next quarter shows up, before it gets popular. The talk you can watch later is the one to skip in person.

Two of us met at a Stockholm meetup, at a roughly 90 minute talk on chaos engineering with Istio, which is not a normal meetup talk.

Masters know the exceptions

Finding those people is one thing. Knowing what to take from them is another, and the valuable half is not what you’d expect.

What should you take from someone who’s already expert?

What they don’t do, which is the half that rarely reaches the documentation.

A student knows the rules; a master knows the exceptions. People who have been through the pain are usually keen to pass it on, so the hard part is locating them rather than getting them to talk.

A book makes the shape of it obvious. Douglas Crockford’s JavaScript: The Good Parts runs to 172 pages and came out in 2008, and what stays with you isn’t the feature list. It’s don’t use this, don’t do that, this will complicate your life later. The premise is to scrape away the bad parts and leave a smaller subset you can rely on.

Hype runs the other way. A new thing lands and the conversation is about adopting it; far fewer people say you could ignore this one and lose nothing.

Learning by failing works, and it’s the expensive route. The alternative is to trust someone who already paid, do what they say, and get on with the work.

Teaching, and a room where failing is cheap

The other end of this is being the person someone else learns from, which has its own failure modes.

Why does showing beat explaining?

Because a result people can see gives them something to copy, and a description leaves them nothing to hold.

Separate two questions that usually get asked as one. Teaching someone who wants to learn is a solvable problem. Getting someone to want to learn is a different problem. We’ve had plenty of failures trying to motivate people to learn.

For the people who want it: show me the code, this is how you do it, this is the result. A Terraform workshop is a complete shift for people used to clicking around a console, because now they have to write things. Seeing it done first is what makes the shift survivable. Then hand over a starter kit and a test environment where nothing they break matters, because taking apart what worked matters as much as taking apart what didn’t. A little theory, then practice, then a second pass on what the better way would have been and why.

Presentations are passive, which is both why they work and where they run out. Mob programming picks up from there: everyone on the same thing at the same time on one keyboard, with rotating roles. The navigator says what to do, the team feeds the navigator, and whoever is at the keyboard types and mostly stays out of the discussion. Frequent rotation helps people stay engaged, and five minutes is the interval we’ve used. Woody Zuill’s original write-up rotates the driver every 15 minutes, so treat the interval as a dial and set it to whatever keeps your room awake.

It raises a team towards its strongest members, which is also its one requirement: somebody in the room has to know what they’re doing. We’ve had salespeople in the rotation writing tests and finishing them, carried by the people around them.

All of it rests on something smaller. People have to be able to say they don’t know. Years on Terraform and AWS still leave you with a fraction of what’s there. Say that out loud in front of the team, and the room gets safe for everyone else to say it too.

What this means for teams

Read what serves your current problem or specialty, and let the rest wait. Choosing the input before you spend the hour is the part that compounds.

This week:

• Write down the problem your team actually has this quarter, and drop the learning that doesn’t serve it. Keep one exception: the specialty people come to you for, which you do have to follow.
• Before your next Terraform module, search the registry and GitHub. Start from terraform-aws-modules/vpc/aws, delete what you don’t need, and open the source of the version you pinned to see where the database routes actually land.
• Put your feeds on a delay. Route RSS and newsletters into a read-later queue, open it twice a week, and see what you genuinely missed.
• For the next thing you have to teach, build the throwaway environment before the slides, then rotate the keyboard every few minutes and let the room do the talking.

Common questions, answered

How do I learn Terraform for AWS without writing every module myself?

Start from the maintained open source modules and read those instead of a tutorial. terraform-aws-modules/vpc/aws builds public subnets, private subnets with NAT gateways in front of them, and a database tier, which covers most of a first AWS environment. Copy it and delete what you don’t use. Do not assume the database subnets are sealed off. They share the private route table unless you set create_database_subnet_route_table, and the local route leaves an intra-VPC path to them either way. What actually gets through is whatever your security groups and network ACLs permit, so that is where the access control lives.

Should I learn from books, videos or hands-on labs?

Match the medium to the material, and keep anything with code listings or diagrams in front of your eyes. Audio takes biography, history and discussion well and runs while you walk or cycle, which is how some people find ten to twenty hours a week. Video suits conference talks. For a tool you’ll actually type, use a browser sandbox such as Katacoda, or a cloud provider’s self-paced labs in your own project. In our experience these labs cost roughly cents, but the bill is yours, so read what a lab provisions first.

How do I get a teammate started on a tool they’ve never used?

Show them a working result first, then hand over a test environment where breaking things costs nothing. The demo gives them something concrete to copy, and the sandbox is where they pull apart what worked as well as what failed. For a group, mob programming beats a presentation: one keyboard, roles that rotate every few minutes, the navigator saying what to do and the team feeding the navigator. Somebody in the room has to know the tool, otherwise the mob compounds its guesses.

Related episodes

• Infrastructure as Code: the long version of the Terraform and configuration management argument this one only touches.
• What Are We Working On: our standing segment on current work, including the S3 access problems that keep sending us back to the documentation.
• SemVer or Not to SemVer: Johan Abildskov on versioning, and the Git katas he maintains as practice sets.

Resources

• Mob Programming Basics: Woody Zuill’s 2012 write-up, with the driver and navigator roles and a 15 minute rotation.
• awesome-docker: the curated Docker list we maintain, and the static page that renders it.
• sindresorhus/awesome: the index of awesome lists, which is where to look first for a topic you know nothing about.
• Kubernetes SIG list: chairs, Slack channels and meeting times for every special interest group, so you can follow people instead of hashtags.
• terraform-aws-modules/terraform-aws-vpc v2.33.0 main.tf: the route resources behind the database tier, and which route table each flag writes to.
• O’Reilly acquires Katacoda: November 2019, and what browser-based scenarios are for.
• A Cloud Guru announces acquisition of Linux Academy: December 2019, which settles why the two cloud platforms we recommend now overlap.
• JavaScript: The Good Parts: Crockford’s 2008 guide to JavaScript’s useful subset.

Since we recorded

The database routing above was a module bug, not a design: create_database_nat_gateway_route kept writing to the private route table until v2.48.0 on 17 August 2020 pointed it at the database table. O’Reilly closed katacoda.com on 15 June 2022, keeping the technology inside its own subscription. Mozilla shut Pocket down on 8 July 2025, which removes the far end of the RSS pipeline. We came back to what’s worth learning now in episode 112, and to books, juniors and where practice comes from in episode 113.