[slowmovintarget]

If someone has been "inculcated their entire career" to be cloud-first, then their career is only six years old. Cloud-first hasn't been a viable solution for much longer than that.

For many endeavors these days, cloud-first will be the correct default choice. Get something up, min-max it later. For most devs, for most workloads, the cost of running a data center isn't worth it.

I've been building software since before the internet was a thing. I'm fairly certain this isn't a pendulum that will swing back the other way. It is a rising waterline.

[kortilla]

> For most devs, for most workloads, the cost of running a data center isn't worth it.

This is complete bullshit. For most devs and most workloads, you don’t need a datacenter, you need a few servers with UPSes.

There is just a vast amount of ignorance that leads both devs and CTOs to pick cloud solutions without even trying. “Put it on the cloud” is the new “nobody got fired for buying IBM”. There are vanishingly small sets of cases where the flexibility of the cloud actually makes sense financially.

> I'm fairly certain this isn't a pendulum that will swing back the other way. It is a rising waterline.

It will when these companies need to start competing on margin.

[rektide]

"you need a few servers with UPSes" imagines a world where companies can responsibly maintain a reasonable computing environment independently. oh such optimism! refreshing!!

we are near to having a world where that might be reasonably possible & likely, thanks to the availability of off-the-shelf open-source broadscale diy cloud software like Kubernetes. but until today, few companies have been able to create & more challengingly maintain healthy points of presence that they can manage & run competently. there have long been offerings like Puppet and Chef & countless others to help a company try to maintain systems, but it's always been a picking of assorted pieces, a cobbling together of various concerns. rarely has running a couple boxes been a reasonably strong competency for most companies, as simple & elegant sounding as the idea may come off as.

and if you do have people with less than stellar, 100% self-hosting experience, they will have no where to go to learn & skill up. all the articles, all the focus today is on using cloud systems. when you're on your own you're on your own.

i do think we are nearing a new era, a new place, where running systems may be possible. but it's only because we have started to upscale & compete with what the cloud offers. we've begun to reconsider how most software is ran, & have advanced our collective skill, knowledge & systems to align towards more managable, coherent, modern practices. we've learned so much. but we're only just beginning to figure out how to deploy & run & keep running these private clouds. and anything less seems like an act certain to become a tragedy.

> It will when these companies need to start competing on margin.

i see the future as supply side driven, not, as posited here, demand side driven. running your own has usually been a barrier to competing, to keeping your talent focused on product & development. we've had no general access to good, strong, competent, robust, well used alternatives for running software, versus using the cloud & it's array of easy to latch onto, well maintained, affordable, pay per use, easy to scale cloud service. we have been gaining that rapidly with Kubernetes, with open source & even proprietary, assistive Cloud Native Computing Foundation & other software. we're just starting to work together, to have known quantities we can put into place.

the option of trying to cut cost, avoid the colossal Hyperscaler surcharges has been out there. but it has absolutely, per the parent, been radically in favor of not running shit yourselves. i strongly agree, "for most devs, for most workloads, the cost of running a data center isn't worth it," because there's been few good understandable deployable patterns for running software. Kubernetes marks an early beginning where we emerge from this tar pit. nothing else has come close to providing a solid base for computing alike this. i'd seen some decent Rancher Fleets in action, which came semi-close, but like many of the possibilities from >5 years ago, it was esoteric, known to few, hard to skill up in, fraught with unknown perils, and few could help you. the situation has just started changing, we have just started finding common shared practices for computing, where skills & expertise are exchangeable across systems, where newcomers to your business have some chance of following along, understanding, on their own, with the out of the box tools. without having to deeply dive into the particulars that you have used to cobble together your systems.

cobbling shit together is how things have gone, & it's a long term nightmare, as easy as it is to start. we're finally becoming better. but i'd still say, for most entities, it's too soon.

[bryanrasmussen]

> then their career is only six years old.

So they definitely have the Senior Developer title and might even be the lead somewhere.

[noir_lord]

Pretty much.

I was a lead (or the equivalent since titles change) after 5 years way back in the day and I really shouldn't have been.

The thing is the job titles are pretty much meaningless as I've never worked two places that had similar criteria for what they considered junior, regular, senior, lead and in some places seniors are leads (if you only have 1 senior on a team of 8 they are a lead, if you have 6 seniors on a team of 8 and no lead then are they really senior and to who).

Other places promote on time served, so you are junior 2 years, regular dev for 2-3 years, senior after that.

It's one of the reasons when hiring I completely ignore their previous titles and look at what they actually did.

I've seen juniors who where at least equivalent to seniors in other places and "Seniors" who I wouldn't have hired as a junior.

My favourite title in my entire career (and it was my actual title) was "Code Monkey"[1], it got entered as a joke in the HR system and everything after that sort of followed on even my business cards (remember those?) said it (since company ordered them and did a mail merge from the HR system).

[1] https://www.youtube.com/watch?v=v4Wy7gRGgeA

[actually_a_dog]

> My favourite title in my entire career (and it was my actual title) was "Code Monkey"[1], it got entered as a joke in the HR system and everything after that sort of followed on even my business cards (remember those?) said it (since company ordered them and did a mail merge from the HR system).

One company I worked at let people use whatever title they wanted, as long as it was in good taste, and it didn't imply a level of authority you didn't have. I never actually took advantage of that, but I kind of wish I had, just for the sake of having some hilarious business cards.

[TeMPOraL]

I'm gonna guess the career-savvy people just went with no-joke "senior software engineer" or "principal software engineer", because the easiest way to be hired as a senior/principal and get the associated salary bump is to already have that job title on CV from your previous job.

[actually_a_dog]

Sorta kinda. Most people just went with some variation on "software engineer," but I don't think anybody really inflated their title beyond what the norm would have been for their experience level.

Now that I've read what @noir_lord wrote about how it's helped a bit career-wise, I may go back and revise my title to "Code Slinger" or something. After all, given the policy, it's not like they can really call me on it. ;)

[noir_lord]

It actually worked to my advantage career wise.

Partners would get a chuckle out of it, then remember me when anything dev related came up which let me make really useful contacts I otherwise wouldn't have made.

What is life for if not to be whimsical occasionally.

> Do not take life too seriously. You will never get out of it alive. (Hubbard)

[andylynch]

I knew a guy at Morgan Stanley who’s business card said ‘Tea Lady’

[bryanrasmussen]

When I was working for the Danish government on several standardization projects (basically writing schemas and attending meetings with interested parties to work out syntax) me and a couple other guys chose the title 'XML Architect' as sort of nose-thumbing at the IT architecture division (unfortunately there are stories and reasons there that should probably be kept unshared)