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.

https://en.m.wikipedia.org/wiki/Ted_Kaczynski

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.

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.

What a typical 100% Serverless Architecture looks like in AWS

Does it look like an unmaintanable untestable mess?

Mullet? Check.

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.

An excellent therapist is always a good thing to identify, but excersize can definitely also have a massive impact on self esteem, energy levels, and mood in general.

I found that strength training has radically changed my life, and I've certainly plumbed the depths of profound depression and anxiety in my own life. So far, nothing has come close to helping me as much as strength training. Working out regularly gives me a way to care for myself, and I can walk around knowing that I'm doing work that will have a lasting benefit for all aspects of my life. It's a lot less about looking perfect or weighing some ideal amount and more about caring for myself, and celebrating those small victories in the gym as evidence of personal resilience and growth.

Excersize may not be the magic bullet for your situation, but the same experience of caring for yourself might come from other experiences, like volunteer work, studying a new skill or hobby, etc.

By the way, I've certainly let mediocre therapy go too long. Nothing wrong with exploring other therapists, it's a deeply personal search, and needs also change over time. Trust your instincts on whether you are receiving the right care for you. The worst that can happen is that you try someone else and realize you prefer your former therapist.

You are worth it! Best of luck.

A pissing match between two unrelated branches of an enormous org chart has caused monumental waste and discord where I work as a software engineer.

My employer is also allergic to open source, even though we are a huge publicly traded software company, so we're reinventing wheels for things that are already solved problems.

Toxic hell, I should be gone in weeks.

I suspect the majority of people who claim to disdain SOLID principles are in fact using them every day without realizing it.

Seems pretty disturbing that so many engineers are piling on to recommend abandoning adherence to some really basic (and easy to understand and apply) ideas about design. Glad I don't work with you! :-P

Test your code, or stay the hell away from me. :)

Yes, so good. Martin Fowler's Refactoring is an excellent companion to Feathers' book.

Popularize the value of tests. Test, refactor, repeat. 2 years of legacy spaghetti isn't really that bad. I work for a company whose codebase is at least 14 years old in places, and there have only been serious testing efforts for 2-3 years.

Chances are, the code is a mess because nobody who knew better was empowered or motivated to advocate for a better way, but you have a hidden opportunity to be that hero.

Good luck!

Awesome, straightforward advice. Why I love HN. Thanks!

I would wager they haven't listened to good performances or haven't spent enough time with Bach's music. There's nothing cold about BWV199. Find Gardiner's rendition featuring Magdalena Kozena, it'll knock your socks off.

The article describes an agnostic man being drawn to faith by Bach's music. I am no Christian, but this is my own experience as well. Douglas Adams is correct.

No, no composer can equal Bach. Done. Upvote to the top please. :P