This might not make sense at a small company that has few internal stakeholders or that can deliver a feature soup to nuts in a "sprint". In large companies, like Amazon where I work, this is great because the smallest unit of time to deliver any marginally complex new feature or application appears to be somewhere around 3-6 months of effort.

This is a great mechanism for routine check-ins during that time.

it's a farce. Interesting idea in theory, terrible in practice. The away team incentive is "launch as fast as possible at all costs" and that goes about as well as you'd expect.

We constantly deal with shit code and loose rules. Given that many away teams work in different time zones AND Amazon gives them carte blanche to get their work done, the host team can't manage them effectively.

So yeah. On one hand management is like "push back! Make them follow your standards!" while also saying "Don't dedicate time to away teams, you have your own deliverables."

It's a major drain on the home team and can cause a lot of unnecessary stress.

These opinions are my own, obviously, lol.

My (limited, retail only) experience tells my gut that most retail investors do it to get rich, and not to learn the markets, learn the risks, and build a business. They are different goals, granted both do seek to make long term gains.

I like to believe that retail investors can make it if they put in the effort and learn to manage risk appropriately. At least I need to tell myself that as I work towards making money in the markets myself.

I am definitely dumb money right now, and I could also be delusional, but saying there is no hope so give up and just do something else completely is just defeatist.

My principal engineer values "The best possible solution" while I value delivery even if there are some short term tradeoffs. We are often at odds and since he's a level above me, he wins (generally speaking). Because he is a core feedback provider to my promotion I have a harder time getting the feedback I think I should as I'm expected to be his version of a principal engineer, and not mine.

As you move up the ladder it seems convincing people you are successful is more important that actually being successful.

Bi-directional data binding and the isolation between style, structure, and logic felt was less productive. Angular has some nice properties, like dependency injection built in, but you can circumvent many of those needs with a functional component tree in react (or limit the surface area across components). The simple fact that you need @Output event emitters to handle callbacks is a good example of how bloated it feels.

It may be that I don't know nearly enough about Angular but even after a year of doing my best to learn the idiomatic Angular ways I wasn't impressed.

The tide in the US seems to be normal people vs business with this idea that all businesses are out to take advantage of employees and I just don't feel that's true in a general sense.

Granted, I'm a highly skilled software engineer making great money and with seemingly limitless opportunities in the current market so saying I have privilege is an understatement.

For reference, we migrated to new t4g instances on AWS and received about a 100x performance improvement for a similar (sometimes cheaper) price than Heroku. We are also able to connect to our company VPC and use private resources partitioned elsewhere in AWS (e.g. a redis cluster that costs the same as Heroku with far fewer limitations).

The downside is obviously configuration and learning AWS. Thankfully, we are pretty well versed in AWS here.

I'm just complaining to complain lol.

After migrating an entire startup infrastructure from Heroku to AWS I'm even more against Heroku given how easy it is to use something like Elastic Beanstalk to do the same thing without many of the same downsides.

I've been burned by Heroku, though, so I have a strong negative opinion.