loading...
Cover image for Moving Past Tutorials: a course on problem solving for programmers

Moving Past Tutorials: a course on problem solving for programmers

aspittel profile image Ali Spittel Updated on ・2 min read

In my experience working with programmers at beginner and intermediate levels, the most difficult part of programming is putting the pieces of the program together and knowing which pieces to actually use. And, most programming courses don't teach that part. They teach the pieces individually and then expect students to put the pieces together. So, I'm building a multimedia course that will focus entirely on problem solving, how to move past tutorials, and why certain choices should be made when you're programming.

This course will take the format of a DEV series, so it will be totally free and accessible to anyone. I will be releasing a new post each week so that I have time to get any feedback from the previous week's post and incorporate it into the next post, as well as balance creating content and the rest of my work.

I'm a strong believer in making content accessible to people with different learning styles, so this course will be very interactive and use different mediums to reinforce the material. Most of the concepts will be written and diagrammed. Then there will be example problems within the concept for you to solve, finally there will be videos explaining how to solve the practice problems after you attempt them yourself.

This course will be mostly language agnostic, though I will be solving my problems in Python since it's pretty understandable if you know a different programming language. This course won't teach the fundamentals of programming, though. Before starting, I would learn the fundamentals at least at a basic capacity. The fundamentals needed prior to this course are: variables, lists/arrays, hash tables/dictionaries/objects (whatever they're called in your programming language of choice), loops, conditionals, and functions. If you're looking to get started, here's a list of free resources for learning those.

The topics will include breaking down problems both for coding puzzles and for more realistic business problems, debugging, thinking abstractly, pseudocoding, what to think about when optimizing code, refactoring, approaching problems, edge cases, and what to learn outside of code that will help you code.

I'm really excited to work on this project, and would love your ideas and feedback through out. Feel free to comment below!

Posted on by:

aspittel profile

Ali Spittel

@aspittel

Passionate about education, Python, JavaScript, and code art.

Discussion

markdown guide
 

Can I suggest:

  • problem definition - asking the right questions
  • proof of concept solutions
  • demonstrating code as a way to verify the problem has been solved
  • figuring out if parts of your problem have already been solved (avoiding not-invented-here syndrome)
  • generating and evaluating proposed solutions - hypothesis testing
  • structuring code in the large - laying out the solution for a non trivial system
  • solving a problem from scratch vs working with an existing code base
 

These are great ideas! thank you!

 
 

Looking forward to this! Just curious, will this have any focus on the Gang of Four Design Patterns? I've read on them before and the specific problems they've solved, and seen them indirectly used in much of my job's code frameworks but still want to try learning about them more later on.

 

Oh cool! I could totally write about design patterns in here. That’s a great idea!

 

I agree for sure. Design patterns and other best-practices are often not fully appreciated by newcomers because most of the simple examples are not big or complex enough to show off why you might want to use something like object orientation, the state pattern, dependency injection, etc.

 

When exposing beginners to design patterns, it's important to tell them specific patterns are language-dependent. Many have more idiomatic solutions in some languages, or solve problems some languages don't have (or refuse to acknowledge as problems worth solving).

It's easy to hear about a pattern as "here is a good way to code" and try to use it everywhere. But a pattern has 2 parts: problem & solution, and one has to understand the problem first.

I think the specific patterns in the GoF book were Java-centric (?), although their deeper legacy was to show an organized way to talk about patterns.

As you asked, the GoF book was written before Java so no.

 

I can't wait for design pattern 😍😍

 

As a product manager, I've found that the biggest problem new devs have is navigating and dissecting our fairly expansive codebase. It's one thing to know how to code, it's an entirely different thing to jump into a mature, commercial-grade product.

 

Absolutely! I am sort of a "newb", but I have worked on a few projects that I didn't understand all of the codebase even if I knew the framework/library. I am fearful of applying to jobs and so stuck in tutorial hell precisely because of that hinderance. Brilliant suggestion, Wesley.

 

Sounds like a great idea for another 10,000 foot approach to programming..

Rather than another 'Hello World!'

 

Needed. My God the first time I was in a saas, it was terrifying. Been in other code bases before taking apart things, etc, but that was a whole other monster of 10 years worth of code.

 

This so hard. I really need to learn this.

 

What I have trouble (or at least I think I have trouble with) is the actual design and architecture of programs, like how would you go about deciding what classes and functions to make, and how to go about writing code that's clean and extensible without being too verbose.

What you pointed out does ring true to me in that code is easy to write, but good code isn't always so easy.

 

I highly recommend Sandi Metz's book Practical Object Oriented Design in Ruby (aka POODR). (The choice of Ruby is not essential to the content.) It deals with exactly the themes you ask, and gives ways to think about such decisions. The central criterion guiding the book is not "how to write perfect code you can set in stone and never change", but "how to write code that will be easiest to evolve".

The book is surprisingly concise but very clear. I've been programming for ~2 decades, and still it was interesting & refreshing to read.

She has many lectures online if you want to sample her style.

 

That sounds like exactly what I need, thanks! I'll check it out soon.

Also, do you know any analogs to this for functional programming?

 

You may want to take a look to SOLID principles and GRASP patterns.

 

Great idea!

Can I suggest a couple of things for the todo list? 😂

  • an awesome name (so that we can create a tag)
  • killer songs to include somehow (with "thank u, next" as a linked list you raised the bar)

💃
🕺

 

haha yes! amazing! maybe the next course will be about data structures through the lens of pop culture... I just claimed the #movingpasttutorials tag!

 

As someone who only just recently got out of tutorials, I couldn't agree with you more. The path I take when learning something new is, tackle the docs first. If I really can't make sense of them, look up a general explanation to the new topic, then go back into the docs. When I exclusively used YouTube tutorials, I was scared of looking at docs but now I like them way more than YouTube tutorials. YouTube may be outdated, the content creator might've talked too much, or maybe the content creator was flat out wrong. I can always trust the docs!

 

Hmm, I am afraid I am not getting something; You are saying that this course will not teach the fundamentals of programming (like most programming courses do) but will focus more on problem-solving and analyzing.
But then you give an example of the course topics including variables, lists, and objects. Isn't these concepts what most programming courses focus on?

 

So those are the things to learn before this. So study those elsewhere, then we will be using those concepts to solve problems.

 

Oh, OK! Good to know. Then I would suggest changing "This course will primarily focus on..." to something more explanatory, since "This course" seems to be referring to the course you will curate :)

 

