Hacker News Reader

Comment by dijit | Hacker News Reader

My sister-in-law (girlfriends brothers girlfriend, not that it matters) recently studied for a data analytics certification. Actually several.

The entire course (located on here: https://medieinstitutet.se) is based on Google Analytics.

Now her entire value is tied to the use of Google Analytics, she will almost certainly fight very hard to ensure that these skills remain relevant, nobody would want to retrain for 6-12mo on new analytics systems (or, god forbid, not be an analyst at all!).

I think we don't really assess the amount of lock-in we allow when we learn something that supposedly makes our lives simpler. Google Analytics was sold as a solution to you making your own analytics, because that's hard! and the cost is that google gets your information too- which most webmasters don't care about individually.

However now we're in a situation where at least a few thousand people depend on this precise tool existing, and will be economically useless if it is banned.

Personally I find this astonishingly foolish of the people who train exclusively on these tools instead of first principles and primitives.

That said; we also have "Cloud Engineer" as a job title, so I'm not sure we will learn this lesson.

View on HN

If the ability to work with the things taught in that course is so dependent on GA, then I dare question the term "data analytics" for that certification. Data analytics is a general area of expertise, that is not bound to GA. Perhaps the certification should be called "Google Analytics Certification", instead of implying more knowledge and skill than is actually there.

Data analytics has some statistics in it, these days probably a pinch of training ML models and using them and understanding them in the basics as well. Source: I did some work for a company specializing in creating courses for actually learning data analyst skills, as a preparation for switching careers towards data analyst jobs. I myself helped creating course content. The course is officially certified for job-seeking people as a means of learning a new job.

Exactly.

It's interesting to observe how the existence of a mediocre course in Sweden is leveraged to make the popularity of Google Analytics a major concern.

And maybe the course is not even that Google-dominated. Looking at the content here https://medieinstitutet.se/utbildningar/digital-analytics-di..., they use both Google Analytics and Adobe Analytics and mention other tools like Hotjar.

This level of dependence on certain tools is neither rare nor unprecedented.

Your run-of-the-mill business drone will be trained on Word/Excel/Outlook and be hard to impossible to retrain on anything else (either because of actual stupidity or resistance to change). This already starts at school where "Informatik" is often just learning where to click in Microsoft products.

Similarly, tradespeople often specialize in certain tools and products. Your average car repair guy will often be forced to specialize in one brand of car. Your home appliance guy will preferrably sell and repair one brand of washing machine, dryer, dishwasher.

'actual stupidity'... gotta love the general disdain of the 'run of the mill business drone'... It's funny my wife is a run of the mill business drone. She thinks IT is a bunch of assholes. I would say she is probably right. Way to keep things going.

and IT "assholes" think the run of the mill business drones are "assholes" as well. Their inability to be effective at their jobs tend to make IT lives worse because they can't understand what IT workers do but IT workers can understand what the basic run of the mill business drones do...and their work tends to be a bunch of pointless meetings.

Yeah, I work at a corporate office and have made it a mission to see what kind of work they do, and majority of the time...it's pointless meetings and meetings that involve pointing to IT workers and saying "do this". I check many of their daily schedules, and see what kind of stuff they talk about in meetings...just wow. Am I an "asshole"? Sure you can call me that, but I can call them useless in turn because I wonder how many more qualified people out there who can replace these workers.

> but IT workers can understand what the basic run of the mill business drones do...and their work tends to be a bunch of pointless meetings.

What an ironic comment.

Sorry, any early-career worker looking down their nose at anyone else (or pretending to have any idea what their job entails, especially because they “looked at a calendar”) might as well go back to middle school. They definitely need to grow up.

While true, it’s very fair to say that many (possibly most) meetings in a corporate environment contain a lot of absolutely pointless time wasting.

I say this with the perspective of someone who has slowly had to have many more of these meetings added to his calendar over the years.

Some are very important, some are reasonable but often bloated, but so many are a waste of time.

At the very least: they’re 5-10 mins of work spread over an hour. It’s occasionally maddening.

I find that a lot of engineers don't understand good communication, and definitely don't understand the value of relationships.

When I was really junior, I'd go to meetings and think that the vast majority of the time was wasted. As I became more senior, I realized that a lot of that wasted time is for providing context, relationship building, and alignment. You may not need those things for your current task, but your leadership and partner teams may need these things.

Yes, a lot of meetings could be emails, and a lot of meetings could be better run (agendas and objectives in the invite, action items assigned at the end), but unless you're working somewhere awful, most meetings probably have a reasonable purpose and aren't all filler. Lots of jobs require way more meetings, and probably aren't filled with context relevant to you.

Looking down on non-engineering positions is a personality trait I associate with inexperience. It's absolutely something I'd consider when denying a promo.

> When I was really junior, I'd go to meetings and think that the vast majority of the time was wasted. As I became more senior, I realized that a lot of that wasted time is for providing context, relationship building, and alignment. You may not need those things for your current task, but your leadership and partner teams may need these things.

100% agree. In early or IC roles, it's easy to think "just let me go do X" (or worse, "talking about X or Y is a waste of time when X is the obvious answer") without seeing the bigger picture that there's tremendous value in making sure other teams are aware of what X is, why it's important, and having a chance to weigh in or ask questions. Certainly there are valid complaints about some people's meetings, but those shouldn't overshadow the alignment/communication value meetings can have.

> I realized that a lot of that wasted time is for providing context, relationship building, and alignment.

A lot of that seems to be about office politics, which historically been something which engineers and office workers in general has disliked. It is a generally unhappy fact that relationship building and office alignments is what dictate who get promoted, who get raises, who get the desired assignments and who don't.

It might be true that those who refuse playing that game is associated with inexperience. In my experience, employees who get tired of it generally leave large companies, which leaves behind only inexperience employees or those who enjoy the game.

Looking down on, yes. Suffering nonsense meetings silently? No.

My entire point was that there is a major difference between the two & that while the instinct to look down on others for this organizational symptom is immature, it’s not unfounded or without basis to highlight the issue: they’re blaming the wrong thing however.

And I often find that in those types of meeting communication & relationship building is the absolute last thing that is happening. Most of these meetings are CYA, checklist, type meetings.

Meetings that literally only exist to allow someone to demonstrate they had a meeting about something.

Worse, the actual communication that is happening is usually in side channels.

I'm guessing you're junior, or you'd have more control over these meetings, or have the ability to decline ones that you believed weren't going to be good use of your time.

Having good meeting culture requires everyone involved to improve it. If you want meetings to be better, set them up, add an agenda and objectives, and run the meeting so that it's effective. If you can't run the meeting, if it doesn't have an agenda or objectives, ask the person who created it for them. Ask for action items at the end of the meeting, if no one is calling for them. If it's mostly status meetings, propose a better process to track and communicate status.

If you're working through side channels, you're part of the problem.

Calling people assholes, rather than improving the situation, is an indicator of inexperience.

This is the most wrong, yet condescending and naive, comment I’ve encountered on HN so far.

I’m actually impressed.

Call me in 20 years, maybe you’ll have learned something.

Getting real "toxic positivity" vibes off your whole line of arguments...

Being proactive in changing the situation isn't toxic positivity, and being empathetic with folks in different jobs isn't toxic positivity either.

Assuming people are assholes, and blaming them for situations is just run of the mill toxic. Working through side-channels rather than addressing a problem is also run of the mill toxic.

Nah your stuff came across as blind tolerance which is just pointless unconstructive and solely to placate people's feelings (in such instances unjustifiable/irrational).

Just because Joe or Judy "feels" a certain way doesn't mean it should actually have bearing on anything. Really...

Enough placating those with the least logic and self control.

This attitude is the kind of engineer stereotype we can live without.

People's feeling matter in the long term, because it's the difference between them wanting to work with you, and them being forced to work with you. If I had to pick between a genius coder with awful people skills, and an average coder with exceptional skills, I'd essentially always pick the average one.

Someone's feeling do matter in the long term, which is where it should be dealt with, not in the immediate.

Do you not see the difference?

People's feelings about you are based on a series of accumulated interactions. You can't just "deal with it" later, because that's now how people work. This isn't like tech debt where you can accumulate some and then spend some timing working it down later. If you're consistently an asshole to people, it doesn't matter if you take a little time now and then to try to repair that. Good relationships require taking people's feelings into account and acting consistently.

The context of the discussion was accommodating feeling during meetings, right?

Well that's absolutely not the place for it.

If your little fee fees get hurt you keep it to yourself and focus on the task at hand. Then after the task is complete you either pull the offender aside to address the problem or you bring it to a superior to be addressed. It in no way should have any bearing on the work at hand.

This is basics of work place decorum, right?

> and IT "assholes" think the run of the mill business drones are "assholes" as well. Their inability to be effective at their jobs tend to make IT lives worse because they can't understand what IT workers

Have you ever dealt with an average IT department in a non-tech company? This attitude doesn't help anyone and I really want to believe that only a small minority of tech people think of any other worker anywhere as an "asshole".

I'm a Sr. SE at a large medical device company and can confirm that our IT dept is filled with assholes. We do everything we can to keep systems out of their hands because they are so difficult to work with compared to every other part of the company.

I get they have to deal with a bunch of technical inepts constantly falling for phishing attacks and occasionally teams will make outrageous requests to them that simply can't be done, but their attitude is terrible.

If you ask for something simple but "scary", like a firewall or internal network change, they will immediately assume you are just some idiot and speak dismissively to you in a very obvious manner. It's extremely frustrating because they won't even bother to read your emails that justify the change and will just invent some unrelated excuses about why they can't or say they will get back to you later (they don't).

