For me and for Tony, this clip is extremely reassuring. If Miyazaki — the world’s greatest living animator — can admit defeat after trying his best, then it’s okay for everyone else. If he can let go, then so can we.
If you know you have a meeting in an hour, do you start your deepest, most complex problem solving work? I’d venture to guess most people don’t. I certainly don’t.
Notice how these colors do not seem ‘natural’ per se, but are chosen to convey the taste of the product.
[…] Debt is acquired by building for the short-term. Design debt is made up of an overabundance of non-reusable and inconsistent styles and conventions, and the interest is the impossible task of maintaining them.
I wish I had more comforting words for you, but all I can say is that most things worth doing are a struggle.
Fail fast. Iterate quickly. Prototype. Prototype. Prototype. And cut. Cut scope until it hurts.
Failure is a good thing if you plan for it. Failure can teach you lessons that no success will ever teach you […]
If you’re describing what a function does and you have to use the word “and,” that function is probably too complex. What a function does should be simple enough to explain with only a descriptive function name and descriptive arguments.
Tell everyone you’re working on this project to make sure that there isn’t anything you overlooked.
Values aren’t what’s printed on the wall or in the employee handbook, but the interactions that happen every day. The values stem from the top, are reinforced by each employee, and determine how the company works.
Solutions based on this knowledge can help you to give users what they need, rather than what they say they want.
[…] software patents are actually preventing the adoption of new technology, rather than encouraging it.
Your job is not to stop your mentee from making any mistakes; it’s to stop them from making the same mistakes over and over.
[…] it’s confusing because I don’t think pictorially, I’ve done it grammatically […]
A difficult client who demonstrates trust issues right from the beginning of the business relationship and shows an inability to compromise might be more trouble than they are worth.
Yes, I have regrets, but as soon as you start rewriting your past you realize how your failures and mistakes are what define you.
After reading that, do you still want to include open source work in your project? Will it derail your purpose and goal?
What has changed in the last generation is that companies today view more and more of the labor it takes to produce their goods and services as akin to staplers: something to be procured at the time and place needed for the lowest price possible.
When an organization tries to maximize inputs, rather than outputs, the result is a whole series of bad judgments.
Exhaustion isn’t cured over a weekend (or even a long weekend). It requires a recalibration of priorities, tasks, life goals and even life purpose.
[…] it is important to distinguish between ‘state’ and ‘act.’ The state of something in UX is fundamentally static, like a design comp. The act of something in UX is fundamentally temporal, and motion based.
[…] there are three levels of consistency: individual, collective, and institutional.
If a project calls for SVG and a designer has been tasked with creating illustrations and providing design assets for development, then the designer is no longer handing over a static file, but a snippet of code […].
Being a senior developer doesn’t mean you have to know everything, it means you can help find out anything.
Effective retrospectives require a commitment to maintain an open mind and open communication with your team, as well as a willingness to be vulnerable.
[…] we primarily use animation in three ways—to indicate a state change, to add an emphasis, or to reveal extra information
A common pitfall is to define your goals in terms of your existing metrics—“well, our goal is to increase traffic to our site.” Yes, everyone wants to do that, but how will user-experience improvements help?
Trust keeps a relationship going, but you need the knowledge of possible future repeat interactions before trust can evolve.
When you’ve been set up to fail, your primary goal is to demonstrate that the inevitable failure was not your fault.
Focusing on coding inflates the importance of finding the “right” method to solve a problem rather than the importance of understanding the problem.
What advice does anyone have for me?
I tend to finish a presentation with some questions of my own. I ask whether they feel the project will achieve its desired goals, meet the needs of users and fulfil organisational objectives.
Audrey, you’re missing a really important step. I think you need to just listen to them.
Uber is far from alone among technology giants in using machine learning systems to attempt to profile its users at a granular level to find the activity and users that stick out as abnormal.
If you use a group chat tool, there’s only one way to find out if the unread number is relevant: You have to click through and read everything just to figure out if there was anything worth reading. That’s the very definition of wasting time.
You want insights, not numbers. You want truth, not graphs.
[…] and the ball went for being like a stupid tennis ball to a motherfucking comet or something.
Understanding what you can afford to build—how much runway you have and how long you really want to work on a single project—is crucial to making it to the finish line.
[…] First, data is just information and alone does not represent objective reality. Next, whatever data you have is never, ever complete, and finally, getting more data does not necessarily mean more clarity.
Create harmony in your environment by sticking to a coherent shape language. You can then create focal points by using dissonance, which is the breaking up of the environment’s shape language.
Actually, sometimes a cancelled project is something you should be proud of. Regardless of the talent of the team, if you can’t reach a compelling first playable, it’s time to kill the project and move on.
Don’t fall into the trap of assuming your players will find gathering collectibles as interesting as you find placing them. While alternating the pace of your action is good, having your player travel for long stretches, no matter how much beautiful art she looks at, is just boring.
Underlying your need to micromanage is a fear of failure. By magnifying the risk of failure, your employees engage in “learned helplessness” where they start believing that the only way they can perform is if you micromanage them.
You can’t leave home to rebuild that feeling again somewhere else. You dilute that feeling. It’s what Voldemort did with his soul: he split it up into parts, and it could never be whole again.
The form — in its many manifestations — provides a gateway for user submission.
[…] and what we’re left with for the most part is a polished UI that can’t quite stand toe-to-toe with the world it’s framing.
Start early. […] Talk preparation will expand to fill all available time. […] It will take a lot of time to do your talk, way more than you think.
One method that I use for characterizing the relative size of development tasks is a variation of the tee-shirt sizing method. Each task is given a relative size corresponding to five tee-shirt sizes […] XS: Half day or less S: Half day to one day M: Two to three days L: One week XL: One to two weeks.