Tech Trained Monkey

Everyday Problem Solvers

Category Archives: Motivation

Why english

As you know (or not) I’m Brazilian. I was born in Brazil, studied in Brazil, I work in Brazil, and (I’m ashamed to say) never been to a English speaking country. Nevertheless my blog is written in English and more often than not I hear the question “Why English? Why not Portuguese?” and I my answer always is “Because I want to reach as many people as possible”. Reaching people is not why I write this blog (my motives are strictly selfish) but it’s the motive why I do it in English.

I also program in English. When people ask me why I reply: Read more of this post

Reinvention of the Real Programmer

In classical computer science the Real Programmer (a.k.a Hardcore Programmer) is a mythical man who writes code almost in bare metal. The most high level language he uses is ANSI – C and he debug code in hexadecimal and things like that…

I don’t know anyone that fits that description but investigating and (mostly) philosophizing I came up with a real-world definition for the Real Programmer:

  • The Real Programmer leaves no broken windows behind. Ever.
  • The Real Programmer works with his project manager, not for his project manager.
  • The Real Programmer does not complain about anything. Never.
  • The Real Programmer knows that fixing bugs is more important than implementing new functionalities. (See first point.)
  • The Real Programmer works because he wants to, and when he wants to.
  • The Real Programmer uses a IDE, and high level languages, but he’s not afraid to go back to Assembly if necessary.
  • The Real Programmer does not re-invent the wheel. The Real Programmer re-engineers and re-implements the entire car.
  • The Real Programmer documents his code, in a way that a six-year-old can understand it.
  • The Real Programmer knows that the currency for computers is performance. He’s always thriving for the best performance so he can pay a beautiful interface and other items.
  • The Real Programmer does not TDD. The Real Programmer knows that only making the “bare minimum” is not enough to get to Carnegie Hall.
  • The Real Programmer delivers, but he’s not afraid to delay milestones if he feels that his work is not finish yet.
  • The Real Programmer does not fear tight schedules and rejoices on phrases like “The client changed his mind completaly”.
  • The Real Programmer knows how to separate trendy frameworks from real groundbreaking frameworks.
  • The Real Programmer doesn’t wear suits.
  • The Real Programmer’s computer is not a desktop nor a server. It’s a workstation with more than 1 monitor.
  • The Real Programmer only uses headphones when he’s working in a noisy environment.
  • The Real Programmer is always on top of the situation. He’s calm and never looses his temper. Like a Zen Buddhist master

Think I forgot something? Please fell free to comment!

Leading by Example

It takes discipline for development teams to benefit from modern software engineering conventions. If your team doesn’t have the right kind of engineering discipline, the tools and processes you use are almost irrelevant. I advocated as much in Discipline Makes Strong Developers.

But some commenters were understandably apprehensive about the idea of having a Senior Drill Instructor Gunnery Sergeant Hartman on their team, enforcing engineering discipline.

Scene from Full Metal Jacket, Gunnery Sergeant Hartman Pointing
You little scumbag! I’ve got your name! I’ve got your ass! You will not laugh. You will not cry. You will learn by the numbers. I will teach you.

Cajoling and berating your coworkers into compliance isn’t an effective motivational technique for software developers, at least not in my experience.If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn’t to brainwash everyone you work with, but to negotiate commonly acceptable standards with your peers.

I thought Dennis Forbes did an outstanding job of summarizing effective leadership strategies in his post effectively integrating into software development teams. He opens with a hypothetical (and if I know Dennis, probably autobiographical) email that describes the pitfalls of being perceived as an enforcer:

I was recently brought in to help a software team get a product out the door, with a mandate of helping with some web app code. I’ve been trying my best to integrate with the team, trying to earn some credibility and respect by making myself useful. I’ve been forwarding various Joel On Software essays to all, recommending that the office stock up on Code CompletePeopleware, andThe Mythical Man Month, and I make an effort to point out everything I believe could be done better. I regularly browse through the source repository to find ways that other members could be working better.

When other developers ask for my help, I try to maximize my input by broadening my assistance to cover the way they’re developing, how they could improve their typing form, what naming standard they use, to advocate a better code editing tool, and to give my educated final word regarding the whole stored procedure/dynamic SQL debate.

Despite all of this, I keep facing resistance, and I don’t think the team likes me very much. Many of my suggestions aren’t adopted, and several people have replied with what I suspect is thinly veiled sarcasm.

What’s going wrong?

I’m sure we’ve all worked with someone like this. Maybe we were even that person ourselves. Even with the best of intentions, and armed with the top books on the reading list, you’ll end up like Gunnery Sergeant Hartman ultimately did: gunned down by your own team.

At the end of his post, Dennis provides a thoughtful summary of how to avoid being shot by your own team:

Be humble. Always first presume that you’re wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you’re certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to the entire group. Widening the audience is more likely to yield defensiveness and retribution. The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.

