Presenting at SDC on Empowering a Team as an Individual Contributor

I had the opportunity to present at the SDC on "Empowering a Team as an Individual Contributor" (9/1/2013).

http://www.meetup.com/SoftDev/events/134325872/

Most developers are individual contributors (IC) – in other words they do not have direct reports. But even as a non-manager, you can empower an entire team. This is due to the nature of software engineering, where developers create their own tools, a star developer can be 10x as productive as an average developer, and a single developer can use technology for team-wide impact. With the right mindset ("add business value"), and using a combination of hard skills (automation, tooling, code generation, open source, code reuse, etc…) and soft skills (interviewing, mentoring, communication and knowledge sharing, etc…), you can be that IC developer who helps lift your entire team, and have fun along the way.

Does an expert follow all the rules?

Some people think an expert is one who can follow all the rules. Others think that an expert is one who knows when to break the rules, and can do so to get the job done.

Ideally you'd have both, but I favor the second. The first depends on what the rules are – are they good guidelines or are they ivory tower red-tape and bad process.

The problem with "It's not what you know, it's who you know."

I wasn't the most popular kid growing up. Even in college as I lived up to the analytical stereotype and stayed home studying (a better word would be "experimenting" or "training"), my party-going acquaintances would assure me that I was investing in the wrong thing. "It's not what you know, it's who you know. So don't spend so much  effort with the books when it's the relationships that matter." And there certainly is some truth to this. We've all seen the stranger's perfect resume get passed over for the friend's average resume (the stranger is by definition unknown, and therefore risky, so there is business rational to pick the safe candidate over the risky one). People ultimately make the decisions, so people are important. It's one reason I so actively endorse the community user groups.

However, there must be balance. There are three caveats that this cliché misses:

1.       If what you know is valuable, then people will want to know you. Even a hermit who cures cancer will begrudgingly become famous. Recruiters in every major city are scouring over LinkedIn, user groups, monster, dice, and every online job board trying to find good candidates, offering bounties, and poaching top talent from competitor's. In other words, "what you know" will quickly open doors to "who you know" (and "who knows you").

2.       Really, it's not "who you know," but "who knows you." Sharing an elevator, or even a lunch, doesn't mean that they'll risk their reputation giving you a referral, or that you can "phone them for a favor".

3.       There are talkers and doers. Talkers can drop a name for every occasion, have 500+ social-networking friends, and can truthfully say things like "Oh, I know Acme's Chicago director, Bill, we met at last Autumn's pumpkin-throwing contest…" They could get the interview with their connections, but they could never pass the interview itself.

Of course, with "what you know" vs. "who you know", like most two-way debates in life, you'd prefer both. But in the field of software engineering, you can never sell-short the "what you know".

Is development for sissies?

I was reading the book "Tales to make boys out of men" (I have 2 young ferocious gorillas boys). It was filled with adventurous stories of courage and valor who fought battles in the jungle or trekked through the frost-bitten Antarctic. Then here am I, a software engineer, essentially doing a "desk job" in an air-conditioned office with free coffee.

Sometimes I see people who have two categories: "tough-guy" jobs like fighter pilot, football player, or astronaut,  and "sissy" jobs like software engineer sitting behind a desk. What do I tell my impressionable kids?

I see it like this. "Tough-guy" jobs are honorable, and you certainly need them. But don't dismiss a "desk job" as being a sissy. Many IT engineers need to work with the most ferocious, dangerous, lethal, destructive animal on the planet – other people.  People inevitably have competing demands and interests, there are ruthless sharks out there, and any job that must constantly deal with people cannot, by definition, be a sissy job.

Second, developers also must work with the most uncaring and cold-hearted beast ever to exist – the compiler. The compiler doesn't care if you've had a bad day, if your code should work, or if you've spent a hundred hours on a 5 minute task. It has no grace. Such an inhuman vacuum is not the field of sissies.

Furthermore, other people are depending on the IT engineer's work. You could have a million customers using your financial application, or a billion dollars of revenue flowing through your processing system. Hackers attack your system every day. And the system has got to work. To have that sort of responsibility is not sissy-like.

Lastly, software engineering is so complex that you inevitably make mistakes (sometimes really big ones) – and then need to own up to them. That takes courage.

Ok, it's still not Rambo, but software engineering is not for the weak.

They should not complain if...

Every project and team always has issues. I'm a big fan of making things better. No one wants to hear complaining (not to be confused with constructive criticism or a call for action). Here's a brain dump of when people should not complain:

• They don't have a better alternative
• They can't specify what the actual problem is (saying "something seems wrong, but I don't know exactly what" isn't complaining)
• If their manager asks "what can I do", and they can't tell them
• They caused the problem
• They were warned, and did it anyway
   

How does a techie know when they're learning the business?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_does_a_techie_know_when_theyre_learning_the_business.htm]

Obviously there's a gradual scale, but here's a brain dump:

