For me, it's often Wikipedia rabbit holes. "How many Boeing 747s are still used by commercial airlines?" -- that was recently my way to avoid a Todoist list of 20 items.

Clearly, reading about 747s is just avoidance -- I don't think my career would get better if I knew more about this.

But, surprisingly, procrastination can also be a good thing.

First, remember that context switching is very expensive for our brains. So, if you need to immerse yourself in a big task, your brain can't switch gears immediately. An artist would spend an hour sharpening his pencils before he starts drawing. The famous writer John Steinbeck began each working day by writing letters to his editor -- before he could start writing his novel, the real thing. Maya Angelou would start her day at 6:30 a.m. by playing solitaire, to occupy the "little mind" so the "big mind" could get to work. These ramp-up rituals can look suspiciously like procrastination -- don't blame yourself for them, they help your brain gradually turn itself on.

Second, sometimes, you avoid one task by starting another. Yes, sometimes, that "another cool task" leads nowhere and just wastes time. But often, your brain has had something brewing, subconsciously -- and it's telling you that it's time to make that thing happen! This is exactly how I started building MyNextProject.dev -- I was planning to work on other things, but I just felt an instant urge to prototype something I had in my head. So, procrastination led me to a startup!

The key here is mindfulness. When you see that you're procrastinating, try to classify what's actually going on. If you're sharpening your pencils, or your brain is leading you to something cool that it wants to think about -- allow it and see where it leads you. If you're reading about 747s -- well, just close that page and get back to work! :-D

Some books teach you algorithms, others teach programming language syntax. This book teaches you what it means to be a programmer. The meaning, the philosophy of being a programmer is the foundation of everything else.

I read The Pragmatic Programmer way too late in my career -- I wish I'd read it 20 years earlier.

Certain things that the book recommends, I was doing intuitively -- I realized that I was actually following the advice to learn a new programming language every year!

Other things -- I was not doing right for way too long (I really hope you'll never see my old code with zero tests!)

There are books that you could read, other books you should read. This is the one that you must read if you're a programmer.

First, just to make it clear. In hackathons, people do not break into systems. Quite the opposite -- they build things (which is also called "hacking" -- thank you, English).

"But why a hackathon? I can just build the same thing at home, on my own timeline!"

a) Hackathons give you very different energy -- mostly because you're surrounded by others (see Tip 192). Usually, if you don't have an existing team, you can find teammates at the hackathon start -- and we know that building with others is way more fun (and better learning)!

b) Hackathons are time constrained. A classic hackathon runs 24 hours (fun fact -- a common sponsor for hackathons is Red Bull, you might have an idea why); these are the most intensive building sprints. There are other formats: weekly (start on Monday, build during the week, present on the weekend), even monthly.

c) Usually, there are prizes! Tech companies love sponsoring hackathons (guess why? they hunt for talent!). And having a "hackathon winner" line on your resume is a real prize by itself.

And also, really, it's not an all-or-nothing situation, not at all! Having the "hackathon participant" line on your resume (and the project on your GitHub, see Tip 8) is a real big thing. So, you don't need to be an experienced dev to enjoy the hackathon -- when I judge, often, the most interesting projects are built by juniors!

Now, where to look for hackathons?

I recommend you start by looking at your local tech scene: your university chat, or local meetups are good places to start. Local hackathons have the best energy, and are best for meeting people.

For larger-scale hackathons (mostly online), check out Devpost and MLH.

So, just go ahead, find a hackathon that's happening this month -- and show up!

I recommend you try three deployment scenarios. They'll teach you different things.

The easiest one is fully managed deployment. You might already know the platforms: Vercel, Netlify, Render, Fly. The process is designed to be easy: you create a TOML/YAML file with deployment config, you connect a repo to the platform (using CLI or web UI)... and the magic happens! If you need a database, you just add it to the config file, and the platform does the rest.

With this option, you learn the "happy path deployment," and also touch the concept of config-as-code (preparing yourself for things like Terraform).