wow.... nice one.... Although i am not a beginner Dev.... But I am looking forward to it... Learning is not limited, I love learning new things... I am sure i will be able to learn one or two things from it...

 

Hi Ali!

I spent the weekend digging up resources for this same purpose. However, I’ll just recommend what I already know and have personally found fruitful.

The most effective (by personal anecdote) and general framework I know of is polya problem solving. In practice, I find that this technique is especially good at getting beginners (and experts) to slow down and plan the implementation rather than rush to a shaky implementation: en.m.wikipedia.org/wiki/How_to_Sol...

I highly recommend checking out the wiki page and, if interested, picking up “How to Solve It.”

A second, more in-depth set of tools I’ve found for problem decomposition is in “The Art of Insight in Science and Engineering” by Sanjoy Mahajan. The applications in this book are all towards approximation questions in physical sciences, but I argue that they are also a beautiful articulation of several key foundations for computational thinking.

Lastly, “The Algorithm Design Manual” by Skiena gives some excellent advice on how to think about finding counter examples to a heuristic in the first chapter (think small, think exhaustively, try extreme cases, etc.) I find this to be a common skill set for assessing the correctness of an algorithm you think you up.

Lastly, since problem solving is a practice before it is a theory, I highly recommend “A Mind for Numbers” by Barbara Oakley as a practical manual on what constitutes effective practice for mathematical subjects.

 

I think you've hit on a problem that has not been solved well so far. Did you know most courses/tutorials on coding don't actually help junior coders? And in college, coding has always been one of the courses with the lowest survival rate. So, I'm curious how you'll teach junior coders to apply their "coding tools" to solve problems. Do you have any pre-release content or links?

 

Awesome, I'm looking forward to this series!

You're talking about learning the fundamentals of programming before starting this course, but I would say that problem solving is the fundament of everything else programming-related. The most important thing about programming is computational thinking: learning to think like a computer and how it would solve a problem. The programming language you're using is just a tool to aid you in solving that problem.

 

