2. Take code as documentation. This helps to debug things faster
3. Focus more on problem solving than language/tool priorities
4. Listens more and always towards exploring and experimenting new things. This improves breadth knowledge
Architecture is important, but organizations employing "software architects" tend to be bad at software.
The worst thing I remember is a web API where some call could fail but didn't tell you, it just gave you some kind of plausible looking inert data. The call to query system status was separate, so there was always a time of check / time of use problem. Also there was a transition period when the original call did return an error but the system status API didn't yet. Nobody (I hope) comes up with such a disaster while implementing and testing it.