I always start by looking at existing code. Most times, you'll probably be extending some existing module or functionality, so an overview of available extension points is important for me. This also helps in getting a feel of the style of Shopware development, because you'll be exposed to a lot of the core.
As Shopware is based on Symfony, any existing open-source bundles can also teach you good practices.
I aim for the minimal amount of modifications to Shopware's functionality. The more of my logic I can put separate from Shopware's logic, the better. If an official extension point (like an abstract class, an interface or an event) exists, I'll find a way to use that.
Apart from Shopware's structure, anything you can learn about software architecture helps. Things like SOLID exist for a reason, after all. If you understand their history and purpose, you will structure your stuff better, and it will probably be easier, too.
I take lots of knowledge from reading existing code and understanding the domain of my customer. Being interested in your customer's business and processes is very much recommended.
To me, performance-oriented development is a big part of daily business. Large(-ish) ecommerce applications tend to handle lots of data, so having good processing in place is important. Never fetch "all data", don't load stuff one-by-one, load the same data just one time and pass it around.
I love working with developers that strive to be better and reflect on their code! So if someone already wants to get better, they'll probably be open to (or even asking for) feedback.
Any feedback I give is aimed at the thing, not the person. So if some part of code should be changed, I ask something like "What would happen if X is input". By starting a discussion and asking for their opinion, I prevent a situation where a change MUST be done without any context. I think context is the most important thing if feedback should be internalized. Why do I think this doesn't look good? Why do I think it should be something else? Maybe I can point to some requirement and ask if that is correctly handled.
I am very fortunate, because I mostly work with experienced developers, so we can usually focus on the code. When working with juniors or non-technical staff, I try to bridge into their domain and give even more context. Handling Shopware's HTTP cache correctly is a good example. If I can show the immediate error cases, it helps to clear up why it is important. This often leads to interesting discussions, both for me and the other person.
I think it depends on what you're usually working on. If you're expected to deliver innovations and be on the bleeding edge - maybe most of your projects are using the latest Shopware versions - it is very much needed.
For handling backwards compatibility and keeping existing projects running smoothly, knowing the latest changes may also be advantageous.
We use lots of channels for that. Apart from official Shopware sources like the Changelog, its RSS feed (which we have integrated into our Slack workspace) or the various newsletters, we're also looking at community pull requests (or creating our own PRs) to get a feeling of where the community is pushing toward.
On the more DIY side of things, we look into new Shopware tags on GitHub before they are actually released to get a preview of updated features while still having time to think about how they may affect our projects. Reading code is one of the essential ways for me to get to know Shopware's inner workings.
The Shopware Community Slack is a great place to hear from other Shopware developers and seeing what they're working with. Community events like the Shopware meetups (of which we have the pleasure to organize many of in Germany) are one of my favourite places to get to know the community and exchange ideas. Let's hope we can have more of those in the future (written during the COVID19 pandemic). I love meeting the people (both from and outside of the existing community) in a more relaxed setting like meetups or conferences.