Next step -- do cloud deployment yourself. Choose a major cloud platform -- can be AWS, Google Cloud, or Azure. Consult with an LLM on what you need, and go ahead with the cloud-first approach. Need a backend? That's likely a separate EC2 instance. DB? Separate, managed. Don't forget to set up networking and security groups. Do not go way too far (an API gateway or sharding might be overkill at this point!), but do make sure you have an actual working system in place.

Here, the main lesson for you is seeing the deployment as the actual system architecture. What are the components? Who talks to whom? You will not just put this on a whiteboard -- you will make it work.

Finally -- try a single-server deployment. Cloud is great, but, in many cases, a bare-metal server is more cost-efficient. You don't need the actual bare metal -- any VPS will do (a DigitalOcean droplet is a good choice). Now, make all the components work on one machine. Let your LLM guide you as you set things up: reverse proxy, SSL certificates, firewall...

Here, you touch the ops layer that you would completely miss otherwise -- you control the actual system that runs your app.

When you deploy your project, you learn what happens when your beautiful code touches the big, messy, real world of servers and systems -- that's the best learning, don't skip it! And did I mention that seeing your project live is just the best feeling?

References

Managed platforms (the "happy path"):

• Vercel -- frontend-first managed deployment, tight Git integration.
• Netlify -- managed hosting for sites and serverless functions.
• Render -- managed apps, databases, and cron jobs from a single config.
• Fly -- deploy app containers close to users; fly.toml is the config file.
• Terraform -- where config-as-code leads next: infrastructure defined declaratively.
• Infrastructure as code -- the underlying concept the config file is teaching you.

Major clouds (deployment as architecture):

• AWS -- Amazon Web Services.
• Google Cloud -- Google's cloud platform.
• Azure -- Microsoft's cloud platform.
• Amazon EC2 -- resizable compute instances; the "separate backend" box.

Single server (the ops layer):

• DigitalOcean Droplets -- simple, low-cost VPS to run everything on one machine.
• Reverse proxy -- what sits in front of your app and routes requests.
• Let's Encrypt -- free, automated SSL/TLS certificates.

So... what's next?

You need to make decisions. "Should I focus on distributed systems, or deep learning?" "Should I get a degree sooner, or try to do more internships?" -- making the right call is hard, because the decisions affect the future, and each choice implies trade-offs.

How to decide? Let the future-you guide you today.

Fair warning -- I did not invent this exercise. It's a version of a common exercise used in coaching. If you haven't done it before, here's how you do it.

Allocate 2-3 hours of uninterrupted time. Do not use AI -- this is your deep reflection. Take a pen and paper, or -- if you strongly prefer typing -- find the most low-tech text editor you can, to minimize interruptions and unwanted "help" (I used ghostwriter).

Then, start writing: where do you see yourself in 1 year? Just write whatever comes to mind. No structure, no polishing. Just imagine -- you're one year older -- where are you? What do you do? What do you learn? What are you proud of? And the most essential prompt: how do you feel? Future-you's emotional state is the data point that matters most. The career that looks right on LinkedIn but feels wrong when you imagine it -- pay attention to that. Be as detailed as you'd like -- sometimes, adding random details (like the color of your window shades) helps.

Then, move on -- now, you're 2 years older. Actually, calculate your age at that time and write it down. What are you then?

Keep doing the exercise. Don't stop. Repeat for 5 years from now. 10 years from now. 50 years. You'll have five snapshots: 1, 2, 5, 10, 50.

The 50-year jump may feel hard -- but that's exactly the point. Most of us never project that far, which means we make career decisions based on the next 2-3 years and ignore whether those decisions add up to a life we'd be proud of at 75.

Maybe you'll be surprised by what you write. Or maybe you'll just shrug and think, "yeah, that feels right, I guess." Either way, you now have several milestones for future-you.

So, next time you're deciding between distributed systems or deep learning... what would yourself, 10 years from now, advise?

I'm a huge fan of esoteric programming languages, or "esolangs." These languages are strange.

In Rockstar, your programs look like rock song lyrics. Variables are named things like "Tommy" and "my dreams," and a loop may look like "While the world is on fire."

In Forth, everything is a stack. You don't call functions with arguments -- you push values onto a stack and the function pops them off.

