I have been working with Copilot non-stop since being laid off from Microsoft, and having a lot of fun doing it. In fact: I have a fun idea and I could use your help. I'll leave that until the end.

The Problem

In my last post (newsletter) I talked about what I was working on at Microsoft right before I left, and why it was so exciting:

I was giving workshops to thousands of internal folks (mostly engineers) on how best to increase efficiency with AI which, in my case, meant Copilot. I had workshops lined up for months, and was receiving multiple inquiries every day! It was absolute madness, but worth it as I was helping thousands of folks and also getting some great feedback.

The key was this: focus on them and their work. Just a dash of Copilot, here and there, goes a very, very long way and it really can bring joy to your day.

I am well aware that people are experiencing ridiculous fatigue when it comes to Copilot. In fact, I asked this question at the end of the post:

... what are your top two or three concerns when it comes to working with AI and Code?

I received an avalanche of replies, which I can summarize with:

• It will take jobs away and devalue our work. Entire teams will be replaced by a few devs with AI tools.
• Programmers will forget how to program.
• Code quality will decline or be entirely untrustworthy.
• It takes too much time to vet the code.

I agree with some of these sentiments, but I also think that Copilot is a tool, like any other, that we will need to learn how to use. Moreover, we will need to show new programmers how to use it properly so the concerns above are minimized.

Either way - these are valid concerns, but what if you sidestepped the code generation part and let Copilot do other things that help you through your day? With a little customization and an open mind, you can add so much to your day with what I like to call Copilot's "Good Parts".

Let's take a look.

Massive Time Savers

Have you ever plodded through a codebase trying to figure out what's going on, or where a particular thing is happening? Copilot can do that for you without touching the code at all! It can also answer general coding questions quickly, write helpful shell scripts, and generate documentation for you based on Git commits.

None of these things actually generate code aside from the shell scripts, but those are utilities that aren't necessarily meant for production.

Here are a few others that I really like:

• Generate formatted Git commit messages which you customize with custom instructions.
• Fix CSS problems or, better yet, make something look less atrocious.
• Generate test data for a database using DDL or a JSON object as context.
• Create a database for you using nothing but a spec document.
• Create a database change script using two DDL files.
• Add open source documents for your project, including CoC, issue templates, LICENSE, SECURITY.md, and a CHANGELOG based on Git commits.

This is just the beginning! You can do so much more by fine-tuning Copilot and telling it exactly what you want to see.

Customizing and Templating

Many people don't quite understand what's possible with custom instructions. Yes, you can give it code styles or "nudges" as to how to do things, but you can also get very specific.

For instance, if you're a C# person, it's likely your company has a very specific way they want classes created. You can tell Copilot this (using .github/copilot-instructions.md in the root of your project):

Every class in the project should follow this convention:

```csharp
/// <summary>
/// Class <c>Thing</c> represents X business concern.
/// </summary>
public class Thing {

  //Sensible factory methods here. Use test logic to decide.
  
  public override ToString(){
    //use a sensible property selection here
  }

  public string ToJson(){
    //serialize this class
  }
}
```

I worked for a senior dev once who would become quite agitated if we didn't override ToString() on our classes. Call it a quirk, I guess.

The point is: Copilot is very good at following templates, which is extremely useful when dealing with boilerplate code!

Go Ahead, Explore!

This is probably my favorite "Good Thing" with Copilot: I get to play around and find out. I love exploring things, whether it's a new language or framework, or maybe an open source application I want to use. Unfortunately, this kind of thing takes time.

For instance: the good people at Tailwind Labs just created Compass, which is a Next.js template for hosting an online course:

I'm a Tailwind UI customer and something like this could be extremely useful for me. The only problem is that 1) I have very little time these days and 2) I don't know Next.js at all (I really should change that).

Without Copilot, exploring this template would be a quick "no-go". With Copilot, however... well see for yourself! In 45 minutes I was able to switch out the Compass video player to use Vimeo (where I host my stuff), and convert my course pages (written in Markdown with frontmatter for the course and lesson data) to the mdx and JS format the Next site needed. I also learned a bit about Next.js and React, which is always fun.

As I mentioned, I recorded all of it with some light editing to make it more watchable. I captured the time, too, so you would believe me:

Here's My Idea

There is so much hype and nonsense surrounding Copilot that I was thinking of putting together a set of videos, articles, and workshop outlines to help people get the most out of Copilot in the real world.

At first, I thought it would be fun to post some videos to my YouTube channel. Then I thought it might be good to create a new channel focused on Copilot alone. And then I thought "hmmm - what if I went all in and created a site that contained everything", including courses (free and paid) and workshops that you could sign your team up to.

