But the most amazing thing about the web is simple yet devastatingly powerful,
and the whole reason the web exists in the first place. It's the humble
paul is right. however links randomly disappear, move and change.
Despite the pervasive assumption that everything online lasts forever, the
internet is inherently unstable. We assume everything we publish online will be
preserved. But websites are businesses. They get sold, forgotten and broken.
Eventually, someone flips the switch and pulls it all down. Hosting charges are
eliminated, and domain names slip quietly back into the pool. What’s left
behind once the cache clears? For media companies deleting their sites, legacy
doesn’t matter; the work carries no intrinsic value if there is no business
remaining to capitalize on it. I asked if a backup still existed on a server
somewhere. It apparently does; I was invited to purchase it for next to
nothing. I could pay for the hosting, flip the switch on, and all my work would
return. But I’d never really look at it. Then, eventually, I would stop paying
the bills, too.
imagine books disappearing randomly from your bookshelf from time to time.
however, this is a funny thought as it pretends books were always available to
i for myself started archiving outgoing links in the
wayback machine with a zsh snippet like this one. i know
well that this is no real solution to this problem, but i hope it helps. for
Anyway, about the duck. As the story goes, the artists had created all of these
animation cycles for their game, and it had to pass through the review stage of
a project manager. One of the artists knew the way these guys tended to want to
"leave their mark" on things, and did something a little extra. Supposedly, the
PM saw this and said "it's great... just remove the duck". So, the artist went
in and removed the duck (which had been carefully placed to make that easy),
and that was that. The sacrificial duck kept the meddling manager away from the
stuff that was important. It's almost like they want to be able to point at any
given part and say "I'm the reason that happened".
I believe it's actually easy to earn trust as a manager, provided you
understand a few very important things. It's the team who contributes the key,
valuable actions behind great software like writing, reviewing, and designing
code, not you. The people on your team are way better at this than you are,
and they have far more context. As a result, your team's contributions are
much more important than your personal contribution.
Because creating good software is so much about technical decisions and so
little about management process, I believe that there is very little place for
non-technical managers in any software development organisation. If your role
is simply asking for estimates and enforcing the agile rituals: stand-ups,
fortnightly sprints, retrospectives; then you are an impediment rather than an
asset to delivery.
Recent studies have proven that praising a child's effort over the childs
achievements is the correct way to raise a little person that will do well.
"I'm so proud of how hard you worked towards your exam" vs "You’re so clever!
Look how good your exam results were"; the first phrase raises a child that
works hard, the second raises a child that's scared of trying (in case they
disappoint your expectations). The last sentence of the advert is sums it all
up. Lego helps your child discover the most special thing: themselves. From an
advertising point of view, it's almost a masterful game that's been played. The
advert is not saying "Lego is the most important thing there is - GO BUY
LEGO!". It's being submissive to the true nature of things. The child, and its
personal growth, are the most important things in the equation. Lego is not.
It's just there to help with the process
Why do games have such a radically different learning curve than advanced
applications? It turns out that games are carefully tuned machines that hack
into human beings' most fundamental learning processes. Games are exercises in
applied psychology at a level far more nuanced than your typical application.
Implicit in this description of interactivity is the fact that users change.
More importantly, the feedback loops we, as designers, build into our games,
directly change the user's mind... The person that starts using a game is not
the same person that finishes the game. Games and the scaffold of skills atoms
describes in minute detail how and what change occurs. This is a pretty big
philosophical shift from how application design is usually approached. We tend
to imagine that users are static creatures who live an independent and
unchanging existence outside of our applications. We merely need to give them
a static set of pragmatic tools and all will be good. Games state that our job
is to teach, educate and change our users. We lead them on an explicitly
designed journey that leaves them with functioning skills that they could not
have imagined before they started using our application. Our games start off
simple and slowly add complexity. Our apps must adapt along the user's journey
to reflect their changing mental models and advanced skills. Failure to do so
results in a mismatch that results in frustration, boredom and burnout.
a very interesting approach to building applications. it also very much reminds
me of the idea of
it's been almost two years, since i started with the
first edition in this
series. 70 editions, 877 links, 68 videos, 35 papers, 0 unicorns. that's a
lot. unfortunately also a lot for the reader. i repeatedly got the feedback
that each edition was too long, too comprehensive, too many interesting links, no
unicorns (well, actually
therewerea few) and no time to read/watch
and i wanna take this criticism to heart. that is why
edition 70 will be the
last one in this series. but, please don't despair. i've already got plans on
how to continue with a different format. thanks for your time, for your
suggestions, the nice emails and the great advice. hope to see you soon.