It's quite telling how dumb even Apple thinks the case is when you have to scroll pretty far down on the page and then pretty far to the right to see the so-called "Smart Case". It remains a pretty horrendous "case".
Speaking of unique names within AWS, I learned the other day that even after you delete an AWS account, you can’t reuse the root user email addresses (it’s documented, but I wasn’t aware).
Someone at my org used their main company email address for a root user om an account we just closed and a 2nd company email for our current account. We are past the time period where AWS allows for reverting the account deletion.
This now means that he isn’t allowed to use SSO via our external IdP because the email address he would use is forever attached to the deleted AWS account root user!
AWS support was rather terrible in providing help.
AWS support seems to be struggling. I just came to help a new customer who had a rough severance with their previous key engineer. The root account password was documented, but the MFA went to his phone.
We've tried talking to everyone we can, opening tickets, chats, trying to talk to their assigned account rep, etc, no one can remove the MFA. So right now luckily they have other admin accounts, but we straight up can't access their root account. We might have to nuke the entire environment and create a new account which is VERY lame considering they have a complicated and well established AWS account.
Amazons assistance for account issues to organizations if an employee did anything individually is honestly horrible.
They treat it like the organization is attempting to commandeer someone else's account so all the privacy protections you expect for your own stuff is applied no matter how much you can prove it is not some other individuals account.
The best part is the billing issues that arise from that. In your example, if the previous engineer logged into that account (because they can) and racked up huge costs, assuming that account is getting billed or can be tied to your client, Amazon will demand your client pay for them, while at the same time refusing to assist in getting access to the account because it's someone else's. They hold you responsible, but unable to act in a responsible manner.
While true, the engineer would have to be a weapons grade tit to get themself in such legal trouble, and honestly deserves whatever criminal charges comes their way.
Is this something where you could pay a "consulting fee" to the previous key engineer to login and remove the MFA?
I know that that's not ideal, but as a practical matter perhaps it would be easier than creating a new account, if you can get the engineer to agree to it?
when your startup is three employees and only one technical? this person created their AWS root account, I think it's fair to assume that he's their first engineer and probably first employee
Yes, I am very familiar with zbarimg and qrencode. But, other people might not be, and that's why just scanning a QR code works. Not everyone has Bitwarden, 1Password, Pass, keepass, etc.... also these tools may not be approved by your security teams.
And we are talking about the root account for your production AWS account. No need to get fancy. Just print the QR code, and put it in a safe hoping you never need it.
I won't attempt to defend AWS here, but if any company has such incompetent IT management as to allow an individual employee to have that level of control then they kind of deserve what they get. Life is hard when you're stupid.
That's not an equivalent analogy. A better analogy would be to say I had a bank account and I told my bank to call up Joe on the phone when confirmations were needed. I still have the account, but I have fallen out with Joe. I want the bank to call somebody else, but they refused to do so, even though it's my account and I'm paying the bill for it!
Banks have established processes for changing signatories on business bank accounts, including in situations where a past signatory is no longer with the business.
In a nutshell: if a past signatory was a regular employee, it just takes any other signatory to remove them. If there was no other signatory, or if the past signatory was an officer, it takes a current officer (as set forth in the company's AOI or corporate minutes). Usually only the latter 2 situations of the 3 above require an in-person visit to the local branch office, and that only requires a few minutes.
I don't really understand that problem, exactly. I'm not aware of any restrictions for using AWS Identity Center (SSO) with an email address that happens to be a root email for another AWS account.
I checked the documentation but I couldn't find anything to show this to be a problem other than that the practice is discouraged.
I create "job function" DLs. "Company-Region-IT Manager". Then give that DL it's own SMTP address. Then use that.
It's really nice when you have to hire someone new for the position. You add them to the DL and they're automatically in control of all those accounts.
Or you don't have employees using their personal email to open corporate accounts.
Still on Amazon to clearly tell people it is this way so they can properly plan for it, but employee's email addresses really shouldn't be used for the root account.
That’s not what’s being described here. What OP described is the much more common situation where employees use a personal phone for MFA. Sure, some places issue hardware dongles and disallow authenticator apps on your personal phone, but IME most places default to just having people use their phone.
You should not have the root account be a human anyway. Make that a special account, secure the credentials and only ever use them when you screw something up really badly.
Good for them. It's amazing how pointless most
security is when a 10/10 rating to some commodity
communication service's support from a phisher
is all it will take.
Help me understand why you would delete your AWS account if the company and email address are unchanged - I can’t see the motivation.
And on the flip side I can easily see why not allowing email addresses to be used again is a reasonable security stance, email addresses are immutable and so limiting them only to one identity seems logical.
Sounds quite frustrating for this user of course but I guess it sounds a bit silly to me.
This was a secondary AWS account in use by the company that had been in place for quite some time and that secondary account was just no longer needed. So to consolidate things down, it was deleted. Also at that time, SSO wasn't being used for anything with the company - and they were on a completely different email provider.
I'm not arguing that it was impossible to know the long term outcome here, but it doesn't mean it isn't frustrating. If you've spent any length of time working in AWS, you know that documentation can be difficult to find and parse.
I can certainly understand why the policy exists. What I think should be possible is in these situations to provide proof of ownership of the old email address so it can be released and reused somehow.
>Help me understand why you would delete your AWS account if the company and email address are unchanged - I can’t see the motivation.
Have you ever worked in a company of any size or complexity before?
1. Multiple accounts at the same company, spun up by different teams (either different departments, regions, operating divisions, or whatever) and eventually they want to consolidate
2. Acquisitions: Company A buys Company B, an admin at Company A takes over AWS account for Company B, then they eventually work on consolidating it down to one account
It's such a common case, especially in tech with startups and small software companies getting gobbled up all the time I can't see how you WOULDN'T consider it a possible reason
Yes. There are solutions to all of these issues, but what often happens is these situations come about through the natural course of companies changing over time - different people managing accounts, different providers, etc. The happy path is easy, but the happy path is rarely the one we find ourselves walking down when we inherit a previously made decision.
It’s not hard to imagine a case where maybe there’s 2 offices that had their own separate aws accounts and they closed one.
AWS has been around for quite a while now. It’s also not impossible to believe that there are companies out there that might have moved from aws to gcp or something, and maybe it’s time to move back.
> And on the flip side I can easily see why not allowing email addresses to be used again is a reasonable security stance, email addresses are immutable and so limiting them only to one identity seems logical.
If they aren't actually deleting the account in the background and so no longer have a record of that e-mail address, then they must allow re-activation of the account tied to that e-mail address using the sign-up process.
And in this case, it’s actually less secure for this one user and the account if as a workaround I’m required to create an IAM user for them (even though I can limit their use of the system).
I would expect the SSO configuration to map the IdP's given email into a role appropriate for the identity. What does "forever attached to the deleted AWS account root user" mean here? What is the mechanism blocking use?
That seems like a GDPR violation waiting to happen. It shouldn't be possible for them to store an email address like that forever and be in compliance.
You can't derive the original better than guessing. With public identifiers you can just take a list of them and guess with those. If someone asks for your email they can hash it themselves and compare it against whatever databases.
If user foo@gmail.com violates our ToS and I suspend them, I can keep that email address forever to keep them from signing up again. They can’t just say “GDPR! You have to forget me, tee-hee!”
Yep. Almost every company uses multiple vendors for things. Suppose you use a tech support helpdesk and you don't want to waste time dealing with banned ex-customers. You can't import that list of hashes into Zendesk or whatever and tell them to blocklist them.
Substitute "billing company" or "authentication provider" or "fraud detector" for "helpdesk". There are times when it's not sufficient to say "don't do business with SHA-256 hash ef61a579c907bbed674c0dbcbcf7f7af8f851538eef7b8e58c5bee0b8cfdac4a". You need to say "John Smith is banned".
Under "Prerequisites"[0] I see: "Get an Anthropic API key".
I presume this is temporary since the project is still in alpha, but I'm curious why this requires use of an API at all and what's special about it that it can't leverage injecting the prompt into a Claude Code or other LLM coding tool session.
“I’ll just say it: I think I’m done with iPads. Why bother when Apple is now making a crackerjack Mac laptop that starts at just $600?”
I’m curious to see this machine in person, but I’d bet the an iPad is still the best large device in Apple’s ecosystem for anything that benefits from viewing in portrait mode.
Portrait or landscape - if your use is dominated by looking at the screen and/or situations where it can't set it down (to use the KB), then the iPad is better.
Assuming the software you need supports iPad, etc.
Cheers, opening System Settings and then Option clicking Displays, did the trick and showed the rotation option for the built in display. It's mostly PDFs I'd be reading so might try the PDF reader option, as yeah, navigation using the trackpad after the screen rotates is challenging.
Edit: Just tried rotation in the built in MacOS Preview app, (Command+R or Command+L) and works really well. You do have to set the View to Single Page, and rotate each page separately (it does remember which pages were rotated), but other than that it's great.
No, you’re not the only person. I use it to read news, blogs & hckrnews. Probably more than 2h per day. Often in an IKEA bamboo Bergenes, which I have several laying around the house, upside down with a usb-c cord charging it till 80%.
If you are reading this and you are thinking you want to become an engineering manager, I urge you to think long term what you want that to look like. I've seen too often that developers who want to become managers because they think it's the next inventible step aren't prepared for the people management and HR part of that role.
And, as you move up to Director and beyond, those higher often have much less to do with actual engineering than tasks that sort of surround the world of engineering - lots of organizing information and attending meetings.
I've seen too many developers who though they wanted to manage become victim to the Peter Principle [1].
There is nothing wrong with staying a developer, even if you're not "moving up" to some idealized title. If you like the work and you can tolerate the place you work, you're probably ahead of most people in our field.
On the contrary, my manager doesn't do much outside of the perf evaluation season, and takes home a higher salary than me. He also gets to take credit for pretty much everything that his team does, despite not contributing to it much. Sounds like a fairly easy job most of the time.
Here's how I see it: Ideally a manager / reportee relationship is a symbiotic relationship. A manager becomes more successful by making their reportees more successful, and both roles grow together. And repeating this across teams, the whole company grows as well.
There's a lot of nuance but here's a simplistic overview: a manager tries to land a big project for their team, which lets the team stretch their abilities and grow, which over multiple successful deliveries results in promotions / raises for everyone involved AND the cachet to ask for bigger projects (and more headcount!)
The manager's role is the hustling and jockeying in landing the project, ensuring their team is executing and getting any mentorship needed (directly or indirectly) and protecting them from disruptions ("shit umbrella") -- which includes managing everything around the team including stakeholders and dependencies and escalations -- and then making the case for promotions / raises / PIPs based on their performance.
I've never been a manager, but having been involved in all these aspects, I can tell you none of this is easy. All of these can get very contentious, even in the best-run of companies; in the rest, a lot of pathologies spring up (like politics and empire-building) that cause even more nastiness.
So it may seem like they're taking credit for your work, but that's literally part of the arrangement, and it's only unfair if you're not seeing any upside. If you feel that way, this is 100% something you should bring up (very tactfully!) in a 1:1 or (even more tactfully!!!) a skip-level.
I think a good manager should also be a cushion between the higher up politics and his team, so they do perhaps get more praise than is deserved for their team's successes but they should also absorb much of the criticism for their team's failures
Until you are dealing with a difficult employee or struggling with whether to put someone on a PIP or being asked to deliver things you don't have direct control over or dealing with penny-pinching edicts from above etc. etc.
Also when the project becomes a dumpster fire and you have to save it - or go through months of justifying what path is being taken or be clear with leadership what needs to change or be fired for the failure.
Engineering Manager can be a social role with some tech aspects.
You attend meetings, negotiate deadlines, evaluate people, navigate project minefields, take decisions or force people to take them,... and the technical aspects are quite minimised.
Depending on the company this is not an upgrade, it's a lateral move. I have people under me who earn more than me, and I agree with that.
The job it's not easy, it's different. Spending 5 hours on meetings it's easy, but exhausting. Giving credit to your people but taking the blame (which is what should be done) it's easy, but demoralising. Not having a peer group of people with whom easily socialise makes the job feels lonely, when you talk with other managers it's 99% work related, and you can't make your people like you as a person.
Most days I'd love to have a clear objective.
One of the worst is the strange feeling that you have because you've studied for a long time some skills, and worked using them, and now those are hardly used. You need to use a set of skills that you haven't trained for, and haven't used as much (depending on your personality/skillset, of course).
I've jumped back and forth between IC and Management. The roles are measured on completely different things. Most of IC is about through put. Most of management is about building/doing the right thing (aka making money).
Sometimes, it can look like management is doing very little because you only see the tail end of their outputs to the team.
The question to ask of course is do you see how your manager interacts with their management?
Do the things that get done stay consistent, or are your priorities constantly changing? Do you and your team control your priorities or are they out of your control?
I think it's very difficult to see what managers are even doing (I'm not one, I'm a senior IC) until you have a particular level of visibility or exposure to planning and prioritization. But once I started to see that and see why it was hard as I began to interact with it myself, it becomes much clearer.
A lot of people think this until they become managers and discover all the bullshit they have to deal with from above and below. You're literally something of a human shock absorber, and in the analogy when the road is smooth there's not much to it, but when things get bumpy, you're the one taking the hits.
In my experience, I kind of think that The Dilbert Principle [1] holds more than the Peter Principle.
With the Peter Principle, it's implied that they were good at their previous job and are bad at their current one, but having had to debug awful, awful, broken code at Apple by people who had been promoted into managers or directors, I'm not convinced that they were ever good at their job. I remember some code we had in iTunes, my manager would say "that was written by X. Don't worry, he's been safely promoted out of danger".
I think management, especially higher management, is often about how much you can make it look like you're doing important things. It requires zero effort or skill to book a dozen meetings in Outlook or Google Calendar, and it only requires a fairly small amount of effort to make slide shows to talk about how "important" the work is that you're doing. Instead of getting good at engineering and writing good software, it's much easier and more effective to tell people how good at engineering and writing software you are instead. Most of the higher-level managers are pretty removed from the low-level work so when promotions come along, they remember the person who kept booking all the meetings with them and assume what they were doing is important.
I'm admittedly more than a little cynical about this stuff; I have been routinely negative about big corporations (and particularly Apple) and I think that the Peter Principle is assuming a level of rationality and intelligence that I really haven't observed.
I'm a freelance interim EM and I do it for the same reason the article explains: I genuinely enjoy it.
I love engineers and I love tech. I still code daily but I'm not the guy that delivers at the pace of some of the amazing engineers that I had the privilege to work with. I love putting others ahead of myself wherever I can and it's never cost me anything, so I'm not afraid to do it again. I love telling the engineers how what they do actually matters because they're too focused on the work to sometimes see why changing goals doesn't mean their work and efforts were wasted and I also love shielding them from the corporate mess upstairs (that I somewhat masochistically don't even dread being part of)...
So, yeah, I really love my job and if one of my guys (or gals) wants that too, the more of a joy it is to me to mentor them into that process.
> I've seen too often that developers who want to become managers because they think it's the next inventible step aren't prepared for the people management and HR part of that role
As an IC, this is baffling to me because that seems like the biggest and most obvious part of the job. I never want to be approving people's leave requests or telling someone they're being a jerk on slack.
EM is a terminal position that does not own the product roadmap (Product Management) nor the underlying implementation (Staff/Principal Engineers).
They primarily own delivery and execution because orgs can't be bothered to hire program managers anymore.
If you are great at managing upwards and ensuring delivery by hook or by crook, you will make a great EM. But the next jump after EM is extremely difficult because you are competing with Principal Engineers and technical-minded PMs making a lateral move and cofounders who are being managed out by the board; and dealing with micromanaging CTOs or CPTOs.
Are you saying principal engineers and tech minded PMs make lateral moves into director level manager without going through being entry level EMs first?
I've never heard of something like that. Usually the requirement for being director level manager of engineers is to at least have managed people as an EM for several years before.
The pay is aligned with the level whether or not you’re a people leader. To your point though, it may be difficult to go from Principal to Director. I see the lateral moves happen more at the Lead/Sr. Lead levels. They might do a Principal to a Sr. Manager as a trial period with the expectation that you’d be Director after a short time if you perform well. I’ve definitely seen directors become principals as well, so it goes both ways.
Learned something new, about the Peter principle. Thank you. I don't know if I should be surprised that it was published in 1969, and it seems that the principle still holds.
reply