MS did design ONE way to do things. They just don't always prevent you from doing something different. Sometimes, it will just be harder. Sometimes you will think your method works because you didn't test thoroughly and because you don't understand the event model but there is a problem waiting to bite you. You can learn best practices from the experts which is boring and a lot like defensive driving but which will save you a lot of problems over time or you can be sloppy and take shortcuts and then flail and complain how bad and backward Access is.
I came to Access from IMS/CICS/COBOL/DB2/Oracle on the IBM mainframe where I developed applications for thousands of concurrent users and processed millions of rows of data when working with batch processes. Switching from functional thinking to event driven logic took some doing. I am 100% self taught regarding Access but at least I already understood good programming practices and Relational database design so I didn't have those hurdles also. I found Access to be such a productive tool compared to COBOL that I transitioned from main frame work to almost totally Access development with mostly SQL Server (or other RDBMS depending on the client's needs) as the BE. I find that the hardest people to train to use Access are people who have been programmers using other platforms. For some reason, they think they are smarter than Access and resist learning the "Access way" because they think it is somehow inferior. I guess it is all that bad press you see on the internet. However, if you read those articles closely, and you know what Access actually is (it is NOT a database engine), you will see that the people who rail against Access don't even know what Access is. Their complaints are always about the limitations and shortcomings of Jet and ACE which are the desktop database engines closely associated with the RAD tool "Access". Access is a RAD tool. It is NOT a general purpose development platform. You would never use it to develop web pages or video games. Nor would you use it to write channel programs (low level programs that connect the OS to various external drives). Access does what it does and it does it superbly. You just need to understand what its target application is and make sure that it works for you. If it doesn't, find yourself a different tool that will allow you to twiddle the bits you want to twiddle. Just because Access isn't a tool for all uses, doesn't make it bad. It actually makes it better since it is targeted. I far prefer to use my camera to take photos than to use my cell phone. My cell phone is a jack of all trades but a master of none. My old flip phone was far better as a phone than is my current, very expensive "smart" phone. My smart phone is a pretty bad flashlight but since I rarely have a flashlight in my purse, I use the poor tool that I do have and I don't complain.
From my perspective, I've written my million lines of code and I don't need the practice. Therefore, my last inclination is to write code rather than my first. I use property settings, Access methods, and queries. I use VBA for validation in the FORM's BeforeUpdate event to ensure that I don't save bad data or empty records. Then I write VBA if none of the other options get me to where I need to go for the rest of the logic I need to implement.
You would do well to find the list of VBA functions organized by category and keep it close at hand. The alpha list is useless since if you are looking for a function, you are unlikely to know its name. Then find the documentation for form and control events. Most of it is lousy but there are some gems out there.