Tribal golB: Dec 2009

Dear Ari,

I am in [country] at the moment, when I get better web access I look forward to looking over your web site.

You do know engineers are not supposed to have feelings don't you ;-)

Dear Ari,

It gave me something to think about -- I am glad you started this.

Ciao bello,

so, how are you? child born yet? how about you send me a photo!!! how is your mom, [wife]? i deleted my account at [social network] and lost all my contacts because of that.

listen, I have quick qestion for you. I *NEED* to "hack" a gmail account, do you think it's doable? I'm sure you have an idea about this.

so long, say hi to everybody, waiting for photos and ideas!

[name] (in case you havent figured me out;=)

Dear Ari,

After trying several times to read this and get you good feedback, I'm going to have to confess to wanting to block my emotions on this one... this just isn't how I work psychologically, so I can't really engage with the subject matter. I have to imagine there are better reviewers out there in the software world than me.

Sorry about that.

sweet:=) why do you worry about me? i need to get some pix from that email, dont see my problem feelingwise there. i was not asking if YOU per say could do it but if you thought its possible

(via Google Translate)

I would like to participate in the group, which you collect.

As the entrance fee would suggest its symbol (see attachment).

Congratulations on your new position at Silicon Valley Computer Tribe!

I did not know you were Native American "Chief" ;-} Congrats to a very talented man.

Dear Ari,

I don't know if I'm the right person to write my impressions of the tribe meeting. As I said last week, this is not something I'm looking for or interested in. I personally don't believe in its maxims and as such would have a hard time writing about it without being overtly negative. However, I can appreciate that you've found something in it that is beneficial to your life.

Anyway, I saw something today that I thought you'd find interesting considering your interest in pixel mosaics:

Congrats again about becoming a father and good luck with your tribe and projects.

Dear Ari,

My Gran has been looking to buy an aeroplane in a bottle forever, do you know if there is anywhere she could buy one from??

Dear Ari,

The article certainly resonates with me. I used to be a software engineer and a manager of software engineers.

While some may deny it, and "macho through", I found a great deal of emotion attaches to software engineering, whether individual pride (or fear or shame) or group versions of the same. We found that encouraging group ownership of code helped people be willing to critique and receive critique, while ocassionally individuals would do exactly as you say about avoiding source control etc and try to build "private" sources, then get really really defensive about anyone reviewing them. I cannot recall a single instance where the individuals involved in this behavior did not have an over inflated opinion about their own abilities. I guess they tried to protect their self image, but ultimately it never worked.

Interesting, well worth it, and I wish you the best of luck.

Dear Ari,

Interesting article, with good observations.

Who is the author?

Shame. I am completely open for criticism and suggestions and will expect to influence the design of the software. In Database design I do adhere to the industry standards and am quite open to suggestions and prefer to make decisions via discussions. To some extent, I expect the other developers to do same. Code flexibility is important.

Rejection. I know, that live dog is better, than dead lion. So, there should be a finite feature set, which should be defined by the team. This set should be adequate to achieve the main goals of the project. The rest 'nice to haves' should be left for future marketing possibilities. The only thing, which I want for these non-implemented features is ability to plug them in in the future with minimum pain.

Usually for Database based applications this main overhead is contained within the data model with very small overhead to the application itself. So, I prefer to have this small overhead during design stage (over-design the DB) and having easily expandable application.

Disappointment. I am probably too ready for disappointments. I am not interested in spending too much time and efforts if I do not see 'light in the end of tunnel' and the tunnel should be short enough. Most likely this is the reason, why I am still working here instead of having a fortune and retiring.

Fear. The bugs are bugs and we need to address them depending on their relevance to the company goals. Over-testing the code is maybe a good idea, but it is expensive one and we you should always weight the severity of potential issue due to not investing time into a more sophisticated testing mechanism vs lack of features due to not investing time into their development. There is no bugless software. And it is not going to be.

Dear Ari.

An interesting premise (been talking to [name] about it, I see!) I think you're right about emotions making better allies than enemies, but I think it's somewhat simplistic to divide people into the ones who are "with it" and the ones who are not. I assume that everyone manages their emotions as best they can and has their reasons for experiencing or expressing these emotions (or not).

In Nonviolent Communication they talk about needs and the strategies people use to meet those needs. The idea is that people's needs aren't in conflict, but their strategies may be. The further idea is to become aware of the needs and to be flexible and increase communication about the strategies for meeting them. NVC doesn't talk about this, but you could also assume that some strategies are more effective than others. I think it's good to examine what it is that people are trying to accomplish with their particular strategy, and to offer them better options, but it's important to assume that the underlying needs are legitimate and to probe into those and see what they might be.

Also, I assume that, for most of these issues, there is no one answer. All people and societies have to find their own "sweet spot" -- a balance of being open to feedback, while being able to avoid the negative consequences of being overwhelmed or paralyzed by certain emotions. I certainly wouldn't assume that the way the "real world" -- i.e. certain societies -- goes about enforcing shame, fear or rejection on people is necessarily healthy or wholesome. And it's very fine to talk about being open to those feelings in theory, but anyone who's ever been incapacitated by fear or shame etc. knows just how non-constructive that openness can be when it's chronic or not balanced by other emotions.

The overall lesson to geeks that embracing feelings rather than trying to block them out is a good one, though, I think.

Dear Ari,

I think your emotional-engineering paper is coming at the situation From the wrong end. I can't imagine doing good engineering in an environment of shame, rejection, disappointment and fear.

All of your examples have opposites and those are more motivating: praise, acceptance, success, and joy.

