How to guide myself in learning, why after 4 years of work experience am I still bad at programming?

Question

Books

The situation is this.
I have 4 years of experience.
And, suddenly, when colleagues looked at the code, they did not understand anything.
To be honest, I have no idea what exactly is wrong.
When I ask them this question, there is nothing specific. Looking through their code, I also do not understand how they are mine. Well, I start debugging and gradually understand. They seem to be reading the framework, but I don't understand it. and To understand I need to debug watch and check
Question one.
What is clear to me, exactly, I do not have enough guidance, and if not at work, where can I get it?
The second question is
why such a situation could arise, what skills do I lack or what is wrong?)
UPD I did pet projects and this is not one job, the feeling that I am learning is learning and I won’t even learn the basic things. Here is a frequent question: did you read the documentation, but I read it 5 times, and still did something not according to it, and even after the explanations, I still did not understand where it was in the dock ...

Answer 1

No code no opinion. Put it on github or ask for a review.
This is the most correct practice.

Answer 2

You need a mentor and a code reviewer at work.
PS: I have been programming for thirty years. And every time I review my code written a year ago, I exclaim what the hell is written here - either it can be written easier, or more understandable, or the code should not work at all.

Answer 3

There is a generally accepted codestyle for almost any language, for the same PHP there is PSR, for Java Style Guide , etc. Usually, what is written according to the codestyle is read quite simply and easily, in fact, for which these guides were compiled.
For some frameworks, or even within individual organizations, there may be a separate codestyle that differs from the generally accepted one, dictated by various reasons, from purely technical to senile and idiotic, but all of them are designed to make it easier for developers of one product to write in the same style and understand the code of colleagues as comfortable as possible.

Answer 4

Simple things help explosive growth: job-hopping and pet-projects. If you have been in one place for 4 years, from the very beginning of your career, then this is the whole problem. There is no driver for growth.

Answer 5

Discuss with the team leader or head director to devote at least a couple of hours a week to code review. Ideally, every day for half an hour (at least) to view each other's commits. They will resist, it could be a waste of time, but as a result, the quality of development will increase, you will spend less time debugging your own and, most importantly, someone else's code.
Well, from the obvious, you need to adhere to a formalized coding style at the level of a company or a specific project (naming variables and functions, brackets and other little things). Since you have such difficulties in mutual understanding, then you need to try to brush the entire code with one comb so that there is less rejection when reading. And, since the code is not clear at all, there are not enough comments. You can read about what comments should be in the books referenced in the answers above.

Answer 6

If you have problems understanding the code, then you are developing without a methodology. The fact is that any deviation from a particular methodology, which is not consistent with the rest of the methods within the same methodology, turns any software development methodology into a pumpkin. Either everything works as a system, or everything does not work. If you don’t have a review code, there is no pair programming at the root, work on the subject area occurs without discussion, and there are no joint discussions of api and subject areas of inter-module layers, then naturally this means that communication between developers is not established. The consequence of this is that the flight of thought for each developer occurs on its own wave and it is not surprising that you do not understand each other's code. As a bonus, you are also not aware of each other's strengths and weaknesses.
1) Take a colleague - 1 piece
2) Take the code of another colleague - 1 module. Limitation: You and a colleague independently evaluate another colleague's code as incomprehensible.
3) You and a colleague independently refactor it to the state: "now everything is clear to me."
4) Get together with a colleague at the same screen and conduct a code review on the results of both refactorings.
That's the only way you'll get the answer to your question. But there is not much profit, because you need to ensure the implementation of the methodology and clearly adhere to it by the whole team.