Moving Past Tutorials: Receiving a Problem to Solve

Ali Spittel on March 23, 2019

The first step to solving any problem is understanding what the problem actually is. Sometimes specifications and intentions for projects can be ... [Read Full]
markdown guide

You'll have to remember the discussion and the specifications after the fact, and relying on your memory alone is not enough!

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 :)



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.

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!


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.


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!


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.


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.


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!


Also, regarding project features, one thing to be aware of is scope creep

Here is my favorite article on the subject


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?


Great article Ali.

About finding a problem to solve, If possible I would try to find a real problem that someone is having. Think about boring things that you or your friends and family have to do regularly that could be solved by tech.

Or if it´s not enough, look around you and try to find common problems affecting a group of people.

After you find your problem, I believe focus and prioritization are really important and it's a thing I struggle a bit as I have many ideas and technologies that want to try at the same time which is not very productive.

I think like you said, defining the MVP and identify the key features and prioritize them, splitting them into smaller tasks can help a lot.


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.


This is a great list of the thoughts that go into planning a project.
Can't wait to


Nice article. One question. Are wireframes using tools like Figma necessary or hand sketch with pen and paper can do the job??


And if you want to know whether the javascript file doesn't need to stick with html pages, except for one small file, call the javascript file.

From the experiment the css file must be attached to the html body, maybe other if the css is packaged in javascript.

this is the experiment:


code of conduct - report abuse