DEV Community: Lane Wagner

Maybe You Do Need Kubernetes

Lane Wagner — Mon, 18 Mar 2024 13:00:00 +0000

Theo has this great video on Kubernetes, currently titled "You Don't Need Kubernetes". I'm a Kubernetes enjoyer, but I'm not here to argue about that. The part of the video I do want to discuss has nothing to do with k8s. It's where Theo draws the "Line of Primeagen".

He explains that some technologies trade scalability (performance, flexibility, whatever) for speed of development. Deploying Next.js using Vercel and Firebase is quick but it comes at a cost. As you scale up, either by adding users or by adding more complex features, you'll need to do one of two things:

Rewrite with something more flexible or performant
Pay a lot of money to a third-party to handle your problems for you

So, the idea is that you should choose a fast-to-ship technology so that you can move faster and hire more cheaply.

...I can ship a Go app to k8s faster than I can get eslint, tsc, and vsc-de to cooperate... but I digress...

Then you stick with that strategy until you scale up to the "Line of Primeagen":

It represents the point where you're spending so much money due to slow code or third-party costs that it's worth it to do the hard things required to more efficiently "scale" (whatever that means in your case).

You gotta hire a Rust Chad and kick those React Andys to the curb. Or something.

What's wrong with this idea?

Well, nothing really. Theo's correct. If you're a founder, indiehacker, or engineer #1 at a startup, this is exactly how you should be thinking.

The problem is that you aren't a founder, an indiehacker, or engineer #1 at a startup. 99% of my readers want to be a great engineer and earn a high salary as employee #2-10000 at a tech company. There's nothing wrong with that, but it means you should think about this stuff differently.

What should you do?

When I look at that graph above, I think:

"How can I be the one they throw money at to come in and do the hard things?"

In other words:

When you're making a business decision, it's generally good to pick the simplest, fastest, and cheapest option
When you're making a career decision, it pays to be an expert in hard things

To be clear, I'm not saying that you should solve simple problems in complicated ways just to inflate your market value. That can have the opposite effect. Bad engineers do that. I'd say:

Gain the hard skills required to solve complex problems, but only deploy complex solutions when they're actually needed.

Maybe you should learn Kubernetes

People don't like to hear this, but difficulty is a moat. When something gets easy, it gets cheap. If you want to be paid a lot, you need to be really good at something that's both in-demand and hard. If it were easy, everyone would be doing it. That's why very few people actually made money dropshipping in 2015 or buying NFTs in 2017.

It's also why I hate when coding Bootcamps talk about how easy it is to learn to code. It's not easy. At least, not if you're doing the interesting stuff that pays well.

To be clear, I don't believe in standing in the way of progress. I want coding and software engineering to get simpler, easier, and faster. The result of that, however, is that the winning strategy for software engineers is to continually build expertise in in-demand, hard-to-learn stuff.

So should I not learn Next.js?

I'm not trying to single out individual technologies (except for Java, don't do Java kids). I'm saying that you shouldn't be scared of the hard stuff. Don't jump from easy tutorial to easy tutorial. Once you've found your bearings in this whole coding thing, start tackling some harder problems. The work will pay off.

Give Up Sooner

Lane Wagner — Wed, 13 Mar 2024 21:57:51 +0000

As a developer, how many times each day do you look something up online? I'm not talking about a simple piece of syntax, I'm talking about the things that are a bit harder to find. For example:

Is there a good way to compile C to WebAssembly and run it in a browser without needing to modify the code itself?
Can the Stripe UI export promotion code redemptions as a CSV?
Is there a good tool for hot module reloading in Go?
Is it socially acceptable to go out in public in South Dakota with blue hair?

While working as a team lead a few years ago, I remember asking Jeffy, a developer on my team:

"Is there a way to get sqlc to use pointers for nullable columns instead of the sql.Null types?"

Jeffy went heads down for... much longer than I would have expected. After more than a full day of research, he came back with:

"No, there isn't a way. I found something that seemed promising, but it doesn't work. I think we should fork the project and add it ourselves."

Hol' up. I've got some questions.

First, you're telling me that you found what we want in the API of a well-known open-source project, but it's broken and no one else knows that it's broken but you? You are confident there aren't any skill issues involved?

Second, you're telling me that your recommended course of action is for our team of four to fork a project with many thousands of lines of code and maintain our own version ad infinitum? All for a little quality of life improvement?

No, Jeffy. No.

What was Jeffy's problem?

Counterintuitively, I believe Jeffy's problem was that he didn't know when to give up. I don't mean on the task as a whole, I mean on each individual path he was taking to find the answer. Here's a chart.

Jeffy was too attached to his initial searching methods. Maybe he was too attached to one page from the docs, to his initial search query, or to Google as a search mechanism altogether. Jeffy found a local maximum and became stuck. He should have bailed so much sooner and tried looking elsewhere.

If I don't find good evidence that the answer I'm looking for exists in the place I'm searching, I'm bailing pronto. That doesn't mean I'm 100% certain it doesn't exist, but you usually don't have to read an entire Stack Overflow thread to know whether or not it relates to your problem.

I'm honestly amazed at how some developers take so long to look stuff up. Now, in their defense, even if you're an efficient searcher, you can still get stuck in a "quagmire": a local maximum. If you're not careful, you can find yourself reading on and on about a topic that seems like exactly what you're looking for, only for it to skim over the details that you actually need. Bummer.

I'm a big fan of using AI as a replacement for some of my would-be Google searches, but Chat GPT is the ultimate quagmire, that is the ultimate local maximum. It's the worst kind of quagmire because at every step it will confidently reassure you that it does in fact know the answer. When you insist that it's wrong, it confidently continues to provide information that sounds correct, but isn't.

If you use Chat GPT for programming assistance, you need to develop a strong sense of when Chat GPT is making stuff up. In short, you need to know when to bail.

RTFM

Sometimes we talk about "Googling things" as a skill unto itself, and it kind of is. But similar to Chat GPT, it's less about formulating the most pristine search query, and it's more about knowing when to give up on a goose chase.

Does the SERP indicate that your original search query was a good one? No? Bail.
Does the first page you visit have a directly relevant title or first paragraph? No? Bail.
After spending another minute on the page are you still convinced the answer is somewhere below? No? Bail.
Is it likely the answer can be found more easily in the docs, the user manual, or, gasp, the code itself? Yes? Bail.

Reading the manual, perusing the official docs, or digging through the source code usually takes longer than skimming an on-topic article or tutorial, but SEO-spammed articles often coalesce into an entire sea of local maxima. They tease you by scratching the surface of what you're looking for, but if your issue isn't the most common one, you can waste hours trudging through the garbage.