• You can talk to a non-tech person without using tech speak (Your business skills are strong enough that you don't need to "hide" behind your tech skills to bail you out).
• You can list at least three industry-specific success metrics (besides standards like "revenue" and "profit").
• You can use business decisions as a "tie-breaker" between technologies.
• You can prioritize features and defend your reasoning.
• You know why your CEO or supervisor is upset.
• You know where your revenue comes from, and how it flows through the company’s various systems and departments. Looking at the production database (that records transactions), you can make an educated guess if this year was financially better than last year.
• You can read the year-end report.
• When a new boundary case comes up in the code, you can make an educated guess before verifying with the business analyst. Then you send the business analyst (BA) an email like "I think it's X because of A and B, would that be right?", and the BA can just reply with a "yes" instead of a detailed email correcting all your concepts.

Secrets to Winning at Office Politics - Part 2

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/secrets_to_winning_at_office_politics__part_2.htm]

Following up on my previous post, here are several good quotes from the other chapters of the very good book, Secrets to Winning at Office Politics.

Chapter 4: Political Psych 101: Allies and Adversaries

• "Positive relationships build political capital." (pg. 53)
• "Allies can be grouped into three categories: Friends, Partners, and Connections." (pg. 55)
• "colleagues usually judge your personality and your competence separately." (pg. 55)
• "Those who loudly complain that 'it's who you know' are usually the same ones who never take the initiatives to get to know anyone." (pg. 59) --> as an introverted hermit, this hits home with me.
• "adversaries fall into three groups: focused, emotional, and vengeful" (pg. 63) --> you want to be aware that someone who seems adversarial because they're just focused on their goal is not necessarily out to get you personally.
• " is not an adversary - [they're] simply a difficult person." (pg. 67)
• "Usually, the most effective containment strategy [with adversaries] is to increase your leverage." (pg. 68)

Chapter 5: Political Games: Moves and Countermoves

• "Political games re played for emotional rewards" (pg. 83)
• "Political game players always have a socially acceptable explanation for everything they do." (pg. 83)

Chapter 6: How to commit political suicide

• "If you want to commit political suicide, simply start engaging in any behavior that consumes a disproportionate share of management's time and attention." (pg. 107)
• "Once people arrive at a conclusion, they unconsciously continue to gather evidence that supports their opinion." (pg. 109)
• "There are four common causes of career destruction: (1) poorly controlled emotions, (2) a victim mentality, (3) self-centered foals; and (4) foolish reactions to change." (pg. 110)
• "Many political suicides are so caught up in their own concerns or delusions that when the ax falls, they are totally shocked." (pg. 121)
• "It's a heckuva lot easier to blame somebody else." (pg. 123)
• "if your colleagues are happily  and productively engaged while you're fuming with rage, then you need to take a closer look at yourself." (pg. 124)
• "When someone indicates that your behavior is a problem, don't automatically reject that possibility." (pg. 126)
• "When you are trying to recast your image, remember that others will not immediately notice the change in your behavior. If you're waiting for the applause, it may seem awfully quiet for a while." (pg. 127)
• "if you're not the problem, but people think you are, the political effect is unfortunately the same." (pg. 127)

Chapter 7: Power, Power, Who has the Power?

• Don't confuse "power" with "authority".
• "... any strength, carried too far, becomes a weakness." (pg. 137)
• "Here are some questions to consider in determining a person's power level: ... Do they talk more about the past or the future? ... Who can they go see without an appointment? ..." (pg. 137)
• "Some timid souls, fearing that they will be perceived as pushy, overbearing, or insensitive, simply give their power away." (pg. 138)
• "If you want to look ridiculous, just try using power that you don't have." (pg. 140)
• On pg. 147, the author presents a 2x2 "Power Grid":
  • High level of position and high degree of influence --> Power Players
  • High level of position and low degree of influence --> Empty suits
  • Low level of position and high degree of influence --> Persuaders
  • Low level of position and low degree of influence --> Weaklings
• "An organization's culture is largely determined by the beliefs, values, and preferences of the Power Elite... you must adjust to the culture established by the reigning Power Elite. There is not one chance in a million that you are going to change it." (pg. 149)

BOOK: Emotional Intelligence

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_emotional_intelligence.htm]

I have always admired those who have a firm grasp over their emotions, and I don’t mean the Spock-like characters that appear dead to their feelings. This eventually led me to read Daniel Goleman’s #1 bestseller Emotional Intelligence. While the book was filled with good concepts, two really stood out to me:

• Verbal Bias - Many “techy” people have a verbal bias in their communication. They think it is more “logical” and “objective” to just go with the words that were written or said, and not taint that with someone’s non-verbal inflections. But such a bias is not more logical, quite the opposite. The majority of someone’s communication is non-verbal, and it is illogical to ignore additional (and relevant) information, therefore it’s actually very illogical to have a verbal-bias that ignores - or doesn’t attempt to understand - someone non-verbal communication.
• Emotional Hijacking – I’ve seen coworkers freak out. Rands points out that this means that they care. Great, but I don’t want to be the one freaking out where the frustration of a bad project gets the better of me. It helps to know that most of us have some sort of trigger that will instantly hijack our emotional state and make us go into a state of uncontrollable rage. For example, don’t tell me that “I don’t have time to write unit tests”.

Good emotional exercises that came to mind as I read:

1. Think of every emotion you can. You fail if you can only list “happy” and “sad”. You also fail if you keep listing physical states (“tired”, “hungry”) or mental states (“frustrated”, “focused”). I failed on both accounts. Then I went to google for “list of emotions”.
2. Think of 20 coworkers. What emotions do you think each are feeling? “Rejected” because no on adopted their initiative? “Excited” because they’re on a hot project?

The book has a lot of good zingers:

