I'm Launching Street-Smart Coding: 30 Lessons to Help You Code Like a Pro (the Roadmap I Wish I Had Starting Out)

I spent five years in college learning to code.

A stupid dissertation delayed my graduation. But that’s another story.

Most of my five-year program didn’t prepare me for real-world coding. My real coding journey began at my first job, with one Google search: “how to get good at coding.”

I found a lot of conflicting advice:

• “Use comments”
• “Don’t use comments”
• “Do this”
• “Don’t do that”

Arrggg!

It took years of trial and error to learn what worked.

I had to survive on-call shifts, talk to stakeholders, and say “no” politely. More importantly, I had to learn that coding takes more than just syntax.

That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind, so you don’t have to go down the same rabbit hole.

I wrote it for every developer who’s ever typed “how to get better at coding” into Google or ChatGPT, just like me back in my first job.

Inside “Street-Smart Coding”

Some lessons inside Street-Smart Coding are conventional. Others were learned the hard way. And a few are weird.

One of the tips will save you from staying at work until 3:00 a.m. That’s on Chapter #21.

Another tip is to watch a TV show. And no, it’s not Mr. Robot or Silicon Valley. That’s on Chapter #29. It will teach you about problem-solving.

But all the tips and lessons are battle-tested.

These are the lessons I wish I had starting out, the lessons I learned over ten years through plenty of mistakes. Now they’re yours.

Get your copy of Street-Smart Coding here

7 Hard-Earned Lessons from Launching Street-Smart Coding

Last month, I launched Street-Smart Coding, my most ambitious writing project so far.

I wrote the roadmap I wish I had at the start of my coding journey. I had written mini-books before, but this one was different. It pushed my writing and marketing skills, and my self-discipline.

Writing taught me lessons, but launching was a whole different game.

Here’s what I’ve learned:

#1. Set an artificial deadline. To keep yourself focused, set a launch day. Pick a day and mark it on your calendar. Also share it with everyone involved in your book: beta readers, designers, editors…

#2. Start with a promise, title, and outline. Before writing the actual content, start with the sales page or the Amazon description. It forces you to clarify your message. And to make the promotion phase easier, come up with a one-liner to explain your book.

#3. Focus on one big project at a time. While writing the book, I was:

• Engaging on LinkedIn
• Sending a weekly email
• Writing a daily blog post
• Coding for a contracting client

I could have finished in half the time by focusing on one commitment. I only started to see progress when I focused on my book and let all other projects suffer. It’s really easy to lose momentum with a book.

Make your book your priority.

#4. Start selling before your book is done. Write your intro and some chapters and go pre-sell it. You don’t even need a final cover. You can change it later.

I made 4 sales in the first two weeks: two preorders and two sales. That was enough to see some traction and keep going.

The other day, I read that we should start marketing the day we start a project. I read it about coding side projects, but it’s also true for books.

#5. Share every stage of your journey. Finished the first draft? Share it. Designed the cover? Share it. Choose a final title? Share it. Share every milestone on your social media, newsletter, or blog. And plug a pre-sale CTA on every piece of content.

For my title, I had three winning ideas. To pick one, I ran a poll on LinkedIn and let followers and readers vote. Their favorite became the final title.

#6. Focus on one task at a time. A book demands you to wear multiple hats:

• Writer
• Designer
• Marketer
• Copywriter
• Project manager

Of course, if you’re with a publisher, they will take care of some of those tasks. But when you’re self-publishing, you’re on your own.   All those tasks might be daunting, but focus on the task at hand.

Being a fan of writing 10-idea lists, I used 10-idea lists for every step of the process:

• 10 title ideas
• 10 chapter ideas
• 10 possible beta readers
• 10 promotion ideas

Don’t overthink the next steps beforehand.

#7. Promote it everywhere. Once you write the last word of your first draft, you’re not a writer anymore. You’re a salesperson. Go out and sell your book!