Ironically the only way to get anything done through them is to have my team members create a bunch of duplicate tickets (1 per person), and schedule multiple pointless meetings with them that essentially just consist of me reading my emails to them out loud.

Non-technical teams in the company get the same treatment but lack the technical background to counter them. Frequently I've had team leaders come to me to get a second opinions on the stuff IT tells them and it bothers me how much they seem to clearly exaggerate the difficulty of things. To the point where I can't help but wonder if they are just pretending to know what they are doing, and use their better-than-you attitude to mask their own ineptitude.

So overall I feel the negative reputation of IT departments is earned.

> and it bothers me how much they seem to clearly exaggerate the difficulty of things.

Scotty Engineering principle at work. I'm no stranger to that, it's often enough the only strategy keeping higher management from completely swamping you with work.

It's not that it usually is the Scotty Engineering principle. It is more often a hedge against unforeseen complications, because if you give a realistic estimate that would be true for 90% of the tickets, the 10% will come to bite you. So to not get chewed up for providing realistic 90%-true estimates, you give 99.9%-true estimates that are far higher, but with just a .1% chance of being screwed instead of a 10% chance. Which is, at 10 tickets per day, getting chewed up daily vs. once every two weeks or so.

reminds me of the saying "don't tax you, don't tax me, tax that guy behind the tree".

Its always us vs them.

I someone can't be retrained, and it's not because they're being stubborn, what other reason do you have?

Is it better or worse to assume they're being a problem on purpose?

I won't say 'average' but I will say 'common enough to make changing software a huge issue'.

https://news.ycombinator.com/item?id=36601986

Many devs are the same, hence loyalty to a language

Unless its Webdev, because from the outside looking in it seems there’s some new fad moving through every few months.

Who's the a-hole:

The person trying to make things better and seeks out knowledge at great cost

The person who is willfully ignorant and actively refuses knowledge handed on a platter?

Because one of those is the typical IT pro and the other is the worker drone....

Don’t worry, the people in IT don’t like the other people in IT. Devs think that security are a bunch of a-holes, DBAs hate the devs, etc etc.

lol

Seriously, some looking down the nose comments

> Your average car repair guy will often be forced to specialize in one brand of car.

Not because of skill issues, but maybe forced because they work for a dealership that sells a particular make exclusively or, less often, a specialty shop; most “car repair guys” outside of those environments have to be generalists.

> Your home appliance guy will preferrably sell and repair one brand of washing machine, dryer, dishwasher.

IME, the sales are done by shops that carry many brands, and delivery, installation, repair donw by firms that often have relations with the retailers and handle whatever you get from them, including multiple unita of different brands that come together with the same team. They may also have relations with the manufacturers, but those don’t seem usually to be exclusive.

> Not because of skill issues, but maybe forced because they work for a dealership that sells a particular make exclusively or, less often, a specialty shop; most “car repair guys” outside of those environments have to be generalists.

Yes, I'd expect any car guy to be able to change your tires. Or change your oil. But even resetting the oil-change alarm or tire-pressure sensor can be a hurdle here:

Manufacturers also use skill issues to their advantage to bind tradespeople. Modern cars do need manufacturer-specific diagnostic devices that used to be unobtainable for independent shops. Since that practice has been largely forbidden by the authorities, now the software, cabling, and diagnostic output are made intentionally hard to understand without having taken the corresponding lessons that the manufacturer provides for a modest fee.

Perhaps you're using a broad/generic example to try and make the point but I'll say this:

If a seasoned mechanic is unable to figure out how to reset the Maintenance Reminder or look up how to sync Tire Pressure sensors, run away.

In the same way that one can use knowledge of one programming language as a means to leapfrog into other languages, other skilled trades are similar. Perhaps there's something that could be said about an ICE mechanic trying to dabble on Electric but that's not the point you're making. So yeah. I know you're trying to make a point about lock in, but when I think of people I want to hire for tasks who might say "Oh, sorry, you have a Volkswagen and I only know how to work on GMC" I wouldn't take my GMC to them either. It shows a fundamental lack of skill in that they don't understand the broader concepts and their universal applications. If I, a programmer, can figure out my Volkswagen, my GMC, my Mazda, my Nissan, certainly a mechanic can. If my appliance repair specialist can only do Whirlpool when I ask for help on a Bosch that's red flags.

One might specialize. Sure. But to refuse? Weird. But I fear I might be getting lost in the weeds here because its all about the approach. "Sorry, too busy to take on work on things that aren't my specialty": yep, understood. "Sorry, I don't know <model> I only know <other model>" bad.

