Look for didactic materials and approaches used by the French Academic painters of the nineteenth century. A good book about the sight-size technique of drawing and painting should be a useful toolset for someone engineering-minded. There are books published within the last 20 years on this approach, and there are thousands of living competent practitioners in the real world.
There are methods of examining and translating our physiological visual experience into an abstraction we call a "drawing" that were developed over hundreds of years. They are very good methods. Don't be intimidated by their age or some imagined importance of an old approach. Anyone can learn to draw given the correct system of reasoning and evaluation.
All that said, don't waste time on anything you do not think is beautiful or inspiring.
Finally, nude figure classes are a great challenge and motivator.
Of course anyone can look anything up. The point I think the author is making is that the database is better positioned to tell us about potential performance issues. Would be wonderful if we could avoid reading through slow query logs, or paying big money for APM tools, if the db exposed more user friendly information about perf issues or other useful metadata.
The UX of 'damn I have to look that one weird query up again' to look up some metadata is not as good as it could be.
Raise your hand if you've committed the PostgreSQL to memory for looking at the DDL for a table, or identifying slow queries. Too many database management operations require highly specialized knowledge about a given database's internals.
Folks are far too willing to spend huge money on expensive licenses for db analytics tools to tell them when queries are slow or suboptimal.
Love the idea of making the db responsible for migrations. Downside there could be that db lock-in becomes a concern, and it might add cognitive overhead connecting application code to the current schema. How do you know if app code is up to date with the db without a live connection to prod?
Yes, absolutely. I did at 35. Find the aspects of the work you love the most and let them guide you. A bootcamp or similar educational experience should help you ask the right questions at the outset, and will be a significant boost to your self study.
Any mid-life career change carries risk, so I recommend speaking with your family and/or loved ones to make your intent clear. I also saved money for a while before joining a bootcamp to take pressure off of my wife during the training and to ease the job search after finishing.
Most important tip: talk to people. Ask software engineers about their work, lives, interests, practices. Whether you take some formal schooling or not, learning about how people work and why they make decisions will help you move forward more quickly. Without that context it's easy to get lost in a sea of details.
Cultural problems are hard to change. If you like your team, one option might be to simply begin testing your own code and ask people to review your work. Don't be overly optimistic, but from time to time the right person can create enormous change simply by doing the right thing and patiently explaining why it's helpful. It's likely your experience of mature engineering practices in a bigger company is largely foreign to your colleagues, and they would enjoy learning more from you, because you care about them and care about your work.
If that doesn't help, move on. Life is short and bad practices will be a drain on your energy and your long term career trajectory.
Testing is a skill to learn like anything else. Teams that dogmatically apply any new practice or process without making a genuine effort to learn that thing will never extract value from it. If your team can try, fail, and learn from mistakes, you are in a mature organization. If your team gives up quickly because of fear of dogma or has no strategy for dealing with the challenges of learning new skills, it's unlikely your team will ever extract value from testing until the team culture itself changes.
A small step up from the pit of despair we're in should not be confused for meaningful progress, though we should fully expect the Trump administration will soon be releasing misleading self-congratulatory statistics for political gain.
I worked for a company that did this, and our scale was quite large. It took a lot of work to get AWS to give us more and more databases on RDS. We had some unique challenges with scaling databases to appropriately meet the needs of each account. Specifically, it was difficult to automatically right-size a DB instance to the amount of data and performance a given customer would need. On the other hand, we did have the flexibility to manually bump an account's database to a much larger node size if we needed to help someone who was running into performance issues.
I think the biggest problems had to do with migrations and backups. We maintained multiple distinct versions of the application, and each had a unique DB schema, so there was frequent drift in the actual schemas across accounts. This was painful both from a maintenance POV, and for doing things like change data capture or ETLs into the data warehouse for data science/analysis.
Another big problem was dealing with backup/restore situations.
I suspect this decision was made early in the company's history because it was easier than figuring out how to scale an application originally designed to be an on-prem solution to become something that could be sold as a SaaS product.
Anyway, I think choosing a solution that nets your business fewer, larger database nodes will probably avoid a lot of maintenance hurdles. If you can think ahead and design your application to support things like feature flags to allow customers to gradually opt in to new versions without breaking backwards compatibility in your codebase, I think this is probably the better choice, but consider the safety and security requirements in your product, because there may be reasons you still want to isolate each tenant's data in its own logical database.
Cognito has an awful API and worse documentation. It's also super limited in terms of how user metadata is represented, is hard to query efficiently for users meeting certain criteria, and produces super cryptic errors when integrations aren't set up correctly. As a whole the Cognito product feels like some weird bolted-on POC that AWS decided to charge money for. Compare that to a real _product_ like Auth0 and it just falls to pieces.
If the appeal is about free usage under 40k monthly active users, you probably don't need an external complex managed auth solution in the first place.
A gentle beginning is a great thing to shoot for. I would second the recommendation of a Starting Strength program, or something similar, where you can work a clear, well-established path with coaches who are familiar with the principles of the training methods, can guide your form, etc.
I started off in a 2x/week one-on-one coaching relationship, and after a few weeks (basically once I had some basic understanding of the main powerlifting exercises) I started attending small group classes 3x/week.
Take your time, focus on form, and work with a knowledgeable coach. You might look for gyms that feature classes in powerlifting or olympic weightlifting.
https://www.barbellmedicine.com/ might be a good resource to check out if you don't have coaches in your immediate area, and you want to have expert guidance.