planxty

it is tuesday my dudes :P

Seeing the same.

This was my introduction to drawing. You will not be disappointed. Drawing from Bargue's lithographs will teach you technique, and taste.

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.

"Easily", not sure that is always easy to do. Is a clever approach to be sure, but to the author's point there could probably be better UX.

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.

This author is spot on.

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.

No it's been a total fucking nightmare. Take care of yourselves out there! Meditation helps me keep my lid on.

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.

I think you have some things to learn, as a manager, and as an engineer.

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.

Forgot to mention: we were not a Rails shop, but I think the kind of code or framework being used isn't the most important challenge here.