Sometimes, taking the time to go deep into the topic is the fastest (only?) way to find answers to the more esoteric questions.

Back to Jeffy

I don't want to leave you hanging on this story. As it turned out, the documentation for SQLC was complete, but it was tricky to understand how to use pointers for nullable columns if you landed on the wrong page. There are a lot of configuration options for SQLC, and it's easy to get lost.

I just cloned the repo, grepped for "pointer", and found the code that parsed the configuration option. It was clear after just a few minutes of reading the source that we just needed to do three things:

Specify the go_type we want (e.g. "string" instead of sql.NullString)
Set nullable: true
Set pointer: true

Here's the code:

overrides:
  - db_type: "text"
    nullable: true
    go_type:
      type: "string"
      pointer: true

Sometimes you gotta rtfm. Sometimes you gotta suck it up and grep the code.

btw, sqlc is awesome and if you like Go you should be aware of it.

Put that Framework Down Before Someone Gets Hurt

Lane Wagner — Tue, 07 Nov 2023 14:00:00 +0000

There is only one question that ignites my inner rage more than "How do I get a developer job in 3 months?"? That question is:

What web framework should I use?

It's not that I think frameworks are evil, scary, or even bad. I'm just bothered by the 'assumption that to build an online thing, you must start with a framework.

What do I mean by "framework"?

The JavaScript ecosystem has had its way with the definition of the term "web framework". The JS community seems to excel at keeping us from having nice things.

I like to define the terms "library" and "framework" as follows:

Library: Code that you import into your project.
Framework: A structure that you import your code into.

A framework provides nearly as much project lock-in as a programming language. If I choose to build my application in Next.js, it's impossible to move to SvelteKit without a rewrite.

A library is hot-swappable. If I use a library for database operations, and a new one comes out that seems to do a better job, only a small part of my application needs to be updated.

Hey Next.js devs, React is a framework. Neither Dan Abramov nor God himself can convince me that React is just a library. I understand that it can kinda be used as one, but no one does that.

And while we're at it, Express.js isn't a framework. It's just a routing library. (yes I know it says framework on the homepage, but see my preview comments about the JS ecosystem)

Put that hammer down

Story time. I was working at a company about 5 years ago where we were maintaining an ETL pipeline that processed anywhere from 100 to 1000 messages per second. There were some micro-services involved that did a bunch of different things. For example:

Translating messages from one language to another
Sorting the messages into categories based on keywords in the content
Sending alerts based on the aforementioned categories

One day I was tasked with figuring out why one of our services was choking at a mere 30 messages per second. This service was responsible for taking messages from a queue and placing them into different Postgres databases depending on which customer cared about the message. In theory, it was literally this simple:

Message comes in
If the customer_id on the message is in the map of customer_id -> database_url, then insert the message into the database at database_url

I hopped into the project and was immediately dismayed to learn it was a Ruby project. But not just a Ruby project, it was a Ruby on Rails project.

Look, I have no problem with Ruby on Rails. There are plenty of examples of companies that have made millions or even billions dollars on the back of Rails projects.

But this isn't a monolithic web application. This is a tiny service that's supposed to quickly dump messages into a Postgres database. Why do I need an HTTP router? Why do I need an auth library? Why do I need all the other junk?

I need two things:

A way to concurrently pull messages from a Rabbit queue
A way to insert messages into a database asynchronously

Go and JavaScript both have super easy and lightweight ways to accomplish this. I just need a few lines of code, and not much by way of dependencies. After a couple of hours poking through this Rails monstrosity (that for some reason also used Redis to track progress) I just wrote a single worker in Go, which took less than an hour, deployed the new service, tested it in production, and archived the Ruby project.

But could it have worked in Rails?

Yes. I'm sure that I could have just refactored that Rails project, found the hot paths, and optimized the performance bottlenecks. I mean, its unlikely that it was ever going to be as fast or as lightweight as a Go service, but the project was I/O bound so it could have been fine.

The point is that sometimes as software engineers we find a hammer that we really f---ing love. It's such a fun hammer! It's so ergonomic! So clean! And we're so good at wielding it! So, its natural that we go around swinging it at every goddamn nail we see.

It's a question of defaults

At Boot.dev we use Nuxt.js for our front-end UI. It's a great framework. But when I write a Discord Bot you won't catch me running nuxi init.

I'm not just saying:

"Use the right tool for the job"

Instead, I'm saying:

"Use the simplest tool for the job"

It's easy to add complexity as you need it to accomplish your goals. It's much harder to remove it.

Understanding Stacks: From Concept to Python Implementation

Lane Wagner — Sat, 07 Oct 2023 19:32:34 +0000

A stack is an abstract data type that serves as a collection of elements. The name "stack" originates from the analogy of items physically stacked on top of each other. Just like a stack of plates at a buffet, plates can be added, removed, and viewed from the top. However, plates further down are not immediately accessible.

A stack operates on a LIFO (last in, first out) principle. This means that the most recently added item will be the first to be removed.

Basic Stack Operations:

Push: stack.push(item) - Adds a new item on top of the stack
Pop: stack.pop() - Removes the top item from the stack
Peek: stack.peek() - Returns the top item without removing it
Size: stack.size() - Returns the number of items in the stack

When might you use a stack?

Let's take the and example from the world of game development.

When designing a weapon system in a video game, especially for weapons with magazines like a repeater crossbow, a stack can be an ideal choice for the underlying data structure. A magazine that holds arrows, for instance, would benefit from the LIFO principle: the last arrow loaded is the first one fired.

Here's the code:

class Magazine:
    def __init__(self):
        self.arrows = []

    def push(self, arrow):
        self.arrows.append(arrow)

    def pop(self):
        if not self.arrows:
            return None
        return self.arrows.pop()

    def peek(self):
        if not self.arrows:
            return None
        return self.arrows[-1]

    def size(self):
        return len(self.arrows)

You could then use the Magazine class:

magazine = Magazine()
magazine.push("Arrow 1")
magazine.push("Arrow 2")
magazine.push("Arrow 3")

print(magazine.peek()) # Arrow 3

print(magazine.pop()) # Arrow 3
print(magazine.pop()) # Arrow 2
print(magazine.pop()) # Arrow 1

Are stacks fast?

Stacks are fast. All operations are O(1), which means they take the same amount of time regardless of the size of the stack. Stack of 10 items? Stack of 10,000 items? It doesn't matter, pushing and popping will be blazingly fast.

