How can he remember well his ignorance -- which his growth requires -- who has so often to use his knowledge? -Henry David Thoreau, in Walden

Few things are tougher than admitting that you are wrong. Fewer still are more important, perhaps even necessary, than being wrong. I’m no longer young enough to know everything but I sure started out that way; and while I may occasionally regret the diminishing of that aggressive confidence, I am happy for the gain in the quieter version that lets me accept that I can, and have, failed.

The denial of failure is an indication of fear

What is your first reaction when someone points out a mistake in your code, a shortcoming in your design or questions your premise for a solution? Does your pulse quicken? Is a retort ready to be hurled? Does your voice rise? Do you feel besieged? Are you convinced you are being treated unfairly? These are all signs that you are suppressing fear and denying the possibility that you may be wrong. You may win the battle by browbeating your opponents at the table, but you’ve lost the war of gaining their respect. Your colleagues will think twice before they come to you for an opinion or invite you to a brainstorming session. Anger and defensiveness are masks for insecurity, so watch out for them and focus on understanding the causes of your reaction than on the motives of your (perceived) opponents. Being wrong is inevitable; your colleagues are doing their jobs by questioning, probing and analyzing the design; are you doing yours by being open, receptive and flexible?

Why be wrong?

Because it lets you do things. No matter how careful your thought process, how exhaustive your research and how nuanced your calculations, you will be wrong. If not now, tomorrow, the next month, or the next year. The longer you postpone your failure, the more spectacular it’s going to be. While you push decisions further and further ahead, you are losing out on smaller, valuable failures that could instruct and bolster your inner self.

Conservative, careful decisions result in timid outcomes that slowly eat away at your confidence at making the big decision. Use your early years to accumulate experience in making decisions; put in the work to acquire the knowledge required for your work and make decisions based on that knowledge without worrying about being wrong. If your boss thinks your decision is wrong, he’ll correct it (that’s his job!) and you’ll learn from it. If not, you have learned how to make good decisions based on knowledge. Either way, you are one step ahead in mastering decision making.

Making decisions is not something that’s acquired through thought or some vague, magical quality like “guts”; it is a skill that is born out of knowledge and practice. Making a big decision, if you’ve done the right things in your career, is not so much a leap of faith as a calculated path chosen by drawing on your experience.

Take a side; make a stand; build a case for something. Listen; accept feedback; learn; move on.

Being wrong the right way

Is there a right way to be wrong? I think so. While it is common to see participants who argue every position without committing to any side as long as there is some resistance in the air, the starved ranks of the bold are further cleaved into those saying "Yes, we can" and those saying, "No, we cannot;" and usually, it’s the naysaying crowd that forms the majority in this division.

It has puzzled me no end throughout my career when I run into these otherwise smart, motivated engineers who bring up one reason after another on why not to do something. It isn’t even that what exists is good or that they have a better proposal; they just seem to like to say no. True, they are taking a side, making a stand, building a case; so far, so good. But where they frequently fail is in the listening, accepting feedback and moving on parts.

There will always be reasons for not doing something (“we’ll disrupt our current customers”; “our priorities will have to be reshuffled”; “what if our assumptions are wrong”; see my top 10 here); but if it’s an even choice between doing and not doing something; or between a bold, slightly risky one versus a safe, unrewarding one, always bet on doing the bold, risky thing versus sitting on your hands. That is the right way of being wrong: a path that lets you (and your organization) create something, learn from it and move ahead versus just waiting for the market to write your epitaph. Remember: making a big decision is not a leap of faith, it’s a calculated path; and the calculation will make sense to you only if you have done some math in your career.

The indecisive manager

As an individual contributor, there is nothing more frustrating than working for a boss who cannot make decisions. Engineers, for all their seemingly intractable opinions at design reviews, want to get down to work and build things once their need to express themselves is spent; woe to the team lead or manager who doesn’t have the knowledge or the intestinal fortitude to make a call and get them to do it. Engineers smell fear and ineptitude a mile away and the indecisive boss might as well pack his bags and leave. The engineer’s need to respect his/her boss aside, an indecisive boss will leave projects hanging, responsibilities unclear and an air of vagueness that leads to a directionless team. The point here is this: the team will respect more a manager who makes a decision, even if it turns out wrong, than the one who ducks making one.

