The software engineering job market was NUTS just 4 years ago. Now, the job market is constricting. Sure, some of it’s due to macro stuff, but plenty of the pressure is from AI.
When ChatGPT came out, I quickly started using to help me program. Some syntax lookups here, some bug hunting there.
Then came Cursor. Shortly after, Claude Code. In-between, Replit, Lovable, v0, etc. Programming has changed, and it changed FAST. You can build apps that used to take days-to-weeks in less than an hour. You can do real software engineering work without actually writing a single line of code.
Some people are interpreting this as the end of the profession, but I don’t think software engineering is going away completely.
I think the best engineers 5 years from now are going to be the ones that understand programming incredibly well and leverage AI tools effectively.
If you want to be a software engineer, you should still learn to program (even if vibe coding tool startups are telling you otherwise).
If I were starting from zero today, I’d approach learning to code very differently than people did even five years ago.
The optimal path to a career in tech has changed. Junior developer jobs are getting eaten by AI because AI can write a shocking amount of code now. That’s both a cheat code and a trap.
You can ship real things faster than ever without ever building the mental models that make you dangerous in a codebase. This will cause you problems in a real development job.
You should bother to learn to actually program.
Here’s exactly how I’d do it.
If you only build projects with AI, you’ll get dopamine and cool screenshots for a portfolio, but you’ll build a shaky foundation that will cause you real problems.
If you only study fundamentals, you’ll get theory and no momentum, forcing you to move slower than you actually have to move.
So I’d split it:
You need both at the same time. I’ll show you the exact steps I’d follow, but first, a word about debugging.
This is the part beginners skip in the age of LLMs, because AI “fixes” lots of bugs without much effort from you.
I would make debugging a first-class skill from day one.
You need to get comfortable with:
I can NOT stress enough how important it is to be able to read and understand a stack trace.
Here’s a rule I’d follow:
Never paste an error into AI until you’ve read it, located it in code, and formed a guess about what it means.
Even if your guess is wrong, that act is building your brain.
Because the people who “make it” in software are the ones who can stare at a broken system and methodically force it to make sense.
Pick Python or JavaScript. I’d say pick Ruby because I love Ruby, but the job market for Rubyists is weird.
Pick one, commit, and start.
You can learn the other later. The first language is mostly about learning how programming works.
I’d do one solid beginner YouTube course to get the basics:
Courses feel productive, but they’re a passive form of learning past the initial ramp.
After that, you need actual reps.
Yes, LeetCode. This is good training for interviews at least for now (tech companies are quickly making interviews AI-first).
The main reason to do this is it to build muscle memory and learn the core data structures and algorithms without hiding behind frameworks.
What I’d do:
You’re trying to internalize arrays/lists, strings, hash maps / dictionaries, stacks, queues, recursion basics, sorting/searching patterns, and time complexity intuition (you don’t need to be a wizard, just not clueless about how your code handles growing inputs).
This is where you build the “I can reason about code” brain. You can even use AI as a LeetCode coach!
I would do step 3 in parallel with step 4.
I would do this step in parallel with step 4 (the above).
This is where Cursor (or similar tools) becomes a huge advantage.
But I would be intentional about it.
I’d build 3 to 5 basic apps:
The rule is: small, boring, complete.
Use AI to speed you up, but add constraints so you’re still learning:
You keep doing this until you can build one of these apps without leaning heavily on AI.
Agentic tools like Claude Code are incredible. They’re also dangerous for beginners.
So early on, I’d skip the “AI goes off and does a bunch of stuff” approach.
Stick to an interactive tool like Cursor, where you’re still steering, still reading diffs, still making decisions.
Earn the right to go more agentic later.
Before spending years on a CS degree, bootcamp, or career switch, I’d want to prove something to myself:
I can build a small app end-to-end, understand most of the code, and debug common issues and not hate the process.
It will take time to gain this level of competency. If you can’t get there, you might still eventually become a great engineer, but you should learn that before you commit major time and money.
Once you have baseline competence, it’s completely fine to lean harder into AI, including agentic workflows.
Just keep one habit alive to avoid skill atrophy:
Always have a “learning mode” for some portion of your work.
]]>Conversations I’ve had with peers and mentors quickly turn to the topic of specialization. If you read around online, you’ll find a lot of arguments about whether it’s better to be a specialist or a generalist in terms of the skills you build.
This is an especially notable topic when considering software engineering careers, because there’s so much to learn, you can’t possibly be the best at all of it.
Cal Newport writes often that if you want something above-average from your career, you have to provide above-average value.
In his “So Good They Can’t Ignore You”, he puts it clearly:
If you want something that’s both rare and valuable, you need something rare and valuable to offer in return—this is Supply and Demand 101. It follows that if you want a great job, you need something of great value to offer in return.
The whole question of specializing vs generalizing for me is really a question of how I can offer the best value to my team. If I were superhuman, I would just become the best at all programming things and while I’m at it become the best at business things too. But that’s not realistic, so many of us find ourselves wondering where best to focus our limited energy.
It seems to be common advice, at least in software, that specializing after building a foundation of knowledge is a good way to differentiate yourself. But what does it mean to specialize?
Saying that it’s good to specialize isn’t specific enough.
Even knowing that it’s a good move to specialize still isn’t enough information to make an actionable decision about what to get good at.
We already know that being the best at what you do is great.
I don’t know about you, but becoming the world’s best programmer seems like a daunting task for me. Naval talks a bit about how redefining what you do to make it easier to stand out:
If you really want to get paid in this world, you want to be number one at whatever you do. It can be niche—that’s the point. Become the best in the world at what you do. Keep redefining what you do until this is true.
Just becoming the best programmer is too hard. Becoming the best ruby programmer is hard, but not as hard. Becoming the best Ruby on Rails backend developer is a little easier. Becoming the best person at improving tests for Ruby on Rails apps is niche enough to be achievable.
It’s a lot easier to be the best in a category of 10 than best in a category of 10,000.
I’ve found that a good way to continue refining what I do is to develop mastery in more than one thing. This is sort of specializing - Steph Ango, creator of Obsidian, calls it hybridizing:
The hybrid path means developing expertise in two or more distinct areas. Having several specialties allows you to see patterns that no one else can see, and make contributions that no one else would think of. The world needs more hybrid people.
My favorite flavor of Hybrid that Steph describes is the U-shaped hybrid, where one develops a wide base of skills with 2 specialties.
I’m still figuring out what this means for myself. I like to write backend code with Rails, but I’m also trying to develop my skills in infrastructure. I like to write code, but I also like to teach people how to write code through long-form tutorials. Fortunately, both of these paths are complimentary.
In the end, careers are long and these aren’t one-way doors. I’m having fun experimenting and learning - I hope you are too.
]]>Maintaining a brag doc takes time, so many people are hesitant to start. There are plenty of reasons why a brag doc is worth the work. Most of these reasons point towards ways for you and your manager to avoid recency bias when thinking about your performance.
For starters, a brag document helps you remember what you did at work. This is a huge benefit to your career for a number of reasons, but a little-appreciated reason is that it gives you visibility into your time spent.
You can work ten times harder than anyone around you and it still not matter for your growth or career if you spent that energy working on the wrong things. A brag doc helps you retrospect on whether you’re actually executing on things that push you towards you goals.
The second benefit is that a brag doc helps your manager (and maybe even their manager) appreciate the value you bring to the business. Whether they’re thinking about your performance for review season or trying to justify a promotion, a brag document helps your leadership avoid recency bias. An organized list (we’ll get to that later) of what you did and why it matters gives clear visibility into your impact, which can only help you in performance reviews and promotion committees.
If you’re still reading, maybe you’re convinced to make and maintain a brag document. You could start by just keeping a note of all the work you’ve done, but putting in a little extra effort goes a long way.
These days, I recommend using AI to make the best brag doc.
As a software engineer, you can start by going to your issue tracker or version control system like Jira or Github and copying work you’ve completed recently. Each item should have a “what you did” along with a “why it matters”. Something like “shipped this linked pr that fulfilled my team’s xyz OKR” is a great general format. Half an hour spent doing this ought to yield at least a quarter’s worth of work, which should give you enough space to start organizing.
The way you format your brag doc is largely dependent on your primary goal or audience, so there isn’t a one-size-fits all template. Most recently, the primary purpose of my brag doc was to make it easier for my manager to advocate for my promotion. I wanted to grow faster as a developer, and I wanted to get recognized for that growth.
Because of my goal, the format of my brag doc looked a lot like a promotion justification. I started tracking how the work I did aligned with the expectations outlined for the level above mine. After a year or so, I had a dense document that outlined how I was fulfilling the expectations of the role above mine, supported with links to design documents, code reviews, and pull requests.
These days I’m still sorting out the format of my brag doc, but I’m leaning towards aligning work under headers that represent goals I’m working towards for both my performance and areas I’d like to improve in.
It’s just as important to track work that isn’t explicitly found in a pull request or Jira ticket. Glue work like helping peers and responding to incidents is all valuable to the business, so it belongs on your brag doc. This is the hardest work to remember, so you may have to ask your peers or leadership if any work you did comes to mind as particularly helpful to them.
A brag doc is best done when updated regularly. Trying to do this on a yearly or even quarterly basis is playing life on hard mode. I have a regular calendar reminder to update my document every 2 weeks, which makes it pretty painless.
It’s up to you to shamelessly advocate for yourself. Keeping a running list of the impact you have definitely isn’t the most fulfilling work you’ll do as a developer, but it might be the most valuable for your career.
]]>I got a Raspberry Pi for my birthday last year and have been suffering analysis paralysis, trying to figure out what I want to do with it.
I recently came across some open source software called Pi-hole, that boasts the ability to block ads for your entire network. Perplexed, I had to see how this worked, so here’s how I set up my Raspberry Pi to act as a black hole for all things advertisement related. Not only will you experience a (mostly) ad-free internet, but things like Smart-TV’s and other “sketchy” analytics tools won’t be able to send their data home. Hurray privacy!
If you have any questions, leave a response below or feel free to tweet me!
The Raspberry Pi is an incredibly cheap computer, which makes it a great candidate for such a specific task.
I have tried this on both the Raspberry Pi Model 3 Model B and the new Raspberry Pi 5. It’s wireless, so I didn’t need an adapter. However, if you buy a model without WiFi, you will need to either wire it into your router with an ethernet cable or buy a WiFi adapter. You’ll need a power supply if you don’t have one already, as well as a usb mouse and keyboard. You’ll
You’ll also need a microSD cardto store the operating system (more on that later). You’ll need an HDMI cable for the Raspberry Pi 3, or a microHDMI to HDMI cable for the Raspberry Pi 5.
The Raspberry Pi is pretty bare-bones. You can choose your operating system from a number of interesting choices based on the task you’re trying to accomplish. First, install the official Raspberry Pi imager from the website.. Given that we’re just going to run the Pi-hole software, I went with Raspbian Lite, an open source port of the Linux operating system. The lite version comes headless (with no desktop), which is perfect since we will only connect to the Pi-hole remotely. When you launch the imager, it will have you select your hardware, the operating system you’d like, and where to install it (your SD card!).
You should also customize settings to enable SSH with a password, as we’ll use that to connect to the Raspberry Pi in the next step.
When you’re done installing the operating system, you can eject the SD card and insert into into the Raspberry Pi. You can run the Pi-hole wirelessly, but if you can connect it directly to your router via ethernet you can avoid any wireless connectivity problems.
You’ll first need the IP address of the Raspberry Pi. You can find this in your network settings or by running:
arp -a
If you haven’t already, now is a good time to allocate a static IP address to the Raspberry Pi in your routers settings.
To connect to the Raspberry Pi, run:
ssh YOUR.PI.IP.ADDRESS
Here, substitute the IP addres you found for your Raspberry Pi. It will prompt you for the password you configured when you installed the operating system.
Either in your Pi’s terminal or your computer’s terminal connected to the Pi via SSH, run the following command from Pi-hole’s website to install it:
curl -sSL https://install.pi-hole.net | bash
The installer will run and ask a bunch of questions. It’s okay to choose the defaults, but feel free to customize like I did.
When the installer finishes it’ll show you the password it selected. Note this and copy it, then change the web dashboard password by executing:
pihole -a -p
Now that your Pi-hole is acting as a DNS server, we need to make sure that your devices use it instead of your ISP. You can do this on a per-device basis, but I’d recommend changing it at your router. That way, every time a device on your network makes a DNS request, it will first go through the Pi-hole.
This step is very specific to the brand of router, so I won’t go into detail. Essentially you need to tell your router to treat your Pi-hole as a DNS server, rather than your ISP. You should also reserve a static IP address for your Pi to ensure it’s IP does not change because this would break your setup.
And Voila, enjoy your ad-free internet! 🙌
Normal Ad-Blockers allow advertisements to load and just hide them from your view. Once you’ve gotten the Pi-hole up and running, advertisements will stop dead in their tracks, before they even begin to download.
Pi-hole is a very specific DNS sinkhole. DNS stands for Domain Name System, and it is the protocol for connecting names (like medium.com) to IP addresses, which is where websites/servers really live on the internet.
A DNS sinkhole acts in place of your usual DNS provider to provide false results. This pretty much breaks your internet — NEAT! With Pi-hole, everything that isn’t an Ad gets forwarded to your DNS provider, but if the domain name is in Pi-hole’s blacklist (which is customizable for the nerdiest among you), then the Pi-hole sends back a fake IP address.
So you visit a website and it loads. Next, the website asks its ad provider for ads, and Pi-hole says “What ad provider? That doesn’t exist.” And boom your ads are gone. This can actually speed up your network, as you won’t be using as much bandwidth.
An interesting note is that Pi-hole won’t kill youtube ads, as youtube serves its content and advertisements from the same DNS, so killing youtube ads would also kill youtube.
]]>It’s been a crazy helpful book, about both rules and conventions.
Here’s a massive brain dump of of Ruby goodness
@# is a commentdo end syntaxdo after an if, just the if, the condition, the block, and the endunless to mean if notYou can create an array of strings the traditional way like this
words = ['left', 'right', 'yellow']
Or in a fancy faster way like this
words = %w{left right yellow}
You can create a hash the traditional way like this
frequency = {"left" => 1, "right" => 17, "yellow" => 99}
or in a fancy faster way like this only if your keys are symbols
frequency = { left: 1, right: 17, yellow: 99 }
If you want to make a parameter optional to provide, you can specify a default
def load_font( name, size = 12 )
You can make a method take an arbitrary number of arguments by passing an astrisk before the argument name. Will create an array of values passed
def print_all ( *strings )
To run through a Ruby collection, you should use the .each method!
words.each {|word| puts word }
The find_index method for arrays returns the index of a condition being met
words.find_index { |this_word| word == this_word }
Ruby assumes if an object has the right kind of methods, then it’s the right kind of object
This is called duck typing
If it walks like a duck, well, you know the saying
Ruby uses the composed method, where methods have 3 characteristics
== behaves the same way as .equal?Object@, is attached to a single object, an instance of the given class:attr_accessor methods you can use to have getter methods for a class instance variableModuleName.method_nameThere’s a LOT more to this book, especially metaprogramming Honestly, that was a lot less interesting to me than what .I’ve talked about here, so I hope you can find it useful
]]>ActiveRecord makes it really easy to tie models in a Rails app to other models. In fact, you can even specify when you create a model what it should be associated with. If you already have to models and you would like one model to belong to the other, you’ll need to change both models and create a migration.
Let’s say you have a model, Tweet, and another model, User. A user can tweet many times,
and a tweet only belongs to one user. In ActiveRecord speak, User has_many tweets, and
a Tweet belongs_to a User. The database records are tied together, and you can build
features around the association easily.
Continuing on the User/Tweet example, in the Tweet class, simply add belongs_to :user.
The class should look like this:
class Tweet < ApplicationRecord
belongs_to :user
end
In the User class, simply add has_many :tweets.
The class should look like this:
class Tweet < ApplicationRecord
has_many :tweets
end
This will tell rails to generate some methods you can use, but you still need to tie the database records together. Create a new migration by running:
rails generate migration AddUserIdToTweets
In the migration file, make the change method look like this:
def change
add_column :tweets, :user_id, :integer
end
This adds a user_id column to the Tweets database table, which rails will use
to keep track of which user a tweet object belongs to.
You can use the association to do a number of things, including getting all
tweets that belong to a given user. The call is simple enough, and assuming
current_user refers to a User model, it looks like this:
current_user.tweets
To create a new Tweet that belong to a user, you can do this:
current_user.tweets.build(tweet_params)
Hope this was helpful!
]]>rails new app-name --css tailwind
Then I got to work making my views and adding styles. When I started the app with rails s
I noticed none of the styles loaded. You can quickly fix this by running the following before
you run rails s
rails tailwindcss:build
This is annoying though, because you’ll have to run it anytime you include a new class. You can instead start your rails server with this command for hot reloading:
bin/dev
Hope this helps!
]]>Right from the beginning, John calls out that complexity is the enemy of well-designed software. Most of the book is spent discussing either why complexity is bad or ways to avoid it when writing code.
I really enjoyed this perspective and it’s already affecting how I’m writing code, so I thought I’d share a bit of what I found most impactful.
For the purposes of the book and this discussion, complexity is something in the code that makes it harder to understand, maintain, or modify. To some extent, complexity is unavoidable.
For this reason, every decision around how our software is structured and written becomes a tradeoff.
Firstly complexity increases the cognitive load of working in a codebase. More complex apps require a developer to have (or find) more information to accomplish a task. Even further, complexity causes simple changes to be amplified into more complex changes. Anyone who has ever worked with microservices knows exactly how coupling can amplify a simple change into one that requires half a dozen pull requests.
Complexity makes it harder to make changes and introduces risk into those changes.
Obviously, complexity cannot always be avoided.
The author of this book introduces the concept of “tactical programming”, a style of writing code that focuses on finishing a task as fast as possible. Oftentimes this approach is taken by newer developers (myself included) or those trying to optimize for velocity in an agile approach (guilty as charged).
There’s a benefit to tactical programming. Businesses need to make money, and developers get paid to make that happen. Like I said, everything is a tradeoff. The author argues that developers should strive to do what he calls “strategic programming”, where the primary goal is to produce a good software design that also happens to work*.
Strategic programming can be justified in software projects as an upfront investment in the future development velocity of a project.
Tactical programming naturally results in more complex codebases that grow in complexity with exponential speed as simple changes continue to amplify into complex ones. Left unchecked, this results in a mountain of technical debt, with teams paralyzed by necessary refactors before any features can be built.
Conversely, the author argues strategic programming has the opposite effect on a project. Taking longer to implement things because of an investment in good design pays dividends, as all future changes are easier to make.
John has a strong opinion here and seems to insist that tactical programming is always bad. I personally think there are times where it makes sense to just get something done, though after reading this book the likelihood I would do that is greatly reduced.
Modular design puts emphasis on writing code so that only a fraction of a systems complexity must be dealt with at a given time, reducing cognitive load, and therefore complexity.
Breaking things into modules, classes, or even microservices is an incredibly common way to write software. What is unfortunately not as common, is breaking things into deep modules.
Modules that are deep have minimized dependencies on other modules. Modules that are deep abstract functionality away from other modules. Modules that are deep provide functionality while requiring little understanding or information from another module.
The author argues that we should design software with modules that have simple interfaces, but powerful functionality.
Specifically, the author pushes the idea that we should pull complexity downward into a module. When designing a method, it’s more important that the method have a simple interface than a simple implementation. This scales to classes or even services as a whole. Every piece of complexity in the interface of a module introduces coupling to anything that uses it.
One really easy way to reduce complexity in code and improve readability is to use meaningful names. I’ve been guilty of using abstract variable names like data only to later annotate the variable with a comment like // the location the user entered to describe the usage.
It’s far more useful to just name the variable what it actually represents, as it makes the code far easier to understand. Easier to read means less complexity!
This book contains a lot more detail (and a few more topics) that I didn’t get into here. These are the things that stood out the most to me as immediately useful in my day-to-day of writing code and squashing bugs. Still, you should go read it, no way you regret it 🙂
]]>Code, especially Ruby code, should make its intent loud and clear to the reader. Clear code is the opposite of complex code. It’s easy to understand its purpose, so it’s easier and less risky to modify, extend, or remove.
One thing that I haven’t seen explicitly discussed in this book is double negatives.
Whether it’s spoken or written, double negatives make sentences less clear. Something like “There are not no eggs left at the store” is obviously poor grammar, but it also makes the sentence harder to understand.
When our code reads like a sentence (well written Ruby should), double negatives
increase complexity. Things like unless !some_condition can be more clearly written
as if some_condition.
Most programmers will find writing in-line conditionals like this to be straightforward, but it gets less intuitive when extracting this logic into methods.
A bit ago, I was writing some ruby code with a friend. We wanted to take an action if something was false, and like the good ruby programmers we are, we extracted that complex conditional into its own short method.
We found ourselves going around and around trying to make this as clean as possible. One of our first iterations contained a programming double negative - see if you can find it:
# Method call
return [] unless items_found(users)
# Method implementation
def items_found(users)
no_items_found = false
users.each do |volunteer|
if volunteer.items.present?
no_items_found = true
end
end
no_items_found
end
# Method call
return [] if no_items_found_for(users)
# Method implementation
def no_items_found_for(users)
no_items_found = true
users.each do |volunteer|
if volunteer.items.present?
no_items_found = false
end
end
no_items_found
end
It’s a pretty small change, but I think it highlights what the code actually does much better than the first time around. I’m trying to be more intentional about writing my code with these things in mind.
]]>It’s also been a busy year for me - I got a job as a Software Engineer and worked hard at it while finishing my degree, I got my degree, and I got married. Writing for giggles on the internet took last place in my mind. Even so, I have been writing!
I spent a lot of time in college sharing what I’ve learned about programming online. I accelerated this when I started contracting for companies doing iOS development. Everyday I was faced with task that was completely novel to me. It was constant learning.
I got into the habit of writing “how-to” articles on technical things that I was learning. My words would serve as a “learning exhaust” - a direct byproduct of the work I was doing. By forcing myself to condense what I was doing for work into some words to be shared, I learn faster, understand deeper, and retain longer.
Eventually, this led to some paid work. My portfolio of learning exhaust showcased my ability to teach technical concepts well. In the last year, all my writing has been on other companies’ sites for money. For the most part, I tried to propose and choose articles that would allow me to explore and learn while I write. It’s been a wonderful way to continue to learn and grow quickly - I mean getting paid to learn is the ultimate luxury.
I’ve written for Honeybadger and been featured many times in Ruby Weekly, a newsletter in my field with 40k readers. I’ve written articles for Docker about Docker, specifically while I was learning Docker for my actual job! I’ve written articles about testing for CircleCI and Linktree about software testing, a skill that I’m intentionally growing in for my actual job (again!). I have even more articles in-progress and in the pipeline about topics relevant to areas I’m focusing my technical growth in.
One of the best and also worst things about writing on the internet is that people read what you write. Some things I write get little traction, others have been seen by tens (and occasionally hundreds) of thousands. This reveals a now-obvious problem with writing about things that are on the edge of what I’m comfortable with - People are quick to tell me when I’m wrong.
Yeah, it hurt when the first few people pointed out mistakes or nitpicked, but it’s actually been a multiplier for how fast I grow.
Some of my best growth in the last year has followed this formula:
Putting myself out there still feels silly - even writing this is a little unnerving. Still, I’ve found this pattern to be incredibly helpful in supercharging my growth. Learning in public is the fastest strategy for growing technical skills that I’ve found yet.
I’ve been using Ruby on Rails for over a year now in my job, and I’m liking it more and more. Still, I feel like a novice. I work through problems for my company and retain a good deal of what I learn, but I haven’t yet crossed the threshold where I saw I really know the language or framework well.
Over the next year, I’m putting most of my professional energy into becoming incredibly comfortable with both Ruby and Rails. I’m going to learn and write about Ruby, what makes it tick, what makes it great, and what makes it not so great. I’m going to learn and write about Rails in the same manner. My goal is that by August of 2023 I have moved clearly beyond novice in this niche, delivering more value in less time in my work.
This intentionality comes with a trade-off. I’m going to have to pass on some technical articles that would take up less time so that I can use my extra intellectual energy outside of work to learn, even if it means missing out on the extra income. I’ll probably be writing more on my website, but I’ll still be writing for places when the topics match up to my goals.
So here’s to the next year of intentional growth in my technical skills, and all the writing along the way!
]]>