I know mechanics in particular can be quite chauvinistic.

In the US, for a very long time, you had to find an "import specialist" mechanic, even long past the point where Japanese brands had gone mainstream. Part of this might have been because of the availability of metric tools at the time; my family had a set of metric wrenches specifically because they had to do occasional light maintenance on their early Datsuns and Toyotas.

I can recall that the mechanic in my neighbourhood was decidedly unwilling to service a new Hyundai in the late '90s. He complained they were 'disposable'.

Mechanics are in business to be profitable.

Specialized items require specialized tools. Specialized tools, like all other tools, require maintenance and they change.

A shop dealing with domestic produced automobiles can significantly reduce profit-bleed by not servicing vehicles that require special tools, special diagnostics, special machines, etc.

It's simply a math equation. Do I serve enough of these vehicles daily/quarterly/yearly to make these expenditures profitable for me? The shops you're referring to answered no to that question.

Try to get a French car in Poland, most shops are used to deal with VW, Audi.

It is not impossible but if you try to go to a random shop you found on Google and fix your Citroen or Renault you might be surprised.

It could just be a parts issue. A lot of mechanics will work on pretty much any car, if they have the parts, but if it's not a popular model then they don't want it sitting in their shop for a week while they order parts.

I guess some mechanics will prefer to work with a smaller number of models, because they're much faster if they're familiar with the model, but new models come out every year, and they need to learn how to fix those. If a mechanic can learn to fix the newest VW, they can learn to fix the newest Renault, it just might not be worth their time if they have enough work to do.

I'm not from Poland but I hope this is hyperbolic. Parts delivery is once or twice a day delivery in most cities in Europe, no matter if it is Renault, VW or a Kawasaki motorcycle. Of course a part can have longer delivery time but not because it is a Renault instead of a Audi. At least not at any reputable delivery business in modern parts of Europe (which I would think Poland is a part of even though I haven't been there since the 90's).

So that is circling back to original topic.

I believe person learning GA could learn any other analytics tool. It is just not worth their time.

That's often certain German cars in the US. IE some shops will just not work on modern Minis. Plenty of shops will avoid weird, niche cars.

Any mechanic can fix a Citroen, but is it worth the floor time it'd take to get the parts and figure out french quirks vs working on something they know that they'd make the same money in a third the time.

Having done shade tree work on various cars, I'd totally turn down any Subaru engine bay work if I was already close to swamped.

Once upon a time I was the proud owner of a third gen RX7, proud that is until the powertrain warranty ended and I had to go outside the dealership network for minor repairs. Basically your options were... go back to the dealership and pay unsubsidized warranty rates (double or triple what independent mechanic charged for "normal" engine work), or go to questionable looking characters running "performance" shops who wanted to side port everything they could get on a lift. And still pay double or triple the normal mechanic rate.

I think you are missing at least one important point. The reason the mechanic can’t work on the other brand of car is not knowledge or skill, but equipment. It costs money to buy the full suite of equipment required to correctly service a particular manufacturer’s vehicles. It often makes much more sense to specialize and make more use of fewer expensive tools than to have tools for everything and have only marginally more business.

Well, that's a very American way of doing things that most places simply don't do. The norm is for tools to be compatible with all brands and at best it is an added option to unlock or a pay per use. You can do 99% of the diagnostics with a Wish Bluetooth dongle and a free android app if you wish, since by law it is an open standard.

Most specialty equipment costs less than a mechanic can earn in a day. You even order the parts from the same company no matter if the bumper is for a Mazda, VW, or an Alfa. Or a Kawasaki motorcycle for that matter. This lock-in behavior is, luckily, mostly illegal.

Diagnostics yes, but try to reset the warning light on a German car after fixing the fault. This can apply even when replacing seemingly purely mechanical parts (I think some suspension parts on bmw/Mercedes). You will need vag-com for any vw/Audi and something else proprietary for Mercedes or bmw

I have only done so on a Seat, with no trouble. Seems to me that if this is true it is against EU law.

There’s actually a far better reason they don’t retrain. There aren’t better tools. Or the tools are basically carbon copies (Google Docs and Sheets).

Show me a product that provides so much more value for my team than Excel that it would be worth a retrain.

My first office software was WordPerfect and Lotus 1-2-3 on DOS. Then Lotus Smartsuite, Microsoft Office, OpenOffice, now LibreOffice, with occasional bits of Google Docs. I never had to be retrained.

Here's the thing, for 90% of use cases, those are all effectively equivalent. You really shouldn't need any retraining whatsoever. A spreadsheet's a spreadsheet, and a word processor is a word processor. You type the text in the box and then hit print or whatever. Nothing new to learn.

Now admittedly, there are some power user features which are different, which is why I said they're only 90% equivalent. But most people don't use those anyway. Yet they will intensely oppose using a different but 90% equivalent thing because they haven't spent years being trained to use it - even though it's almost exactly the same thing they're using.

It's just a weird and bizarre mental hangup that seems to be natural to many humans.

If you're in tech, you will see the same thing with programming languages, frameworks, applications, etc. And it's on both sides, not just the users, but also the people hiring them too. "Oh, you've only worked with WordPress, you haven't been trained in Drupal?" "Oh, that's PHP, I only work in Python." "Well we're looking for a Ruby developer, not a C# developer." "That's React, I only know Vue.js"

It's mostly all general-purpose programming languages, libraries, and frameworks. Sure some details are different. There's a bit of a learning curve. But if you are actually capable with one, then picking up another nearly equivalent alternative should not be viewed as some impossibly complex thing that will take years of retraining.

You are both right and wrong. It depends on the intelligence of the person you are dealing with.

There is a thing called "intelligence". There are several definitions of it, the one I'd like to use here is "the ability to infer general principles and common workings from small isolated samples and apply those principles and workings".

So if you are sufficiently intelligent, you can infer, from observing a few (or even one) doorhandle being pushed, that his is the general way to open doors. You can then apply this principle maybe even to different doors, windows, rotating knobs, etc. The fewer samples you need to learn and the broader your application range after learning, the more intelligent you are. In the stupidest case, one only learns to open one specific kind of door in one specific way, like a cat might.

You are writing from the point of view of someone sufficiently intelligent to derive the working principles of software and apply it to other software packages that generally serve the same purpose. However, there are people who are not intelligent enough to do that. Those people do get by by just following instructions, learning by rote which buttons to click for which purpose. Those people are the "door opening cats" of the office application world.

Less intelligent people like those do exist (50% do have an IQ<100 after all...), they do get jobs and they can be successful within limits. Just as Stackoverflow/ChatGPT-copy&paste-programmers do get by somehow.

Which is why I'm also a fan of intelligence-test-type job application processes. The ability to learn, for higher-level jobs, is far more important than preexisting knowledge. And intelligence is the best known predictor for the ability to learn.

Mathcad is the only thing that comes to mind. It is very unique and a massive productivity boost for engineering calcs.

