Ankintol
A key finding is that people are not creative generally but are instead creative relative to their skills.
e.g. if you are not a skilled programmer your programming is very unlikely to be creative except insofar as it relates to a non-programming skill that you have acquired.
This suggests that most creative solutions will come from people who learn many things. You'd expect people with high IQ and conscientiousness (implies being organized and driven) to be the most creative group. This lines up with the best evidence I've found, and anecdotally matched my experiences as an educator and continues to as a software developer.
I think this may also explain your own experiences. The model predicts that a smart person who learns a lot less about a topic than their less smart peer would be less creative thinking the topic.
[0]: https://www.amazon.com/Cognitive-Explorations-Instructional-...
A thought I should have fleshed out in the above post: the kind of sensor data that enables AR can also be used to deduce a great deal of personal information[0]. With Apple taking a strong position on privacy I suspect they will make only a limited subset of data available to developers.
[0]: https://www.researchgate.net/publication/332386880_Privacy_I...
My own prediction, using many of the same data points as the author, is that Apple is trying to create a suite of features that act as a sort of Software Personal Assistant. For years Apple has consistently put in better sensors and larger TPUs than strictly necessary for the expected lifetime of the device. We're already seeing some of the results of this with the Health app.
Apple understands the profit potential of platforms, so they'll make some of the data that enables these features to App Developers and that in turn may enable AR, but I doubt any Apple executives are seriously focused on bringing AR capabilities to developers.
The problem is that even amongst "serious" programmers people often have a patchwork of knowledge with small, unpredictable gaps in understanding; many of which will surprise you. You will find these gaps even if you've taken the time to handpick vetted experts. Once you account for this patchwork of knowledge gaps in verified experts you'll often notice that you're really close to a tutorial for relative beginners, which most people are, and just go the full distance.
The problem generalizes to a variety of subjects but is particularly pernicious in programming where small details are often of much greater significance.
Best of luck.
I'm confused that you think this is something I can prove through citations. The way we adjudicate whether someone is a victim is through the courts, my claim is the courts do a bad job of this. There are only two things I can think to poinnt you at:
1. The numerous written accounts online of women attempting to get justice and being stonewalled. Some of the more famous cases during the beginning of the #metoo era showed this.
2. I can say that the lived experience of every woman I know to have gone through the courts found it unnecessarily degrading (n~=20) and while I believe all of them, only a quarter (n~=5) received a guilty verdict. I know far more women who did not go through the process due to stories from women they know.
I'm personally convinced, if you're not I understand but am not ready to expend the energy digging up cases to try and convince you.
> can you clarify what you mean by "verbally insulting and degrading them"
Literal slurs, misogynistic generalizations about women being temptresses, stereotypically horrible questions such as "were you asking for it?"
Even for fairly straightforward sexual assault case in a liberal jurisdiction with witnesses I've watched a friend struggle with members of the justice system verbally insulting and degrading them as they try to obtain justice for themselves.
Having seen all that when I see a post like this I understand why the author did not go to court, and don't question it. If we took the time to actually fix the courts I'd be much more skeptical of claims that had not been presented to law enforcement.
I feel for people like your brother who are victims of people abusing the trend, but as long as our justice system fails victims so horribly I think this is the least bad solution available.
Software developers are able to build abstractions out of thin air and put them out into the world incredibly quickly. The value proposition of some of these abstractions are big enough that it enables _other_ value propositions. The result of that is that our "materials" are often new, poorly documented, and poorly understood. Certainly my experience writing software is that I am asked to interact with large abstractions that are only a few years old.
Conversely, when I sit in a meeting with a bunch of very senior mechanical engineers every one of them has memorized all of the relevant properties of every building material they might want to use for some project: steel, concrete, etc. Because it's so static, knowing them is table stakes.
I'd say this difference in changing "materials" is a big source of this discrepancy.
thing_1_a
thing_1_b
thing_1_c
thing_2_a
thing_2_b
> When people acquire skills, and that makes some tasks easier compared to untrained people, that difference categorically is not subjectivity. It is not subjectivity because we can reproduce the training effect in person after person, and even measure it with some kind of numbers that we can plot on nice graphs and see things like that similar "learning curves" are consistently reproduced in different people.
It sounds like you're referring to convention. Adhering to conventions a reader is familiar with definitely improves readability, but _any_ style can be improved by adherence to convention, so we want to ask, what is the most readable style before we start layering on conventions?
Is it elegant? OO couples data types to the functions that operate on them. After years of working on production OO I've still never come across a scenario where I wouldn't have been equally or better served by a module system that lets me co-locate the type with the most common operations on that type with all the auto-complete I want:
//type
MyModule {
type t = ...
func foo = ...
func bar = ...
}
3 is likely to be a sticking point however. Once you have responsibility for large projects you are often in a certain amount of resource contention, the chance of avoiding political battles there is small unless you are a known superstar within the company.
If you're ok with that, I'd prepare for a whiteboard interview at one of the big well-paying tech companies.
For several years I've been writing a large computer algebra system(CAS) that runs on a webpage. Every time the user puts some input into a text box the CAS runs. Depending on the input it may run as many as ~40k lines of code. There are no coherent lines upon which to split the CAS as far as anyone developing it can tell.
The CAS must run on the browser both to deliver on real time performance requirements and to keep server costs manageable (certain inputs will get even high end CPUs humming).
If breaking this SPA up is possible, it's not apparent even to engineers with >10 years of experience developing highly complex applications.
Other similarly complex applications run on the web, even if it's unusual.
Most websites are what I'd call "broad and shallow". For any individual action the corresponding code path is small. Most code in these sites is easy to write and easy to debug in vanilla JS. Typescript adds boilerplate and compiler times for type safety the development team was doing fine without.
However there are some sites, usually very complex SPAs, that are necessarily "deep". Even small user actions absolutely must cause >10k lines of code to run. Type systems are often very valuable for the development of such sites.
It's my experience that some developers who've only ever worked on "broad and shallow" sites fail to appreciate what a time saver a type system can be for the right "deep" website.