1. “the brain has two memory systems, one for ordinary facts and one for emotionally charged one.” (pg. 21)
2. “people who cannot marshal some control over their emotional life fight inner battles that sabotage their ability for focused work and clear thought.” (pg. 36)
3. “many people with IQs of 160 work for people with IQs of 100.” (pg. 41)
4. 5 fields of emotional intelligence: Knowing one’s emotions, Managing emotions, Motivating oneself, Recognizing emotions in others, and Handling relationships (pg. 43)
5. “New solutions and fresh ways of seeing a problem do not typically come from worrying.” (pg. 67)
6. “People who are optimistic see a failure as due to something that can be changed so that they can succeed next time around” (pg. 88)
7. “People’s emotions are rarely put into words; far more often they are expressed through other cues.” (pg. 96)
8. There are at least three ways of displaying emotions: minimizing, exaggerating, and substituting (pg. 113)
9. “The two cardinal sins that almost always lead to rejection are trying to take the lead too soon and being out of synch with the frame of reference.” (pg. 123)
10. “Stress makes people stupid.” (pg. 149)
11. “Many things people do at work depend on their ability to call on a loose network of fellow workers” (pg. 161)
12. “[stars] do the work of building reliable networks before they actually need them. When they call someone for advice, stars almost always get a faster answer.” (pg. 162)
13. “There are no grades given in Self Science; life itself is the final exam.” (pg. 268)
14. “The emotional mind is far quicker than the rational mind” (pg. 291)

Dealing with an IT bureaucracy

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/dealing_with_an_it_bureaucracy.htm]

A background on bureaucracies

By definition, large companies employ a lot of people. Large companies also tend to become bureaucracies in order to manager all those employees. Therefore, lots of people are working in a bureaucracy.

At least in my experience, bureaucracies usually:

• Require a lot of red tape, which in turns hurts cross-team coordination
• Split people into specific roles and teams ("separation of duties"), so they must constantly coordinate with others
• Encourage escalation of problems instead of individuals finding immediate solutions.
• Require many people to approve a specific decision
• Regulate most activities
• Are very risk-adverse, and hence punish risk more than it awards innovation
• Are very big

Bureaucracies tend to have a negative connotation, sort of like living out a Dilbert comic strip. So, if bureaucracies have such a bad rap, then why would a company ever become one?

• As the company grows, it's an understandable way to govern masses of people.
• If a company employees micro-manager personalities, the bureaucracy is a natural consequence.
• Big companies can't afford risk: People will sue them, Hackers will attach the security of their systems, millions of users depend on their product, etc...  So bureaucracies use red-tape as a safety net.

To help appreciate the positive tips of how to deal with a bureaucracy, let's first explore some futile approaches.

• Whining sessions - Everyone will complain that it's a mess, but nothing will get done.
• Emotional appeals - Bart in IT feels your pain that your 1GB workstation is slow, but he's not allowed to give you an upgraded memory chip.
• Asking someone to do something outside their role - Ok, so maybe you get lucky and Martin, the local DBA, helps install a virtual machine, but in general you can't expect this.

Practical Tips

Besides common sense (be polite, do your homework, communicate clearly, etc...), here are 11 tips for dealing with a bureaucracy:

1. Know what each role should do. In a bureaucracy, each person has their role, and that is all you can expect them to do. It is not an entrepreneurial start-up where everyone does everything they can to make the team succeed. While you may get occasionally surprised, you can't expect someone to go above and beyond. For example, perhaps only the legal/procurement team can purchase tools, or only the security access team can give your user account rights to the Customer database, or only Support can view production data, or only the Graphics department is allowed to create the official icons used in the application (despite you could do it yourself with your 5 years of hobbyist Photoshop skills), etc... You can't expect a fish to fly. Each person has a role, and a bureaucracy beats people into fulfilling just their specific role.
2. Know how information is passed between departments. A major side-effect of a bureaucracy is that it takes many departments to do even simple things. This means that even the most mundane request could bounce through 5 departments like a ping-pong ball. How does the request get passed along? Is there some official ticket/issue software that tracks everything, are official emails sent, does it only happen in face-to-face meetings? For example, if nothing happens until "a ticket is opened", then learn how that ticket system works and be prepared to open tickets. Even if you go directly to your buddy in security access to help resolve something, he'll still need a ticket to track his time against. A dozen hallway conversations with the senior VP herself may have less impact than that one ticket you actually submit. You need to leverage these communication channels, else you're just screaming in the wind.
3. Allow time for requests to percolate through the system. Because even a simple request may need five signatures from five departments, requests can move slower than molasses. Therefore, when you're designing a solution, try to determine what ticket requests you'll have as early as you can, and then submit those as soon as you can. While those tickets are dripping through the system, you can flush out the internal details of your design. Sometimes, submitting the ticket "reserves your place in line", and you can update the ticket with more details as you find them (think of it as giving that department a "heads up"). The last thing you want to do is calculate every possible edge case, and then (two days before the deadline), submit a flood of ticket requests.
4. Let the person causing the pain feel the natural results of it. - Where possible, when someone is blocking the project due to some artificial rule, let them feel the natural consequence of that project being blocked. I.e., don't enable bad behavior. For example, if someone in sales keeps entering data the wrong way, consider not enabling them by writing an automated script to continue cleaning everything up. If you do, they'll essentially think that their current approach is working, and why would they ever change?
5. Distinguish between roles and titles. Say "managers don't have access to source control", but you (a new manager) really need access. If your company allows one person to play multiple roles, then perhaps you can pass muster with "I'm not asking you to change the security chart and give managers access to source control, rather I'm trying to (temporarily) contribute with the developer role, which needs access to source control."
6. Make red tape problems known to your manager. Don't be malicious or whiney, but simply report the facts to your manager. "I can't complete the report module until procurement gets the Amazingnator rendering engine." Don't just eat it yourself and try building your own Amazingnator rendering engine over the weekend. Sure, it may make you today's hero, but the continual burden of not getting the proper resources because another department is broken will leave you bitter and exhausted.
7. Know the people who approve the tickets - Even the biggest bureaucracy ultimately boils down to individual people. If a ticket is languishing in the Data Services department, it's beneficial to ask Marge from Data Services if she's heard anything about the ticket, and if she has any advice.
8. Where feasible, keep skills in your own team - Because cross-team coordination is often slow in a bureaucracy, having the skills in your own team such that you don't need to go to another team can be a good ace-up-your-sleeve. I remember a web consulting gig when .Net first came out where the manager split development into separate roles - C# guys and SQL guys. He thought this would be easier to staff ("you only need devs with one skill or the other"), and result in higher quality ("each dev is an expert in their niche"). The problem for applications at that time was that C# and SQL were so intertwined that one without the other was like trying to run with only one leg. Coincidentally, some sub-teams secretly had their own SQL guys, and those teams flew.
9. Stack the deck - You know when you ask the procurement department to purchase a tool, that they're going to want forms filled out - how much does it cost, what's the business justification, does your manager approve, are there alternatives, etc... Ask upfront what forms they need, and have those ready. Else, you may be "sent to the back of the line", and need to wait days (weeks!) to get your chance again.
10. Focus on what people can do without spending money. This is related to knowing what each role does. Maybe that department can't give you what you your request because it costs money (more staff, purchase a tool, additional hardware, etc ...), but they can do helpful things that cost nothing, such as: provide "temporary" security access so you can run a test yourself, let you borrow a resource that they're not currently using (such as a VM server you can log into), switch the order of two tasks that has no impact on them but simplifies your life, offer information such as who you should unofficially talk to "make it happen". Ironically, although time is money, it is often easier in a bureaucracy to get time than get approval to spend money.
11. Mentally prepare yourself that it is inefficient. People can psychologically deal with crap if they're in "I need to deal with crap mode". So, just set your expectations and prepare yourself that bureaucracies are slow and inefficient. If things do go well, then congratulations, but if not, at least you'll be psychologically prepared for it.

See Also:

Book: Making Things Happen, Book: Managing Humans

10 tips to write shorter emails

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/10_tips_to_write_shorter_emails.htm]

There are some who think that the volume of email you send out directly reflects how much work you've done. So if you cc twice as many people, you've done twice as much work. For the rest of us, reading long emails is a time-consuming nuisance. To avoid being that person who irritates everyone with a daily novel-worth of emails, here's some tips to write shorter emails:

1. The shortest email is the one you never even had to write- perhaps the issue can be resolved with a quick IM or water-cooler conversation.
2. Refer to external resources with the URL instead of pasting large chunks into your email (like "see the wiki page at...". Although sometimes it may be more convenient for the recipients to just see the content of the URL that you're referring to (such as if they don't have access to the target URL).
3. Make good use of "To" vs. "CC". Some people even filter their emails to redirect CC.
4. If replying to a long email thread, consider deleting the older history that no longer matters.
5. If your email is longer, consider splitting it into a clearly-marked "Summary" (2 lines), and "Details". Make it easy for a busy person to get the main point of the email in less than 30 seconds.
6. "A picture is worth a thousand words", therefore a picture (like a diagram or graph) can often convey a concept much quicker than verbose text paragraphs. Consider also using outlines and tables for the same reason.
7. Differentiate between informal and formal emails. Informal emails are usually quick questions or responses to friendly co-workers about a current issue for which there isn't a big consequence (example: "Should the confirmation page have a link back to the home page?"). You can make them shorter because you don't need to re-explain the whole problem or define every term. Formal emails usually have big consequences, are usually followed up with a live meeting or phone call to confirm, and have the details in an attachment. (Example: "Is a rate of $120 per contractor hour acceptable?") This usually requires them to be longer such that you catch all the influential and controversial ideas to ensure that everyone is on the same page.
8. Consider tailoring your email to your target reader and their history of the topic at hand. For example, phrases like "Per our discussion yesterday..." can save you from re-describing a problem. Don't assume that because email can be forwarded to everyone, you need to write it to the "lowest common denominator".
9. Consider batching multiple questions into one email. Yes, that individual email may be longer, but as a group, the emails will be shorter. It also saves you from having to re-explain the context in each email.
10. Use good writing skills to condense your writing.

Advice to a college graduate seeking an IT job

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/advice_to_a_college_graduate_seeking_an_it_job.htm]

A lot of eager students will be graduating with CS degrees soon. Realistically, with almost 10% unemployment, out-sourcing, and a rough economy, it can be hard for a college-grad to find a tech job.

Here's a brain-dump:

1. Condition your mind
   1. Until you are employed, your job is to find a job. Prepare to spend at least 4 (maybe 8!) hours a day actively pursuing job opportunities.
   2. Furthermore, you're not seeking to "get a job", you're looking to "add value" to a company by solving problems in a technical field that you're passionate about.