> There aren’t better tools. Or the tools are basically carbon copies

LibreOffice, free open source software. Just as good as Excel and... free.

LibreOffice is a perfectly functional spreadsheet for basic spreadsheet tasks. It is, however, not in the same league as Excel for more advanced spreadsheet tasks. Sometimes as a user you just want to be able to use the software that works better, you know?

Yeah, that is the trade-off; if you keep using the proietary software that you're familiar with, you don't have to relearn, but you'll be more dependent on 1 company. But if you spend some time up-front into learning a free software alternative, you won't be dependent on a single company.

But yeah, for some things there are not yet complete free software alternatives, but the gap is really getting small these days. I think for most common use cases for most people, LibreOffice is more than enough. If you need more advanced features that are only available in the propietary variant, try to find ways to not be dependent on that feature, or find an alternative way to do it with free software. If you are creative, there are usually many ways how you can do your work using free software.

But yeah it does take some dedication to this idea. But what you get back is probably, on the long run, gonna be of more benefit to you for the future than if you would invest it in learning the propietary software. Unless you really have a special love for the propietary software company, and you are sure you want to grow more and more into their ecosystem and have no need to have any personal freedom over the software you use.

Yeah, but for retraining to be worth it then in the future your people have to be better or more productive than they would be with Excel and it'll also impact every new hire you make that needs to do the same retraining. Just as good is not good enough. That the tool is free is rarely a strong enough reason especially if there are licenses around already.

Home appliance repair is not a specialized job. Maybe you have some sort of memory about the Maytag repair man, but that is just branding, just like DeBeers with their diamond monopoly.

Home appliance repair is knowing the general layout of each major appliance, a bit of specialized knowledge on how to dismantle them without braking them, and which modules are responsible for which function, and finally knowing how to source the replacement parts and knowing which common items are best kept on hand for convenience.

Very few people are doing board level repair for appliances, especially when the replacemeent boards are typically very inexpensive for any modern machine (save for main boards and for induction plates in induction stoves, which are typically so expensive that it is smarter to replace the entire appliance rather than repair the broken module).

> Your run-of-the-mill business drone will be trained on Word/Excel/Outlook and be hard to impossible to retrain on anything else (either because of actual stupidity or resistance to change).

Change purely for the sake of change is bad and people are right to resist it.

The vast majority of businesses have no compelling reason to switch off Microsoft Office. Would the world be a better place if there were more feasible options? Maybe. But that's not the concern of either a random business or its employees.

I'm old enough to remember when every young self-taught sysadmin was getting their MCSE or A+ certs.

> That said; we also have "Cloud Engineer" as a job title, so I'm not sure we will learn this lesson.

Comparing something as vast and broadly reaching as "Cloud" is a disengenous comparison to something as specific as a tool like Google Analytics, kind of a wierd comparison IMO. The entire pattern of tech is towards the "cloud" - even if you refuse to use the big ones like Amazon, Microsoft, or Google, it's still technically "cloud" if it's managed servers (wherever they may be).

To be honest I never got into the hype behind Google Analytics and I'm glad that I never spent more than 5 minutes at a time dropping the occasional tag on sites I built. (I've also never worked for anyone big enough where the analytics ultimately proved useful or valuable anyway). These tags are now easy to remove by deleting a few lines of code. I really wonder if the larger orgs really should have spent the extra few hours / weeks of development to develop an in house solution all along...

> Comparing something as vast and broadly reaching as "Cloud" is a disengenous comparison to something as specific as a tool like Google Analytics

Is it? Tons of cloud people I know are very narrowly specialized and certified on AWS or Azure. They certainly don't ever apply for jobs using the other...

I'm sure they could retrain. But I'm also sure they don't want to.

At this point, being a "cloud" engineer essentially means that you're good at understanding and adapting to new services / value propositions, since they become available quite regularly. It doesn't mean, "really good at EC2, and incapable of learning more."

If I were reviewing resumes and saw someone list themselves as a "cloud engineer", I would make very sure their skills listed the cloud provider used where I was hiring. That title would make me assume they were a specialist in a cloud until I saw otherwise.

You know that the big clouds (and to a lesser extent the smaller ones) have more in common than they are different?

They use different jargon, they love to market themselves on their differences (because why compete on price?), but the fundamentals are really very similar and the skills transfer.

Anyone who’s telling you that Cloud X is vastly different from Cloud Y is either trying to sell you something, or has gotten their knowledge from someone who was selling them something.

That says more about you than them, though. You’re projecting your own inability to translate knowledge into new systems and assume the same of others.

I'm not projecting my inability, I'm assuming incompetence. I'm a cynic, not insecure.

I wouldn't blanket block a resume that said "cloud engineer", I'd just make sure to probe that they aren't just an "AWS engineer" or "Azure engineer".

That is entirely reasonable.

A title I have frequently worked under is “Cloud Engineer”.

I’m strongest in AWS, secondly Azure. But I also am extensively using Linode’s platform and Kubernetes too.

My best friend’s title has also been “Cloud Engineer” and he is exclusively in AWS. He doesn’t really know more about Azure than he needs to get things connected to AAD.

How anyone could know that without asking eludes me. If you’re hiring for a position, you have a responsibility to know.

I work at AWS Professional Services, people move around among AWS ProServe, Google/GCP, and Microsoft/Azure all of the time.

Heck plenty of people come into ProServe with no AWS experience. But they know their areas of specialty well and it only takes a couple of months to use AWS specific services.

> it's still technically "cloud" if it's managed servers (wherever they may be).

Thank you for this. No more second thoughts about pointing cloud.example.com at our local HPE rack.

You can learn the most generic course out there and still turn out clueless, you can also learn the most specific tool and come out and be able to generalize. As far as I can tell this depends entirely on the individuals ability to be resourceful. In that respect a GA specific course might help them Get their first job faster so maybe that’s not a bad thing at all.

If you already have the background to understand computation and software, you're: a) not one of the people at risk of making this bad decision or getting stuck there; b) already in possession of much more valuable skills than knowing some software suite.

Getting this background requires a non trivial amount of time. It's easy to take our ability to generalize different computer based tools when you already understand digital computer architecture and know a few programming languages. The vast majority of people do not start from such a broad base of knowledge when choosing some software tool to learn.

> Now her entire value is tied to the use of Google Analytics, she will almost certainly fight very hard to ensure that these skills remain relevant

Or this could be the right time to check one of the self hosted alternatives (Matomo, Snowplow, etc), apply what she learned about Google Analytics, learn how to do it on those systems and sell her skills on two different classes of customers: the ones that will keep using Google Analytics, the ones that will try alternatives, at least not to be fined if not out of genuine compliance with the local laws.

As someone whose total compensation went up 600% over 5 years as a 'cloud engineer' from a sysadmin background, I think your comment is kinda silly.

Those skills are very transferable to new products and very little of the worth I bring is from my certs

Sysadmin background is akin to first principles when it comes to Cloud.

I also have a sysadmin background and my journey to the cloud has been "I can learn new things that make things easier or just use some pretty standard Linux VMs at any time".

