1. Hold in tension how many questions to ask you fellow developers
You'll never truly understand something if you always ask your fellow developers after the first signs of trouble. Commit to spending some time understanding something new before you ask for help. If something can be solved with a simple Google search, you should definitely not be asking your fellow developers. You should also attempt to use your debugging tools, like logging and breakpoints to look for the root cause of an issue. While an expert on your team may be able to solve the problem quicker this time, having the result handed to you can stunt your growth and limit your own learning. This doesn't mean you should never ask for help however. If you can't make any progress on something for what seems like an unreasonably long time, it can better to ask just to get moving in your current project, but keep in mind that this reduces your own growth as a developer
2. Keep the big picture in mind and uncover more problems sooner
Mostly its advantageous to bump into all the issues with a project as fast as possible, even if it means working on multiple parts of the project without finishing them. For instance, as a web developer, there is no point optimizing the code or styling the first page in a web funnel if you interact with external APIs in the next few steps for which you rely on another team. Try to bump into the edges your your system, where you interact with the outside world as quickly as possible. If there is an issue, it's better the other team knows as soon as possible. It's important identity things in your project that you may rely on a third party for first, so you can give others the most amount of time to respond and address the issue. In the meantime, you will have lots of time to refactoring your code, add caching and optimizations, and increase your test coverage.
This also applies to problems you run into on your own. Instead of letting something hold you up for a long time because you don't know how to elegantly solve it, do what you have to to move past the problem for now. Your unconscious mind may help you come up with a solution when you least expect it. Treat your keyboard time preciously, and leverage your mind while away from the computer by bumping into as many difficult issues as you can while at the computer.
3. Always leave the code base better than how you found it
Don't ultimately aim for the quickest solution when committing to a code base, but always try to write code in a way that makes structural sense. You and your fellow developers may be maintaining and adding to a codebase for a long time, so it's important that the code is easy to follow, the methods are short and appropriately named and thus easy to understand by yourself and others in the future. Less is more in software development, so if you can reduce the amount of code in your codebase by refactoring out common code and put it in modules, superclasses and gems(libraries), you should. However, don't immediately try remove any and all duplication. If it's not apparent to you which method of code abstraction you should use, remember that duplication is still better than using the wrong abstraction. Also, don't reinvent the wheel: if functionality you need can be found in an external library, you're mostly better of using that than writing extra code yourself.
4. Automate and Abstract whenever you can
This should be applied at many levels. You should set up your system so applications are running without maintenance, and abstract away long, complex command line commands with bash aliases. There is no point memorizing something your machine can memorize for you. If you find yourself performing a lot of tasks that should be repeatable, it can often be better to write a script or a code module that will allow you to perform the same action in the future if it comes up. Once checked into your version control system with some high level documentation, your fellow developers will be able to benefit from your work for a long time. People should not have to look through your code to know how to use it. You should always be looking for ways to simplify and abstract away unnecessary complex and tedious tasks.
5. Write code that doesn't need documentation
Documentation adds another layer that must match the code that you must maintain. It can get out of date, or cause conflicts in your version management system. It's better to write the code in a way that is self-explanatory. To achieve this, reduce the length of methods you create, and accurately name the methods, describing what they do. If a class does something non-obvious besides its described function, it may be be better to extract that functionality and put it in its own class or module. Finally, ensure you place methods in classes where they make sense. Each file your write should represent a class or object. If methods are like the messages sent to that class or object, ensure that the messages are something you would expect the object to do. If a method makes no sense in the context of a particular object, maybe it should be in a different object.