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.
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?
> Downside there could be that db lock-in becomes a concern
Lock-in is often mentioned as a downside to tech, but in my experience the budget never exists to change tech past a certain point anyways.
Honestly it always seems like an argument for better upfront planning, to me. Start out by assuming you're going to be locked-in to your choices forever, and make those choices with care.
Why would I want to have the examine DDL or slow query query committed to memory? I need to know that the concept exists and I can google the syntax in 90 seconds. I’m never within 90 seconds of disaster avertable with this knowledge.
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.
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.
Agreed, but the culture reflects the leadership. If leaders put up a backstop and say "tests passing gate new commits and new commits should include new tests," then the culture will bend to this. If leaders think that simple process elements are negotiable, then the culture will reflect that.
