I am not a great fan of agile and people that argue strongly for it. I like tools that encourage critical thinking and design development docs, well defined prototypes, and working on customer requirements docs. I think Agile in it's most naive form makes those things harder than they need to be, but of course you can fit good practice into almost any framework.
I am though a big fan of frequent checkpoints, and checking in with the 'big engineering' / 'refactor everything' people before they get too carried away with code only tangentially related to the business case. Agile provides a really good 'excuse' to do the check in, demo code, and a time to reflect if what the developer has is good enough to hit the aforementioned customer requirements.
In my experience, definitions of managers and what they should be doing varies widely. A lot of developers I meet these days put a pretty narrow scope on what constitutes 'management'. The bar is pretty low, and seems to get hotly debated as marginally useful to redundant on reddit and other places. Frankly it's hostile enough I'll be glad when I retire.
I think the better managers have 1:1's were they think about it before and after as opposed to just showing up. They have career plans and objectives on a quarterly basis, and they do it with the employees as partners, not just recipients. Operations, planning to make sure teams work reasonable hours, managing customers, documentation, hiring, budget, procurement, audits & process, salary planning, all of these things are in scope where I learned about management. Managers also lose control of the hours in their schedule, they need to work on other people's schedule in the team more often than not ... urgent issues for people can come up all hours of the days, nights or weekends. If you're a good manager you're there for people when they need it.
I don't meet a lot of managers that both do those things & really want to do them. I meet a lot of good team leads who are also coding that don't do the above, which frankly should be ok and rewarded. It's misleading to suggest though that they could also pick up everything else and still have the same time available to code.
Coded for 10 years, been a manager or higher roughly the same period of time.
What knocked me out of coding ... you should always give your best work to your people ... don't steal it, never block the team, and do the work your team doesn't want to ... e.g. c*p deflection. For any reasonably sized team (8+) and company that isn't a startup, that's a full time job. That's without going above and beyond the low standards most people set of managers these days ... working career planning, understanding industry technical and business trends, helping people realize their better ideas and so on.
One other thing I've realized ... anyone that's hiring knows that it takes new hires time to come up to speed. Depending on how optimistic or senior you are, that can be anywhere from 1 to 2 months full time. If you're a manager, you should look in a mirror, that's you. That means to be anywhere near as effective you need a month to focus on bringing yourself up to speed while delivering on some content your team needs.
If you're a full time manager doing a good job, that's not a thing unless you are giving up nights and weekends to do it.
I miss my years coding and delivering though, when I finally get to a 'work on my own terms' state towards the end of my career, I'd really like to go back to it though.
I think it's deceptive to say it's a single zone. We have VMs across three zones, but anything stateful on zone a is stranded, we can't get the volumes back. It's not just that the zone is down, it's that services are not easy to fail out of the impacted zone or move that's the problem.
Kind on implies regional isn't good enough to secure high availability. You need multi regional deployments. Good luck with that when the bill comes due.
The most useful piece of advice I have gotten for estimates is that they are all junk until someone sits down and tries to do the work. For big jobs, 20% of it, small jobs pushing 50% of the work.
In every single case when you've done that much work, I seem to wind up with a reasonable estimate.
If we've done the job before and have data on it, also reasonable.
Started small with k8s / gke, suffered a lot, coming to appreciate it as we grow. I think over the last 1-2 years there weren't a lot of other choices.
Knowing what I know now, I think if you are successful something like k8s is required to scale and you are running non trivial apps. For trivial stuff I'd go serverless plus some kind of managed app platform as much as possible.
For non trivial, there are stripped down k8s distributions out there that would work and let you work in portable containers. I'd think pretty hard about something like Rancher to get started, and 'graduate' to GKE / EKS / AKS when you hit scale with at least 100's of VM's. You need to keep it in containers to plausibly make the switch though and not require a rewrite later. I think Rancher deploys on all the major and smaller cloud vendors, is small enough to run on your desktop, still do development, and adheres to the API standards you'll care about later.
Surprised I haven't read this in thread yet, but isn't this Issue what makes homekit enabled routers appealiNg when they finally release ? As I understand it the router can isolate Internet access on a per device basis.
Yes you can VLAN & firewall your way to the same place, but dealing with it at a consumer router level seems like a really great feature of homekit to me.
And yes, homekit supported devices are relatively rare and often more expensive, and they don't have a $€|$$> doorbell. But If we are talking about BSG Colonial style dishwashers, then this seems like a small price to pay.
I am though a big fan of frequent checkpoints, and checking in with the 'big engineering' / 'refactor everything' people before they get too carried away with code only tangentially related to the business case. Agile provides a really good 'excuse' to do the check in, demo code, and a time to reflect if what the developer has is good enough to hit the aforementioned customer requirements.