tho, the important piece is the network. the network doesn't know or care if random people have a locally downloaded copy of the art. all sites, services, validations, virtual worlds, whatever on the network will hit the ethereum contract which gives up an address which you've proved you own by key signature.
the network can't see nor does it care about your local files.
which means, basically, any other appearance of the art in any other place is just an ad for the current owner of the nft.
it sounds like a lot of the negativity revolves around devops. that's understandable. it's part of a pendulum that swings back and forth. devops and docker as topics aren't really mutually inclusive.
docker, however, is more about the abstraction of complexity stemming from the industry's overall drive toward scalable, distributed applications and development teams. it's more analogous a developer saying, "why do we even use virtual machines?!? bare metal is way faster!"
like movies, games have credits. entertainment products (movies, games, music, books, etc.) have traditionally been about following talent around to find more work by them. we're all basically entertainers.
that, and angry gamers can chase down people to yell at. especially the higher you are in the responsibility chain, the easier you are to find. linkedin makes sure of that. resumes and all that. because, you know, game devs want jobs, too.
this often means game developers don't have the choice to not be derided in public. not unless step one to joining a game team is the switch your entire life to "private". delist your home address. everything. and, i know plenty of devs who've had to. we all shrug and say, "man, that sucks."
because the difference between making games and making boring, insurance middleware? nobody really cares about enterprise middleware as craft. nobody wants to do it, much less thinks they can do it better.
EVERYONE passionately thinks/hopes/wishes/wants to make better games than you.
(. . . well, maybe not everyone, but certainly a whole lotta folks)
we do this at my (very large) company. it's awesome.
the best thing about it? engineers who aren't good at the strategic, human high-touch, or political issues, but excel at execution and implementation aren't managing teams of people -- they're busy executing and getting paid (and further promotions) based on their ability to execute, not on their ability to manage herds of programmers.
as a software engineer, i love that my boss is my boss because he's good at managing teams of software engineers. not because he's the best software engineer in the house.
but yeah, if i happen to still live in this house in 15 years, sure, no electricity bill. and, i'm sure somewhere along the line i'll end up "making all my money back".
this article seems to confuse speed reading with skimming.
i took a full semester class back in high school where all we did was train speed reading. i was able to get to 800 wpm with 90% comprehension on tests. that was from a baseline start of ~150 wpm with 80% comprehension. (the tests afterwards weren't easy "what was the name of bob's dog?" questions)
i've, of course, lost it all in the past 25 years of no practice, but i remember the keys being swallowing entire lines instead of words, achieving "flow", and dropping the subvocalization of what you're reading. (when you pronounce words in your head)
we've had an echo for about a year now and we love it.
by 'we', mean my busy family of four. it acts as everything from shopping lists to homework timers to streaming pandora/spotify to telling jokes -- and more. we easily talk to her (she is basically part of the family) a dozen times a day.
i can totally see how someone who doesn't have all this commotion and such would think it useless. for us tho, it's not useless. it's both fun and functional.
i suspect it's more about lua being a really nice, embeddable scripting language. there's a reason game companies all* use it for content developer scripting languages.
language preferences aside, sometimes it's all about the right tool for the job.
* not literally _all_ of them, but lots and lots and lots.
i mean, what's the layman's description of a rabi cycle? anyone? if someone can lay on me a description my very smart, but non-techy wife would understand, i'll be happy to update the wikipedia entry.
seems like all you have to do is explain quantum physics to a layman first. then (apparently) how a two-state quantum system interacts with an oscillatory driving field and what that has to do with that original layman's explanation of quantum physics.
while this process feels like it's hitting the sweet spot for finding out who can write brilliant code, that's half or less of the battle in hiring people. personally (and as a hiring manager), i feel like a majority of the hiring process is dependent (obviously) on the environment you're hiring into.
hiring for that small startup? you'll want multi-hat wearing people first, brilliant programmers second.
hiring for a large enterprise team? you'll want to hire for "plays well with others" first, and brilliant programmers second.
that's not to say you should hire schleps, for sure. they should at least be competent programmers. i guess what i'm saying is (despite how it sounds), hiring someone who can program brilliantly is important, but not as important as hiring someone who can navigate your company's software-making requirements successfully.
firing the brilliant engineer who thinks he's more talented than everyone else in the small company so he keeps demanding to be put in charge? yup, that's a thing. firing the brilliant engineer who fights tooth-and-nail over some inconsequential feature the product team wants to change? that's a thing too. assigning a brilliant engineer to crap, meaningless work because no one else on the team wants to work with them? yuppers -- seen it.
in any organization, you are either the only one in charge or you're following someone else's orders -- both of which require different aspects around working well with others.
it feels like it's starting to get shaken out. the whole mega-popular digital book thing is enabling wider distribution of formats like novellas.
heck, even sanderson is getting in on the gig with all of his recent success with the shorter novels like "the emperor's soul" or "legion" -- which are both fantastic, btw.
near the beginning of your startup, you need multi-hat-wearing-swiss-army-knives for developers. once you get traction and growth, you need to bring in vertical expertise.
as a parent, the places these buttons would need to be for me are already child-proofed. if it's sitting next to where i keep my laundry detergent, that space is already child-proofed. if it's under the sink next to my bottle of 409, it's already child-proofed.
i would certainly rather have a small bank of interchangeable buttons for the 1/2 dozen items below my sink (dishwasher pods, 408, windex, sponges, trash bags, dish soap) than having to (with wet hands) find my phone/app/screen/button/click. those, of course, would be different than the small bank of buttons near the shelf in the garage. which would be different than the small bank of buttons in the laundry room.
would it make the inside of the sink cabinet door nicer-looking to have an app in my pocket? probably. also, this isn't a zero-sum thing. we can have both!
tho, the important piece is the network. the network doesn't know or care if random people have a locally downloaded copy of the art. all sites, services, validations, virtual worlds, whatever on the network will hit the ethereum contract which gives up an address which you've proved you own by key signature.
the network can't see nor does it care about your local files.
which means, basically, any other appearance of the art in any other place is just an ad for the current owner of the nft.