The Not-an-Architect Effect

Has this also happened to you?

You’re in a meeting discussing a technical issue or a bug. After many ideas, you share yours. But it passes unnoticed.

Since there was no consensus, another meeting is scheduled. But this time with a figure of authority or expertise: an architect, director, or VP.

Surprisingly enough, they share the same idea as yours. But this time, it’s considered.

That’s when you say “I said the same thing, but since I’m not an architect, director, or VP nobody listened.” Arrggg!

Sure, those moments are frustrating. But they earn us points in our authority and trust score.

It’s not only about sharing good ideas, but how we present them and how others perceive us, just another team member or a trusted one.

That’s what I call: the not-an-architect effect. A reminder that how we present our ideas is as important as the ideas themselves.

Minifeed Showed Me the Indie Web: My Favorites from Yesterday's Feed

If you’re not new to writing online, you’ve heard blogging is dead.

And there’s some truth behind that. Social media has killed blogging. Google doesn’t like personal blogs anymore. It’s regurgitating AI answers. That made me change my writing strategy, by the way. My blog isn’t the only place I show up anymore.

Personal blogs are still alive…in a small corner of the Internet. The problem is discovering them.

If Google’s bots don’t crawl and index your blog, your posts will sit there forever, waiting for visitors. That’s not the case with social media. Just open your account and scroll your feed. And boom! Content is there!

These days, while looking at my analytics, I discovered out a “feed” for blogs: minifeed

Minifeed is “a curated blog directory, reader, and search engine.”

Its goal is to collect personal blogs and make them discoverable. No AI or algorithms behind the feed, just human curation.

Yesterday, I scrolled through minifeed’s feed and went down the rabbit hole of personal blogs. Here are my favorite posts:

#1. A photo of a big door. This is from a photographer running a plog, a photo blog. Did I just invented a new Internet word?

#2. A diagram of feline feelings.

#3. A software engineer who changed his mind about AI.

#4. A reflection on time passing.

#5. A developer who learned about nonograms. Imagine a sudoku marrying a crossword, but instead of putting numbers in cells, you have to color them. Definitely, I’m giving them a try.

#6. A writer who decided to stop writing down ideas because good ideas always come back. Well, I need to write them down to tell my brain “it’s OK, we already did something about it. Back to sleep.” I also discovered another daily blogger.

#7. A post on why requests to fire people are often rejected.

#8. Someone using music as a pain reliever after getting his knee replaced.

#9. And of course, my own post with tips to read code. Shameless plug.

If you want to go down the rabbit hole of personal blogs, try indieblog.page to get a random post or searchmysite.net for a search engine of personal blogs, ooh.directory, or blogroll. Blogging isn’t dead yet.

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.”