300 karma · joined November 26, 2015
In case of a time pressure, I just focus on workarounds instead of analysis. Once the problem is no longer burning, it's up to the project priorities to investigate the root cause.
I also learned that panic never solved any of my problems, so when I notice that I am moving into panic mode, I stop for a minute and cool down. This is a skill that can be learned.
The fact that they don't know the scientific names of the grammar rules doesn't mean that they don't know grammar. As somebody how's native language is very dissimilar to English, my intuitive language rules are no help speaking English. The grammar you are taught at school is descriptive of English and not a prescription. The distinction s very similar to "laws in physics". Nature doesn't really care about the rules we impose on it.
Learning grammar alone is not enough. Learning vocabulary alone is not enough. Immersing yourself to a language without a guide (like your parents guided you into language) is completely ineffective.
Grammar, vocabulary and pronunciation are equally important if you want to get fluent in both spoken and written communication in a different language.
Now, formalising that above sentence even with symbols is quite difficult.
There are some big companies talking about their experience.
I've seen quite a lot messages going through RabbitMQ. I wouldn't worry too much about scaling, because the possibilities depend very much on the architecture. With some tuning RabbitMQ can take you a long way. I would give clustering a go and see where the limits are before exploring more complicated architectures like federation.
The problem with number crunching or maths is that it is very difficult to cut the whole computation into smaller units and pre-emptively schedule it. If it is possible for a specific use case, then it is moderately easy to replace that part with NIFs. For effective maths you need to convert the internal tagged number representation to machine native code that is also expensive. Solving these two things in the generic case is very difficult while preserving all the good parts.
It is also important to have a clear goal. Let's say you want to understand how webpack starts up, or how it does a specific feature. Make this question your main concern and don't wander around. Don't try to understand everything at once. Divide and conquer.
It is also useful if you can ask questions, but please spend some time coming up with a theory first why things are the way they are. Formulate a hypothesis (e.g. "this piece is necessary because it handles an edge case", or "this piece of code looks uglier than the rest, is there a reason?") and try to prove it. If you can engage with the community, the better, but please don't outsource your "thinking efforts" to other project members. You can't learn how to reason about code, if you don't reason.
The most important one: be humble. Just because you would've solved a problem differently, it doesn't mean that the code is bad. Don't spend time judging the code. You are there to learn from others, so be open to other solutions. Whether it is a good or bad example is so difficult to judge... be patient and you will realise what kind of code is easy to understand. Once you have some idea, take that knowledge to your next project. This may take weeks/months/years depending on the project size.
You can improve your reasoning skills by fixing bugs. First observe the bug, try to make a hypothesis. Try to support it by reading the code (do not run it, don't use a debugger at this point). Once you have a plan, find evidence that support your theory. Once your theory is right, find a solution, and answer the question "why".
It will take time, but you will improve over time. For me, the key is patience.