Most new entrants to cloud learn the following:

* an object storage system (GCS, S3)

* A functions as a Service system (Cloud functions, Lambda) -- if you are lucky, Cloud Run; since that also gives you Docker.

* Message systems (Pub/Sub, SQS)

* Maybe an orchestrator (GKE, ECS), but only surface level.

* Some very minor information on how to create and access VMs; but it's clumsy, since you have to also learn Linux, this is unused.

For me, I can always fall back to my foundational knowledge of DNS, Networking, Linux and the systems I used to run, like databases, app services, mail systems, queue systems etc;

For people who are trained only on FaaS and SQS they do not have foundational knowledge to fall back on. That's not to say they can't get it, but it's not helping them make money and it's usually not taught, and worse: it's not something you ever reach for- and people typically learn through failure or by doing.

For me: Cloud just makes my life easier.

But I can also use an iPad as a consumption device; if I was only ever given iPads I would not be able to write C++ or Perl. That's just the nature of exclusively using simplified tools and abstractions.

What you are describing is a "developer doing devops" arrangement, or maybe some junior guy with an associate-level certification. A well paid Cloud Engineer is 100% expected to know architecture, Linux, networking and all the things you mention.

there are engineers who specialise on systems that have been in industry long enough to be called senior that have never touched anything non-cloud.

Most people who are “devops” with <8 YoE are unlikely to have touched non-cloud systems. Worse still, whether you want to admit it or not: some people are "DevOps" with no prior developer or sysadmin experience. (Since the term "Systems Administrator" is out of vogue but the need for systems administrators has never gone away.)

There are so many bootcamps for this too, and they mainly focus on AWS skills.

Here's a few bootcamps that people might decide to take to break into "DevOps" of which none are assuming prior knowledge, though techworld with Nana does teach a little Linux.

https://www.techworld-with-nana.com/devops-bootcamp

https://clarusway.com/aws-devops/

https://www.udemy.com/course/aws-devops-bootcamp/

https://techproeducation.com/courses/aws-devops-engineering/

https://aws.amazon.com/training/classroom/devops-engineering...

I know where you're coming from but the reality is that a lot of those things are increasingly less relevant. I'm not sure what real advantage I get today from having done racking and cabling of physical servers back in the day. In a managed Kubernetes world, I haven't leveraged my ability to run a massive pool of Linux servers in a long time (I kind of miss that btw). For all intents and purposes you can be a great DevOps / Cloud Engineer / SRE or whatever you want to call it without ever seeing a non-cloud system.

I think we're in agreement which is the entire point of the thread we're in.

You don't need certain skills today; instead you can use higher order systems instead. That doesn't mean there's no value in understanding (to use a programmer example) a linked list.

Equally knowing how a queue system works from the OS to bytes on a wire can make a world of difference in some contexts.

You can live in the higher order world and use the tools that make life simple (google analytics, in the case of this thread) but you are jailed to not understanding the systems that they are made from and while you are exposed to some concepts not everything transfers cleanly. "What is the PostgreSQL equivalent of a ML.PREDICT in Google Spanner!".

To give another contrived example; a huge reason people learn Latin or complete computer science courses is not because they will be speaking Latin or using Comp Sci concepts; it is because it sets a foundation for learning other systems, a sort of proto-field that permits you to see the relationship building blocks on which other systems exist.

This is terrifying.

> will be economically useless if it is banned.

Economically set back, maybe. "Useless" (with its implication of permanence) is way OTT.

How many can afford to spend 6 months re-training, and even worse: how many companies are willing to hire people who have no experience in their specific tool.

I don't think it's permanent, but it does make them economically useless until such a time as they retrain.

You are stretching credibility when you talk about 6 months to retrain from GA to some other analytics tool. 1-2 weeks is much more realistic timeline considering standard industry terms and similarity between tools.

if it was a 1year bootcamp, then I think saying 6mo is.. "fine".

Consider transitioning from Excel to LibreOffice or Google Sheets. On the surface it's the same, but doing advanced things requires considerable time investment and is very uncomfortable.

>Consider transitioning from Excel to LibreOffice or Google Sheets. On the surface it's the same, but doing advanced things requires considerable time investment and is very uncomfortable.

Silly hypothetical. I can't imagine a scenario where a company heavily utilizes advanced Excel, and then decides they want to use Google Sheets instead.

Besides, we're programmers, and learning new tools all the time. Things are deemed obsolete regularly.

> I can't imagine a scenario where a company heavily utilizes advanced Excel, and then decides they want to use Google Sheets instead.

I can't imagine a company that has built it's foundations on AWS migrating off of AWS. Such an endeavour would be more painful than transitioning spreadsheet tool by at least multiple orders of magnitude on basically every metric you can come up with.

That's also a broad definition of programmer. Most people (even programmers) come in a few categories:

1) People just solving a problem, tinkerers and explorers, people who are not really programmers first but it solves a need to get further work done.

2) People who just want a job that pays; lots of these, bootcamp folks mostly though I don't mean to make it sound negative -- nothing wrong with people that just want a decent paying job.

3) People who learned enough skills as teenagers to be well paid and are coasting or specialising in that area. I know lots of people like this, I believe on some level that even I am like this, though generally curious I tend to mainly focus on my area and only expand slighty around it and slowly. If you swapped out Linux for VAX I would be terribly displeased. See also: SystemD

4) People who love to learn about computers and how they work. This is probably the rarest person, and I was this person in my teenage years. It doesn't matter to this kind of person the economic viability of a project: the only thing that matters is that they do something. This is the people who make GameBoy Colour games in 2023. Or the people writing console emulators or doing DemoScene.

The majority of people don't keep learning, they learn their area and improve upon it.

I firmly believe that an AWS Cloud Engineer (or AWS programmer) would strongly prefer to move to another AWS shop.

> If you swapped out Linux for VAX I would be terribly displeased.

Having used both I’d say that the differences between Unix and VMS are much greater than the differences between Excel and Google Sheets.

A better comparison might be between Linux and BSD.

A company that relies on VBA scripts

If Google analytics was banned companies would have no choice but to hire and retrain people.

There's a saying: You'll never get rich harvesting in someone else's garden. It's not just Google Analytics, all Google products can be killed off at Google's whim any time, and it's not just google. That's why it's so important to work with tools you could own.

What if you don't want to get rich and just want to work enough to be comfortable and then come home and do other things besides tending a garden? In that case pay me to tend your garden so I can ignore it when I am not on the clock.