2. Prepare
   1. Set up a linked-in account. This is an effective and professional way to keep track of people you meet.
   2. Make the equivalent of a business card that you can hand out as you meet people. Even a card saying something like "Joey Finklestein, my-email, 'Technology Specialist'" is good. The goal is to have your contact info easily available.
   3. Get your resume ready. make sure it downgrades to plain text in case you need to dump it into some online text area. I personally don't think resumes are the biggest deal. Yes, everything counts. But if you're blindly submitting your resume online, you're one among thousands, and it probably won't matter (sorry). If you meet someone in person, the impression you make will probably dwarf any wordsmith-ing on your resume. If you've actually got even a phone screen, the resume has already been sufficient.
3. Network. Meet people.
   1. Especially if you live in a larger city (like Chicago), prepare to go to a user group meeting at least once a week. For example, Chicago has dozens of user groups (LCNUG, ALT.Net, CNUG, SQL groups, IT, SharePoint, TFS, Design, etc...) Just google it, there's probably a group. Even if the group isn't exactly on target, go to the closet-related thing. Try to meet at least 3 people. Talk to them, ask them what they do, get their business card, give them your business card. Often user groups have recruiters who are trying to fill positions - talk to these people. Even if their position isn't an exact match, they may know of another position, they may have a position that frees up later, or they may just offer you good advice. Plant seeds.
   2. Keep in touch with your graduating class. Maybe they have leads.
   3. Go to job fairs - most community colleges offer these on a regular basis.
4. Start a corporate and professional online presence.
   1. Contribute to online discussion boards (like http://stackoverflow.com/)
   2. Contribute to an open-source project (check out CodePlex.com)
   3. Consider writing some articles (either start your own blog, or contribute on a free site like CodeProject. Even if you're just writing simple articles like "Joey's C# 101 tutorials", it's still beneficial. It tells employers that (1) you're motivated, (2) you can write (non-tech skills are a great asset), (3) you're pro-active enough to write. It will also make you more confident after you've explained things in an article. Try to write at least two short blogs, or one longer article, every week. Even if you're "not the writing type", employers want people who can write, and having a repository of your articles shows them, as opposed to summary statements at the top of a resume that say "has good communication skills". You can then also list your blog on your resume.
5. Continual Education - industry is a different beast than academia. The CS degree is great, but that's the beginning, not the end.
   1. Prepare to spend at least an 1 hour a day reading blogs that are relevant to the job you seek. Find who the top bloggers are in your field of interest, and read them. Probably get an RssReader.
   2. Read the job postings on online sites like Monster, Dice, HotJobs, etc.... You want to make sure you know all the buzzwords, and see what employers are asking for.
   3. Do charity projects. Many charity groups could really use the free help. Offer to do a tech-related project (assist with their website, do a data migration, write a tool to help them do some task). It doesn't pay cash, but it does pay in experience and relationships.
6. About applying...
   1. Ideally you want to meet someone in person (like at a user group). Next best thing is to meet someone in the company who can provide a referral.
   2. If you do apply online (with no personal reference), don't put all your eggs in one basket - apply to several companies. But don't spam Monster. Perhaps submit to a few companies each day, but not more than 10 companies at once. If you don't hear back from a company within 5 days, move on. Many companies send out an automated "we received your resume note", and then only personally follow-up if they're interested.

BOOK: Winning with People

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_winning_with_people.htm]

I am not a people person. However, I do love software engineering, and I recognize that no software engineering project will succeed without people. 95% of every project failure I've ever seen (or heard of) has ultimately been due to people reasons, not technical reasons - two coworkers can't get along, the manager leads the team in the wrong direction, the tech folks can't get the requirements from the business folks, the QA and dev teams bicker about what's "really an issue", etc... Hence, the cruel irony that just like I work on technical skills, I must also actively work on people skills. Sometimes that means not talking about work during the occasional co-worker lunch. Other times it means reading people-oriented books. This latter activity makes me consciously focus on people interactions.

One such book I read was John Maxwells' Winning with People. It was a Christmas present. John has written dozens of books about people, leadership, relationships, and all that. He's got a lot of wisdom. The book is a series of short chapters on various principles like "Never let the situation mean more than the relationship", and "the journey with others is slower than the journey alone." I found it practical, avoiding the common sense clichés like "be nice, work hard, etc..."

I saw a few big take-aways:

• "The journey with others is slower than the journey alone" (pg. 198)
• Quoting Andrew Carnegie, "No man becomes rich unless he enriches others." (pg. 230)
• "If individuals don't possess people skills, they very quickly hit a ceiling in their effectiveness." (pg. 242)
• "Most of us admire and respect people who sustain solid, long-term relationships." (pg. 259)

The book is also filled with good quotes, like:

• Quoted T.S. Eliot as saying "Half the harm that is done in this world is due to people who want to feel important." (pg. 11)
• Quoted someone "the difference between who you are today and who you will be in fie years will be the people you spend time with and the books that you read." (pg. 13)
• "Actions are remembered long after words are forgotten" (pg. 42)
• "People who add value to others almost always do so intentionally."
• "We often expect maturity to come with age, but the truth is, sometimes age comes alone." (pg. 63) - There are young devs who are great, and "experienced" devs who are not.
• "Ultimately the things that bring fulfillment involve others." -  I would find it more fulfilling to use an old technology with friends, where we actually ship the product, then a new "cool" technology by myself.
• "The best way to keep from stepping on other people's toes is to put yourself in their shows." (pg. 73) [I see this continually in the classic software rivalries: managers who want to deliver vs. techies who want to do "cool" stuff; application developers vs. QA, application developers vs. IT infrastructure, etc...]
• "I made a mistake of trying to impress everybody" (pg. 95) - Software engineering is too big, so you can't possibly know it all, so inevitably you'll meet people who know more than you. One of the dumbest thoughts that ever crossed my mind as a younger consultant was "everybody asks me for help, but I don't need to ask anyone else - I must be doing great". Ah, the cluelessness of being young.
• "If you don't like people or don't believe in them, you won't be able to fake it" (pg. 104). Tim's translation: "People can tell when you think they're a moron."
• "Caring for people should precede confronting people" (pg. 107)
• "Quitting is a permanent solution to a temporary problem." (pg 111)
• "Most of the time when you confront people, they will have an emotional reaction." (pg. 114)
• "Most people hate confrontation, but they love resolution." (pg. 115)
• "If you are not honest with yourself, you will not be capable of honest with others." (pg. 126) - Example: If you deceive yourself into thinking the big task will be done in only 4 days, you're going to struggle giving accurate status reports to management.
• "It is more rewarding to resolve a situation than to dissolve a relationship." (pg. 132)
• Quoting someone else: "If you make every game a life-and-death proposition... you'll be dead a lot." (pg. 138)
• Quoting someone else: "A successful man in one who can lay a firm foundation with the bricks others have thrown at him" (pg. 222)
• "People are an appreciating asset only if we are willing to invest in them." (pg. 233)

See also:

BOOK: Making Things Happen, BOOK: Bringing Out the Best in People

Why share knowledge with others?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_share_knowledge_with_others.htm]

