The Why
I mentor at a few different online courses, and a common theme I've noticed across quite a few of them is an odd "gap" in the tr...
For further actions, you may consider blocking this person and/or reporting abuse
This is great model for how to break down a project.
Good development is about planning100% agree.I like to mix in a prioritization step after I've laying everything out. Some items might be more essential than other.
Thanks for the great article. :)
When I see folks going through an online curriculum, and working on some of these projects, I cringe. Diving in and coding, and when this part starts getting wonky write more code to fix, until we are back to non-supportable spaghetti code.
I've been working for some time on trying to find that middle ground - how can we take the basic language skills we have, do some funky middle magic, and return a well-crafted final project?
Suggestions on how to teach the developer mindset?
It's a good question. I think allowing a certain level of spaghetti might actually be ok to start with. What's important is that they are learning and doing. If we correct too heavily and get pedantic about style too early on, they may get discouraged, disheartened. It needs to be fun! The reward of building something and seeing it work is what matters most.
With that said, how do we mix in teaching good patterns? I'd say as a quick follow. So once something is working, no matter how messy, celebrate that win! Then we can offer "Do you want to clean this up and simplify it?"
Refactoring and cleaning up code is a great teachable moment, there is both messy working code, and then the cleaned up working code.
I think this is a natural process. Even after 9+ yrs of dev, I start out a bit messy, hacky, then pause and clean up.
What are your thoughts? What have you been trying?
I am a huge believer in "You can't refactor until there's something to factor." I believe that as we learn, we see that things aren't always ideal as we start. When they ask, I'm always going to give guidance, suggestions to simplify and clean things up.
But I'm not going to tell someone on their second week coding that they shouldn't use three loops and a switch statement, if that is working for them. I'll suggest they make the time to revisit these projects in a month or two, and look at ways of doing some of these same things differently.
I also recommend using versions. Being able to show an employer (or to look back yourself) will show an evolution and growth of skills. It is great to see where someone is, but I like seeing how they've got there.
Been coding for nearly 40 years, been teaching in one form or another for the past fifteen. I was surprised to find that the combination is my happy place.
I agree with your principles, I think they are wise.
I love this, and will be borrowing this idea. :)
Thank you for the article, although I'm late here (coming from the-odin-project discord) after suffering from direct code implementations but I'll surely try these in my next projects.
Quick suggestion
Can you change the font style of the article. It's really hard to read
Nice content BTW
Thank you for the suggestion! I'll have to look into altering fronts in markdown. Wondering what it is about this post that makes it more difficult to read than any other dev.to article.
Sorry, i just found out that it was the font setting on my account. It's strange cause I've never touched it
Fixed it
Thanks for responding
Came here from The Odin Project Discord server. This is a great article, it really helped. Thanks Toby 🙏
Excellent, glad it did. It was more of an abstract piece than some of the others, but I think we need to explore both the theoretical and the practical.