it seems the bar should be that high as that is what the hype has told us we would be getting.
I'm OK with it being as good as the hype ...and when it isn't the companies that write the software and build the cars can pay for the damage
hmm... so, yeah, nothing about 1000 true fans theory points to it being an easy path. Making a living as some sort of creator is hard. The platforms & "the internet (tm)" just provide a plausible access to those fans vs old-media mechanisms.
I watch many youtube channels with 100Ks of subscribers. Those creators are not out there spending resources getting an audience and those audiences are not coming from personal connections - the platforms are facilitating the connection.
Re : how "attempting to work in the art world" works : this is a very interesting subject/discussion - at what point is someone regularly publishing entertaining youtube videos about small engine repair "working in the art world"? When they get enough income to quit their day job or some lower bar - I dunno - both ? neither / never?
Re stardom: what you're saying is 1000 true fans != total number of fans/casual followers. Agreed.
so, I've been near sea lions on the Oregon coast - the males can be large and many 100s of pounds (bigger than actual Lions!) and rather intimidating.
This picture of the whale's mouth with a sea lion in it really puts into perspective how big the whale is.
I've read the cliff-notes version of first break all the rules. (its floating around the web).
It has the list - and also interesting discussion of talent and having employees in positions where their talents are used.
IIRC - it also suggests never trying to change people - which I've taken to heart in both work and personal aspects of my life.
I have two Australian shepherds - One of them was a puppy when I read the book about Chaser. So I decide to try to sort-of reproduce some of the author's experiments with my dog - and I'll be damned if it didn't work.
I didn't go to near the extent of the training John Pilley did with Chaser, but I did do the verbal only approach and put the toys in another room - and I was able to teach him to retrieve probably 5 or 10 toys by name. I was really amazed. I didn't do nearly as much training with the second Aussie - but she picked up on the whole game even quicker than the first dog (because she had a role model?).
Another thing I learned about this game/training : it really wears the dog out. After 20 or so minutes of playing "go find the toy" they dogs lay down for a nap.
(ps. doing "nose-work" games with dogs also wears them out)
I'm really glad this is coming back - I've bought it several times over the years and really enjoyed flying it. In more recent versions using the ATC and trying to make it as realistic as possible experience - flying around between nearby local airports.
>"If we could get more of them doing it, it would be great," he joked.
>Karisoke's Vecellio, though, said actively instructing the apes would be against the center's ethos.
>"No we can't teach them," she said. "We try as much as we can to not interfere with the gorillas. We don't want to affect their natural behavior."
I wonder if this "prime-directive" style rule might be something they consider changed - if there was a way to teach the gorillas to disabled various kinds of traps it seems that would be great.
On the other hand, I wonder what the side effects would be.. anyone?
Two things I've learned about deadlines
#1 - never get into a fight with a superior about a deadline - think of the princess bride quote about land wars in asia.
Which brings us to #2 : look at them relative to what's important to your business. Much of the time a deadline isn't really a deadline at all - its a point in time to show progress in the right direction. With that in mind, i might say to the team - "what's important to this business is _______ , so lets be sure to highlight our progress on items a/b/c because they're key to ______. ..all this other shit in the backlog is #2 .. n that Alice and Bob want. Alice and Bob will get their shit when we get the important shit done (which might be never) [0]
What direction is important to the business? Well, hopefully the direction of solving a problem or delivering a widget to someone who is waiting to actually use it and hand over $ in exchange. If its something else its often your deadline playing chicken with someone else's deadline on the gantt chart and then its the old joke about two guys running away from a bear.
[0] Alice and Bob will get their shit when they start contributing items to the backlog that are aligned with what is important with the business.
EDIT: deadlines aren't inherently "bad" - especially when one is competing against others for something. The problem is too many points in time are made to look like deadlines and often by the wrong people. Imagine running a marathon, and someone is yelling at you from the sidelines : "run as fast as you can to the 4 mile mark!"
different problems here - if the production and scale are already well known and understood - there are, arguably only design choices to be made that fit into the existing tooling.
"the new chair model must fit into these production constraints"
"the new software must be written to fit into this system - JVM based, web interface ..."
> These languages are very powerful, but they don’t scale.
The problem, it seems to me is that software developers often think: "what programming language do we really like && can continue to use for $long_time over $scaling_of_business".
When this is the case, business management expectation problems emerge regarding costs, maintenance and timing when the business scales by 10 or 100x. Early phase teams are lambasted for making poor decisions - and "adult supervision" ( i hate that term ) is hired to "fix things".
Thing is, the early "poor decisions" may not have been poor decisions at all relative to the business needs. However, since costs and retooling issues weren't discussed and planned for - the early team look like a bunch of fools/amateurs.
As software developers, we need to understand and communicate that the tools can we use to accomplish the needs for the business at one stage are different than those of a later high-scale stage. its OK, completely natural, and a requirement if we want to keep our jobs and grow with the business.
analogy:
If a specialty carpenter is designing and building high end furniture with a set of well made brand-name niche tools and techniques they wouldn't expect that those same tools would be used if sales take off and 10x or 100x the number of units need to be produced. It would be understood that retooling would be required, people with expertise in those tools be hire and that there would be new costs involved. Also, the carpenter who starts the business with small scale tools isn't lambasted for being an idiot for picking those tools in the early phases. It would be quite odd to suggest that that person have picked tools and hired people for 100x production when they were selling single digit units a year.
that's really cool.
We do "nose work" with our dogs just as a game for them. Its super fun to watch them find treats and toys we hide for them.
What I was most surprised about when we started is how the game sort of wears them out almost like a good run at the park. (we have 2 aussies and 2 silken wind hounds)
i have two Aussies - they're great and super smart.
after reading the book "chaser" - I trained one of them to distinguish several toys by name similar to what he had done in the book. it was a lot of fun and now he's always bringing me toys to play with. Interestingly he brings them at very specific times of the day when I'm most likely to play with him: morning while making coffee, and evening while cleaning up the kitchen.
this a great response to so many situations. avoiding sugar coating turds and fubaridness is key to being a good boss. Acknowledge the fubar situation - let the team chime in - then get back to facts and actions.
Corollary (to the whole article): act/do the way you expect others to act/do in a small set of areas that are very important to you.
I've often seen leaders/managers get upset about the little shit while not acting the way they expect others to act in the areas they care about.
My step dad and a few bosses I've had over the years are great at this; they jump in and start doing the work and its amazing to see others jump right in along side them. Also, and this is key: they jump in and work along side their own reports who are doing the right things (this is a powerful message to a team).
One boss and mentor (and now a good friend) - would write documents/presentations and share them with an employee: "hey, I'm doing this presentation to _______ , check it out. I'd like you to ramp up and next month take it over. I'll be happy to help if required"
One time, some people were arguing one day about how to test some software and hardware. Boss observes the argument and comes in the next day with a little circuit board he made to help complete the tests. The model within the team from then on was often "hey I built this thing to help with the _____ ..what do you think, will this help?"
Another example, eng boss in a standup : "hey, I like how you did that thing with ____ in the code, I'm going to fork that and try an experiment".
Comes back a few days later "hey check out this branch.. its a way to do _____; You can see what I'm getting at - and maybe figure out how something like this can work in the main codebase ..food for thought".
for that case - rather than resort to the debugger - I've always went through the code, come up with a theory of operation and then and instrumented it with either print statements or a scoreboard style struct in some shared mem to validate.