I'm a big advocate of knowledge sharing. However, I understand why some developers may be hesitant to do so. We live in an era of unprecedented competition. People (and therefore Companies) compete against one another for employment opportunities, promotions, recognition, mindshare, and plain-old-power. In today's cut-throat world, it almost seems counter-intuitive to "undermine" yourself by sharing your knowledge (read: "competitive advantage") with others (read: "competition").

While obviously you shouldn't share trade secrets and proprietary knowledge with the competition, I still think there are a lot of good reasons to share general knowledge with the community, and especially your coworkers.

• It teaches you
  • Explaining something to others forces you to better understand it yourself.
  • It is self correcting - By sharing your knowledge, the other dev may be able to help you improve it by offering tweaks or suggesting gaps that you need to fill.
  • It provides a chance to practice your communication. To communicate, you need a "receiver", someone who wants to catch (i.e. listen to) whatever message you're "throwing". This means that the message needs to be relevant. What's more relevant than a message that is solving the problem that the "receiver" actively wants solved?
• Social benefits
  • To have a friend, you need to be a friend. If you never share your stuff (knowledge, tricks, tools), people may be hesitant to share their stuff with you.
  • Some people just enjoy helping others.
• It's part of your job
  • It frees up co-workers to do something useful (which could in turn benefit you, and more importantly, the company who is paying you), as opposed to them re-inventing what you've already done.
  • It's your job as a good developer - Good developers share knowledge. Also, when a company is paying you to code, it's no longer "your code", but the company's code, and therefore the company has a right that tricks and knowledge be shared amongst the team.
• Demonstrate leadership
  • Knowledge-sharing increases your credibility. By sharing objective things that other devs can verify to be correct, these devs are more likely to trust you on subjective opinions or predictions that are much harder to verify.
  • Become a thought-leader - Often consulting firms encourage their star consultants to demonstrate thought leadership by blogging, writing articles, or contributing to open source projects. Sometimes this is great marketing for that company, and even leads to sales. For example, thousands (millions?) of people use CruiseControl from ThoughtWorks, which in turn gives ThoughtWorks name recognition and marketing.
  • It is necessary in order to be promoted. Leaders communicate, and usually the higher up you go, the wider the audience you need to share knowledge with. If you never practice knowledge sharing until you absolutely have to (via a job demand), then you will probably not be very good at it.
  • It helps make your approach the official standard (which may be good or bad). If you hide your tricks and code, only you will use them. If someone publicizes and shares their code - even if it's worse than yours - their code will be used by more people and hence adopted as the "official" team approach.

There are many ways to share your knowledge, such as:

• Wikis
• Email
• Automated governance
• Sample applications
• Team meetings
• 1-on-1 meetings (like a Code Review)
• Blogging

 

You are not alone

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/you_are_not_alone.htm]

I continually try to get more involved in the developer community (such as via user groups and tech events). This gives me the opportunity to talk to developers across a wide spectrum of different projects. One type of developer, for whom my heart really goes out to, is the lone developer struggling in isolation. They're trying, but they're on a team of one - the only consultant on a project, a remote developer working from home, or the only developer in a one-person "department" of a small company.

The problem is that software engineering is too hard to do alone. It's easy to feel like you're on the outside looking in - while other departments have niche experts and devs to cover your back, you're left all by your lonesome to figure out the entire thing yourself.