The best way to earn credibility and respect is through hard work and real results. Cheap, superficial substitutes — like best practice emails sent to all, or passing comments about how great it would be to implement some silver bullet — won’t yield the same effect, and are more easily neutralized.

Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you’re just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they’ll detest you for it. If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn’t guarantee that the initiative will fly, and the effort might be for naught, but the team will identify that it’s actual motiviation and effort behind it, rather than an attempt at some easy points.

There is no one-size-fits-all advice. Not every application is a high-volume e-commerce site. Just because that’s the most common best-practices subject doesn’t mean that it’s even remotely the best design philosophies for the group you’re joining.

What I like about Dennis’ advice is that it focuses squarely on action and results. It correlates very highly with what I’ve personally observed to work:the most effective kind of technical leadership is leading by example. All too often there are no development leads with the time and authority to enforce, even if they wanted to, so actions become the only currency.

But actions alone may not be enough. You can spend a lifetime learning how to lead and still not get it right. Gerald Weinberg’s book Becoming a Technical Leader: an Organic Problem-Solving Approach provides a much deeper analysis of leadership that’s specific to the profession of software engineering.

Within the first few chapters, Weinberg cuts to the very heart of the problem with both Gunnery Sergeant Hartman’s and Dennis Forbes’ hypothetical motivational techniques:

How do we want to be helped? I don’t want to be helped out of pity. I don’t want to be helped out of selfishness. These are situations in which the helper really cares nothing about me as a human being. What I would have others do unto me is to love me– not romantic love, of course, but true human caring.So, if you want to motivate people, either directly or by creating a helping environment, you must first convince them that you care about them, and the only sure way to convince them is by actually caring. People may be fooled about caring, but not for long. That’s why the second version of the Golden Rule says, “Love thy neighbor”, not “Pretend you love thy neighbor.” Don’t fool yourself. If you don’t really care about the people whom you lead, you’ll never succeed as their leader.

Weinberg’s Becoming a Technical Leader is truly a classic. It is, quite simply, the thinking geek’s How to Win Friends and Influence People. So much of leadership is learning to give a damn about other people, something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated.

Internet and Intelligence

Intelligence is a very controversial topic. There’s no official definition that is accepted worldwide, but among all the definitions, scholars usually adopt one of the two:

A very general mental capability that, among other things, involves the ability to reason, plan, solve problems, think abstractly, comprehend complex ideas, learn quickly and learn from experience. It is not merely book learning, a narrow academic skill, or test-taking smarts. Rather, it reflects a broader and deeper capability for comprehending our surroundings—”catching on,” “making sense” of things, or “figuring out” what to do.Mainstream Science on Intelligence

or

Individuals differ from one another in their ability to understand complex ideas, to adapt effectively to the environment, to learn from experience, to engage in various forms of reasoning, to overcome obstacles by taking thought. Although these individual differences can be substantial, they are never entirely consistent: a given person’s intellectual performance will vary on different occasions, in different domains, as judged by different criteria. Concepts of “intelligence” are attempts to clarify and organize this complex set of phenomena. Although considerable clarity has been achieved in some areas, no such conceptualization has yet answered all the important questions, and none commands universal assent. Indeed, when two dozen prominent theorists were recently asked to define intelligence, they gave two dozen, somewhat different, definitions. – American Psychological Association

Some think that this is a “I say tomato, you say tomahto” kind of discussion, to the propos of this post you can choose any of them.

Scientists did demonstrated that intensive use of the internet does decrease our capacity to concentrate. Some people in possession of that fact concluded, (in my opinion and racionalization) wrongly, that because we can’t concentrate we are getting dumber… In my opinion the lack of concentration does not allow us to show how intelligent we really are. In my opinion lack of concentration is like a dirty window, it’s hard to see through it, but the inside of the room is there!

The ability to concentrate is very powerful, but it’s not everything. Never concentrated so hard on something and actually got stuck? And then left, watched the birds while drinking some coffee and returned to the problem with a fresh perspective and a rush of creativity?

Common sense states that if you know something, you don’t need google for it (ok common sense don’t mention google), and the more you know, more intelligent you are.

At a first glance you might think that common sense is right again, but lets not confuse intelligence with the ability to hold information! Yes intelligence is commonly followed by good memory, but not the way around. Rain Man had an extraordinary memory but performed very poorly on all the areas of intelligence! Einstein himself stated “Never memorize something that you can look up“. Google does help us a lot in this point!

In the business world intelligence is highly associated with the ability to solve problems. The internet and its vast amount of knowledge did not turn those who can use it properly more intelligent! Notice that these people did not solve problems! Other people have! They were intelligent enough to think that maybe someone else already had the problem that they’re trying to solve, solved it and posted a How To about it! but that’s it, no real creation. R&D people only use google to find out how ahead they are, compared to the rest of the world… they don’t expect to find a “how to solve my problem”, because if they do, whats the point on reinventing the wheel?

I would like to conclude quoting Voltaire:

Judge a man by his questions rather than by his answers.Voltaire