Promote it everywhere: your email signature, social media, blog, newsletter, even WhatsApp. Do the work, then tell the world about it.

Launching and promoting a book has been a long but rewarding experience. Even after many revisions, the fear of typos didn’t easily go away. But I’ve loved the experience so much that I’m already working on the next. Every lesson makes the next one even better.

6 Lines That Have Made me Think Recently

I’ve reduced the media I consume. I’ve stuck to books and podcasts while doing the dishes, and occasionally a few forums and indie bloggers via Minifeed.

From those few sources, these lines have made me think recently.

#1. AI won’t take your job. It will change your job description.

#2. The rich have money, the wealthy have time.

#3. Don’t be the best, be the only.

Those three come from Kevin Kelly, the guy behind the 1,000 true fan concept. I’ve been listening to this podcast interview. I don’t know how many dishes I need to wash to finish it.

#4. Hands first, then computer. This is a line I found on Steal Like an Artist. Computers have disconnected us from doing art with our hands.

#5. Momentum isn’t doing more, it’s doing less, but better.

#6. Two hours of focus work today can create a lifetime of income tomorrow.

This comes from Mark Thompson, a veteran marketer I’ve been following recently. I’ve used Mark’s Sales Funnel method to promote my new book.

Friday Links: Leaving jobs, full-stack myth, and stickers

Hey there. Here are 4 main links plus 2 extras I thought were worth sharing this week:

#1. I’d give my junior self lots of advice. But if I had to choose one, I’d say always be ready to leave your job (6min), even if you’re not planning to leave.

#2. I once tried being full-stack, until I discovered the backend world: RESTful APIs and DDD. Maybe being a full-stack coder is a myth (10min) after all.

#3. Here’s a quick take on why polymorphic tables aren’t a good idea (3min).

#4. Could strict best practices and clean code create an unhealthy culture (10min)?

And two quick ones, just for fun:

#a. I had my first laptop full of stickers. If you’re like the old me, share your laptop stickers on stickertop.art.

#b. It seems we coders aren’t the only ones copy-pasting from ChatGPT. Journalists do it too

And in case you missed it, I wrote on my blog about 8 steps to take over a legacy codebase (5min) and when AI feels like cheating (2min).

(Bzzz…Radio voice) This email was brought to you by… Street-Smart Coding: 30 Ways to Get Better at Coding. From Googling to clear communication, it covers 30 lessons to help you code like a pro. It’s the roadmap I wish I had moving from junior to senior, and the one I hope helps you too.

See you next time,

Cesar

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.

8 Proven Steps to Take Over a Legacy Codebase (Without Losing Your Mind)

Like it or not, you can’t escape from legacy code.

I know how it feels to inherit a codebase like that. The “what I’m supposed to do now” feeling. While I’m writing this, my latest gig is yet another legacy code.

I’m not alone. Recently I found this question on Reddit, a fellow coder who received a codebase with only a handoff from a coworker.

I’m about to take over an .NET Core + SQL Server + Knockout.js/Angular project at my company. The issue: There’s zero documentation. I’ll only get a short handover from a teammate…

My main questions are:

• For legacy .NET projects, what’s your process to get up to speed fast?
• Should I start writing my own documentation (README, architecture notes, etc.) while I learn?
• Any tools/tips for mapping out the database + system structure quickly?
• From your experience, what do you focus on first: business logic, database schema, or the code itself?

I’d love to hear how you’ve handled taking over undocumented C# / .NET projects before. Thanks!

Having been in their shoes in every job I’ve had, here’s how I’d approach inheriting a legacy codebase, step by step:

#1. Understand it takes time.

It takes 6-12 months to know the ins and outs of a medium-to-large legacy codebase. Your mileage may vary. The point is: You don’t have to know every single small detail up front.

#2. Install and run the app.

Your first step should be to have your working environment running on your machine.

Install the tools you need: maybe a database engine, editor plugins, or scripts.

Also, this is a good opportunity to document those prerequisites in a README file and to open your first pull request.