Sometimes you can get out of the situation - switch jobs or press the business sponsors to hire a secondary dev (do they really want the entire project resting with one person, without any backup if you become unavailable?)

However, even if you cannot change your department or project's headcount, you are still never alone. Especially with the online developer community, blogs, forums, user groups, conferences, books, and the like. It is one joy of software engineering in today's world - you are never alone.

Related: What if you're a big fish in a small pond - life without a mentor?

You know management is going to ask for it

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/you_know_management_is_going_to_ask_for_it.htm]

Time is precious, so it's natural to always be on the lookout for short-cuts. But certain short-cuts end up being anything but short, costing you far more later than if they had just been done up front. In other words, even if management promises "don't waste your time on it", you know that they'll come back to you and ask for it:

• Cross-browser web applications - they say "just worry about IE for now", only to want FireFox a year later.
• Refactoring your navigation - they're going to want a page referenced from multiple places.
• Scalability - They might say "just get it done now", but they'll want it to scale up.
• Changing any environmental value - they may let you assume some environmental value, like the hard-drive disk volume or some url, but you know it's going to eventually change.
• Turning static data into dynamic data - any hard-coded data (like entering a customer service phone number) is going to change.
• Changing relationships from one to many - you want to pass in a single scalar, but really the business rules require an array (or a one-to-many database relationship).
• Allowing client customizations and overrides -
• Some way of doing online help documentation -

I lose track of how many changes like these happen. It's best to just always be prepared for it. Even if the manager (or client) signs of on some waterfall doc, it won't matter, because without the change they'll feel "cheated" and resent the developer.

The kicker is that with the right starting framework, tools, and code-smell, many some of these changes take roughly the same amount of time to "do right" as to hack them (like cross-browser JS or using app.config values for literals like paths), especially when it comes to total cost of ownership.

How do you know when a project is screwed?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_do_you_know_when_a_project_is_screwed.htm]

At the MSDN DevCon last month in Chicago, one of the groups in the community center had a very good discussion going - "How do you know when a project is screwed?"

 

A lot of good ideas floated around:

• There is no test code

• All code just has  "catch (Exception ex)" everywhere

• There is no source control - really some projects still just make zip file backups, not even using the free SVN.

• Reinventing basic framework methods

• Lack of team innovation

I think that team chemistry and discipline is also a very good indicator of project success. A team that hates each other will likely fail, even if they're all individual stars. So, I think another good indicator of failure is bad team chemistry.

 

This sort of thing is very-opened ended., I'm assuming that anyone who's been around long enough has seen a dying project, and there are a slew of different reasons.

How to discourage a developer from working overtime

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_to_discourage_a_developer_from_working_overtime.htm]

A while back I pondered what it would take to motivate a developer to work overtime. I was thinking about the flipside of that - what would discourage a developer from working overtime?

• Constantly change the feature on them - This can be like pulling the rug out from under their feet. I saw this all the time in consulting - for some projects, everything was "of absolute importance". People get burnt out and stop being motivated. After all, why waste my evening plowing on a feature, if the whole thing is just going to be scrapped tomorrow at some executive's whim?
• Assign boring tasks - This speaks for itself.
• Provide slow hardware - Not having the proper tools to do your job is just demoralizing. Imagine your manager with a slow laptop - would they wait 60 seconds while their machine freezes when they try to send a single email, or wait 10 seconds every time they clicked a new cell in Excel? Of course not, they'd get furious about how such a slow machine prevents them from effectively doing their work. Same thing for developers - every time a laptop freezes when you try compiling, getting source code, or running tests, it just demoralizes and frustrates the developer. Yes, savvy developers can optimize their machine, but at the end of the day, the .Net development environment has certain hardware needs. For example, it's just wasting their time asking a developer to work on a machine with only 1 GB ram, or 5400 rpm hard drive, or a 1 GHz processor. They'll spend idle time throughout the day - constantly losing their rhythm. The manager saves a few hundred bucks, but both demoralizes their developer and diminishes the return of a $100,000 resource (total cost of the developer = salary + benefits + other stuff HR could tell you about). It's an absolutely clueless business model.
• Never reward positive accomplishments - Management can offer "non-monetary" rewards like verbal affirmation, or allotting schedule time to pursue a promising research project.
• Waste their time during the normal work day  - If a developer already "wastes" time due to excess meetings, pointless issues, rework from original bad design, or waiting on a slow machine, why would they spend their own evening to "make that time up"  - time that should never have been taken from them in the first place.
• Assign them to a "sinking ship" project - Some projects are fundamentally screwed - the core architecture is hopelessly lost, or there's already a run-away bug list, or the spec is unstable (or even contradictory). There's little motivation to work on this kind of suicide project.
• Have them do a task the hard way because the manager won't pay for the proper tools. For example, have a developer spend 100 hours writing an ajax datagrid, when you could just buy third-party controls for much cheaper. Or, have a developer scour through thousands of lines of database plumbing instead of using a code generator or ORM.

The irony of it all is that the rich get richer and the poor get poorer - i.e. A good environment will motivate the developers to work overtime (or at least be more productive during the day), hence getting farther ahead. Whereas a bad environment will constantly demoralize, frustrate, and slow down its developers, thus getting farther behind.

This is just a partial list - anything to add? What sort of things discourage you from working overtime?

Why I'd rather be an optimist

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_id_rather_be_an_optimist.htm]

