How to approach problem-solving as a developer 🤔. Seven steps and strategies to solve software development challenges faster. 

1:45 Identify the problem
2:52 Research and refine
4:37 Write pseudocode
6:25 TDD
7:54 Implement
8:33 Reflect and improve
9:31 Practice 

GitHub GraphQL API https://fireship.io/snippets/github-graphql-merge-pull-request/

#code #dev #tutorial

Install the quiz app 🤓

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

My VS Code Theme

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T06:18:18.998Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
cf1e6905-e8bb-4ca4-8e57-831164fb61be
d9e58257057c9e1d20d96a092081fcc9cd8291566a31bfbda4b7f47771fb851f
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
Houston, we have a problem.
I created a bit of a problem last week by offering to mail a sticker to anybody who submitted a pull request to this repo.
And now I'm stuck with over 600 code changes to review and merge.
I could sit at my computer for a few days and manually merge each one by clicking a button, but luckily we have this awesome thing called code that lets us do this thing called programming to solve problems like this.
In today's video, we'll look at the steps involved in what many consider to be the most important skill of a software developer, Problem solving.
We'll look at 7 different concepts that can help you solve coding problems quickly and reliably.
When you become comfortable with these concepts, You'll be able to ship code faster and be more comfortable in technical interviews.
We can use my real world problem with pull requests as an example.
What we have here is a very specialized use case, but it represents one of the most fundamental problems that software solves, the elimination of manual repetitive work.
Many new developers start their programming journey focused on learning a language, And that's perfectly fine because obviously you need to know a language to solve problems with code.
But when you get to know highly experienced developers, you'll realize that their skill set is It's more about problem solving than it is about knowing every single feature of the language they use.
That's why most of the top companies have you do whiteboarding problems in interviews.
They want insight into your thought process when you approach a software development problem because that skill is much more difficult to learn than memorizing the syntax of a programming language.
It takes years of experience and practice to get good at.
But once you have it down, you'll be able to confidently turn your ideas into reality through the magic of code.
And you won't even need YouTube channels like this for tutorials.
But in the meantime, make sure to subscribe and hit the notification bell so you don't miss the next sticker giveaway.
Now, I want to start things off by saying that everybody's brain is different and there's no one universal right way to solve a problem.
I'm going to show you techniques that work well for me, but follow your instincts and do what works best for you.
The first step is to identify and understand the nature of the problem.
If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.
In our case, we have 600 pull requests on GitHub, and we don't want to have to click this stupid button 600 times.
So what we have here is an internal optimization that will hopefully save us time and money.
But there are many different types of software problems out there.
You might have a bug in existing software, where you have to look through the application stack trace and figure out the root cause.
Or you might have a more abstract problem, like the user experience.
That tends to be such a big problem that many teams break things down into epics, stories, and themes through the agile approach.
When defining a problem, I first like to start with context.
We have more than 600 pull requests on GitHub that must be merged, then explain why that's an issue.
It would take hours of mindless code review and button clicking to get that done.
And lastly, summarize why we should solve this problem.
It can be automated with the GitHub API to save us time and money.
So now that we've decided this problem is worth our time, we can break it down into a bunch of smaller problems.
I remember when I first got into development, I'd often ask myself, where do I start?
I would have a clear vision of what I wanted to build, but just no idea how to put things in motion.
And that brings us to step number 2, research and refine the problem.
And how do you do that?
Of course, you Google it and then click on the 1st Stack Overflow result that comes up.
Just copy and paste that into your code base, and the problem is solved.
In all seriousness, You should go out and research what other people have done to solve the same problem, because you're likely not the first one.
And it's perfectly okay and typically encouraged to use other people's solutions as a starting point.
Just make sure you confidently understand what the code does before using it.
Now in our case, we have a pretty specialized problem.
Not many people have to concurrently merge 600 pull requests.
If possible, discuss the idea with other developers.
I wanna give a shout out to Christian Wheeler on GitHub, who opened an issue that started the discussion about how we can merge all these pull requests.
He provided a bash script that we can run from the command line.
But after doing some more research, we realized that we would need to validate every single pull request by ensuring that each person who made a submission only modified the one file that they were authorized to modify.
And that breaks our larger problem into a smaller one of how do we validate each individual pull request.
Luckily, GitHub has a really nice GraphQL API that we can use to retrieve information from GitHub's servers about our account.
But before I started writing any code, I did Did some research first to make sure the API supported what I wanted to do.
We can further refine the problem into 2 smaller objectives, retrieve all the pull requests from GitHub, and then merge each one individually.
By researching the API documentation on GitHub, I was able to confirm that it supports these requirements.
Now at this point, we have our main problem broken down into a few sub problems, And we've done research on the tools and APIs that can support these requirements.
In most situations, there will be more than one way to solve a problem.
Like, in this case, I could use the GraphQL API or the REST API.
So make sure to weigh the pros and cons of alternative approaches.
And now we're ready for step 3, pseudocode.
In this step, our goal is to write an outline for how we will implement our code.
You could do this on a whiteboard, a piece of paper, or directly in your editor.
The idea is that you focus on the logic of your code without having to worry about the syntax or implementation details.
If you're very comfortable in a language, like in my case JavaScript, I recommend writing your pseudocode in that language.
In this case here, I start with the main function And then inside that function, I know I'll need a GraphQL client.
I'm not sure where I'll get it, so for now I'm just using this as a placeholder.
And I know it's going to need an auth token to authenticate with the GitHub API.
From there, I'll need to retrieve all the open pull requests using a GraphQL query, and then I'll write a function to validate each one before merging it.
In the function body, I'll add some comments about the validations that we want to run inside this function.
They say there are only 2 hard things in programming, cache invalidation and naming things.
An added benefit of writing pseudocode is that you can focus on naming things before your code gets filled up with a bunch of other syntax.
So it's a great way to increase your code readability.
Then from there, we'll set up a for loop.
And if the pull request is valid, then we'll go ahead and merge it with a GraphQL mutation.
And now we have a general idea of how we'll implement our code.
Now because we're working with an API, it's also very valuable to explore that API before you dive into it.
To do that, I'm using an app called Insomnia that allows me to make requests to the API before I actually implement the code in JavaScript.
GraphQL makes this especially nice because we can see the entire schema of the API without ever having to leave this app.
I have an entire video dedicated to GraphQL if you wanna learn more about it, but the code itself is pretty self describing.
Our query first makes a reference to the Git repo, And then we fetch 10 pull requests that have a state of open.
And then we grab the fields that we know we'll need in our algorithm, like the changed files, the author, and so on.
But the bottom line here is that understanding the API will make it much easier to implement the solution when we get to the code.
And now we're ready for the next step, which is optional but highly recommended, test driven development.
If you're building a critical feature that your business depends on, you should test it.
And yet another skill of an experienced developer is understanding what tests will be valuable for that feature.
And really the only way to get good at that is to start writing tests and see where they add value to your code base.
In this example, I think a valuable test would be one that checks our validation logic to ensure that the username that requested a sticker is the same as the username that made the pull request.
The basic process looks like this.
We start by writing a test that describes what we're actually testing.
Then we execute our code using some mock data.
And lastly, we write an expectation expecting the Turn value of that code to be a certain shape.
In this case, it should be the value of true.
From here, we could expand on this by adding additional test cases with more mock data, and we can keep doing this until we're confident that our code can handle any situation that we throw at it.
But one thing you might have noticed is that we're writing this test before we've written or implemented any actual code.
Why would we do that?
It's not always practical, but writing your test before you write your code can be extremely valuable because it takes you through the red green refactor process.
You start by writing a failing test that forces you to think about what you're trying to do.
Then you figure out how to do that thing by implementing some code that makes the test pass.
And from that point, you can reflect on what you've done and try to simplify or optimize your code.
When you write good specs, they'll be able to catch issues in your code much quicker than you can manually debug them.
And they also help prevent regressions in your code when you go back to refactor things later on.
And now we're ready to move on to the easy part, the implementation details.
Now personally, when I go to implement code, I try to get it done as quickly as possible.
Or in other words, have all my tests passing and have a working prototype in the least amount of time possible even if the code is not perfect.
And the reason for that is psychological.
Solving a big problem is a collection of small steps.
And when you try to perfect every small step, It takes a really long time to get to the finish line, and that can be really discouraging.
There's nothing worse for a developer than to work on a project for weeks at a time, only to have the project canceled for one reason or another.
Personally, I like to rush to implement my initial code like I'm doing a hackathon.
When I get to a full working prototype, I now have confidence that this problem can be solved.
And now it's time to relax, get a good night's sleep, and then reflect on the code.
In fact, here's a little pro tip that I've learned over the years.
When you find yourself banging your head against the wall in a small problem for hours, Just take a break and focus your mind somewhere else for 15 minutes.
When you come back, you might magically solve that problem in 5 minutes.
That might sound silly or just Too simple, but Isaac Asimov actually explains that it's your subconscious still solving the problem while your conscious mind is doing something else.
And that's why people often have moments right before they go to sleep or in the shower.
Now that we have a full working prototype, let's take some time to reflect on it.
There There are many things you can look for to improve your code, so here's a short list.
Improve readability by naming things better.
Add comments, remove duplication, improve the time and space complexity of your algorithms, Add caching to reduce cloud computing costs, and improve your error handling, and so on and so on.
The bottom line is that it's much easier to improve a working piece of code than it is to write a Perfect piece of code on the first go around.
The last thing you should keep in mind is that problem solving is a skill you never stop learning.
There's an infinite number of problems to solve, each with its own unique and novel challenges.
And you should take practice seriously.
Practice?
We're talking about practice, man.
At the end of the day, it doesn't matter which Programming language, philosophy, or framework you used to solve the problem, the only thing that does matter is that you solve a problem.
In my opinion, the best way to get good at this skill is to practice.
It's just like a musical instrument.
You're not going to pick it up and start making music right away.
You have to spend a huge amount of time practicing and pushing yourself to overcome new challenges.
When you learn to play the guitar, your fingers develop calluses, which build up over months of painful playing.
When you learn how to program, your mind develops the ability to look at a problem and visualize how a computer system can solve that problem.
To become really good at anything, you have to practice and repeat, practice and repeat until the technique becomes intuitive.
And lastly, get feedback from other developers, especially developers that are more experienced than you.
It's easy to feel self conscious about your code, especially when you really care about it.
But the more you do this, the faster your what the fucks per minute will decrease.
I'm gonna go ahead and wrap things up there.
If you have things you want to add to this video, make sure to leave them in the comments.
And if you want to build entire apps with me, consider becoming a pro member at Fireship IO.
Thanks for watching and I will see you in the next one.

Speaker 0: Houston, we have a problem. I created a bit of a problem last week by offering to mail a sticker to anybody who submitted a pull request to this repo. And now I'm stuck with over 600 code changes to review and merge. I could sit at my computer for a few days and manually merge each one by clicking a button, but luckily we have this awesome thing called code that lets us do this thing called programming to solve problems like this. In today's video, we'll look at the steps involved in what many consider to be the most important skill of a software developer, Problem solving.

We'll look at 7 different concepts that can help you solve coding problems quickly and reliably. When you become comfortable with these concepts, You'll be able to ship code faster and be more comfortable in technical interviews. We can use my real world problem with pull requests as an example. What we have here is a very specialized use case, but it represents one of the most fundamental problems that software solves, the elimination of manual repetitive work. Many new developers start their programming journey focused on learning a language, And that's perfectly fine because obviously you need to know a language to solve problems with code.

