docs.daveops.net

Snippets for yer computer needs

People

Akira Kitamura

Game designer of Mega Man

Interview: http://shmuplations.com/megaman/

Kitamura: Going through all those games taught me something important, though. I started to think that if I focused on more detailed, intricate enemy behavior and placement, then I could probably achieve a better difficulty balance than what action games had offered so far.

Ariga: I think that attitude become one of the key elements of the Mega Man series.

Kitamura: Also, two of my personal goals for Mega Man were to create a game where all the stages could be cleared in an hour, and to make something that players would want to come back to again and again. To that end, I actually calculated the total number of stages by measuring Mega Man’s walking speed and seeing how long it would take to get through each stage. I then split that up so that the first half of the game would be the robot master stages, and the second would be the Wily stages.

Ariga: Whoa! You really did that?

Kitamura: I also created some rules for myself about enemy placement and design.

#1: Single, weak little enemies would appear in “waves” of 3 or 4 individuals (and to the extent possible, I’d avoid mixing up multiple enemies);

#2: they would all use the same attacks;

#3: I would use differences in terrain and enemy placement to adjust the difficulty of a given section;

#4: The difficulty of each enemy in the wave would gradually rise, but the last enemy to appear would be easier.

Kitamura: Making the last enemy encounter in the wave easier was a key idea. It leaves the player with a softer impression of the game’s difficulty. I think the reason that people don’t replay games—even good ones—is that when they remember playing the game, their minds go back to the extremely difficult parts and enemies, and then replaying the game starts to seem like tedious work. I wanted the player to feel like he was improving at the game too, and that was another reason to make that last enemy easier, I think.

These weren’t my only “tricks” for how to get more replayability, but they were some of the big ones.

Players like little secrets

Paul Gibbs

Learning Contract

Reflective Cycle

Alan Perlis

Both knowledge and wisdom extend man’s reach. Knowledge led to computers, wisdom to chopsticks. Unfortunately our association [ACM] is overinvolved with the former. The latter will have to wait for a more sublime day.

Alan Kay

https://www.quora.com/profile/Alan-Kay-11

Xerox PARC Principles

  1. Visions not goals
  2. Fund people not projects — the scientists find the problems not the funders.

    So, for many reasons, you have to have the best researchers.

  3. Problem Finding — not just Problem Solving
  4. Milestones not deadlines
  5. It’s “baseball” not “golf” — batting .350 is very good in a high aspiration

    high risk area. Not getting a hit is not failure but the overhead for getting hits. (As in baseball, an “error” is failing to pull off something that is technically feasible.)

  6. It’s about shaping “computer stuff” to human ends per the vision. Much of

    the time this required the researchers to design and build pretty much everything, including much of the hardware — including a variety of mainframes — and virtually all of the software needed (including OSs and programming languages, etc.). Many of the ARPA researchers were quite fluent in both HW and SW (though usually better at one than the other). This made for a pretty homogeneous computing culture and great synergy in most projects.

  7. The above goes against the commonsense idea that “computer people should not

    try to make their own tools (because of the infinite Turing Tarpit that results)”. The ARPA idea was a second order notion: “if you can make your own tools, HW and SW, then you must!”. The idea was that if you are going to take on big important and new problems then you just have to develop the chops to pull off all needed tools, partly because of what “new” really means, and partly because trying to do workarounds of vendor stuff that is in the wrong paradigm will kill the research thinking.

  8. An important part of the research results are researchers. This extends the

    “baseball” idea to human development. The grad schools, especially, generally admitted people who “seemed interesting” and judgements weren’t made until a few years down the road. Many of the researchers who ultimately solved most of the many problems of personal computing and networking were created by the ARPA community.

Every invention has to be usable by at least 100 people.

Source

Arrogance in computing is measured in nano-Dijkstras’

Brendan Gregg

The USE Method

http://www.brendangregg.com/usemethod.html

Bret Victor

Videos

The Humane Representation of Thought Flat, symbolic representation of ideas (ie printed on paper) is only one facet of expressing thought. We lose our ability to think some thoughts if we express only through this mechanism

Dan J. Bernstein

Dave Thomas

Agile is Dead

Agility - what to do

Agility - how to do it

No rules are universal (except this one)

Francis Bacon

4 idols:

G. Mark Hardy

http://gmark.com

G Mark’s Observations on Life:

Edgar W. Dijkstra

James Bach

Level 0: I overcame obliviousness:

I now realize there is something here to learn.

Level 1: I overcame intimidation:

I feel I can learn this subject or skill. I know enough about it so that I am not intimidated by people who know more than me.

Level 2: I overcame incoherence:

I no longer feel that I’m pretending or hand-waving. I feel reasonably competent to discuss or practice. What I say sounds like what I think I know.

Level 3: I overcame competence:

Now I feel productively self-critical, rather than complacently good enough. I want to take risks, invent, teach, and push myself. I want to be with other enthusiastic students.

Jez Humble

Why Scaling Agile Doesn’t Work

HPPO Method - Highest-Paid Person’s Opinion

Cost of delay needs to be taken into account when comparing projects. Focus on value, not cost.

Users don’t know what they want, but they know what they don’t want when you’ve put it in front of them.

Kent Beck

“Software features that can’t be demonstrated by automated tests simply don’t exist.”

Joel Spolsky

Joe Armstrong

Seven Deadly Sins

  1. Code even you cannot understand a week after you wrote it - no comments
  2. Code with no specifications
  3. Code that is shipped as soon as it runs and before it is beautiful
  4. Code with added features
  5. Code that is very very fast very very very obscure and incorrect
  6. Code that is not beautiful
  7. Code that you wrote without understanding the problem

Martin Fowler

Is High-Quality Software Worth the Cost?

Roger Faulkner

Co-creator of /proc https://thenewstack.io/remembering-roger-faulkner/

Seymour Cray

“What Seymour threw out the window, Les [Davis] would catch.”

I guess I have faith. That’s a little different than confidence. I’ve been well taken care of in my lifetime. God looks after me so to speak and so if you have faith that you’re doing what you’re supposed to be doing, you’re doing the best you can, then as I view it, you can leave the responsibilities for all of the peripheral aspects of life to someone else. So far that’s worked for me.

Steve Yegge

“Old algorithms don’t suck, unless perhaps you count Bubble Sort. Generally, the more tried-and-true an algorithm or data structure is (DFS, BFS, quicksort, binary search, hashing, etc.), the more confidence you have in it. Ideas are fundamental and timeless, but technologies are always replaced.”

Blogs

Ted Nelson

Inventor of Xanadu

Computers for Cynics

Youtube link

Tim Ferriss

DiSSS

CaFE

W. Edward Deming

14 Principles of Management

The “Seven Deadly Diseases of Business”

“A Lesser Category of Obstacles”

Yukihiro Matsumoto

Inventory of Ruby language

“…computers don’t mind if I must make effort to communicate with them or if it is easy to communicate with them. They don’t care if I put the numbers of instruction byte sequences in a file and feed it to them to run, or if a very high level language generated the instructions. The computers don’t care. We humans care about the effort we pay. Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.”

Paul Graham

Hackers and Painters by Paul Graham (book)

The day job to pay the bills, and the fun/beautiful work after hours

“Run upstairs”

When you’re small and nimble, try to get as much technical ground between you and the competition. They’re bigger, so it will take longer for them to reach feature parity. Natural barrier to entry.

“Start by picking a hard problem, and then at every decision point, take the harder choice.”