My question is mostly to those, who’ve finished / is going through algorithms.
I’ve just finished basic algorithms section, and I’m pretty sure that I have created the ugliest code for Caesars Cypher this site has ever seen. But the question is not about this particular challenge.
After I finish a challenge, I always chech hints to compare my code to the answer. And gosh, that’s hideous.Unnecessary variables, ugly loops, and I’m not even talking about ternary operators, arrow functions and other stuff. And I feel like - I’m happy that I solved the problem. It’s working! But at the same time, if I’m not doing it the correct way, it’s like I’m not learning, and this will lead to problems with advanced stuff.
So, the question (or two). After you see the answer, and it’s not quite like your code, do you change yours? Do you consider it a failure? How do you work with new knowledge, you get from these answers?
And overall, was this section difficult for you?
Taste develops with experience. Concise is not necessarily more beautiful. Short solutions or even code golf require you to think hard about the underlying problem and what tools you have available.
Don’t fret over it, but I suggest you revisit older solutions once you’re done with let’s say a few sections later or a few months later. Fresh eyes and all that.
I agree with @lynxlynxlynx about this. Worry about getting a working result. Period. Making the code more readable, more efficient, more eloquent comes with practice and reading other people’s code, be that in books, on Stack Overflow, inside other student’s answers, or one great source for this is reading the code inside the libraries like jquery, etc…
Yeah, when you’re learning to ski, just worry about getting down the mountain in one piece. After you get better you can worry about doing it with style and panache.
You’re not writing the cleanest, most efficient code. But that’s part of learning. As you code, your instincts will become better, and you will make better decisions. Just keep coding.
I think you’re doing it the exact right way - figure out how to make it work on your own, get it working, and see what might be a better way to do it… solving the problem is more important than solving it perfect. More than going back and changing your solution, I would say to remember what you learned from looking at the hint, and keep it in mind for when you are working on your next problem. To answer your questions, …no, I do not consider anything that works to be a failure. There’s an infinite number of ways to solve each problem and everyone comes up with their own solution. I think I went through the algorithms pretty smoothly, I consider it one of my better areas - I might as well forget about being a designer - who knows, maybe it’ll come. That being said, I’m sure I, and most other people, have at least a few pretty ugly solutions to some of the algorithms.
The best code is one that is readable, and understandable by you and others, 6 or 12 months down the road, or 6 years into the future. You’ll probably spend more time reading code, than actually writing brand new code – as you debug or add new features to an existing project.
And you’ll be grateful if the guy before you wrote easy to understand and follow code. – and you’ll curse the guy that wrote that very long, cryptic one-liner buggy code.
As you gain more experience, you’ll find that balance between very short and very long code. In the end, I think code should be written to be easy (and quick) to be understandable by other humans, it’s like leaving documentation or telling a story for the next person that will work on your code… the computer and compiler will know how to take care of themselves.
For the algorithm challenges? I didn’t think twice about it. You’ll have plenty of chances to redeem yourself as you do the projects.
Unnecessary variables and ugly loops mean that some concepts haven’t quite clicked yet - maybe your brain isn’t trained to recognize exactly which data you require. I think once you start relying on objects, you’ll get better at recognizing which data you need because objects force you to be organized.
Ternary operators aren’t automatically better than if/else statements and I didn’t even bother with arrow functions until I started using React. SHRUG
I had a similar experience - I’d solve a problem, think 'this just feels bad, then take a peek at the various solutions and other’s solutions for ideas on how to improve my own code.
The hardest part about learning independently is the lack of feedback, so I started to think of this process as feedback. Then, I would compare against my own answers and understand ways in which I could improve my own.
Similarly, after working through some Codewars problems, I found that finding my favorite solution, in terms of elegance/readability/cleverness, then trying to write it from memory, has been helpful for me to actually learn how the other solution works. Doing this definitely helped improve my understanding of built-in array methods! Filter, map, reduce, et al are good friends now!
Where I am at with FCC is I’ve just finished all the advanced algorithms and I’m about to start the final front-end projects. I think that my code is probably very ugly, but I don’t have anything to compare it with since I hardly look at other people’s code unless it’s part of a learning resource or posted on the forums here. When I do look at other people’s code, it seems very clever and I don’t really understand it and I end up thinking I must be deficient. I’m thinking though that as long as your code is organised, logical and it does the job it’s supposed to do it’s probably ok. From reading other people’s comments on the subject, it seems an important thing to do is to write lots of comments in it to explain things to other people who might have to adapt it in the future. But what I keep thinking about the subject generally is that from a user’s point of view it’s not important at all and it’s the user and their experience that really matter in the end.
Yes, as long as it works that’s the main thing. But the algorithms are completely isolated chunks of code - that’s why they’re good learning exercises. In a real situation, 99% of your time is spent dealing with code that is linked into a much larger system, that was written by other people (such as you a week ago). This is why the code should be clear and clean and well written. Code is for people to read, not computers, and although it doesn’t matter to the end user, it sure as hell matters to the poor bastard tasked with unpicking horrible code. You need to read other people’s code to understand how to structure things, to get better, it’s too complex a skill to learn from first principles
I recall on one of the challenges that I wrote a solution with ~15 lines of code. The solution had it in 1 line with chained array methods. It was quite disheartening at the time. The course content had not covered that technique so it felt unfair that that should be the solution. But my code worked perfectly well.
Looking into the chaining technique, it’s actually pretty slick and I ended up using it in subsequent challenges. As our experience grows we can learn new things and incorporate them into our coding. Meanwhile, get to the solution as best you can with the knowledge you have. For the end user, it makes no difference - they just want it to work.
But don’t forget that chained statements are harder to change and debug. And inbuilt error handling can be trickier. So they have their place, but they’re not absolutely better.
Learning to code is like learning anything, really. You start off flailing and looking ridiculous while doing it. When you look back at the stuff you’re doing now, say, six months or a year from now (assuming you keep at it between now and then) you’ll laugh at how ridiculous your code looks. That’s a good thing. We all start out writing ugly code. Your description of how you solved the Caesar’s Cipher sounds alarming like how I solved it the first time. Ugly, ugly, ugly. But you know what? It worked. It solved the problem. That’s what’s most important at the start, that you learn how to solve problems. When you become more familiar with the tools and techniques, your solutions will become more elegant. For now, just enjoy solving them. Don’t worry about how they look.