But when you get to know highly experienced developers, you'll realize that their skill set is It's more about problem solving than it is about knowing every single feature of the language they use. That's why most of the top companies have you do whiteboarding problems in interviews. They want insight into your thought process when you approach a software development problem because that skill is much more difficult to learn than memorizing the syntax of a programming language. It takes years of experience and practice to get good at. But once you have it down, you'll be able to confidently turn your ideas into reality through the magic of code.

And you won't even need YouTube channels like this for tutorials. But in the meantime, make sure to subscribe and hit the notification bell so you don't miss the next sticker giveaway. Now, I want to start things off by saying that everybody's brain is different and there's no one universal right way to solve a problem. I'm going to show you techniques that work well for me, but follow your instincts and do what works best for you. The first step is to identify and understand the nature of the problem.

If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. In our case, we have 600 pull requests on GitHub, and we don't want to have to click this stupid button 600 times. So what we have here is an internal optimization that will hopefully save us time and money. But there are many different types of software problems out there. You might have a bug in existing software, where you have to look through the application stack trace and figure out the root cause.

Or you might have a more abstract problem, like the user experience. That tends to be such a big problem that many teams break things down into epics, stories, and themes through the agile approach. When defining a problem, I first like to start with context. We have more than 600 pull requests on GitHub that must be merged, then explain why that's an issue. It would take hours of mindless code review and button clicking to get that done.

And lastly, summarize why we should solve this problem. It can be automated with the GitHub API to save us time and money. So now that we've decided this problem is worth our time, we can break it down into a bunch of smaller problems. I remember when I first got into development, I'd often ask myself, where do I start? I would have a clear vision of what I wanted to build, but just no idea how to put things in motion.

And that brings us to step number 2, research and refine the problem. And how do you do that? Of course, you Google it and then click on the 1st Stack Overflow result that comes up. Just copy and paste that into your code base, and the problem is solved. In all seriousness, You should go out and research what other people have done to solve the same problem, because you're likely not the first one.

And it's perfectly okay and typically encouraged to use other people's solutions as a starting point. Just make sure you confidently understand what the code does before using it. Now in our case, we have a pretty specialized problem. Not many people have to concurrently merge 600 pull requests. If possible, discuss the idea with other developers.

I wanna give a shout out to Christian Wheeler on GitHub, who opened an issue that started the discussion about how we can merge all these pull requests. He provided a bash script that we can run from the command line. But after doing some more research, we realized that we would need to validate every single pull request by ensuring that each person who made a submission only modified the one file that they were authorized to modify. And that breaks our larger problem into a smaller one of how do we validate each individual pull request. Luckily, GitHub has a really nice GraphQL API that we can use to retrieve information from GitHub's servers about our account.

But before I started writing any code, I did Did some research first to make sure the API supported what I wanted to do. We can further refine the problem into 2 smaller objectives, retrieve all the pull requests from GitHub, and then merge each one individually. By researching the API documentation on GitHub, I was able to confirm that it supports these requirements. Now at this point, we have our main problem broken down into a few sub problems, And we've done research on the tools and APIs that can support these requirements. In most situations, there will be more than one way to solve a problem.

Like, in this case, I could use the GraphQL API or the REST API. So make sure to weigh the pros and cons of alternative approaches. And now we're ready for step 3, pseudocode. In this step, our goal is to write an outline for how we will implement our code. You could do this on a whiteboard, a piece of paper, or directly in your editor.

The idea is that you focus on the logic of your code without having to worry about the syntax or implementation details. If you're very comfortable in a language, like in my case JavaScript, I recommend writing your pseudocode in that language. In this case here, I start with the main function And then inside that function, I know I'll need a GraphQL client. I'm not sure where I'll get it, so for now I'm just using this as a placeholder. And I know it's going to need an auth token to authenticate with the GitHub API.

From there, I'll need to retrieve all the open pull requests using a GraphQL query, and then I'll write a function to validate each one before merging it. In the function body, I'll add some comments about the validations that we want to run inside this function. They say there are only 2 hard things in programming, cache invalidation and naming things. An added benefit of writing pseudocode is that you can focus on naming things before your code gets filled up with a bunch of other syntax. So it's a great way to increase your code readability.

Then from there, we'll set up a for loop. And if the pull request is valid, then we'll go ahead and merge it with a GraphQL mutation. And now we have a general idea of how we'll implement our code. Now because we're working with an API, it's also very valuable to explore that API before you dive into it. To do that, I'm using an app called Insomnia that allows me to make requests to the API before I actually implement the code in JavaScript.

GraphQL makes this especially nice because we can see the entire schema of the API without ever having to leave this app. I have an entire video dedicated to GraphQL if you wanna learn more about it, but the code itself is pretty self describing. Our query first makes a reference to the Git repo, And then we fetch 10 pull requests that have a state of open. And then we grab the fields that we know we'll need in our algorithm, like the changed files, the author, and so on. But the bottom line here is that understanding the API will make it much easier to implement the solution when we get to the code.

And now we're ready for the next step, which is optional but highly recommended, test driven development. If you're building a critical feature that your business depends on, you should test it. And yet another skill of an experienced developer is understanding what tests will be valuable for that feature. And really the only way to get good at that is to start writing tests and see where they add value to your code base. In this example, I think a valuable test would be one that checks our validation logic to ensure that the username that requested a sticker is the same as the username that made the pull request.

The basic process looks like this. We start by writing a test that describes what we're actually testing. Then we execute our code using some mock data. And lastly, we write an expectation expecting the Turn value of that code to be a certain shape. In this case, it should be the value of true.

From here, we could expand on this by adding additional test cases with more mock data, and we can keep doing this until we're confident that our code can handle any situation that we throw at it. But one thing you might have noticed is that we're writing this test before we've written or implemented any actual code. Why would we do that? It's not always practical, but writing your test before you write your code can be extremely valuable because it takes you through the red green refactor process. You start by writing a failing test that forces you to think about what you're trying to do.

Then you figure out how to do that thing by implementing some code that makes the test pass. And from that point, you can reflect on what you've done and try to simplify or optimize your code. When you write good specs, they'll be able to catch issues in your code much quicker than you can manually debug them. And they also help prevent regressions in your code when you go back to refactor things later on. And now we're ready to move on to the easy part, the implementation details.

Now personally, when I go to implement code, I try to get it done as quickly as possible. Or in other words, have all my tests passing and have a working prototype in the least amount of time possible even if the code is not perfect. And the reason for that is psychological. Solving a big problem is a collection of small steps. And when you try to perfect every small step, It takes a really long time to get to the finish line, and that can be really discouraging.

There's nothing worse for a developer than to work on a project for weeks at a time, only to have the project canceled for one reason or another. Personally, I like to rush to implement my initial code like I'm doing a hackathon. When I get to a full working prototype, I now have confidence that this problem can be solved. And now it's time to relax, get a good night's sleep, and then reflect on the code. In fact, here's a little pro tip that I've learned over the years.

When you find yourself banging your head against the wall in a small problem for hours, Just take a break and focus your mind somewhere else for 15 minutes. When you come back, you might magically solve that problem in 5 minutes. That might sound silly or just Too simple, but Isaac Asimov actually explains that it's your subconscious still solving the problem while your conscious mind is doing something else. And that's why people often have moments right before they go to sleep or in the shower. Now that we have a full working prototype, let's take some time to reflect on it.

There There are many things you can look for to improve your code, so here's a short list. Improve readability by naming things better. Add comments, remove duplication, improve the time and space complexity of your algorithms, Add caching to reduce cloud computing costs, and improve your error handling, and so on and so on. The bottom line is that it's much easier to improve a working piece of code than it is to write a Perfect piece of code on the first go around. The last thing you should keep in mind is that problem solving is a skill you never stop learning.

There's an infinite number of problems to solve, each with its own unique and novel challenges. And you should take practice seriously. Practice? We're talking about practice, man. At the end of the day, it doesn't matter which Programming language, philosophy, or framework you used to solve the problem, the only thing that does matter is that you solve a problem.

In my opinion, the best way to get good at this skill is to practice. It's just like a musical instrument. You're not going to pick it up and start making music right away. You have to spend a huge amount of time practicing and pushing yourself to overcome new challenges. When you learn to play the guitar, your fingers develop calluses, which build up over months of painful playing.

When you learn how to program, your mind develops the ability to look at a problem and visualize how a computer system can solve that problem. To become really good at anything, you have to practice and repeat, practice and repeat until the technique becomes intuitive. And lastly, get feedback from other developers, especially developers that are more experienced than you. It's easy to feel self conscious about your code, especially when you really care about it. But the more you do this, the faster your what the fucks per minute will decrease.