Think about it: you can only add or remove from the top of the stack. You never have to iterate through the entire stack to find an item.

Now, to be fair, if for some reason you know that an item exists in a Stack, you can pop() until you find it. This would be O(n), but if that's a use case for you, you should probably be using a different data structure.

The Origin of "Stack Overflow"

While many developers are familiar with the website Stack Overflow, not everyone knows the term's origin. A programming language, such as Python, uses a stack data structure to manage function calls and their scope.

Consider this simple program:

def function_one():
    function_two()
    function_two()

def function_two():
    function_three()
    function_three()

def function_three():
    print("function three")

function_one()

Here, each function call is represented by a call frame in memory. When a function is invoked, a new frame is pushed onto the runtime stack. When the function completes its execution, its frame is popped off the stack.

The Dreaded Stack Overflow

A "stack overflow" refers to an error that occurs when the stack exceeds its capacity. The limit of this capacity varies based on numerous factors like the programming language and available memory. If a program surpasses this limit, the stack overflows, which often results in the program crashing. Python, however, takes measures to prevent the interpreter stack from growing excessively large, thereby averting a stack overflow. Instead, a runtime exception is raised.

Learn to Code the Slow Way

Lane Wagner — Mon, 11 Sep 2023 15:51:34 +0000

Ever since starting Boot.dev, I've been flooded with what I call "quicksand questions". On the surface, a quicksand question seems like a good question. If you could answer it, it would catapult you from where you are (nightshift at the Wendy's drive-in) to where you want to be (telling friends that you work at Netflix btw).

Quicksand questions are all about finding shortcuts.

I need a developer job in 3 months, what's the best way to do that?

I see you've laid out 20 courses in your backend learning path, but, *wink* which ones can I skip?

What's wrong with shortcuts?

Now, I want to be clear, there is absolutely nothing wrong with wanting to take a shorter path toward your career goal. Anything else would be insanity. If there was a pill to turn you into a senior developer overnight, I'd encourage you to pop that sucker.

In theory, educational min-maxing seems like a solid strategy, but in practice it just doesn't work.

Why? Because the destination is unknown.

Dijkstra's algorithm is great if you know where you're going. If you don't, you need something else.

No one knows where they're going

The tech scene is a clusterf*ck of complexity. I learned like 10 different programming languages in college, and even 3 years into my degree, I still didn't know that I'd end up working as a backend engineer writing Go.

I interviewed for all sorts of nonsense, from embedded systems to frontend development. Yeah, turns out that my Prolog class didn't help much in my first interview, but you know what? It didn't hurt, and now when someone says "it's a declarative system" my facial expression doesn't betray ignorance.

If you knew exactly which concepts you'd need to master to pass your first interview, then you could might be able to find an effective shortcut. The trouble is, there is no precise subset of knowledge that will always be enough to pass every possible first interview.

Every company has its own janky tech stack
Every PM has their own version of "agile"
Every hiring manager has their own 7-step interview process
Every job requires different bits of arcane knowledge

You have no idea what you'll be doing day to day at your first job when you're starting to learn to code. I hear people say things like "I never even use my DSA skills at work", and upon further inspection, it turns out they're a WordPress "developer".

So I shouldn't be interested in the shortest path?

You should, it's just not where you think you'll find it. The shortest path to a job as a programmer does not involve minimizing the amount of things you need to learn and build. That sort of thinking results in a much longer, more mentally exhausting journey. Something like this:

Jump directly into a web framework (probably Next.js since you're basic af)
Find you have a talent for building TODO apps
Realize you can't build "hello world" without a tutorial
Attempt to remedy that by doing more tutorials
Read on Twitter that ackshaully Rust is the best language
Admit defeat at the hands of the borrow checker
Repeat steps 1-4 n times, where n is a d4_roll * your_stubbornness

The shortest path (or at least short*er* path) usually looks like this:

Learn core programming/cs concepts in some language
Tentatively decide on the kind of programming you want to do (frontend, backend, mobile, etc)
Learn the fundamentals of that kind of programming in technologies well suited for it
Never stop learning and building while you search for a job

Don't get me wrong, this second path still isn't short. Programming isn't easy, sorry if you were told it was, but if you're willing to put in the effort you can avoid an aimless stroll through the 9th circle of tutorial hell.

Don't be scared of work

Folks spend eons trying to find the shortest learning path, or trying to avoid learning things that "they'll never use again". They're fine wasting months or years learning absolutely nothing to avoid doing any unnecessary work. Why not bite the bullet and risk spending a few days learning something that's not directly applicable to the job you'll eventually land?

Dogecoin to the mooon?

Let's be 100000000% honest. Some folks are looking for a good 'ol fasioned get rich quick scheme. After a few weeks of struggling with loops, they'll give up and purchase an AI-powered crypto trading bot on Fiverr. Don't be like those folks.

Becoming a software engineer is NOT a "get-rich-quick" scheme. It's a "get-upper-middle-class-slow" scheme

The trick to "making it"? You have to actually get good.

So, instead of copy/pasting haphazardly from StackOverflow to "fix" the next error you encounter, take the extra minutes to figure out what it means. I can't begin tell you how many PRs I've reviewed that "fix" something, but are just a patch of a patch because the dev never grokked the underlying problem.

For example, an ex-Java dev (it's always a Java dev) finds that sometimes this function (in Go) panics:

// sendEmail sends emails, but sometimes panics
func sendEmail(e *email) error {
  // ...
}

They go straight to Google and find that panicking in Go can be "solved" with a recover. So they open a pull request:

func sendEmail(e *email) error {
  defer func() {
    if r := recover(); r != nil {
      log.Println("recovered from panic in sendEmail")
    }
  }()

  // ...
}

This kinda works? But a better developer would try to understand and fix the underlying problem in the code. They would add nil checks, or just stop using pointers altogether for this function...

// now sendEmail never panics
func sendEmail(e email) error {
  // ...
}

You want to have a bias toward becoming better, not reaching the end. There isn't an "end", there's just too much out there to learn. The scope of all of software engineering is larger than the scope of your last program's global namespace.

It's not the advice you wanted

Getting fit, giving up addiction, building a business, and yes, getting your first dev job are all hard. Don't make it harder on yourself by wasting your time searching for shortcuts.

Learn evergreen foundational stuff, build projects that interest you, and you'll be amazed how far you can get in just a year or two of consistent effort.

Frontend? Gross. This Is Why I've Always Preferred the Backend

Lane Wagner — Mon, 10 Jul 2023 15:54:00 +0000

As a kid, I always wanted to be good at drawing. I practiced drawing my favorite anime characters, but frankly, my mom was the only one who thought they were good.

Fast forward roughly 18 years, and I'm a college graduate with a computer science degree looking for my first role. I had a part-time full-stack developer job in college, but I wanted to work at a larger company and specialize on one side of the stack for at least a few years. I built a few websites in college, and I found that I would spend roughly 50% of my time on the entire project just tweaking CSS.

The worst part?

The sites all looked like ass anyways.

My decision was made. I wanted to become a backend engineer. Let's talk about some of the other factors that impacted my decision.

I love building my own stuff, sans the UI

I hate UI design. You know, sitting for hours, tweaking bloody CSS classes, and the result? A site that makes most 90s GeoCities pages look like a Van Goph.

It was then I realized that I could just make the command line my best friend. When you build backend projects and CLI tools for developers, you never need to build a UI again. Developers prefer CLI tools!

It’s not about giving up, it’s just about recognizing where my strengths and preferences lie.

Building tools for developers makes you a better developer

If you think about it, everything you build as a backend developer will be used by other developers! That means you have a fantastic feedback loop where your peers and mentors are telling you how to hone your craft, every single day.

Building a REST API? Front-end devs use it.
Building a CLI tool? Other developers use it.
Architecting a database? Other back-end developers use it.
Choosing a backend technology? Other developers on the team will integrate with it.

And trust me, the feedback from other developers is rarely sugarcoated. There are no shit sandwiches.

They’ll tell you if your tool is a diamond in the rough or just plain rough. It's an opportunity to learn, improve, and ultimately, become a better developer.

My favorite question: "Is it possible?"

I've always been more invested in what can be done rather than how it looks. Function over form, at least from an engineering perspective.

Fancy buttons and interactive graphics are cool, but I'd rather geek out about:

Can we translate all these tweets into Japanese in real-time?
Can we reduce our cloud bill by 50% if we use this database?
Can we cut the page load time in half?
How can we architect our backend to simplify the code required for email, sms, discord, and in-app notifications?

Scalability and performance

I love thinking about scalability and performance. There’s just something so satisfying about planning, creating, and optimizing systems to make them perform better, handle more traffic, and grow as the business and use cases grow. It's so nice to work on something that can be measured concretely.

I reduced latency by 50%.
I improved throughput by 200%.
I reduced our cloud bill by 30%.
The system can now handle 10x the traffic.

You get the idea. It's easier to explain the value of your work when you can quantify it. It sounds more impressive to the boss than "I moved our vanilla CSS to Tailwind".

JavaScript kinda blows

Let's switch gears and talk about JavaScript.

It's unbelievably impressive that JavaScript has come as far as it has, you know, being the absolute cluster f*** of a language that it is. It's a dynamically typed nightmare with legacy baggage that's been bolted on over the years. There are ways to work with it that are less bad, but it's still bad.

At the moment Go is my language of choice. Static typing, fast compile times, a great standard library, and statically compiled binaries. It's a joy to work with.

The great thing about the backend is that you can kinda just pick your stack. Use whatever you want!

Like Go? Use it.
Love Python? Use it.
Enjoy the borrow checker? Rewrite your backend in Rust.
Like Java? You're wrong, but use it.

Higher pay

And now, let’s talk about the elephant in the room: money. Moolah. Cheddar. Greenbacks. Benjamins.

Let’s face it, we all have bills to pay and I'm not ashamed to admit that I like money. So yeah, the pay advantage of backend engineers played a role in my decision.

According to 2023 Stack Overflow:

Backend developers in the US: $165,000
Frontend developers in the US: $140,000

You do you

I can confidently say that my preference for backend development is not just a passing fancy. It’s a career choice driven by curiosity, passion, and yes, practicality.

But remember, this is my journey. Your preferences in programming might be in creating sleek, dynamic web interfaces, or in developing the next big mobile app experience. And that's okay!

In the end, finding joy in what you do, whether it's frontend, backend, game dev, or something in between will probably be the best predictor of your personal success. Good luck out there.

Build Your First Coding Project and Avoid Tutorial Hell

Lane Wagner — Wed, 05 Jul 2023 13:47:00 +0000

While "real" hell may or may not exist (no need to get into religious beliefs here), tutorial hell is very real.

My definition of tutorial hell goes something like this:

Tutorial hell is where you write code that others are explaining to you how to write, but you don't understand how to write it yourself when given a blank slate.

At some point, it's time to take the training wheels off and build something on your own.

When is it time to build your own project?

At Boot.dev, students write their first non-tutorial project after completing the following modules:

Learn Python (course)
Learn OOP (course)
Build a Python CLI (project)
Learn Algorithms (course)
Learn Data Structures (course)
Build a Maze Solver (project)
Personal Project 1 (when they build their first fully custom project)

Now, keep in mind that Boot.dev students are hands-on-keyboard 100% of the time. I'm not saying you should watch 40 hours of video before building anything, but I am saying you should have a solid understanding of coding fundamentals before building your own idea. You should learn those fundamentals by writing code, but it's best if the projects and challenges you're working on are guided so that you can focus more on learning the concepts and less on figuring out what to build.

What's the goal of your first project?

Your goal here is not to build something that makes money, or even to build something that will make its way onto your resume.

The goal of this first project is simply to get you used to the process of building something from scratch. You just need to get some practice breaking down a project into smaller pieces. You need to experience that first breath of fresh air as you emerge from the depths of tutorial hell for the first time.

What are some good requirements for your first project?

Try to spend 20-40 hours on this project.
Use a programming language you're already familiar with.
Commit your code to Git often, and push it up to Github.
Create a README.md file for your project. It should explain to readers:
- What the project is, and what it does
- How to clone and run it
It's okay for (I'd even encourage) you to use third-party libraries! That said, make sure that some of the code that you write is doing something interesting. You don't want a razor-thin wrapper around a third-party library to be the only thing you've written.

But what should I build?

The whole point of a personal project is that it's personal. The idea needs to be yours. Even if the project you build is simple for now, at least it's yours.

Build something that you find interesting.

This probably isn't a project that will make its way onto your portfolio or resume, but it's still good to get into the habit of building things that are interesting and useful. Interesting and useful projects have many benefits:

They're more fun to work on
They have more interesting and difficult problems to solve
You (or someone else) might actually use them
They're more likely to grab the attention of other people
Attention from other people can lead to career opportunities

Use a programming language that you're already at least somewhat familiar with. Assuming you haven't been writing a ton of code outside of Boot.dev, your project should probably be a Python program that runs on the command line. That's fine!

I want to provide a few ideas to get your creative juices flowing, but please don't choose a project from this list without at least putting your own spin on it

A text-based adventure game in the terminal
A CLI tool to detect the strength of a password, or to validate it
Tic-Tac-Toe in a tkinter GUI
A tool that creates ASCII art from an image
A command line tool to view Reddit feeds in the terminal
A command line tool that parses a CSV file of pokemon data and lets you search for pokemon by name, type, etc.

But, but, but... I don't know how to build "X"!

Your job as a developer is to constantly build stuff that you've never built before. Don't shy away from an idea because you're not sure where to start. Google it. Ask ChatGPT. Ask the Discord community. You might need to put in an hour of research before starting to decide if your idea is feasible within a 40-hour time frame, but that's fine!

Assuming that you'll be doing something you've never done before! You have some fundamentals under your belt. Now it's time to piece it all together and research as you go.

You'll need help

You're going to get stuck. If you don't get stuck, you probably chose an idea that's way too easy.

The trick is developing a skillset for getting unstuck. This is a skill that will serve you well (and is absolutely necessary) in your career as a developer.

Get used to Googling

Start with Google. Do some research on your idea. See what others have done when building similar projects. See if there are any libraries you can install to make your life easier.

Use ChatGPT

Talking through your issues with ChatGPT (rubber duck debugging) can be a great way to get unstuck.

Don't have ChatGPT write your code for you! You won't learn that way, and you'll be dreadfully slow if you get stuck in that habit. Instead, use ChatGPT to help you think through your problems, and ask it to try to find bugs in your code or explain code snippets you don't understand.

Keep in mind that ChatGPT can be confidently wrong, so don't take its word as law. Use it to get back on track, but verify the information it feeds you with other sources.

Use Discord

Ask questions in the Boot.dev Discord server, especially if you're a current student (but you're welcome either way)! As with all question-asking, provide as much context as you can so that when your fellow students and mentors help they can efficiently provide you with the information you need.

