The first step to solving any problem is understanding what the problem actually is. Sometimes specifications and intentions for projects can be vague. Also, once you understand the problem you have to start outlining the general features before you start thinking of the code.

There are a couple of different ways you may be given a project -- either verbally in a meeting or in writing. Also, there are a few different types of problems you might get -- ones for work, school, or code puzzles for interviews practice. We'll tackle all of these scenarios in this post!

Finding a problem to solve

In some cases, you will have a problem given to you, usually through work or an educational program. That being said, sometimes if you're self-studying or given a broader assignment, you will have to come up with a project yourself. In that case, there are a few places to look. The first is to do code challenges to get better with working through puzzles. Here are some great sites to try:

• Tons of challenges with difficulties attached: CodeWars
• Another code challenge site with more consistency: HackerRank
• Mathematical coding problems: Project Euler

If you are instead looking for an application to build, I would first think about the things that interest you or the subfield you are trying to enter in tech. If you're still not sure what to build, here is an excellent list of projects you can build. Also, re-creating games tends to be pretty challenging and fun to build.

What you'll need to understand

There are two main categories of information that you will need to know before starting to work on your project. The first is the features. What are the attributes that make up the final project? What does the client want the final product to include? How do those features need to be implemented? Which ones do you prioritize? Make sure to ask questions to get these details.

The other half is the intent -- why is this app being built, whose life will it improve, who will be the user. Understanding that gives you more context so that you can implement features in a way that will benefit end users, and it will also give you a purpose when you're coding.

Make sure you are asking questions in order to fully understand both the what and the why for your project.

Taking notes

Please, take notes. No matter if your assignment is written or given verbally, writing down your thoughts is so important. Doubly so if you are getting the assignment in a meeting. You'll have to remember the discussion and the specifications after the fact, and relying on your memory alone is not enough! Write down your thoughts as the meeting goes along. I use Google Keep for writing notes, and I don't worry too much about formatting at that point. I just write.

If you're getting an assignment in a written format, make sure you read through it a couple of times. I would even take notes on requirements, and make sure to email, comment, or ask in person about any contextual questions

What is the MVP?

Once you have the actual project, it's important to figure out what components of it are necessary to the project. Which ones are essential and which are bonuses? What is the minimum viable product that you can build to put something out to users? You can then iterate and add the next set of features. Even if you run out of time, you will still have something to ship.

Whenever I'm given a project, I first create an unordered list of all the requested attributes. Then I start grouping them into priority levels -- the really essential ones, the nice to haves, and the really pie in the sky ones that would need a lot of thought and work to implement. Then, depending on the project workflow, I'll turn the steps into a to-do list for myself with detailed notes, make GitHub issues for them, or make Trello cards. Then I get started on the really essential ones and then move my way up.

What could go wrong?

It may be super pessimistic, but it's also worth thinking about what could go wrong while you're building out your project. What blockers may you run into, what might you have to learn, and what parts of the application will be really hard to build. If you're drawing out a timeline, all these factors are important. Don't be overly optimistic, or you may end up not meeting the deadline.

Wireframes

One of the first things I do on a project is to create wireframes. What will the user interface look like (if there is one), and how will users interact with it. On larger teams, you'll have designers, but if you're working for yourself or learning, you're your own designer and developer. You can go in depth and learn something like Sketch or Figma. But, you can also go more minimalistic and sketch something on a whiteboard, or use a tool like Balsamiq or Wireframe. Just having an idea of what you're building is super helpful, and makes the coding process a lot smoother.

Timelines

Another thing to think about is deadlines. Do you have one given to you (like in school or many workplaces), or are you expected to chart out your own path? If you are setting your own deadlines, be realistic but also hold yourself to the deadlines you set for yourself. If you're given a deadline, make sure to hit the minimum viable product before trying any of the fancy stuff, graduating or having something to ship is so much more important than perfection in most cases.

My challenge to you

The homework for this portion of the course is:

• Find a problem to solve.
• Identify an MVP for your project.
• Create a list of key features, ordered by importance.
• Create wireframes for the said problem if applicable.
• Create a timeline for that project if you haven't been given one.

Updates on new posts

I'm going to be totally honest, I get really nervous about putting out new content sometimes. And, that's why it took me so long to put this out, even though it's been written for a while. I'm going to try to be better in the future, thanks for sticking with me!

If you want to hear about new posts when they come out, here's a link to subscribe to my email list.

Thanks for reading, and I'll be back with more soon.