I change my coding style to fit my peers because I get praised for doing so and because uniformity of coding style has tangible benefits.

Avoiding feature creep isn't about rejecting bad features, it's about strengthening the core features of a product.

Experiencing disappointment early isn't about the benefits of disappointment, it's about limiting the scope of disappointment, it's about finding success faster.

Test driven development isn't about fear. We all accept the red lights, but what's motivating about testing is the joy of seeing them all turn green eventually.

Hope that helps.

Dear Ari,

Interesting article on emotions and programming. Don't agree about shame though. Point is to move beyond shame. To embrace not criticism, but assistance. Not to shame folks, but to engender a loving community where "failure" is okay if it's a waypoint to success.

Indeed, all your emotions are negative ones. My 2 bits: the trick to successful software is 1) attract good people 2) create a positive environment that focuses on healthy emotions.

Totally agree. But, in my experience, you get a better results when the working environment is 90% carrot and 10% stick rather than visa versa.

As you suggest, it's important that we deal with negative emotions. And that a good working environment inflict them from time to time. But, you'll get a better product if you spend most of your time creating a work environment with lots of positive emotions.

Most emotions come paired. Negative when we screw up, and a paired opposite when we do well. Shame/pride for example. It's better to create an environment where folks are more likely to feel proud when the do well, than shame when they screw up. Hence the dictum, praise publicly, criticize privately.

Dear Ari,

On your topic of emotions in engineering, its definitely topical. The conclusion of a recent review of Windows Server 2008 R2 at ArsTechnica described some of the changes that Steven Sinofsky implemented within the Windows Server team - it was described there as 'testosterone-based engineering' (whoever had the loudest voice at meetings). Sinofsky managed to change it and now they have had two high-quality releases in two years.

http://arstechnica.com/microsoft/news/2009/12/windows-server-2008-r2-in-depth.ars

Dear Ari,

Your paper is quite interesting. I'm afraid I know very little about industrial software engineering though, so I'm not sure what feedback I can give you.

To manage your subscription details, please visit:
http://unieddevt.cmph.org/f/[id]
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Dear Ari,

I think your paper is excellent, except that it is too short! You need to spell things out in detail and with more use cases.

You know that [Name] is back in [Town]? The Aristo-Markup-ologists should have another dinner together!

Dear Ari,

Nice meeting you today at [organization] luncheon. Your ideas on sharing emotions for engineers are fascinating! Never thought that is a possibility. Engineers are perceived to be analytical, rational and unemotional. How interesting!

I was intrigued to hear that you like working with people, understanding their needs and listening to their emotions. What makes you being like that? That's more like the personality of sale and marketing professionals. Am I being steoreotypical?

[Name] here,

I'm protecting myself from receiving junk mail.

Please click the link below to complete the verification process.

You have to do this only once.

[url]

[Company Name] - Take control of your inbox!

------------------------------------------------------------

You are receiving this message in response to your email to [Name], a [Company Name] customer.

[Company Name] requests that senders verify themselves before their email is delivered.

When you click the above link, you will be taken to a page with a graphic on it. Simply read the word in the graphic, type it into the form, and you're verified.

You have to do this only once per [Company Name] customer.

Dear Ari,

I too glad that we met at [function]. I'm sorry that I didn't get a chance to talk to you. Would you let me know that where and when your group meets?

Dear Ari,

I truly appreciate your attempt to address the common emotions all of us have experienced at a work place as a software engineer or their manager or a cross functional counterpart and bring them to our awareness.

All the emotions you listed are valid and usually cannot overcome by logic. But we have a choice about the attitude and respond. My feelings are it's critical that the leaders of the software development realize the importance of foster trust and synergy in a team where people do not need to carry unnecessary anxieties, insecurities, fears, and stress. If you have a quick 2 seconds answer to someone else's question, do you let them spend hours to research for it? Do you prefer to work with someone who are smarter and know much more than you? Or you prefer to work with someone who is less competent than yourself, so you'll feel more secure? Are you overly competitive that you need to feel better than others all the time in order to feel good about yourself? Those are set of the questions good for all of us to answer to ourselves. If we are all thoroughly convinced that we will all become better off to be more tolerant to different opinions, more compassionate to co-workers, more willing to share our talents, more respectful to others, practice work and life balance to improve quality code, and there is REALLY NO NEED to stab anyone on the back to succeed, then we'll have a long list of positive emotions for being a software engineer.

Dear Ari,

I'm a bit confused, is the tribe's focus are on Ed [Seykota]'s teaching or the feelings of Software Engineering?

Dear Ari,

I'm a software engineer/therapist co-founding [a new] venture with [Name].

Interesting to hear of your work, much needed I think.

I work with a lot of engineers in my therapy practice and have been thinking of starting some group sessions.

I'd be interested in talking more.

Dear Ari,

I have re-read the white paper again and below is what I felt: I agree with the Structure of the mind which was illustrated by Ed [Seykota].

I love the Trading Tribe member philosophy outlines.

It would be wonderful that there is a group of people willing to be there to support each other without the risk of being judged regardless what you feel.

I wish to learn to better control, or more precisely to better direct the flow of inner energy that caused by various emotions by the events of the working days we all have to a more positive channel.

It's amazing that how much similarity in problems solving of any problem vs. trading on the market! Being a trader at one point of my life, I understand exactly what it means by follow the trends, let winners ride and cut losses and manage risks!

Above all, I do sincerely care the feelings of others. I wish to eliminate my irrational out of the control, self-destructive behaviors.