Learn your everyday tools, they will free you up a lot of time and will give you an edge to become faster and better with time.
For example Integrated Development Environments (IDE) have lots of quick keys for everyday use and most blogs reccomend memorizing the most used ones. I'll go on a different route for my suggestion with a little of backstory.
At my first job near 2002 most developers were using very crude tools as the workstations available to us were not powerhouses and most of us were pretty new to the industry so we didn't know better.
The workflow mostly involved using a plain text editor on local Windows NT, upload source code to a Unix server, compile and possibly restart a server in order to load new code. As you can imagine this was brittle and there were multiple places for collissions either by overwriting somebody else's code, restarting in the middle of another developer test or plain corruption of compiled binaries.
The first thing that we started to adopt was a text editor that had file transfer capabilities to speed up a little the process, this introduced more probable collissions. As you can imagine there was no source control anywhere in sight so each developer started to have a local backup or their files and merging other changes when needed. As most developers were using Java Server Pages (JSP) which allow a single file to contain lots of weird things together like sql, html alongside with java tied together with string and tape, this meant that none of the code highlighters could parse them correctly and thus give hints on correct code it made very difficult to validate against incorrect syntaxt.
At first there was effort to configure highlighters to work with multiple languages in a single file but it was really difficult to handle all cases. In the end it started to force us to better practices as not mixing languages in a single file but it introduced another problem: restarts of server needed to be more frequent as only JSPs had hot deployment for that particular type of server. It took us a while to understand this and it would have been very helpful to understand the lifecycle of the JSP, J2EE container and class loading. Too much for a new developer to grasp in a short timespan.
In the end we ended up with a local J2EE libraries against which we could compile our sources and run unit tests, once we had something usable they were copied with a more robust editor that had both merge/diff utilities and file transfer capabilities; it also managed automatic backup and history of files on local. Sadly we could not get centralized version control, but all improvements allowed us to move faster and more confident to not break other developers code. This wouldn't have been possible without knowledge of how the server loaded code, what was the lifecycle of the application once loaded, what meant hot code replacement and what could be done with it, starting to learn separation of concerns and moving away from humongous single file 'programs' to more classes and views as we also learned to reference templates in a nested way which in turn reduced lots of duplicated code and weird bugs related to copy-paste-mutate conditions.
In conclusion:
- Learn your everyday tools for speed of execution. Do not waste time on repetitive tasks.
- Learn the train of thought of your stack. Chances are most of the problems you are having are for trying to go against what they were designed for.
- Learn the lower layers of your platform, you might not need to touch them or code them from scratch but they will give you insights on which you'll be able to build upon.
- You will not work in isolation for long, learn where collaboration will happen and where conflicts should be resolved and where they should be avoided.