In Befunge, you code on a 2-dimensional grid (so an if statement is a visual "switch").

In Whitespace, the only available tokens are whitespace characters: space, tab, and newline.

...and YES, all of the languages above (and most esolangs) are Turing complete -- meaning you could, in principle, write any program in them. (I usually start with Hello World, then work up to binary search :-) )

There's a book that introduces esolangs: Strange Code by Ron Kneusel. Just take a look at the subtitle: "languages that make programming fun again." That's the pitch -- programming used to feel like solving puzzles, and somewhere along the way it started feeling like configuring YAML files. Esolangs bring the puzzle back.

LLMs make it easier to build, but if you miss the pure joy of writing code -- try an esoteric language. Pick up Strange Code, or take a look at esolangs.org, an esoteric programming languages wiki.

References

• Esolang wiki (esolangs.org) -- the community wiki cataloguing esoteric programming languages.
• Strange Code by Ronald T. Kneusel -- No Starch Press book introducing esolangs, from Turing completeness to building your own.
• Rockstar -- the official site, with an online interpreter; programs read like power-ballad lyrics.
• Forth -- Wikipedia overview of the stack-based language.
• Befunge -- the 2D grid language on the Esolang wiki.
• Whitespace -- the language whose only tokens are space, tab, and newline.
• Turing completeness -- why "you could write any program in them" is literally true.

It's public speaking.

You're no longer hired to sit behind three monitors, wearing headphones, and closing tickets in Jira. Junior devs are expected to think about the product. They code less. They talk more.

• With stakeholders: turning a vague request into something you can build, explaining what tradeoffs you made.
• With your team lead: defending your approach when they push back, changing your mind when their pushback is right.
• With your peers: brainstorming together without dominating the conversation, arguing without making it personal.

You can practice your technical skills individually, at home. But public speaking skills can't be practiced at your desk. You need other people in the room (public speaking is supposed to be public!), you need a safe environment (so you can fail and move on), and you need high-quality, actionable feedback. A Toastmasters club can give you all three.

Among other things, Toastmasters has a format called Table Topics -- you get a random question and are asked to speak for 1-2 minutes, no prep. This is exactly the training you need for the 'So what do you think?' moments in meetings! Or for short videos I record for these tips (note, they have no cuts).

I joined Toastmasters last year -- now realizing that I should've done it years earlier. Please don't repeat my mistake. If you're looking for a single action that can make you a better developer -- find a local Toastmasters club.

References

• Toastmasters International -- Wikipedia overview: history, structure, and how clubs work.
• Toastmasters International (official site) -- the organization's home page.
• Find a club -- search for a local or online club near you.
• Table Topics -- the impromptu-speaking format mentioned above.
• Pathways learning experience -- the structured curriculum behind the meetings.

If you're a software developer, your real resume is your GitHub profile.

What should you look for?

First (and easy): the profile page. It's markdown, which means it's simple yet very powerful. Figure out how it works and put together a nice "about me" message. You can include stats, languages, projects, badges... search for examples online — you'll be fascinated by what's possible! This one is an easy fix, with some real ROI.

Second (and this one will take more time): you should have a few public repos. An interested employer might open your GitHub and click around. Give them a choice -- have a few public repos (your projects!) featured in your profile. It's best if the projects are varied -- and if not all of them are classroom projects. This is the primary showcase of your experience.

(What to do if you don't really have many projects to show? Start with one (see Tip 176 for some ideas), give it a little polish, and make it public!)

Third (and the deepest) -- those green squares tell a story. What kind of developer are you? Do you commit only when your class projects are due? Or are you a curious builder?

Your GitHub profile is your most important public asset -- start building it tonight.

So, there should always be a next thing on your learning bucket list. But how do you choose what to learn next?

Let's dig a little bit into pedagogy (theory of learning). German educator Tom Senninger (building on Lev Vygotsky's research) developed a model of three "learning zones." I'll call them +0, +1, and +100.

In the +0 zone, learning feels very easy, but you don't really learn anything new. Learning gets boring. You don't grow.

