Customer obsession

You love your customers. You care about them. You design for them. But, are you truly obsessed, or do you let technology and personal preferences creep into your decisions and communications? I sometimes recognize when my personal agenda is creeping in—it requires real vigilance to keep personal bias in check. To help me stay customer-focused,…


Good engineers

It’s time at Microsoft for midyear career discussions. I’m often asked what makes a good software engineer. I used to think it was writing quality code, as I describe in Nailing the nominals. Good engineers review their software design with peers (that’s right, they think first and consult others), write code and unit tests, ensure…


We’re on the same team

A big organization, like Windows, needs to be aligned and work together to produce a great cohesive product. This means teams talking to each other about dependencies, interfaces, and timelines. That communication is crucial to tying together seamless customer experiences, reducing friction, and delivering value smoothly and efficiently. Unfortunately, humans are lazy, selfish, and suck…


Diamond dependencies

 How can you tell if you’re a smart engineer? What separates people who go through the motions from those who really get it? Second-order effects. Anyone taking an introductory software class can learn what changing a line of code does to a function, but engineers who really understand programming will see the cascading impact of…


Better for everyone

 This month’s column is about accessibility. I’m not making patronizing arguments for it. I’m not saying, “We’ll all need it someday.” I’m not rehashing heartwarming stories of inspiring people who prevail over life’s challenges. I’m not reminding you of your legal obligations. If that’s why you’re following software and hardware accessibility guidelines, then you’ve missed…


Courageous design

 Does this sound familiar? You’re meeting to design a solution to a tricky problem. People are alternating between adding new requirements and deriding prior approaches. Everyone agrees with the issues (“Yeah,” “Yup,” “That’s right”), but no one is suggesting a solution for fear of rebuke. These meetings end one of three ways: Deciding to meet…


Stupid in any language

 Surely you’re smart enough to know that people outside the United States attempt to use Microsoft software every day. I mean, Nadine Kano first published Developing International Software for Windows 95 and Windows NT back in 1995. By now you must be aware, but how can anyone tell? You could try using our software outside…


Data-driven decisions

 You’re working on a feature and think there’s an obvious customer improvement to be made. The tester thinks you’re in obvious need of medical attention from a psychiatric professional. She believes the shipped design was fine from the start. The PM insists that your suggestion doesn’t fit the design language (?). He wants to make…


Software engineering—what’s missing?

 To start the new year, my boss gave an all-hands speech to a large group of developers about being an engineer. He equated being an engineer with taking responsibility for quality and using methods that ensure high quality at checkin (Nailing the nominals). Naturally, a developer in the crowd took issue with calling software developers…


Green fields are full of maggots

As I said in Nailing the nominals, the two keys to successful big projects (100K+ LOC) are thinking ahead and defining done. Thinking ahead is about design and planning. Defining done is about setting a quality bar and sticking to it. Yet many big projects go astray even when people think ahead and define done….