As a kid, I always wondered why an entire army dropped its weapons and ran when its leader fell. As part of a team in the corporate world, I now know why: I may be the best engineer in the land with a team of aggressive code warriors, but unless I am led by a boss who can convey what to build, why, and for whom, I will either form my own army or look for another leader; I am not standing in the field waiting to be slaughtered.

Making it OK to be wrong

Finally, as you get comfortable with being wrong and using them as incidents that instruct, make sure that you extend that freedom to those around you. As you start out in your career, it’s natural to focus on your work, your improvement, and your successes; but as you assume more responsibilities and widen your influence, remember to make those around you successful, too. As in life, so at work: you cannot succeed while others fail around you. The bigger your successes, the more you are dependent on those around you to make it happen. Remember how you failed and learned, and make it OK for others to follow the same path. The incentive is simple: when being wrong is OK, things get done. A team that’s wary of making mistakes will never venture anything and nothing will ever be gained.

I cannot end this post without mentioning that there might be, in some cases, painful consequences to being wrong. You may be demoted, or stripped of responsibilities or even fired. While I cannot say for sure that it’ll turn out to be the best thing that happens in your career, it will still be instructive on many levels. You have to decide at some point if you want to work at a place where you are not allowed to be wrong: nosce te ipsum! Will you be able to function at a place where you are not allowed to take a risk? Where your ideas and initiative are not valued? Where seniority or contacts count more than the substance of the ideas? Seizing opportunities and doing things from the beginning will have armed you with the knowledge of who you are, what you are capable of and where you will be happy; and that will help you make that decision. You will never have a perfect answer but when in doubt choose the unknown, bold road; what’s the worst that can happen?

Fittingly, I’m willing to admit that this whole thesis may be wrong but I’d like to know why, so if you disagree, let me know, either by commenting below or via twitter @nmandavilli.

Software engineers start out as being curious, enthusiastic and gung-ho about getting things done. Somewhere along the way, they butt heads against a world that doesn't understand software development: systems that count engineers by numbers, productivity by lines of code and quality by process; a world where software development is a "risk-management" bureaucracy rather than a creative endeavor that can solve customer problems.

Unfortunately, many engineers consider this a wake-up call to shed their energy and adopt those bureaucratic ways, convinced that they have stepped into a new, adult world of "management". Some who manage to resist that misstep become disillusioned and don the garbs of martyrdom, ascribing every failure to something that management did or did not do. 
 

If you are a software engineer, or an engineering manager, here's a list to help you identify if you still retain your software development genes or have morphed into someone that brings out a worn out list of cliches to robotically throw into every meeting, killing every idea and the morale behind it:

10. "This is good enough" : The fact is that nothing is ever good enough, least of all software. It may be good enough for today, or this release, but if your product has had the same problem for the last decade ¹, some other company has already taken your customer away because of this feature. Fix it before you reach the point where you cannot.²

9. "This is how it was always done": This is an anachronism in any competitive, rapidly changing field but particularly in software. Software companies are not like automobile companies that can set an assembly line in place and forget about it for a hundred years. Oh, wait-a-minute! Even automobile companies cannot do that anymore! Today's problems require a new set of solutions because in an industry fantastically bound to Moore's Law, machines, along with people's expectations from them, set a terrific pace of change.

8. "There isn't enough time to do it right": This is how you get into Technical Debt; some of it may be inevitable due to business pressures or working with a new piece of hardware or technology. As long as you repay this debt in the immediate future, this is part of the process; but if this is how you avoid making the right decision and the responsibility that goes with it, you are not being true to your engineering origins.

7. "This requires core architectural changes": What doesn't? Ideally, a well-designed piece of software should be flexible and amenable to changes as the product develops. But as we've said, demands on software change rapidly and every piece of software written will need to be rewritten. This is the nature of the work, not an anomaly to be used as an excuse!

6. "Management has not prioritized it": I always want to ask: what exactly hasn't management prioritized -- making a good product? writing error-free code? reducing bugs in the field? making the customer happy? Agreed that sometimes we inherit legacy code and there is juggling to be done between fixing what exists versus writing new code but this is a specious argument as we will see below. Suffice it to say that engineering needs to set and execute its own priorities, however small, every day, instead of waiting for some giant, magical mandate from above, because that's never going to happen.

