Andrea Buran’s Site ^5.0

De Bono’s “hat” represents a certain way of perceiving reality. Different people are used to “wearing” one favorite “hat” most of the time, which limits creativity and breeds stereotypes.

The benefits are strong. You understand the big architectural choices before sinking money into building them. You empower designers by giving them space to explore multiple options and do rapid iterations. This leads to huge progress, quickly.

So it’s often better to encourage the behavior you want, than discourage the behavior you don’t. Instead of punishing a player that is too slow, reward a player that finishes the level quickly.

There’s an extremely successful Netflix documentation about decluttering your house—this is directly applicable to software as well. The main essence is that if we did not use something for e.g. three months, it’s not worth keeping it.

But I think there’s a lot of value in actively questioning the need for complexity. Sometimes the smarter way to build things is to try and take some pieces away, rather than add more to it.

Critically missing from the core scrum team, and necessary for the integration of UX design, is a full-time designer on the team. The only way the tactics in #3 can happen in parallel collaboration with developers, product managers, and scrum masters is if there is a full-time designer on the team.

Jeff P advocates for 2 types of work, not 2 teams. The type of work the team is doing fluctuates over time. In some parts of the initiative more discovery is needed. In others, more delivery is needed.

This meant analyzing search trends in order to generate key phrases—everything from “What time is the convention” and “Watch Trump’s speech live” to “How to pick up women”—and assigning those key phrases to a staff of SEO writers, who then reverse-engineered stories around them.

Facebook is such a big distributor of traffic that no news operation can afford to ignore it, but it is not a neutral distributor. It’s a bit like if the paperboy went rogue, decided to put a gun to the temple of a newspaper editor and barked that unless he gets a cut of the sales he’ll pull the trigger.

In other words, clickbait, personalized to my psychological profile, as determined chiefly by an analysis of my online behavior. Anyone who has followed the recommendation engine on YouTube knows that after delivering one or two innocuous videos, the “Up Next” cue serves up increasingly extreme content. The algorithms push us to become caricatures of ourselves. They don’t merely predict our behavior; they shape it.

Facebook et al. became the primary sources of news and the primary destroyers of news. And they refused to deal with it because their business is predicated on the fallacy that technology is neutral—Silicon Valley’s version of “guns don’t kill people”.

As you can see, an important rule of thumb is to personalize around the main content, not the entire page. There are a variety of reasons for this, including the risk of getting the audience wrong, effects on search indexing, and what’s known as the infinite content problem, i.e., can you realistically create content for every single audience on every single component? (Hint: no.)

In order to successfully model content, we must create content environments that stand up to the pressures of production.

Another exercise is asking the question, “What is the evil version of this feature?” Ask it during the ideation phase. Ask it as part of acceptance criteria. Heck, ask it over lunch. I honestly don’t care when, so long as the question is actually raised.

Error rates climb with hours worked and especially with loss of sleep. Eventually the odds catch up with you, and catastrophe occurs. When schedules are tight and budgets are big, is this a risk you can really afford to take?

So, people tend to underestimate two crucial things about content: how much content they need, and how long content takes to write.

The starting point is realizing that working long hours makes you a much less productive employee, to the point that your total output will actually decrease […].

If there is a should, there is a way to get out of it. It is an excuse for missing commitment. Real change starts with the burden that I am indeed responsible for the change. If I only believe that I should do it, is not important enough for me. If it would be I would do it. If it would be important for all of us, we would all do it together.

[…] we look at best practices, analyze the competition, and then, often, we take a copycat approach to building our product. We think that if it’s working for them, it’s got to work for us too. The problem? It frequently doesn’t—at least not the way we think it will.

I love how David Allen says that you can do anything you want but you can’t do everything you want. And that is an extremely liberating mindset.

Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.

Metrics are a horrible way to understand customer intent. Great way: customer interviews.

But: we bias our people, when we ask them. Even if we try not to.

Reason: we believe our own bullshit.

Being the one poor soul remote in a co-located team is hard… you have “5x” the process needs… People will continuously forget to involve you in discussions or decisions, you will be the person not knowing what is happening why—you will suffer.

Like many modern workers, I find that only a small percentage of my job is now actually doing my job. The rest is performing a million acts of unpaid micro-labor that can easily add up to a full-time job in itself. Tweeting and sharing and schmoozing and blogging.

When companies just build it, just ship it, iterate on it, and build and ship again, this means that customers are seeing a variety of versions. They are seeing the work in progress and watching the sausage being made. This is often a frustrating and confusing experience requiring customers to keep relearning a system that’s evolving.

One of the most common questions I get from people is why I use [some older technique or tool] over [some newer technique or tool] […]. The technologies, tools, and techniques don’t matter. The answer is always the same.

Because it does what I need and I already know how to use it.