When you're in the +100 zone, you're trying to learn something that is fundamentally beyond your capacity. This leads to anxiety ("I can't get it, I am stupid"). Learning shuts down.

Now, in the +1 zone, you're adding some new learning to what you already know. It does not always feel easy -- you have to work hard -- but you're clearly learning.

Let's think of a technical example. Suppose you know Python well enough, and you're wondering what to learn next.

The +0 zone is watching another video about Python syntax. You may feel productive ("I'm watching a tutorial!"), you may even earn a certificate (and post it on LinkedIn), but your brain is not really working.

What would then be an example of +100? "I will contribute to CPython!!!" This is great as a "big hairy audacious goal" (more on this in a later tip), but a very bad idea now. If you don't know C, memory management, garbage collection, and the contribution workflow of a massive open-source project, this is a clear path to panic mode and, soon, to the "I am useless" mode.

The +1 zone here can take multiple forms:

• You could read "Fluent Python" to understand how the language actually works under the hood (dunder methods, generators, etc.). Here, you focus on the language and take it deeper.
• Or, you could learn a Python library like Pandas to see how you can solve problems in a different domain (namely, data science).
• Another option could be learning some tooling for Python, like uv or ruff.

Of course, there are situations when you don't really have a choice. Sometimes, your job, or your class force you right into the +100 mode, or keep you stuck in the +0. But when you do have a choice -- which is actually more often than you think -- reflect on what you already know and identify the learning direction. Not too comfortable, yet not the full "panic mode on."

One (+1) step at a time. That's where the most effective learning happens.

On a shallow level, yes. I still can't quite understand many song lyrics, and my Canadian friends still have to explain some jokes to me.

However, on a deeper level, the disadvantage disappears completely.

Just think about this -- I learned English well enough to write this series of tips (and yes, yes, it is me writing, not an LLM). Honestly, after years of practice, I'm probably a better writer than most native English speakers. I also record videos -- and yes, I do have an accent! But what matters is that I have something to say.

Now, there is an actual advantage that I (and many of you reading/watching this) have and many native speakers don't -- I know a whole other language, which is a unique feature of my brain.

Some studies show that humans think in a language. So, for those of us who speak more than one -- our brain has this cool feature -- a multilanguage thinking mode! We might not always notice how it works, but think about this as an engineer for a moment -- if the brain has more "instruction sets," it must be able to do more, right?!

Now, on a purely practical level. You can read more books (I feel so privileged to enjoy Dostoyevsky's original writing). You can relate to more people. You can do business in more places -- not just because you understand what people say in Portuguese/Hindi/Swahili/Russian, but because you also understand the culture -- how to say things and build work relationships.

That's not just nouns and verbs -- that's your whole language arbitrage in action!

So, while you work on your English (which does have enormous value and does open doors worldwide) -- never forget that strategic advantage you have if you're not a native English speaker. Don't hide that advantage, don't apologize for it -- embrace it.

There is one idea that always wins -- build software to solve your own problems. It's always best to build something that someone actually needs, and will use. In other words, it's always best to have a "client" -- instead of building something that nobody asked for.

So, who is the client that is easiest to access? The person reading this right now! :-) Think about it -- when you are your own client, you don't need to do user interviews (voices in your head don't count) -- you already know the pain!

Where to start? Think back about your day -- and try to identify two things:

a) A tedious manual process that you have to do, or b) An app that you use, but are not quite happy with (maybe it doesn't have the features you need, or it's too expensive).

For me, the most recent example was budgeting. My use case is quite unique -- I wanted to track our family budget and my business (sole proprietorship) in a single app. All existing tools were either too basic or too complex. So, I just built my own thing!

Here is an important note -- software you build for yourself might never have more than one user! It doesn't have to become a startup. Just like my budgeting app -- it solves exactly what my wife and I need, and we love it. It's personal software, and it's built as such.