5. "There is already a lot on our plate": This is one of those nonsense tautologies that add nothing to the discussion. The focus is no longer the idea or how it should be executed but some longstanding grouse about 'having no resources' or some customer's bug list. Of course you have a lot on your plate! You are being paid to have that stuff on your plate -- start chowing down!

If an idea is worth executing, its adoption should not depend on whether you have a lot on your plate; if you fill your plate at the buffet with junk and decide you can't have a desired dish because your plate is full, you have done two things wrong: you chose the wrong things to begin with and then haven't done the simple math that you have to throw the junk off your plate to get what you want. You don't kill the idea, you clean your plate.

4. "Our software is very complex; we have to be careful about making changes": Check another nonsense tautology off the list. What enterprise software isn't complex? Are you saying you are usually not careful when writing code? You are a software engineer -- you are expected to deal with complexity and be careful about making changes -- that's a basic requirement. If this is a reason we as engineers cannot execute an idea, we need to go back to relearn the basics.

3. "No one is asking for it": This reminds me of Henry Ford's wry comment "If I’d asked people what they wanted, they would have said 'a faster horse'." Human beings are incredibly adaptable -- they will live with anything, including, as Ford observed, horse manure. If you give your customers a substandard product, they will live with it. But remember that humans are incredibly fickle, too; an idea you kill will only bloom in another company's garden. Being sloppy just because our software is "sticky" -- short for "the customer hates us but can't change because it's too much work" -- is setting the bar at a level that's not worthy of a true engineer.

2. "We have to have consensus": This is at number two for a reason -- it's a seemingly innocuous statement with noble intent that is insidious and on closer inspection, meaningless in the software context. Consensus is given undue importance in everything from design meetings, SRS/SDS³ reviews, documentation, QA practices etc. Software development is an expertise-driven exercise. Someone has spent years studying, learning and working in a specific field, and to not defer to that person for the final decision is to waste all that expertise, not to mention deliver a bad product, demoralize the expert, adopt the safest and most timid way and most insidious of all, diffuse accountability.

A group decision is a way to duck responsibility for the outcome. "We all decided together" is a way of saying "No one is responsible". We have a presidential system instead of a parliamentary system for a reason: the congress advises the president but the president makes the decision. Unless the decision is so obviously horrendous that 2/3rds of congress decides to override the decision, the president's decision stands. This is the only way the buck can stop at the president's desk.⁴

And the #1 idea killer in software development is

1. "It can't be done": There is nothing that cannot be done in software. Non-engineers kid around with "It's only software, right?" as a way to gently provoke engineers but it's true! It is indeed only software. Engineers should respond with specifics of what it takes to implement rather than say something cannot be done. A statement like "It will take 15 engineers, with individual licenses for software xyz, with 30 Model ABC machines, each with 2 TB of storage with at least 250GB in SSD storage and 5 QA personnel for a period of 1 year to deliver this software" instead of "it can't be done."

Everything can be done; let's get into that mindset first. The rest will fall into place.

Footnotes

1. Anyone who has worked on enterprise software can give you a long list of "known bugs" that have been around for more than a decade

2. Sometimes you cannot because too much code has grown around the defect and changing it is just too darn difficult at this point; or because the software died under the burden of too many such defects; or you no longer have a job because the company folded. It happens.

3. Software Requirements Specification/Software Design Specification

4There was a comment recently on which presidential system I was referring to here. After nearly 18K views, it was almost a relief that someone asked! The comment has since muysteriously vanished, apparently removed by the commenter himself, but I thought I should address it anyway, since this has been annoying me since the time I wrote it. I was referring to the US system and the president's executive and veto powers and the congress's veto override. I was aware that the construct was weak when I was making it but I can certainly make a case for it. However, since the article is not about governments and  the larger point being made is helped by the example, I am going to let it remain and beg the indulgence of more discerning readers.

What Your Manager Expects From You - II 

Now that you know what your job is and are on your way to being a star in the eyes of your boss and colleagues, a few thoughts to keep in mind on the journey:

Take Your Work Seriously

