DEV Community: Boot.dev

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.

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.

Complete Python Tutorial for Absolute Beginners in 2023

Lane Wagner — Tue, 04 Apr 2023 12:45:00 +0000

Python is an unbelievably powerful programming language that is used by millions of developers in production systems around the world. It's easy to learn, free to use, and has a huge community of developers that are always willing to help.

If you're interested in back-end web development, data science, data engineering, or just want to automate some of your boring tasks, Python is a great place to start.

Would you rather learn by doing?

I've included all the static read-only material you'll need here in this tutorial, but if you would like a more hands-on experience, you can take the interactive version of this course, complete with coding challenges and projects on Boot.dev here.

Chapter 1: Introduction

Thousands of students start their coding journey right here with Python. We think it's the best programming language to get started with. Python is famous for being a simple language that's easy to read and write.

However, just because it's simple that doesn't mean it's not useful! Python is an extremely popular language in the industry, and is well-known for:

Backend web servers
DevOps and cloud engineering
Machine learning
Scripting and automation
etc...

On the other hand, it's not particularly well-known for front-end work. While it's possible to do so, Python isn't typically used to build visual user interfaces.

Setup a Local Development Environment

To get started with Python, you'll need to install the python command on your computer, and then install a text editor or IDE. If you're not already familiar with how to do that, I have a full step-by-step project guide here that you can follow.

If you're able to edit and run Python code on your computer, you're ready to continue!

What is "Code"?

Code is just a series of instructions that computers can follow. Computers obey each instruction, one after another.

Programs can be comprised of many instructions. Like many. Like millions.

Addition is one of the most common instructions in coding.

Printing numbers

print() can print text using quotes:

print("some text here")

but it can also print numbers without quotes:

print(1)

and you can do math directly inside the parentheses:

print(1 + 2)

Try some of these code snippets in your editor! For example, you could create a file called hello.py and write the following code:

print("Hello, world!")
print(1 + 2)

Then, run the file with python hello.py and see what happens.

Multiple Instructions

Code runs in order, starting at the top of the program. For example:

print("this prints first")
print("this prints second")
print("this prints last")

Syntax Errors

Syntax is jargon for "valid code that the computer can understand". For example,

prnt("hello world")

is invalid syntax because prnt() is not a valid function, "print" is spelled incorrectly. As a result, an error will be thrown and the code won't execute.

Syntax varies from langauge to language

A coding language's syntax makes up the rules that define what properly structured expressions and statements look like in that language. For example, in Python, the following would be considered correct syntax:

print("hello world")

While in a different programming language, like Go, the correct syntax would be:

fmt.Println("hello world")

Code can have many different problems that prevent it from working as intended. Some examples include:

A bug in the logic. For example, a program that should add numbers multiplies them instead
A problem with speed. A program that calculates how to play the perfect game of chess might never be able to finish because it requires too many calculations.
A problem with syntax. This is the most common problem for new developers. Luckily the Python interpreter will try to give you a descriptive error message in the console to help you find the problem.

Chapter 2: Variables

Variables are how we store data in our program. So far we've been directly printing data by passing it directly into the print() function.

Now we are going to learn to save the data in variables so we can use and change it before we need to print it.

A variable is a name that we define that will point to some data. For example, I could define a new variable called my_height and set its value to 100. I could also define a variable called my_name and set it equal to "Lane".

Creating variables

To create a new variable in Python we use the following syntax:

my_new_variable_two = 2
this_can_be_called_anything = 3

Variables Vary

Variables are called "variables" because they can hold any value and that value can change (it varies).

For example, the following will print 20:

acceleration = 10
acceleration = 20
print(acceleration)

The line acceleration = 20 reassigns the value of acceleration to 20. It overwrites whatever was being held in the acceleration variable before.

Let's do some math

Now that we know how to store and change the value of variables let's do some math!

Here are some examples of common mathematical operators in Python syntax.

sum = a + b
difference = a - b
product = a * b
quotient = a / b

Comments

Comments don't run like code, they are ignored by the computer. Comments are useful for adding reminders or explaining what a piece of code does in plain English.

Single line comment

# speed is a variable describing how fast your player moves
speed = 2

Multi-line comments (aka docstrings)

You can use triple quotes to start and end multi-line comments as well:

"""
    the code found below 
    will print 'Hello, World!' to the console
"""
print('Hello, World!')

This is useful if you don't want to add the # to the start of each line when writing paragraphs of comments.

Variable Names

Variable names can't have spaces, they're continuous strings of characters.

In Python you should use "snake_case" when creating variable names - it's become the "rule of thumb" for the language. By way of comparison, "camel case" is where the beginning of each new word except the first is capitalized.

No casing (pure insanity)

somevariablehere = 10

Camel Case

someVariableHere = 10

Snake Case

some_variable_here = 10

Basic Variable Types

In Python there are several basic data types.

String Type

"Strings" are raw text in coding speak. They are called "strings" because they are a list of characters strung together. Strings are declared in Python by using single quotes or double quotes. That said, for consistency's sake, we prefer double quotes.

name_with_single_quotes = 'boot.dev'
name_with_double_quotes = "boot.dev"

Numeric Types

Numbers aren't surrounded by quotes when created, but they can have decimals and negative signs.

Integers are numbers without a decimal

x = 5
y = -5

A "Float" is a number with a decimal

x = 5.2
y = -5.2

Boolean Type

A "Boolean" (or "bool") is a type that can only have one of two values: True or False. As you may have heard computers really only use 1's and 0's. These 1's and 0's are just Boolean values.

0 = False
1 = True

is_tall = True

NoneType Variables

Not all variables have a value. We can declare an "empty" variable by setting it to None.

empty = None

The value of empty in this instance is None until we use the assignment operator, =, to give it a value.

None is NOT a specific string

Note that the None type is not the same as a string with a value of "None":

my_none = None # this is a None-type
my_none = "None" # this is a string

Dynamic Typing

Python is dynamically typed. All this means is that a variable can store any type, and that type can change.

For example, if I make a number variable, I can later change that variable to a string:

This is valid:

speed = 5
speed = "five"

Just because you can doesn't mean you should!

In almost all circumstances, it's a bad idea to change the type of a variable. The "proper" thing to do is to just create a new one. For example:

speed = 5
speed_description = "five"

What if it weren't dynamically typed?