Publish and share

Get your project out into the world! Again, the purpose of your first-ever personal coding project probably shouldn't be to build something amazing for your resume. That said, I still think you should put enough love into it that you're not ashamed to make it public on your GitHub profile and share it with other devs you know. Get some feedback, ask for code reviews, and you can always iterate on it later and improve it as your skills improve.

Awww, do I Really Need to Learn X to Get a Job as a Developer?

Lane Wagner — Mon, 26 Jun 2023 14:20:00 +0000

A developer's life is a never-ending saga of learning new things. It's like you're playing Diablo where every new Jira ticket can feel like the next mini boss to slay. Exciting? Absolutely. Scary? Sure. Especially at first.

Why do we resist learning new things?

We're creatures of comfort. We like what we know, and the unknown can be as intimidating as a null dereference in prod. But here's the deal: the software development industry moves fast and there's a near-infinite amount of stuff to learn. This isn't mechanical engineering. We have 3 new JavaScript frameworks per day people.

Imagine this. You're squaring off against another candidate for a job, and you both are qualified in that you check all the boxes in the listed job requirements (I know, super unrealistic). The only difference between you two? They know a heckofa lot more about the non-essential stuff than you do.

Who do you think the employer will choose?

The necessity vs curiosity dilemma

Now, I'm not saying you should learn every design pattern, language or tool that comes onto the scene. What you need is a balance between necessity and curiosity.

Before you panic about not knowing the ins and outs of Kubernetes or TensorFlow, remember this: you don't need to learn everything before getting a job. Real growth happens on the job, through tackling real problems, not hypothetical ones.

But if you want to stand out in this vast sea of developers, a spark of intellectual curiosity can be your purple cow. Go ahead and explore an interesting algorithm, RTFM when you're working with a new library, or take a minute to watch FireShip's latest video about that language you've been eyeing. You might be surprised by the doors it can open.

Increasing your "starting point"

Learning isn't about hoarding answers like Scrat hoards that acorn. It's about pushing the boundary of your ignorance a little further with each passing day. I like to call this your "starting point".

