notyourNMI
I believe the reason users still pay is so the price can justifiably be multiplied in bulk corporate purchases, otherwise they'd give it away for free to get more of that sweet, sweet data. So they can copy Google, poorly.
It may not be the truth some want to hear, but Netflix will likely be more than happy to identify "troublemakers" with this planned walkout, even if they're fantastically productive otherwise.
Many C-suite see themselves as leaders "going in to battle" leading an "army". The last things leaders tolerate in an army are deserters and overly objectionable types.
For one, anime enables storytelling on a level and scope that would ordinarily be too expensive for real film production for most stories told. As an aside I think we're about to see a whole new level of mind-bending "realism" afforded to lower budget productions with tools like UE4/5.
You could argue that "animation" in general does this, but the particular (myriad) stylization choices in Japanese animation carry a fairly unique appeal. I think this was borne of a long-existing cultural tradition of prolifically illustrative literature.
For my part I had family that liked DBZ and similar ilk. The over-the-top-ness blinded me to the appeal as it just felt blah to me. It wasn't until I encountered more serious, darker themes in GITS, SEL, and others that I really grew attracted to the artistic potential of the medium.
I personally feel that art, in whatever form, is validated by making the observer feel something. Even if it makes them feel disgusted, annoyed, inspired, becalmed, horrified, and so forth. Given this, I value anime (or storytelling in general) that knocks me over the head with the emotional intent of the storyteller. It's really hard to get right without being heavy-handed (thus diluting the effect).
Two amazing examples come to mind: "Grave of the Fireflies" and "Ghost Hound"
Grave of the Fireflies is semi-autobiographical and will mess you up for days afterwards. Kind of like Bjork's "Dancer in the Dark". Both do an excellent job of forcing you to take a perspective that most will (fortunately) never have to endure in real life.
Ghost Hound touches on frankly f'ed up themes that an adolescent is trying to cope with. It engages supernatural elements that honestly at times practically noped me out for the imagery and setting alone. Of course this is animated fiction but the way the viewer is pulled in to the story with the protagonist was so well done that you can forget the medium to a degree. Highly recommended.
(Don't read/watch anything about these before watching if you can avoid doing so. Best to come in unopinionated.)
On a side note, I found SEL polarization to be very telling. Some people absolutely hated Serial Experiments Lain, while others like me were drawn to the bizarre reality of the story. I think the fact that this medium can be so polarizing validates my claim that this is art.
"Update August 30th, 12:30pm: Added mention of the Atari 2600 as predating the Nintendo 64 for console joysticks."
From Wikipedia: Ralph H. Baer, inventor of the Magnavox Odyssey console, released in 1972, created the first video game joysticks in 1967. They were able to control the horizontal and vertical position of a spot displayed on a screen.[8]
(Magnavox definitely had joysticks on their controllers early on)
It's not unreasonable for them to ask me to pay, but it's not unreasonable for me to not want to bother for content of this level.
Half-kidding, half-serious. I'm thinking of those books with titles like "How to make lots of money" where the opener is "Chapter One: Write a book about how to make money"
Jokes aside, kudos for writing about your experience and putting it out there for others to benefit from. That's further than many will dare to go.
I have to say I do like his Chatodoro concept, however, so perhaps that's the key.
I agree we're perhaps dickering over distinctions no one external cares about, akin to characters in "Let That Be Your Last Battlefield". Is our internal perspective as valueless as the mindset of those characters above, or is there use in hammering out a common understanding for the general public before it's handed to us?
That being asked, the distinctions may be moot. Most of us have probably 10-20 years of rapidly dwindling utility in our respective realms due to the swift boot that is ML/DL/etc. And your point will remain more poignant at that time: "will anyone outside of our field know or care about the difference?".
What I meant to express is how I personally see our types of work relating to non-software engineering professions. For many physical engineering disciplines there's some type of external regulatory body that you must measure up against for each project you complete, to have that project approved to be "launched". In the UI example: if there's no external body that has to sign off on your work, you can pretty much do whatever the heck you want to get that gorgeous interface in front of a user. The skill required to do so may well dwarf my own, with a million crazy frontend js libraries, web standards, and so forth to memorize and wrangle (not a UI guy, obviously). But in my own admittedly narrow definition, as the work can be done without being answerable to some external body that has to sign off on it, I couldn't call that engineering. Again, it doesn't mean the UI work isn't complex, requiring highly skilled individuals, etc. Of course even safety critical software engineers don't have a regular recertification required. Given that and other differences, even this application of the term falls short in comparison to other disciplines.
For the record, I'm still of the mind that "real" engineers are those individuals trained to create physical things built to withstand innumerable stresses, structural material complexities, manufacturing hurdles, and so forth without endangering lives or risking property damage. We software types have sort of usurped the term, for better or worse. It's here to stay, but some kind of indicated specialization known widely beyond our industry could help.
Regarding "full stack" though, there are areas of certain software-heavy industries where that term doesn't matter. Take an avionics "black box" for instance. It can be a strictly embedded device with no concept of a PC-type environment. They almost universally run some kind of RTOS or compartmentalized RTOS, and perform a short, known list of master tasks (10-20 for instance) that will never change. They talk with various hardware in the aircraft and through radios on the aircraft to a variety of ground stations, satellites, and other aircraft. The standards they adhere to (for the physical wiring from box to box, the protocols on those wires, the way the software is designed, etc.) can be 20-30 years old. Those standards can be updated sometimes never, sometimes 2 or 3 times over that span. There's no concept of constantly changing software libraries because it's so SO ridiculously expensive to go through a process called "certification" that reports on exact versions of software working on exact versions of hardware, and then you don't change a thing (not a single resistor, not a single bit) unless you have a very good reason to. Besides knowing your embedded software/hardware craft, the companies that build these boxes want engineers steeped in the guidance and rules of the appropriate regulating body (in this case, the FAA). There's a rep from your company (but representing the interests of the FAA) looking over your shoulder, so to speak, called a DER. That person's job is to put their ass on the line for your company, to the FAA, saying you did what you were supposed to. You have to highly specialize in order to do your part correctly so your DER can do their highly specialized part correctly, so the FAA can approve your company to sell said black box to aircraft manufacturers with an FAA seal of approval. It's a ridiculously intricate, expensive, and time-consuming process that helps to ensure air travel is generally extremely safe. The FDA is about 20 years behind the FAA in terms of dictating what and how, but similar concerns, processes, and regulatory hurdles apply. There's extreme rigor required in these fields, and extreme specialization, because if you screw up you can kill somebody (or lots of somebodies).
Depends on the field you are in. Here at least, use of the title as it relates to software is currently driven by the hiring agency/company. If you are hired on as a Software Engineer without a degree, then you are a Software Engineer (at least in title, at that position). You damn well better be able to perform. But you can legally write "Software Engineer" on your tax forms.
In my personal opinion, what differentiates a software engineer from a software developer is the level of engineering rigor required for the development and application of your software in a given environment or system. Are there standards in place that recommend (mandate) you provide certain reasonable assurances (e.g.: verifiable proof derived through specified means) that your software will not yield unexpected behavior? Are there standards in place for a given industry that confine the way you use specific languages (to attempt to ensure the aforementioned unexpected behavior will be minimized or eliminated)? I'm thinking of DO-178B/C, IEC 62304, & MISRA as industry representatives here. If you can digest and navigate these standards, and prove to the applicable regulatory body that you adhered (designed, developed, and tested) to their respective guidance documents, they couldn't give a damn about a degree. You've proven you're aware of the risks your software can pose and how to mitigate them through thoughtful application of standards, rules, and hopefully best practices.
Here's where I'll piss some people off: Would I call a front-end UI developer a "Software Engineer"? Probably not, unless that UI is destined for a system where a developer error could cause harm, property damage, etc. What about a trading system where performance losses measured in nano-seconds could accumulate millions in losses? Possibly, depending on the complexity. My personal metric (based on my own career experience) is "will a screw-up cause harm, loss of life, or irreparable damage/destruction to expensive things". Losing millions in a trade and losing millions in an *craft crash are not equivalent to me personally.
Background: Non-traditional EE trained on avionics hardware who moved into developing safety critical avionics and medical device software and hardware.
Google "Python light control with RPi (Raspberry Pi)". Drastically simplifies things that use to be quite complicated for the novice to dig in to.
If you're a book reader, look for "Raspberry Pi Cookbook" by Simon Monk. Has pretty much everything you'll need to know in once place, including how to approach what you're talking about.