So are you suggesting that the standard company that uses 39 different SaaS products (https://financesonline.com/saas-software-statistics/) should give up all the products that meet their needs and only use free software?

This is a strawman: I didn't say a word about free software.

Or be ready to move to a new garden.

Off the grid Homesteaders aren't more profitable than people who engage in the compromise of society.

Wow, job for people who only knew google analytics exist? I thought at minimum SQL is required, and today's analysts also need to know python/pandas at minimum.

Imagine being a 'frontend developer' who can only use squarespace.

> Imagine being a 'frontend developer' who can only use squarespace.

More likely: Imagine being a 'frontend developer' who can only use React.

It's sad because it's a reality for many

Seems horribly limiting regardless of how we slice it.

IDK, I used to worked with "Drupal consultants" who barely knew PHP. They delivered the sites they were asked to, usually on time and within budget.

Drupal was the only accessible door to me to this entire industry in 2010, with no CS knowledge or available mentors. I was one of those people and I barely fed my family, and I eventually learned PHP, JS, the hosting stack, automating the hosting stack, Varnish and HAProxy, Linux sysadmin, how the internet works, and a decade of topics since.

We all need a door into this stuff, a place to be dropped in to start putting it together. Maybe the OP’s sister in law is totally out of luck, or maybe she’s now got a few of the hundreds of tools she’s going to need to build out a career. Luckily she has a brother in law in the industry, hopefully he’s the helpful type.

And they could migrate to WordPress if all theirs customers had to migrate.

There are people who are trained and know mainly Wordpress, so not a surprise. However, if they can transition to a second product, they will be able to generalize to a n-th as well.

When I got my AWS certification it didn't promise any applicability to Azure or GCP. But I brought skills, and took knowledge away, that would apply. Some of this is just on the practitioner.

> That said; we also have "Cloud Engineer" as a job title, so I'm not sure we will learn this lesson.

As long as you don't depend too much on highly vendor-specific stuff, most of the stuff a "cloud engineer" uses day-to-day is just the same fundamentally - EC2/Azure VM/GCE, ECS/Azure Container Apps/Cloud Run, Security Group/Azure Network Security Group/Google Firewall, whatever. Different names, same or very similar stuff.

I can tell you thats not the case…

I’m curious what you’re working with that is significantly different from one CSP to the next. I put most of my effort into AWS, but when I get staffed on a Google Cloud project, there isn’t much that I can’t figure out pretty quickly, especially with IaC managing everything. As long as the CSP has good docs, I find it relatively easy to move from one to the next.

There are certainly some cases where that breaks down, but it’s usually in specialized areas that I’d have to do some upskilling on in my preferred cloud anyway.

The benefit of the cloud is its service and resource (i.e. building block) oriented nature. There’s a level of transparency to cloud-based services that just didn’t really exist before.

> I’m curious what you’re working with that is significantly different from one CSP to the next.

I work here:

https://aws.amazon.com/professional-services/

There is a lot more to any of the cloud providers than just VMs and networking. I haven’t done anything hardly with a raw EC2 instance in 5 years except for one or two deployment pipelines. AWS alone has 130 services. True many of them are hosted versions of open source products

I work with call centers (Connect), Athena (Apache Presto), Step functions, and I have done some IOT work and of course Lambda and a lot more. I don’t do anything with traditional VMs. My specialty is “application modernization” meaning my work is a combination of DevOps and traditional application development using AWS services.

There are all kinds of specialties within any of the major cloud providers.

> I work with call centers (Connect), Athena (Apache Presto), Step functions, and I have done some IOT work and of course Lambda and a lot more.

Well, Lambda has a multitude of competitors (although to my knowledge they are only competing on the principle of serverless computing, so you'll still have to re-write scripts using these), and same for IoT integration.

The rest I'd say is pretty exotic stuff... and thanks for mentioning AWS Connect, that looks like something I'll have a deeper look into - do I get it correct that this is something like a combination of JIRA Service Desk/OTRS, some form of SIP telephony service plus a webchat and AI assistant?

It was originally the call center software that Amazon Retail used. It was ported to become an AWS service. For text to speech it uses Lex - the AWS version of Alexa. For other integrations you have it call a Lambda.

It’s the standard type of software you use when calling into a call center with a mixture of automated help and operators.

Like I said above, if you know your specialty well, it’s not hard to map your expertise to AWS services. It took me two years from never opening the AWS console but having literally decades of software development/architecture experience to working at AWS in consulting. I worked at a 60 person startup before.

I’m more challenging the notion that all any of the cloud providers offer is a bunch of VMs and the surrounding networking infrastructure.

> I’m more challenging the notion that all any of the cloud providers offer is a bunch of VMs and the surrounding networking infrastructure.

Granted, I'm biased because I work at a development-focused shop so my experience is the development/infra side of AWS and Azure as well as a healthy load of legacy on-prem servers (I leave my fingers off of GCP though, heard too many horror stories). We follow KISS - so just from a quick grep through our Terraform files it's almost all EC2, S3, Cloudfront, ELB, ACM, RDS, EFS, Beanstalk, ECS and EKS plus Cloudwatch for logging/monitoring, well wrapped in modules. That's stuff one can find pretty much everywhere, especially as most of our workloads are shifting to EKS.

The things you use are IMHO more targeted for specialist use cases, and I can clearly see the value-add... I'd pay good money to never have to see JIRA again in my life.

For practical things it's hard to teach in the abstract - you have to do - and doing means choosing some sort of toolchain - typically the most popular is a frequent choice.

As an example imagine learning programming - without some real world practice. And if you do some real world practice you have to choose which tool to use.

I take your broader point - but I think it's inevitable that most courses of this type are based around a particular tool chain.

Most Data Science courses use Python for example.

Choosing a tool doesn't mean locking yourself into it forever and refusing to ever use anything else though.

Well before I even started my first development job, I had used BASIC, Turbo Pascal, Assembler, C, Euphoria, Java, C++, Javascript, and Visual Basic.

My first dev job didn't use any of those, however. I had to ramp up on PHP, SQL, Perl, Python, and a little Ruby. Took two weeks to become productive, albeit not a master.

Over the years since then, I've used a wide variety of other tools (languages, frameworks, compilers, editors and IDEs, etc.) I can't imagine where I would be if I still insisted on using BASIC and writing code like

10 PRINT "Hello!"

20 GOTO 10

In the end, they're all just tools to do the job. You don't refuse to use a screwdriver just because you learned to use a hammer first.

I see your point to a certain...eh point. During my studies we also had our ERP course accompanied with some specific tasks on one tool (don't ask me for the name now, its been some time). BUT it was accompanied only, we usually had the concepts presented beforehand. If you want to go a step further...show an alternative from time to time.

But I don't agree with the python comparison. Python is only a language and even Numpy/Pandas still need you to know the concepts and knowledge attained using them are definitely transferable.

It comes down to the course - a course that just teaches a cargo cult like set of steps is a bad course, one that involves a proper discussion of the fundamentals is a good one.

All I'm saying, the fact that a course uses a particular tool chain isn't the determinant factor to whether a course is good or not.

>It comes down to the course - a course that just teaches a cargo cult like set of steps is a bad course, one that involves a proper discussion of the fundamentals is a good one.

totally agree here

>All I'm saying, the fact that a course uses a particular tool chain isn't the determinant factor to whether a course is good or not.

I totally agree! My comment was related to the commented mentioned that the whole 6 month training is worthless if GA get's blocked

I guess we aren't that far apart :)

Naively I would assume that the purpose of a data analyst is about presenting the relevant information to a company. How that data is collected, stored, processed and indexed is the role of system administrators, web developers and database designers.

It seems very inappropriate to allow a data collecting tool to dictate what information is relevant for a specific company.

Once upon a time I might have agreed with this take, but having years worth of battle scars on me now - the interface that any company’s data presents about its operations is entirely coupled to the implementation of how it’s collected and the assumptions with which the system generating it is built. This is a good thing, because there is very little new under the sun, especially in business.

However, most young businesses will waste tons of time and money reinventing the wheel of these systems and trying to customize them to their business’ unique needs, but the much more effective path is to really (re)think through your business process and figure out how to align it with the grain of the tool instead. This option is only obvious to those with experience in failing to execute on the former option, unfortunately.

To your point, an effective analyst doesn’t just present data, they have to understand the entire world around that data - tooling, people, processes.

Not really important to the rest of your comment, BUT — Sister-in-law means they have to be a “sister in the law”, a girlfriend has no legal basis in fact.

All that said, there are other analytics systems out there mixpanel, amplitude, roll your own, etc. they might not be quite as full-featured but 95% if the value comes from a few features everyone has

> Personally I find this astonishingly foolish of the people who train exclusively on these tools instead of first principles and primitives.

The argument for Universities right here.

I always find the opinion that Universities should make students job ready to be naive, even if well intentioned. There's a place for certifications that focus on job readiness, and there needs to remain a place that focuses on first principles and primitives.

I went to University about a decade into my career as a programmer to fill in the pot holes and absorb the first principles and primitives. I advocate that route every time I can. It's great if people can get a certification and start working with GA right away, and they have a place to level up their career with the money they make if they want to.

Many people depend on YouTube or Instagram to make money. If YouTube and Instagram bans them - and it happens - they lose the ability to make money.

Then they will learn an important lesson.

Don't specialize in something that you are good at?

What is the lesson here?

The business lesson is if you are entirely dependent on somebody else you are not in a good position. Especially if your interests aren't aligned.

When people are banned, it's the platform deciding the reputational risk of association isn't worth the money you bring in. Given reputation impacts can be huge - it's hard to see how you'd ever be the right side of that equation.

Even worse, the platform may decide it's not even economic to make sure each banning is fair....

Ultimately I suspect the only way to rebalance the balance of power is to use collective power.

So having large number of friends on the platform that will campaign on your behalf, taking out insurance ( another pooled method ), or even having formal Unions.

In essence that puts some of the economic cost of getting the decisions right onto the platform users ( as the friends/union does the work, and makes the case ). Pooled insurance has a similar economic basis ( platform users bear the cost of the insurance ).

Don't put all your eggs in one basket. We're taught that for everything from investing to dating.

This gets far more difficult as one competitor in an industry nears monopoly status.

Lets say for example that you somehow make $120,000 a year over expenses with instagram (don't ask how, it's just an example). This is far more than you previously made in your last job by double. The problem is it takes nearly 100% of your working time to make this income on that single platform. Any less amount of effort and your income drops significantly. Now, you are in a trap where you cannot split your efforts between platforms, you have to go full in on one.

Your solution would be to make far less money... um, safely? Whereas a far more realistic solution would be to ensure that you don't live to close to the edge of your means and put 1/3rd of your income back in savings in case the day the platform fails/kicks you occurs.

You could define all your eggs in one basket a different way.

So you could think about not operating as an individual who can be picked off, but operating in a collective way - either through friends, insurance, or unions.

ie what's your support network if you are dropped through no fault of your own.

If you save half your income, then for every year you spend on Instagram, you can spend another year figuring out what to do after Instagram collapses.

Own your customer relationship.

> However now we're in a situation where at least a few thousand people depend on this precise tool existing, and will be economically useless if it is banned.

If a 6-12 month training has no skill transferable to another analytics tool, I strongly suspect the training was useless to begin with. Other analytics tools are not so dramatically different from GA that you'd lose all methodology on what to monitor, how to conduct a study, etc.

To make an analogy, you don't suddenly become useless if you move from Java to C#.

Java to C# is pretty close though to be fair.

Going from Haskell or Scheme to Rust or even Python is going to take some time before you're completely comfortable with all the built-in's the standard libraries, the "pythonic" or "rustic" way of writing, tools and so on.

It's a lot of hidden things, you're not completely useless of course, but it's not like you write "production quality" code and have the ability to work completely independently or be an SME (like you probably were) within 1 month or even 2. It's a lot of little work to get back to where you were professionally.

Because it's not just a training course that is lost, it's all the incidental knowledge that was picked up on the job too.

I chose the languages used in the comparison with that in mind. Moving from GA to e.g. Matomo or Plausible does not require to completely reshape the way you think about your problems, you don't have to change the way you work, you just have to learn how your new tool implements it.

(Also Haskell to Rust is pretty straightforward, the typesystem knowledge you learn in Haskell usually means the harder parts of learning rust are made easy. Having done that transition, 1 month is reasonable to be productive in Rust)

IT is full of those tools that have so many undiscoverable but (arcanelly) documented problems that there's an entire market for people that spent years studying them.

The side effect is that for each of those tools, there's an army of people that spent years studying them, and will push them at every opportunity they can.

And interestingly, those tools keep being pushed at places even when perfectly fine alternatives exist that won't give you almost any of those problems and don't require any specialization.

what you wrote is mostly true but also partially incorrect: many competencies are transferrable.

there are privacy-compliant products in that sense, unless you've been literally told "click here and click there" you should be able to employ old concepts with new tools.

Given GP's paragraph:

> Personally I find this astonishingly foolish of the people who train exclusively on these tools instead of first principles and primitives.

I wouldn't be surprised for this to be a "click here and click here" kind of training. I've seen a painful amount of those. And then, when the inevitable "new and improved ui" comes along, these people are lost and require a new training.

These are essentially "IT Factory Workers". To be honest, I think there's value in that, with the same economics of "traditional" factory workers.

You'll be surprised at how many competent (or looked like) people that cannot connect the dots between technologies / tools. They excel at one tools and will having a very hard time migrating to new one since they cannot connect the concept and similarity between both.

Not all, but there's many.

There was a time when "Six Sigma" was all the statistical analytics rage for everything and anything corporate. However, if one already knew statistics they'd encounter a franchise branded school of terminology, different formulas than the accepted standards, and their own separate "z-tables" that apparently backed in corrections for their use of non-standard formulas. It was a hugely successful re-branding of standard statistics with a branded hierarchy of made up human hierarchies and Scientology-level made up technical terms. All the "Six Sigma Black Belts" - an actual title in corporate pointy head world - are 1000% useless now, unless they are at some dinosaur still following that nonsense.

This is how corporations and the will to profit undermines first principal knowledge and leaves a wake of fake education that ultimately needs to be unlearned or unwisely held as a fragment of useful adrift in an island of potential non-logical nonsense

> Personally I find this astonishingly foolish of the people who train exclusively on these tools instead of first principles and primitives.

Even if we would train them on first principle primitives, recruiters don't view it that way. That's even true in the software dev world. If you don't have 3 years of experience in Java, then it doesn't matter that you're a 5 years experienced software engineer in all kinds of languages.

> That said; we also have "Cloud Engineer" as a job title, so I'm not sure we will learn this lesson.

I don't bill myself as such, but I am basically a "Cloud Engineer". My expertise is in no way dependent on a particular cloud, and I've done work in GCP, AWS, Azure, Rackspace, and even a private cloud or two. A VM is a VM, Postgres is still (more or less) PG regardless of who is hosting it. Sure, there are specifics, but even cloud-specific stuff really doesn't differ too much, and it's pretty easy to find the common memes between the two. I can assign a role to VM in AWS, an IAM service account to a VM in GCP, and an "identity" in Azure. All 3 then permit the VM to make API calls to the respective cloud. All 3 fetch their access token in basically the same (but incompatible, of course) ways: HTTP request to a magic link-local IP.

A lot of the concerns I deal with, such as "can we survive an outage? what types?" depend on concepts like failure domains that apply equally to a cloud or to a datacenter.

But at some point, I had to dip my toe into a new cloud. I started a new job, and they used this thing called "Azure", and at that point, I'd never heard of it before. But you approach it with an open mind and the right balance of "some of my old knowledge might be relevant, but this new thing might also work differently and I should be prepared to build a separate mental model around it if the old knowledge is leading me astray."

… and I'd expect the same from someone doing "data analytics"; I'd expect something like "math is math, how I collect the data might change, what APIs I use to process it might change but the math is the same."

>> Google Analytics was sold as a solution to you making your own analytics, because that's hard

It's not hard at all, it's just that we have become too lazy and mentally dependent on big tech companies!

If all you want is user tracking, a few lines of JavaScript is all you need on the frontend. A popular WordPress plugin named jetpack gives you almost all data needed for site analytics, for example.

There are other tools too like tableau and python based tools like pandas and numpy which help you with all kinds of analysis.

Humble techies are everywhere with their tools, you just have to trust them a little bit, that's all! It's almost like trusting your Uncle Joe's pizza dude next door instead of the familiar Domino's or McDonald's. It takes a while but you'll eventually discover there's no difference.

Some business area pivots could be into user analytics or marketing analytics. Product management even.

Data engineering could be another path to explore.

I'd view your sister-in-law's certification course as more of a first step than an end. It could open doors but still have to stay relevant with broader skills.

> Personally I find this astonishingly foolish of the people who train exclusively on these tools instead of first principles and primitives.

Completely agree. So it is their personal decision. It has been forever.

People getting Macromedia Dreamweaver certifications instead of web development, and so on.

> Personally I find this astonishingly foolish of the people who train exclusively on these tools instead of first principles and primitives.

That's an elitist perspective that doesn't include the average worker making a living by knowing their tools and not much else.

Please tell me more about what you think is elitist here.

My personal situation is possibly the least background elite possible and even I know that first principles are important in a field that is shifting -- which happens to be most fields, just tech is a bit faster at churning.

That's just as true as it used to be with proprietary statistics tools such as SPSS, Minitab, SAS, STATA, JMP, etc. They used to own the market, pre-cloud; and all the university courses and commercial trainings. Eventually, people migrated off those platforms in favor of the current cloud-vendor ones (or else migrated to code in R or Python, or even MATLAB).

> However now we're in a situation where at least a few thousand people depend on this precise tool existing, and will be economically useless if it is banned.

Not really, there is no GoogleAnalytics-industrial complex yet, but yes apparently they have quite a lot of lock-in on nonprofits. I see this story as a privacy regulatory story driven by the EU and GDPR. They will order GoogleAnalytics to fix violations, and then Google roll another version of GA. Customers who want to take a stronger stance on privacy would migrate off GA.

I doubt there is anyone whose entire livelihood depends on GoogleAnalytics (I don't think your relative's "entire value" does, for example) and even if there was, they could reskill in the medium-term, but anyway you could make the same comments about certification, lock-in and perverse incentives about AWS, or plenty of other companies in previous decades.

This is why I suspect most cloud certifications are garbage. Most often they are just teaching you their product offerings. Even the implementation details aren't that useful because they change so often.

Compared to something like a Cisco networking certification: The CCNA will cover practical use of their products, sure, but they're also going to teach you subnetting, both standard and Cisco proprietary routing protocols and how they work, in theory, as well as how to employ them in practice. I've mostly moved on from using Cisco products day to day, but all of the understanding was directly translatable to any other platform I've worked with.

> Now her entire value is tied to the use of Google Analytics, she will almost certainly fight very hard to ensure that these skills remain relevant

On one level it's an important observation, on another it's mundane: DBAs will fight one another over Oracle vs DB2 vs SQL Server. Traditional bare-metal DBAs will fight RDS. C programmers are upset by Rust. People who invested a lot of effort in shell scripting for SysV init dislike systemd or s6.

This is almost like U.S. high schools, which almost exclusively require students to have Texas Instruments TI-84 series calculators in math class.

I had a TI-85, which was just a little different than the required calculator and didn't do everything quite like the book described. That was good. It meant that I had to learn to program it to do the things it didn't do like the 5 number summary and something else. Which meant I actually learned that stuff pretty well.

With a student:teacher ratio around 30:1 I'm not sure what the alternative would be

Probably, not totally wasted. If you learn the principles of analytics (what KPI:s to measure, why, how to diagnose based on analytics data etc) you can hopefully transition to another analytics platform such as matomo. Kind of like how it isn't wasted time to learn a programming language even if you later have to switch language.

How many bootcamp "developers" tooled up in one framework and struggle outside of that?

> we also have "Cloud Engineer" as a job title

Not quite the same, the core concepts and skills of a Cloud Engineer should be easily transfereable between providers and even to on-prem infra.

> where at least a few thousand people depend on this tool

Just taking Google employees alone, a few *tens* of thousands of people depend on this tool. Millions of non-Googlers depend on the tool.

> she will almost certainly fight very hard to ensure that these skills remain relevant

Skills are very seldom tied to a specific product these days, so she will be good.

Sounds a lot like the tech programs when I grew up being MS exclusive with active efforts to undermine non-MS products....

No snark intended--sounds like it may not have been a well designed course. Hopefully it was at least explicit about being GA-based.

Im still waiting for the Scrum fad to passover and the entire scrum masters guild to be without a job.

A bit like Instagram etc - there has to be a new fad for those people to move to for that to happen.

So sadly these things don't tend to go away, they just evolve.

Occupational lock-in was a theme explored repeatedly and with nuance in The Sopranos.

It is nothing new, that using Google Analytics is in violation of the European GDPR, I guess this was covered in the course. So why would she learn a technology, that is mostly illegal to use?

Maybe because most companies use it. Also, it is quite new for it to be considered illegal, GDPR only came into effect a few years ago. It would only seem "nothing new" if you're extraordinarily young and inexperienced.

Or if you work in web development in Europe. Moving away from Google Analytics and Google Fonts was a huge deal in the last 3-5 years. Companies kept looking intensively if they still use it somewhere and it was a lot of work.

Reply on news.ycombinator.com