Programming Tierlist

When someone asks you "Which programming languages do you know?" to judge your skill in programming, it actually reflects his skill: Bottom-tier.

Why? Because once you learn the logic behind a programming language, you realize it applies to all languages, since all 'real-world application' languages are object-oriented languages. Only the syntax is different. So, if you are truly "skilled" in programming, you can learn any language in a day. I put this to the test recently, by learning java in a day, and finishing a basic chess terminal application from scratch, in 3 days.

"Which language should I learn then?"

Depends on the framework/engine you will use. Which depends on what you want to make (or where you intend to work)

If you want to make a videogame for example, you have 3 choices:

So, what language you should learn, depends on which of the above engines you consider ideal for the game you want to make.

But if you want to learn programming for programming's sake, I suggest C. Oldschool choice, but it teaches you the fundamental programming logic, without burdening you with the concept of classes,interfaces,polymorphism and other bloated features. C also teaches you some low-level concepts like memory allocation (e.g. memory leaks) or serialization.

If you dislike C as the first choice, I suggest picking anything but Python and javascript, because declaring variables without a type, makes types hard to understand for a new programmer.

"If all languages are fundamentally the same, how can you judge the programming skill of someone?"

Simple answer is portfolio. Long answer is skills which transfer in any language.

So, let me write a list of skills from "basic" to "advanced" a programmer typically learns:

How to git gut

Sure, you know the theory, but if theory alone was enough, everyone would read 10 books, watch some youtube videos, and go to work as systems engineer for 100K$ a year. You must write systems, and when you finish them, identify what can be improved and try better alternatives. Of course, to write systems without a monetary incentive, you must be hyped to write them, so pick an interesting project where you can apply whatever new technique/practice/experiment you want. If you watch random youtube videos or read tutorials, and don't apply them (write code!) you will forget about them in a few days, giving you false confidence that you learned something useful.

Practice makes Perfect

I remember when I was first taught OOP, I thought I got it, until I was asked to write a small program in it (pretty much the factory design pattern) and that is when I noticed I didn't quite understand it properly, yet I was confident I had understood OOP.

I also remember my first implementation of ECS was a mess, resulting in a refactoring worse than the original OOP code I tried to replace it with. But when I refactored my 2nd system to work with ECS, it was great, the 3rd was excellent, and so on. Trial&Error solves all misunderstandings, because if you haven't accurately understood something in programming, it will run, but never correctly.