So, when you build something for yourself, enjoy using it (that's the primary goal!) and enjoy the process of learning as you build. Absolutely consider making it a public GitHub repo (easy to do, and gives you clear portfolio value, even if the code is not "perfect" -- and what is perfect code anyway?). But don't try to turn it into a business while you're still using it as personal software. If a business emerges, it'll likely be a clean rebuild anyway.

Let me explain.

There are things that are fragile. Think of glass. It's easy to break. The same applies to fragile people.

Other things are robust. Think of a stone. It is very hard to break! But it's just a matter of the force applied. Get a good industrial grinder, and the stone becomes sand. Same for robust people -- they are strong, but at some point, they will break apart.

Now, think of a sequoia tree. Those are HUGE trees, up to 100 meters high, and they live for up to 3,000 years!

The seeds of a sequoia tree are hidden in a cone, high up in the tree's crown. The cone has a thick, resin-sealed shell, and it can stay closed for up to twenty years. It is waiting. Waiting for the biggest possible chaos -- a devastating forest fire. A fire that destroys everything in the forest: trees, shrubs, brush. The fire also dries out the cone, so it cracks open. And now the new sequoia tree can grow -- with everything else destroyed, it has all the sun it needs, and rich soil!

A sequoia tree is antifragile. It does not just survive the chaos. It GAINS from the chaos. In fact, the hotter the fire, the better the seedlings grow. Without fire, it cannot reproduce at all!

Now, when AI is disrupting everything around us, it feels like there's chaos everywhere. A "safe" job is actually fragile -- everything can change in a moment.

So, how do you become antifragile as a junior developer?

First: build side projects and share them publicly. Your public presence, your visibility, gives you options -- when one path closes, others (maybe better ones!) open.

Second: don't just learn things -- learn how to learn. (More on this in a later tip.)

And if you want more on antifragility, read Nassim Taleb's book, "Antifragile."

Don't be a "yes-machine" to your boss -- she already has one. When you disagree with something, say it -- that is your value. Remember that you are not making your manager's life harder by doing this! Quite the opposite -- if you disagree thoughtfully, you're giving your manager something valuable that others won't.

Don't get me wrong. I don't mean you should be rude. Be sensitive and remember that the ways to disagree are very different in different cultures.

If your manager is North American, you might use the "yes, and" method: "Yes, X is a good idea, and I think we should also consider Y."

In many cultures, public disagreement reads as disrespect -- so the tactic is different. Wait for a 1:1, frame it as a question ("Have we considered Y?"), or follow up in writing where the manager can respond at their own pace (for a deeper dive into cross-cultural communication, I highly recommend Erin Meyer's book "The Culture Map").

Still, the core idea stays the same: your main value as an engineer is NOT your ability to write code (an LLM can do it well). Your value is your judgement. And if your judgment is underutilized because you keep saying "what a great idea, boss" (role-playing ChatGPT) -- then what do you bring?

Yes, your judgment will not always be right -- often, you will disagree, and you will be wrong. That's fine -- be ready to accept it. The question to ask yourself is not "who's right?" but "what's the best path forward?". It's all about solving the problem -- and if you think you have a better solution, don't hide it!

And for many of you, your first job is at this kind of place. It could be fast food, retail, delivery... So, the question is: should you hide this kind of work experience on your resume?

The common advice is "keep only what's relevant." I disagree -- because for a junior dev, this often means a very sad, empty resume that just says, "I don't really have any experience." Do you want to send that message?

So my advice is the opposite: these jobs are way more valuable than you imagine, and you should definitely keep them.

A job at a fast-paced fast-food restaurant teaches you how to:

1. Work with customers and understand their needs (especially problematic customers -- that's your conflict resolution skills!)
2. Handle stress
3. Deal with teammates and supervisors (and their personalities)

These skills -- we normally call them "soft" -- are highly transferable.

In a software development team, you will be doing the very same thing! An angry customer at a restaurant (the kitchen was slow, their order was late) is surprisingly similar to an angry stakeholder (the dev team hit a big blocker and missed a deadline). You are already prepared for most of that!

Two more important things that your future employer will see.

First, it shows your agency. You took a hard job to pay your bills and earn your own living. Likely, you were also helping your family. This shows who you are.

Second, very pragmatically, you've got the stories you need for the behavioral interview! "Tell me about a situation when you resolved a conflict at work" -- I bet you have great stories, so bring them to the interview! Interviewers love specific stories. They can tell when a story is real and when it's invented. And your lived experience -- even from a job that has nothing to do with code -- will always beat a vague, half-fake story about a class project.

So, don't hide your real job. Be proud of it.

I've done both. And I think that the universal 80/20 rule actually applies here. My rule of thumb now: 80% of your work should use tools you trust, 20% should use tools you're learning.

The language I know best is Python (yes, I read the second edition of "Fluent Python," and I highly recommend it). So, when I need a reliable, stable (boring!) choice for something that "needs to work," I choose Python and, likely, FastAPI.

But then, if all of my projects are Python and FastAPI, how would I grow?

So, for many side projects, I go wild and expose myself to something that teaches me a new paradigm (functional vs OO), a new ecosystem (Node vs PyPI), a new data model (relational vs NoSQL).

Recently, I was rebuilding my personal website. Staying "reliable" would mean Python, so Pelican as a static site generator -- but in this case, that feels like "bad boring == no learning," not "good boring == stable results."

So, I deliberately went for something I'd never used before -- Deno (not even Node!) + Lume as the SSG.

A personal site is the kind of project that is "safe" for this kind of choice -- even if things don't go as planned, you still keep the upside ("learning") and the downside is small (easy to rebuild if needed).

The 80% keeps you employable, the 20% keeps you growing.

No, it did not. If you got a new idea, then it was you who created the idea. The LLM helped.

Here is my point: only humans are capable of generating really unique, novel ideas. LLMs only pretend to do this. Think about how an LLM works: the model learned from a giant pile of information — mostly text, whatever is available online: books, articles, Wikipedia, blogs, Reddit posts... actually, lots, lots, LOTS of Reddit posts. So, when the LLM answers you, it predicts the next likely token.

Of course, it's way more complex than that (and you should watch Andrej Karpathy's videos to understand the mechanics), and you can control the way the LLM talks to you by adjusting your prompts and temperature, but in principle, it's all about the next most likely token. And "most likely," statistically, means "what an average Redditor would think about this."

Pause for a moment and imagine an average Reddit thread, and an average response in that thread. Not the most upvoted one! The average reply, the one you won't even scroll to. That's your LLM's judgment.

Now, please don't get me wrong -- I am not anti-LLM. I did run this tip by Claude after I drafted it -- its feedback was actually pretty good. But first, I wrote the tip myself.

Use the LLM as your sounding board, your rubber duck, your critic, your research assistant. But please don't use it to replace something that is only yours -- your creativity.

No, it's not your classmate who was always getting an A+ on every test. It's small children. They learn foundational, sophisticated things -- how about a completely new way to move around in space (it's called "walking"), or a new way to communicate thoughts ("speaking")?

And well, babies don't watch tutorials on YouTube (Baby Shark doesn't count) -- they just play, using the world outside them as a giant playground, and it works.

Also, have you noticed how often your team lead will say, "this is a new framework, just play with it to see how it works"? Of course, they don't mean that you speak with the classes and methods in a funny voice while copying the code around (hmmm, but, actually, why exactly not?). They mean that you tinker, experiment, do whatever comes to mind -- just like a little child would play with something new.

There's actually a theory that explains how this works -- it's called Kolb's Experiential Learning Cycle.

1. You start by playing with something -- it's free-flow experimentation, just do what seems most fun.
2. You reflect on your experience. Sometimes consciously (a chat with an LLM might be a good idea here), sometimes subconsciously, somewhere in the back of your brain.
3. As you play and reflect, your brain builds abstractions. That's how you form skills and knowledge.
4. Then, you play more -- now, in a more informed way. The learning cycle repeats.

So, next time you need to learn something -- a framework, a tool, or a programming language -- do not start with a YouTube tutorial. Instead, install the thing and start tinkering; then, just go where the "fun" takes you.

Even before LLMs, why would you need to write Dijkstra from scratch -- it's already done!

But what you need to have is the intuition for algorithms and data structures. They'll be hiding in unexpected places, and you need to have a good eye to notice them.

My student shared a story the other day. She took her son to a corn maze near Vancouver. We were learning graphs in class that week, so, while in the maze, she realized that she and her son were actually... using DFS! She then imagined BFS, and laughed at how ridiculous it would be (please pause and imagine BFS in a corn maze, it's genuinely funny).

Want a more technical example of an "everyday thing"? Git. Git history is an acyclic graph (type git log to see it). Since it's a graph, the graph magic is at your disposal. Merging a pull request? Least-common ancestor problem (your CS2 algorithm, hiding in every pull request merge out there).

As a developer, you're not just the user of Git and other existing systems. You will need to design such systems. It will be your decision whether to use an acyclic graph. So when you see a problem, you should intuitively see what can be used there.

This intuition comes with experience, and it's not easy to train. But like every muscle, it can be trained -- by constantly dissecting everyday things.

A long, annoying line for Richmond Night Market (where you can pay to skip it)? Priority queue.

Starbucks mobile order pickup shelf? Hash table (and watch for collision if you have a common name!).

Shared kitchen fridge in student housing? Memory allocation and (quite literal) garbage collection.

As an engineer, you should see things differently. Even if sometimes this goes too far (just last week, I found myself chitchatting about linked lists at a party; true story).

I bet it was a long time ago. Or never. (Ask me how I know!)

Sure, before LLMs, students would sometimes come to profs' office hours for shallow reasons -- to debug code together, or to clarify something from the textbook. Now, such things are handled perfectly by an LLM, and you can keep asking follow-up questions until the context window gets full (humans sometimes have slightly lower tolerance for this).

I keep saying -- LLMs are great, and they replace a human instructor in many, many cases. But when it comes to deep, reflective questions, they'll keep telling you the "averaged" narrative, over and over again.

To get unique points of view, we need to speak with other human beings.

But how do you find unique, interesting people to speak with? There are ways, but they all require extra effort: events, networking, asking for warm introductions... Getting coffee chats with original thinkers (and you want to speak with those people) is very hard.

If you're a student, you have a huge unfair advantage -- professors' office hours. Don't come to argue about your grades (who cares about grades). Come to speak with your prof.

Ask reflective questions.

What is on your mind right now? Maybe you're worried about finding a job. So, ask: "How did you find your first job?" Of course, it was before the AI revolution, but we know that genuine, unique human stories will survive a revolution (read "Doctor Zhivago" if you haven't yet).

A little-known fact: you don't actually need to be in the prof's class to join their office hours. Just figure out the time, show up, and introduce yourself. The prof will never kick you out -- they'll be flattered that you showed up and want to talk.

P.S. If you recently graduated, you can still get away with this for a while :-)

I promise (unless your job is Photoshop or AutoCAD) you'll do just fine, and you'll learn some productivity tricks that may stick.

...back in 2002, I got a job as a student technician in a summer camp. We packed a PC and brought it to the camp. We brought everything we needed -- monitor, keyboard, printer, enough paper... we just forgot about the mouse. The next car from the city would arrive only a few days later, and I was in charge of the camp's only computer -- spreadsheets, invoices, cafeteria menus.

And I realized that I could use Word and Excel just fine. There are hotkeys for almost everything, and I learned them faster than I thought. I still use some! (yes, Word is notoriously backward compatible)

Now, I'm not asking you to learn the hotkeys of MS Word. Word and Excel were my daily tools in that summer camp. What are your daily tools? Your terminal is keyboard-first already. What else? IDE? Issue tracker? Messenger?

My bet is that if it's a tool created for developers, it has a "power user" mode that is keyboard-heavy. And it doesn't have to be Neovim! VS Code has a command palette (Ctrl+Shift+P is your portal to the kingdom of hotkeys); your browser has Ctrl+L, Ctrl+Tab and F5...

So it's not just that you can do everything without a mouse -- in many cases, you'll be more efficient this way -- your hands never leave the keyboard, so you do things faster and keep your focus (and I'm not mentioning that it just looks cool -- I always go "aaaaah" when I see a student demoing their code in Neovim).

So, if you were waiting for an incentive to learn the tricks, just create your incentive -- tomorrow, hide your mouse in a drawer, disable the touchpad, and start the day.