I think this type of problem-solving is where TDD really shines. It gives you a space to write your ideal code and how you would prefer things work. Then you get to go out into your application and make that code a reality with the helpful guiderails of your test.
I think yelling at computer is a mindset. No rules can help you unless you stop expecting things to work as expected. Problem solving is another point.
I think the problem is not about the expectation of things working as planned, but our reaction to the moment in which they don't. We shouldn't feel angry, upset, or disappointed. Instead, we should remind that this is a process, and failure is just part of the process.
Creator of TinkerHost, the no-cost hosting platform for beginners and small businesses! I enjoy programming and PHP and SQL, and learning about new technologies and techniques for building websites.
Software Manager, Agile Aficionado, Tech Dabbler, and Public Speaker. A lifelong learner, the prospect of something new and coffee are what get me up in the morning.
The article by itself isn't bad, the example is.
You took an example and solved it by slowly reducing it into multiple smaller steps. This, by itself is fine. But you managed to end up with a less readable and over engineered example.
I think the example's objective is to demonstrate the reasoning behind the solution of a problem, and not the most efficient way of writing code. The example is also not using any other method apart from the for loop and the console.log() method. In your case, the inner for loop gets replaced by the repeat method, which adds an extra step of complexity and deviates from the initial objective of the example.
I think your solution could be presented as an extra step in the problem resolution: "improve and make the solution more efficient".
Budding front-end dev. Lover of React, Next, and all web technologies. I have a drive to learn all new things. Love APIs and making fun projects on my own during weekends.
I think this type of problem-solving is where TDD really shines. It gives you a space to write your ideal code and how you would prefer things work. Then you get to go out into your application and make that code a reality with the helpful guiderails of your test.
Interesting take. Thanks for sharing it!
I think yelling at computer is a mindset. No rules can help you unless you stop expecting things to work as expected. Problem solving is another point.
I think the problem is not about the expectation of things working as planned, but our reaction to the moment in which they don't. We shouldn't feel angry, upset, or disappointed. Instead, we should remind that this is a process, and failure is just part of the process.
Interesting subject! Thanks for sharing.
Nice article! But what if we love throwing words at our computers???
Go for it! 😅
Great stuff. Remember about Plans though, they are good until they encounter the enemy, so prepare to be adaptable as well.
Totally!
Awesome Article. Damian thank you.
I'm glad you enjoy it!
The article by itself isn't bad, the example is.
You took an example and solved it by slowly reducing it into multiple smaller steps. This, by itself is fine. But you managed to end up with a less readable and over engineered example.
You could simply do:
That's a great improvement over the final code! 👍
I think the example's objective is to demonstrate the reasoning behind the solution of a problem, and not the most efficient way of writing code. The example is also not using any other method apart from the
forloop and theconsole.log()method. In your case, the innerforloop gets replaced by therepeatmethod, which adds an extra step of complexity and deviates from the initial objective of the example.I think your solution could be presented as an extra step in the problem resolution: "improve and make the solution more efficient".
Brilliant article.
Thanks, Steve!