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.
Top comments (25)
Say it again for the people in the back! So many times I've told myself I'll remember it, and news flash....I never do.
It's a very good practice to get into writing it all down.
If you take up software development professionally, as you advance you are juggling more and more information.
If something is not supplied in written form, ensure that it is.
Another piece of advice is to email them back with your understanding and get confirmation. This can occasionally jog their memory for anything that has been missed and gives you a written trace in case of any disagreement.
The more data on your own project the better
I try to write the why of a piece of code, what was the thought process that made it like it is. As well as what it is supposed to do.
Try to contribute to some open source projects :)
First
It's great that you're honest about this - I bet we've all had a post that just won't get out for one reason or another. I try and remember that it's just a blog post - it doesn't need to be perfect - and that I can change it afterwards based on feedback. But I do make sure I've got a few friendly people I can show it to before it goes out for the first time, just to get a little bit of confidence.
So I try not to feel too pressured (stupid advice) and just get something out quickly. Then, I try to change it as I get more information, feedback, change my mind. Yes, it's the Minimum Viable Post!
Anyway - feedback!
Wireframes
I'd just like to say that, while I know lots of people love wireframe software, I try to avoid them. Why? I find them a timesink. By the time I've drawn my wireframe I could've written the same thing in CSS/HTML in the actual, usable, first iteration of the application (if it's even a web app with a ui). So for me design tends to be done on the back of a napkin in around thirty seconds.
Timelines
If I'm approaching a prioritized list of features, I try and forget any deadline that might be in play. Why? Because I know I've delivered the most value to the customer in the time available. Focusing on a deadline makes me feel like I have to be 'finished', that everthing should be done and 'over'. The truth is that my software projects, like all art, is never finished, only abandoned. I just try to make sure that it's abandoned in the best state possible.
Anyway, just a few thoughts. Keep up the good work!
Thanks! Totally agree on wireframes, think that it tends to be different for everyone -- I find it really helpful (though usually more time consuming). I like that idea on deadlines and timelines! I am really type A and so they're kind of helpful for me! Thanks for the feedback and advice, these are great thoughts!
I’ve been working on a repo where people could find projects to work on to improve their skills and it also has some extra features (not only the project/app name). Check it out on GitHub. I hope this would be helpful! ☺️
Thanks for your post! Keep it going! 👏🏻
Interesting repo, that'll definitely be useful to help others build stuff including content creators too.
My preferred website for coding challenges is codingame.
I like that the challenges have a visual representation (for example programming how a robot behaves) in any programming language and they make challenges between them continously.
As for project ideas, here is nice list
github.com/karan/Projects
Also, regarding project features, one thing to be aware of is scope creep
en.m.wikipedia.org/wiki/Scope_creep
Here is my favorite article on the subject
codeproject.com/Articles/2079/The-...
One of the sites I've seen mention Ed in other places is leetcode. It looks like puzzles and challenges designed to help you do well in interviews with tech companies. I'm curious if folks around here have any opinions on it.
I find it quite interesting and useful to horn/test one's problem-solving ability.
Nice article and read, thx!
Between identifying the problem and the MVP, I personally like to add and focus on one question, the most important one for the solution: what's the core process?
When I've got that I'm good to go ;)
Hi Ali. I'm fairly new (currently self-learning) and have been hesitant about beginning a personal project. I realize that there are many benefits to beginning a project and hope to figure something out soon.
Thank you for the resources and especially the link to the site that shows example projects. Those are geared to Ruby on Rails for the back end. Can these also be implemented using Node?
btw... Your content is great!
totally! May be more difficult depending on the Node framework, but totally can be done. and thank you!
Think about what can go wrong - I like this one. Premeditatio malorum or the pre-meditation of evils is an old stoic exercise and helps you to prepare for the inevitable setbacks and problems you'll have to face not just in development, but in life.
While this is important on an individual level, it works on project level as well. It's called pre-mortem when before starting to work, the project team gathers and imagines that the project failed. Then they try to reverse engineer what went wrong.
Have you ever done a pre-mortem in your projects?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.