Anyway: here's where you can help. It's another question and, like last time, you can reply to this email (if you're reading this as a newsletter) or ping me on social (links below). Would you be interested in watching me build a new business venture focused on Copilot, using Copilot itself?

If so, what topics would interest you most and/or least?

As an entrepreneur, I use AI for quite a few things and it's extremely helpful. The biggest, of course, is prototyping an idea and getting it out there. I also use it to think about marketing ideas, branding, and newsletter ideas. I never let it create the actual content for me - just outlining and providing some structure.

Thanks for reading!
Rob

I suppose if I have a single skill that I could say "this is what I'm good at", it would be telling a story. I don't know why I have this skill, I just do. I remember when I realized I had it, too: it was my first year in college as I stared down at an essay I wrote and saw a big red "A" circled on the front page. "See me" was written under it.

I did as instructed and walked slowly up to the professor after class. Back in those days, we turned our essays in on actual paper, and mine was rolled up in my right hand with a bit of sweat starting to dampen the pages.

Yes, sir? You wanted to see me?

I do Rob. I have to ask you about this paper. Is this your work, entirely?

Yes, of course. My mom is an English teacher and would never forgive me if she thought -

That's OK, I believe you. It's just... this image you've created here with this sentence... It's wonderful. I'm still thinking about it.

What my professor was talking about was a phrase that hit me as I as I was trying to explain my childhood predilection for playing with words, especially ones that sounded funny, like moist or pamphlet. To try and explain this, I said that I "liked to pound round words into square sentences". The idea of a "round" word had to do with the way it sounded in my brain, and a "square" sentence was a clunky one, so to spice things up I would... well you get it.

At the time, I honestly didn't think it was that profound; it was a one-off idea I had and just rolled with it. My professor loved it, and told me that I have a way with telling a story that he enjoyed, and that I shouldn't stop writing.

That's what a good teacher can do for you: help you see the skills inside that you never thought you had.

Taking the Time Makes the Difference

I need time to create a story, however. I'm not exactly skilled at improvisation and, indeed, it's gotten me in to trouble more than a few times. I like to toss the ideas and concepts in my mind, breaking them apart as I said above. No idea is ever fully-formed, and is usually a collection of other ideas repackaged. I like to rip off the packaging and see what makes the idea tick.

That was my job at Microsoft for the last 6 years. It was also my job before that, when I worked on my own, creating books like The Imposter's Handbook and A Curious Moon and video productions like Take Off With Elixir and SQL in Orbit.

That's only the first part of telling a story, however. The other part is you, sitting where you are right now, reading the words I'm putting together. Not the pluralized "you", meaning everyone out there reading this. No, and hopefully this doesn't sound creepy, but I'm thinking of the singular you and how these words are settling into your eyes (if you've made it this far).

Thinking about the audience was what made working on This Developer's Life such a cursedly wonderful side project. I would explore, play, try something new, rerecord... because I knew you might be listening.

Take the idea of fonts, for example. Most people (you included) probably don't think too much about them. Maybe you know one or two, and almost assuredly have one or two you hate (Arial, Comic Sans, etc).

So how do I spin the notion of fonts into a story? Good question, and here's the answer:

2.0.5 Typo

Who cares about typefaces and why should you? Well, these guys do and you should start caring. Rob and Scott explore the world of reading online with one of the godfathers in the world of typeface and fonts.

This Developer's Life

I'd write more about that episode (and fonts too), but I have to get back to this post. It's starting to wander some.

Omit Needless Words

I'm a fan of Stephen King, and this is going to sound weird, but not because of his books, though I like many of them. I love his ability to weave a narrative and keep people guessing. That's really his trick: always keep people guessing.

I've read his book On Writing perhaps 7 times over now, and I always hear something different. That's a good writer right there: he's kept me guessing to the point where I need to read the book repeatedly to see what else I've missed.

King echoes William Faulkner's famous line (though no one can be sure who really said it first) in On Writing that I just love:

Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings.

It's the literary version of laying off a large percentage of your workforce, I suppose.

Another bit of advice that King echoes is from Strunk and White's The Elements of Style:

Omit needless words

I suppose I could apply that to this post, but I would rather apply it to my resume, if I'm honest.

If I trimmed my resume as much as possible, killed every darling in there, and omitted every needless word, I would be left with this:

I tell stories people like

I can do other things too, of course, but what I love to do is just this: think about you, the reader or viewer, and tell you a story about what I'm working on.

If you can use this sort of thing, here's my resume. I would love to work with you, to tell the story of your company and why it does what it does. Maybe you founded it, or perhaps you lead a small project within. No matter what: there's a story there to be told and I would love to help you tell it. That, and I need a job.

Change can be extremely hard, especially when it's the destructive kind. I'll be OK. In fact I'll be more than OK, I'll be working with you. I hope.

With love and appreciation,
Rob

Full disclosure: I work at Microsoft but what you're about to read is 100% my personal opinion. Don't @ me with "dude from Microsoft claims..." please...

I've been deep in a rewrite of the AI chapter in The Imposter's Roadmap, and I'm trying to discuss the role of AI in a senior programmer's life... and I noticed something interesting as the AI discussions heat up in our industry: we both fear and want to protect junior developers.

What a weird straw man argument!

Note: this article addresses the presence of AI and might not be suitable for some readers.

The Catalyst

Microsoft and GitHub announced a free tier for Copilot a few weeks ago which has a few limits on it (2000 completion requests, 50 text sessions). The idea is that people get to try Copilot and see what they think.

This, of course, was met with "challenging" responses from people. Read the entire HN article linked, if you like, but it's a very typical HN discussion (i.e. inflammatory and not very productive). But it did make me think about one thing in particular: the simultaneous fear and guarding of junior developers.

To summarize the responses I've seen: AI is making people dumber and my job harder because I have to deal with their dumb code! Who's going to help these dumb junior programmers!

I've read over Reddit threads, BlueSky discussions, and had plenty of animated discussions with friends and colleagues, and every one of them is worried about the Big Bad/Sweet Innocent Junior Developer.

We Love Them, We Fear Them

I used to use Visual Studio back in the mid-2000s when I was writing C# on a daily basis. One of the "must-have" tools at the time was Resharper, which would help with navigation, refactoring, code exploration and a whole lot more.

For some reason it never clicked with me, but I do remember when it came out that the .NET community was up in arms over the need for a "crutch". Senior developers would forbid the junior developers from using it because it would slow their "growth" and they needed to know the underlying code and why it was good or bad. Others argued that the tool itself can help with this process.

What a weird paradox.

On one hand: yes, taking time in code reviews to help a new programmer improve their code takes time and yes, I can see how that would be insanely frustrating if it was obvious that the code came from an automated process.

On the other hand: what a great way to learn. I mean... if the code works, it works! Let's see how to improve it now, and why that's important. You get to that point either way, but I might suggest you get their faster with the automated version.

Reducing the Google - StackOverflow - Copy-Paste Cycle

I wrote about this in a previous note, but the best code you can expect from an LLM is the most predictable code. Sometimes this is good enough, sometimes it isn't. That part is up to you and your code review.

That code review should consider:

• Provenance. Is there a copyright issue?
• Readability. How well can people understand what's going on? (You can, by the way, usually ask your LLM to make the answer more readable or follow a given style).
• Performance. How well will this scale? (Big O stuff).

Here's the reality: your junior developer is going to Google whatever problem they are facing, probably end up on StackOverflow, and then copy/pasting the answer.

As a senior dev, you know this already. The only thing that's worse than these two cases is when they try on their own to figure it out and continually get it wrong, wasting everyone's time. This might be the best choice in terms of personal growth, but you've got an app to ship!

Let's try an experiment.

SQLite Transactions in Node.js

Let's ask a simple question:

How can I do a transaction in SQLite using Node.js?

The OG method to answer this question is to RTFM. Start your timer...

(10 minutes later) I give up. I know the answer is likely out there, but I checked the docs for SQLite3 and also read up on the driver. There is one mention of the word "transaction" so I know it's possible, but I have the rest of this email to write so... giving up.

Google It

I worked for 5 years as a programmer before Google came along and I don't know how I did it. It took just one search using the prompt above, and here's the answer which was, of course, StackOverflow:

This wasn't the first hit, however, which was 8 years old and I had to read through it before I realized it was out of date and didn't directly answer the question. With the code above, running serialize is the key... but if there are multiple connections to SQLite and a write comes in to the same record, apparently it causes problems.

More reading is in order, I suppose. Either way: total time spent was about 5 minutes.

Copilot

I asked Copilot the same question using the 4o model:

That took 20 seconds to type and get a response back. The code looks basically the same, and this is what I tell people all the time with respect to Copilot:

It's simply shortening the Google/StackOverflow/Copy-Past cycle.

That is truly my opinion. I know others feel differently.

Reviewing The Code

Let's put our senior hats back on, shall we? When asking about the code used, we learn that the first example above was lifted from StackOverflow and then modified for clarity by our programmer.

I think we're all used to the drill by now: 

Rewrite this routine and feel free to use the SO code as inspiration. Clean up the variable names to be in our style. I don't like seeing hand-written SQL, but this works for now. I might ask you to change or use a library in the future. 
​Good for you for recognizing parameterization so we don't have an injection attack. I don't like the way the connection is handled here, however, so make sure it persists so we don't screw up the transaction.
​
Also, make it more generalized please...

For the second example, we would have the same concerns RE copyright and SQL injection. We ask for the same changes as above but, this time, our junior person is back within 10 minutes:

Our junior wrote good notes during our review and pasted them directly into Copilot as a follow up prompt...

Is This A "Good" Thing?

My goal with this post is not to come off as a "pitch man" for Copilot, I promise. I like discussions like this one because my opinions are still forming, and hearing other people's ideas are key. 

Anyway: let's get right to it - if you're facing a shipping deadline, faster code is better. If you're worried about the growth of your junior developer, that's a concern here as well.

They didn't write this code, they prompted it. It's like people who call themselves brewers using computerized, all-in-one machines to handle temperature and timing! All you did was push a button!

For me, personally, I'll always take the win on this, which is shipping. In addition, and I think this is critical, is to step through the code with the junior person and:

• Ask if they understand it and how they tested it. Automated tests are OK, but they need to tell a story and the junior dev better be able to discuss that story.
• Discuss copyright exposure.

That last one is a BIG discussion, and how you and your company choose to address it is up to you. I need to sidestep going into detail on this, which I hope you understand, but I did want to recognize the need for the discussion.

So: what do you think? Does shipping something on schedule outweigh the other concerns over AI? I read every reply - so hit me up!

One of the hardest things to learn when it comes to skating is the "hockey turn", which looks something like this:

This is hard. Very hard. If you master it, you can change direction and lose very little speed. When you're learning to skate, however, it's almost impossible to get your body to do this.

That's when my coach told me something that has stayed with me:

Turn your head, your skates will follow

He was right. This also works with surfing, skiing, and snowboarding among other sports. Just turn your head and your body will do the rest for you.

But how? How did my body know which way to shift my weight and balance if I had never done a thing like this before? It didn't make any sense, but oddly, it worked. I just needed to 1) look where I wanted to go and 2) trust my body to do the rest for me.

What kind of weird voodoo is this!

Turn your imagination and your confidence will follow 

I was thinking about hockey turns when listening to A Confident Mind this last week (link). The author, Nate Zinsser, believes that confidence in sports, business, or your personal life is a trained skill - not something you're born with.

What you're training is the same thing I was training when learning how to turn on skates: 1) imagine yourself doing the thing you need to do and 2) trust your subconscious to do the rest.

Honestly? This feels a bit too new-age for me. Affirmations and The Secret (where you just believe in yourself and divine purpose) were just a bit too precious, even for the 1980s and 90s, when they were popular. Isn't this just a repackaging of that whole idea?

Maybe. But as the author of our next book states:

You don't have to believe me. Try it for 30 days on your own and see if it works for you. I think you'll be surprised.

You and Your Machine

The book I'm referring to with the quote above has the unfortunate title Psycho Cybernetics. It was written in the 1960s and I think the author, Dr. Maxwell Maltz, was trying to be edgy. 

The title refers to a "helmsman", which is what "cybernetic" loosely refers to in Greek. The idea is that we have a machine inside of us, a "goal-oriented mechanism", as Maltz calls it, that we can steer in a direction of our choosing. He doesn't suggest we can control it - only that we can give it a goal and let it do it's thing.

Like turning your head on a pair of mental hockey skates.

The premise of both of these books is that, through visualization, we can convince our subconscious (our inner machine) that we're not only capable of executing at a high level, but that we've actually done it already, so the next time should be easy.

Both books have you visualize yourself in extreme detail, doing the thing you're not sure you can do. If you're speaking to an audience, you see the clicker in your hand and feel its weight. You listen to yourself effortlessly speaking at a casual pace as the slides click perfectly behind you. You pick out one or two faces in the crowd and watch them laugh at your asides, or look wide-eyed in astonishment at your big reveal.

In the end, you watch people clap for you and come up to shake your hand, telling you it was the highlight of their week.

This is where we run into an old friend: Imposter Syndrome. Do I really think I know enough to impact someone's entire week? Isn't it extremely arrogant of me to think I deserve claps and handshakes?

Damn I hate this feeling.

Sabotaging Yourself

You know the drill: you work hard, achieve something, and instead of owning it, you think, I just got lucky or they’re going to find out I don’t know what I’m doing. That’s my default setting most of the time, especially when I’m taking on something new. In other words: I don't filter my self-perceptions very well.

This is self-sabotage, plain and simple, and serves nothing but your own ego.

I wrote about getting over Imposter Syndrome as a programmer in both The Imposter's Handbook and The Imposter's Roadmap, and the idea is straightforward:

• Recognize these negative thoughts are toxic to you and your team.
• Refocus and reframe. Spend time being grateful you can support yourself doing something you love.
• Get curious. What don't you know? Write it down, dig in, and learn something new.
• Small steps, big changes. Take small actions to build your confidence, and ask lots of questions.
• Write it all down in a journal. This helps internalize your process.
• Share what you've learned. Nothing feels better than helping someone else.

The most important part of this process is recognizing your toxicity, and taking action to refocus your thoughts. It might be hard to think that Imposter Syndrome is toxic, but it truly is. You drain the energy from others, who feel the need to make you feel better about yourself, and you drain the energy from the team. Most of all: you drain yourself of purpose, looking externally for proof that you belong where you are.

As Zinsser suggests, however: confidence isn’t about proving anything. It’s about reminding yourself of what’s actually true—your preparation, your effort, the work you’ve already put in. The truth of your current situation is that you were hired to do the work, so people do believe in you. You just won't accept this.

Imposter syndrome isn’t lying about the facts; it’s just amplifying all the wrong ones. This works both ways, it turns out.

The Dunning-Kruger Spiral

I'm sure you've heard of the Dunning-Kruger effect, which is when people think they’re better at something than they truly are because they don’t know enough to realize how bad they are. Ever see someone talk like an expert after watching one YouTube video? That’s Dunning-Kruger.

What’s wild, though, is that the more you learn, the more you realize how much you don’t know. And that can tank your confidence if you let it. 

Zinsser reframes this: confidence isn’t about knowing everything. It’s about trusting that you can figure things out, that you can grow into the gaps. The whole "I’m aware of my shortcomings" thing will feel less like a reason to doubt yourself and more like proof that you're on the right track.

The Connection

Here’s where it all clicked for me: both imposter syndrome and the Dunning-Kruger effect mess with your perception of reality. Imposter syndrome keeps you stuck in the past, replaying every little mistake. Dunning-Kruger blinds you to what you don’t know, which means you can’t grow. 

Confidence, though—the kind Zinsser talks about—is all about the present. It’s about choosing to believe that what you’ve done matters and what you can do will get you through the next challenge.

But what about your failures? We will fail in our endeavors - do we just ignore these?

Absolutely not! Zinsser talks about this with the "next play" mindset. When you screw up, which you will, what's your next move? You can't dwell on what you did wrong, thinking about all the ways in which you suck. What you can do is to learn from that failure, and make sure you don't do it again with your next plan. 

Don't dwell on the past, don't believe too strongly in your bright and amazing future. Learn for the here and now and let the future unfold as it will.

What Do We Do With This?

Maybe imposter syndrome isn’t something we’re supposed to beat. It’s a signal—a way of saying, "Hey, here’s where you can grow." 

If you feel affronted by someone's condescension or you don't prepare for a conference talk because "I'm good at improv and I know this subject cold" - maybe check yourself.

People with Dunning-Kruger don't know what they don't know, which I think is a great default. 

Confidence isn’t about feeling 100% sure all the time. It’s about choosing to act even when you’re not sure.

Confidence is the stuff that turns thoughts into action.

I love it. 

You can't wait for some magical moment when you "feel" confident. You simply decide to keep going, keep learning, and keep showing up. 

Keep. Showing. Up.

Here's the latest video I did for the VS Code team. It's on Remote Development with VS Code, which is wild stuff! Many call it the "killer feature", but that brings up an interesting problem: how do you make a video about an 'interesting feature'?

We discussed this internally (I work at Microsoft supporting VS Code). My initial thought was that I would show how you could set up and configure Ghost (the blogging platform) on a remote machine. I did a few takes on that idea but it turned out to be a video about Ghost, not VS Code Remote Development.

That wouldn't do. We needed something a bit more direct and engaging.

The Tension Script

This video was for YouTube, and there is a particular structure that many YouTubers favor, and it goes something like this:

• Mercilessly grab your audience's attention.
• Add bait for them to stick around until the end.
• Build out your story in three acts, building and releasing tension with each act.
• Wind up with a Big Reveal at the end.
• Call to action to one of your other videos.

If I used this script for the VS Code Remote video, I might do something like this:

Opening scene with a montage of Rob yelling at Vim, not being able to quit or maybe wandering around completely lost in a terminal session on the server. 

Rob starts a remote connection with VS Code, muttering "thank god..." and then winking at the camera: "stick around to the end and I'll share 5 tips that will save you hours when getting started. Don't forget to like a subscribe". 🤮

Yeah, I know. But if you want eyeballs and watch hours, you gotta play the game. Which is more about you as the presenter, less about your audience. Ew.

Tutorials vs. Stories

With my original VS Code Remote script, I was trying to create a story that viewers could relate to. This can work, but it's really tough to tell a story and create a tutorial at the same time. 

​I took this to a whole new level with A Curious Moon. I really enjoyed writing it, but I kept wondering if I was doing it more for me, or for my reader. This is where things get interesting.

Tutorials have a "standard" structure:

• Introduce the topic and yourself.
• Tell people what they're going to learn.
• Present a problem your audience might face.
• Present the solution, which is the thing your tutorial is about.
• Summarize the problem and solution for retention.
• Offer additional resources.
• Say goodbye and thank you.

I think this is a logical structure and it makes sense to the presenter. The problem is that tutorials that are structured like this are boring and bored viewers don't retain things.

Stories, on the other hand, can be told with a variety of techniques, including Campbell's "The Hero's Journey", which is every action or adventure movie you've ever seen.

Star Wars, Lord of the Rings, The Barbie Movie...

• Call to adventure
• "No going back" point
• Meet the wizard in the forest, the teacher in the cave, etc.
• Come close to death.
• Defeat the dragon, just barely.
• Return the hero.

Working this into a tutorial video would be tricky, but probably fun:

Opening scene: Rob is eating a sandwich on his lunch break and gets an email from his boss, Burke Holland. Burke tells him the group needs a new blog, ASAP, and it has to be ready in two hours.

Rob drops his sandwich and uses his last Azure credit to create a Linux VM. He doesn't know what platform to go with, but just then he sees a tweet from John O'Nolan, the cofounder of Ghost. He asks John for some help, and they get on a Zoom call together. They use VS Code's Remote feature to run the install scripts, update settings, and tweak the theme. Things are going well until...

John has to leave so Rob continues the installation but soon notices that things are starting to slow down to unusable levels. He realizes at the last second that he picked the wrong SKU! Everything he's done has been for nothing! 

"Use the elastic scaler, Rob..." It's the familiar voice of Scott Hanselman, who has somehow appeared from nowhere. He hands Rob a magical slider bar which scales the server up a SKU or two, and then restarts it just in time...

I admit, it would be fun to make this video but, again, I think it would be more about me and less about you.

In Medias Res

That's a Latin term that means "in the middle of things" or, if you're a writer, "starting in the middle". It's effective because it adds a layer of mystery to your story.

You're probably familiar with this plot device with title's like The Bourne Ultimatum, Forrest Gump, The Fugitive, or any detective story. You come in at the peak of tension and have to figure out how you got there, discovering more about the main character and what's happening as time goes on.

Here is an outstanding video I found on YouTube, where the author restructures Passengers(Chris Pratt, Jennifer Lawrence) to start in the middle. It's told from Jennifer's point of view instead of Chris's, and turns into a tension-filled horror story! I think it's fantasic.

It would be fun to do this in a tutorial video. The opening scene could be Slack going off with downtime alarms:

Rob stumbles into his home office at 3am and everything is down. The server appears to be up but no services are running. Is it a disk space issue? DNS? Did we get hacked?

Rob opens up VS Code to see if he can get the site running locally using port forwarding. Nope, nothing. He starts the debugger to see where the error is and notices that his cache server isn't responding...

This would be entertaining, but would you actually learn something? Interesting dilemma.

Top Down

This is a standard way to structure a course or tutorial and is what I use most often. You start in a general way, then drill down into each topic.

In today's video you're going to learn about Remote Development with VS Code. This is incredibly useful if you can't work on your local machine, or if you prefer a more visual way to work on your server. You can run external code as if it were local, and you can even debug! Let's see how.

Tell people what they're going to get, then give it to them. 

This is how universities might structure a Computer Science degree program. For instance:

• First year would mostly be math and general education classes with Introduction to Computer Science and Programming.
• In the second year you might get into data structures and algorithms, more math, computation and logic. 
• Third year you might get into complexity theory, software engineering, networking and possibly an ethics class
• The final year is the project year with advanced elective classes including Cybersecurity, Cryptography, AI/ML, Robotics, Compiler Design, Language Design, and advanced theory classes.

I have a degree in Geology. At first, the classes I took seemed random and disconnected but as the years passed by, everything started to mesh and I got excited.

I remember taking a Structural Geology class (mountains, faults, big stuff) and Advanced Mineralogy and having one of those "epiphany moments", where you could see how the chemistry and molecular structure of a dominant mineral could change the way a mountain was shaped. Melting limestone peaks and rounded granite domes look the way they do because of how they're made.

It's that moment, that connecting of the dots, that remains with you forever and fires you up!

Missing CS Degree Outline Ideas

I mentioned in the last email that I was considering creating a course called The Missing CS Degree and an overwhelming amount of you thought it was a darn fine idea.

But how do I structure such a thing? I have a few thoughts, but I decided to go with a typical curriculum structure (top down) but I'm not all that sure how it translates to an online course.

I really could use your help. So far, I have these modules:

• The Big Picture: History and Evolution of Computer Science. Ancient computers, Babbage, Lovelace, Turing, Hopper, Shannon, etc.
• Fundamentals of Logic and Problem Solving. Boolean and binary, Information Theory, Set Theory and SQL.
• Algorithms and Computational Thinking. Intro to data structures and algorithms. Recursion, etc.
• Theoretical Computer Science and Cryptography. State machines, Turing Completeness, Symmetric/Asymmetric encryption, P vs. NP with Prime Factorization and other NP Hard problems.
• Data Structures and Secure Data Storage. Trees, Graphs, Hashes, Tries, Trigrams and Bigrams. Hash Functions, graph traversal.
• Programming Paradigms. Asynchronous, functional, object-oriented, imperative, concurrency vs. parallel.
• Networking and Web Systems. TCP/IP, HTTP and DNS basics. Practical networking tools.
• Ethics in Programming. Discuss real world case studies. Quantum computing, AI and ML.

I'll admit: this seems ambitious so please don't hold me to it! I want to start general and move into more specific things as we go along. There is a ton of overlap, especially with data structures and algorithms.

What do you think? Add more? Maybe take a few things out? I'm iffy on the Networking module but it's so useful to know. I had an Operating Systems and Compilers module in there but how often do we need to know that?

Thanks for wandering through story time with me! Grateful for each of you...

Rob

I was talking with a coworker the other day about one of the new AI offerings and how well it simulated human interaction. I was asking it to summarize some notes I had taken on a book, and it did a fantastic job - but I then mentioned something I truly believe:

AI is mediocre, at best

It has to be, by definition. It's just repeating back to us the most common and probable things that we have said to it. Or, as Scott Hanselman describes it: "AI is a sock puppet on your own hand":

Understanding Probability and Information Theory

​Claude Shannon is one of the towering figures of Computer Science and mathematics that no one has heard of. He created the digital circuit by synthesizing George Boole's work with true and false (Boolean Algebra) with the base two numbering system (aka "binary"). That was for his Master's Thesis back in the 1930s.

Later in his life, he single-handedly started the Information Age by publishing his theorems on how you could "quantify" information. His breakthroughs led to compression algorithms, the notion of "entropy" in cryptography, and error correction.

He also laid the foundation for predictive analysis, which is key when it comes to error correction.

Surprise!

Back in the 1930s and 40s, people wanted to know just how much pure information they could send from point to point. This used to be done by telegraph, person-to-person, or actual letters in the mail. Wars, however, were becoming larger and more complicated, so the need to send more information in a shorter period of time was crucial.

Shannon realized that people communicate in extremely "redundant" ways, filling sentences with "noise" that don't communicate anything aside from non-useful pleasantries. 

To him, the true measure of a sentence was its "surprise" - the unexpected thing that, quite literally, would surprise you, and that you would learn from.

Consider a text from my mom, checking in on me:

Hi Rob, hope you're having a nice day. I wanted to know if you could send me the link to the article you and I talked about the other day. Call me if you can. Love, mom

Note: yes, she really does sign off that way.

This sentence is full of redundancy that, to an Information Theorist (or a network admin trying to reduce load on his pipes), could be made much more efficient, thus increasing it's "surprise":

ChatGPT 🔗🤦🏼‍♀️

In my mom's first message, each sentence has a degree of predictability and form. In other words: it's not all that surprising. The only thing I learn is that she forgot the link for the ChatGPT article we talked about.

The second message makes this bleedingly clear.

Shannon realized two things from this: surprise is useful for compressing information, but redundancy is good for predicting what will be said.

The Surprise of ChatGPT Responses

This brings us to the mediocrity part, and I do realize that it was a bit of a wander, but hey, it's Saturday and it's fun to learn CS stuff, isn't it?

When an LLM does its thing and chunks massive amounts of data, it's following a path laid down by Claude Shannon almost a century ago. Each bit of information is related to a previous bit based on the structure of the language being used - which is English, in most cases. Sometimes it's code, I suppose, but either way there has to be some underlying structure or nothing will work.

If I type the letter "q", what letter will follow? In almost every case, it will be a "u" because that's the way English works. If I type the phrase "The Little" into Google's search box, the predictive bits in the background will do their thing for me:

Google is able to do this by leveraging a more advanced form of a graph data structure called a "Digital Tree", also called a "Trie":

This is, of course, is an extremely simplified doodle by yours truly - but the idea is the same: each letter you type decreases the possible result set, which increases the likelihood of an answer. 

If I typed in "HA" and used this trie to predict what was next, my choices would be "half", "hang", "hand", "handball", and "handbook". If I added an "n", we get closer to the thing you're looking for, assuming we're working with word structures.

But here's the real question: how was this trie created? Randomly from a dictionary, or from an encyclopedia? Maybe it's a collection of every tweet ever written, which would be horrifying!

The transformers and algorithmic voodoo that LLMs use to predict an answer for a question work in much the same way: using probability, based on the underlying model, to hand you the most likely answer. 

The most likely thing tends to be the most common thing, which can be good or bad depending what you need.

If you have a "frozen pizza" type of problem, then a Walmart answer will probably work just fine for you. If, however, you're trying to figure out your latte art with your new Rocket Espresso Cinquantotto Mignon, a Starbucks answer might be problematic.

This is what I think about, every time I use AI to help with a coding problem: this suggested answer is the most mediocre solution possible, given the source.

The Missing CS Degree

As you can tell, I love spending my weekends learning new things and writing about them if I find them interesting. That's how The Imposter's Handbook (and the more recent The Imposter's Roadmap) was born!

Which got me thinking...

I wrote the first book over 8 years ago, and while I think it's still very relevant... I think there's a lot more I could do with the subject. Which led me to an idea...

Do you think a course with a title like "The Missing CS Degree" would be worthwhile? I've been thinking about this since my last post a few weeks ago - and no I wouldn't charge a ton of money for it! But I was thinking 6-8 hours of in-depth Computer Science and how it applies to what we do today.

If this is interesting to you, let me know! I'm sketching out a few ideas for an outline.

Happy Saturday, thanks for reading!

Rob

In my last note I mentioned that I put my precious Bullet Journal on the shelf (which really does make me sad) and switched to Obsidian as my full time journal. I wrote about this process in The Imposter's Roadmap as well.

I did this for these reasons:

• I like to review what I've done for a given month, and often need to find a specific reference. That's difficult with a paper-based book.
• I like saving code snippets.
• I like using tags so I can roll up my notes and entries based on who or what.
• Searching is a massive time saver!
• I love adding photos and screenshots. This is especially useful with Obsidian's canvas feature.

I tried it for a month to see if it would make a difference and yes, without a doubt, it has changed everything for me. 

As Requested: A Video

There is so much to explain as to the how and why, so I made a video for y'all which you can watch right here.

Hope this is helpful! Bullet Journaling is a wonderful process that keeps you focused on what matters and allows you to forget what doesn't. Something that can help all of us.

Talk to you soon!

Rob

You would think that after years of development, the act of shipping something would be nothing but joy and relief. In the moment, however, "pushing send" is terrifying and feels like running naked into traffic.

That's what I'm feeling right now because today is the day! After two years of planning, research, writing, and editing - it’s ready to go: The Imposter’s Roadmap, essential practices, tools, and skills for self-taught programmers. If you click that link, I've thrown in a 20% discount as a thank you for reading my emails.

The book is all about polishing your professional game, and includes:

• How to use GitHub like a pro (as opposed to a simple push with a PR).
• Different styles of testing and when to use them, including TDD, BDD, System, Integration, and Exploratory.
• How to create a developer’s journal because keeping receipts is critical.
• How to work with other people when you’re not good at social interactions.
• How to use GitHub to manage big projects, including discussions, setting up a build, running code reviews, and how to do a PR without making people cranky.
• Using containers, from simple docker run to Kubernetes.
• Monitoring, logging, and disaster recovery.
• Architectural approaches for OO people.

I tried to think of everything that I would want to know if I was moving up in my career, hoping to land in a lead position within the next year or so. You can learn the technical things, that’s for sure, but there’s a lot more to this game than understanding how to use Git.

To that end, I discuss soft skills throughout the book, and what it means to gain responsibility and influence without losing your soul. We also discuss how to spot a sociopath (there are so many of them) and what you can do to avoid people problems.

Want to see something else? I'm happy to add it! Just let me know (hit reply) or fill out an issue on GitHub (link in book).

Why I wrote this

Back in 2004 I bought Mike Gunderloy’s classic, Coder to Developer. I remember reading it in 7 hours as I flew to Hawaii, and it is, to this day, the fastest flight I’ve ever been on.

I devoured this book - I wanted to know what “the real pros” did so I could have a reasonable conversation with them and not look and feel like an imposter. Fast-forward to 2024, and things have changed, drastically.

As a lead, you need to understand so many different systems and how they all work together. It’s easy to feel left behind, which was me 8 years ago as docker started taking over and this thing called Kubernetes was what the “pro” developers were using.

I wrote this book for me. Instead of cobbling together some notes, I decided to go deeper and document everything with the goal of sharing with others.

It's a living thing

The book is up for presale but I would say it's about 95% "ready". I might add or expand some chapters based on feedback, but no matter what, you'll have access to every version from now until forever.

If you're an annual subscriber, you can download the book straight away. It's right in your dashboard under "Subscription Downloads" (along with the other books I've made).

If you would rather wait until the book is final, that should be in about a month and I'll send out another note at that time.

Hope you enjoy the book!

Rob

Most people aren't aware of the power of constraints in a database. They're there to enforce data rules, and you're probably familiar with a few of them, including:

• The null constraint, which won't allow null values.
• The unique constraint, which ensures a record is always unique.
• The primary key constraint, which I don't need to explain.

Assuming you've used these before, let me ask you a question: is this business logic? I think it's fair to say that some logic is being used here in the form of a very basic conditional statement: if null then no. Some people hate this idea.

What about foreign key constraints? Articles like this one claim you shouldn't, claiming that "rules change, deployment becomes harder, unit testing, and application reuse". 

I clearly have an opinion on this one, which is simple and direct: if your database can protect your data, do it. That's what constraints are there for, and protecting your data is far more important than reusing your application later on.

Let's test this notion.

A Real World Scenario: The Program Schedule

Back in 2021, I was tasked with creating a scheduler for Microsoft's LearnTV. It had to work like a guide on a regular television, which you can visualize as this:

Here are the requirements I had to meet:

• The start and end time needed to be at the top or bottom of the hour (like 14:00 or 14:30).
• The duration had to be in 30 minute blocks, up to 2 hours (30, 60, 90, or 120).
• There can be no overlap between programs.

How would you implement this in a domain model? The start and end seem simple enough, as does the duration calculation. Checking for overlap, however, gets a bit tricky.

Or you could write up a few constraints. Here, I'm using Postgres:

If you're not used to SQL, this is going to be jarring. I suppose the same goes for learning any programming language or platform - it takes a little time, then you have a whole new toolset at the ready.

With 13 lines of code, we have defined our table and knocked out every single requirement above, including one more, which is to ensure that the start happens before the end.

Every program has a start and an end, so it makes sense to have a range as the data type (which is what tstzrange is - timestamp with a timezone range). You get at the range values using lowerand upper, which define the boundaries of the range.

I can define a constraint using the check keyword, and then pass in a boolean expression that can be any valid SQL expression.

The duration is a computed column using generate, which I'm then popping a constraint onto so that we can check the 30 minute block thing. We would need duration anyway in our code, so having it here, calculated by Postgres, makes good sense.

I had never used an exclusion constraint before I did this project and, if I'm honest, that syntax is a bit weird and is something you just have to memorize. That one line is what keeps things from overlapping, using the && operator.

Is This a Better Solution?

If you don't know SQL, I don't blame you if you look at this and wonder if I've lost my mind. That doesn't make it wrong. There are 13 lines of code here and it would take 30 minutes to Google and figure out what it does, and the reward for learning it is tremendous in my opinion.

Having data rules as close to the data makes sense. You can get around rules defined in code easily by writing a SQL query when you're in a hurry (like trying to fix a bug or running some report). 

Can you unit test this? Of course. I know that many programmers will utterly refuse to test their code if it requires a database, and I understand that. It can slow things down, and also cause failure for ... reasons.

Rails freed me from this mindset, and I don't mind involving a test database. But that's me. It works for what I do, and it feels good to let go and do what feels right.

Will this logic change? Maybe. Perhaps we'll allow programs to be 15 minutes long in the future. This means we need to change code somewhere, either in our project, or in our database in the form of drop constraint on the slot, making the change, then alter table add constraint with the update. 

Of course, you would want to check both.

Here's the thing, however: when you rewrite that application, you won't need to rewrite this logic. In my experience, rewrites happen far more than database changes, at least for me. 

It'a All About The Guarantee

In the end, what matters most to me is when my boss pings me and asks "are you sure about these numbers?" Reports are going to be based on these numbers (who viewed what, for how long, etc.) and whatever data is in the programs table needs to be as correct as possible.

As you think about your reply to this question, you might wonder whether your tests captured every case. You also might wonder if some other bit of code might have altered your data without you knowing it (observers, triggers, hooks, weird ORM relationships).

For me, having constraints like this are guarantees. Data cannot exist in the table without complying, full stop. When you're asked about numbers being right, you should feel comfortable replying "yes, they are".

It's all about the data, just be sure you're right.

Learning More

I made a video about this exact thing just over a year ago, and you can watch it up on YouTube.

I also created a full course on Postgres and working with data, which I just put on sale for $20. This is a fun one, as we work with real data from the Cassini mission, and its exploration of Enceladus.

Happy querying!

Rob

It doesn’t matter if you work for yourself, at a startup, or in a massive enterprise environment: knowing what you’re going to do when it’s over is incredibly important to your career. I work at Microsoft currently and before I started there in 2018 I pondered my “end game” – where do I want to be when it’s over and what do I hope to gain?

Let’s dig in to this.

BIG TECH/BIG ENTERPRISE

For a lot of people in a big tech company, the goal is to accumulate enough stock so you can live comfortably on top of your retirement savings plan. If the company is private then you take a bit of a risk here as the only way your stock is worth anything is if you can sell it.

Working for a publicly-traded FAANG(M) (Facebook, Apple, Adobe, Netflix, Google and Microsoft) is a sound plan. If you work at a company like Google or Microsoft for decades you will accumulate a giant chunk of stock that will stay relatively stable. Many of my friends have portfolios in the millions but that, of course, depends a lot on the performance of the company stock in the market.

How do you exit this kind of job? For many people it means retirement – often at an age much younger than “retirement age” used to be.

Let’s say you’re this person and at some point in the future you’ve been at Google for 25 years. You’ve received promotions and a yearly stock grant, and you’ve managed your investments well, retiring with X million dollars and a retirement plan worth Z.

In this scenario, what are X and Z? Moreover, what do you plan to do in your mid 50s? It might seem like a simple answer and who knows, maybe it is! Traveling is fun, but so is building something useful to the world and having a sense of meaning. You’ve likely thought these things through – but it might be worth discussing them with people who are facing retirement themselves, or who have just been through it.

Both of my brothers are at this point in their careers. My oldest brother is a retired college professor who is trying to figure out what he’s going to do now that he doesn’t have to create lesson plans. I asked him directly, and he didn’t have an answer and instead shrugged in an “I’m sure I’ll find something” kind of way, but it’s not hard to see that he feels a sense of loss.

My other brother drives a bulldozer and hauls dirt. He keeps saying he’s going to stop and “this is my last year, for sure“… but he hasn’t. He enjoys what he does and keeps taking jobs. Working for yourself has that effect!

SOLO CONTRACTING/HIRED GUN

I’ve worked on my own for many, many years prior to working at Microsoft and I like the freedom of it – but I dislike the stress, especially when a contract is over and you don’t have another one lined up.

After a few years things tend to smooth out and, hopefully, you’re making more money than you need and you can save but let’s face it: you’ll be hard-pressed to make as much as a big tech company can offer in the form of stock + salary, unless you’re very, very good. And maybe you are!

Either way: is this something you plan to do until you can’t do it any more, or just don’t want to? Work is harder to come by as you get older in this industry – it’s simply a painful truth. I used to get calls from recruiters constantly; this year I’ve had 2.

If you’re very good and very niche, the contract world can be extremely lucrative, but someday you’ll complete your last contract and send your last invoice. What does that day look like to you, and what’s next? THE STARTUP GRIND

I have created 3 companies so far. The first was a consulting company I founded with a friend in 1998. We did very well for a few years and went out of business in 2002 due to the whole dotcom implosion thing.

The second one, Tekpub.com, was sold to Pluralsight in 2013. I’m still running the third one in my spare time – which is where you’re reading this post.

This is, perhaps, the hardest thing to consider when starting a company of your own: how will I leave this? More importantly: how do I want to leave this?

I know that I will either leave or dissolve my company at some point and I’ve made the decision it will be when I’m no longer here. I don’t plan to retire! I want to keep writing books, articles and making videos until I absolutely can’t do it anymore which means I’m probably in the ground.

With Tekpub, my cofounder James Avery and I had this conversation in the very first week. We didn’t think Tekpub would ever go public, nor did we want it to. We didn’t want to deal with venture capital nor running a massive company. We felt that doing so would dilute the quality of our content and I still feel this way!

We knew that acquisition was a very likely outcome so we laid out some numbers we would entertain, how we would get to that point and also when. It basically worked out the way we thought it would but I’ll be honest: selling my business was traumatic.

James and I built Tekpub from nothing and were doing very well for the most part. When I sold it I immediately missed it and wanted to start it all over again, which I kind of have with Big Machine.

For me acquisition was a nice windfall with short-term excitement, but I love what I do and I stopped being able to do it every day. I found out the hard way that money doesn’t buy happiness and my exit plan sucked.

SO, WHERE YOU GOIN THEN?

We’re so lucky to be in this industry, with so many opportunities in front of us. One person can build a business from nothing and sell it to Microsoft for billions of dollars. How insane is that?

You can also build a business like my friend Frans Bouma, who sells developer tools that enable him to take fun pictures in video games. Another friend, Rick Strahl, also sells developer tools that enable him to chase the wind between Hawaii and Oregon. These people are just fine without company stock, an IPO or acquisition and, instead, enjoy the work they do every day.

Other friends enjoy the security of a job at a FAANG(M) and know they’ll be taken care of until the day they retire with their fat nest egg. They interact with coworkers every day, leave work behind them (for the most part) when they go home and don’t stress out about their next paycheck.

The important thing is to know what you want to be doing and where you want to be when your current gig is done.

I was talking with my friend Tess Ferrandez at NDC London just over a month ago and we started talking about code reviews. She was about to go on stage, and that was the subject of her talk (I can't find a link to the recording), which was ironic because it was also the chapter I was outlining for The Imposter's Playbook, which I'm getting near to finishing. 

I stood in the corner of the room, which was jam packed, as Tess offered her tips on being more understanding, empathetic, and, in a word: human when you review someone else's code (thanks to Emad Mokhtar for finding the link!) .

This is something we should talk more about!

Advice from Stephen King

Reviewing code for someone is, quite literally, an editing process. Your goal is to help them find the nugget of goodness, the purpose, if you will, of what they're trying to create. One of my favorite English teachers in college pushed me once, quipping: whatever you're trying to say, just say it already.

That was a bit forceful, but apparently what I needed at the time. It unlocked the idea of "voice" for me, and my writing dramatically improved from that point on.

I like how Stephen King describes the editing process in his book On Writing, which I've read 3 times now:

To write is human, to edit is divine.

I like that, and I think we can adopt that idea in terms of code reviews:

To code is human, to review is divine

My English teacher unlocked something in me that changed my life. My friend Dian Fayeedited a book I wrote, A Curious Moon, and would consistently blow my mind with her ability to see what I was trying to say, and push me to say it. It's more than fair to say that book would not be what it is today without Dian's patient, kind, thoughtful, and ridiculously smart feedback.

I think we can do the same for others when we review their code.

A Dedication to Plot and Scene

The plot of most books is made up of a series of scenes that the characters move through. We can think of code this way, as reviewers, except instead of characters we might be dealing with bits of data wrapped in classes or structs of some kind.

Clarity of intent, when it comes to code, is paramount if you're trying to convey why a bit of code exists. As a programmer, it's important to set the scene for your reviewer, so they know what's happening and why.

I think this is a challenge for many programmers, myself included. Consider the following bit of code. I found this online, but it could easily be something I wrote! Let's pretend we've been asked to review it, shall we?

What are your thoughts as you look over this code? What "scene" are we in and what characters are at work?

Channeling Terence Fletcher

Like any review, the code above has room for improvement. I'm sure you see things, immediately, that you don't care for, such as:

• No comments.
• Use of older JavaScript patterns.
• Possible floating point math issues.

To name just a few. Already sounds like I'm picking on this poor person, doesn't it? That's human nature. I'm absolutely not trying to nitpick here! If I'm asked for a review, I should give a review, right?

Unfortunately, I sound like this guy:

If you haven't seen Whiplash, by the way, please... change that! The professor above is Terence Fletcher, one of JK Simmons' most amazing roles. The guy is terrifying.

Let's not be terrifying. Let's see what we can do to be "divine reviewers", shall we?

We're Here to Help Clarify

If we understand that our role is to help our coder find the beautiful truth of their code, then this becomes a bit more fun! This, however, means that we need to address our inner Terence by seeking the good. Yes, we're being sugary and yes, there is a benefit to a dose of salt at times. We'll get there.

Here's a list of positive things we can do straight away:

• Does the code run?
• Do the tests pass (yes there are tests with this code)?
• Do we have opinions on how we would have written this?

If we're reviewing a PR on GitHub, we ideally have a build that will go off, running whatever tests that our coder has put in place. That should be the first order of business.

If there are no tests, which could easily be the case, then we're done with our review and we can reply in a supportive way: adding a few tests would help me review this code in a much more efficient way. It would also add nicely to our build - can you add a few that cover the basics?

Or, if you're on good terms with the coder, your reply could be a bit shorter: tests? This would be the "dose of salt" I referred to above. Submitting code without tests is a waste of time - namely ours as a reviewer - and people should be reminded just how precious time is.

Let's assume we have tests, for now. The tests are reasonably complete and demonstrate that the code works, as far as the coder is concerned. This is good and positive stuff - let's find something else that's a positive!

I like the use of a hash for the cart items:

I like this because I understand the scene, because I've read this book before (if you will): we don't want duplicate items in the cart, so having a hash helps with that. I do think a comment here would be useful, however, because a few years from now we might forget how carts work!

Comments tell our reviewers and our later selves about the scene unfolding in our code. If you take care to write comments that create a scene, you might also realize that you forgot something (happens to me all the time), or that something you've written just doesn't make sense (also happens to me all the time).

On to the characters now - or the "data". Who is in this scene, and should they be?

I'm noticing that an id is being sent in for the item, which means that identifying an item in the cart lies outside the cart itself. This might be by design, but I'm curious if the item has an identifier, like a sku, perhaps? If so, we can improve this method signature and, possibly, make the dialog a bit cleaner.

Finally, item is a bit generic and could benefit from more development - "rounded out" if you will. Let's suggest a little more clarity in terms of what's expected, using destructured assignment:

Let's stop at three bits of feedback (comments, using the item identifier, and destructuring). If we've done our job right, these suggestions might trigger a few ideas in our coder's head!

Offering Sparks of Inspiration

One of the things I didn't bring up in the first round of review is the lack of checks on the incoming data. What if there's no sku or name or the price is 0 or, worse, less than 0? How are discounts handled? 

By offering the destructuring suggestion, we're nudging our coder to add details and make clear a few assumptions. Just seeing those three values coming in naturally makes you question their validity. That's the hope, anyway.

This code review might take a few rounds to get "right". It's a discovery process that should focus on helping our coder sharpen things, not write code the way we think it should be written.

Would I like to see a class here? Sure! A factory method in addition to an empty constructor that creates a cart from data passed to it? Yes again. Does this code needthat? I don't think so. It might come up in the future, and if it does, I can bring it up then. The important thing here is that our coder gets their PR in the door.

They might also ask if there is anything else they could do to improve the code. That's a tricky question because it means you think you know how to do it better, and maybe you do, but would adding patterns and refactoring things the way you like to see them really improve the code? It's working and the tests are passing!

So that's what I would say:

The code works. You've added a few more tests, I see, and I like the way you've used assert to ensure that price is correct and that there's a sku. This meets our requirements, but if they change, we can talk then.

That's a tough one, when you're asked "how can I make this better". Answering that question highlights the gap between you and your coder, which can be discouraging. You might have a lot of experience, and flexing that can be destructive.

Conversely, your coder might have more current knowledge, or actually moreexperience than you in some areas. By offering your "improvements", you might be limiting yourself rather than learning something new, which happens to me in every code review I've ever done. 

Thoughts?

Obviously this is highly subjective stuff, but you can make a massive difference in someone's career by offering careful, thoughtful code reviews. Who knows, you might learn something!

Have some thought for me on this? How would you improve my code review process 😇?

Back in 2014 I created a course for Pluralsight called Hacking Ghost, which is the CMS platform you're reading this post on (or maybe got an email from). I had a good time putting that course together, but Ghost has grown up a lot since then.

I've been using it on my personal site (this one) for the last year or so and I really, really like it. Recently, however, I decided to see just how far I could push this platform to do a few things it was never meant to do.

Allow me to share, because some of y'all might benefit!

Hosting Video Courses

One of the things I have wanted for a very, very long time is a site that's all about content production while at the same time capable of hosting video courses. You can do it in WordPress, of course, and there are a few services out that there come close... but nothing like Ghost.

It's easy. That's really the selling point here. One thing that's extremely simple to do is to create your own theme. Ghost uses Handlebars under the hood (a Node/JS templating engine) and exposes a ton of helpers to you that allow you to create what you need. They also give you access to routing using a simple YAML file.

I have quite a few templates laying around, so I took one of them and made a blog theme that I like based on Bootstrap 5. I also did something that I've wanted to do for years: I wedged in a Vue application so people can watch the courses I've made.

Here's one that I just launched: The Imposter's Frontend Accelerator. Click around! I think it works pretty well so far, though there might be a few bugs here and there.

Point is: Ghost is flexible enough that I could write up a Vue app, drop it into my theme, and show some courses! But there's a little more here too...

Hooking Up Supabase

Ghost doesn't give you access to its database, unlike WordPress (thank god). That means that if you need to access some data, like whether someone has bought one of your courses, you need to do something different.

For this, I used Supabase. It's basically a "backend in a box" that runs on Postgres and for me, say no more I'm all over it. All of my business data is in there going back years and if you bought something from me, you're in there!

One service that Supabase offers is user authentication. They do this using magic links, email/password, and social. This presents a problem with Ghost because Ghost provides authentication too - so how do you synchronize the two?

Here's the fun part - and I think it works pretty well. Every user of this Ghost site has an account with a GUID as an ID. When you're logged in, Ghost gives me access to your information from my theme:

const email="{{@member.email}}";
const password="{{@member.uuid}}";

Now this might make you want to puke, especially seeing the password reference there - but just think of it as an access token. I have a routine that fires when you visit the site that tries to log you in to Supabase (if you're logged in to Ghost). If that fails, I send your credentials to an edge function (another Supabase service) which adds you on the fly.

Once added, I know what you've bought and what you can watch - all protected by Supabase's row-level security, which I'll let you read about... or I might write about it more at another time if you're interested.

Is it a hack? Sure! Does it work? Yes!👨🏻‍🎤

I love exploring and learning new things. While fun, sharing what I've learned is even more rewarding. 

I spent the majority of my free time over the last year finishing off The Imposter's Roadmap,which I just wrapped up final last weekend. Everything I'm about to share is detailed in the book, and if you're interested, I have a discount for you!

1: The GitHub Project

I was talking with Burke Holland a few months ago about using GitHub to run a technical project (using GitHub projects) and he shared with me that the VS Code Team (who we work with) uses a simple repository with issues instead.

I found that confusing. GitHub has the notion of actual projects with Kanban boards, roadmaps, and customizable tasks... how could you use a repo to do this? Moreover: why?

Then he showed me their iteration plan:

Long story short: the VS Code team uses a "parent" issue called an iteration plan (from Agile), which covers a month's worth of work. On that issue, they create a set of tasks and notes, and tag the people responsible for each one. They also tag child issues, which they track from the plan. When the work is done, the task is checked.

All of the checklist tasks in an issue come with a "Create Issue" hover button, that you can see on the right side of the editor. If you click that, an issue is created and linked back to the parent. Crazy stuff.

The iteration plans are done in monthly milestones, so it's easy to go back and see the work performed in a given month. It's also easy to customize, which I love.

Burke and I liked this so much, we plugged it in for our group (which Burke leads) and it's been working wonderfully.

2: Bullet Journaling with Obsidian

I love the Bullet Journal process. It has made a massive impact on me personally, and helped me see clearly where I waste effort, and what I really should be focusing on (like finishing the Roadmap book!). 

The only downside is that it's hard to search and relate information. I find myself referencing collections 2 journals back sometimes, which breaks my mental flow when I have to go dig up the old journal and find what I was trying to remember.

I tried a few digital methods, including Notion, Apple Notes, and a few other writing apps - but none did what I needed. Then I decided to give Obsidian a try. Everything is stored locally in Markdown files, which you can sync using a cloud solution of choice (I use iCloud).

Over a weekend, I created a set of templates and a process to mirror the Bullet Journal method:

• My daily, monthly, and yearly logs sit in the root, tagged with the date.
• Each month has its own directory, with all the daily logs moved into it at the end of the month.
• A collection lives in the month it was created.
• People and Processes are tags, so I can always find them when I need.

The terminology here (daily logs, collections, etc.) is very Bullet Journal-y, but you pick it up fast.

Here's what it looks like:

Obsidian supports GitHub style Markdown, so you can add all kinds of flourishes to your notes, like special checkboxes and callouts. Everything is templated, so it's super easy to create your daily log and not forget something.

I'm thinking I'll do a YouTube video about it. Reply if you'd like to see that!

3: Code Generation with Careful Prompting

It's fair to say that most people I know are pretty tired of reading about AI, and I completely understand. That said, Burke (him again!) asked me to review a video he put out on prompting, and it blew my mind. I just didn't know you could do these things!

It got me thinking: every demo I see that uses ChatGPT or Copilot uses a prompt to do a thing; but what if we thought of it more as a conversation, rather than a command?

I started playing around with a simple idea: 

• Create a README that has the scope of what I'm trying to do. Maybe I'm building an e-commerce application, or something. I have a summary paragraph and then a bulleted list of services and functionality.
• Create a SQL file that could be my dumped database schema, or what I hope to use at some point. The more detailed, the better.
• Load these files up to ChatGPT (or whatever model you're using), starting with the README. 

The conversation, at that point, starts with something like:

What is the simplest file structure and project architecture I can use to build the application described in the README file?

I'm using Copilot for this, and this response is pretty grand:

I like what I see here, but I could do without controller and the config stuff. That's where the conversation part comes in - just tell the LLM what you want to have added or removed. Once you see one you like, you can actually tell ChatGPT to "remember this", and it will!

Next you load up the SQL file, and prompt:

Here is my database schema. Use this to create the models using Sequelize. 

It's insane how accurate the code is! The data types are correct, as are the null checks. Copilot (the LLM I'm using here) was able to guess the relationships too. I'm using the Chinook test database, by the way.

It's not perfect, but that's fine, we're still way ahead. Sequelize, by the way, is a popular ORM for Node. Replace with whatever you use and, yes, it will generate a repository for you if you want! Even Command and Query objects if that's your thing!

Here's the fun part, however:

Create a bash script that generates the code for the Sequelize models.

This freaked me out the first time I saw it. Here's the response I got (yours might be different):

I didn't know Sequelize has a CLI! I opened the terminal in VS Code and clicked the "Run in Terminal" button in the chat for each of the responses. The CLI generated the database migrations and model files I needed... and everything worked. 

We live in wild times.

I do feel that it's a roll of the dice when you do things like this, and this time I got lucky and snapped a screenshot. Other times I've had to go in and tweak a few things - but I'm still far ahead, and honestly don't mind.

There's More...

I've learned so much in the last year, which is what I love about the work I do. I hope you found a little inspiration here, and if you want to know more, go get the book!

Thanks again!

Rob

I was reading Twitter/X the other day when I came across a compelling question from Kevin Naughton:

This is a wonderful question and, to be honest, something I didn't understand until a few years ago when I wrote part 2 of The Imposter's Handbook.

As you can see, Kevin got a lot of replies and, if I'm honest, there seems to be a lot of confusion. Old Rob might take up the challenge here, striking up some exciting conversation on Twitter about the nature of one-way functions... but let's be positive and dig in to some details.

The Enemy Knows the System

There are a lot of very wrong replies to Keven's tweet and I don't want to call anyone out, but I will say that the theme of wrongness goes something like this:

I have a bunch of things and if I scramble those things up and give them to you, you'll have no way to unscramble them.

There were examples of candy, cake, a deck of cards, and so on and many of them made sense in a human way. I wouldn't want to unshuffle a deck of cards or unbake a cake!

But see here's the thing: if I know the result (a lovely cake) and your exact process, which I will because these are algorithms after all that must produce the exact same result - then it's possible for me to figure out the initial ingredients - easily I might add. It might take a while and some guessing, but in short order I will produce the exact same cake.

When you bake a cake or shuffle cards, you're doing encryption: turning one value into another following a process.

Hashing, on the other hand, is completely different. Hashing turns some value into an unrelated number using functions that you can't reverse - this last bit is the thing I think most commenters were missing.

What's a One-way Function?

Let's take our cake's individual ingredients and weigh them on a scale that only counts up to 11 grams and then starts again at 0:

Some ingredients will weigh more than 11 grams, of course, but you would still record the number you see on the dial. For instance: 35o grams of flour would spin this dial around quite a few times before ultimately landing on the number 9.

This is a modular operation; 350 mod 11 to be specific:

Now, imagine that I do the same for every ingredient and record what the dial says using my mod 11 scale, and then write that number down. It might end up being something like:

Sugar: 4
Flour: 9
Eggs: 3
Oil: 3
Vanilla: 10
Milk: 3
Salt: 0
Butter: 8
Baking Powder: 4

Now we have a number we can play with, or compress, in our hashing algorithm: 4933103084. How did we get this number? Well you just saw me do it, but there's no way you could reliably figure out my ingredients list from here!

Hey, It's a Video!

Want to see more? I made a video about all of this and I do hope you enjoy...