Build Your Career: Nosce te Ipsum 


Nosce te Ipsum

Navneeth MandavilliNavneeth Mandavilli is a senior technologist and innovator with experience ranging from hands-on development to the management of multi-national engineering teams building enterprise applications and system software. His most recent focus has been on helping others build development organizations that can successfully innovate, creating incubation teams that select projects based more on the promise of technology than proof. His approach has resulted in ground-breaking solutions, valuable acquisitions, and interesting failures.

Navneeth believes a successful career is rooted in two words: Know Thyself. He hopes that sharing his thoughts on what he learned about himself as he succeeded, and failed, in his career is helpful to the readers of this blog. He currently works in the Office of the CTO for EMC Corporation and is based in Santa Clara, California.

Follow Navneeth on Twitter @nmandavilli.

Log in to register a comment.

Subscribe here.

Entries with tag software development ideas innovation.

Top Ten Idea Killers in Software Development

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 1, some other company has already taken your customer away because of this feature. Fix it before you reach the point where you cannot.2

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/SDS3 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.4


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.



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.

On Being Wrong

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.

IAmTooGooditis and Other Signs of Complacency

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

The one thing that workers in any profession need to watch out for is complacency. We may start out with the best intentions but much like the seven year itch, complacency hits us just when we think we've mastered it all (perhaps because we think so) and unless we are watchful, will lead to rather unhappy results. The signs are different for different folks but here are a few classics:

          You start thinking of ‘the road not taken’: maybe you wanted to be a politician, or an English professor, or make a great movie. The day you catch yourself saying ‘I could have been a great …’ is the day you need to wake up and take stock. Are you being the best you could be in your current role? Think again. If you were as good as you think you are, you wouldn’t have time to day dream about what you are not: you would be nose down, enthusiastic and energized, working on designing the next exciting product from your company; your boss would be driving you, depending on you every day to help him make important decisions at work; your colleagues would be constantly seeking out your opinion; you would be scrambling to respond to all the mail you get from your highly respected blog on current technologies; you wouldn’t have enough time turning down invitations to speak at and contribute at tech conferences … is that the case? 1

-         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.2  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.3 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 genius6; 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. 9

All of the above comes from not taking yourself, your career and your job seriously. Young people have a notion that taking work seriously is somehow ‘not cool’; being nonchalant or flippant about work has more cachet than otherwise. But no matter how talented or intelligent you are, without application and focused hard work, you will always fall short of your potential. If you look down on what you do every day, it has an effect on your self-esteem, however subtle. Taking yourself and your work seriously is about respecting yourself and your work, and therefore your colleagues and your organization; it's about believing in what you do and achieving your full potential while enjoying the process. As our friend Heraclitus also observed, man is most nearly himself when he achieves the seriousness of a child at play. Yes, you may have exceeded the goals that you set for yourself when you passed out of college, or the ones your parents had for you; but the mistake is in not changing them as you grow and gain knowledge and experience. You grew out of wanting to be a fireman, now remember to grow out of whatever you have been doing – you have bigger worlds to conquer.
1: perhaps that is the case. Maybe your boredom is the result of you having achieved everything possible at your current job and it’s only right that you explore other avenues of self-expression. In that case: Hello, Prof. Knuth; nice day, huh?
2: I can’t emphasize this blind spot enough. Look around you: can you not itemize in a list what the incompetencies are in every coworker around you? Well, here’s a news flash: so can they.
3: Yes, ‘C’ is still widely prevalent and you have held on to a job while others have lost theirs. But this is about you – how have you grown? How have your responsibilities at work grown? How comfortable are you talking to a freshly minted engineer about the current technologies? What experiences have you had in learning, using and building software? Ultimately, this comes down to how you see yourself: are you the man in the grey flannel suit? Or is there more to you?
4: the other question to ask here is why you still need to do the same job after 10 years? Shouldn’t you have fixed the problems in your software by now? Shouldn’t you have made the framework better, the logging more meaningful, diagnosis automatic, support better, processes scalable and errors self-correcting? If you had explored, proposed, suggested or thought out loud on any of the above and implemented any of them even partially, your organization would have seen you as a better fit somewhere other than the same old place fixing the same old problems.
5: Does being promoted to the next grade in the developer category count? You are now "Software Developer IV" instead of "Associate Software Developer". Well, it depends. What are you doing? Are you designing the product? Are you influencing management? Are you coming up with breakthrough ideas that result in your products outperforming competitors' products, or that result in all-new products? Are you known as a whiz within your division? Are you advancing the usage of technology? Have people outside your division heard of you? Yes, it counts, if you are at least aiming to be the next Kent Beck, Grady Booch, Dennis Ritchie, Larry Wall or even Marco Arment
6: usually.
7: not going after bigger goals while dismissing your current job is, I am sorry to say, a subtle hint of fear of failure.
8: what bigger things? There are numerous options to choose from in just creating software (see list of programmers in 5); but beyond that, mastering people and business management is a worthwhile challenge for every software engineer who feels unfulfilled
9: yes, changing a job is difficult; but not really. If you have a different opinion, feel free to post a comment below
What Your Manager Expects From You

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.

