I keep trying to read Diaspora and struggle too much with the concepts presented early on. Very "hard sci-fi", just stick it out and it all gets explained?
The beginning describes the formation of an intelligence and it is indeed very dense. You can figure out what's going on but it takes some slow reading, and probably best to revisit it once you have some more context from later in the book.
The whole book isn't like that. Once you get past that part, as the other commenter said, it gets much easier.
I actually love the beginning of Diaspora, and have recommended just that section to people. I found it beautiful and moving. It's starting to learn that people have to "get past" that section...
Egan is always dense. It's some mind bending physics/comp sci, but all cooked up in his brain so doesn't really apply to anything productive. I struggled with his books and his writing but toughened it out because I liked the concepts, but he's divisive.
Another book by Greg Egan - "Zendegi" - has more overlap with MMAcevedo. It covers a different approach to mind uploading (possibly) more practical in near future: a generic model of the brain is fine-tuned on responses from a specific human. The generic model itself is made by averaging over many scanned connectomes. The other part of the book is VR Shahnameh which, honestly, was a bit too boring.
He also has a whole bunch of short stories on the same topic. Some assume reader is already familiar with concept of sideloading, as it's explained in the passing:
Yeah, I read a zine the other day, where a sociologist warned that the biggest threat isn't that AI destroys jobs, it's that AI is compacting the work per person.
Employers expect more from each employee, because, well, AI is helping them, right?
Some people mentioned to me that going Solutions Engineer was a good way to get more non-technical/business skills.
I saw a few SEs starting their own companies later, seemingly because their SE roles "trained" them for the business side of things.
I considered doing this myself; however, I'm a freelance software engineer and technical writer. More a jack of all trades than someone with major skills in one category of software engineering.
You can hate coding and be an excellent network engineer or even DBA.
I'm an infrastructure guy and I learned to code, but I don't code today. The other poster who talked about good people in the old days using Perl and suchlike tools is right. Competent people care about automation.
But there are all sorts of automation tools that don't require knowing how to write object oriented code or do a ton of code reviews. Terraform is one - it's yaml, and the complexity is one of design patterns. Another is Ansible. GitHub Actions. Many many more.
Let me throw out a grenade. Software developers often over estimate their capabilities in technology. Because a person is an expert in Ruby or Go, and on the weekend they stood up a hosted app on ECS, now magically they're geniuses and understand DevOps.
False. DevOps engineering, network engineering, DBA, and a lot of other non-developer jobs take 5-10 years to get right.
Hopefully I've slammed our Leetcode hiring practices, but really I'm just venting at this point.
It’s a red flag anytime I see a company with a dedicated “database administrator” usually they want you to put all of your business logic in stored procedures and have a dozen GetCustomer_n copies for versioning.
What can a modern operations person do that can automated anything via coding?
BTW: I am “expert” in cloud by any definition (did at a startup, worked at AWS ProServe, staff consultant at a 3rd party consulting company) and I develop. How hard do you really think it is for someone with a developer mindset to learn how system design works at scale and bring their same developer mindset to infrastructure as code?
It took me exactly 2.5 years from opening the AWS console for the first time to being hired at AWS.
Everyone in my division at my current company at my level can hold their own as either a developer or a “senior cloud engineer”. We just find infrastructure babysitting incredibly boring
Half the reason I learned cloud was not because I didn’t want to manage servers - I didn’t want to deal with server administrations.
>BTW: I am “expert” in cloud by any definition (did at a startup, worked at AWS ProServe, staff consultant at a 3rd party consulting company) and I develop. How hard do you really think it is for someone with a developer mindset to learn how system design works at scale and bring their same developer mindset to infrastructure as code?
It depends! Do you mean clicking in the AWS console and spinning up infrastructure? It takes a few days.
Learning terraform/CloudFormation so it's repeatable? Probably a few weeks.
Kubernetes design patterns and troubleshooting? I feel like it takes at least a few months of hands on and theoretical.
To build infrastructure that lasts, is monitored with an APM as well as infrastructure specific tooling (not Cloudwatch) has cost dashboards set up to account for workloads across a dozen product lines (not Cost Explorer), has a CI CD pipeline automation for hundreds of repos including automatic onboarding of new ones, understands cloud security enough to have designed a tight perimeter with some automation around detection and remediation, has strong network level knowledge and knows how to deal with external vendor/client connectivity options (since you have to adapt to their limitations or demands)... Instead of server babysitting, you know in advance how to prepare the inevitable situation where workloads need to scale, and already have tooling and horizontal and vertical auto scaling either automated or ready to go...
If you know these things after 2.5 years, and I say this fully seriously, you are in some sort of .5 percent elite in this industry and deserve something like 1M a year, or you should be leading something huge.
Otherwise there's a risk here that you don't know what you don't know, which was my original point about over confidence by software engineers when it comes to infrastructure.
You did see the part that I worked at startup for 2.5 years, then worked at AWS ProServe for almost 4 and now work at a third party consulting company as a staff consultant leading cloud + app dev hybrid projects?
I turned down a job where the position was going to be created for me by a former coworker at AWS who is now a director at a well known non tech F500 company where I would be responsible for a multi year migration and modernization strategy that would have paid about 30% more than I was making at AWS.
I really hate babysitting infrastructure and lift and shifts so much I turned it down and took a job that paid the same as I was making at AWS. That’s just how much more I enjoy the hybrid cloud + app dev roles.
I deal strictly with AWS on the infrastructure side, the minute I’m working on a large assessment (those huge 50 page requirement docs) and they mention hybrid, or anything outside of AWS, I bring in someone who actually likes that stuff. As I do when I see it’s going to be a migration.
The other side of my job is to actually do hands on app dev + cloud either doing it myself for small projects or leading larger ones.
I’m also not the person who is going to be on call or monitoring, that’s for the young folks.
My last three projects were using the CDK, Terraform and CloudFormation respectively
I'm with you on the avoiding tedium, on-call and monitoring and overall Operations pieces of it.
There's an infrastructure creation aspect where you're creating automation systems and passing it along for others to maintain. I personally think that's a sweet spot.
Everything you said here I relate to, it seemed like you were arguing that infrastructure design and systems engineering is just "app dev ++" as opposed to a collection of skill sets that take years to learn.
It's no different than AI slop if someone thinks cloud automation is just another programming framework to learn. I've worked exactly in 0 companies that got it right when it came to intelligently designed, bullet proof systems. Some of the slop and chaos is so bad it takes big new projects and smarter hires to repair it.
