• 0 Posts
  • 59 Comments
Joined 2 years ago
cake
Cake day: December 17th, 2023

help-circle
  • I see you mention Azure and will assume you’re doing a one time migration.

    Start by moving everything from OneDrive to S3. As an AI I’m told that bitches love S3. From there you can subscribe to create events on buckets and add events to an SQS queue. Here you can enable a DLQ for failed events.

    From there add a Lambda to listen for SQS events. You should enable provisioned concurrency for speed, the ability for AWS to bill you more, and so that you can have a dandy of a time figuring out why an old version of your lambda is still running even though you deployed the latest version and everything telling you that creating a new ID for the lambda each time to fix it fucking lies.

    This Lambda will include code to read the source file and write it to documentdb. There may be an integration for this but this will be more resilient (and we can bill you more for it. )

    Would you like to see sample CDK code? Tough shit because all I can do is assist with questions on AWS services.





  • Yeah I was trying to pull out a nested react component and styles out of a larger component that got to be almost 1500 lines. Claude and GPT both struggled to get down what styles were required and what that subcomponent was actually doing. And generating tests around just made a fuck ton of spaghetti.

    Which is fine. LLMs don’t have to be great at everything. But it’d be nice if people stopped saying I’m gonna be out of a job because of em.

    Also a good warning: I just had to completely rewrite an mcp server I had Claude build because when I needed to update it, the whole server was one giant if/else statement and utterly unmaintainable.

    I’ve noticed that in some of my bootstrapped code (also an MCP server :) ). I think it tends to bias towards single file solutions so it tends to be a lot less maintainable.






  • It’s a bit misleading for engineering.

    Every Engineer starts at L4. That’s the junior position.

    L5 is the mid-senior level. Most SDEs in Amazon are L5 and that’s considered a terminal position. For management this is the “junior” (for lack of a better term) tier

    L6 is Senior but it’s closer to staff engineers at other companies. You tend to do more cross team work. This is also where a glut of managers are at

    L7 is Principal engineer and senior manager. Only about 2% of engineers get here. Managers at this lever oversee multiple teams.

    L8+ is fancy external hires and directors.

    The problem is that Amazon expects a lot of people to churn out before you hit the L6/7 levels. They dangle a carrot of super high pay for those tiers but don’t actually expect to pay it long term. There’s quite a few that have stayed longer than expected. And it’s hard to get out because they know how to game the system to demonstrate “impact”. Now that isn’t to say there aren’t a lot of good managers and engineers at this tier either. There are really good people at this tier. It’s just Amazon doesn’t want that many at this tier for long.

    Also if the idea of having an expected churn and dangling pay that no one can hit sounds dystopian and awful it is. Amazon sucks.