Is it because most people are willing to pay someone else to manage monitoring infrastructure or other reasons?
Almost every infrastructure decision I endorse or regret
511–520 of 644 posts
Re: Almost every infrastructure decision I endorse or regret
#512Earlier quoted context omitted.
I don't want to be negative, but this post reads like a list of things that I want to avoid in my career. I did a brief stint in cloud stuff at a FAANG and I don't care to go back to it. Right now I'm engineer No. 1 at a current startup just doing DDD with a Django monolith. I'm still pretty Jr. and I'm wondering if there's a way to scale without needing to get into all of the things the author of this article mentio…
I'm currently early in my career and "the software guy" in a non-software team and role, but I'm looking to move into a more engineering direction. You've pretty much got my dream next job at the moment — if you don't mind me asking, how did you manage to find your role, especially being "still pretty Jr."?
The things I did to get here are honestly kind of stupid. I started out at a defense contractor after graduating and left in the first six months because all the software devs were jumping ship. Went to a small business defense contractor (yep that's a thing) and learned to build web apps with React and Django. Then the pace of business slowed so after about 18 months I got on the Leetcode grind and got into a FAANG. Realized I hated it, so I quit after about 9 months with no job lined up.
While unemployed I convinced myself I was going to get a job in robotics (I actually got pretty close, I had 3 final level interviews with robotics companies), but the job market went to shit pretty much the exact day I quit my job lol. I spent about 6 months just learning ROS, Inverse Kinematics, math for robotics, gradient descent and optimization, localization, path planning, mapping etc. I taught at a game development summer camp for a month and a half, that was awesome. Working with kids is always a blast. Also learned Rust and built a prototype for a multiplayer browser-based coding game I had been thinking about for a while. It was an excuse to make a full stack application with some fun infrastructure stuff.
https://ai-arena.com/#/multiplayer
The backend is no longer running, but originally users could see their territory on the galaxy grow as their code won battles for them.
For the current role, I really just got lucky. The previous engineer was on his way out for non-job related reasons. He had read a lot of the books I had (Code Complete, Domain Driven Design) and I think we just connected over shared interests and intellectual curiosity.
I think that in the modern day, so many people are really just in this space for the paycheck-- and that's okay! Everyone needs to make a living. But I think that if you have that intellectual curiosity and like making stuff, people will see that and get excited. It ends up being a blessing and a curse.
I have failed interviews because of honesty "I would Google the names of books and read up on that subject" or "I think if I was doing CSS then I would be in the wrong role" (I realize how douchey that sounds but I just was not meant to design things, I have tried). But I have also gone further in interviews than I should have because I was really engrossed in a particular problem like path planning or inverse kinematics and I was able to talk about things in plain terms.
I think it's easier to learn things quickly if they are something you're actually interested in, it becomes effortless. Basically I just try to do that so I can learn optimally, then I try to get lucky.
EDIT: Oh I just thought of more good advice. Find senior devs to learn from. They can be kind of grumpy in their online presence, but they help you avoid so many tar pits. I am in a Discord channel with a handful of senior engineers. The best way to get feedback is to naively say "I'm going to do X", they will immediately let you know why X is a bad idea. A lot of their advice boils down to KISS and use languages with strong typing.
Re: Almost every infrastructure decision I endorse or regret
#513Earlier quoted context omitted.
Azure is a complete disaster, deserves its own garbage-category, and gives people PTSD. I don't think AWS/CGP should ever be compared to it at all.
Funnily enough, I have the opposite opinion. AWS has "fun" features like the ability to just lose track of some resource and still be billed for it. It's in here... somewhere. Not sure which region or account. I'll find it one day. GCP is made by Google, also known as children that forgot to take their ADHD medication. Any minute now they'll just casually announce that they're cancelling the cloud because they're bor…
How can you even compare it to AWS is a mystery to me. There are pages showing all your resources, not sure why you think it's a problem. Could be a problem from long time ago?
Re: Almost every infrastructure decision I endorse or regret
#514Earlier quoted context omitted.
I thought you meant API and parameters. Blaming them for product names is weird to me.
why is that?
Re: Almost every infrastructure decision I endorse or regret
#515Earlier quoted context omitted.
I thought you meant API and parameters. Blaming them for product names is weird to me.
It's nice when things do what they say on the tin. That being said, it's hard to build a "brand" when you start out with a generic name.
Re: Almost every infrastructure decision I endorse or regret
#516Earlier quoted context omitted.
No, but again, that sounds like a lot of complexity your average startup does not need. Multi-az? Why?
Because their Enterprise client requires it on their due diligence paperwork.
Re: Almost every infrastructure decision I endorse or regret
#517Earlier quoted context omitted.
BigQuery - Athena Pub/Sub - Kinesis Cloud CDN - CloudFront Cloud Domains - Route 53 ...
Perfect list, also: Google Cloud Run - Lambda Sure I get the reference to the underlying algebraic representation of coding but come on, Lambda tells us nothing of what it does. Products (not brands, products) should be named in a way that means something to the customer afaic.
Re: Almost every infrastructure decision I endorse or regret
#518> Picking AWS over Google Cloud I know this is an unpopular opinion but I think google cloud is amazing compared to AWS. I use google cloud run and it works like a dream. I have never found an easier way to get a docker container running in the cloud. The services all have sensible names, there are fewer more important services compared to the mess of AWS services, and the UI is more intuitive. The only downside I ha…
I don’t have as much experience with aws but I do hate gcp. The ui is slow and buggy. The way they want things to authenticate is half baked and only implemented in some libraries and it isn’t always clear what library supports it. The gcloud command line tool regularly just doesn’t work; it just hangs and never times out forcing you to kill it manually wondering if it did anything and you’ll mess something up runnin…
Re: Almost every infrastructure decision I endorse or regret
#519Earlier quoted context omitted.
We have all of that neatly extracted into a Terraform module. Write it once and now EKS clusters are essentially disposable.
You just added yet another Thing in that huge pile of things representing millions of lines of code. That's the point.
Re: Almost every infrastructure decision I endorse or regret
#520Earlier quoted context omitted.
BigQuery - Athena Pub/Sub - Kinesis Cloud CDN - CloudFront Cloud Domains - Route 53 ...
I thought you meant API and parameters. Blaming them for product names is weird to me.