#3. List the main components.

Don’t jump to files and methods.

Instead, get to know the overall architecture of the app:

• Is that a monolith? Does it use microservices?
• How many databases does it use?
• Does it call external APIs or services?

You can go as simple or as fancy as you want. Maybe that’s a sketch on a whiteboard or a version-controlled compiled diagram. I tend to go simple with pen and paper.

#4. Learn the building blocks.

Navigate the source code of the main solution or entrypoint.

Try to answer:

• What is the folder structure?
• How is the code organized? Per project? Per domain?
• How does it access the database? Stored procedures? An ORM? Plain SQL queries?
• How does it achieve common tasks like logging, REST calls, etc?

#5. Look for the most frequently changed files.

This is a trick I learned from Your Code Like a Crime Scene by Adam Tornhill.

Those are the places that attract complexity. That’s where bugs tend to happen or where requirements aren’t clear. They’re like the most dangerous places in your code.

If you’re lucky and the code is under version control, use and tweak this Git command,

alias gmost='git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10'

I probably found it on StackOverflow. Or use fancier code analysis tools instead.

#6. Find out the most frequently used features.

Get to know how the end users interact with the app and what the 20% of features they use 80% of the time.

You will find one single screen they use daily, or just a few buttons out of a dozen. “Do one thing and do it well” is often a dream in enterprise software.

#7. Find out the module or component that gets more bug reports.

This is the spot to focus on first or to get early victories.

It doesn’t have to be the same one as the most used component or feature. Maybe it’s a report that runs once a month or a page that takes forever to finish. Or whatever.

Ask users about common pains. Maybe some ex-coworker always mentioned a fix. “Oh, every time that thing broke, Bob mentioned he had to…” You’re like a detective looking for clues.

#8. List key tables and parametrization tables.

Don’t try to understand every detail. Start with the overall design.

Is it one database per client in the same server? Or separate schemas per client?

Then try to generate a diagram from your database schema.

Most likely, you’ll find one or two key tables. Those are the “Reservations,” “Invoices,” or “Orders” tables. They tend to attract more references.

And you’ll also find parametrization tables. Those are tables with only a few records that power the behavior of the system. They’re good candidates for caching.

Parting thought

With those steps, you’ll get a clear big-picture of the codebase. Start broad, then move on to the details when you need it. That’s far better than trying to understand every single class or method up front.

Working with legacy code isn’t glamorous, but it’s the reality of our work. Most of the time, we’re maintaining and modernizing live systems, not building new ones from scratch.

That’s why I dedicate a chapter to legacy code in my book, Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind. Junior me thought I’d only start new projects with the latest tools. Wrong!

Grab your copy of Street-Smart Coding here. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

Wednesday Links: $0.01, layoffs, and Zuckerberg emails

Hey there.

I just realized I already had 4 links and I didn’t want to wait for next Friday to share them. So here they are.

These first two are just for laughs:

#1. Imagine waking up to an invoice for $0.01 from your cloud provider. Yep, that happened. Here’s the full story (10min).

#2. Now imagine sharing a name with the creator of a major social media platform. You won’t believe how many emails you would receive if your name were Mark Zuckerberg (2min).

On a more thoughtful and serious note…

#3. Everybody blames AI for the recent layoffs, especially the ones at Amazon. But there’s a real reason (1min) and of course, nothing to do with AI.

#4. My best interview was just one call and one open source contribution. That happens rarely. But what if open source contributions were like service duty? (2min).

And in case you missed it, I wrote on my blog about the scariest lines of code I’ve written (2min) and my reactions to r/csharp homepage (4min).

(Bzzz…Radio voice) This email was brought to you by… Check my latest book, Street-Smart Coding: 30 Ways to Get Better at Coding. From Googling to clear communication, you’ll find 30 lessons to help you code like a pro. It’s the roadmap I wish I had moving from junior to senior and the one I hope helps you too.

See you next time,

Cesar

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.