Yes, practically speaking it usually is. (However, #1 and #2 are very similar, because parsing a new version of JavaScript into an old version might actually require a full implementation of lexing for the old version, PLUS lexing for the new version.) But from a heuristic perspective, it's not useless. It provides you a way of thinking about what the language is capable of doing at the outset.

This might be referring to two things, possibly. The idea that the language could be used to write a parser that could parse itself. That a newer version of JavaScript could be transpiled to an older version of JavaScript, again, using JavaScript. (Like Babel.) I haven't heard anyone say this, but I would guess if they said it, they are referring to #1. Edit: To answer ahead of time - the purpose of this is less about actually doing it, and more about explaining what the language is capable of doing. JavaScript is capable of a lot of stuff. There's probably a more useful descriptor of "language that can implement lexing", but that's beyond the scope of my answer, and apparently beyond the scope of my quick Googling as well. Someone else on here will know what it is.

Let's discuss quantification and why it matters for a second, then we'll talk about how to apply it. Statistics and "data" is essentially an agreed-upon measurement of something. That's all it is. That means that the measurement only has meaning if you understand it, trust it, and you can replicate the measuring process. This is where a lot of people go wrong unfortunately, because their measurement process is borked. Put another way, quantification is a way to describe something in a format that another person can understand. This takes a perception and turns it into an object - "objectification", in the good way. Okay, so now that you've taken this behavior and put it into an object, you have a clearer picture that can help remove mental bias and other errors that can occur without objectification and quantification. And that can be very valuable to the learning process. But the key here is to choose carefully what you measure, how you measure it, and what to do with the measurements. Now we can discuss a few things you could be measuring to quantify your growth and experience as a developer. Days you've been a developer. This is perhaps the easiest one, but is roughly correlated to your growth and experience directly. Of course, this also depends on knowing your rate of growth, which is a different measure. But assume that you grow at 1 arbitrary unit per day - now every day you've been a developer, you have grown by that 1 unit. (This is unlikely to be true, but a simple to achieve measurement with little noise.) Languages you can accomplish a particular templated task with. For example - ToDoMVC accomplishes the narrow set of requirements for a ToDo app. Can you build a todo app (or some other minimum thing) with 1 language, 3 languages, or 20 languages? Be careful here, however. Learning new languages doesn't necessarily mean you are "growing", per se. Remember, growth has to be defined in order to select adequate metrics and measurement strategies. Self-survey. Your growth isn't only limited to how much you can do with your hard skills. Your growth is also internal. Surveying yourself periodically to determine how you feel about your own career gives you a way of taking a subjective matter and compress it into an objective measure. Track this over time, and you can start to learn about the seasonality of your mood. Code reviews. Ask other seasoned developers to rate you. Consensus measurements are extremely important. Being a developer is, after all, mostly a communications job. If you are growing, other people should be able to perceive it. Ask for regular consensus from other developers to determine areas that are, at least from external perception, growing or dying. Hackerrank and other interview-style questions. - Things get a little fuzzy here, because you might be very good at solving algorithmic puzzles but have a hard time bringing those skills into your work. However, this is a decent proxy to programming and problem-solving skills. There are certainly many more, and my guess is that this style of answer is less what you are looking for - but, I believe it's important to remember that self-quantification should be aimed at refinement, not at making a sweet dashboard for yourself. If you aren't certain what you want to grow in, start there.

Perpetuated the quick-fix mentality. This is really quite terrible, and a cycle that is hard to break from. Start with tests, code reviews, and continuous improvement on day one, and don't break away from that. Believing technology was inherently valuable on its own. (It is not.) The people you encounter in your career who are not developers (read: project management, executive teams, clients) will likely not understand the value of testing, or the value of new technology for that matter. The more you understand how to translate value into terms that others can understand, the further in your career you will go. Not automating repetitive tasks. I don't know how much time I've lost, but every task you repeat that isn't made more efficient is time lost. See: Understanding my own values, goals, and clear path earlier. If you don't set yourself up for longer-term career fulfillment, eventually you will hate your job, no matter how cool it is or how high-paying it is. Find what you care about. Find your underlying values and career purpose. It is the fuel you need.

Dissecting the question, we have two operative terms here: "readable" and "maintainable." Let's talk about what these mean. "Readable" would describe code that is understood without much inspection or explanation by another developer. You have to choose what parameters you want to describe the "other developer" to know what would be readable to them. Some things are somewhat universal and limited by human factors. For example, few people can follow poorly named variables. (There's your first heuristic - are there clear names for variables, classes, methods, and other references?) Other things are a bit more nuanced. For example, if the developer uses the language you are writing in on a regular basis. Or, is the developer familiar with the domain the project operates within? How experienced are they as a developer? Do they have a particular background that might make the code more or less readable to them? But what if you don't know who the other developer is? This is why we develop standards, patterns, and best practices. For example, JavaScript code tends to use camelCase, so writing your code with camelCase provides a sense of fluidity (which plays into readability). Knowing the common patterns and style that the language typically uses is important. (As an additional note, your organization may have your own style defined; follow it.) Some simple, practical heuristics to follow: Use descriptive variable names. Longer variables are more easily read. Use whitespace! Compilers and minifiers mean that whitespace is free. Take advantage of this. Practice finding a balance between abstraction and practicality. You do not need 10 layers of redirection for simple tasks; start with the simplest approach, and abstract during a refactoring process. "Make it work, make it right, make it fast." In that order. This will immensely help the readability of your code, because you start first from comprehension, and then move towards performance. This establishes your pattern and semantics up front, and you are more likely to maintain good semantics this way. Know your audience. If your audience isn't used to inline lambda calculations, skip it. Even if you believe it is the "best way" to solve the problem, there are other equally good ways most likely available. Follow well-established refactoring and OO patterns. Seriously. These things have been tried and tested, and they work. Look here for a good description of many of these patterns: https://sourcemaking.com/design_patterns Don't follow rules blindly. Take some time away from the code and revisit it - what sticks out as weird? What sticks out as confusing? When does your brain feel tired? Readable code isn't always maintainable, and vice versa. Maintainable code is established by following good practices and principles. Tests are HUGELY important to codebase maintenance. Having good test coverage keeps you from having to load all of the codebase into your working memory (in your head), and reduces errors. (Note: tests won't eliminate errors all together; they are there to help you, not to make you obsolete.) All-in-all, coding is a human process. Follow Hemingway's advice when writing code. Simpler is typically better.