The interested employee can figure out the easy expectations: do good work, meet your deadlines, keep your word, be a team player. The inquisitive one can even get to the subtler ones: listen to your boss, understand his goals and make him look good. But many are the slips between the cup and the lip: reading or hearing about something is not the same as knowing it; knowing something is not the same as doing it, and neither is wanting to do something; and doing something is not the same as doing it well. How then does one know what to do and then do it well?
Use your values as a guide, a mentor once told me but that only led to a deeper question: what are my values?
Some values in life we acquire through unquestioning osmosis: from our parents, friends, the ethos; some we “choose”, driven by rebellion, individuation, the unexplored life of the parent; and others we adopt for purely utilitarian purposes. Whatever the reason, it is only over the years that we (perhaps I should say ‘I’) begin to understand truly what a value means, why we chose it, the impact it has on our lives and its effect on those around us. What then is a young knowledge worker to do?
One could faithfully follow a set of rules, say, to ‘make one’s boss happy’; but that way lies the road to short lived success, puzzling career stagnation, decision making that is agonizing and a feeling of being lost. Working at understanding and aligning the expectations at work with one’s personal values is a more rewarding way to shape career and character; but values take years to seep into our consciousness, grow roots and bloom in their full glory, and need constant and careful nurturing and nourishment. Expectations, on the other hand, are full blown and immediate. So, as I caution you on the perils of second-hand wisdom, and with the confidence that you will look to yourself to validate the truth of what I am saying, here are a few things that I learned about expectations:
Know Your Job
In my entire career, I have never had the pleasure of having my job defined for me (I can only imagine what such a Utopia would be like). Unlike the job of, say, a cashier at a movie theater, the software engineer comes into a job that has no real definition. I’ve sometimes asked, only to receive responses like a crisp “figure it out” or a half-joking “what am I paying you for if I have to tell you?” The interesting thing is that even the manager, the person hiring you, can only give you the broad outlines – “you will be part of the Cloud Infrastructure Group” or that you will “work on building the next version of our product”; what that means is for you to figure out.
If you are a young engineer, you may need to establish your credentials with the team lead to get a meaty assignment.1 You may then have to understand, choose the right technology for and design the module you are given such that it fits into the overall framework of the project (for which you need to broadly grasp the framework itself, and that may not even exist yet). You may have to provide estimates, call out milestones and lay down measurable progress markers. You may have to communicate your design to your team mates and gain their approval; understand their modules and make sure that yours is compatible; you may even have to interact and gain cooperation from other teams or members of another division. You may have to write the documentation or work with the ID team to get it right; you may have to run unit tests and write test cases for the QA team to accept the module for testing. You may have to prepare reports and presentations to show to your manager and his peers and bosses.
Or you can sit in your cube, browse the web and wait for work to be assigned to you. You can carefully listen to the requirements, finish it exactly the way it was communicated, on time and go back to waiting for your next assignment.
Both are feasible options. You won’t get fired for following the second option; but I doubt you will learn anything new. Your manager certainly won’t be looking at you as the one who gets things done. Your colleagues will be more than happy that you are not competing with them2 or showing them up; you’ll be a nameless, if dependable, cog in the machine of software development. But here’s the worst part: your manager will never tell you that you are one.3
I spent a significant chunk of my early career waiting for my next assignment: as long as I am being paid, it’s the company’s (or my manager’s) responsibility to make sure that they are getting their money’s worth, I figured. What was assigned to me was completed on time, correctly and to specifications. But little did I realize that by not defining my role to be bigger than was assigned,  I was wasting precious time and missing significant opportunities at work, with not one adverse reaction from anyone around me4.
Why this is so is a little complex: your manager does not want to lose you because even in this bad economy, with all the outsourcing, the job market for even mediocre software engineers is pretty good. S/he is not going to say anything that might make you leave. Many managers have learnt the hard way that people are sensitive, and accepting criticism equably is a rare quality. I have gone to managers and said, "Tell me when I am doing something wrong because I LOVE to learn" and still the worst I ever got was "everything is great"; it's a really strange phenomenon.
Another reason could be that your manager himself doesn't know what to expect; it happens. First line managers who have lost touch with development sometimes have no idea what to expect in a project and completely rely on the team lead to do the "technical management"; the performance reviews5 then become a magical combo of gut feel, feedback from the team lead and your personal relationship with the manager. Many managers are also into 'empire building' -- they are looking at not losing anyone and making their teams bigger because that's their ticket to the next level in management. So, just because you are getting paid and your manager seems happy is not an indication that you are doing well*; and not getting criticized doesn't mean that you are meeting the job's expectations.
'Knowing your job' then, becomes these two things: one, you should meet the basic requirements of the job: know the current technologies, be able to follow directions, work in a team, communicate ideas and not need to be micro-managed. And two, and this where most people stumble, is the ability to define your job. This is not a stretch for a software engineer; as I said at the beginning, almost6 no project is handed out with everything defined and well laid out. So if you take the opportunity, the first option, of exploring the project, learning about the problem, fleshing it out, defining the boundaries, forming the solution or making it better by working with team -- you are defining your own job. In the process, if you can suggest how the modules that you have to interface with can be made better and help improve your team mates’ output -- you are defining a role for yourself that is bigger than just that of a programming cog -- you are becoming a leader!7
Having done your job well and having lent a hand to your team mates, there is one more thing that you can add to your definition of your job: help your boss shine.8
Your boss comes to you with a skeleton definition; now, instead of merely dressing that up in rags, if you can flesh it out fully because you are more in touch with the current technologies, are aware of what the industry trends are and what the competing products are doing; if you can give it back to the manager, not just having met the expected milestones but with enhancements that have a direct business impact or that give the product a leg up on the competitors through better technology, you are meeting a need that your manager had only dreamed of having fulfilled9
None of this is going to be easy: you will face resistance from peers, pushback from seniors, questions from your manager and if you are doing things right, find yourself out of your depth. But that's what the job is; that's what no manager is going to tell you to do but every manager expects; and that's the only way to success.


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.


1 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

2 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

4 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?

6 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

7 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

8 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.

9 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

On Being a Knowledge Worker

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!

Showing 5 results.


Sign up for the Build Your Career newsletter to receive the latest career news and job listings.




View All Newsletters | Privacy Policy



Marketing Automation Platform Marketing Automation Tool