I think what's impactful about this approach is how it allows a team to share progress and get early feedback from key stakeholders. If you demo to the team that built the software you might get marginal value, but when your leaders are involved, or when key customers are involved, this can be powerful. Demoing a project early is a great way for those with skin in the game to help change course early, or ensure that the deliverables will meet the quality bar they expect before it's too late. It also helps set expectations for how long the average development cycle is, and with tangible progress highly visible, can help ease concerns on timelines and delivery.
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.
I'm at Amazon now and my team is often the target of away team work as our system is seen as "critical" to other business unit growth.
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.
i feel that this assumes the large investors on wall.street are playing the same game as retail investors. Given the size and scale of their accounts, I'd imagine it's an entirely different playbook.
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.
The adage of "It's who you know" applies in all industries, even tech. you are right, it's opinion based. Depending on the values of your team or organization the criteria for success will change.
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.
Something about VB6 felt so pure when I wrote it. it's not fancy and is missing a lot of stuff we take for granted today (pretty sure there is no built in map structure lol) but solving problems in VB6 due to language quirks was always fun.
I used Angular at my last company. After having used react for many years and then experimenting with svelte, Angular (even the most modern versions) felt like it was always in my way.
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.
I agree with you as I've never seen this side of HR and I've worked at various companies in the US (including Amazon, which was by far my best employer).
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 us it was mainly the fact that every month some part of Heroku is down or degraded. That and the huge price increase when jumping from the standard dynos to the large dynos.
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.
Well Heroku is overpriced garbage so that's not surprising. They rely on lock in to keep you stuck paying egregious fees for services that are relatively unreliable.
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.