A guide to getting technical in the age of AI
March 14, 2023. A day that will live in infamy.
Just months earlier, I was dismissing GPT3 and 3.5 as glorified SmarterChild. And then GPT-4 arrived.
I threw some coding questions at it and what came back floored me. The thinking was clear. The code ran. Follow-up questions suggested real understanding. It was immediately clear: I could use this thing to learn anything. And so I did.
What started as a short break between jobs turned into two years of full-time self-study. Thousands of github commits. Multiple bootstrapped projects. Countless small experiments.
I get a lot of questions about it, since going from thinkboi to builder isn’t a common path. I also had the good fortune to be mentored along the way by friends who are 10X developers. That instilled some fundamentals I couldn’t have gotten from AI alone.
So this is a guide for those starting out on the narrow road. Here’s the plan I wish I had, the setup you need, and how to actually get good.
1) If you are at true zero, go to class
The truth is you can’t do much at zero. There’s a zillion options and a trove of knowledge on YouTube. But being in-person at this stage can make a huge difference. (For me, I had 1 or 2 CS classes that I had mostly forgotten, and that was enough). CodeAcademy and General Assembly can work. But you need something or someone to show you the way.
Before you get too far, it’s worth stepping back and understanding what computers do exactly. Learn how computers evolved from tide calculators from this Veritasium video. Understand the modern plumbing with this legendary article What Code Is. (Non-technical rightly people freaked out when this post came out.) It puts to words how “a computer is a clock with benefits.”
2) Play the computer like an instrument
Your only goal from now on—play the computer like an instrument.
Like Mozart plays the piano. Like Jimi on the guitar. Before you really get going in the Terminal, start working this into your everyday browsing. Terminal shortcuts are the exact same in Chrome. Start with these three, you’ll use them every day for the rest of your life:
- ⌘ + w → kill tab
- ⌘+ “[“ OR ⌘+ “]” → switch tab
- shft + ⌘ + t → resurrect killed tab
Then, start working in a few more:
- ⌘ + tab → switch apps
- ⌘ + ~ → switch between windows of the same application
- ⌘ + l → edit the search bar
- ⌘ + left arrow → back
Get post-it notes going. My monitor’s covered in them.
Then, download Magnet and RayCast from the Mac app store. Make another post-it until those are muscle memory. You should start feeling one with the computer.
3) Go mouse-free
You won’t appreciate this until later, but you need to AGGRESSIVELY go mouse-free. Like I swear to GOD ALMIGHTY, if you touch that mouse when you could’ve used the keyboard…
Because once you learn terminal commands, next it’s github commands. Then tmux. Then PSQL, then Docker, then…
It never ends. It’s like trying to play music without doing your scales. Every time you touch the mouse you should feel a deep pang of shame. You embarrass the family name when you touch your mouse. ⌘ + tab to everything.
4) Terminal Setup
Once you’re navigating the computer mouse-free, get someone to help you add these:
- homebrew – essential, but a PITA to get set up on M1 mac
- python 3.11
- Alacritty (preferred terminal alternative)
- gh – github
- zsh + ohmyzsh – terminal shell / z search
- Poetry
- Pnpm
- Cursor as IDE
It’s possible to DIY with GPT but this is tricky for everyone. Get an experienced dev friend to inspect your setup here if you can. What you probably need is an hour or two of setup to get homebrew, Alacritty, github, python 3.11, pyenv, zsh, ohmyzsh, and poetry installed.
I use Alacritty for the terminal and Cursor for the IDE. Highly rec both.
5) Running the actual code
As mentioned above, there’s unfortunately a lot of ‘brew install this’ ‘brew install that’ to getting code running. Time for the moment of truth: ensuring you have a proper config. Get a basic script in main.py saved in terminal. If you can’t get it to run, see 4.
Next, you need to learn about package managers. Poetry is the best starter here (uv is great once you’ve learned). Basically, you’ll start a fresh repo with “poetry init” press enter a few times for the default settings. Then, if you want your code to work with other people’s code, say, Open AI’s SDK, you’ll bring it in with “poetry add openai.” Then hit “poetry install” and it will actually download the code to your repo. Now, you’re standing on the shoulders of giants.
Last thing to understand is the shell and virtual environment. These are weighty concepts and I never found great explanations. But you’ll intuit how it works by badgering LLMs into getting your code to run with poetry shell. If your config is right, running “poetry shell” returns “spawning shell…” and spins up a virtual environment (i.e. an activated zone where your code will run smoothly with the outside libraries and packages). You’ll pick it up.
6) Git good
After that, make a github account. Let’s say you made ‘yourGHusername’ as your github handle. On your machine, make a series of nested folders like this where you’ll start keeping code repos:
/Users/firstnamelastname/code/repos/github.com/yourGHusername
And in the yourGHusername folder, that’s where you’ll keep all the code repos.
When I make a new repo that I want to be cloud connected, I go online to github.com and hit New repo. Once made, with the green button I grab the “clone this” details. And then in my Terminal/Alacritty I will cd up into “NpappaG” and paste the command “github repo clone thisrepo.”
Before moving on from here, it’s worth getting comfortable with 1) making a repo from scratch that’s pushing changes to the cloud and 2) getting all the commands down. Git is one of those things that may take weeks to really crystalize. Do it over and over.
Too often, newbies want to jump right to project building without using git. It has goofy, archaic commands. You don’t need git to run code or even ship an iOS app! But soon you’ll see how this is like rock climbing without a harness.
Let me save you some pain (or tears from lost work). Don’t proceed until making a repo, committing, and pushing is second-nature. It may take a while for it to click. But there’s no point in going further until it has.
5) Choose a medium-term project
Assuming you’re a regular Beethoven on the keyboard, and you’ve figured out running basic programs, and you’ve got your code pushing into github with ease, project-based learning is where you ramp up.
Think about a project that might take a few weeks to complete. A tool that would help you do XYZ in your workflow. Make sure it’s something you IRRATIONALLY want to see in the world.
For example – I desperately wanted to listen to newsletters and turn it into a podcast using text-to-speech. This is the perfect scope for a project:
Email autofwd → Email to rest API → cloud-deployed python app→cleaned text→voice synthesis API → saving the audio
That is the perfect sized scope for starting out. Break out the project into mini-projects and start there.
6) Pick the right tools
The packages you choose for a project matter quite a bit. The more tried-and-true it is, the more LLMs will have in their training data. I’d recommend:
- Backend: Python w/ FastAPI, SQLAlchemy and Alembic (start getting comfortable with just FastAPI, then when it’s time to start saving data in a db see this guide)
- DBs: Postgres, there is no second best
- Frontend: Next frontend with Tailwind (start with JS and get into Typescript ASAP)
There’s dozens of guides and Youtube videos for all of these. Don’t overcomplicate it with the shiniest new toy.
Lastly, actually consult the documentation for your packages. LLMs aren’t perfect and can still lead you astray. Make sure what you’re doing aligns with the Quick Start docs.
7) Knowing what to do when
It’s easier said than done. In creative pursuits, planning too much can ruin the end product. As a researcher, I’d rarely know what I’d dig up in the process.
Software is more like brick laying: measure five times and cut once.
And it’s easier than you think to forecast what will go into a day’s work. Break down the steps into smaller steps. And plan on getting every step into production. You’d be surprised how good LLMs are for helping plan this out. Pomodoro it out. Stick to it.
8) Time for your Vim pill
As you start making working code, you’ll be rewarded with learning… EVEN MORE SHORTCUTS. The last step in your hands-free journey is vim. You’ll need these:
- vim (a bizarre keyboard language you will master with this game and cheat sheet)
- vimium (chrome ext for hotkeys everywhere)
- magnet (mac app for moving windows with keys)
- tmux (add this once comfy with above, but essential)
- vim extension in VS Code / Cursor (get comfy with vim in terminal before adding to IDE)
- HomeRow (OS X level vimium-style hot keys)
I’ve made this point but it bears repeating. You NEED to learn all these commands if you want to do serious programming. In 2025, you’re still human glue interfacing between tons of apps and abstractions. Mastering the commands makes you like Tom Cruise in Minority Report. And the time savings is exponential.
For example, here’s how I’ll use vim if my code doesn’t run. That’s:
- ctrl + a + [ to engage vim in the terminal
- shft + v to highlight the relevant error text
- “y” to yank/copy the highlight to clipboard.
- ⌘+ tab to switch apps to Cursor/IDE
- ⌘ + y to pull up the LLM bar
- paste and ask LLM pls fix
I reckon I saved 20 seconds on that one move. But you might do that a hundred times in a day. That’s almost 35 minutes. If you code daily minus weekends, that’s 3+ weeks of savings in a year.
Vim is a steep learning curve. But you’ll save so much in man-hours that not using it will soon be unimaginable. Trust.
9) Deployment
Maybe you’ve heard jokes about “testing in prod”. Well, you won’t know what that truly means until your code is running in the cloud (aka prod).
Once comfy with github and your app is running locally, figure out what goes into making it run in the cloud. (My advice, look into Railway and Docker.) Docker is a beast but it’s 100% worth learning and will save tons time down the road. Videos helped me.
If you’re here, you’re SO close to being nasty. Run one program in the cloud and you’ll be drunk with power. You can do it, I promise.
10) Don’t Build for Tomorrow.
After getting an app deployed, a surprising find is that yes… it theoretically works forever. But the big lie is that software runs perfectly in perpetuity. Maybe that’s true for Calendly. For everything else, there’s always new demands, new improvements.
That leads me to some counterintuitive advice I got: don’t build for tomorrow.
Because you will say to yourself, “Look I’m dead certain in 2 weeks I’ll be adding a category column in my database. Obviously, users will want to know what category their newsletter content is, right?”
WRONG. Fight the urge. If you can get away without it today, don’t add it yet.
Why? Because everything is iterative. And you don’t want to iterate with something unnecessary bolted on. Keep it tight.
11) Your new mantra: “small commits, shipped through to production”
What on earth does this mean? It means don’t batch merge a huge heap of changes. Instead, get your progress all the way to production. Start using git branches before merging to main.
[Literally for an ELI5 – you’ll start a new branch (“git co -b new-branch-name”), manipulate some code, get it working locally, then in github merge that branch. Ad infinitum. ]
Small commits, shipped all the way through. This is the way.
12) Everything is like everything.
Once you get good, you’ll notice many things in computing rhyme. Computer architecture is basically: Russian dolls for everything. If you appreciate that, congrats. You are now good with computers.
NpappaG 