A functional programmer would probably disagree with the "learn to think like a computer" requirement. The approach has a stronger focus on identifying the problem and the required functionality to solve it. The specific mechanics or even language needed are not really relevant.

 

How to find information on solving bugs. Letting sometimes intuition being a guide when searching or looking for a solution. Letting go.

I have reached far and wide sometimes to explain why something happened or an enlightened workaround.

Useful skill and I'm finally really applying it in a productive fashion.

 

Looking forward to the series. When will it start and where do I sign up?

 

It will be on here! You can get notifications by following me, and it will be starting this week!

 

Hi Ali! Have you started with this yet? Not sure if Im visualizing the right way. Thanks

 

Performance has always been a pet peeve of mine.

It took some years, but I've finally beaten the "It must be X!" out of my system when I run into a perf issue. I've gotten disciplined enough to test a system, even if it means building a throwaway mockup simulation(ie github.com/richardhendricks/GT-sta...), to determine where the real performance problems are located and attack those instead of what other people or my gut tells me. I don't know if stories about improving performance on ancient Minecraft mods would be interesting to anyone, but maybe I'll write up the couple times I've done it.

 

I'm late to this but have found learning functional programming to be very useful in teaching how to think about problems. It has a thought process that is independent of the language you use and really helps to focus on function and data.

 

Looking forward to your project. Stuck at the moving past tutorial stage. Help lol

 

Interesting proejct there Ali. I had those in past and still do. I think it'd be interesting to see where this goes. I like the problem solving approach. I think open source projects often help out in some way but with lack of reward from it, often I move out of contribution in it. Looking forward to your series.

 

So, when does it start ? Where do we go from here and how do we follow the ongoing series ?

 

It will be on here, and I'm going to be posting each week! I would just follow my account to follow along!

 

" . . . the most difficult part of programming is putting the pieces of the program together and knowing which pieces to actually use. And, most programming courses don't teach that part. They teach the pieces individually and then expect students to put the pieces together."

If you don't mind, could you please elaborate on "pieces of program?" What does it mean? I am very interested in what you come-up with. I will follow your journey and, hopefully, contribute productively if I can.

 

This is great, looking forward to reading this.

One thing I see new devs do quite often is try to figure everything out themselves. There is a balance here. On one hand, yes you should try to problem solve on your own. But to me there is a difference between trying to understand something by yourself and solving by yourself. I don't believe you should just try to understand things on your own. Why? Because that's what senior devs on the team are for. They probably built it, they should be able to explain it. Asking tons of understanding questions will challenge everyone to ensure they all know how a thing was built. If they can't, there's an opportunity for learning from other members of the team. This is a great way to build shared knowledge and I encourage people new to a team to ask away.

When it comes to problem solving, say being tasked to fix an issue, this is where you may want to go on your own before asking. If it doesn't require business knowledge or know-how of the codebase, this is good to explore on your own organically.

I haven't put a ton of thought into this but it could be termed intrinsic knowledge versus extrinsic. Intrinsic knowledge is internal to the team or business domain. You should absolutely ask tons of questions to understand the context you're working in. Extrinsic knowledge would be things outside the team, either simple or complex knowledge. Rote things that are a Google search away all the way to solving a complex problem. That spectrum is wide but I'd encourage you to feel safe getting help for the complex issues and to tackle the rote/procedural stuff yourself. Being able to know the difference is important and comes with experience but you should always feel safe leaning on others to help solve problems. Being a lone wolf sounds enticing but can lead to you going down a rabbit hole that ultimately wastes time and causes the team more angst than if you had seeked help earlier.

This is a incomplete thought but maybe it helps!

 

Been mostly self thought and having firsthand knowledge of the frustration of how to piece it all together, I can tell you this couldn't have come at a better time. Waiting patiently.

 

suggestion:
testing your hypothesis - if there's two or three nearly evenly matched solutions, when should one take the time to test and compare them, and when should one just pick and stick to it?

 
 

Congratulations Ali! What a great idea that is sooo needed. I am super excited and cannot wait! Beyond looking forward to it.

Thank you for giving back!

 

Aw! I'm so excited too! Yay!

 
 

This sounds like a great series! Looking forward to it!

 
 

Dev.to keeps getting better and better! Can't wait!