08 Jan 2026 #coding
We no longer need to keep learning new programming languages.
If AI writes 90% of our code, becoming a polyglot coder isn’t valuable anymore.
Here’s what Gergely Orosz says in When AI Writes All Code,
…With AI writing most of the code, the advantage of knowing several languages will become less important when any engineer can jump into any codebase and ask the AI to implement a feature – which it will probably take a decent stab at. Even better, you can ask AI to explain parts of the codebase and quickly pick up a language much faster than without AI tools.
Obsessing over learning languages didn’t work for me. That was before AI.
Trying to master many languages was my biggest mistake as a new coder. Something else always made people stand out. And something else got me into trouble.
The real question is what skills matter.
Maybe AI is making us:
- Master one general-purpose language, like C or Go.
- Understand core principles: problem decomposition, clean code, and SOLID.
- Develop strong code-reading skills
Or maybe we should learn languages that challenge our thinking: Haskell, LISP, or a language from a different paradigm. Learning Java after C# doesn’t teach much. AI can generate code in “challenging” languages, but they build stronger problem-solving skills for prompting LLMs.
To stand out when AI shines at coding, we need to step beyond the IDE. We need teamwork, communication, and the broader skills I cover in Street-Smart Coding. It’s the roadmap I wish I had when starting out.
07 Jan 2026 #books #writing
As writers, your job is to adapt to how your readers consume words.
Why this matters: Content is free and abundant. We are drowning in emails, Slack messages, and beeps and buzzes. In seconds, we decide to read or keep scrolling.
A wall of text makes us stop reading. I learned that the hard way. And you and I do the same.
We don’t read, but skim.
Deliver fast. Say more with fewer words. That’s the big idea behind Smart Brevity, the digital version of the classic Elements of Style.
Here are six lessons to apply Smart Brevity:
#1. The one idea test. Start writing the one thing you want readers to know. Put it front and center. Then ask someone else if they can find it.
#2. Use headline, strong first line, “why,” and “go deeper.”
- Don’t make people choose what’s important. You tell them.
- Tell readers what your piece is about and if it’s for them.
- Use key phrases to guide skimmers. Phrases like “why this matters,” “the big picture,” or “backstory.”
In Mastery, Robert Greene used “Understand” to introduce big ideas. That’s a visual clue for skimmers.
#3. The bar & beach test. Write like a human. Don’t use any word you wouldn’t use in a bar or on the beach. No more “Dear LinkedIn network, I’m pleased to announce…“
#4. The “would you read it?” test. Once you’re done, ask yourself: “Would I read it if I hadn’t written it?” If not, why do you think someone else will?
#5. For email subject lines:
- Use 6 words and prefer one-syllable words.
- Emojis make your subject lines stand out.
#6. For presentations:
- Start and end with “if you remember one thing from this, …“
- Use 5 or 6 slides and one point per slide.
For fiction, we want authors to take us to new, imaginary worlds. But for emails, presentations, and social media posts, we need shorter, clear text. Even in non-fiction, why make readers flip through pages for one points? Brevity always wins!
06 Jan 2026 #writing #interview #coding
If you have a coding blog, sooner or later you’ll write a “hiring is broken” post.
Today on r/programming, I saw another one. I’ve written mine too.
Yes, we don’t know how to hire. Behavioral questions, LeetCode, take-homes, IQ tests…Every company has a different answer.
But our “hiring is broken” posts won’t change how big corporations interview. Decision-makers don’t read coders’ blogs.
Instead of venting into the void, why not share “here’s what I learned and what I wish I had done differently…” posts, including:
- The kind of interview
- Subjects you forgot to review
- What you like and dislike about the process
Keep blogging. One day, your blog becomes your portfolio, and interviews turn into discussions about your posts. That has happened to me only once.
Blogging won’t fix hiring overnight. But it can fix how you stand out. That’s why it’s one of the lessons in Street-Smart Coding, the roadmap I wish I had staring out.
05 Jan 2026 #coding
If AI can do it in minutes, it’s not special.
AI has made coding accessible. You don’t need a degree or bootcamp to have something working. A few prompts to an LLM can replace hours or days of work.
That’s good news…and bad news.
A portfolio with the same to-do apps no longer stands out. Anyone can do that with AI in a few minutes. Maybe the alternative is a “build/learn in public” YouTube channel. Or contributing to non-trivial open source projects.
A take-home challenge doesn’t work for hiring. Again. An easy task for AI. Maybe whiteboarding interviews won’t go away.
Only crafting clean code isn’t enough.
Don’t burn your copy of Clean Code. You still need to tell whether what AI spits out is good code.
But you need to do what AI can’t:
- Ownership when code breaks
- Collaboration to build trust
- Communication to present technical problems clearly
That’s what you can’t automate. Those skills worked 10 years ago and will work 10 years from now.
To help you build the skills to stand out, I wrote Street-Smart Coding—The roadmap I wish I had on my journey from junior to senior.
04 Jan 2026 #coding #career
Good code won’t save your career.
For so long, I chased perfectly clean code, thinking better code = better cod-er. That turned me into a clean code cop, looking for infractions around me. It got me fired.
Focusing on syntax alone was my biggest mistake as a new coder.
Why code isn’t enough
Two experiences taught me good code isn’t what mattered most.
At a past job, when the team leader left, the one promoted wasn’t the best coder. It was the one who showed initiative to own the core feature.
Then during layoffs, I talked to a leader from another team. He was told to sort people into buckets: A, B, and C. Bucket C left first, then B, then A. The criteria wasn’t perfect code. It was whether the leader wanted you on the team. Of course, the ones writing horrible code got into the C crowd first.
It was always something else besides coding.
Your code can’t speak.
Addy Osmani, a leader at Google, shares why you need more than code to stand out.
He wrote,
Your code doesn’t advocate for you. People do.
…Code sits silently in a repository. Your manager mentions you in a meeting, or they don’t. A peer recommends you for a project, or someone else.
Get good at coding to stand out. No doubt!
But your code won’t speak for you.
Here’s what will:
- Asking the right questions in meetings.
- Working on something that brings (or saves) money.
- Sharing your achievements after every project.
- Being responsible for a feature from end to end.
- Being the team member everyone wants to work with.
People won’t remember your code. They will remember your attitude.
That’s why I wrote Street-Smart Coding, the roadmap I wish I had starting out to grow and stand out as a coder.
Grab your copy of Street-Smart Coding here