Joe Duffy's Software Leadership Series

Table of Contents

1 A few thoughts on the role of software architects

An architect’s success is measured by what he or she ships to customers, and notby the amazing ideas that were ultimately never realized. This necessarily means an architect’s success is deeply rooted in the team’s culture, work ethic,and ability. He or she needs to work through others to get things done.

You can’t do it all yourself. This can be frustrating at times, and at times you might think that you can (particularly in times of frustration). I’ve personally hacked together 1,000s of lines of code that I’m incredibly proud of in a weekend, and that would have taken weeks or months to get done if I had to instead explain the idea to somebody else and wait for them to write those same 1,000s of lines of code. And the 1,000s of lines they write of course wouldn’t end up being the same as the ones you’d have written. And they may decide thatthey don’t like the design after all, start discussing it with colleagues, stagea mutiny, and ultimately overthrow what once seemed like a great idea. Thisis a tough pill to swallow. But it’s a sad fact of life that you need tolearn to be comfortable with.(要习惯放权和让他们来独立完成工作,即便这个工作最后和你想象的有点不同)

Architects should also welcome all ideas with open arms. You want to fosteran open and energetic environment on your team, where intellectual debate is thenorm. All ideas are fair game. That’s not to say all ideas are good ones, and ultimately the bad ones need to die a quick and painless death before going too far, but an architect who won’teven entertain new ideas from the team (typically because of NIH syndrome (i.e.,Not Invented Here)) often drive away the best engineers. Great engineers hateto be told what to do. They don’t want to feel like they are walking in theshadows of somebody else. They want to use the skills that make them so great,which involves inventing bigger, badder, and more impactful designs.(对团队所有的想法都持开放太多)