-         You could do your job with your eyes closed: work has become a comfortable routine, like the daily commute -- you don’t think, you don’t prepare and you don’t sweat; the occasional deviation from the normal has you pushing to get things back to the routine as quickly as possible and irritated at the cause of the deviation. In other words, you have given up on yourself and FYI, so has everyone else at work.²  Nowhere is Heraclitus's aphorism about change being the only constant more true than in tech; and its pace of change is terrific. If you are still doing what you were doing 10 years back, you have been complacent.³ As I mentioned here, your manager will never tell you that you are mediocre; as long as you perform a function that’s required, you will be paid with all the accompanying blah blah of how important your job is. But think of it this way: a 16-year old usher at AMC is cute; a 50-year old usher? Not so much.^4,5

           You dismiss your job as ‘easy’: this is the most insidious of all germs, particularly because it affects the smart ones. You are put into a job, you learn it quickly, master the ins and outs and now can do it without thinking twice. It’s still tough for others to do and you are perceived as a valuable member of the team, doing the difficult job that others cannot; and there is no other time that is more perfect than this to be stricken by ‘I-am-too-good-itis’. The symptoms are that you stop thinking about your job, start dreaming of the road not taken or just mindlessly surf the web in your free time, of which you have a lot. This is where a good mentor, friend or relative is crucial: to tell you that you are wasting your potential. If your job is easy, it does not mean you are a genius⁶; it means you are in the wrong job -- a sign for you to move on. Trust me, software engineering is not just about writing code or fixing bugs. I know you enjoy it a lot, and you enjoy it because you are good at it; but if you feel that you could do more, it probably is because you can. Bigger things await; tougher situations exist; go for them! ^{7, 8}

           You watch the clock and look for excuses to take days off: this is the saddest of all signs. Like it or not, all of us who have to work a job to eat spend 8 hours or more every day doing it; this is way more than any other thing we do in our lives, except perhaps sleep. To feel unenthused and bored about doing it is the worst possible state to be in. If the thought of going in to work brings you down, if the conversation with your coworkers makes you want to kill yourself, if the work is driving you nuts with ennui, there is only one person to blame – you. You have ignored all the signs of complacency: you have chosen to be at an unchallenging job and refused to look for opportunities that would help you grow; you dismiss your job as being too easy or boring and yet have not done anything to look for another position within or outside of your organization; instead of defining your career, you’re waiting for something to fall into your lap. That sick feeling in your core when you think of where you are in your career? That’s you being disappointed with yourself. And the solution is straightforward: change your job. ⁹

There are two things I wish I had known as I started out in my career: what my manager expects of me as an employee; and why s/he expects that of me.

---

I originally intended this post to contain several other thoughts but it soon became so unwieldy that I decided to split it up into multiple posts. You should see them in part II of this post.

Footnotes

¹ How you do this is up to you. You may want to dazzle the team with your knowledge during lunch; talk about the previous projects you worked on and technologies you used; point them to your open source contributions; volunteer to help team members with something they are struggling with; host brown bag talks on technology; or just schedule a 1-1 with the team lead, tell him what part of the project you are interested in and why you are a good candidate for the job

² This obviously depends on the kind of colleagues you have. If you are lucky enough to be working with people who are all equally driven and competent, this may not be an issue. I will say more about choosing workplaces in a future post

3 Again, if you are lucky enough to have an enlightened boss, AND you have shown yourself to be someone open to receiving constructive criticism, this may not be an issue. But I think it's easier to find a team full of exemplary colleagues than a boss who knows how to nurture with criticism

⁴ Perhaps it was (is) a bit naive of me to expect that someone should care. I certainly believe that the desire to excel or succeed must first come from the employee; but I also think that there is many a young fire that is left to die out due to the lack of a guiding and protective hand

5 Such as they are. PR is a topic worthy of a post of its own

^* What is a good indication? No raises. A good worker always gets raises, unless the company is clearly not doing well. In which case, why are you there?

⁶ Inevitably, there will be projects and companies where modules are handed out with everything specified to the last data structure. However, if you are working in a company that is making products (as opposed to ones maintaining them or fixing bugs) you will almost never have anything close to a specification that you have not written yourself, and even then, it will change a dozen times as the project progresses

