Three Tips to Read Code More Effectively

We spend more time reading than writing code, but we’re seldom taught how to read it.

Almost 100% of my coding courses in university were about writing code: syntax, algorithms, and class design. Nothing about reading. I only learned about reading code from a coworker at a past job.

Yesterday, I found this conversation as part of the GOTO Conference about reading code:

Here are some key points from that conversation:

#1. Read a piece of code at first glance and see what stands out. Maybe that’s a function or a symbol or a messy block of code. That’s also my go-to guide to refactor a piece of code: while scrolling through a piece of code, if I need to stop and read it twice, there’s something to refactor, something needs to be better explained.

#2. Read with empathy. After reading Clean Code for the first time, when I found a piece of code that wasn’t closely aligned to the book, I always said “who wrote this crap?!” I had to learn that we all do our best with the context and deadlines we have. If we have to fix a pressing issue in 24 hours, we do our best. That might not be the perfect solution. And of course, there will always be better ways to solve a problem, once we solve it for the first time.

#3. Always start by pointing the good parts, especially when auditing or reviewing other people’s code. It reminds me of the principle from How to Win Friends and Influence People: don’t tell anyone they’re wrong.

Read more code, that’s the best way to learn to code. The more code you read, the better at writing you become.

A Simple Script to Keep a Log File with Bash and Vim

To keep track of my client work, I’ve been using a simple “did” file. You know, I’m a plain-text fan.

At the end of every workday, I write down what I did for that client and what I need to do the next working day.

Here’s the script I use—add it to any of your dotfiles:

function did() {
    vim +'normal Go' +'r! date "+\%Y-\%m-\%d \%H:\%M:\%S"' +'normal o' ~/did.txt
}

From a terminal, simply type did, and it opens a “did.txt” file with Vim, appends the current date and time at the end, and you’re ready to type. Simple as that.

For everything apart from client work, I’ve ditched my to-do lists.

10 Ways New Coders Can Use AI Without Generating Code

If you don’t know how to code, you shouldn’t rely on AI to generate code.

AI is here to stay. Sure. We can’t ignore it. We have to adapt, like we coders have always done.

But the problem with AI is when we use it to outsource or replace our thinking. If you’re not the one using the tool, you’re becoming the tool. And tools are easy to replace when a faster and better tool appears.

If you’re a new coder, don’t ask AI to generate code for you.

Ask AI to do any of these tasks instead:

1. Review your code
2. Dissect a piece of code
3. Explain difficult concepts
4. Create roadmaps and study guides
5. Act as your debugging rubber duck
6. Generate test cases or sample inputs
7. Learn the most common language features
8. Look for security and performance issues
9. Create questionnaires to evaluate yourself
10. Check your understanding of a difficult concept
11. Translate one piece of code to another language
12. Learn the most common methods from standard libraries

Using AI is like using calculators in math classes. They can make you faster if you know what you’re doing, but they can’t think for you. As I learned from Jim Kwik, the brain coach, “use Artificial Intelligence to extend your Human Intelligence, not to replace it.”

9 Lessons from Writing 10 (Bad) Ideas Daily to Become an Idea Machine

Since October 2024, I’ve written 10 bad ideas every single day and it has transformed my creativity.

I started this practice inspired by James Altucher. I found it on his blog and books. Choose Yourself Guide to Wealth covers it in-depth. He calls it: becoming an idea machine.

The point of writing 10 ideas isn’t to come up with 10 perfect ideas, but to exercise your creativity and possibility muscles. The goal is to write 10 bad ideas about anything every single day.

Here’s what I’ve noticed after writing thousands of bad ideas in six months:

1. You can’t run out of ideas

One of my concerns when I started was running out of subjects to write ideas about. But the more I practice it, the more subjects I find to write 10 ideas about.

2. A 10-idea list could be a post

Most of my social media and blog posts start from a 10-idea list. This very post was a 10-idea list.

Writing 10-idea lists is the first step of my content wheel: 10-idea list, then a social media post, then a blog post.

3. It’s easier to execute ideas starting from 10-idea lists

Starting a big project may feel daunting, with too many moving parts and too much uncertainty.

But it’s easier starting with 10 bad ideas, then writing another 10 to execute one of them.

For example, do you want to write a book? Write 10 subjects you can write a book about. Then, write 10 titles for a book on one of those first 10 subjects. Then, write 10 ideas for chapters. Then, 10 stories to include…and so on and so forth.

4. The first 5 or 6 ideas are the easiest ones

The other 4 or 5 are when you start sweating and stretching your idea muscles. After those 4 or 5, that’s when the aha moments happen.

5. Give away 10 ideas to connect with others

Instead of reaching out to ask for anything, give away 10 ideas.

Since I started this practice, my favorite way to connect with someone on LinkedIn (or via email) is giving away 10 post ideas the other person could write. It surprises them and makes the connection more meaningful because you’re giving, not asking.

6. Writing 10 ideas works like note-taking

After consuming anything, a book or podcast episode, I write 10 ideas I learned from it. It works like taking notes. It helps me recall the main points of what I consumed and remember them more.

7. It’s a perfect exercise to quiet your mind

Write 10 ideas about anything and give your mind a productive task instead of letting it wander off imagining lions behind bushes trying to attack you.

8. It’s a perfect replacement for a to-do list

Since this year, I’ve ditched my to-do lists and replaced them with a done list. Guess how I do it? Yes, with a 10-point list.

At the end of every month, write 10 things you did in that month.

9. Write prompts for future days

As soon as I have a subject to write 10 ideas about, I write it as a prompt on a new page of my idea pad. Otherwise, I forget about it. It’s easier to sit down and write 10 ideas the next day when you already have a prompt ready.

Writing 10 ideas a day helped James Altucher get out of bankruptcy and change his life. For me? It has given me lots of ideas for new content. It helped me with my 100-daily-post challenge. It made me more creative. Because creativity isn’t just about art. It’s also coming up with bad ideas. It’s about becoming an idea machine.

Is Burnout Inevitable in the World of Tech?

In 2023, I burned out.

I checked all the boxes for the first time. The burnout boxes. It wasn’t a good thing. And it took me almost an entire year to recover.

I know I’m not the only one, of course. It’s all over the tech industry.

In recent weeks, I’ve been exchanging emails with another senior software engineer who went through a burnout season. His take? The tech industry is unsustainable.

These days, I’ve been chatting with a group of colleagues and friends. Most of them claimed to experience some sort of boredom at their jobs. OK, boredom isn’t burnout, but it’s a warning sign.

We’re privileged to work in the tech industry.

But, it has its own challenges—YMMV, of course:

• We work long hours.
• Coding is mentally exhausting.
• AI threatens us to take our jobs.
• Layoffs are always around the corner.
• Agile and SCRUM take control away from us and trap us in “ceremonies.”
• We’re problem solvers at heart, but often we don’t get to solve problems.
• We’re expected to code after hours just to prove we’re “passionate.” Side projects and open source contributions.
• We have high standards for quality and development practices. But stakeholders’ expectations don’t align ours. They care about different things.

The toll? Our mental health. Burnout.

The solution? I don’t have one.

Yesterday I found on the front page of Hacker News a post about tech being a burnout machine and unionizing as the solution. Mmmm. Dunno.

My best idea? Detach our sense of meaning from our jobs, recognize there’s nothing wrong with coding just to pay the bills, set boundaries between work and non-work, and diversify our sources of joy.