Often practical software development is not so much about algorithms, as it is for example:

• finding suitable packages
• matching calls
• finding ways to abstract the structure of things so that code is both understandable and efficient
• sometimes doing vanity things to make fast copy-paste possible
• sufficing and dealing with the possible “buyer’s regret”
• exposing your solution to immediate evaluation of a colleague
• trying to motivate others to give attention or feedback to you
• handling scope issues of variables
• keeping your grand idea clear while doing laser-focused pinpoint development on a particular part
• converting stuff from form to another

I also found it really hard that whilst acquiring basically my Javascript experience from zero to hero, there was tons of terminology and sort of this “neospeak” of familiar concepts wrapped into new words. Whereas I had thought of many structures and down-to-earth computing concepts in very plain terms like:

• array
• byte
• function
• procedure
• call sth
• return a value

soon I found myself dealing with

• hoisting
• callbacks
• promises
• scaffolders
• dispatching
• duck-typing
• polyfills

A language may bring along whole bunch of terminology. Eponymous terms are often used in lack of time to start juggling for a better term. The new turf is often a bit brittle and may feel lukewarm to a newcomer. However, do try to enjoy the endulging dive.

Often what happens is the best learning experience is exactly at the point where you’re surfing on the edge of your comfort zone. If you’re a bit on either wrong side of the wave, you feel a different urge. I remember binging articles after article of new knowledge and it felt absolutely superb. It’s part of being a virtual crowd.

Keep coding!