DEV Community

benboorstein
benboorstein

Posted on • Edited on

A Collection of Advice

Over the last couple years, as time has allowed, I've been learning front-end web development. During this time, I've received advice from various people and places. And, as I've progressed, I've begun to formulate a bit of my own advice. I figured it would be a fun and beneficial exercise to aggregate all this input, organize it, disregard the pieces that seem less pertinent, and put the remainder into my own words. (Lord knows I need to be reminded of these points as much as anyone.) So that's what I've done. Hopefully others will find it valuable, although I’m open to the possibility that some parts aren't as wise as they seem to me to be. Whatever the case, here's the collection:

There's an idea these days that if you're not passionate about a discipline before you sincerely pursue it then you'll never become passionate about it. But this is not actually true. There are examples everywhere, around us now and throughout history, of people taking up a discipline without any passion for it and their passion growing alongside their proficiency. This doesn't always happen, but it often does. So in reality, the rule, with some exceptions of course, is: We actually can, with a receptive mind and with perseverance, grow passionate about a discipline for which we had little or no prior passion.

One of the biggest differences between beginner programmers and veteran programmers is the level of faith that there is a solution.

Programming is about having a large, complex, intimidating problem in front of you and breaking it up into pieces small enough that you are able to solve one piece at a time...until the whole problem is solved.

When your code snippet seems like it should work but it doesn't: Systematically explain, to yourself if no one else is around, what every single aspect of your code snippet is doing, even the aspects that seem obvious.

Whether your code snippet works or not: If you can't grasp what you've written, try to rewrite it in a way that you can grasp it.

One of the toughest obstacles a beginner faces is getting drawn down rabbit holes. Web development is a broad domain and also requires precision. Put another way, there's a ton of material to learn and each aspect of the material needs to be implemented just right for it to work. As a result, you'll frequently reach a point in your project at which you don't know how to write the code you need...so you'll start researching how to write it. And this is a good thing! Finding your code solution may or may not be quick, but it’s usually once you've found it that the rabbit hole beckons. You'll be tempted to 1) mentally solidify your new knowledge through extended research (for example, you were researching forEach(), and now you want to find and work through fifty more examples of forEach()) or 2) learn about all the new, tangential code concepts you just unintentionally discovered during your initial research (for example, you were researching forEach(), and you unintentionally discovered filter(), map(), and reduce()). But instead of succumbing to these, or any other, temptations, try to make a habit of returning to your project to implement your solution and proceed. (If one of the diversions is something with which you sincerely want to engage, then simply make a note to return to it another time.) Why? Because applying what you know and doing so within the continuity of a project is what best facilitates learning web development. In the process of starting to learn web development, being able to let go is probably just as valuable as having a driving desire to learn. So, to reiterate: When you need to do some research to solve a problem, find what you need in order to proceed in your project, implement it, and move on.

Asking "Why?" is often good, but it becomes a hindrance to your learning when it prevents you from proceeding. In programming, proceeding is how you learn best over the long-term, even if it doesn't feel like it in the short-term.

If you have a specific, pointed question, ask it. Always ask it.

Much like with writing in your native tongue, to be a proficient programmer you have to abandon perfectionism. Keep moving. Only later, once you've finished the project or a major section of the project, go back to polish it and make it "perfect".

When you are told to not be a perfectionist and to keep moving, it may seem that you're being directed to code at breakneck speed. But this is not the case. As long as it's not overthinking or perfectionism that is slowing you down, move at whatever speed works for you, and, with practice, you will become faster.

It's true that it's a good idea to really internalize (that is, understand and remember long-term) what you're learning; after all, this is how we get better at whatever we're learning. But don't make the mistake of assuming that each concept or code snippet you practice can be internalized after doing it once or twice or even several times. Programming is too broad and too complex. You will drive yourself crazy with such an unrealistic expectation, and you will start to doubt your own intelligence and maybe even your worthiness to learn the discipline. The reality is: Each time you practice some aspect of programming, you will only understand it a sliver better than before and remember it a sliver longer than before. But at some point, after you've revisited that aspect innumerable times, you'll get the pleasant feeling of realizing that you've internalized it. Sure, some beginners absorb new concepts faster than others, but, for every beginner, learning the craft is an incremental process and there's no way to make it otherwise.

Try to avoid drawing conclusions about your skill level as it relates to that of your programming peers; don't assume that they're better than you or that you're better than them; do assume that you can learn from them and that they can learn from you.

When you're building a project that requires more than one language (for example, a project that requires HTML, CSS, and JavaScript), there's no rule that says you have to finish your work on one language before moving on to another. So, if it feels more fluid mentally to do a little work on one language, then a little work on another language, and so on, then go for it. And if it feels more fluid mentally to complete one before moving on to another, then go for it.

Top comments (0)