I. M. Wright’s “Hard Code”

An opinion column for developers.Brutally honest, no pulled punches.
Posts
  • I. M. Wright’s “Hard Code”

    Debt and investment

    • 5 Comments
    We all have friends or relatives with money problems. There are three sources of those problems: a lack of income, a catastrophe, or a lack of self-control. There are whole industries devoted to solving the income issue—I’m not going to cover...
  • I. M. Wright’s “Hard Code”

    Evil assumptions

    • 1 Comments
    You work on big, important projects that involve many moving parts and many different teams. You work hard to deliver your piece on time and with high quality. No one can claim that you’re the one who held things up. No, it’s always those...
  • I. M. Wright’s “Hard Code”

    You can't have it all

    • 0 Comments
    There are two executive planning strategies: go for it all (cut later), and do a few things well (add later). Executives follow the strategy that best reflects their belief system. They use that planning strategy to drive work throughout the product cycle...
  • I. M. Wright’s “Hard Code”

    Fixing five fundamental flaws

    • 7 Comments
    After decades as a professional software engineer, working for six different firms (large and small), I can honestly say that Microsoft is by far the best. I can also honestly say that Microsoft is far from perfect. My monthly rants typically focus...
  • I. M. Wright’s “Hard Code”

    Is it important?

    • 0 Comments
    We’re getting into the midyear career discussion period at Microsoft. People do appreciate a career discussion with their manager, but most folks have another topic on their mind—how am I doing? Look, it’s not a mystery—you should...
  • I. M. Wright’s “Hard Code”

    Taking over

    • 1 Comments
    There are many books and lecture series about creating high-performing teams that work well together, work hard for each other, and produce tremendous results. That’s nice. In real life, you, the manager, don’t get to create high-performing...
  • I. M. Wright’s “Hard Code”

    Collaboration cache—colocation

    • 7 Comments
    Software geeks know that registers fetch data roughly 10 times faster than the L2 cache, 100 times faster than main memory, and more than a million times faster than hard drives. Smart software engineers work hard to keep all the data for their inner...
  • I. M. Wright’s “Hard Code”

    Data-driven decisions

    • 2 Comments
    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...
  • I. M. Wright’s “Hard Code”

    The new Microsoft

    • 0 Comments
    The Microsoft Company Meeting was a few weeks ago. If you love the tech status quo inside or outside of Microsoft, seek shelter. How the company operates and how it engages with customers and the markets is about to change. All the signs were there in...
  • I. M. Wright’s “Hard Code”

    It’s not going to be okay

    • 7 Comments
    Eric Aside This month I cover a touchy subject—getting a 4 or 5 review rating. Please know that all opinions expressed in this column (and every Hard Code column) are my own and do not represent Microsoft in any official or unofficial capacity...
  • I. M. Wright’s “Hard Code”

    Too much of a good thing? Enter Kanban

    • 1 Comments
    Last month, I wrote about the value of good program managers (PMs). Some people liked the column (mostly PMs). Some people hated it (folks with bad PMs). However, the most common response was that Microsoft has too many PMs. Can you have too much of a...
  • I. M. Wright’s “Hard Code”

    PM: Secret weapon or wasted headcount?

    • 9 Comments
    Microsoft is one of the few software companies that uses program managers (PMs). PMs, developers, and testers form the infamous engineering triad. Together they prioritize and cost features, triage bugs, and make design decisions. Now that highly agile...
  • I. M. Wright’s “Hard Code”

    Permanently high plateau

    • 0 Comments
    A friend asked me recently about one of his reports. He had a few concerns going into annual review calibration. His employee was a smart, strong, consistent contributor, well beyond entry level and independence (see Level up for reference), but he had...
  • I. M. Wright’s “Hard Code”

    Hired helpers

    • 3 Comments
    There are never enough resources to complete our ambitious plans, so Microsoft is constantly hiring help—vendors and contingent staff (CSG). Full-time employees (FTEs) are hired too, but the relationship is different—at least it’s supposed...
  • I. M. Wright’s “Hard Code”

    Don’t be a tool

    • 4 Comments
    A recent flood of build breaks triggered a wave of tool suggestions to plug the cracks in our code. Some argued for faster builds. Some argued for deeper branching. Some argued for a “gauntlet” service that simulates official builds and blocks...
  • I. M. Wright’s “Hard Code”

    Out of focus

    • 0 Comments
    Are you sensing a rush coming as we complete midyear career discussions at Microsoft and head into the stretch toward annual reviews? Worried about keeping up with your peers when you already have far too much to do and far too little time in which to...
  • I. M. Wright’s “Hard Code”

    Software engineering—what’s missing?

    • 6 Comments
    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...
  • I. M. Wright’s “Hard Code”

    Who’s in charge here?

    • 0 Comments
    I was talking with a friend from another Microsoft division. He complained about gridlock on his team because “no one can make a decision.” He lamented, “We discuss issues and come to some conclusions, but rarely get a resolution that...
  • I. M. Wright’s “Hard Code”

    That's not funny

    • 0 Comments
    Tension fills the conference room a few weeks before the Client release. The Client team wasn’t told that the Database team had added a parameter to the AddClient API. The Client broke spectacularly—the latest in a series of miscommunication...
  • I. M. Wright’s “Hard Code”

    Destabilization

    • 1 Comments
    It breaks my heart and sickens my stomach to witness the tremendous productivity and quality gains of Lean Software Development practices at Microsoft: feature crews in Office, scrum teams in Xbox, and improvement teams in SQLServer, to name a few. These...
  • I. M. Wright’s “Hard Code”

    Master of your domain

    • 0 Comments
    If you had to choose between hiring an outstanding candidate with only related domain knowledge and a solid candidate with specific domain knowledge, who would you select? At Microsoft, we generally select the outstanding candidate, figuring a talented...
  • I. M. Wright’s “Hard Code”

    Production is a mixed blessing

    • 1 Comments
    There is one service design flaw that engineers repeat day after day, month after month, year after year. Scalability? Nope, though it’s popular. Security? Happens, but not that frequently. Serviceability? Getting warmer. Give up? Don’t care...
  • I. M. Wright’s “Hard Code”

    A change would do you good

    • 5 Comments
    Few Microsoft engineers change positions between mid-May and mid-August—they don’t want a role change to adversely impact their annual performance ratings, which lock around mid-August. Of course, managers shouldn’t allow position changes...
  • I. M. Wright’s “Hard Code”

    Out of calibration

    • 8 Comments
    It’s calibration time at Microsoft. Time for managers to rank everyone in your peer group (same discipline, same career stage, same division) into five (and a half) ranges: the top 20 percent (and top 5 percent), the near top 20 percent, the middle...
  • I. M. Wright’s “Hard Code”

    Quality is in the eye of the customer

    • 3 Comments
    Not every bug is the same. A bug that frequently freezes an app gets more attention than an extra line of green pixels in a border. An embarrassing typo in a prominent feature is more urgent to fix than an inappropriate exception thrown by a misused API...
Page 2 of 4 (97 items) 1234