Tag: coding practices

  • Vibe coding made less terrifying

    Vibe coding made less terrifying

    It’s been a long time since I’ve felt I like I was hanging on every word of a book.

    I was so done reading about AI. Then I saw that IT Revolution was publishing a new book:

    Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond, by Gene Kim and Steve Yegge.

    The book isn’t out until October, but I have a few sample chapters of the ebook because I’m on IT Revolution’s mailing list. And I realized that, despite my current dread of all things AI-related, I should read those sample chapters before attending the seminar.

    Wow, y’all. It’s been a long time since I’ve felt like I was hanging on every word of a book. This is one of those books.

    I’ve already added it to my list of books I recommend. And I have a whole list of people, developers and non-developers alike, who I think would enjoy it. (I may be able to get you a discount. More about that later.)

    Skeptical of vibe coding? I sure was, and to some extent still am. Gene and Steve were, too.

    But they are clearly converts, and the book is getting me to rethink my initial impressions.

    Addressing concerns

    Yes, there are serious concerns about writing “real” production code with vibe coding, where you’re not really delving into the code output.

    • Is the coding process itself safe?
    • Is the code it generates secure, maintainable, and extendable?
    • If you don’t understand or even look at the code, how can you be sure there isn’t some terrible problem lurking that will cause major problems once it’s in production? Okay, you can never be sure of that, but it seems so much worse if you don’t fully understand the code.

    It’s clear that the authors of this book are grappling with these same concerns. The chapters where they talk about how to approach vibe coding for better results are still ahead, and not part of the sneak preview! Argh, cliffhanger! 🙂

    Magic and hope

    One of my early takeaways isn’t directly related to vibe coding at all: I finally understood why, after 20 years as a developer, I just didn’t want to write code anymore. The tedious parts have started to outweigh the magic. If you’re feeling that way, too, you’re not alone.

    Vibe coding may be a way for developers to rediscover that magic. It may also be an opportunity for people not trained as developers to discover it too, and to create new software directly.

    The book also gives me hope that the role of the developer, even the junior developer, isn’t disappearing. Changing, yes, that’s inevitable. But they point to other historical moments where people feared the end of our profession, and those moments turned out to be times of growth.

    Learning more

    My thoughts these days are all about the role of humanity for software developers, so I’m interested to see what I’ll learn from Gene and Steve’s session and the conference itself. I’ll report back on my mailing list after the conference.

    Does this Vibe Coding book sound like a good read to you, too? Want 15% off a paperback copy?

    If there’s interest, I will coordinate a bulk order for 15% off for folks on my mailing list. Email me or message me on LinkedIn by 9/28 to let me know if you’re interested.

    Join the mailing list below so you don’t miss a thing!

  • Naming things, in spades

    Naming things, in spades

    Naming things is hard. One of the hardest things in computer science, as the saying goes.

    I once spent a full day trying to find the perfect name. Does that seem excessive? Well, consider these factors:

    • I was coding a major feature of the application. All users, whether they were customers or colleagues, would use whatever name I chose. It would even be an option on the main menu.
    • A large part of the codebase would also use the name. Developers would see it a lot.
    • I refused to choose an obscure name or a name so long that it would get abbreviated. Nobody should have to ask what it meant.
    • Many potential names were already in common use for related, but not identical, concepts. Some of those names would even appear on the same screens.

    I finally found the perfect name. We integrated it into the application design, the code, and the way we talked and thought about that feature.

    You know where this is going, don’t you…

    Many months later, we changed one of the tools we used as developers. The new tool used the same name for yet another related, but not identical, concept. 😭 After much agonizing, we changed the name of the feature, and I spent another full day updating every reference to it across the entire application and all of our documentation.

    So, as someone experienced in the sport of naming things, I can help. Let me make it easier for you.

    S

    That’s right… S.

    True story: I once spent hours trying to troubleshoot a program where all of the variables had single letter names. By the time I figured out how C, D, E, H, P, M, N, R, S, and W all fit together, I had forgotten what I was looking for and why.

    Also, it was causing a production issue, and it was several hours past my bedtime. I was groggy and desperately trying to fix everything before user traffic started to pick up in the early morning hours.

    Photo by Surendran MP on Unsplash

    “It seemed like a good idea at the time,” the code’s author said when I confronted him about it the next day. 😠

    Would it help to have comments telling you what C, D, E, H, P, M, N, R, S, and W all represent? Maybe, but sooner or later someone’s going to change the code without updating the comments, and then the outdated comments might actually make things more confusing.

    So, rule one: No single letter variables. Please and thank you.

    The only exception might be a small for loop where it’s clear that c or i is a simple counter, like this:

    for (let i = 0; i < 9; i++) ...

    Otherwise, please call a spade a spade, not an S.

    Say what you mean

    That said, info is not much better than i. Info about what? You can do better than that.

    92.84% of the time, adding info and data and details doesn’t contribute to the conversation. It’s okay for customer to refer to an object with all the details about the customer. You don’t need to call it customerDetails or customerInfo. Think of how much nicer it will look when you use dot notation: customer.firstName beats customerData.firstName.

    Granted, 7.something% of the time (I can’t be bothered to do the math on my made-up statistic), you won’t have a choice. You have to differentiate between customer and customerDetails, and there’s just no getting around it. You’ll know those times when you see them. Keep it simple until the code strong-arms you into doing otherwise.

    Rule two, then: call a spade a spade, not a digToolInfo.

    Someone using a digToolInfo to unsettle() some plantingSubstrate. (Photo by Anaya Katlego on Unsplash)

    Keep it short

    You don’t call the bank and ask “what is the current value of the total amount of money in my account?” You don’t call the bank at all these days, but that’s beside the point. You’d just ask: “what’s my balance?” No need to call it currentValueOfTheTotalAmountOfMoneyInTheAccount when it’s a balance.

    It might be a currentBalance if you need to distinguish it from some other kind of balance — previousBalance, maybe, or projectedBalance. If balance is just as clear, though, use it.

    How DO people get their bank balances these days, anyway? I log in to my bank website and look it up, but I bet by now that’s old school. Probably you record a video of yourself dancing to a song about your bank balance and post it to TikTok, and a bot from your bank will text you with the value and a relevant movie clip as commentary.

    Just checking that bank balance (Photo by Amanda Vick on Unsplash)

    Rule three: it isn’t acompactToolUsedForDiggingInOrderToPlantInTheGarden.

    Okay, I think you’re getting the idea. Call that spade a spade, and you’re good to go.


    Have you ever had to deal with code that just made no sense? Did you get angry at whoever wrote that garbage, only to look it up and find that you wrote it, six months prior? I feel you. Worst programmer ever is Me From The Past.

    Think of it this way instead: you’re so much better of a programmer now than you were six months ago! Learning and growing, that’s how you’re rocking it. Go you!

    Originally posted 30 May 2022 on Medium.