⁷ I have to warn you that this is not as much of a victory lap as I make it sound to be; being thought of as a leader requires genuine qualities of humility, equanimity, knowledge and keeping the success of the team above yours, among others; not to mention dealing with the ambitions of your team mates

⁸ This may be seen as kissing your boss's a** but that's the job! Making your boss look good is good for the team: it means his team works well, s/he is able to suggest new solutions, deliver results on time and meet his/her own boss's expectations and the organization's goals. When you have his back on technology questions, you make the team look good. If your boss takes a hit, the team does too, because whether you like it or not, your boss is your representative. When you make your boss look good, you are really taking care of yourself.

⁹ Trust me: every manager is waiting for an employee who can take more responsibility, deliver results, fill in the holes in his knowledge and make the team better. S/He cannot express disappointment that none of his current team members display those traits but that doesn't mean that every night isn't spent with a hope that the morning will bring in this savior into the team

I did not know what a career was when I started out as a software engineer; I did not even know what a job was. All I knew was that this was something I had to do, that everyone did: go to school, get a degree, get a job. My parents made sure that I went to school -- packed my lunch, paid my fees, frowned on poor grades and scoffed at the notion that humans could exist without graduate degrees. Once I got a job, my manager made sure that I had work to do and the corporation paid me regularly. I was on my own without ever realizing that I was. I was living by myself, making my own food, buying my own clothes and earning a good wage; but I was also at the bottom rung of a long and winding ladder of a career and I had no idea.

I spent the first few years of my career doing well a job that I loved doing -- writing code, building programs, making things work. I never gave a thought to titles or promotions or seniority grades. Those were vague notions at the back of my mind but the stronger notion was that if I did good work, it would be recognized and the rewards would follow. For this post, suffice it to say that it was not enough. I have thought back many a time since, at incidents that could have been handled better, opportunities that should have been seized, ideas that should not have been dismissed, roads that should have been trod, wishing I knew then what I now know. That rue has led me to accost fresh-faced engineers at work and lecturing them on what a career should be, leaving some more wary than wise, I've been told.

My fellow blogger on this site, Jim Coplien, does a wonderful job of talking about building an integrated career and wrote a great first post about what it means to be a software engineer. I love reading Jim's posts, and the first one in particular makes it clear that he is not going to talk about "planning to become a CEO". "Life happens a minute at a time", says Jim, and I cannot agree more. The rueful incidents I mention above have all been rueful moments, really.

But this is after all the "Build Your Career" site, and I want to pick up on what Jim has started in talking about the big picture and make the focus a little bit narrower. It will still be, as he says, in "the everyday stuff" that we shall find the nuggets that add up to a rich career but in the specific context of a software career in the modern corporation. A lot of the questions I raise, and answers that I suggest, will be opinions; self-inquisition disguised as opinions, really: What does it mean that I am a software engineer? Am I an engineer or a programmer? Why am I not a CEO yet? Why am I writing this blog? Will I be coding when I retire? Should I learn Ruby on Rails? Is it wrong that I haven't built an iPhone app yet? Why am I surrounded by idiots? And so on ...

I don't want to put myself into a strait-jacket as far as the content goes, but as I look back from where I am, I see three distinct phases in my technical career where I could have used some insight, some advice, perhaps a mentor. I am aware that The Social Network has skewed what a software engineer thinks a career should be, but this is a blog for the rest of us. Generally,

- The first five are when you are just starting out and don’t really know what to expect, and chances are that what you do expect is completely unrealistic. How you face, and grow, in the first five years impact how you handle the next five

- Years 5-10 are where you are perhaps comfortable with the technical aspects of your job, but are now faced with the subtler challenges of dealing with and leading people and projects. How well you adapt to and succeed in these years relate to the kind of opportunities that will open to you in the prime years of your career: years 10-15.

- Years 10-15 are where the engineer faces his/her toughest challenges, where s/he has to battle boredom and complacency, tackle threats from competing coworkers who want the same promotion and newbies who claim to know more than him/her, and face the biggest decision of his/her career: whether to switch to management.

With the above as my triangulation points, I will share my thoughts and experiences with you, for I have found that nothing clarifies thought and provides insight into oneself as thinking out aloud with friends; and that's a thought I leave with you, my new friends. Till next time, cheers!