Left to its own devices, the team would veer off course in no time. That’snot because of malicious intent, but rather because of the sheer diversity of softwareengineers. This diversity is present on many levels: in skill level, taste(which is hard to measure: more on that in #2 below), motivation, work ethic, interpretationof the vision, personal beliefs and experience, and so on. An architect actsas a low-pass signal filter, smoothing out any irregularities that deviate too farfrom the core design principles.(团队可能会因为分歧太多而偏离方向,这时候架构师应该做一个低通信号过滤器,将某些过大的分歧解决掉,确保不会偏离方向太多)

Sadly, this responsibility often entails being “the bad guy”. Sometimesyou need to mercilessly kill an idea because it would put certain parts of the projectat risk. Other times you need to let somewhat bad (but not too impactful) ideasgo. There’s a tradeoff here, because each time you kill an idea you’regoing to leave somebody feeling burned. And you may waste peoples’ time,depending on how much time has already been invested in that idea. Some battlesare best left unfought. There is an art to be learned here: if you can getthose with the idea to firmly believe that there has to be a better way, you canavoid being seen as the bad guy. “Sit back and wait” can work in some cases,but it can backfire too.(否定团队提议太多会招来很多骂名,造成一些人离开,但是有时候为了确保目标一致不得不这么做)

The deep involvement in the technical design details unfortunately means that thearchitect can become the bottleneck if he or she is not careful. This can slowthe team down. Some slowdown can admittedly be a good thing, because it hasthe effect of forcing more thoughtfulness in each and every decision.(有时候你自己还会成为团队的瓶颈)

But there is one common trait that, as far as I can tell,is impossible to measure, and yet common to all of the great software architectsI know: good taste. And because it’s impossible to measure, those who lackit have a hard time understanding the difference between a design with good tasteand one with bad taste.

I’m not certain where taste comes from: an innate skill? Perhaps, but notexclusively. In my best estimation, good taste can be learned from paying closeattention to the right things, taking a step back and viewing designs from afar oftenenough, being learned in what kinds of software has been built and was successfulin the past, and having a true love of the code. That last part sounds cheesy,but is true enough to reemphasize: if you don’t feel a certain passion for yourcode and project, it’s a lot easier to let bad taste run rampant, because yourcare level isn’t as intense as it needs to be.(品味是件非常神秘并且难以量化的东西,但是在项目进行中大家又能逐渐感觉到。只有不断地做正确的事情,或者说不断地犯错直到做对,才能学习到品味)

Writing code also has the benefit of ensuring that you maintain credibility withthe team. It’s easy to dictate crazy and grandiose ideas, but if you’rethe one who has to implement such a grandiose idea, you’re apt to be more sympatheticwith and mindful of the other engineers of the team. You need to keep yourselfgrounded and writing real product code will help to ensure your technical decisionmaking carefully considers the implementability and down-to-Earth ramifications ofyour decisions.

It can be particularly disturbing to realize that a large number of people have beengoing off in the wrong direction on your watch. Yes, you wasted their time.But you have to learn what went wrong, internalize it, and commit to never makingthe same mistake twice. You owe it to them to respond promptly. Everybodyon the team will have learned and grown from the circumstances, and if you’re luckythe situation is salvageable. Sometimes it won’t be. But in any caseyou will gain the respect of many around you by making the right decision; particularlyif you’re the only person with the broad technical responsibility, understanding,and insight necessary to make such a decision, people will feel relieved when youmake it. And if you don’t make it, people will curse you for it.(用于承认自己的失败,从失败中学习经验教训)

Beingan architect, in the end, is all about helping others to succeed. If you’rea really good architect, you’ll inspire people and rub off on them. You’llgain a certain level of respect that is unmistakable and priceless. And that,in my opinion, is far more fulfilling than anything you could accomplish on yourown working in a vacuum.(你会因为帮助别人成功而获得尊敬,相比自己独自完成一些事情更加有满足感)

2 Code Speaks; Love the Code


Pick somebody in software that has done great things. Bill Gates comes to mind forme, because that’s who inspired me to get started in software. He wrote code foras long as he could manage, and famously delivered code reviews even as his companygrew to 1,000s of engineers. No matter who you pick, I am sure one thing rings true:they obsessed over the details. And when it comes to software, those details arein the code.

Those who cannot read and write code must spend all of their time convincing otherpeople of their ideas, and are usually sufficiently disconnected from reality (i.e.,the code) that their ideas do not work in practice. This is an awful situation tobe in, particularly at a company whose primary asset is code. Worse, most peoplevoluntarily place themselves into this category, particularly over time in theircareers, because they believe that coding is “not one of their job responsibilities.”What rubbish!

Even those that write code often don’t do it enough. I’ve seen so many fall intothe trap of debating whether or not something would work, or how elegant it wouldbe. Certain people are afraid of failure, or find it difficult to get motivated to“start” coding. The best people, however, realize that questions are easily answeredby writing the code in prototype form. They go from 0-60 in an instant, having avision of what they would like to build, and letting nothing get in the way. I callthis “oozing code from your fingertips.” I do think some of this is a skillset thing.In software, the top 20% are easily 50X more productive than the bottom 20%. ButI also think these traits can be learned, given role models who exhibit and demonstratethe behavior. (快速Prototype是一种非常高级的本领)

3 Authority is an Illusion


反抗权威也是有风险的,最好的策略或许是,在一个无关面子和具体利益的场景下讨论各种可能情况, 但是在公开场合,做一个老好人?

When starting a new job, it’s natural to be in what I call “understanding and assessment”mode. In fact, coming into a new job and telling everybody how they are doing thingswrong is a recipe to not only get you off on the wrong foot, but also permanentlypoison your relationship with what would have been very important allies down theroad. However, it’s critical to turn the corner at some point before it’s too late.The more experience you have, the less time it should take.

However, I was pulled aside afterwards and told how stupid a move thatwas. And what’s worse, I actually listened for my first two years and went out ofmy way not to rock the boat too much. This was against my better judgment. I wasstill young, and had come from another job where I was confident and could safelyquestion anything; but I made the silly mistake of thinking “well, maybe things aredifferent around here.” I still wish I could get those two years back.

Allow me to let you in on a little secret. (Well, okay, it’s not really a secret,but if only I could go back and tell my younger self this. And I suppose it oughtto be obvious.) These people don’t always know what is going on. It’s probably safeto assume that these people have been rewarded in their careers because, statisticallyspeaking, they are right more often than they are wrong. But it’s still just statistics.And truthfully, if they are any good, they will like being questioned. They enjoythe technical debate. This is a critical aspect of a great team.

In fact, if they don’t enjoy the debate, you are likely in the wrong place. The personwho told me I was being stupid was actually right. The organization I had joinedpunished, rather than rewarded, people who questioned people in positions of authority.As soon as I realized this, I got out. It’s a very personal preference, I suppose,but I personally prefer organizations that reward and promote people based on abilityand direct impact. Sadly, in organizations where authority prevails, advancementis almost always based on who-likes-who, ass-kissing, and time-in-position. For folkslooking for cozy jobs with guaranteed income, perhaps this is ideal; but you’re quiteunlikely to grow rapidly, build amazing things, and change the world in such places.

Now, you can’t be an asshole about it. And you can’t be arrogant. Software is allabout people and collaboration, and all of this questioning must be done with a singlegoal in mind: to make the software, the organization, and/or its people better. Authorityis there for a reason, which is that ultimately someone needs to run the business,make decisions, and have their butt on the line. Sometimes the simple reality isthat a leader’s intuition is extremely good, and though data may be lacking to supportthe decision, you can trust it. It’s okay to agree to disagree, or sometimes admitthat someone simply has a stronger background than you in a particular area and somaybe you aren’t in a position to fully understand why a certain decision was made.I have always tried to turn such occasions into learning opportunities. Jot downa few notes, and go read about it afterwards. I always jot down and research anyterm I hear that I’m not totally on top of, technical or business. It happens allthe time.

4 Slow Down to Speed Up


In such environments, however, I’ve found one thing to be a constant struggle foreverybody on the team – leaders, managers, and individual doers alike: rememberingto take the necessary time to do the right thing. This sounds obvious, but it’s veryeasy to lose sight of this important principle when deadlines loom, customers andmanagers and shareholders demand, and the overall team is running ahead at a breakneakpace.

To achieve this, leaders needs to be consistent, demanding, and hyper-aware of what’sgoing on around them. You need to be able to recognize quality versus junk, so thatyou can reward the right people. You need to set up a culture where critical feedbackwhen shortcuts are being taken is “okay” and “expected.” I’ve made my beliefs prettyevident in prior articles, however I simply don’t believe you can do this right inthe early days without being highly technical yourself. As a team grows, your attentionto technical detail may get stretched thin, in which case you need to scale by addingnew technical leaders that share, recognize, and maintain or advance these culturaltraits.

Facebook has this slogan “move fast and break things.” It may seem that what I’msaying above is at odds with that famous slogan. Indeed they are somewhat contradictory,however paradoxically they are also highly complementary. Although you need to slowdown to do the right thing, you do also need to keep moving fast. If that seems impossible,it’s not; but it sure is difficult to find the right balance.

I have a belief that I’m almost embarassed to admit: I believe that most people areincredibly lazy. I think most quality comprimise stems from an inherent lazinessthat leads to details being glossed over, even if they are consciously recognizedas needing attention. The best developers maintain this almost supernatural drivethat comes from somewhere deep within, and they use this drive to stave off the laziness.If you’re moving fast and writing a lot of code, strive to utilize every ounce ofintellectual horsepower you can muster – sustained, for the entire time you arewriting code. Even if that’s for 16 hours straight. If at any moment a thought occursthat might save you time down the road, stop, ponder it, course correct on the fly.This is a way of “slowing down to speed up” but in a way where you can still be movingfast. Many lazier people let these fleeting thoughts go without exploring them fully.They will consciously do the wrong thing because doing the right thing takes moretime.

Another practice I encourage on my team is fixing broken windows. I’m sure folksare aware of the so-called broken windows theory,where neighborhoods in which broken windows are tolerated tend to accumulate moreand more broken windows with time. It happens in code, too. If people are discouragedfrom stopping to fix the broken windows, you will end up with lots of them. And guesswhat, each broken window actually slows you down. As more and more accumulate, itcan become a real chore to get anything meaningful done. I guarantee you will notbe able to move very fast if too many broken windows pile up and start needing attention.Slowing down to fix them incrementally, as soon as they are noticed, speeds you updown the road.

5 Read Every Checkin

Code Review 可以反应出团队的很多方面,也可以快速地了解项目进展和细节。另外程序员虽然不太喜欢微管理, 但是看到自己的代码被别人review也会感觉很好。

As a technical leader and manager, code reviews and checkins are literally the heartbeatof your team. Reading them religiously – although admittedly time consuming – isan absolute requirement for truly understanding what the team is doing and its strengthsand weaknesses. If you’re joining a new team, it puts you right at the heart of theengineering dialogue, and in a position to start fixing whatever is broken (openingit up, encouraging debate, changing technical direction, etc). When it comes timeto calibration meetings, you’ll already have a deep awareness of who’s actually gettingstuff done, and who is writing the quality code. You’ll see the technical leadersvery visibly, including who is really setting the pace for the rest of the team (codingoutput, good feedback, work ethic, etc).

And from time to time, you may even find the opportunity to offer up a small suggestionyourself. Some might see this as micromanagement, however I’ve found that developerssincerely appreciate when their boss or boss’s boss or whatever really cares enoughto take the time to understand their work at this level of detail.

6 Codevelopment is a Powerful Thing

不要自我设置边界,打破边界去做事情,一方面你可以学到更多的知识,另一方面在产品上可以做到更好的 end-to-end的用户体验,优化整个产品。抽象是件好东西,但是它的cost/value必须放在特定的context下面重新 evaluate.

In fact, the developers I love most are those who will go make a change to the language,ensure the IDE support works great, plumb the change through to the backend code-generatorto ensure optimal code-quality, whip up a few performance tests along the way, deploythe changes to the class libraries so that they optimally use them (and on up throughto the consumers of those libraries in applications), write the user-facing documentationfor how to use this new language feature, … and beyond. All in a few days’ work.

It takes real guts. The best programmers are absolutely fearless.

Obviously my present situation is a bit unique. Not everybody works on the developmentplatform and operating system and everything in between, all at once. But there’smore opportunity for this than one might think; in fact, it’s everywhere. It canbe a website or app’s UI vs. business logic, hardware vs. software, the engineeringsystem vs. the product code, operations vs. testing vs. development, etc. Most peoplehave sacred lines that they won’t cross. It saddens me when these lines are drivenby organizational boundaries, when engineers should be knocking the lines down andcollaborating across them.

Abstractions afford a degree of independence, but I always regularlystep back and wonder, “what is this abstraction costing me? what is it gaining me?is the tradeoff right?” Abstractions are great, so long as they are in the rightplace, and not organizationally motivated. The biggest sin is to knowingly createa lesser quality solution, simply for fear of crossing or dealing with the engineerson the other side of such an abstraction boundary.

7 Empower Bottom-Up Innovation


It’s critical to create an environment where the best ideas are heard, discussed,and ultimately able to grow into things that are much bigger. Your company’s nextbig success could be sitting right under your nose, and in an environment where thoseideas have no voice, you lose doubly: first, you don’t capitalize on the idea; and,second, the person is likely to take their ideas elsewhere. Smart and creative peopleneed outlets.

Too many high-level managers care more about the “what” than the “how”; how a teamworks – collaborating, generating ideas, engineering culture – is even more importantthan what it is building, because a healthy culture ensures success not just in thecurrent project, but also equips the team to tackle future projects with agility.

8 On the Importance of Intellectual Honesty


The best engineers and leaders I’ve worked with have an insatiable curiosity forhow things work, a desire to discover how to do things better, and fundamentallyunderstand that careers are about a lifetime of learning. If you don’t knowsomething, it’s an opportunity to learn, not cover up the fact you don’t know.Everybody has missing information. It’s impossible to hold the world ofknowledge in a single person’s head (at least with today’s technologies). Thebest leaders know this, and ask endless streams of insightful questions.

The reason this sucks is it breeds a culture where technical debate, discourse,and the pursuit of excellence isn’t the norm. People “game the system” andstart playing politics, rather than letting technical innovation shine through.People with an innate ability to find flaws and help patch them are discouragedfrom participating, left frustrated and therefore under-utilized, and often endup leaving, despite them being an enormous competitive advantage to yourcompany.