The bugs are not at fault here. The people who created the environment for them to thrive are.
Edit After Downvote: I get it - They were a major nuisance to you. Lanternflys weren't a one time thing. This has happened before - remember stink bugs? This has happened many times and it is going to get worse. Please don't shoot the messenger.
Stink bugs, gypsy moths, Japanese beetles... I get it. The wave of SLF hit Central PA right as my first grape vines were maturing.
But Tree of Heaven is also an invasive species, native to China like the SLF; it's their favorite host plant. The SLF invasion can be very "spotty". If I eliminate the stand of Tree of Heaven from my yard, the SLF will probably go elsewhere. I don't use pesticides or herbicides of any sort... just some copper fungicide for my fruit trees.
When I see this article and the state announcement, I think of the Robert Pirsig Quote: "If a revolution destroys a systematic government, but the systematic patterns of thought that produced that government are left intact, then those patterns will repeat themselves in the succeeding government. There’s so much talk about the system. And so little understanding."
As someone originally from Pennsylvania - PA seems especially excited about invasive species. The spotted lantern fly was a big nuisance. Everyone talked about it. The spotted lantern fly and even this pear tree are not the enemy.
Invasive species thrive in ecosystems that we create. You don't want spotted lantern flys? You don't want thorny pear trees? Maybe ask who is defining the term "invasive species" and why they are defining them as such? Anyone thinking about cutting down your pear tree. Read "Beyond the War on Invasive Species: A Permaculture Approach to Ecosystem Restoration" [0]
> Invasive species thrive in ecosystems that we create. You don't want spotted lantern flys? You don't want thorny pear trees?
Non-native species get planted in environments we create (eg suburban yards). What makes them invasive is when they spread uncontrollably and displace native flora (dramatically reducing biodiversity in native ecosystems).
> Maybe ask who is defining the term "invasive species" and why they are defining them as such?
Sure, my definition above came from a hobby gardener friend who volunteers for a local environmental nonprofit.
> Anyone thinking about cutting down your pear tree. Read "Beyond the War on Invasive Species: A Permaculture Approach to Ecosystem Restoration" [0]
The reviews on that book are delightfully polarized.
I am averse to the rhetoric about invasive species, but do believe that invasives are, in fact, frequently a real problem, not a contrived one. But I think that all the hatred poured on the plants/bugs/etc. is misplaced. IMO, the two most important things we can do are:
1. Create fewer disturbed environments. These plants are typically those that thrive in disturbed environments. As such, they may even be regarded as providing some kind of ecological service. Unfortunately, one of the reasons they out-compete natives is lack of predation. The Amur Honeysuckle I've been systematically removing still have beautiful leaves even in early Autumn, untouched by mold or bug.
2. Prevent the introduction of new species via the commercial nursery vector; hard to achieve any kind of ecological equilibrium when we are constantly disrupting it.
I've kinda had a similar perspective until buckthorn. Buckthorn is essentially eradicating native Big Woods forest, transforming forest that comprises an open understory with high canopies into dense tangles of buckthorn that choke out anything else. It also leads to these boom-bust nitrogen cycles that wreak havoc on the soil.
Many of these forests were just fine until buckthorn arrived. The problem isn't with buckthorn per se, it's in the destruction that it causes on native ecosystems. If the buckthorn was just here or there, an addition to the landscape, it might be fine, but it's not.
A solution to buckthorn overgrowth can't come soon enough because mechanical solutions, while effective, are very laborious.
Maybe there's something that could be imported to keep it in check (I recall reading buckthorn has some kind of highly specialized moth or something that eats it in its native range) but regardless of why, it's a problem.
> I've kinda had a similar perspective until buckthorn. Buckthorn is essentially eradicating native Big Woods forest, transforming forest that comprises an open understory with high canopies into dense tangles of buckthorn that choke out anything else. It also leads to these boom-bust nitrogen cycles that wreak havoc on the soil.
Buckthorn is the devil's plant. IIRC, it's a hedge plant, and literally turns a forest into an impassible hedge.
> Maybe there's something that could be imported to keep it in check (I recall reading buckthorn has some kind of highly specialized moth or something that eats it in its native range) but regardless of why, it's a problem.
IIRC, they're close to approving something like that for garlic mustard (which kind of does the same thing as buckthorn, except on the forest floor, and often gets bad after you deal with buckthorn). They've had to do a lot of testing to make sure it's very specialized and doesn't cause another invasive pest problem.
> A solution to buckthorn overgrowth can't come soon enough because mechanical solutions, while effective, are very laborious.
In Minnesota, they’ve been using goats. It’s still labor intensive, but the labor is performed by goats. Still, there are only so many goats, and there’s a lot of buckthorn.
I love the Big Woods ecosystem, and there’s very little of it left :/
This. My own "invasive is bad" epiphany was with honeysuckle in a SE Michigan park. They had grown so thick that nothing was able to grow in the soil under them - which had turned to dust, like the surface of the moon.
> Invasive species thrive in ecosystems that we create...Anyone thinking about cutting down your pear tree. Read "Beyond the War on Invasive Species: A Permaculture Approach to Ecosystem Restoration" [0]
The problem is they also thrive in (i.e. invade) ecosystems that we didn't create, and destroy or disrupt them.
If these species didn't invade wild ecosystems and stayed put in our backyards, then they wouldn't be invasive.
You're acting as if it's not possible to steelman the case against invasive species. This is a bit disingenuous.
Imagine we discover an alien planet with no predators. Should we allow ecological merging, with reasonable expectation of large biodiversity loss?
I'm not an absolutist; there are opposite examples - imagine that in the far future Australia were about to finish its tectonic journey to touch another continent and we expected new connection to result in massive ecological disruptions. Trying to prevent such a thing forever would be questionable.
The point is: you have to dig into reasons and outcomes, and can't resolve this kind of debate by simply saying "foreign bad" or "foreign good".
I 100% agree with you. You absolutely "can't resolve this kind of debate by simply saying "foreign bad" or "foreign good"
Imagine we discover an alien planet with no predators. Should we allow ecological merging, with reasonable expectation of large biodiversity loss. The problem is, the alien planet doesn't have a pesticides industry propped up around saying "foreign bad"
But I have no idea, and am not qualified to answer that hypothetical.
(The author was my theory of computation professor at University of Pittsburgh. Dr. Daley (RIP) commuted by Harley-Davidson and in his free time served as chairman of the regional forest stewardship council.)
> Invasive species thrive in ecosystems that we create.
In some cases yes, in other cases they simply out compete local species.
My country had managed to keep snakes out, but no doubt if they ever took hold here they would thrive in the wild, and harm the native bird population like the invasive stoats have. The invasive stoats live in the wild, far from people.
The book referenced actually provides numbers on this. Invasives out competing local species is a rarity according to the studies referenced in the book.
I'm not really commenting on the thesis of the book, but pointing out what seemed like a valid criticism of the book overall. After skimming a few articles on the subject [1] it seem like the reviewer is not out of line with scientific consensus on the example he points out.
Kind of, the idea is that no species would be invasive if we didn't create the ideal place for it to thrive. Invasives mostly thrive in disturbed areas and don't actually displace natives. The book I referenced goes into way more details, but in most cases invasives actually help repair damaged ecosystems. They are often pioneer species in the disturbed areas.
You cite -one- book that maybe says what you want to think and looks more opinion than science. You write also a quote about politics and there is also that old feeling of "we humans are the worst" in the air that can feel justified but never solved anything.
I have a PhD in biology and frankly I'm sick of discussing this issue each time again and again.
Are you solely focused on plants here? Invasive species can also apply to animals. Invasive aquatic species have decimate local animals, and we didn't necessarily create those environments. There's also invasive plants in these aquatic systems as well.
Yes thank you for this clarification. Apologies for my being imprecise. Most of the reading I have done has been related to plants and the use of pesticides to intervene.
I'm sure this is really well intended, but the individualization of environmental guilt is a major problem. [0]
Where I agree with the article is to use tools like lighthouse and write code that uses the language properly. It is absolutely individual's responsibility to do this. The responsibility of making code efficient (dare I say "green") lies in those writing the browser engines/compilers.
I only recently found out that the idea of an "individuals" carbon footprint was popularized by BP, in order to shift the blame off themselves and onto us:
No, this is wrong. Performance is everyone's responsibility, because compilers are fundamentally garbage-in-garbage-out. The people that work on them are incredibly smart and I don't want to discount that, but there is fundamentally nothing they can do if you write something nontrivial that's O(n^3): that's on you to fix. The fact is that a lot of websites leave timers running in the background or use really inefficient ways to manipulate the DOM, and despite the work of all major browser vendors there's not much that can be done here except asking the people that make those websites to not do this. If you're one of them, you should make it your responsibility to care about performance.
>The responsibility of making code efficient (dare I say "green") lies in those writing the browser engines/compilers.
I don't get it. Are they not doing that? Performance and battery life is a major selling point for browsers. If anything the biggest failure is at the individual developer/site level, not that firefox causes your fan to spin into overdrive when it tries to load a SPA monstrosity.
By the logic of the original article, you should hyperoptimize your code. The problem is. If everyone writes `for` loops instead of using `map`. When map eventually becomes more efficient there's all that garbage code out there that has to be refactored.
It comes down to return on effort. We only have so much effort to put at solving this problem. You maximize your return on effort by having a clear separation of responsibility. In this case the individual's responsibility is to write code to the latest spec. The institution's responsibility is to make the code written as efficient as possible.
A single website saving .000000001 ppm of carbon (exaggerating) is just never going to be worth the effort. But a compiler improvement on all websites running javascript. Now that's totally worth it.
P.S. Thoughts: This might be the case for software engineering, but might break down in other domains and should be applied carefully elsewhere.
For example recycling plastic is your responsibility - but what if your city burns plastic recycling? What do you do? Do you continue to buy plastic blame the companies for using it and the city for burning it? Why should the individual be penalized?
This seems more gray to me, like yeah okay I'm going to reduce the amount of plastic I buy in that case. And there are alternative like paper. In programming it feels more black and white. There is map and it serves a single purpose.
> For example recycling plastic is your responsibility - but what if your city burns plastic recycling? What do you do? Do you continue to buy plastic blame the companies for using it and the city for burning it? Why should the individual be penalized?
Unfortunately, while what you are saying is the conventional wisdom, it turns out that it’s also insidious propaganda from the plastic and beverage industry created to evade responsibility for their products.
According to the Changing Markets Foundation, which has extensively tracked the history of this issue
> the industry has successfully shifted the blame and responsibility for plastic pollution from the corporations to consumers and public authorities, all while promoting recycling as a convenient excuse to produce ever more plastic. We see how fake environmental groups and increasing numbers of new voluntary initiatives are used to distract from accountability, while legislation – such as plastic-bag bans and bottle bills – has been furiously fought against for years.
Inefficiency is not due to the choice between for and map, but due to them executing many times. When you run a quadratic algorithm, it doesn't matter whether it's implemented with for or map, it's inefficient in both cases. Premature optimization is when you optimize based on assumptions as opposed to diagnosis of the problem. You believe the problem is due to for/map based on a priori reasoning. You also believe your code needs hyperoptimization before it had basic optimization. Well indeed why not, your code can't possibly be bad?
Google and Mozilla seem considerably less concerned about efficiency than Apple and Microsoft are. Safari is well known for being easier on the battery than Chrome and Firefox are on macOS, and pre-Chromium Edge had similar efficiency margins over Chrome and Firefox on Windows. I’ve heard that even Chromium-Edge tends to outperform its competitors on Windows even now.
This starts to make sense when you consider that for Apple and Microsoft, end users are the customer and bad battery life is going to have implications on number of devices sold. For Chrome and a lesser extent Firefox, the “customer” is instead web devs, who are more interested in a constant stream of new features than they are efficiency.
That said, both browser vendors and site devs are responsible. It doesn’t matter how optimized the browser is if a site loads tens of megabytes of dependencies and is written with expediency and cheapness in mind only.
More practically, if the browser developers make more efficient browsers, what typically ends up happening is that the web developers make more inefficient websites that consume the additional resources available. It's Parkinson's law. We need both efficient web browsers and efficient websites.
All guilt and responsibility is individual, as individual humans are the only ones with subjectivity and agency. Assigning blame to groups and "others" is extremely counterproductive. You either do what you can or you don't.
We can sit around trying to find scapegoats and and point fingers for a hundred years, and it's not going to do any difference. The consumers can blame the the producers, the producers can blame the consumers. The voters can blame the politicians and the politicians can blame the voters. The right can blame the left and the left can blame the right. Men can blame women and women can blame men. Cats can blame dogs and dogs can blame cats.
The reason it all sounds true is that every single one the accusations are true. Why yes, the producers are to blame, so are the consumers, the politicians, the voters. We are all to blame, we're all culpable for our decisions as individual humans. Each and every one of us all have responsibility.
Individualisation is just a step needed for collective change.
From the individual to the state and then the world, everything is continuously collective.
You just can't hope your institutions to change if a minority of citizen haven't proven lowering one's environmental impacts is possible, and made it socially desirable.
Then institutional change can happen.
In democraties at least, comsumer-citizens are necessary for the system to change.
In the developed world we've already gone beyond the optimal point of individual environmental responsibility and it's all diminishing returns from here.
Inefficient code reduces battery life, consumes CPU and RAM resources and overheats hardware - all this directly affects the user, not environment. If the browser terminated the script after, say, 1000 instructions, that would help, but it's only a mitigation for a bug in the script code, not a proper solution.
Once again, the answer seems to be "why not both". Calculations on individual carbon footprint are useful for buying offsets. Complaining about individualization feels like permission to just not make it our problems. Yeah, we have big companies and big governments, but individuals use those services. So yeah, agitate for changes on the global scale, and yeah, also look at your own footprint.
Not 100% on topic, but related - not mining or using crypto or writing apps / software / sites that enable it, at least the ones like Bitcoin that are massively greedy re: electrical usage, might also be effective.
no, it is not not only the responsibility of those writing browser engines / compilers.
it is the fault of the product designers who take any advancement in the efficiency of technology as a excuse to push more crap. see: blockchain for the sake of blockchain, machine learning for the sake of machine learning, web apps for the sake of web apps
This is a good critique of low-code/no-code in general. The root problem I see of "Unfortunately, when we frame the problem space that way, we have allowed our tools to think for us." is that in reality there are just not enough qualified software engineers out there.
I got bounced off a front-end job once, for not being good enough at React.
Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue.
But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic".
Meanwhile, none of them could tell me how React actually works, beyond throwing jargon vomit. They couldn't write a web application without React. The recruiter, which we had to go through, basically had no empathy and saw me as a failed resume. I felt pretty helpless, even though I've said many times to both parties that I wasn't a "React developer".
That is the sad state of affairs today; and I'm finding it's not just in the front-end, where you could argue that you need sanity on this pile of rubbles. It's also in the backend, especially on the auto-magic "DevOps!"
> Meanwhile, none of them could tell me how React actually works, beyond throwing jargon vomit. They couldn't write a web application without React. The recruiter, which we had to go through, basically had no empathy and saw me as a failed resume. I felt pretty helpless, even though I've said many times to both parties that I wasn't a "React developer".
But they don't make money by knowing "how React works". They make money by "writing good-enough React code that pushes features to production". I think get you, and in some sense I feel identified with you, it's just that the industry has shifted from "let's care about our craft" to "let's write good-enough code to make more money"... makes me sad, but hey, it's business I suppose.
I couldn't care less that a candidate knows what "React hooks" are (that's probably gonna be outdated in 1 or 2 years). I care if they know how to write modular code. Management doesn't have the same opinion, though: employees usually work for 1 to 2 years at the same company... so knowing what "React hooks" are now, matters for them.
I don't think React hooks will be outdated in 1-2 years. Between Svelte and Vue I don't see a path for a formidable challenger. You get the complete ecosystem around it. There's tools like Stencil, and I like those tools, but giving people whole-cloth access to make anything, with no 'base' design system, tends to lead to the creation of inaccessible UIs. And it's quite simple to introduce a11y issues. The front end stack isn't moving at the speed it did in the early 2010's, of which I am personally appreciative of.
I agree. I think the next big shift will be a fairly big one, not an incremental step.
Personally, my money is on Phoenix LiveView - the syntax and concepts aren't super familiar, but the benefits of no longer having to build a lot of your logic multiple times and the ease of scaling this platform are extremely attractive.
I've worked with people of varying skill-levels but personally gravitate towards those who can code idiomatically. For me it's important I write idiomatic code and follow the language/framework/api guidelines to the letter so I don't become a maintenance burden to my team.
In the fast-paced world of frontend dev, the last thing I want to do is revisit "complete" work, be it a lack of env parametrisation or something bigger. We make assumptions based on idiomatic implementation - failing to conform means work-items can slip ("This story will slip into the next sprint because the I had to convert the callback into an idiomatic action/reducer first").
Which idioms? This week’s? Or last week’s? If I’m at guru level and am capable of evolving to whatever next week’s idiom is, can we code together then?
I agree with you in general. But I do find that this litmus test sets up a moving target in some of today’s more trendy/culty language ecosystems.
I think it depends: not using specifically env variables for configuration should let be a big deal. But hard coding values rather than using some sort of configuration file is bad practice and could cause issues on a team.
This is fair, but silly then to interview someone who “doesn’t know React” if you’re not willing to teach the framework. Frameworks and languages are easy to learn, idioms and all. If a candidate is knowledgeable and can write idiomatic Vue or something similar, why would you think they won’t be able to do the same with React?
I have been in a similar boat. I was spending a bunch of time avoiding extra API calls and extra renders in React and the team I was working with didn't seem to understand that there were potential performance issues around that. They said "just use memo"
On the other hand I think it is a natural progression. 30 years ago experienced engineers would look at young people who didn't know how to fix a PCB or read bytecode and think it was a shame. If everyone had to get a computer engineering degree and work at several different roles before they could even build a UI, that would be bad for productivity.
It does make you wonder what is going to get missed though, doesn't it? Each generation gets to work on a level of abstraction higher than the one before it.
I think about that often when I think about all the things I don't understand about hardware and EE.
I did computer engineering in school 20 years ago, and have always enjoyed understanding technology. So I know what is happening from the gate in the cpu all the way up to the pixel in the monitor. The downside is that I'm spread pretty thin. I can't pass leetcode exams in the 30 minutes of allotted time, ops people can't understand why I don't use containers, and my knowledge is probably useless in making a modern CPU.
At some point, you may have to look beyond traditional employment situations to best make use of your technical knowledge and experience. However, it might mean moving to consulting and possibly 'selling' yourself on a more regular/periodic basis.
I have soldered chips to boards .... close to 40 years ago, and plugged enough cards/cables together to last a lifetime. (I really don't like hardware stuff!). I've done basic Z80 and 6502 assembly up to ... web stuff today, and loads in between. I can passably describe the innards of some layer of various SQL engines, have compiled linux kernels and various packages from scratch, configured mail gateways, debugged DNS, setup/managed firewalls and intrusion detection systems, can often diagnose various application performance issues from description of symptoms alone, and can do many other things 'tech' related. (not trying to brag - loads of people here can likely do all of this, and more, and better, than me).
BUT... this set of skills often doesn't fit well within a traditional 'job' role. Finding situations where people can get/extract value from a wide variety of your skills is difficult (but can be rewarding when it's done).
I also can't do leetcode stuff, struggle with some 'point/click' things that others seem to find natural, and it can take me longer to 'produce' compared to others (although, I've often found myself cleaning up after others' projects when they leave).
I hope you have found (or can find) some situations that make the most of your skills, experience and perspectives!
There are still places that need and are looking for that sort of help! Especially inside smaller cloud companies (Digital Ocean, Linode, etc) (or any company that's got their own datacenters, eg Facebook) where the solution to a problem can't be to use some AWS service. A heavy hitting sysadmin (embrace calling it devops instead) like yourself is necessary to getting stuff off the ground to a proof of concept stage, then to production.
Grinding leetcode is falling out of fashion anyway for many reasons, (but Leetcode will never tell you that), but it's still a skill to practice up on and be able to make it past an easy question without problem. It's not a skill you'll use normally at work, but the secret is no one's good at leetcode shit out of the door. It takes dedicated practice until you can pass it the interviews, just like any new skill.
I found that I make the most money investing, mainly via Tesla over the past 8 years. I only have about 1% of the engineering skills and work ethic of Elon, but that has been enough to understand what he is doing and ignore all the people on CNBC with MBAs who don't understand engineering.
I'm actually thinking that at some point, no one will be building custom software. Everything will be available off the shelf, as some product, running on some cloud within a few clicks.
So "custom software" developers are a dying breed.
For example, when Jira is down, a Jira "specialist" will tinker and bring it back and look like some guru walking down the mountain of knowledge. Arguably, this person probably wouldn't know anything about SIMD. Yet the SIMD guy is looking for a job, no one cares about that guy. But the "salesforce developers" and "Jira specialist" are permanently employed at very high wages.
Custom software won't be dead because you can't buy integration off the shelf. And JIRA specialists and similar roles will just eat up more of the potential workforce that could be employed as software developers, so software developers will stay a valuable scarce resource.
I think there are quite a few people like us - I have a different background from you, but I do feel like I'm spread a bit thin and haven't really specialized in anything. The good news for us is that I think it's not the end of the world - it's still possible to deep dive into something and specialize in it, so long as you can find the time :)
As another generalist that enjoys occasional (very) deep dives but never gets tied down to one platform/tool/skill/problem set - being a good jack of all trades is it's own special skill, and it is quite rare.
Small and medium sized teams really need this sort of person as the mythical "10x" engineer, and in many cases this is a great stepping stone to technical/team leadership, PM roles, and entrepreneurship.
This is a nice glass-half-full way to look at it, which honestly I hadn't considered doing before. I will try to think about things this way a bit more :)
> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Thing is, if you needed to make a fire in the rain and skin & prep and animal, you'd have a good chance of at least getting most of the way there as you understand the concepts. The problem here is more equivalent to not even knowing what and animal or fire is, nevermind how to do the tasks at hand.
if you are that good, then why are you wasting your time with front ends? Go into databases. You're apparently already starting to age out of the young and dumb and works overtime flotsam.
I work at pretty much all levels of the pie, but my passion is with what the user interacts with, which is why I tend to gravitate towards the front-end.
Being "good" has nothing to do with being a back-end programmer, imho. One could even argue that the front-end of today is far more complex than most back-ends!
> Being "good" has nothing to do with being a back-end programmer, imho
That's a tough one. As I see it, a lot of the complexity in frontends is in framework feature bloat, subpar tooling and high tech churn as compared to backends. In a word: immaturity. Frontend doesn't guarantee backcompat like backend technologies do, which is also a large part of the (unnecessary) complexity. Obviously, frontends are additionally subject to the whims of fashion in a way that doesn't apply to backends.
In contrast, backends have mature frameworks that can deal with most concerns, allowing the developer to operate on a higher level and with greater confidence in the basic nuts and bolts. Package management is generally sane, to boot.
How much less complex would frontend be if we weren't trying to cram applications into a document model and instead had built-in support for controls/components, theming, data binding and inter-component events? If JavaScript didn't have so many shortcomings or perhaps even gradual typing?
In my experience, frontend skews young whereas backend skews older. That leads to junior class errors in frontends, such as not understanding the benefit of type annotations in a dynamic language and general cowboy behaviour. Perhaps the latter is also down to the general "move fast and break things" approach in JS land.
My own conclusion is backend developers as a group tend to be better, but that's mainly by virtue of having more experience under the belt, being less impatient and taking a longer view.
I’m a mostly backend dev (I dabble in Vue), but it’s seemed to me for some time that browsers are effectively operating systems. The level of complexity of the JS/HTML/CSS troika is staggering, and the number of APIs in a browser pretty much gives you access to abstractions of the whole machine. It’s nuts!
So I have complete respect for professional front end devs. They are every bit as smart as any other developer I’ve ever met.
And then with all that they make it look good too. Something I’m apparently genetically incapable of!
I think you're missing the point on every subject you touched on and I likely would not hire you either.
For one, most frontend developers now use environment variables to feed in configuration specific data, most notably URLs and feature flags, so that they don't need to do find/replace operations in the final scripts (most notably, minified bundles). It really has nothing to do with HTML, unless you've decided to interpolate values in static HTML pages. The environment variable concept is agnostic of any frontend framework and only requires a build tool of some sort, such as Webpack or Rollup.
On your point about not knowing React... I'm not really sure why you couldn't stick the landing here. If you knew they were a React shop, why not just look into it and build a React app on your own time? It's as simple as doing `npx create-react-app` (or something, I forget the syntax) and building your own React app. If you're such a seasoned frontend developer, surely this would be easy?
On the sad state of affairs: I really think this is another area where you're wrong too. I now know Knockout, Angular.js, Vue, React, and just now looking into Solid.js. I don't know the exact internals of each of these tools, but I can certainly explain to you what a digest cycle is in Angular and what hydration/rehydration means in React SSR. To someone who doesn't know the terminology, this can sound like jargon very easily.
On devops: a couple of years ago I found out about CI/CD, monitoring, and a couple of other concepts, and my workflow completely changed in both professional and personal projects. I now spin up entire infrastructures in AWS in minutes using Terraform. And frontend apps are now incredibly easy. I'm currently working on a Solid.js frontend application on my spare time.
So yeah... maybe you should change your attitude a bit. Based on what you wrote, it sounds like you might be the one that's not on the same wavelength.
Why would one go and s/// in a minified bundle when you have the code? I don’t get it. Is your code read-only? Write-only? You can’t follow imports, can’t lookup a symbol definition?
You sound like the one who wants to hire a guy who already worked for 1-2 years in your department. These minor details at the interview like “in your whiteboarding session you didn’t name a constant like we usually do, wrong!”. Duck-diffing as it is it seems.
I agree with grand parent regarding .env variables. During an interview it shouldn't matter whether a candidate uses a .env file or a shared config javascript object, just as long as the candidate can demonstrate the ability to write maintainable code, and isn't excessively dogmatic about their preferences.
I’ve hear the way to succeed with SAP is to reorganize your business to match either the default world view or some other cookie cutter variant. Essentially using it no code style.
Otherwise you’re exerting yourself doing “normal” things. That’s not sustainable.
At the end of the day you are purchasing a COTS product specifically to gain efficiency of industry best practices already coded for you.
If you take a COTS product and then try to rewrite it to fit your "unique" business processes, we'll, that's why half of them fail.
Implementation of erp is incorrectly and disastrously viewed as an IT project. It is first and foremost a business transformation project. A company should be self-aware to say "HR|Accounting|whatever is NOT our core business or competitive advantage; it's not what we are great at. It's not a thing we should be unique in. It's a cost centre and we need to standardize and minimize that cost with help of people and software that were successful with many other companies".
(Source: I've been implementing Peoplesoft, a competing erp,for 20 years for dozens of companies, as a technical resource eventually wise enough to be aware it's fundamentally not a technical endeavour :-)
This is why my company has custom applications that talk to the ERP for certain departments. Inventory control in the ERP isn’t going to work with reality. The data modeling is good enough but the interface is not.
Rather than train everyone we hire to use horrifically bad and expensive barcode readers, we purchased cheap smart phones, put them in cases, and locked them down to run an app that uses the camera to scan barcodes. Drop a phone? It’s encased in rubber. Run it over with a forklift? Toss them another one from the box and then figure out why this only happens on Tuesday afternoons.
We already need a dev team for other reasons. Adding another decent programmer to create and support internal apps isn’t that expensive in the long run. Plenty of good devs like me who are happy to work remote from the Midwest at less than FAANG rates. :)
> This is why my company has custom applications that talk to the ERP for certain departments.
This is the best approach. Inventory is a great example of something that is both very important to an ERP and needs to be modeled impeccably if you want accurate costs (think license plate numbers tracked back to manufacturing), but at the same time you sure as hell don't want your ERP to be the "system of record" for operational systems.
It was a very humbling experience working with accounting and finance to close the books and update forecasts.
My wife worked for an association that got bit badly by the one true platform bug. They had an excellent publishing platform, with features that were then incompletely implemented in whatever association-management platform it was. I couldn't imagine why a clean, limited interface to the platform couldn't have been implemented at less cost. She was fortunate to be gone before the change was implemented.
Yup there's a few approaches. These days most ERPs have nice semi-modern interfaces making mix-and-match easier, but honestly over 20 years I've seen industry go through 3-4 long cycles between preferences for single-vendor/stack homogenous solution, or "best of breed" mix (I know, buzzwords all but sometimes handy:). It seems one of those things that goes and comes around....
This outlook is actually endemic in the ERP implementation space.
The part you're not going to like hearing is that, due to laws/regulations, that "default world view" may be the best way to approach that problem for that given module/area (e.g. how to structure benefits or compensation). "Creativity" in the ERP space is costly.
Also reducing your variation to something that's configurable as opposed to custom codebase means you don't have to do extensive testing whenever a patch or upgrade to the ERP software comes out.
One of my biggest customers was bought by their competitor after a big SAP implementation. The consensus amongst management was that the project weakened them so much they became vulnerable to takeover.
Twenty-odd years ago we sat through presentations by Peoplesoft implementation consultants. When I looked through my notes, I found that all of them said, with slight variations in the wording, "you have to do it Peoplesoft's way." I'm sure they were right.
I have it seen time and again. Organizations and leadership being faced with a problem and jumping directly to tool / software selection and implementation before really having understood the problem itself, the processes and requirements. After selection, directly to implementation. Because, you know, we a re agile and working in sprints. So we can sort out architecture and interfaces as we go. End result, tools force you into the use not understood processes that have nothing to do with your business requirements whatsoever, an architecture that is cobbled together and users that don't understand neither.
Even better if the tools are selected based on previous experience alone.
(Of course, this is the problem with the traditional synechdoche of a country name for the policy of one particular government at one particular point of time...)
> They're saying no to a Chinese puppet org (the UN)
That's a strong and outright ludicrous statement. The UN's highest body, the Security Council, has 5 permanent security members with veto powers, which includes the UK and US ( alongside China, Russia, France). So China doesn't have any more power over the UN compared to the US.
> using clean environment as an attack on them while China does nothing to address their environmental impact.
China is adressing their environmental impact - most notably in electricity generation where they're replacing coal power plants.
More coal generation too. All this means without context is that they're big. Their commitment to green initiatives has been extremely toothless to date
And they also have the most lax environmental standards. Green energy is nice but allowing business to dump whatever they want into the environment isn't.
I would imagine China will demand a clean environment be a human right and then turn around and say they have no duty to help with it because they have been and always will be a “developing nation”.
Edit After Downvote: I get it - They were a major nuisance to you. Lanternflys weren't a one time thing. This has happened before - remember stink bugs? This has happened many times and it is going to get worse. Please don't shoot the messenger.