I'm gonna go ahead and wrap things up there. If you have things you want to add to this video, make sure to leave them in the comments. And if you want to build entire apps with me, consider becoming a pro member at Fireship IO. Thanks for watching and I will see you in the next one.
Houston, we have a problem. I created a bit of a problem last week by offering to mail a sticker to anybody who submitted a pull request to this repo.
And now I'm stuck with over 600 code changes to review and merge. I could sit at my computer for a few days and manually merge each one by clicking a button, but luckily we have this awesome thing called code that lets us do this thing called programming to solve problems like this. In today's video, we'll look at the steps involved in what many consider to be the most important skill of a software developer, Problem solving. We'll look at 7 different concepts that can help you solve coding problems quickly and reliably. When you become comfortable with these concepts, You'll be able to ship code faster and be more comfortable in technical interviews. We can use my real world problem with pull requests as an example. What we have here is a very specialized use case, but it represents one of the most fundamental problems that software solves, the elimination of manual repetitive work. Many new developers start their programming journey focused on learning a language, And that's perfectly fine because obviously you need to know a language to solve problems with code. But when you get to know highly experienced developers, you'll realize that their skill set is It's more about problem solving than it is about knowing every single feature of the language they use. That's why most of the top companies have you do whiteboarding problems in interviews. They want insight into your thought process when you approach a software development problem because that skill is much more difficult to learn than memorizing the syntax of a programming language.
software
software development
programming
deep learning
machine learning
computer science
It takes years of experience and practice to get good at. But once you have it down, you'll be able to confidently turn your ideas into reality through the magic of code. And you won't even need YouTube channels like this for tutorials. But in the meantime, make sure to subscribe and hit the notification bell so you don't miss the next sticker giveaway. Now, I want to start things off by saying that everybody's brain is different and there's no one universal right way to solve a problem. I'm going to show you techniques that work well for me, but follow your instincts and do what works best for you. The first step is to identify and understand the nature of the problem.
psychology
youtube
If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. In our case, we have 600 pull requests on GitHub, and we don't want to have to click this stupid button 600 times.
So what we have here is an internal optimization that will hopefully save us time and money. But there are many different types of software problems out there. You might have a bug in existing software, where you have to look through the application stack trace and figure out the root cause. Or you might have a more abstract problem, like the user experience. That tends to be such a big problem that many teams break things down into epics, stories, and themes through the agile approach.
software
software development
bugs
computer science
When defining a problem, I first like to start with context. We have more than 600 pull requests on GitHub that must be merged, then explain why that's an issue. It would take hours of mindless code review and button clicking to get that done.
And lastly, summarize why we should solve this problem. It can be automated with the GitHub API to save us time and money. So now that we've decided this problem is worth our time, we can break it down into a bunch of smaller problems. I remember when I first got into development, I'd often ask myself, where do I start?
software development
I would have a clear vision of what I wanted to build, but just no idea how to put things in motion. And that brings us to step number 2, research and refine the problem. And how do you do that? Of course, you Google it and then click on the 1st Stack Overflow result that comes up.
Just copy and paste that into your code base, and the problem is solved. In all seriousness, You should go out and research what other people have done to solve the same problem, because you're likely not the first one. And it's perfectly okay and typically encouraged to use other people's solutions as a starting point.
solutions
Just make sure you confidently understand what the code does before using it. Now in our case, we have a pretty specialized problem. Not many people have to concurrently merge 600 pull requests. If possible, discuss the idea with other developers. I wanna give a shout out to Christian Wheeler on GitHub, who opened an issue that started the discussion about how we can merge all these pull requests. He provided a bash script that we can run from the command line. But after doing some more research, we realized that we would need to validate every single pull request by ensuring that each person who made a submission only modified the one file that they were authorized to modify. And that breaks our larger problem into a smaller one of how do we validate each individual pull request. Luckily, GitHub has a really nice GraphQL API that we can use to retrieve information from GitHub's servers about our account.
But before I started writing any code, I did Did some research first to make sure the API supported what I wanted to do. We can further refine the problem into 2 smaller objectives, retrieve all the pull requests from GitHub, and then merge each one individually. By researching the API documentation on GitHub, I was able to confirm that it supports these requirements. Now at this point, we have our main problem broken down into a few sub problems, And we've done research on the tools and APIs that can support these requirements. In most situations, there will be more than one way to solve a problem. Like, in this case, I could use the GraphQL API or the REST API. So make sure to weigh the pros and cons of alternative approaches. And now we're ready for step 3, pseudocode. In this step, our goal is to write an outline for how we will implement our code. You could do this on a whiteboard, a piece of paper, or directly in your editor. The idea is that you focus on the logic of your code without having to worry about the syntax or implementation details. If you're very comfortable in a language, like in my case JavaScript, I recommend writing your pseudocode in that language. In this case here, I start with the main function And then inside that function, I know I'll need a GraphQL client. I'm not sure where I'll get it, so for now I'm just using this as a placeholder.
logic
programming
software development
documentation
modeling
And I know it's going to need an auth token to authenticate with the GitHub API. From there, I'll need to retrieve all the open pull requests using a GraphQL query, and then I'll write a function to validate each one before merging it.
In the function body, I'll add some comments about the validations that we want to run inside this function. They say there are only 2 hard things in programming, cache invalidation and naming things. An added benefit of writing pseudocode is that you can focus on naming things before your code gets filled up with a bunch of other syntax. So it's a great way to increase your code readability. Then from there, we'll set up a for loop. And if the pull request is valid, then we'll go ahead and merge it with a GraphQL mutation. And now we have a general idea of how we'll implement our code. Now because we're working with an API, it's also very valuable to explore that API before you dive into it. To do that, I'm using an app called Insomnia that allows me to make requests to the API before I actually implement the code in JavaScript. GraphQL makes this especially nice because we can see the entire schema of the API without ever having to leave this app. I have an entire video dedicated to GraphQL if you wanna learn more about it, but the code itself is pretty self describing. Our query first makes a reference to the Git repo, And then we fetch 10 pull requests that have a state of open.
logic
programming
databases
And then we grab the fields that we know we'll need in our algorithm, like the changed files, the author, and so on.
But the bottom line here is that understanding the API will make it much easier to implement the solution when we get to the code. And now we're ready for the next step, which is optional but highly recommended, test driven development. If you're building a critical feature that your business depends on, you should test it. And yet another skill of an experienced developer is understanding what tests will be valuable for that feature. And really the only way to get good at that is to start writing tests and see where they add value to your code base. In this example, I think a valuable test would be one that checks our validation logic to ensure that the username that requested a sticker is the same as the username that made the pull request.
software development
machine learning
quality assurance
The basic process looks like this. We start by writing a test that describes what we're actually testing. Then we execute our code using some mock data. And lastly, we write an expectation expecting the Turn value of that code to be a certain shape. In this case, it should be the value of true. From here, we could expand on this by adding additional test cases with more mock data, and we can keep doing this until we're confident that our code can handle any situation that we throw at it. But one thing you might have noticed is that we're writing this test before we've written or implemented any actual code.
modeling
programming
logic
Why would we do that? It's not always practical, but writing your test before you write your code can be extremely valuable because it takes you through the red green refactor process. You start by writing a failing test that forces you to think about what you're trying to do. Then you figure out how to do that thing by implementing some code that makes the test pass. And from that point, you can reflect on what you've done and try to simplify or optimize your code. When you write good specs, they'll be able to catch issues in your code much quicker than you can manually debug them.
And they also help prevent regressions in your code when you go back to refactor things later on. And now we're ready to move on to the easy part, the implementation details. Now personally, when I go to implement code, I try to get it done as quickly as possible. Or in other words, have all my tests passing and have a working prototype in the least amount of time possible even if the code is not perfect. And the reason for that is psychological.
programming
Solving a big problem is a collection of small steps. And when you try to perfect every small step, It takes a really long time to get to the finish line, and that can be really discouraging.
There's nothing worse for a developer than to work on a project for weeks at a time, only to have the project canceled for one reason or another. Personally, I like to rush to implement my initial code like I'm doing a hackathon. When I get to a full working prototype, I now have confidence that this problem can be solved. And now it's time to relax, get a good night's sleep, and then reflect on the code.
programming
software development
In fact, here's a little pro tip that I've learned over the years. When you find yourself banging your head against the wall in a small problem for hours, Just take a break and focus your mind somewhere else for 15 minutes. When you come back, you might magically solve that problem in 5 minutes. That might sound silly or just Too simple, but Isaac Asimov actually explains that it's your subconscious still solving the problem while your conscious mind is doing something else. And that's why people often have moments right before they go to sleep or in the shower. Now that we have a full working prototype, let's take some time to reflect on it.
There There are many things you can look for to improve your code, so here's a short list. Improve readability by naming things better. Add comments, remove duplication, improve the time and space complexity of your algorithms, Add caching to reduce cloud computing costs, and improve your error handling, and so on and so on. The bottom line is that it's much easier to improve a working piece of code than it is to write a Perfect piece of code on the first go around. The last thing you should keep in mind is that problem solving is a skill you never stop learning. There's an infinite number of problems to solve, each with its own unique and novel challenges. And you should take practice seriously. Practice? We're talking about practice, man. At the end of the day, it doesn't matter which Programming language, philosophy, or framework you used to solve the problem, the only thing that does matter is that you solve a problem. In my opinion, the best way to get good at this skill is to practice. It's just like a musical instrument. You're not going to pick it up and start making music right away. You have to spend a huge amount of time practicing and pushing yourself to overcome new challenges.
music
solutions
performing arts
teaching
software
logical reasoning
logic
When you learn to play the guitar, your fingers develop calluses, which build up over months of painful playing.
When you learn how to program, your mind develops the ability to look at a problem and visualize how a computer system can solve that problem. To become really good at anything, you have to practice and repeat, practice and repeat until the technique becomes intuitive. And lastly, get feedback from other developers, especially developers that are more experienced than you. It's easy to feel self conscious about your code, especially when you really care about it.
programming
deep learning
software
software development
machine learning
But the more you do this, the faster your what the fucks per minute will decrease.
I'm gonna go ahead and wrap things up there. If you have things you want to add to this video, make sure to leave them in the comments. And if you want to build entire apps with me, consider becoming a pro member at Fireship IO. Thanks for watching and I will see you in the next one.
youtube
video gaming
streaming
Houston, we have a problem. I created a bit of a problem last week by offering to mail a sticker to anybody who submitted a pull request to this repo. And now I'm stuck with over 600 code changes to review and merge. I could sit at my computer for a few days and manually merge each one by clicking a button, but luckily we have this awesome thing called code that lets us do this thing called programming to solve problems like this. In today's video, we'll look at the steps involved in what many consider to be the most important skill of a software developer, Problem solving. We'll look at 7 different concepts that can help you solve coding problems quickly and reliably. When you become comfortable with these concepts, You'll be able to ship code faster and be more comfortable in technical interviews. We can use my real world problem with pull requests as an example. What we have here is a very specialized use case, but it represents one of the most fundamental problems that software solves, the elimination of manual repetitive work. Many new developers start their programming journey focused on learning a language, And that's perfectly fine because obviously you need to know a language to solve problems with code. But when you get to know highly experienced developers, you'll realize that their skill set is It's more about problem solving than it is about knowing every single feature of the language they use. That's why most of the top companies have you do whiteboarding problems in interviews. They want insight into your thought process when you approach a software development problem because that skill is much more difficult to learn than memorizing the syntax of a programming language. It takes years of experience and practice to get good at. But once you have it down, you'll be able to confidently turn your ideas into reality through the magic of code. And you won't even need YouTube channels like this for tutorials. But in the meantime, make sure to subscribe and hit the notification bell so you don't miss the next sticker giveaway. Now, I want to start things off by saying that everybody's brain is different and there's no one universal right way to solve a problem. I'm going to show you techniques that work well for me, but follow your instincts and do what works best for you. The first step is to identify and understand the nature of the problem. If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. In our case, we have 600 pull requests on GitHub, and we don't want to have to click this stupid button 600 times. So what we have here is an internal optimization that will hopefully save us time and money. But there are many different types of software problems out there. You might have a bug in existing software, where you have to look through the application stack trace and figure out the root cause. Or you might have a more abstract problem, like the user experience. That tends to be such a big problem that many teams break things down into epics, stories, and themes through the agile approach. When defining a problem, I first like to start with context. We have more than 600 pull requests on GitHub that must be merged, then explain why that's an issue. It would take hours of mindless code review and button clicking to get that done. And lastly, summarize why we should solve this problem. It can be automated with the GitHub API to save us time and money. So now that we've decided this problem is worth our time, we can break it down into a bunch of smaller problems. I remember when I first got into development, I'd often ask myself, where do I start? I would have a clear vision of what I wanted to build, but just no idea how to put things in motion. And that brings us to step number 2, research and refine the problem. And how do you do that? Of course, you Google it and then click on the 1st Stack Overflow result that comes up. Just copy and paste that into your code base, and the problem is solved. In all seriousness, You should go out and research what other people have done to solve the same problem, because you're likely not the first one. And it's perfectly okay and typically encouraged to use other people's solutions as a starting point. Just make sure you confidently understand what the code does before using it. Now in our case, we have a pretty specialized problem. Not many people have to concurrently merge 600 pull requests. If possible, discuss the idea with other developers. I wanna give a shout out to Christian Wheeler on GitHub, who opened an issue that started the discussion about how we can merge all these pull requests. He provided a bash script that we can run from the command line. But after doing some more research, we realized that we would need to validate every single pull request by ensuring that each person who made a submission only modified the one file that they were authorized to modify. And that breaks our larger problem into a smaller one of how do we validate each individual pull request. Luckily, GitHub has a really nice GraphQL API that we can use to retrieve information from GitHub's servers about our account. But before I started writing any code, I did Did some research first to make sure the API supported what I wanted to do. We can further refine the problem into 2 smaller objectives, retrieve all the pull requests from GitHub, and then merge each one individually. By researching the API documentation on GitHub, I was able to confirm that it supports these requirements. Now at this point, we have our main problem broken down into a few sub problems, And we've done research on the tools and APIs that can support these requirements. In most situations, there will be more than one way to solve a problem. Like, in this case, I could use the GraphQL API or the REST API. So make sure to weigh the pros and cons of alternative approaches. And now we're ready for step 3, pseudocode. In this step, our goal is to write an outline for how we will implement our code. You could do this on a whiteboard, a piece of paper, or directly in your editor. The idea is that you focus on the logic of your code without having to worry about the syntax or implementation details. If you're very comfortable in a language, like in my case JavaScript, I recommend writing your pseudocode in that language. In this case here, I start with the main function And then inside that function, I know I'll need a GraphQL client. I'm not sure where I'll get it, so for now I'm just using this as a placeholder. And I know it's going to need an auth token to authenticate with the GitHub API. From there, I'll need to retrieve all the open pull requests using a GraphQL query, and then I'll write a function to validate each one before merging it. In the function body, I'll add some comments about the validations that we want to run inside this function. They say there are only 2 hard things in programming, cache invalidation and naming things. An added benefit of writing pseudocode is that you can focus on naming things before your code gets filled up with a bunch of other syntax. So it's a great way to increase your code readability. Then from there, we'll set up a for loop. And if the pull request is valid, then we'll go ahead and merge it with a GraphQL mutation. And now we have a general idea of how we'll implement our code. Now because we're working with an API, it's also very valuable to explore that API before you dive into it. To do that, I'm using an app called Insomnia that allows me to make requests to the API before I actually implement the code in JavaScript. GraphQL makes this especially nice because we can see the entire schema of the API without ever having to leave this app. I have an entire video dedicated to GraphQL if you wanna learn more about it, but the code itself is pretty self describing. Our query first makes a reference to the Git repo, And then we fetch 10 pull requests that have a state of open. And then we grab the fields that we know we'll need in our algorithm, like the changed files, the author, and so on. But the bottom line here is that understanding the API will make it much easier to implement the solution when we get to the code. And now we're ready for the next step, which is optional but highly recommended, test driven development. If you're building a critical feature that your business depends on, you should test it. And yet another skill of an experienced developer is understanding what tests will be valuable for that feature. And really the only way to get good at that is to start writing tests and see where they add value to your code base. In this example, I think a valuable test would be one that checks our validation logic to ensure that the username that requested a sticker is the same as the username that made the pull request. The basic process looks like this. We start by writing a test that describes what we're actually testing. Then we execute our code using some mock data. And lastly, we write an expectation expecting the Turn value of that code to be a certain shape. In this case, it should be the value of true. From here, we could expand on this by adding additional test cases with more mock data, and we can keep doing this until we're confident that our code can handle any situation that we throw at it. But one thing you might have noticed is that we're writing this test before we've written or implemented any actual code. Why would we do that? It's not always practical, but writing your test before you write your code can be extremely valuable because it takes you through the red green refactor process. You start by writing a failing test that forces you to think about what you're trying to do. Then you figure out how to do that thing by implementing some code that makes the test pass. And from that point, you can reflect on what you've done and try to simplify or optimize your code. When you write good specs, they'll be able to catch issues in your code much quicker than you can manually debug them. And they also help prevent regressions in your code when you go back to refactor things later on. And now we're ready to move on to the easy part, the implementation details. Now personally, when I go to implement code, I try to get it done as quickly as possible. Or in other words, have all my tests passing and have a working prototype in the least amount of time possible even if the code is not perfect. And the reason for that is psychological. Solving a big problem is a collection of small steps. And when you try to perfect every small step, It takes a really long time to get to the finish line, and that can be really discouraging. There's nothing worse for a developer than to work on a project for weeks at a time, only to have the project canceled for one reason or another. Personally, I like to rush to implement my initial code like I'm doing a hackathon. When I get to a full working prototype, I now have confidence that this problem can be solved. And now it's time to relax, get a good night's sleep, and then reflect on the code. In fact, here's a little pro tip that I've learned over the years. When you find yourself banging your head against the wall in a small problem for hours, Just take a break and focus your mind somewhere else for 15 minutes. When you come back, you might magically solve that problem in 5 minutes. That might sound silly or just Too simple, but Isaac Asimov actually explains that it's your subconscious still solving the problem while your conscious mind is doing something else. And that's why people often have moments right before they go to sleep or in the shower. Now that we have a full working prototype, let's take some time to reflect on it. There There are many things you can look for to improve your code, so here's a short list. Improve readability by naming things better. Add comments, remove duplication, improve the time and space complexity of your algorithms, Add caching to reduce cloud computing costs, and improve your error handling, and so on and so on. The bottom line is that it's much easier to improve a working piece of code than it is to write a Perfect piece of code on the first go around. The last thing you should keep in mind is that problem solving is a skill you never stop learning. There's an infinite number of problems to solve, each with its own unique and novel challenges. And you should take practice seriously. Practice? We're talking about practice, man. At the end of the day, it doesn't matter which Programming language, philosophy, or framework you used to solve the problem, the only thing that does matter is that you solve a problem. In my opinion, the best way to get good at this skill is to practice. It's just like a musical instrument. You're not going to pick it up and start making music right away. You have to spend a huge amount of time practicing and pushing yourself to overcome new challenges. When you learn to play the guitar, your fingers develop calluses, which build up over months of painful playing. When you learn how to program, your mind develops the ability to look at a problem and visualize how a computer system can solve that problem. To become really good at anything, you have to practice and repeat, practice and repeat until the technique becomes intuitive. And lastly, get feedback from other developers, especially developers that are more experienced than you. It's easy to feel self conscious about your code, especially when you really care about it. But the more you do this, the faster your what the fucks per minute will decrease. I'm gonna go ahead and wrap things up there. If you have things you want to add to this video, make sure to leave them in the comments. And if you want to build entire apps with me, consider becoming a pro member at Fireship IO. Thanks for watching and I will see you in the next one.
Houston,
houston
we
we
have
have
a
a
problem.
problem
I
i
created
created
a
a
bit
bit
of
of
a
a
problem
problem
last
last
week
week
by
by
offering
offering
to
to
mail
mail
a
a
sticker
sticker
to
to
anybody
anybody
who
who
submitted
submitted
a
a
pull
pull
request
request
to
to
this
this
repo.
repo
And
and
now
now
I'm
i'm
stuck
stuck
with
with
over
over
600
600
code
code
changes
changes
to
to
review
review
and
and
merge.
merge
I
i
could
could
sit
sit
at
at
my
my
computer
computer
for
for
a
a
few
few
days
days
and
and
manually
manually
merge
merge
each
each
one
one
by
by
clicking
clicking
a
a
button,
button
but
but
luckily
luckily
we
we
have
have
this
this
awesome
awesome
thing
thing
called
called
code
code
that
that
lets
lets
us
us
do
do
this
this
thing
thing
called
called
programming
programming
to
to
solve
solve
problems
problems
like
like
this.
this
In
in
today's
today's
video,
video
we'll
we'll
look
look
at
at
the
the
steps
steps
involved
involved
in
in
what
what
many
many
consider
consider
to
to
be
be
the
the
most
most
important
important
skill
skill
of
of
a
a
software
software
developer,
developer
Problem
problem
solving.
solving
We'll
we'll
look
look
at
at
7
7
different
different
concepts
concepts
that
that
can
can
help
help
you
you
solve
solve
coding
coding
problems
problems
quickly
quickly
and
and
reliably.
reliably
When
when
you
you
become
become
comfortable
comfortable
with
with
these
these
concepts,
concepts
You'll
you'll
be
be
able
able
to
to
ship
ship
code
code
faster
faster
and
and
be
be
more
more
comfortable
comfortable
in
in
technical
technical
interviews.
interviews
We
we
can
can
use
use
my
my
real
real
world
world
problem
problem
with
with
pull
pull
requests
requests
as
as
an
an
example.
example
What
what
we
we
have
have
here
here
is
is
a
a
very
very
specialized
specialized
use
use
case,
case
but
but
it
it
represents
represents
one
one
of
of
the
the
most
most
fundamental
fundamental
problems
problems
that
that
software
software
solves,
solves
the
the
elimination
elimination
of
of
manual
manual
repetitive
repetitive
work.
work
Many
many
new
new
developers
developers
start
start
their
their
programming
programming
journey
journey
focused
focused
on
on
learning
learning
a
a
language,
language
And
and
that's
that's
perfectly
perfectly
fine
fine
because
because
obviously
obviously
you
you
need
need
to
to
know
know
a
a
language
language
to
to
solve
solve
problems
problems
with
with
code.
code
But
but
when
when
you
you
get
get
to
to
know
know
highly
highly
experienced
experienced
developers,
developers
you'll
you'll
realize
realize
that
that
their
their
skill
skill
set
set
is
is
It's
it's
more
more
about
about
problem
problem
solving
solving
than
than
it
it
is
is
about
about
knowing
knowing
every
every
single
single
feature
feature
of
of
the
the
language
language
they
they
use.
use
That's
that's
why
why
most
most
of
of
the
the
top
top
companies
companies
have
have
you
you
do
do
whiteboarding
whiteboarding
problems
problems
in
in
interviews.
interviews
They
they
want
want
insight
insight
into
into
your
your
thought
thought
process
process
when
when
you
you
approach
approach
a
a
software
software
development
development
problem
problem
because
because
that
that
skill
skill
is
is
much
much
more
more
difficult
difficult
to
to
learn
learn
than
than
memorizing
memorizing
the
the
syntax
syntax
of
of
a
a
programming
programming
language.
language
It
it
takes
takes
years
years
of
of
experience
experience
and
and
practice
practice
to
to
get
get
good
good
at.
at
But
but
once
once
you
you
have
have
it
it
down,
down
you'll
you'll
be
be
able
able
to
to
confidently
confidently
turn
turn
your
your
ideas
ideas
into
into
reality
reality
through
through
the
the
magic
magic
of
of
code.
code
And
and
you
you
won't
won't
even
even
need
need
YouTube
youtube
channels
channels
like
like
this
this
for
for
tutorials.
tutorials
But
but
in
in
the
the
meantime,
meantime
make
make
sure
sure
to
to
subscribe
subscribe
and
and
hit
hit
the
the
notification
notification
bell
bell
so
so
you
you
don't
don't
miss
miss
the
the
next
next
sticker
sticker
giveaway.
giveaway
Now,
now
I
i
want
want
to
to
start
start
things
things
off
off
by
by
saying
saying
that
that
everybody's
everybody's
brain
brain
is
is
different
different
and
and
there's
there's
no
no
one
one
universal
universal
right
right
way
way
to
to
solve
solve
a
a
problem.
problem
I'm
i'm
going
going
to
to
show
show
you
you
techniques
techniques
that
that
work
work
well
well
for
for
me,
me
but
but
follow
follow
your
your
instincts
instincts
and
and
do
do
what
what
works
works
best
best
for
for
you.
you
The
the
first
first
step
step
is
is
to
to
identify
identify
and
and
understand
understand
the
the
nature
nature
of
of
the
the
problem.
problem
If
if
I
i
had
had
an
an
hour
hour
to
to
solve
solve
a
a
problem,
problem
I'd
i'd
spend
spend
55
55
minutes
minutes
thinking
thinking
about
about
the
the
problem
problem
and
and
5
5
minutes
minutes
thinking
thinking
about
about
solutions.
solutions
In
in
our
our
case,
case
we
we
have
have
600
600
pull
pull
requests
requests
on
on
GitHub,
github
and
and
we
we
don't
don't
want
want
to
to
have
have
to
to
click
click
this
this
stupid
stupid
button
button
600
600
times.
times
So
so
what
what
we
we
have
have
here
here
is
is
an
an
internal
internal
optimization
optimization
that
that
will
will
hopefully
hopefully
save
save
us
us
time
time
and
and
money.
money
But
but
there
there
are
are
many
many
different
different
types
types
of
of
software
software
problems
problems
out
out
there.
there
You
you
might
might
have
have
a
a
bug
bug
in
in
existing
existing
software,
software
where
where
you
you
have
have
to
to
look
look
through
through
the
the
application
application
stack
stack
trace
trace
and
and
figure
figure
out
out
the
the
root
root
cause.
cause
Or
or
you
you
might
might
have
have
a
a
more
more
abstract
abstract
problem,
problem
like
like
the
the
user
user
experience.
experience
That
that
tends
tends
to
to
be
be
such
such
a
a
big
big
problem
problem
that
that
many
many
teams
teams
break
break
things
things
down
down
into
into
epics,
epics
stories,
stories
and
and
themes
themes
through
through
the
the
agile
agile
approach.
approach
When
when
defining
defining
a
a
problem,
problem
I
i
first
first
like
like
to
to
start
start
with
with
context.
context
We
we
have
have
more
more
than
than
600
600
pull
pull
requests
requests
on
on
GitHub
github
that
that
must
must
be
be
merged,
merged
then
then
explain
explain
why
why
that's
that's
an
an
issue.
issue
It
it
would
would
take
take
hours
hours
of
of
mindless
mindless
code
code
review
review
and
and
button
button
clicking
clicking
to
to
get
get
that
that
done.
done
And
and
lastly,
lastly
summarize
summarize
why
why
we
we
should
should
solve
solve
this
this
problem.
problem
It
it
can
can
be
be
automated
automated
with
with
the
the
GitHub
github
API
api
to
to
save
save
us
us
time
time
and
and
money.
money
So
so
now
now
that
that
we've
we've
decided
decided
this
this
problem
problem
is
is
worth
worth
our
our
time,
time
we
we
can
can
break
break
it
it
down
down
into
into
a
a
bunch
bunch
of
of
smaller
smaller
problems.
problems
I
i
remember
remember
when
when
I
i
first
first
got
got
into
into
development,
development
I'd
i'd
often
often
ask
ask
myself,
myself
where
where
do
do
I
i
start?
start
I
i
would
would
have
have
a
a
clear
clear
vision
vision
of
of
what
what
I
i
wanted
wanted
to
to
build,
build
but
but
just
just
no
no
idea
idea
how
how
to
to
put
put
things
things
in
in
motion.
motion
And
and
that
that
brings
brings
us
us
to
to
step
step
number
number
2,
2
research
research
and
and
refine
refine
the
the
problem.
problem
And
and
how
how
do
do
you
you
do
do
that?
that
Of
of
course,
course
you
you
Google
google
it
it
and
and
then
then
click
click
on
on
the
the
1st
1st
Stack
stack
Overflow
overflow
result
result
that
that
comes
comes
up.
up
Just
just
copy
copy
and
and
paste
paste
that
that
into
into
your
your
code
code
base,
base
and
and
the
the
problem
problem
is
is
solved.
solved
In
in
all
all
seriousness,
seriousness
You
you
should
should
go
go
out
out
and
and
research
research
what
what
other
other
people
people
have
have
done
done
to
to
solve
solve
the
the
same
same
problem,
problem
because
because
you're
you're
likely
likely
not
not
the
the
first
first
one.
one
And
and
it's
it's
perfectly
perfectly
okay
okay
and
and
typically
typically
encouraged
encouraged
to
to
use
use
other
other
people's
people's
solutions
solutions
as
as
a
a
starting
starting
point.
point
Just
just
make
make
sure
sure
you
you
confidently
confidently
understand
understand
what
what
the
the
code
code
does
does
before
before
using
using
it.
it
Now
now
in
in
our
our
case,
case
we
we
have
have
a
a
pretty
pretty
specialized
specialized
problem.
problem
Not
not
many
many
people
people
have
have
to
to
concurrently
concurrently
merge
merge
600
600
pull
pull
requests.
requests
If
if
possible,
possible
discuss
discuss
the
the
idea
idea
with
with
other
other
developers.
developers
I
i
wanna
wanna
give
give
a
a
shout
shout
out
out
to
to
Christian
christian
Wheeler
wheeler
on
on
GitHub,
github
who
who
opened
opened
an
an
issue
issue
that
that
started
started
the
the
discussion
discussion
about
about
how
how
we
we
can
can
merge
merge
all
all
these
these
pull
pull
requests.
requests
He
he
provided
provided
a
a
bash
bash
script
script
that
that
we
we
can
can
run
run
from
from
the
the
command
command
line.
line
But
but
after
after
doing
doing
some
some
more
more
research,
research
we
we
realized
realized
that
that
we
we
would
would
need
need
to
to
validate
validate
every
every
single
single
pull
pull
request
request
by
by
ensuring
ensuring
that
that
each
each
person
person
who
who
made
made
a
a
submission
submission
only
only
modified
modified
the
the
one
one
file
file
that
that
they
they
were
were
authorized
authorized
to
to
modify.
modify
And
and
that
that
breaks
breaks
our
our
larger
larger
problem
problem
into
into
a
a
smaller
smaller
one
one
of
of
how
how
do
do
we
we
validate
validate
each
each
individual
individual
pull
pull
request.
request
Luckily,
luckily
GitHub
github
has
has
a
a
really
really
nice
nice
GraphQL
graphql
API
api
that
that
we
we
can
can
use
use
to
to
retrieve
retrieve
information
information
from
from
GitHub's
github's
servers
servers
about
about
our
our
account.
account
But
but
before
before
I
i
started
started
writing
writing
any
any
code,
code
I
i
did
did
Did
did
some
some
research
research
first
first
to
to
make
make
sure
sure
the
the
API
api
supported
supported
what
what
I
i
wanted
wanted
to
to
do.
do
We
we
can
can
further
further
refine
refine
the
the
problem
problem
into
into
2
2
smaller
smaller
objectives,
objectives
retrieve
retrieve
all
all
the
the
pull
pull
requests
requests
from
from
GitHub,
github
and
and
then
then
merge
merge
each
each
one
one
individually.
individually
By
by
researching
researching
the
the
API
api
documentation
documentation
on
on
GitHub,
github
I
i
was
was
able
able
to
to
confirm
confirm
that
that
it
it
supports
supports
these
these
requirements.
requirements
Now
now
at
at
this
this
point,
point
we
we
have
have
our
our
main
main
problem
problem
broken
broken
down
down
into
into
a
a
few
few
sub
sub
problems,
problems
And
and
we've
we've
done
done
research
research
on
on
the
the
tools
tools
and
and
APIs
apis
that
that
can
can
support
support
these
these
requirements.
requirements
In
in
most
most
situations,
situations
there
there
will
will
be
be
more
more
than
than
one
one
way
way
to
to
solve
solve
a
a
problem.
problem
Like,
like
in
in
this
this
case,
case
I
i
could
could
use
use
the
the
GraphQL
graphql
API
api
or
or
the
the
REST
rest
API.
api
So
so
make
make
sure
sure
to
to
weigh
weigh
the
the
pros
pros
and
and
cons
cons
of
of
alternative
alternative
approaches.
approaches
And
and
now
now
we're
we're
ready
ready
for
for
step
step
3,
3
pseudocode.
pseudocode
In
in
this
this
step,
step
our
our
goal
goal
is
is
to
to
write
write
an
an
outline
outline
for
for
how
how
we
we
will
will
implement
implement
our
our
code.
code
You
you
could
could
do
do
this
this
on
on
a
a
whiteboard,
whiteboard
a
a
piece
piece
of
of
paper,
paper
or
or
directly
directly
in
in
your
your
editor.
editor
The
the
idea
idea
is
is
that
that
you
you
focus
focus
on
on
the
the
logic
logic
of
of
your
your
code
code
without
without
having
having
to
to
worry
worry
about
about
the
the
syntax
syntax
or
or
implementation
implementation
details.
details
If
if
you're
you're
very
very
comfortable
comfortable
in
in
a
a
language,
language
like
like
in
in
my
my
case
case
JavaScript,
javascript
I
i
recommend
recommend
writing
writing
your
your
pseudocode
pseudocode
in
in
that
that
language.
language
In
in
this
this
case
case
here,
here
I
i
start
start
with
with
the
the
main
main
function
function
And
and
then
then
inside
inside
that
that
function,
function
I
i
know
know
I'll
i'll
need
need
a
a
GraphQL
graphql
client.
client
I'm
i'm
not
not
sure
sure
where
where
I'll
i'll
get
get
it,
it
so
so
for
for
now
now
I'm
i'm
just
just
using
using
this
this
as
as
a
a
placeholder.
placeholder
And
and
I
i
know
know
it's
it's
going
going
to
to
need
need
an
an
auth
auth
token
token
to
to
authenticate
authenticate
with
with
the
the
GitHub
github
API.
api
From
from
there,
there
I'll
i'll
need
need
to
to
retrieve
retrieve
all
all
the
the
open
open
pull
pull
requests
requests
using
using
a
a
GraphQL
graphql
query,
query
and
and
then
then
I'll
i'll
write
write
a
a
function
function
to
to
validate
validate
each
each
one
one
before
before
merging
merging
it.
it
In
in
the
the
function
function
body,
body
I'll
i'll
add
add
some
some
comments
comments
about
about
the
the
validations
validations
that
that
we
we
want
want
to
to
run
run
inside
inside
this
this
function.
function
They
they
say
say
there
there
are
are
only
only
2
2
hard
hard
things
things
in
in
programming,
programming
cache
cache
invalidation
invalidation
and
and
naming
naming
things.
things
An
an
added
added
benefit
benefit
of
of
writing
writing
pseudocode
pseudocode
is
is
that
that
you
you
can
can
focus
focus
on
on
naming
naming
things
things
before
before
your
your
code
code
gets
gets
filled
filled
up
up
with
with
a
a
bunch
bunch
of
of
other
other
syntax.
syntax
So
so
it's
it's
a
a
great
great
way
way
to
to
increase
increase
your
your
code
code
readability.
readability
Then
then
from
from
there,
there
we'll
we'll
set
set
up
up
a
a
for
for
loop.
loop
And
and
if
if
the
the
pull
pull
request
request
is
is
valid,
valid
then
then
we'll
we'll
go
go
ahead
ahead
and
and
merge
merge
it
it
with
with
a
a
GraphQL
graphql
mutation.
mutation
And
and
now
now
we
we
have
have
a
a
general
general
idea
idea
of
of
how
how
we'll
we'll
implement
implement
our
our
code.
code
Now
now
because
because
we're
we're
working
working
with
with
an
an
API,
api
it's
it's
also
also
very
very
valuable
valuable
to
to
explore
explore
that
that
API
api
before
before
you
you
dive
dive
into
into
it.
it
To
to
do
do
that,
that
I'm
i'm
using
using
an
an
app
app
called
called
Insomnia
insomnia
that
that
allows
allows
me
me
to
to
make
make
requests
requests
to
to
the
the
API
api
before
before
I
i
actually
actually
implement
implement
the
the
code
code
in
in
JavaScript.
javascript
GraphQL
graphql
makes
makes
this
this
especially
especially
nice
nice
because
because
we
we
can
can
see
see
the
the
entire
entire
schema
schema
of
of
the
the
API
api
without
without
ever
ever
having
having
to
to
leave
leave
this
this
app.
app
I
i
have
have
an
an
entire
entire
video
video
dedicated
dedicated
to
to
GraphQL
graphql
if
if
you
you
wanna
wanna
learn
learn
more
more
about
about
it,
it
but
but
the
the
code
code
itself
itself
is
is
pretty
pretty
self
self
describing.
describing
Our
our
query
query
first
first
makes
makes
a
a
reference
reference
to
to
the
the
Git
git
repo,
repo
And
and
then
then
we
we
fetch
fetch
10
10
pull
pull
requests
requests
that
that
have
have
a
a
state
state
of
of
open.
open
And
and
then
then
we
we
grab
grab
the
the
fields
fields
that
that
we
we
know
know
we'll
we'll
need
need
in
in
our
our
algorithm,
algorithm
like
like
the
the
changed
changed
files,
files
the
the
author,
author
and
and
so
so
on.
on
But
but
the
the
bottom
bottom
line
line
here
here
is
is
that
that
understanding
understanding
the
the
API
api
will
will
make
make
it
it
much
much
easier
easier
to
to
implement
implement
the
the
solution
solution
when
when
we
we
get
get
to
to
the
the
code.
code
And
and
now
now
we're
we're
ready
ready
for
for
the
the
next
next
step,
step
which
which
is
is
optional
optional
but
but
highly
highly
recommended,
recommended
test
test
driven
driven
development.
development
If
if
you're
you're
building
building
a
a
critical
critical
feature
feature
that
that
your
your
business
business
depends
depends
on,
on
you
you
should
should
test
test
it.
it
And
and
yet
yet
another
another
skill
skill
of
of
an
an
experienced
experienced
developer
developer
is
is
understanding
understanding
what
what
tests
tests
will
will
be
be
valuable
valuable
for
for
that
that
feature.
feature
And
and
really
really
the
the
only
only
way
way
to
to
get
get
good
good
at
at
that
that
is
is
to
to
start
start
writing
writing
tests
tests
and
and
see
see
where
where
they
they
add
add
value
value
to
to
your
your
code
code
base.
base
In
in
this
this
example,
example
I
i
think
think
a
a
valuable
valuable
test
test
would
would
be
be
one
one
that
that
checks
checks
our
our
validation
validation
logic
logic
to
to
ensure
ensure
that
that
the
the
username
username
that
that
requested
requested
a
a
sticker
sticker
is
is
the
the
same
same
as
as
the
the
username
username
that
that
made
made
the
the
pull
pull
request.
request
The
the
basic
basic
process
process
looks
looks
like
like
this.
this
We
we
start
start
by
by
writing
writing
a
a
test
test
that
that
describes
describes
what
what
we're
we're
actually
actually
testing.
testing
Then
then
we
we
execute
execute
our
our
code
code
using
using
some
some
mock
mock
data.
data
And
and
lastly,
lastly
we
we
write
write
an
an
expectation
expectation
expecting
expecting
the
the
Turn
turn
value
value
of
of
that
that
code
code
to
to
be
be
a
a
certain
certain
shape.
shape
In
in
this
this
case,
case
it
it
should
should
be
be
the
the
value
value
of
of
true.
true
From
from
here,
here
we
we
could
could
expand
expand
on
on
this
this
by
by
adding
adding
additional
additional
test
test
cases
cases
with
with
more
more
mock
mock
data,
data
and
and
we
we
can
can
keep
keep
doing
doing
this
this
until
until
we're
we're
confident
confident
that
that
our
our
code
code
can
can
handle
handle
any
any
situation
situation
that
that
we
we
throw
throw
at
at
it.
it
But
but
one
one
thing
thing
you
you
might
might
have
have
noticed
noticed
is
is
that
that
we're
we're
writing
writing
this
this
test
test
before
before
we've
we've
written
written
or
or
implemented
implemented
any
any
actual
actual
code.
code
Why
why
would
would
we
we
do
do
that?
that
It's
it's
not
not
always
always
practical,
practical
but
but
writing
writing
your
your
test
test
before
before
you
you
write
write
your
your
code
code
can
can
be
be
extremely
extremely
valuable
valuable
because
because
it
it
takes
takes
you
you
through
through
the
the
red
red
green
green
refactor
refactor
process.
process
You
you
start
start
by
by
writing
writing
a
a
failing
failing
test
test
that
that
forces
forces
you
you
to
to
think
think
about
about
what
what
you're
you're
trying
trying
to
to
do.
do
Then
then
you
you
figure
figure
out
out
how
how
to
to
do
do
that
that
thing
thing
by
by
implementing
implementing
some
some
code
code
that
that
makes
makes
the
the
test
test
pass.
pass
And
and
from
from
that
that
point,
point
you
you
can
can
reflect
reflect
on
on
what
what
you've
you've
done
done
and
and
try
try
to
to
simplify
simplify
or
or
optimize
optimize
your
your
code.
code
When
when
you
you
write
write
good
good
specs,
specs
they'll
they'll
be
be
able
able
to
to
catch
catch
issues
issues
in
in
your
your
code
code
much
much
quicker
quicker
than
than
you
you
can
can
manually
manually
debug
debug
them.
them
And
and
they
they
also
also
help
help
prevent
prevent
regressions
regressions
in
in
your
your
code
code
when
when
you
you
go
go
back
back
to
to
refactor
refactor
things
things
later
later
on.
on
And
and
now
now
we're
we're
ready
ready
to
to
move
move
on
on
to
to
the
the
easy
easy
part,
part
the
the
implementation
implementation
details.
details
Now
now
personally,
personally
when
when
I
i
go
go
to
to
implement
implement
code,
code
I
i
try
try
to
to
get
get
it
it
done
done
as
as
quickly
quickly
as
as
possible.
possible
Or
or
in
in
other
other
words,
words
have
have
all
all
my
my
tests
tests
passing
passing
and
and
have
have
a
a
working
working
prototype
prototype
in
in
the
the
least
least
amount
amount
of
of
time
time
possible
possible
even
even
if
if
the
the
code
code
is
is
not
not
perfect.
perfect
And
and
the
the
reason
reason
for
for
that
that
is
is
psychological.
psychological
Solving
solving
a
a
big
big
problem
problem
is
is
a
a
collection
collection
of
of
small
small
steps.
steps
And
and
when
when
you
you
try
try
to
to
perfect
perfect
every
every
small
small
step,
step
It
it
takes
takes
a
a
really
really
long
long
time
time
to
to
get
get
to
to
the
the
finish
finish
line,
line
and
and
that
that
can
can
be
be
really
really
discouraging.
discouraging
There's
there's
nothing
nothing
worse
worse
for
for
a
a
developer
developer
than
than
to
to
work
work
on
on
a
a
project
project
for
for
weeks
weeks
at
at
a
a
time,
time
only
only
to
to
have
have
the
the
project
project
canceled
canceled
for
for
one
one
reason
reason
or
or
another.
another
Personally,
personally
I
i
like
like
to
to
rush
rush
to
to
implement
implement
my
my
initial
initial
code
code
like
like
I'm
i'm
doing
doing
a
a
hackathon.
hackathon
When
when
I
i
get
get
to
to
a
a
full
full
working
working
prototype,
prototype
I
i
now
now
have
have
confidence
confidence
that
that
this
this
problem
problem
can
can
be
be
solved.
solved
And
and
now
now
it's
it's
time
time
to
to
relax,
relax
get
get
a
a
good
good
night's
night's
sleep,
sleep
and
and
then
then
reflect
reflect
on
on
the
the
code.
code
In
in
fact,
fact
here's
here's
a
a
little
little
pro
pro
tip
tip
that
that
I've
i've
learned
learned
over
over
the
the
years.
years
When
when
you
you
find
find
yourself
yourself
banging
banging
your
your
head
head
against
against
the
the
wall
wall
in
in
a
a
small
small
problem
problem
for
for
hours,
hours
Just
just
take
take
a
a
break
break
and
and
focus
focus
your
your
mind
mind
somewhere
somewhere
else
else
for
for
15
15
minutes.
minutes
When
when
you
you
come
come
back,
back
you
you
might
might
magically
magically
solve
solve
that
that
problem
problem
in
in
5
5
minutes.
minutes
That
that
might
might
sound
sound
silly
silly
or
or
just
just
Too
too
simple,
simple
but
but
Isaac
isaac
Asimov
asimov
actually
actually
explains
explains
that
that
it's
it's
your
your
subconscious
subconscious
still
still
solving
solving
the
the
problem
problem
while
while
your
your
conscious
conscious
mind
mind
is
is
doing
doing
something
something
else.
else
And
and
that's
that's
why
why
people
people
often
often
have
have
moments
moments
right
right
before
before
they
they
go
go
to
to
sleep
sleep
or
or
in
in
the
the
shower.
shower
Now
now
that
that
we
we
have
have
a
a
full
full
working
working
prototype,
prototype
let's
let's
take
take
some
some
time
time
to
to
reflect
reflect
on
on
it.
it
There
there
There
there
are
are
many
many
things
things
you
you
can
can
look
look
for
for
to
to
improve
improve
your
your
code,
code
so
so
here's
here's
a
a
short
short
list.
list
Improve
improve
readability
readability
by
by
naming
naming
things
things
better.
better
Add
add
comments,
comments
remove
remove
duplication,
duplication
improve
improve
the
the
time
time
and
and
space
space
complexity
complexity
of
of
your
your
algorithms,
algorithms
Add
add
caching
caching
to
to
reduce
reduce
cloud
cloud
computing
computing
costs,
costs
and
and
improve
improve
your
your
error
error
handling,
handling
and
and
so
so
on
on
and
and
so
so
on.
on
The
the
bottom
bottom
line
line
is
is
that
that
it's
it's
much
much
easier
easier
to
to
improve
improve
a
a
working
working
piece
piece
of
of
code
code
than
than
it
it
is
is
to
to
write
write
a
a
Perfect
perfect
piece
piece
of
of
code
code
on
on
the
the
first
first
go
go
around.
around
The
the
last
last
thing
thing
you
you
should
should
keep
keep
in
in
mind
mind
is
is
that
that
problem
problem
solving
solving
is
is
a
a
skill
skill
you
you
never
never
stop
stop
learning.
learning
There's
there's
an
an
infinite
infinite
number
number
of
of
problems
problems
to
to
solve,
solve
each
each
with
with
its
its
own
own
unique
unique
and
and
novel
novel
challenges.
challenges
And
and
you
you
should
should
take
take
practice
practice
seriously.
seriously
Practice?
practice
We're
we're
talking
talking
about
about
practice,
practice
man.
man
At
at
the
the
end
end
of
of
the
the
day,
day
it
it
doesn't
doesn't
matter
matter
which
which
Programming
programming
language,
language
philosophy,
philosophy
or
or
framework
framework
you
you
used
used
to
to
solve
solve
the
the
problem,
problem
the
the
only
only
thing
thing
that
that
does
does
matter
matter
is
is
that
that
you
you
solve
solve
a
a
problem.
problem
In
in
my
my
opinion,
opinion
the
the
best
best
way
way
to
to
get
get
good
good
at
at
this
this
skill
skill
is
is
to
to
practice.
practice
It's
it's
just
just
like
like
a
a
musical
musical
instrument.
instrument
You're
you're
not
not
going
going
to
to
pick
pick
it
it
up
up
and
and
start
start
making
making
music
music
right
right
away.
away
You
you
have
have
to
to
spend
spend
a
a
huge
huge
amount
amount
of
of
time
time
practicing
practicing
and
and
pushing
pushing
yourself
yourself
to
to
overcome
overcome
new
new
challenges.
challenges
When
when
you
you
learn
learn
to
to
play
play
the
the
guitar,
guitar
your
your
fingers
fingers
develop
develop
calluses,
calluses
which
which
build
build
up
up
over
over
months
months
of
of
painful
painful
playing.
playing
When
when
you
you
learn
learn
how
how
to
to
program,
program
your
your
mind
mind
develops
develops
the
the
ability
ability
to
to
look
look
at
at
a
a
problem
problem
and
and
visualize
visualize
how
how
a
a
computer
computer
system
system
can
can
solve
solve
that
that
problem.
problem
To
to
become
become
really
really
good
good
at
at
anything,
anything
you
you
have
have
to
to
practice
practice
and
and
repeat,
repeat
practice
practice
and
and
repeat
repeat
until
until
the
the
technique
technique
becomes
becomes
intuitive.
intuitive
And
and
lastly,
lastly
get
get
feedback
feedback
from
from
other
other
developers,
developers
especially
especially
developers
developers
that
that
are
are
more
more
experienced
experienced
than
than
you.
you
It's
it's
easy
easy
to
to
feel
feel
self
self
conscious
conscious
about
about
your
your
code,
code
especially
especially
when
when
you
you
really
really
care
care
about
about
it.
it
But
but
the
the
more
more
you
you
do
do
this,
this
the
the
faster
faster
your
your
what
what
the
the
fucks
fucks
per
per
minute
minute
will
will
decrease.
decrease
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
If
if
you
you
have
have
things
things
you
you
want
want
to
to
add
add
to
to
this
this
video,
video
make
make
sure
sure
to
to
leave
leave
them
them
in
in
the
the
comments.
comments
And
and
if
if
you
you
want
want
to
to
build
build
entire
entire
apps
apps
with
with
me,
me
consider
consider
becoming
becoming
a
a
pro
pro
member
member
at
at
Fireship
fireship
IO.
io
Thanks
thanks
for
for
watching
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The importance of problem-solving in software development is emphasized, with examples given such as using pull requests and researching the problem. Different techniques for problem solving, including validating a code and merging individual code files, are discussed. Practice and learning are recommended, and one can become a pro member at Fireship IO if interested in building apps. Acquiring pull requests and merging each one individually is emphasized, along with researching, refine, and merging pull requests. Testing before merging code and expanding on the process are recommended, and practicing and learning to overcome challenges in code development is suggested.
Problem-Solving for Developers - A Beginner's Guide
Houston, we have a problem. I created a bit of a problem last week by offering to mail a sticker to anybody who submitted a pull request to this repo. And now I'm stuck with over 600 code changes to review and merge. I could sit at my computer for a few days and manually merge each one by clicking a button, but luckily we have this awesome thing called code that lets us do this thing called programming to solve problems like this. In today's video, we'll look at the steps involved in what many consider to be the most important skill of a software developer, Problem solving. We'll look at 7 different concepts that can help you solve coding problems quickly and reliably. When you become comfortable with these concepts, You'll be able to ship code faster and be more comfortable in technical interviews. We can use my real world problem with pull requests as an example. What we have here is a very specialized use case, but it represents one of the most fundamental problems that software solves, the elimination of manual repetitive work. Many new developers start their programming journey focused on learning a language, And that's perfectly fine because obviously you need to know a language to solve problems with code. But when you get to know highly experienced developers, you'll realize that their skill set is It's more about problem solving than it is about knowing every single feature of the language they use. That's why most of the top companies have you do whiteboarding problems in interviews. They want insight into your thought process when you approach a software development problem because that skill is much more difficult to learn than memorizing the syntax of a programming language. It takes years of experience and practice to get good at. But once you have it down, you'll be able to confidently turn your ideas into reality through the magic of code. And you won't even need YouTube channels like this for tutorials. But in the meantime, make sure to subscribe and hit the notification bell so you don't miss the next sticker giveaway. Now, I want to start things off by saying that everybody's brain is different and there's no one universal right way to solve a problem. I'm going to show you techniques that work well for me, but follow your instincts and do what works best for you. The first step is to identify and understand the nature of the problem. If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. In our case, we have 600 pull requests on GitHub, and we don't want to have to click this stupid button 600 times. So what we have here is an internal optimization that will hopefully save us time and money. But there are many different types of software problems out there. You might have a bug in existing software, where you have to look through the application stack trace and figure out the root cause. Or you might have a more abstract problem, like the user experience. That tends to be such a big problem that many teams break things down into epics, stories, and themes through the agile approach. When defining a problem, I first like to start with context. We have more than 600 pull requests on GitHub that must be merged, then explain why that's an issue. It would take hours of mindless code review and button clicking to get that done. And lastly, summarize why we should solve this problem. It can be automated with the GitHub API to save us time and money. So now that we've decided this problem is worth our time, we can break it down into a bunch of smaller problems. I remember when I first got into development, I'd often ask myself, where do I start? I would have a clear vision of what I wanted to build, but just no idea how to put things in motion. And that brings us to step number 2, research and refine the problem. And how do you do that? Of course, you Google it and then click on the 1st Stack Overflow result that comes up. Just copy and paste that into your code base, and the problem is solved. In all seriousness, You should go out and research what other people have done to solve the same problem, because you're likely not the first one. And it's perfectly okay and typically encouraged to use other people's solutions as a starting point. Just make sure you confidently understand what the code does before using it. Now in our case, we have a pretty specialized problem. Not many people have to concurrently merge 600 pull requests. If possible, discuss the idea with other developers. I wanna give a shout out to Christian Wheeler on GitHub, who opened an issue that started the discussion about how we can merge all these pull requests. He provided a bash script that we can run from the command line. But after doing some more research, we realized that we would need to validate every single pull request by ensuring that each person who made a submission only modified the one file that they were authorized to modify. And that breaks our larger problem into a smaller one of how do we validate each individual pull request. Luckily, GitHub has a really nice GraphQL API that we can use to retrieve information from GitHub's servers about our account. But before I started writing any code, I did Did some research first to make sure the API supported what I wanted to do. We can further refine the problem into 2 smaller objectives, retrieve all the pull requests from GitHub, and then merge each one individually. By researching the API documentation on GitHub, I was able to confirm that it supports these requirements. Now at this point, we have our main problem broken down into a few sub problems, And we've done research on the tools and APIs that can support these requirements. In most situations, there will be more than one way to solve a problem. Like, in this case, I could use the GraphQL API or the REST API. So make sure to weigh the pros and cons of alternative approaches. And now we're ready for step 3, pseudocode. In this step, our goal is to write an outline for how we will implement our code. You could do this on a whiteboard, a piece of paper, or directly in your editor. The idea is that you focus on the logic of your code without having to worry about the syntax or implementation details. If you're very comfortable in a language, like in my case JavaScript, I recommend writing your pseudocode in that language. In this case here, I start with the main function And then inside that function, I know I'll need a GraphQL client. I'm not sure where I'll get it, so for now I'm just using this as a placeholder. And I know it's going to need an auth token to authenticate with the GitHub API. From there, I'll need to retrieve all the open pull requests using a GraphQL query, and then I'll write a function to validate each one before merging it. In the function body, I'll add some comments about the validations that we want to run inside this function. They say there are only 2 hard things in programming, cache invalidation and naming things. An added benefit of writing pseudocode is that you can focus on naming things before your code gets filled up with a bunch of other syntax. So it's a great way to increase your code readability. Then from there, we'll set up a for loop. And if the pull request is valid, then we'll go ahead and merge it with a GraphQL mutation. And now we have a general idea of how we'll implement our code. Now because we're working with an API, it's also very valuable to explore that API before you dive into it. To do that, I'm using an app called Insomnia that allows me to make requests to the API before I actually implement the code in JavaScript. GraphQL makes this especially nice because we can see the entire schema of the API without ever having to leave this app. I have an entire video dedicated to GraphQL if you wanna learn more about it, but the code itself is pretty self describing. Our query first makes a reference to the Git repo, And then we fetch 10 pull requests that have a state of open. And then we grab the fields that we know we'll need in our algorithm, like the changed files, the author, and so on. But the bottom line here is that understanding the API will make it much easier to implement the solution when we get to the code. And now we're ready for the next step, which is optional but highly recommended, test driven development. If you're building a critical feature that your business depends on, you should test it. And yet another skill of an experienced developer is understanding what tests will be valuable for that feature. And really the only way to get good at that is to start writing tests and see where they add value to your code base. In this example, I think a valuable test would be one that checks our validation logic to ensure that the username that requested a sticker is the same as the username that made the pull request. The basic process looks like this. We start by writing a test that describes what we're actually testing. Then we execute our code using some mock data. And lastly, we write an expectation expecting the Turn value of that code to be a certain shape. In this case, it should be the value of true. From here, we could expand on this by adding additional test cases with more mock data, and we can keep doing this until we're confident that our code can handle any situation that we throw at it. But one thing you might have noticed is that we're writing this test before we've written or implemented any actual code. Why would we do that? It's not always practical, but writing your test before you write your code can be extremely valuable because it takes you through the red green refactor process. You start by writing a failing test that forces you to think about what you're trying to do. Then you figure out how to do that thing by implementing some code that makes the test pass. And from that point, you can reflect on what you've done and try to simplify or optimize your code. When you write good specs, they'll be able to catch issues in your code much quicker than you can manually debug them. And they also help prevent regressions in your code when you go back to refactor things later on. And now we're ready to move on to the easy part, the implementation details. Now personally, when I go to implement code, I try to get it done as quickly as possible. Or in other words, have all my tests passing and have a working prototype in the least amount of time possible even if the code is not perfect. And the reason for that is psychological. Solving a big problem is a collection of small steps. And when you try to perfect every small step, It takes a really long time to get to the finish line, and that can be really discouraging. There's nothing worse for a developer than to work on a project for weeks at a time, only to have the project canceled for one reason or another. Personally, I like to rush to implement my initial code like I'm doing a hackathon. When I get to a full working prototype, I now have confidence that this problem can be solved. And now it's time to relax, get a good night's sleep, and then reflect on the code. In fact, here's a little pro tip that I've learned over the years. When you find yourself banging your head against the wall in a small problem for hours, Just take a break and focus your mind somewhere else for 15 minutes. When you come back, you might magically solve that problem in 5 minutes. That might sound silly or just Too simple, but Isaac Asimov actually explains that it's your subconscious still solving the problem while your conscious mind is doing something else. And that's why people often have moments right before they go to sleep or in the shower. Now that we have a full working prototype, let's take some time to reflect on it. There There are many things you can look for to improve your code, so here's a short list. Improve readability by naming things better. Add comments, remove duplication, improve the time and space complexity of your algorithms, Add caching to reduce cloud computing costs, and improve your error handling, and so on and so on. The bottom line is that it's much easier to improve a working piece of code than it is to write a Perfect piece of code on the first go around. The last thing you should keep in mind is that problem solving is a skill you never stop learning. There's an infinite number of problems to solve, each with its own unique and novel challenges. And you should take practice seriously. Practice? We're talking about practice, man. At the end of the day, it doesn't matter which Programming language, philosophy, or framework you used to solve the problem, the only thing that does matter is that you solve a problem. In my opinion, the best way to get good at this skill is to practice. It's just like a musical instrument. You're not going to pick it up and start making music right away. You have to spend a huge amount of time practicing and pushing yourself to overcome new challenges. When you learn to play the guitar, your fingers develop calluses, which build up over months of painful playing. When you learn how to program, your mind develops the ability to look at a problem and visualize how a computer system can solve that problem. To become really good at anything, you have to practice and repeat, practice and repeat until the technique becomes intuitive. And lastly, get feedback from other developers, especially developers that are more experienced than you. It's easy to feel self conscious about your code, especially when you really care about it. But the more you do this, the faster your what the fucks per minute will decrease. I'm gonna go ahead and wrap things up there. If you have things you want to add to this video, make sure to leave them in the comments. And if you want to build entire apps with me, consider becoming a pro member at Fireship IO. Thanks for watching and I will see you in the next one.
The importance of problem-solving in software development is emphasized, with examples given such as using pull requests and researching the problem. Different techniques for problem solving, including validating a code and merging individual code files, are discussed. Practice and learning are recommended, and one can become a pro member at Fireship IO if interested in building apps. Acquiring pull requests and merging each one individually is emphasized, along with researching, refine, and merging pull requests. Testing before merging code and expanding on the process are recommended, and practicing and learning to overcome challenges in code development is suggested.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Problem-Solving for Developers - A Beginner's Guide 
        and a small summary : The importance of problem-solving in software development is emphasized, with examples given such as using pull requests and researching the problem. Different techniques for problem solving, including validating a code and merging individual code files, are discussed. Practice and learning are recommended, and one can become a pro member at Fireship IO if interested in building apps. Acquiring pull requests and merging each one individually is emphasized, along with researching, refine, and merging pull requests. Testing before merging code and expanding on the process are recommended, and practicing and learning to overcome challenges in code development is suggested.
        [/INST]
        
        Generate the video : Houston, we have a problem. I created a bit of a problem last week by offering to mail a sticker to anybody who submitted a pull request to this repo. And now I'm stuck with over 600 code changes to review and merge. I could sit at my computer for a few days and manually merge each one by clicking a button, but luckily we have this awesome thing called code that lets us do this thing called programming to solve problems like this. In today's video, we'll look at the steps involved in what many consider to be the most important skill of a software developer, Problem solving. We'll look at 7 different concepts that can help you solve coding problems quickly and reliably. When you become comfortable with these concepts, You'll be able to ship code faster and be more comfortable in technical interviews. We can use my real world problem with pull requests as an example. What we have here is a very specialized use case, but it represents one of the most fundamental problems that software solves, the elimination of manual repetitive work. Many new developers start their programming journey focused on learning a language, And that's perfectly fine because obviously you need to know a language to solve problems with code. But when you get to know highly experienced developers, you'll realize that their skill set is It's more about problem solving than it is about knowing every single feature of the language they use. That's why most of the top companies have you do whiteboarding problems in interviews. They want insight into your thought process when you approach a software development problem because that skill is much more difficult to learn than memorizing the syntax of a programming language. It takes years of experience and practice to get good at. But once you have it down, you'll be able to confidently turn your ideas into reality through the magic of code. And you won't even need YouTube channels like this for tutorials. But in the meantime, make sure to subscribe and hit the notification bell so you don't miss the next sticker giveaway. Now, I want to start things off by saying that everybody's brain is different and there's no one universal right way to solve a problem. I'm going to show you techniques that work well for me, but follow your instincts and do what works best for you. The first step is to identify and understand the nature of the problem. If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. In our case, we have 600 pull requests on GitHub, and we don't want to have to click this stupid button 600 times. So what we have here is an internal optimization that will hopefully save us time and money. But there are many different types of software problems out there. You might have a bug in existing software, where you have to look through the application stack trace and figure out the root cause. Or you might have a more abstract problem, like the user experience. That tends to be such a big problem that many teams break things down into epics, stories, and themes through the agile approach. When defining a problem, I first like to start with context. We have more than 600 pull requests on GitHub that must be merged, then explain why that's an issue. It would take hours of mindless code review and button clicking to get that done. And lastly, summarize why we should solve this problem. It can be automated with the GitHub API to save us time and money. So now that we've decided this problem is worth our time, we can break it down into a bunch of smaller problems. I remember when I first got into development, I'd often ask myself, where do I start? I would have a clear vision of what I wanted to build, but just no idea how to put things in motion. And that brings us to step number 2, research and refine the problem. And how do you do that? Of course, you Google it and then click on the 1st Stack Overflow result that comes up. Just copy and paste that into your code base, and the problem is solved. In all seriousness, You should go out and research what other people have done to solve the same problem, because you're likely not the first one. And it's perfectly okay and typically encouraged to use other people's solutions as a starting point. Just make sure you confidently understand what the code does before using it. Now in our case, we have a pretty specialized problem. Not many people have to concurrently merge 600 pull requests. If possible, discuss the idea with other developers. I wanna give a shout out to Christian Wheeler on GitHub, who opened an issue that started the discussion about how we can merge all these pull requests. He provided a bash script that we can run from the command line. But after doing some more research, we realized that we would need to validate every single pull request by ensuring that each person who made a submission only modified the one file that they were authorized to modify. And that breaks our larger problem into a smaller one of how do we validate each individual pull request. Luckily, GitHub has a really nice GraphQL API that we can use to retrieve information from GitHub's servers about our account. But before I started writing any code, I did Did some research first to make sure the API supported what I wanted to do. We can further refine the problem into 2 smaller objectives, retrieve all the pull requests from GitHub, and then merge each one individually. By researching the API documentation on GitHub, I was able to confirm that it supports these requirements. Now at this point, we have our main problem broken down into a few sub problems, And we've done research on the tools and APIs that can support these requirements. In most situations, there will be more than one way to solve a problem. Like, in this case, I could use the GraphQL API or the REST API. So make sure to weigh the pros and cons of alternative approaches. And now we're ready for step 3, pseudocode. In this step, our goal is to write an outline for how we will implement our code. You could do this on a whiteboard, a piece of paper, or directly in your editor. The idea is that you focus on the logic of your code without having to worry about the syntax or implementation details. If you're very comfortable in a language, like in my case JavaScript, I recommend writing your pseudocode in that language. In this case here, I start with the main function And then inside that function, I know I'll need a GraphQL client. I'm not sure where I'll get it, so for now I'm just using this as a placeholder. And I know it's going to need an auth token to authenticate with the GitHub API. From there, I'll need to retrieve all the open pull requests using a GraphQL query, and then I'll write a function to validate each one before merging it. In the function body, I'll add some comments about the validations that we want to run inside this function. They say there are only 2 hard things in programming, cache invalidation and naming things. An added benefit of writing pseudocode is that you can focus on naming things before your code gets filled up with a bunch of other syntax. So it's a great way to increase your code readability. Then from there, we'll set up a for loop. And if the pull request is valid, then we'll go ahead and merge it with a GraphQL mutation. And now we have a general idea of how we'll implement our code. Now because we're working with an API, it's also very valuable to explore that API before you dive into it. To do that, I'm using an app called Insomnia that allows me to make requests to the API before I actually implement the code in JavaScript. GraphQL makes this especially nice because we can see the entire schema of the API without ever having to leave this app. I have an entire video dedicated to GraphQL if you wanna learn more about it, but the code itself is pretty self describing. Our query first makes a reference to the Git repo, And then we fetch 10 pull requests that have a state of open. And then we grab the fields that we know we'll need in our algorithm, like the changed files, the author, and so on. But the bottom line here is that understanding the API will make it much easier to implement the solution when we get to the code. And now we're ready for the next step, which is optional but highly recommended, test driven development. If you're building a critical feature that your business depends on, you should test it. And yet another skill of an experienced developer is understanding what tests will be valuable for that feature. And really the only way to get good at that is to start writing tests and see where they add value to your code base. In this example, I think a valuable test would be one that checks our validation logic to ensure that the username that requested a sticker is the same as the username that made the pull request. The basic process looks like this. We start by writing a test that describes what we're actually testing. Then we execute our code using some mock data. And lastly, we write an expectation expecting the Turn value of that code to be a certain shape. In this case, it should be the value of true. From here, we could expand on this by adding additional test cases with more mock data, and we can keep doing this until we're confident that our code can handle any situation that we throw at it. But one thing you might have noticed is that we're writing this test before we've written or implemented any actual code. Why would we do that? It's not always practical, but writing your test before you write your code can be extremely valuable because it takes you through the red green refactor process. You start by writing a failing test that forces you to think about what you're trying to do. Then you figure out how to do that thing by implementing some code that makes the test pass. And from that point, you can reflect on what you've done and try to simplify or optimize your code. When you write good specs, they'll be able to catch issues in your code much quicker than you can manually debug them. And they also help prevent regressions in your code when you go back to refactor things later on. And now we're ready to move on to the easy part, the implementation details. Now personally, when I go to implement code, I try to get it done as quickly as possible. Or in other words, have all my tests passing and have a working prototype in the least amount of time possible even if the code is not perfect. And the reason for that is psychological. Solving a big problem is a collection of small steps. And when you try to perfect every small step, It takes a really long time to get to the finish line, and that can be really discouraging. There's nothing worse for a developer than to work on a project for weeks at a time, only to have the project canceled for one reason or another. Personally, I like to rush to implement my initial code like I'm doing a hackathon. When I get to a full working prototype, I now have confidence that this problem can be solved. And now it's time to relax, get a good night's sleep, and then reflect on the code. In fact, here's a little pro tip that I've learned over the years. When you find yourself banging your head against the wall in a small problem for hours, Just take a break and focus your mind somewhere else for 15 minutes. When you come back, you might magically solve that problem in 5 minutes. That might sound silly or just Too simple, but Isaac Asimov actually explains that it's your subconscious still solving the problem while your conscious mind is doing something else. And that's why people often have moments right before they go to sleep or in the shower. Now that we have a full working prototype, let's take some time to reflect on it. There There are many things you can look for to improve your code, so here's a short list. Improve readability by naming things better. Add comments, remove duplication, improve the time and space complexity of your algorithms, Add caching to reduce cloud computing costs, and improve your error handling, and so on and so on. The bottom line is that it's much easier to improve a working piece of code than it is to write a Perfect piece of code on the first go around. The last thing you should keep in mind is that problem solving is a skill you never stop learning. There's an infinite number of problems to solve, each with its own unique and novel challenges. And you should take practice seriously. Practice? We're talking about practice, man. At the end of the day, it doesn't matter which Programming language, philosophy, or framework you used to solve the problem, the only thing that does matter is that you solve a problem. In my opinion, the best way to get good at this skill is to practice. It's just like a musical instrument. You're not going to pick it up and start making music right away. You have to spend a huge amount of time practicing and pushing yourself to overcome new challenges. When you learn to play the guitar, your fingers develop calluses, which build up over months of painful playing. When you learn how to program, your mind develops the ability to look at a problem and visualize how a computer system can solve that problem. To become really good at anything, you have to practice and repeat, practice and repeat until the technique becomes intuitive. And lastly, get feedback from other developers, especially developers that are more experienced than you. It's easy to feel self conscious about your code, especially when you really care about it. But the more you do this, the faster your what the fucks per minute will decrease. I'm gonna go ahead and wrap things up there. If you have things you want to add to this video, make sure to leave them in the comments. And if you want to build entire apps with me, consider becoming a pro member at Fireship IO. Thanks for watching and I will see you in the next one.
        