I see people grow in two directions. Some grow upward, becoming manager, director, VP, etc. Others grow outward, branching into new technologies and disciplines, while remaining an IC.
Regardless of which direction you grow, I think give. enough time, the quality of your work will speak for itself.
I've watched too many people try to run the rat race of moving up the later. Staying at a job/role for only 18 months just to hop to the next thing. They lack depth in their area and eventually bottom out completely.
I started using "The Cloud" in 2012 to build apps. At the time they called it Google App Engine. In the last 13 years a lot has changed and I've used all the main cloud offerings.
I've been a part of many outages that originated on our cloud provider. And what I've learned is the best practices rarely save you. We pretend multi-az, global DBs and fail overs protect us, but they don't. They make us more scale able, but not more resilient.
MSK IAM support has long mystified me. I think they only supported Java for the first 9 months or so. Even then they still don't have GO or PHP support. It's not a ton of work, they're reusing request signer code anyways.
I work at a popular Seattle tech company. and AI is being shoved down our throats by leadership. to the point it was made known they're tracking how much devs use AI and I've even been asked when I'm personally not using it more. and I've long been a believer in using the right tool for the right job. And sometimes it's AI, but not super often
I spent a lot of time trying to think about how we arrived here. where I work there are a lot of Senior Directors and SVPs who used to write code 10+ years ago. Who if you would ask them to build a little hack project they would have no idea where to start. And AI has given them back something they've lost because they can build something simple super quickly. But they fail to see that just because it accelerates their hack project, it won't accelerate someone who's an expert. i.e. AI might help a hobbyist plant a garden, but it wouldn't help a farmer squeeze out more yield.
pdfbox is just as good for 99.9999% of documents. We used to use iText and in the last renewal, they tried to 10x our yearly license cost to the point it would have been more expensive than our AWS bill. No thanks.
I completely agree. I've worked at three places with unlimited PTO and none of them do. I think the moment you set that expectation the illusion of being unlimited goes away.
Beyond the fact that it is a total scam, it also creates a lot of animosity among employees. Because there is no set limit, heck there are rarely guidelines, people often feel it's used unfairly in their teams and org.
> but more importantly it takes just doing fantastic work when the opportunities present themselves.
It has taken me a decade to realize this is the key to success. Just do your very best work, as often as possible, and let the rest figure itself out.
I accidentally created a data warehouse that became the necessary backbone to launch a massive new org (100M+ revenue). I was building it for a relatively small near realtime Elasticsearch cluster to generate data reports for an application. But I thought, gee, if I suck in a bunch of other data from other sources and clean it, I might find a use some day. Little did I know that someone else would piggy back on it to build a POC for a giant business expansion.
There is another dimension to this that most people haven't talked about, remote and gig work. For most small and medium businesses, it's cost prohibitive to hire remote employees. For larger companies it's very easy. This has created a regional imbalance.
Lots of knowledge working and call center opportunities are moving to full time remote. Paying employees the same with better benefits to never leave their house.
This article amounts to someone whining because they didn't take necessary action to prevent a dumpster fire. AWS's Managed Elasticsearch has tradeoffs and you should understand them before choosing it, but AWS is not to blame if you've under provisioned your cluster and imbalanced your shards.
Lack of security? AWS offers very granular, per index, authorizations that are tied into IAM in the same way you would configure S3 or DynamoDB. If user's are failing to implement good policies, AWS is not to blame.
This is a non-issue. The URLs are way to unique to guess (you'd have an easier time guessing an email/pass/2FA). And ones ability to access the URL at all is the same as their ability to access the bytes of the image. Once accessed, they could capture and share either.
I would love to see the look on the face of the guy at the Apple Store when OP pulls out the multimeter. No disrespect, but in my experience they're good at handling common issues and terrible when you have something unique.
Serious question, what's the real harm in this since it's just public keys? Just allowing a server to discover all the other servers you may have been talking to?
Well the Glimmer 2.0 effort started around the same time Ember 2.0 shipped (Aug 2015). That was 16 months ago, Glimmer 2.0 shipped about 2 months ago, ergo 14 months. I agree that it wasn't under development the entire time, but it was a blocker for many other features the entire time.
Basically when 2.0 landed, routable components couldn't be worked on until glimmer components were completed. Angle brackets, Improved Pods, etc, same.
So even if it wasn't under dev that whole time, it held back other features that would have really improved Ember.
LOL. I love how full of his own crap Tom Dale has become.
Ember is a good framework with a lot of potential, but more than anything it needs a good PM. Ember devs just spent nearly 14 months rewriting the layout engine (Glimmer 2.0) that they had spent the prior 8 months writing (Glimmer). And what do they have to show for it? A 100ms or so speed boost on complex views. Instead they should focus on fixing up the crufty parts of their API and adding feature they've been promising users for years. Instead Tom Dale has been off writing FastBoot, an even more niche component of Ember that very few apps will even use.
React and Angular are far from perfect, but one upside is they have parent companies to help keep them focused.
This is an opportunity to bring dollars and jobs to their state and the only reason they're resistant is to stick with party lines.