Think back to when you first started coding. You probably spent a lot of time googling basics like "how to write a for loop" or "what's a git branch?" (We've all been there, no shame.) But as you learn and grow, your starting point moves ahead. Now, you're probably googling something like "how to specify a PUT endpoint in the go-CHI library" or "best practices for asynchronous error handling in Node.js".

See the difference? Your journey from 'for loops' to 'PUT endpoints' is a testament to your growth, and each new concept or tool you learn pushes your starting point even further. You'll never be done Googling or asking Chat GPT, but you'll be able to tackle more complex problems more efficiently with each passing day.

Take the scenic route

Learning to code isn't part of the problem set solved by Dijkstra's shortest-path algorithm. You don't need to find the shortest path to success. Taking the scenic route isn't just okay, it's better in the long run and can be good for your career.

Dare to venture off the beaten path. Those side quests where you learn a random library because it looked cool, or spend a weekend building a game in a language you just stumbled upon, can do wonders for your skillset. Even if you never go on to use those tools again, you'll have learned a new way of thinking about problems, and that's invaluable.

Each time you solve a new problem, or the same problem in a new way, you add flavor to your developer identity. Plus, that random knowledge often magically pops up in interviews and projects.

Moving forward, not sideways

Now, while I encourage you to embrace deviations, it's crucial not to lose sight of your core learning path (If you're a Boot.dev student, it's probably this backend learning path).

You don't want to end up in tutorial hell.

Ah, tutorial hell. The Bermuda Triangle of coding, where you're lost in a sea of online courses and YouTube tutorials, endlessly copy-pasting code without truly understanding anything. The only way out of tutorial hell is to continuously progress along a learning path so you can make sure that you're actually learning new, important things.

Well, that and you need to actually build something. Lots of somethings. Lots of somethings where each step isn't spelled out for you.

Embrace learning, embrace growth

As developers, we're not just coders—we're lifelong learners. It's part of the job description, like being able to survive grueling Scrum meetings.

So, don't shirk from learning new things. Embrace it. The fear, the excitement, the occasional frustration, it's all part of the package. And remember, you're not running away from learning. You're just taking a consistent jog towards success.

JavaScript? Python? Go? Which Tech Stack Should You Learn?

Lane Wagner — Tue, 25 Apr 2023 14:51:00 +0000

Ah, the age-old question: which tech stack should I learn? Aspiring developers often get bogged down in this dilemma, and it's not hard to see why. The tech industry is an ocean of opportunities, and the fear of diving into the wrong waters can be paralyzing.

But here's a little secret for you: it's more important to be insatiably curious and willing to learn new things than to stress over learning exactly the right things.

"Don't try to minmax your programming education"

-- Paraphrased from ThePrimeagen

It doesn't matter much. There are jobs in every stack

There are jobs in every tech stack. From popular ones like JavaScript, Python, and Ruby to newer languages like Go, Elixir, or Rust, there's a market for each of them.

Take JavaScript, for example. It's the go-to language for front-end development, and Node.js has made it incredibly versatile on the back-end too. With the rise of serverless architectures and the popularity of React and Angular, JavaScript devs are in high demand.

But what if you're more into Python? No problem! Python is not only the darling of data scientists and machine learning engineers but also a solid choice for web development with frameworks like Django and Flask.

The point is: whatever tech stack you choose, there's a job out there for you if you know what you're doing.

Total number of jobs doesn't matter, you only need one

Let's say you're a Golang aficionado, but you're worried because there aren't as many Go jobs as there are for JavaScript. Well, remember this: you only need to land one job.

Instead of fretting over the total number of available jobs, focus on finding the right fit for your skills and passions. After all, the perfect job in a smaller market is better than being miserable in a sea of JavaScript gigs. I actually wrote an entire article about how the ratio of openings/developers is a much more important consideration than the total number of jobs.

You'll fail because you give up and stop learning, not because your tech stack is unpopular

The tech industry rewards adaptability and growth. Technologies come and go, but the core skills and mindset of a developer persist. Expect to be constantly learning new programming languages, frameworks, and tools throughout your career.

In fact, dabbling in multiple languages and frameworks can make you a more well-rounded and versatile developer. By exposing yourself to different ways of thinking and solving problems, you'll develop a more comprehensive understanding of programming concepts.

I've seen hundreds of learners fail in their journey to become developers because they gave up and stopped learning. I've never seen a single person fail because they started with the wrong stack.

Anything will work, but some choices are better than others

Alright, so we've established that you can find a job in any tech stack, but does that mean all choices are equally good? Not quite.

When choosing a tech stack, there are factors to consider that can impact your career development. Let's dive into a few key things to keep in mind.

Try to learn something that has jobs in your area

Before picking a tech stack, do some research on local job markets and industry trends. Find out which languages and frameworks are in high demand in your area, and which ones are on the rise.

Working with a tech stack that has a strong community and support network can help you stay up-to-date and make it easier to find jobs or freelance gigs. I've also found that for junior developers it's typically easier to land a job in your local area than to find a remote gig. That's not a hard and fast rule, but it's something to keep in mind.

Choose a tech stack that you enjoy

Remember: your tech stack choice should align with your personal interests and career goals.

If you're passionate about data science and machine learning, Python might be a better choice for you than PHP
If you're interested in cloud-native back-end development, I'd certainly recommend Golang.
f you're all about building sleek and interactive web apps, JavaScript and its various frameworks could be right up your alley

Don't be afraid to learn technologies that you won't use at work

To become a well-rounded developer, there are a slew of concepts that are important to learn. When designing the learning path on Boot.dev, I'm not only interested in teaching students a cluster of technologies, I'm focused on getting those concepts to stick. As it turns out, some languages and frameworks are better at teaching certain concepts than others.

For example, if you're working to become a back-end developer, here are some of the important concepts:

Don't worry, you can always learn more

Once you've learned one programming language, picking up another one becomes way easier. I'm talking like 80+% easier. Most new developers don't realize this, but it's why you don't need to stress over the perfect first language.

Programming languages may have different syntax and nuances, but the underlying concepts remain consistent. Once you've got the fundamentals down, learning a new language or framework becomes more about understanding the specific quirks and less about grappling with entirely new ideas. Binary trees, encapsulation, and function closures are all pretty universal concepts, you'll never need to re-learn them.

Let me give you an example: if you're proficient in Python and decide to learn JavaScript, you'll find that many of the core programming concepts, like loops, conditionals, and functions, are pretty similar. JavaScript has its quirks (looking at you, this keyword), but you'll be surprised at how quickly you can pick it up.

Go forth. Embrace the challenges, learn from setbacks, and above all, never stop being curious. The most successful developers I've met never ask "Do I really need to learn X?" They say "X looks exciting! I'm going to build something with it."

Which is More Important: Hard or Soft Skills for Programmers?

Lane Wagner — Mon, 24 Apr 2023 14:02:00 +0000

You're waiting at the front-desk of Google's campus in Boulder, Colorado, waiting for your coding interview to start. Across from you in the lobby sit two other candidates:

A charismatic airpods-flaunting developer who can charm the pants off of anyone in the room but requires an agonizing 8 hours to get a linked list working
A programming prodigy who writes games in assembly, but is such a colossal jerk that nobody will play their game anyways

Which of them will provide more fierce competition for the job spot? Let's tackle the age-old question: Which is more important, hard or soft skills for programmers?

First I'll annoyingly explain what hard and soft skills are, but then we'll dive into the reason I wanted to write this article: the rectangle analogy. This analogy will help you understand where you should be spending your time improving to maximize your chances of landing a job.

Hard Skills: The Foundation

First things first: what are hard skills? These are the tangible, measurable abilities that you need to get the job done. As a developer, you'll need to:

Code in specific languages - like Python, JavaScript, or Golang.
Use technologies and tools - such as Git, Docker, or AWS.
Understand algorithms and data structures - because nobody wants to be that developer who can't reverse a string without Googling it first.
A boatload of other things - because programming is a vast and ever-expanding field.

Importance of hard skills for landing a job

Hard skills are the bread and butter of your programming career. They're an absolute requirement for most programming positions, and they demonstrate your technical competency. In fact, if you could only have one type of skill, hard skills would be more important. After all, it's pretty tough to write code without, you know, actually knowing how to code.

Keep hardening your hard skills

The tech world moves at breakneck speed, and if you're not continuously leveling up your hard skills, you're gonna get left in the dust. Remember, Rome wasn't built in a day, and neither is your programming expertise. Invest time and effort in learning new languages, tools, and techniques over time.

You don't need to be an expert on everything, but you need to know how to deliver working code that solves real problems within your domain. If you want to be a back-end developer and work at SaaS companies, then you should at the very least:

Have a solid understanding of a couple of programming languages like Python and Go
Be able to set up and use a SQL database
Know how to build a REST API using those technologies
Know how to deploy that API to a cloud platform like AWS or GCP

Soft Skills

Soft skills, on the other hand, are the intangible, interpersonal abilities that can give your career a nice boots. They might not be as easy to quantify as hard skills but they're nearly as vital. Soft skills include:

Charisma - people like working with fun people.
Communication and writing abilities - so you can articulate your ideas and keep everyone in the loop.
Kindness and empathy - because you're working with humans, and humans don't like assholes.
Hard work and follow-through - if you're good, but you don't deliver, then no one cares.

Importance of soft skills for long-term success

Soft skills are the secret sauce that can propel your career to new heights. They facilitate collaboration and teamwork, making it easier for you to work with others and get the job done. Plus, having solid soft skills can enhance your overall job satisfaction and career growth. After all, nobody wants to work with a genius who's also a jerk.

Hard skills are a requirement to get a job in tech, but assuming the gap in hard skills between two candidates is similar, I've actually seen the more charismatic and likable candidate get the job over the slightly more technically competent one. Why? Managers are people, and people like working with other people they like.

How do I improve my soft skills?

If you have a crappy personality, don't worry too much. You don't need to be a brilliant orator or a master of the written word just to get a job as a code monkey. The number one rule should be easy to follow: don't be an asshole. If you do that, you're halfway there.

The related follow-up rule is to balance confidence and humility. If you're a kind, open-minded developer that knows what you're talking about, you'll do great.

The Rectangle Analogy: Combining Hard and Soft Skills

Now that we've explored both hard and soft skills, let's dive into the rectangle analogy to understand how they work together. Imagine your hard skills are the length of a rectangle, while your soft skills represent the width. The area of this rectangle corresponds to your probability of landing a job. The larger the area, the better your chances of finding a gig that suits your skillset.

This means the equation for your job probability is:

hard_skills * soft_skills = job_probability

To maximize job_probability with the least amount of effort, spend more time on whichever skill you tend to lack. The area of a square is larger than the area of a lopsided rectangle with the same perimeter.

The misconception of limited skill points

If you're thinking this sounds a bit like a Dungeons & Dragons character sheet where you have a limited number of skill points to allocate, that's not how the real world works. In the real world, you can just get more skill points. You can excel in both hard and soft skills.

I've worked with amazing people who are easy to get along with and are brilliant programmers
I've also worked with incompetent jerks who are somehow also bad at writing code

If you work hard and do your best, you can be both a great programmer and a great person. It's not an either-or situation. In the immortal words of Shia LaBeouf, "Just do it!"

As a Developer, What Hardware Do You Truly Need?

Lane Wagner — Fri, 21 Apr 2023 14:37:53 +0000

Let's be real here: we live in an age where everyone and their dog seems to think they need the latest, most expensive gadgets to get anything done. But when it comes to learning how to code, do you really need that shiny, wallet-draining powerhouse of a machine?

Nope.

Let's chat about the hardware you need to get started with coding, and dispel the myth that you need to spend a fortune on your setup like a Macbook-toting soydev.

Memory: The real MVP

RAM (Random Access Memory) is where it's at, and this is where you're not going to want to cheap out. If you're not familiar with what RAM does, let me give you the lowdown.

RAM is the temporary storage your computer uses to maintain the data it needs to run apps. More RAM means you can run more apps simultaneously, which is super important when you're coding, because you'll likely have a bunch of programs open at once. For example:

Text editor
Web browser with 50+ tabs (guilty!)
Terminal
Slack
Discord
Spotify

Opening files: When you open a file, the data is loaded into RAM, so having more of it means you can open larger files without your machine choking.

Compiling code: Compiling is the process of turning your code into an executable program. This can be a memory-intensive operation, especially for larger projects. More RAM helps speed up the process.

For most use cases, you probably won't want less than 4GB of RAM. There isn't a true minimum, because, depending on the programs you use, you can get away with quite little, but if you can get 8 you'll be in a good place, and 16+ will feel like a dream.

CPU: Nothing too wild

The CPU (Central Processing Unit) is the brain of your computer, executing instructions and performing calculations.

It might seem counter-intuitive, but a powerful CPU isn't always necessary for coding. As long as your editors and day-to-day apps aren't lagging, you're going to be fine. Remember, a good CPU won't make the programs you write any faster. You need great hardware for running in production, but not necessarily for development.

So, while a good CPU can certainly help, you don't need the latest, most powerful CPU to get started. A mid-range processor from the last few years should be more than enough for most coding tasks.

Hard Drive: SSDs slap hard

You'll just save so much time when you start up your computer and load applications if you have a solid-state drive (SSD). SSDs are faster than traditional magnetic (spinning disk) hard drives, and they're also more reliable.

You don't need one, but you'll be much more productive if you have one. As far as storage space goes, I would hesitate to ever go below 256 GB, just because you'll probably have a lot of apps and data on your local device. That said, if you can get a full TB of storage you'll be in a fantastic place.

GPU: Nice, but far from necessary

The GPU (Graphics Processing Unit) is another piece of hardware you might be curious about. But unlike RAM, a powerful GPU isn't always necessary for coding.

The GPU is responsible for rendering images, animations, and other visual elements on your screen. While it's critical for tasks like gaming and video editing, coding web apps usually doesn't require much GPU horsepower. That said, here are some tasks that do:

Machine learning: If you're diving into the world of AI and machine learning, a beefy GPU is your best friend. It'll help you train models faster, allowing you to iterate and improve your algorithms more quickly.
Game development: If you're creating the next gaming masterpiece, a solid GPU will help you render graphics, run game engines, and test your creations in real-time.
3D rendering: For 3D modeling or animation, a powerful GPU will make your life a lot easier by speeding up rendering times.

Peripherals: Keyboards, mice, and monitors

A comfortable keyboard and mouse can make a big difference in your coding experience, but if you're just getting started you probably won't have a strong opinion about what you like yet. You can get started with super cheap stuff and it probably won't hinder your productivity very much. Later on, as you understand your own workflow and preferences, you can invest in a different mouse/keyboard combo.

As far as monitors go, I would never recommend working with a screen less than 1080p. If you can get a 1440p or 4K monitor, you'll be in a great place. But again, you don't need a fancy monitor to get started. I know "10x" devs that work with 1, 2, or even 4 monitors, but the truth is you won't know what works best for you until you've been coding for a while. I'd start with a simple single monitor setup, and only make changes if you feel like you need to.

Using lightweight apps

Now that we've covered the core hardware components, let's talk about the software side of things. Choosing the right tools for coding can make a huge difference in terms of hardware requirements and overall efficiency.

Vim (or NeoVim) is a prime example of a lightweight tool that doesn't require much in terms of hardware. It's a text editor with a small memory footprint, making it ideal for coding on less powerful machines. But Vim is just one example—there are plenty of other lightweight tools out there, each catering to different programming languages and tasks.

Lightweight tools put less strain on your system, so you'll experience fewer slowdowns and crashes, even if your hardware isn't top-of-the-line. Since lightweight tools use fewer resources, they generally load and run faster, which means you can write, test, and debug your code more quickly. Generally speaking, if you're happy and efficient using the lighter-weight stuff, there's no reason not to use it.

Using bloatware

In contrast to lightweight tools, heavier apps like Electron and full-fledged IDEs (Integrated Development Environments) like Visual Studio can consume a lot more resources. These tools typically offer more features and integrations, which can be helpful for development but also require more memory and processing power. They may also include graphical interfaces and other fancy visual elements, which can further bloat their resource usage.

Generally speaking, I'd stay as far away as you can from the truly heavy apps like Visual Studio, Android Studio, and XCode. If it takes 30+ seconds to start up, it's just not going to be fun to work with. Of course, sometimes you can't escape depending on what you're trying to accomplish, but if you can avoid it, do.

Electron apps are essentially just more browser windows. They work by running web technologies (HTML, CSS, and JavaScript) inside a sandboxed browser. They're certainly not as efficient as command-line tools like Vim, but they're often not as bad as some of the bloaty IDEs listed above. As long as you aren't opening too many of them, and as long as you have a decent amount of RAM, you'll probably be okay.

Final thoughts

Memory (RAM) is crucial for running applications, opening files, and compiling code. Aim for at least 8GB, but 16 GB is even better.
A mid-range CPU should be sufficient, but if you have the budget, this isn't a bad place to spend it.
An SSD somewhere between 256-1024 GBs will put you in a great spot.
A great GPU is only important for specific tasks like machine learning, game development, or 3D rendering.
In terms of performance: command line tools > Electron apps > IDEs.
If you don't know what you like, start with cheap peripherals and a single 1080p monitor. You can always upgrade later.

The bottom line is that learning to code is possible with a wide range of hardware configurations. It's not about having the most expensive, high-powered machine—it's about understanding what you actually need for the tasks you'll be working on and finding the tools that best suit your needs and budget. At the end of the day, you can realistically learn to code on a Raspberry Pi; you just might have to be a little more patient.

Don't let hardware be a barrier to entry. Dive into some code, explore your options, and remember that the most important tool in your arsenal is your own determination and curiosity. As they say, necessity is the mother of invention, so let your passion for coding be the driving force behind your success, not the latest shiny gadgets.

Do You Need to Blog to Get a Coding Job?

Lane Wagner — Mon, 17 Apr 2023 14:28:36 +0000

As the founder of Boot.dev, I've worked with countless students who are eager to break into the tech industry. And time and time again, I see the same question pop up: "Do I need to start a blog to get a coding job?"

It's a valid question. There's a lot of buzz around personal branding and the importance of building an online presence. But as someone who worked (and I guess still works) as a hiring manager, I can tell you that blogs are mostly overrated.

Let's break down the pros and cons of blogging as a developer. I'll share my own experiences and insights, and offer some practical tips for those who do choose to start a blog. So if you're wondering whether or not you need to blog to get a coding job, keep reading.

You don't need to blog, you should only do it if you enjoy it

Let's start with the most important point: you don't need to start a blog to get a job as a developer. I was the only developer at my last company of roughly 100 engineers that had a blog.

A blog can certainly help you stand out in a crowded job market, as it has for me, it's absolutely not a requirement. Your skills, experience, and ability to solve problems are ultimately what will get you hired. If you're not interested in blogging or don't enjoy writing, then there's no need to force yourself to do it.

Blogging will only help land jobs if you write bangers

Assuming you do decide to start a blog, it's important to note that not all blog posts are created equal. For a blog to ackchyually help your job search, you need to write amazing content that showcases your expertise and adds new value to your readers.

Regurgitating information that can be found elsewhere on the inter-webs net won't do you any favors. Your blog posts need to be original, well-written, and packed with insights that can't be found elsewhere. If you're going to invest time and effort into creating a blog, make sure that you're creating content that's truly worth reading.

If you're going to start a blog, write content that slaps. Don't waste your time and energy on mediocre stuff that won't get you noticed.

Write your story

If you're gonna write a blog post, make it yours. No one else should be able to write it better than you. Anyone can explain how a binary tree works for the 42,690th time. But what makes a great blog post is when you share your own experiences and insights.

If you've worked on a niche problem that you're particularly proud of, write about it. If you have a story about how you or your team overcame a unique challenge, write about it. If you've learned something new or personally changed your mind about something, write about it.

Tech influencers overestimate the importance of a personal brand

If you spend any time on Twitter or LinkedIn, you've probably seen countless posts from tech-fluencers talking about the importance of building a personal brand. While a personal brand has value in some scenarios, influencers drastically overestimate the importance of a personal brand when it comes to getting your first job as a developer.

Vanishingly few real-world (non-twitter) developers have a personal brand. Of the hundreds I've worked with personally, I can count on one hand the number that have a large following online, and that hasn't prevented them from finding success in their careers.

At the end of the day, what matters is your ability to solve problems, create value for your employer, and prove that you can do so in an interview. If you can tangibly demonstrate those skills, you'll be in good shape. I think these are much better ways to stand out:

A good portfolio of GitHub projects
Solid open-source contributions
Networking with other developers at meetups in online communities

Don't let the hype around personal branding make you feel like you're not doing enough if you don't have a large following on social media. Focus on building skills in order to write amazing code that solves real-world problems. The rest will follow.

Learning to write is a valuable communication skill

Personal branding nonsense aside, I do believe that writing a blog to clarify your thoughts and improve your communication skills is a valuable endeavor.

Being able to communicate your ideas clearly and concisely in written form can make a big difference in your ability to collaborate with teammates and work on projects effectively. In today's world of Slack, Discord, and other asynchronous communication mediums, being able to articulate your thoughts in writing is a necessity.

Should you blog? Meh. Only do it if you like it.

So, do you need to blog to get a coding job? Nope. A blog might help if you write some bangers that skyrocket to the top of Hacker News, but if your posts are fairly average, they probably won't move the needle. Your skills, experience, and ability to solve problems are ultimately what will get you hired.

All that said, learning to write effectively is still an immensely valuable skill for any developer. Being able to communicate your ideas clearly and concisely in written form can make a big difference in your ability to collaborate with teammates and work on projects effectively. So, if you enjoy writing, I'd encourage you to write to be a great writer and to write useful things, not to be an "influencer".

Don't stress too much about building a personal brand or starting a blog. Focus on building real skills and creating value through code, and the rest will follow. If you do decide to start a blog, make sure that you're writing articles that slap.