Some programmers take pride in calling themselves either an optimist or a pessimist. Both have their positive and negative stereotypes: The out-of-touch bubbly optimist vs. the encouraging can-do optimist; the always grumpy pessimist vs. the face-the-facts pessimist.

Part of it is that most producers tend to be optimists, as it takes a can-do attitude to carry out the positive act of creating. Most critics/complainers tend to be pessimists, negatively and constantly pointing to the shortcomings. However, these are not equal positions. The producer can produce without the critic, but that the critic needs someone else to produce something so that they have something to criticize. In other words, the producer (usually the optimist) does not need the critic (usually the pessimist), but the critic needs the producer. It's like riding a sled down the hill vs. pulling it back up - they're not equal tasks; one is much easier. Likewise, a room full of complainers will never actually build something. While constructive feedback is great, a purely negative feedback loop isn't constructive. It also will get on other coworker's nerves.

Some pessimists think they're providing a great service by always pointing out the flaws, lest the optimists lose touch with reality. However, "reality" doesn't need any help in reminding developers about the facts of life. It's got the compiler, project plan, and end-users to do that.

Ideally, as with everything else in life, there would be a good balance. But, everything considered, if I had to choose one I'd rather be an optimist. It's been said that "The pessimists may be right, but the optimists have more fun along the way."
 

 

Bad Interview Question: What is your greatest weakness?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/bad_interview_question_what_is_your_greatest_weakness.htm]

For technical interviews, I think "What is your greatest weakness" is one of the dumbest interview questions ever. It's like the recruiter thinks they're being so smart and sneaky ("ah ha, this unsuspecting candidate will reveal all their shortcomings as I judge them"), but it really misses the point.

 

Problems with this question:

• If the interview cannot determine your weaknesses from normal interview questions, are they really weaknesses? It is part of the recruiter's job to determine your weaknesses, and by directly asking you, they're essentially asking you to do their job for them.

• Most people aren't even aware of their biggest weakness, especially because human nature always sees ourselves in the best light possible.

• It's an abrasive question that puts the company in a bad light. People want to talk about their successes and how they'll add value, not their mistakes.

• Does the interviewer actually expect the candidate to tell the complete truth about their own flaws?

• To avoid ivory-tower syndrome, (in my opinion), recruiters should not ask behavioral questions that they themselves are not prepared to answer.

• It's a dead-end question that prompts the recruiter to pick the "least of the evils" - if you're just discussing your negative qualities, you're not going to look like a positive candidate.

• If I knew my weakness, I'd already be fixing them.

• It's very dull, and shows no creativity from the interviewer.

• This sort of question isn't going to impress a candidate. Often, the interview is really two ways, with many companies all trying to woo the star candidates.

Really lame replies:

• "I work too hard", or "I try to hard". --> anyone who has been around can see straight through this.

• "I do such a good job that it makes everyone else envious of how great I am."

• "I don't really have any flaws." --> everyone has limits, which is very different than saying that you do have shortcomings, but they occur mostly in other, unrelated fields, or long ago when you first got started.

• "I've never been in a position with enough influence to do any damage, so I'm not sure."

Possible good replies:

• Humor: "You know, you could get a really good answer for that if you just talked to my wife." (or husband/spouse/significant-other )

• Serious: "While I've made mistakes in other fields, like buying my first car, for years I've been putting most of my eggs into the software engineering basket precisely so I don't make huge costly mistakes anymore. But we can discuss my early car-buying experiences if you'd like."

• Confident: "Let's have an interview and you tell me."

• Change topic: "Here's how I've dealt with mistakes that the company has made, and turned them around to be profitable..."

• Pick a small, past event: "When I first got started, 10 years ago, I used VSS for source control. The default single-user lock model really messed up our multi-team project. Now I'm happy that we always use Subversion."

• Sarcasm: "My  biggest mistake ever - like single-handedly causing the stock market crash of 87 - I don't do those kinds of things anymore." (you'd need more charisma than I have to pull it off)

• Smart Aleck: (when you don't want the job) pick a topic that's way over the recruiter's head. I'm trying to think of an impressive example, but I'm sure the readers of this blog would just tell me how simple it was.

• Smart Aleck (when you don't want the job): "What would you consider a failure? Perhaps you can tell me some of your greatest failures so I know what kind of things you're looking for."

At Paylocity, I don't think I've ever asked a candidate this. Instead, I'll ask "what areas of development do you enjoy", or "what areas do you wish you had an opportunity to learn more about". The goal is not to trick people with dumb gotcha questions, but (for me) to figure out where their passion is. I prefer a positive approach of "what are you passionate about" as opposed to a negative approach of "what are your flaws". At Paylocity, we don't ask people to do what they're bad at, we ask them to do what they're good at - i.e. play to their strengths, not their weaknesses. Also, the interview should be an indicator of what the company is about, and what kind of company goes around asking their employees "what do you suck at most"?

 

"I prefer my way of doing it to your way of not doing it"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/i_prefer_my_way_of_doing_it_to_your_way_of_not_doing_it.htm]

I once heard this quote - I forget the context or who said it - but I really like it. Software Engineering is full of second-guessers and Monday-morning quarterbacks. Many projects seem to have that pessimist who snubs the teams' attempt to do something because it's not as good as that "perfect past project" that they were on. There's something to be said for the developer who just gets it done - even if the code isn't the best.