Statically typed languages like Go (which you'll learn in a later course) are statically typed instead of dynamically typed. In a statically typed language, if you try to assign a value to a variable of the wrong type, an error would crash the program.

If Python were statically-typed, the first example from before would crash on the second line, speed = "five". The computer would give an error along the lines of you can't assign a string value ("five") to a number variable (speed)

Math With Strings

Most of the math operators we went over earlier don't work with strings, aside from the + addition operator. When working with strings the + operator performs a "concatenation".

"Concatenation" is a fancy word that means the joining of two strings.

first_name = "Lane "
last_name = "Wagner"
full_name = first_name + last_name

full_name now holds the value "Lane Wagner".

Notice the extra space at the end of "Lane " in the first_name variable. That extra space is there to separate the words in the final result: "Lane Wagner".

Multi-Variable Declaration

We can save space when creating many new variables by declaring them on the same line:

sword_name, sword_damage, sword_length = "Excalibur", 10, 200

Which is the same as:

sword_name = "Excalibur"
sword_damage = 10
sword_length = 200

Any number of variables can be declared on the same line, and variables declared on the same line should be related to one another in some way so that the code remains easy to understand.

We call code that's easy to understand "clean code".

Chapter 2: Computing Basics

Python Numbers

In Python, numbers without a decimal part are called Integers - just like they are in mathematics.

Integers are simply whole numbers, positive or negative. For example, 3 and -3 are both examples of integers.

Arithmetic can be performed as you might expect:

Addition

2 + 1
# 3

Subtraction

2 - 1
# 1

Multiplication

2 * 2
# 4

Division

3 / 2
# 1.5 (a float)

This one is actually a bit different - division on two integers will actually produce a float. A float is, as you may have guessed, the number type that allows for decimal values.

Integers

In Python, numbers without a decimal part are called Integers. Contrast this to JavaScript where all numbers are just a Number type.

Integers are simply whole numbers, positive or negative. For example, 3 and -3 are both examples of integers.

Floats

A float is, as you may have guessed, the number type that allows for decimal values.

my_int = 5
my_float = 5.5

Floor division

Python has great out-of-the-box support for mathematical operations. This, among other reasons, is why it has had such success in artificial intelligence, machine learning, and data science applications.

Floor division is like normal division except the result is floored afterward, which means the remainder is removed. As you would expect, this means the result is an integer instead of a float.

7 // 3
# 2 (an integer)

Exponents

Python has built-in support for exponents - something most languages require a math library for.

# reads as "three squared" or
# "three raised to the second power"
3 ** 2
# 9

Changing In Place

It's fairly common to want to change the value of a variable based on its current value.

player_score = 4
player_score = player_score + 1
# player_score now equals 5

player_score = 4
player_score = player_score - 1
# player_score now equals 3

Don't let the fact that the expression player_score = player_score - 1 is not a valid mathematical expression be confusing. It doesn't matter, it is valid code. It's valid because the way the expression should be read in English is:

Assign to player_score the old value of player_score minus 1

Plus Equals

Python makes reassignment easy when doing math. In JavaScript or Go you might be familiar with the ++ syntax for incrementing a number variable. In Python, we use the += operator instead.

star_rating = 4
star_rating += 1
# star_rating is now 5

Scientific Notation

As we covered earlier, a float is a positive or negative number with a fractional part.

You can add the letter e or E followed by a positive or negative integer to specify that you're using scientific notation.

print(16e3)
# Prints 16000.0

print(7.1e-2)
# Prints 0.071

If you're not familiar with scientific notation, it's a way of expressing numbers that are too large or too small to conveniently write normally.

In a nutshell, the number following the e specifies how many places to move the decimal to the right for a positive number, or to the left for a negative number.

Underscores for readability

Python also allows you to represent large numbers in the decimal format using underscores instead of commas to make it easier to read.

num = 16_000
print(num)
# Prints 16000

num = 16_000_000
print(num)
# Prints 16000000

Logical Operators

You're probably familiar with the logical operators AND and OR.

Logical operators deal with boolean values, True and False.

The logical AND operator requires that both inputs are True to return True. The logical OR operator only requires that at least one input is True to return True.

For example:

True AND True = True
True AND False = False
False AND False = False

True OR True = True
True OR False = True
False OR False = False

Python Syntax

print(True and True)
# prints True

print(True or False)
# prints True

Nesting with parentheses

We can nest logical expressions using parentheses.

print((True or False) and False)

First, we evaluate the expression in the parentheses, (True or False). It evaluates to True:

print(True and False)

True and False evaluates to False:

print(False)

So, print((True or False) and False) prints "False" to the console.

Binary Numbers

Binary numbers are just "base 2" numbers. They work the same way as "normal" base 10 numbers, but with 2 symbols instead of 10.

Each 1 in a binary number represents a greater multiple of 2. In a 4-digit number, that means you have the eight's place, the four's place, the two's place, and the one's place. Similar to how in decimal you would have the thousandth's place, the hundredth's place, the ten's place, and the one's place.

0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8

Bitwise "&" Operator

Bitwise operators are similar to logical operators, but instead of operating on boolean values, they apply the same logic to all the bits in a value. For example, say you had the numbers 5 and 7 represented in binary. You could perform a bitwise AND operation and the result would be 5.

A 1 in binary is the same as True, while 0 is False. So really a bitwise operation is just a bunch of logical operations that are completed in tandem.

& is the bitwise AND operator in Python. 5 & 7 = 5, while 5 & 2 = 0.

Binary notation

When writing a number in binary, the prefix 0b is used to indicate that what follows is a binary number.

0b0101 is 5
0b0111 is 7

Example: Guild Permissions

It's common practice in backend development to store user permissions as binary values. Think about it, if I have 4 different permissions a user can have, then I can store that as a 4-digit binary number, and if a certain bit is present, I know the permission is enabled.

Let's pretend we have 4 permissions:

can_create_guild - Leftmost bit
can_review_guild - Second to left bit
can_delete_guild - Second to right bit
can_edit_guild - Rightmost bit

Which are represented by 0b0000. For example, if a user only has the can_create_guild permission, their binary permissions would be 0b1000. A user with can_review_guild and can_edit_guild would be 0b0101.

To check for, say, the can_review_guild permission, we can perform a bitwise AND operation on the user's permissions and the enabled can_review_guild bit (0b0100). If the result is 0b0100 again, we know they have that specific permission!

Bitwise "|" Operator

As you may have guessed, the bitwise "or" operator is similar to the bitwise "and" operator in that it works on binary rather than boolean values. However, the bitwise "or" operator "ORs" the bits together. Here's an example:

0101 is 5
0111 is 7

A 1 in binary is the same as True, while 0 is False. So a bitwise operation is just a bunch of logical operations that are completed in tandem. When two binary numbers are "OR'ed" together, the result has a 1 in any place where either of the input numbers has a 1 in that place.

| is the bitwise OR operator in Python. 5 | 7 = 7 and 5 | 2 = 7 as well!

Not

We skipped a very important logical operator - not. The not operator reverses the result. It returns False if the input was True and vice-versa.

print(not True)
# Prints: False

print(not False)
# Prints: True

Chapter 3: Comparisons

Comparison Operators

When coding it's necessary to be able to compare two values. Boolean logic is the name for these kinds of comparison operations that always result in True or False.

The operators:

< "less than"
> "greater than"
<= "less than or equal to"
>= "greater than or equal to"
== "equal to"
!= "not equal to"

For example:

5 < 6 # evaluates to True
5 > 6 # evaluates to False
5 >= 6 # evaluates to False
5 <= 6 # evaluates to True
5 == 6 # evaluates to False
5 != 6 # evaluates to True

Evaluations

When a comparison happens, the result of the comparison is just a boolean value, it's either True or False.

Take the following two examples:

is_bigger = 5 > 4

is_bigger = True

In both of the above cases, we're creating a Boolean variable called is_bigger with a value of True.

Since 5 > 4, is_bigger is always assigned the value of True.

Why would I use the comparison if I can just set it to "True"?

You wouldn't in this case. However, let's imagine that instead of hard-coding the numbers 5 and 4, we had some dynamic variables that we don't know the values of. For example, perhaps you're making a video game and need to keep track of player scores.

To calculate who wins, you would need to write something like:

# player_one_points and player_two_points are defined and change somewhere else in the game's code
player_one_wins = player_one_points > player_two_points
print(player_one_wins)

# prints "True" when player one is winning, otherwise prints "False"

Increment / Decrement

If we're changing a number and simply want to increment (add to) or decrement (subtract from) there are special operators for that.

shield_armor = 4
shield_armor += 1
# shield_armor now equals 5
shield_armor += 2
# shield_armor now equals 7

shield_armor = 4
shield_armor -= 1
# shield_armor now equals 3
shield_armor -= 2
# shield_armor now equals 1

Notice that shield_armor+=1 is just short-hand for shield_armor = shield_armor + 1

If Statements

It's often useful to only execute code if a certain condition is met:

if CONDITION:
  # do some stuff here

for example:

if bob_score > bill_score:
  print("Bob Wins!")

If-Else

An if statement can be followed by zero or more elif (which stands for "else if") statements, which can be followed by zero or one else statement. For example:

if score > high_Score:
    print('High score beat!')
elif score > second_highest_score:
    print('You got second place!')
elif score > third_highest_score:
    print('You got third place!')
else:
    print('Better luck next time')

First the if statement is evaluated. If it is True then the if statement's body is executed and all the other elses are ignored.

If the first if is false then the next elif is evaluated. Likewise, if it is True then its body is executed and the rest are ignored.

If none of the if statements evaluate to True then the final else statement will be the only body executed.

If-Else Rules

You can't have an elif or an else without an if
You can have an else without an elif

Chapter 5: Loops

Loops are a programmer's best friend. Loops allow us to do the same operation multiple times without having to write it explicitly each time.

For example, let's pretend I want to print the numbers 0-9.

I could do this:

print(0)
print(1)
print(2)
print(3)
print(4)
print(5)
print(6)
print(7)
print(8)
print(9)

Even so, it would save me a lot of time typing to use a loop. Especially if I wanted to do the same thing one thousand or one million times.

A "for loop" in Python is written like this:

for i in range(0, 10):
    print(i)

In English, the code says:

Start with i equals 0. (i in range(0)
If i is not less than 10 (range(0, 10)), exit the loop.
Print i to the console. (print(i))
Add 1 to i. (range defaults to incrementing by 1)
Go back to step 2

The result is that the numbers 0-9 are logged to the console in order.

Whitespace matters in Python!

The body of a for-loop must be indented, otherwise you'll get a syntax error.

Example

This code print the numbers 0-9 to the console.

for i in range(0, 10):
    print(i)

Range Continued

The range() function we've been using in our for loops actually has an optional 3rd parameter: the "step".

for i in range(0, 10, 2):
    print(i)
# prints:
# 0
# 2
# 4
# 6
# 8

The "step" parameter determines how much to increment i by in each iteration of the loop. You can even go backwards:

for i in range(3, 0, -1):
    print(i)
# prints:
# 3
# 2
# 1

F-strings in Python

You can create a string with dynamic values by using f-strings in Python. It's a beautiful syntax that I wish more programming languages used.

num_bananas = 10
print(f"You have {num_bananas} bananas")
# You have 10 bananas

The opening quotes need to be proceeded by an f, then any variables within curly brackets have their values interpolated into the string.

Chapter 6: Lists

A natural way to organize and store data is in the form of a List. Some languages call them "arrays", but in Python we just call them lists. Think of all the apps you use and how many of the items in the app are organized into lists.

For example:

A twitter feed is a list of posts
An online store is a list of products
The state of a chess game is a list of moves
This list is a list of things that are lists

Lists in Python are declared using square brackets, with commas separating each item:

inventory = ["Iron Breastplate", "Healing Potion", "Leather Scraps"]

Arrays can contain items of any data type, in our example above we have a List of strings.

Vertical syntax

Sometimes when we're manually creating lists it can be hard to read if all the items are on the same line of code. We can declare the array using multiple lines if we want to:

flower_types = [
    "daffodil",
    "rose",
    "chrysanthemum"
]

Keep in mind this is just a styling change. The code will run correctly either way.

Counting in Programming

In the world of programming, counting is a bit strange!

We don't start counting at 1, we start at 0 instead.

Indexes

Each item in an array has an index that refers to its spot in the array.

Take the following array as an example:

names = ["Bob", "Lane", "Alice", "Breanna"]

Index 0: Bob
Index 1: Lane
Index 2: Alice
Index 3: Breanna

Indexing into Lists

Now that we know how to create new lists, we need to know how to access specific items in the list.

We access items in a list directly by using their index. Indexes start at 0 (the first item) and increment by one with each successive item. The syntax is as follows:

best_languages = ["JavaScript", "Go", "Rust", "Python", "C"]
print(best_languages[1])
# prints "Go", because index 1 was provided

List length

The length of a List can be calculated using the len() function. Again, we'll cover functions in detail later, but this is the syntax:

fruits = ["apple", "banana", "pear"]
length = len(fruits)
# Prints: 3

The length of the list is equal to the number of items present. Don't be fooled by the fact that the length is not equal to the index of the last element, in fact it will always be one greater.

List Updates

We can also change the item that exists at a given index. For example, we can change Leather to Leather Armor in the inventory array in the following way:

inventory = ["Leather", "Healing Potion", "Iron Ore"]
inventory[0] = "Leather Armor"
# inventory: ['Leather Armor', 'Healing Potion', 'Iron Ore']

Appending in Python

It's common to create an empty list then fill it with values using a loop. We can add values to the end of a list using the .append() method:

cards = []
cards.append("nvidia")
cards.append("amd")
# the cards list is now ['nvidia', 'amd']

Pop Values

.pop() is the opposite of .append(). Pop removes the last element from the array and returns it for use. For example:

vegetables = ["broccoli", "cabbage", "kale", "tomato"];
last_vegetable = vegetables.pop()
# vegetables = ['broccoli', 'cabbage', 'kale']
# last_vegetable = 'tomato'

Counting the items in a list

Remember that we can iterate (count) over all the items in an array using a loop. For example, the following code will print each item in the sports array.

for i in range(0, len(sports)):
    print(sports[i])

No-index Syntax

In my opinion, Python has the most elegant syntax for iterating directly over the items in a list without worrying about index numbers. If you don't need the index number you can use the following syntax:

trees = ['oak', 'pine', 'maple']
for tree in trees:
  print(tree)
# Prints:
# oak
# pine
# maple

tree, the variable declared using the in keyword, directly accesses the value in the array rather than the index of the value. If we don't need to update the item, and only need to access its value then this is a more clean way to write the code.

Find an item in a list

Example of "no-index" or "no-range" syntax:

for fruit in fruits:
    print(fruit)

Modulo operator in Python

The modulo operator can be used to find a remainder:

For example, 7 modulo 2 would be 1, because 2 can be multiplied evenly into 7 at most 3 times:

2 * 3 = 6

Then there is 1 remaining to get from 6 to 7.

7 - 6 = 1

The d operator is the percent sign: %. It's important to recognize modulo is not a percentage though! That's just the symbol we're using.

remainder = 8 % 3
# remainder = 2

An odd number is a number that when divided by 2, the remainder is not 0.

Slicing lists

Python makes it easy to slice and dice lists to work only with the section you care about. One way to do this is to use the simple slicing operator, which is just a colon :.

With this operator, you can specify where to start and end the slice, and how to step through the original. List slicing returns a new list from the existing list.

The syntax is as follows:

Lst[ Initial : End : IndexJump ]

scores = [50, 70, 30, 20, 90, 10, 50]
# Display list
print(scores[1:5:2])
# Prints [70, 20]

The above reads as "give me a slice of the scores list from index 1, up to but not including 5, skipping every 2nd value. All of the sections are optional.

scores = [50, 70, 30, 20, 90, 10, 50]
# Display list
print(scores[1:5])
# Prints [70, 30, 20, 90]

scores = [50, 70, 30, 20, 90, 10, 50]
# Display list
print(scores[1:])
# Prints [70, 30, 20, 90, 10, 50]

List Operations - Concatenate

Concatenating two lists (smushing them together) is really easy in Python, just use the + operator.

all = [1, 2, 3] + [4, 5, 6]
print(all)
# Prints: [1, 2, 3, 4, 5, 6]

List Operations - Contains

Checking whether a value exists in a list is also really easy in Python, just use the in keyword.

fruits = ["apple", "orange", "banana"]
print("banana" in fruits)
# Prints: True

Tip: Quotes within quotes

To use quotes within quotes, they either need to be escaped or you need to use the other kind of quotes. Because we usually use double quotes, we can nest strings with single quotes:

f"banana is in fruits list: {'banana' in fruits}"

List deletion

Python has a built-in keyword del that deletes items from objects. In the case of a list, you can delete specific indexes or entire slices.

nums = [1, 2, 3, 4, 5, 6, 7, 8, 9]

# delete the fourth item
del nums[3]
print(nums)
# Output: [1, 2, 3, 5, 6, 7, 8, 9]

# delete items from 2nd to 3rd
nums = [1, 2, 3, 4, 5, 6, 7, 8, 9]
del nums[1:3]
print(nums)
# Output: [1, 4, 5, 6, 7, 8, 9]

# delete all elements
nums = [1, 2, 3, 4, 5, 6, 7, 8, 9]
del nums[:]
print(nums)
# Output: []

Tuples

Tuples are collections of data that are ordered and unchangeable. You can think of a tuple as a List with a fixed size. Tuples are created with round brackets:

my_tuple = ("this is a tuple", 45, True)
print(my_tuple[0])
# this is a tuple
print(my_tuple[1])
# 45
print(my_tuple[2])
# True

While it's typically considered bad practice to store items of different types in a List it's not a problem with Tuples. Because they have a fixed size, it's easy to keep track of which indexes store which types of data.

Tuples are often used to store very small groups (like 2 or 3 items) of data. For example, you might use a tuple to store a dog's name and age.

dog = ("Fido", 4)

Because Tuples hold their data, multiple tuples can be stored within a list. Similar to storing other data in lists, each tuple within the list is separated by a comma.

my_tuples = [("this is the first tuple in the list", 45, True),("this is the second tuple in the list", 21, False)]
print(my_tuples[0][0])
# this is the first tuple in the list

Chapter 7: Functions

Functions allow us to reuse and organize code. For example, let's pretend we need to calculate the area of a circle. We can use the formula area = pi * r^2, or in code:

r = 5
area = 3.14 * r * r

This works great! The problem arises when multiple places in our code need to get the area of a circle

r = 5
area1 = 3.14 * r * r

r2 = 7
area2 = 3.14 * r2 * r2

r3 = 11
area3 = 3.14 * r3 * r3

We want to use the same code, why repeat the work?

Let's declare a new function area_of_circle(). Notice that the def keyword is written before the function name, and tells the computer that we're declaring, or defining, a new function.

def area_of_circle(r):
    return 3.14 * r * r

The area_of_circle function takes one input (which can also be called a parameter or argument), and returns a single output. We give our function the radius of a circle and we get back the area of that circle!

To use or "call" the function we can pass in any number as the input, and capture the output into a new variable:

radius = 5
area = area_of_circle(radius)

Let's talk through this code example step by step.

The radius variable is created with a value of 5.
The area_of_circle function is called with a single argument: radius
The area_of_circle function is executed, with r being equal to 5
The result of 3.14 * r * r is returned from area_of_circle, which happens to be 78.75
area_of_circle(radius) resolves to the returned value of 78.75
The area variable is created with a value of 78.75

Multiple Parameters

Functions can have multiple parameters, or inputs:

def subtract(a, b):
    return a - b

Where to Declare Functions

You've probably noticed that a variable needs to be declared before it's used. For example, the following doesn't work:

print(my_name)
my_name = 'Lane Wagner'

It needs to be:

my_name = 'Lane Wagner'
print(my_name)

Lines of code execute in order from top to bottom, so a variable needs to be created before it can be used. That means that if you define a function, you can't call that function until after the definition.

The main() function is a convention used in many programming languages to specify the entrypoint of an application. By defining a single main function, and only calling main() at the end of the entire program we ensure that all of our function are defined before they're called.

Order of functions

All functions must be defined before they're used.

You might think this would make structuring Python code difficult because the order in which the functions are declared can quickly become so dependent on each other that writing anything becomes impossible.

As it turns out, most Python developers solve this problem by simply defining all the functions first, then finally calling the entrypoint function last. If you do that, then the order that the functions are declared in doesn't matter. The entrypoint function is usually called "main".

def main():
    func2()

def func2():
    func3()

def func3():
    print("I'm function 3")

main() # entrypoint

Scope

Scope refers to where a variable or function name is available to be used. For example, when we create variables in a function (by giving names to our parameters for example), that data is not available outside of that function.

For example:

def subtract(x, y)
    return x - y
result = subtract(5, 3)
print(x)
# ERROR! "name 'x' is not defined"

When the subtract function is called, we assign the variable x to 5, but x only exists in the code within the subtract function. If we try to print x outside of that function then we won't get a result, in fact we'll get a big fat error.

Global Scope

So far we've been working in the global scope. That means that when we define a variable or a function, that name is accessible in every other place in our program, even within other functions.

For example:

pi = 3.14

def get_area_of_circle(radius):
    return pi * radius * radius

Because pi was declared in the parent "global" scope, it is usable within the get_area_of_circle() function.

Infinity

The built-in float() function can be used to create a numeric floating point value that represents the negative infinity value. I've added it for you as a starting point.

negative_infinity = float('-inf')
positive_infinity = float('inf')

None Return

When no return value is specified in a function, (for example, maybe it's a function that prints some text to the console, but doesn't explicitly return a value) it will return None. The following code snippets all return exactly the same thing:

def my_func():
    print("I do nothing")
    return None

def my_func():
    print("I do nothing")
    return

def my_func():
    print("I do nothing")

Parameters vs arguments

Parameters are the names used for inputs when defining a function. Arguments are the names of the inputs supplied when a function is called.

To reiterate, arguments are the actual values that go into the function, say 42.0, "the dark knight", or True. Parameters are the names we use in the function definition to refer to those values, which at the time of writing the function, could be anything.

That said, it is important to understand that this is all semantics, and frankly developers are really lazy with these definitions. You'll often hear the words arguments and parameters used interchangeably.

# a and b are parameters
def add(a, b)
    return a + b

# 5 and 6 are arguments
sum = add(5, 6)

Multiple return values

In Python, we can return more than one value from a function. All we need to do is separate each value by a comma.

# returns email, age, and status of the user
def get_user():
    return "name@domain.com", 21, "active"

email, age, status = get_user()
print(email, age, status)
# Prints: "name@domain.com 21 active"

def get_user():
    return "name@domain.com", 21, "active"

# this works, and by convention you should NOT use the underscore variable later
email, _, _ = get_user()
print(email)
# Prints: "name@domain.com"
print(_)
# Prints: "active"

Default values for function arguments

Python has a way to specify a default value for function arguments. This can be convenient if a function has arguments that are essentially "optional", and you as the function creator want to use a specific default value in case the caller doesn't provide one

A default value is created by using the assignment (=) operator in the function signature.

def get_greeting(email, name="there"):
    return f"Hello {name}, welcome! You've registered your email: {email}"

msg = get_greeting("lane@example.com", "Lane")
# Hello Lane, welcome! You've registered your email: lane@example.com

msg = get_greeting("lane@example.com")
# Hello there, welcome! You've registered your email: lane@example.com

If the second parameter is omitted, the default "there" value will be used in its place. As you may have guessed, for this structure to work, optional arguments that have defaults specified come after all the required arguments.

Chapter 8: Dictionaries

Dictionaries in Python are used to store data values in key -> value pairs. Dictionaries are a great way to store groups of information.

car = {
  "brand": "Tesla",
  "model": "3",
  "year": 2019
}

Duplicate keys

Because dictionaries rely on unique keys, you can't have two of the same key in the same dictionary. If you try to use the same key twice, the associated value will simply be overwritten.

Accessing Dictionary Values

Dictionary elements must be accessible somehow in code, otherwise they wouldn't be very useful.

A value is retrieved from a dictionary by specifying its corresponding key in square brackets. The syntax looks similar to indexing into a list.

car = {
    'make': 'tesla',
    'model': '3'
}
print(car['make'])
# Prints: tesla

Setting Dictionary Values

You don't need to create a dictionary with values already inside. It is common to create a blank dictionary then populate it later using dynamic values. The syntax is the same as getting data out of a key, just use the assignment operator (=) to give that key a value.

names = ["jack bronson", "jill mcarty", "john denver"]

names_dict = {}
for name in names:
    # .split() returns a list of strings
    # where each string is a single word from the original
    names_arr = name.split()

    # here we update the dictionary
    names_dict[names_arr[0]] = names_arr[1]

print(names_dict)
# Prints: {'jack': 'bronson', 'jill': 'mcarty', 'john': 'denver'}

Updating Dictionary Values

If you try to set the value of a key that already exists, you'll end up just updating the value of that key.

names = ["jack bronson", "james mcarty", "john denver"]

names_dict = {}
for name in names:
    # .split() returns a list of strings
    # where each string is a single word from the original
    names_arr = name.split()

    # we're always setting the "jack" key
    names_dict["jack"] = names_arr[1]

print(names_dict)
# Prints: {'jack': 'denver'}

Deleting Dictionary Values

You can delete existing keys using the del keyword.

names_dict = {
    'jack': 'bronson',
    'jill': 'mcarty',
    'joe': 'denver'
}

del names_dict['joe']

print(names_dict)
# Prints: {'jack': 'bronson', 'jill': 'mcarty'}

Deleting keys that don't exist

Notice that if you try to delete a key that doesn't exist, you'll get an error.

names_dict = {
    'jack': 'bronson',
    'jill': 'mcarty',
    'joe': 'denver'
}

del names_dict['unknown']
# ERROR HERE, key doesn't exist

Checking for existence

If you're unsure whether or not a key exists in a dictionary, use the in keyword.

cars = {
    'ford': 'f150',
    'tesla': '3'
}

print('ford' in cars)
# Prints: True

print('gmc' in cars)
# Prints: False

Iterating over a dictionary in Python

fruit_sizes = {
    "apple": "small",
    "banana": "large",
    "grape": "tiny"
}

for name in fruit_sizes:
    size = fruit_sizes[name]
    print(f"name: {name}, size: {size}")

# name: apple, size: small
# name: banana, size: large
# name: grape, size: tiny

Ordered or Unordered?

As of Python version 3.7, dictionaries are ordered. In Python 3.6 and earlier, dictionaries were unordered.

Because dictionaries are ordered, the items have a defined order, and that order will not change.

Unordered means that the items used to not have a defined order, so you couldn't refer to an item by using an index.

**The takeaway is that if you're on Python 3.7 or later, you'll be able to iterate over dictionaries in the same order every time.

Chapter 9: Sets

Sets are like Lists, but they are unordered and they guarantee uniqueness. There can be no two of the same value in a set.

fruits = {'apple', 'banana', 'grape'}
print(type(fruits))
# Prints: <class 'set'>

print(fruits)
# Prints: {'banana', 'grape', 'apple'}

Adding values to a set

fruits = {'apple', 'banana', 'grape'}
fruits.add('pear')
print(fruits)
# Prints: {'banana', 'grape', 'pear', 'apple'}

Empty set

Because the {} syntax creates an empty dictionary, to create an empty set, just use the set() function.

fruits = set()
fruits.add('pear')
print(fruits)
# Prints: {'pear'}

Iterate over values in a set (order is not guaranteed)

fruits = {'apple', 'banana', 'grape'}
for fruit in fruits:
    print(fruit)
    # Prints:
    # banana
    # grape
    # apple

Removing values from a set

fruits = {'apple', 'banana', 'grape'}
fruits.remove('apple')
print(fruits)
# Prints: {'banana', 'grape'}

Chapter 10: Errors

You've probably encountered some errors in your code from time to time if you've gotten this far in the course. In Python, there are two main kinds of distinguishable errors.

syntax errors
exceptions

Syntax errors

You probably know what these are by now. A syntax error is just the Python interpreter telling you that your code isn't adhering to proper Python syntax.

this is not valid code, so it will error

If I try to run that sentence as if it were valid code I'll get a syntax error:

this is not valid code, so it will error
      ^
SyntaxError: invalid syntax

Exceptions

Even if your code has the right syntax however, it may still cause an error when an attempt is made to execute it. Errors detected during execution are called "exceptions" and can be handled gracefully by your code. You can even raise your own exceptions when bad things happen in your code.

Python uses a try-except pattern for handling errors.

try:
  10 / 0
except Exception as e:
  print(e)

# prints "division by zero"

The try block is executed until an exception is raised or it completes, whichever happens first. In this case, a "divide by zero" error is raised because division by zero is impossible. The except block is only executed if an exception is raised in the try block. It then exposes the exception as data (e in our case) so that the program can handle the exception gracefully without crashing.

Raising your own exceptions

Errors are not something to be scared of. Every program that runs in production is expected to manage errors on a constant basis. Our job as developers is to handle the errors gracefully and in a way that aligns with our user's expectations.

Errors are NOT bugs

When something in our own code happens that we don't expect, we should raise our own exceptions. For example, if someone passes some bad inputs to a function we write, we should not be afraid to raise an exception to let them know they did something wrong.

An error or exception is raised when something bad happens, but as long as our code handles it as users expect it to, it's not a bug. A bug is when code behaves in ways our users don't expect it to.

For example, if a player tries to forge an iron sword out of bronze metal, we might raise an exception and display an error message to the player. However, that's the expected behavior of the game, so it's not a bug. If a player can forge the iron sword out of bronze, that may be considered a bug because that's against the rules of the game.

raise Exception("something bad happened")

Software applications aren't perfect, and user input and network connectivity are far from predictable. Despite intensive debugging and unit testing, applications will still have failure cases.

Loss of network connectivity, missing database rows, out of memory issues, and unexpected user inputs can all prevent an application from performing "normally". It is your job to catch and handle any and all exceptions gracefully so that your app keeps working. When you are able to detect that something is amiss, you should be raising the errors yourself, in addition to the "default" exceptions that the Python interpreter will raise.

raise Exception("something bad happened")

Different types of exceptions

We haven't covered classes and objects yet, which is what an Exception really is at its core. We'll go more into that in the object-oriented programming course that we have lined up for you next.

For now, what is important to understand is that there are different types of exceptions and that we can differentiate between them in our code.

More syntax for errors

try:
    10/0
except ZeroDivisionError:
    print("0 division")
except Exception:
    print("unknown exception")

try:
    nums = [0, 1]
    print(nums[2])
except ZeroDivisionError:
    print("0 division")
except Exception:
    print("unknown exception")

Which will print:

0 division
unknown exception

Chapter 11: Python Facts

The Zen of Python

Tim Peters, a long time Pythonista describes the guiding principles of Python in his famous short piece, The Zen of Python.

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

Why Python?

Here are some reasons we think Python is a future-proof choice for developers:

Easy to read and write - Python reads like plain English. Due to its simple syntax, it's a great choice for implementing advanced concepts like AI. This is arguably Python's best feature.
Popular - According to the Stack Overflow Developer Survey, Python is the 4th most popular coding language in 2020.
Free - Python, like many languages nowadays, is developed under an open-source license. It's free to install, use, and distribute.
Portable - Python written for one platform will work on any other platform.
Interpreted - Code can be executed as soon as it's written. Because it doesn't need to take a long time to compile like Java, C++, or Rust, releasing code to production is typically faster.

Why not Python?

Python might not be the best choice for a project if:

The code needs to run fast. Python code executes very slowly, which is why performance critical applications like PC games aren't written in Python.
The codebase will become large and complex. Due to its dynamic type system, Python code can be harder to keep clean of bugs.
The application needs to be distributed directly to non-technical users. They would have to install Python in order to run your code, which would be a huge inconvenience.

Python 2 vs Python 3

One thing that's important to keep in mind as you continue your Python journey is that the Python ecosystem suffers from split personality syndrome. Python 3 was released on December 3rd, 2008, but over a decade later the web is still full of Python 2 dependencies, scripts and tutorials.

In this course, we used Python 3 - just like any good citizen should these days.

One of the most obvious breaking changes between Python 2 and 3 is the syntax for printing text to the console.

Python 2

print "hello world"

Python 3

print("hello world")

Congratulations on making it to the end!

If you're interested in doing the interactive coding assignments and quizzes for this course you can check out the Learn Python course over on Boot.dev.

That course is a part of my full back-end developer career path, made up of other courses and projects if you're interested in checking those out.

It's Not About the Job Openings

Lane Wagner — Thu, 30 Mar 2023 14:43:33 +0000

I talk to boatloads of students who are starting to learn to code, and invariably they are hyper-concerned about which programming languages and technologies they should be learning.

Now, first of all, I don't think it matters all that much. You don't fail to break into tech because you learned JavaScript instead of Python, or Go instead of Rust. You fail for a bunch of other reasons, chief among them being a lack of dedication, time, and focus.

That said, choosing good technologies to learn can certainly help. Unfortunately, almost everyone I talk to is only concerned with one metric: the total number of jobs for a given technology.

This is a mistake.

The total number of jobs doesn't matter

According to Stack Overflow's latest survey, JavaScript is the most popular programming language in the world, both for people learning to code as well as professional developers.

I also did a quick search on LinkedIn Jobs for "JavaScript" and "Golang" jobs. Here are the results:

JavaScript: 477,512 open positions in the US
Golang: 61,673 open positions in the US

If you look at those numbers and think "I should learn JavaScript because there are more jobs", you're not alone, but you're wrong.

It doesn't matter how many total jobs there are, because you only need to land one.

-- me

Looking at the ratios

To dive deeper I went to Google Trends and looked at the number of people searching for the terms "Learn JavaScript" and "Learn Golang" over the last 12 months. Here was the ratio:

JavaScript: 73
Golang: 6

73/6 is the ratio of people searching for "Learn JavaScript" to people searching for "Learn Golang". Google Trends, like the Sith, doesn't deal in absolutes.

So, let's do some more math:

JavaScript jobs to Golang jobs: 477,512 / 61,673 = 7.7

7.7 JavaScript jobs for every 1 Golang job

JavaScript learners to Golang learners: 73 / 7 = 10.4

10.4 JavaScript learners for every 1 Golang learner

Next, the "competition ratio": 10.4 / 7.7 = 1.4

Based on these numbers, I'd estimate that your competition for JavaScript jobs is about 1.4x higher than your competition for Golang jobs. According to this completely scientific and in no-way fallible analysis, it looks like Go might be a better choice if you're trying to minimize your competition for jobs.

Can I trust these numbers?

I don't know, probably not. My goal here isn't to convince you to learn Go, Python, Rust, JavaScript, or anything else for that matter. I just want you to think about the job market in a slightly different way.

This has been top-of-mind for me lately due to an anecdote from a couple of years ago. I was working as a hiring manager where I was looking for mid-level Go developers. My coworker was hiring mid-level JavaScript developers at the same company. When I opened a new position I would get 10-20 candidates within 2 weeks. He would get 100+ candidates within the same time frame. I felt bad for the JavaScript candidates.

Does the total number of jobs matter at all?

Yes, but I prefer to think of it as a threshold. Like, if there are only 100 total jobs for a given technology, even if you're one of ten people in the world who knows it, you're going to be entering a very niche market that could dry up at any moment.

It's like, "is what I'm learning sufficiently popular that I can reasonably expect to find a job"? If it is, then I'd argue the next most important metric is the ratio of candidates to jobs.

What else matters?

The next thing to consider is your location. Remote work is great, but I'm a big fan of junior devs trying to work on-site for at least a year or two. You'll learn faster, and you'll actually have an easier time landing a job in the first place (assuming you're in a place with some jobs). When you compete for a local job, you're only competing against people who live in your city, not the entire world.

If Python has tons of jobs, and a fantastic ratio of candidates to jobs, but where you live the only developer openings are for Go and Java, then I'd recommend reconsidering your choice of technology.

Please don't worry about it too much

Like I said at the outset, you won't fail to break into tech because you didn't choose the perfect stack to learn.

If you go about learning to code by going deep on the basics, you can always learn new technologies as you go. Fundamental concepts like problem-solving, imperative programming, data structures, algorithms, architecture, clean code, io, networking, HTTP, REST, databases, and caching are universal and language-agnostic. If you know how to build a REST API in Go, spinning one up in Express or Django is going to be a quick learning curve.

Syntax is the easy part. Best of luck out there.

Your Architecture is Bad, So Make It Easy to Change

Lane Wagner — Fri, 10 Feb 2023 15:54:12 +0000

Have you ever started a new software development job and thought:

"Wow, what a beautifully architected system! I wouldn't change anything here."

Unless it's a brand-new project, I'm guessing not. Most of us are dreadfully aware of the dashes of technical debt we sprinkle into our codebases every day, all in the name of getting the job done.

Don't get me wrong, I'm a clean architecture nerd. I love talking about monoliths, microservices, containers, clusters, PaaS, caching, message queues, and everything else under the sun. I do everything I can to make sure that my code is easy to debug, easy to scale, and easy to add features to.

Here's the thing: I also know that my architecture is terrible, and yours is too.

Why is your architecture so bad?

Well, maybe it's not. Your architecture may be pretty good at the moment. You might be using a popular design pattern, you may have services that can scale up to handle 10x the load that you're currently seeing, and all the engineers on your team might understand the codebase.

Unfortunately, your architecture is bad three years from now. It's bad when your team goes from 10 to 100 engineers. It's bad when your company pivots from a B2B SaaS product to a B2C mobile app. It's bad when you onboard a new enterprise client that requires you to store all their data in a different country.

Assuming you have good engineers, your architecture is probably bad due to business decisions, not technical ones. It is often a good business decision to accrue technical debt if the payoff is worth it, and a savvy engineer will know when to make that tradeoff.

Is there no hope?

It's sometimes a good decision to take on technical debt, but we need to acknowledge that the debt must eventually be paid back.

You can know what a good architecture for your current business needs is, so build that! There's no sense in planning for 1,000,000 users when you only have 500. Avoid planning too far ahead, but also understand that your future needs could be wildly different from your current ones.

To put this idea simply:

Build your systems for the present, but anticipate a very different future

Wait for more information before locking in your architecture

The best architectural decision you can make is to often not make one. Here's an example. Let's pretend you're building a web app that displays temperature data from various weather sources. You're already using a PostgreSQL database for authentication and user information and need to decide where to store the weather data, but you know that your temperature aggregations queries won't scale well in a monolithic database like Postgres.

However, you only have a few data sources and a few users, so scalability isn't a problem. I'd argue that you should just shove that data in Postgres, with a loose plan to move to a more domain-specific solution later.

But wait!!! Here's where most engineers go wrong.

You should be engineering around the fact that you don't like your current solution.

Instead of locking yourself into Postgres by using advanced Postgres features and implementing JOINs to your other tables, try to keep your data as flat and as simple as you can. When you do inevitably need to move your data somewhere else, you can do so with minimal effort.

When you're building software for a fast-growing company, a "clean" architecture isn't an optimized one, but a modular one that can be changed easily.

So I should just procrastinate?

It's not about procrastinating architectural decisions, it's about being able to make smarter decisions once the real data comes in. As an engineer, it's impossible to predict every pivot the business will make, every requirement a customer will have, and every technology that will be released in the future. Your goal is to engineer a system that does its job while delaying decisions you don't need to make until you have more information.

Cryptography Course Released on Boot.dev

Lane Wagner — Tue, 24 Jan 2023 15:54:07 +0000

Greetings! We're excited to announce that we've unveiled a brand-new cryptography course on Boot.dev. We're convinced that this new experience is truly one of a kind. If you want to learn cryptography while writing real code in the Go programming language, you should check it out.

You can get started for free here.

Why learn cryptography?

Ever wondered how your data is kept safe online? This course will teach you about encryption, password security, ciphers, and more. After you master the fundamentals, you'll learn how each cryptographic primitive is used in real-world applications.

If you're interested in becoming a valuable back-end engineer, an understanding of cryptography will set you apart from other candidates that will fail to answer basic security questions.

Chapters

1. Symmetric Encryption

Learn the basics of cryptography: encrypting and decrypting a secret message with a key

2. Encoding

To be able to work with encrypted data, you need to understand how information is encoded in different formats

3. Brute Force

Learn about the most primitive, but most important kind of crypto attack

4. Caesar Cipher

Learn about the fundamentals of ciphers, starting with Julius Caesar's famous cipher

5. XOR

Study the importance of the XOR operation in cryptography and how it can be used to create the perfect cipher

6. Stream Ciphers

Stream ciphers can be used to encrypt data as it flows through a system

7. Block Ciphers

Block ciphers are commonly used to encrypt large amounts of data at rest, like entire hard drives

8. DES

DES is an older block cipher that's important to understand to appreciate modern block ciphers

9. AES

AES is a secure, modern block cipher that's used in many production applications

10. Asymmetric Encryption

Asymmetric encryption is used in HTTPS, digital signatures, and anywhere two parties need to securely communicate

11. RSA

RSA is one of the most popular asymmetric encryption algorithms

12. Hash Functions

Hashing has many applications in cryptography, including password security and message integrity

13. Digital Signatures

Digital signatures are a way to prove that a message was sent by a particular party

14. KDFs

Key derivation functions are how we derive keys from passwords or other keys securely

What's inside?

You'll find text and image explanations of all the concepts, as well as video explanations of some of the more visually demanding lessons. You'll be writing real code in Go in most of the exercises, and our system will instantly check your code and provide instant feedback. You'll only enjoy the course if you enjoy an engaging hands-on experience.

If You're Learning Back-end, Don't Start with Frameworks

Lane Wagner — Mon, 16 Jan 2023 15:46:09 +0000

Look, I don't hate frameworks. I'm not as starry-eyed as some other developers, especially when it comes to back-end frameworks, but I don't think there's anything wrong with using tools that make you productive. On the contrary, I'm always trying to find tools that make me as productive as possible.

That said, I'm adamant that you should not start with frameworks when you're learning back-end development. I'm not saying you shouldn't use them at all, but I am saying that they are a poor tool for learning.

Frameworks automate the boring stuff

Frameworks are great at automating all that boring stuff, like boilerplate code, authentication, and database migrations. Who wants to do the same thing over and over again?

Trouble is, when you're just starting, those boring details are exactly the things you should be practicing. They're the building blocks of back-end applications, the foundations of what you need to know. And when you use a framework, you're missing out on all that good stuff.

Like any good developer, I use a library and call sha256.Hash(text) when I need to hash some data. I don't try to write my cryptography from scratch! That said, I've taken the time to learn and understand why sha256 is a good choice in a given scenario, and what security it provides me. Similarly, when you're learning back-end development, frameworks are just too high-level to be a good starting point.

Frameworks are easy to learn, that's the whole point

The entire selling point of a framework like Django, Flask, or Rails is that they're easy to use. They take the repetitive, boring stuff and give you an opinionated way to do it. With just a few CLI commands, you can have a fully-functional web application up and running!

The problem with starting this way is that you'll have an entire codebase, with mountains of dependencies, and you'll understand how almost none of it works under the hood. When you encounter issues (and you will) you'll be spending hours trying to work backwards. The problem is very similar to one of my favorite memes: "Hours of debugging can save you minutes of reading the docs!"

In the long run, it will be a lot faster to learn the basics of back-end servers. You can always learn a framework later, it's really not that hard because you understand the pieces that are being abstracted away from you.

I made the mistake of starting with Django

When I was getting my CS degree, I decided I wanted to build a web app, and up until that point, I hadn't done much with the web yet. All I had done was write little Python scripts. RESTful servers, HTTP requests, SQL databases -- I had no idea what any of that was.

Anyhow, I heard Django was popular, so I decided to use it to build a website. I followed "hello world" style tutorials and in a few days I had a working website! I understood how to change variables here and there to make the page display what I wanted, but boy howdy I had no idea what was going on under the hood.

I stressed for weeks trying to make sure my site was "secure". Every blog post online kept telling me I had to set this configuration, or that setting, if I wanted to be able to run my Django server in production. I avoided the database like the plague, instead using Django's ORM and admin panel to make changes to my data. I'm embarrassed to admit that at the time I didn't even understand that the database was a separate thing from the web server.

Anyhow, a year later when I learned Go and built an API from scratch, everything started to come together for me. I finally understood all the moving parts, and how they are actually separate ideas that can be combined in different ways.

Since then, I've worked with minimalistic Go servers, Django, Flask, Rails and Express. I'm no longer stressed when I build a server in Django because I know what tradeoffs are being made. Django and Rails aren't bad tools for building web apps, they're just bad tools for learning.

How far down the rabbit hole do I need to go?

If you wish to make an apple pie from scratch, you must first invent the universe.

-- Carl Sagan

You might be thinking, "Okay, I get it, I shouldn't start with a framework. But where should I start?"

It's a fair question. Following fallacious "slippery slope" logic, we might think something like:

Before a framework, build a web server from scratch
Before a web server, build the HTTP protocol from scratch
Before HTTP, build the operating system from scratch
etc...

That's not what I'm saying. If you want to be a professional in any industry, I think it's a good rule of thumb to go one layer down the stack from where you plan to do most of your work.

Want to build operating systems? It will help to understand the kernel.
Want to write an ORM? It will help to understand databases.
Want to write Rails apps? It will help to understand web servers.

Lastly, full-stack and back-end development are different

One last thing I want to point out is that full-stack and back-end are not the same thing. I think many developers who start with front-end get a bit confused about this. They think that the back-end is just the thing that serves the front-end.

That certainly can be the case in smaller applications, but as a company grows, the back-end tends to become larger and more complex. Frankly, the servers that serve up to front-end might end up being some of the simplest parts of the stack.

While I still think it's best to write a server from scratch at least once, it's even more important if you want to be a back-end engineer rather than a full-stack engineer. If you're a back-end engineer, you'll be spending most of your time working on the back-end, and you'll be digging into more niche problems where a deeper understanding of server architecture will be more helpful.

I hope this helps you avoid some of the pain I experienced, and as always, best of luck! If you're interested in learning back-end development, check out Boot.dev, I think it will help.