How to Speak Engineer

You’ve heard of Through a Dog’s Eyes, How to Speak Dog, and Inside a Dog. Somehow, there is ample literature on the perceptions, natures, and ways to facilitate good communication between man’s best friend and ourselves (assuming you, the reader, are human — apologies if you are not). At some point, while all of these researchers were following around doodle-this and doodle-that and watching them sniff butts, you would think one might observe and potentially interact with a far more important element of society that has the ability to build or break, well, everything.

The engineer.

As a non-technical person, how do you begin building a relationship with and speaking to an engineer? One of my friends basically asked this question of me. First, it is important to note that he and I have a very good relationship and talk regularly. So, obviously, he already speaks some level of engineer. Just as there are cats that will nip or swat at your hand at the least threatening of touches, there are engineers that require a deeper emotional understanding in order to craft a powerful relationship with good communication.

But, let us assume you do not have a me — a translator of technology personalities — and you do not have the ability to carefully select engineers that you will have an easy time building relationships with. How do you go about the creation of a social and professional rapport that will make 1) interactions more pleasant 2) reduce tensions all around and 3) improve your products.

Listen

First, when you are talking to an engineer, be aware of how much time you spend listening versus speaking. Often times, engineers have social cognitive disorders that make them feel uncomfortable in new social situations. In these cases, asking simple, easy questions about their work (make sure to avoid anything that could be seen as digging for progress or a boss/manager speaking about the product) should illicit a wealth of conversation. If speaking is a rare event for them, make sure you pay attention and listen.

A good way to show that you are actively listening is to repeat back what the engineer has said. “So, what I am hearing is it is difficult to work with shaders on the PS3, is that correct?” This simple sentence shows that you are paying attention, that you are interested, and that it is OK to keep talking (note: this is a trick trained to psychotherapists).

Go to Them or Find Neutral Ground

Calling an engineer somewhere or setting a meeting without a description is one of the worst acts you can perform in the eyes of an engineer. Not only is time sacred, but providing an unstructured anticipatory event will solicit imaginative panic. That is, an engineer will begin to question why you are speaking, what you will say, and will attempt to mold the situation in her mind. This leads to anxiety and will reduce the productivity of whatever chat you were intending to have.

Instead, try to go to the engineer, especially if they have an “off time” or you notice they are less engaged with their work. I highly suggest structuring your first conversations in a, “Hey, want to grab a coffee?” fashion. Do not make your first conversations immediately about work. Instead, get an upper (caffeine), make it somewhere you have to walk to or drive to, and begin the listening exercise above. This gives the engineer the option of engaging and supplies time to communicate.

I have formal methods for achieving this specific result. Every other week, I take each of my engineers out for tea. The meeting is unstructured, but consistent in time and can live on each engineer’s calendar. I make it very clear to new hires that these meetings are about discovering what I can do for them, how they are feeling, and to support my role as their advocate.

Baby Steps

This will sound ridiculous, but I will say it anyway: begin your relationship small. Say good morning. Go for a quick coffee. You need to build your relationship on a foundation of trust — 1) that you aren’t judging them 2) that you aren’t asking them to do anything special (such as work overtime one night) and 3) that you are genuinely interested in crafting a natural dialog. If an engineer is non-responsive early on, make a point of finding what she really enjoys and bringing it up, but do not push hard or ask a lot of questions if an engineer is being non-responsive. Give her space and time.

You are going to work together for years. Baby steps.

Praise

When in doubt, praise is the beginning of trust. “You did a great job on last week’s deliverable,” means a lot to someone who was heads down trying to get a product out. When in the listening phase, “You explained that well, now I understand” can go a long way to establishing a bond of trust.

With Great Responsibility

As a note, the above might sound like a recipe for manipulation. Please do not use it for such. There are ample keen engineers out there that have very sensitive manipulation mechanics (I am one of them). I might not say that I know what you are doing, but I know it is happening. The second you break that trust, an engineer will weigh and measure every word that comes out of your mouth. Be respectful. Be sincere.

Do this because it will help you at your job. Do this because we are all interdependent and good communication is the first step in removing evil from this world.

Let me know how your conversations go and good luck!

HaXe & The Future

Where have I been? Well, I have been busy and, sadly, far away from the crazy world of blogging. I really want to continue blogging; but, I have just been so busy working on projects. That being said, I really do need to maintain my writing. I have been slacking, I apologize.

A few weeks ago I posted a popular Gamasutra blog post called Stupid Simple Code. Unlike past writings, this particular piece is about engineers and engineering, not general culture, hiring, or management. To some degree, I think I need to start talking more about engineering specifics.

In that vein, I have decided to document the game I am currently building on the side and provide code snippets and solutions. The game, Wings of Vengeance, is currently being developed for iOS and Android using HaXe and NME. I have been working on the project for a good amount of time now and have learned a thing or two about HaXe, NME, mobile development, and more.

Generally, I reserve engineering specific talk for the graduate classes I teach; however, I now feel it appropriate to write here and now about my experiences as a software engineer, about code, and about architecture. So, I promise to document my exploration of HaXe, NME, and mobile engineering in detail. While I do have extensive experience building complex game engines and systems AND experience building mobile games, I have yet to discover my favorite or most comfortable method of mobile engine development. I am going to make mistakes. I am going to spit fire and curses. There will be humble moments as I race through my code looking for obvious flaws (as happened last night).

I promise to document them all. Here. As they happen.

Stick with me. The ride is about to get bumpy.

Ding, Dinner’s Ready

This week has been spent in a small bay-side house with my fiancee and dogs. We’ve explored every nook and cranny of the neighboring beaches, our lab-poodle mix romping through the cold waves and rolling in the damp sand, our tiny papillon a pale shadow in her wake. Last evening, we drank champagne on the dock and watched cool night slowly wash away the last semblances of gray day.

I keep promising myself time to sit and think, to compose my thoughts and finally reach decisions about the future of my writing. Instead, I’ve found myself taking the easy way out by embracing the moment. This reads Buddhist, to meditate on the instant of being, but I think it’s an easy escapism. My head is swirling with ideas for new novels, yet I find myself unable to commit.

Cataclysm is out. I already have a rough outline for a second novel in the series, but I’m not certain it’s my next project. There’s an undead story floating around pumped full of sarcasm, a fantasy novel meant to defy standards, and one or two other bands of thought that could evolve into more meaningful cords.

Cataclysm took years to write and edit. What’s next? How long will it take? Committing to writing a story requires dedication. I don’t want to wantonly jump into a project without first considering my options.

So, there you go. Que sera, sera.

Buzz buzz

I’ve been a very busy bee, I apologize for the lack of updates. In recompense, I offer you this: my first self-published novel. One small step for Amazon, one large step for A.A. Grapsas. I tore my hair out (and nails off) attempting to write a well-crafted teaser:

The Houses are long dead, purged from colonized space with vengeful steel and angry rifle. The charred ashes of the ancient monarchy have since been built over by industrial hunger, dark secrets carelessly forgotten. Now, buried ghosts are mysteriously returning, threatening to ravage humankind and rip apart the delicate peace struck between the representative democracy of the United Republics and techno-democracy of Sol. At the center of the tempest is an enigmatic man driven to discover the truth of his nightmarish past, a man soon to become entwined in the pain and disaster of the coming cataclysm.

Follow a brutal tale of high technology across humankind’s vast territories, far into the dangerous wilds of the Reaches where life is won and lost by a blade’s nano-thin edge, and deep within the mechanized efficiency and political web of the Core worlds. Encounter desperation, terror, betrayal, and retribution as a cunning information thief, a rogue ship captain, a tortured mercenary, and others become entangled in humankind’s struggle for freedom and survival amongst the blood stained heavens.

If that sounds interesting to you, please purchase a copy and let me know what you think! Writing should be a dialogue between author and readers, not a one way spew fest. I’d love to hear your thoughts.

Other Stuff

I really have been busy. I’ve been working for Sojo, crafting great gameplay experiences that give back to those that play. The company is great and, hopefully, in the near future I’ll blog about how amazing it is to be doing good.

Expect more updates! I’ve said this in the past; but, all is a-changing.

That’s enough for now. Enjoy the beautiful weather!

Vamps

From the notebook for my new novel:

We are controlled by vampires; creatures that prey on the talents, abilities, and work ethic of others. Yet, no one drives a stake through their black hearts. No one sees the ghoul in the shadows. They are the 1%.

We are zombies. The walking dead. Not the suave, smart image of the vampire, wise with time and fat on blood. We are the dumb, shambling horde. We are driven by our search for flesh and brains, never smart enough to stop and question our single minded hunger.

We should fear this similarity. Monsters lurk in the night and, no, they are not the apparitions of fairy-tale origins. They are very, very real.

Empathetic Software Development

Writing a book is hard. Cataclysm, my soon to be released space opera, took years to outline, write, and edit. Now, I’m shifting gears and preparing to write something completely different: a book on software development.

How’s it going?

Well, I started an outline… and immediately realized it was all wrong. Here you go:

Empathetic Software Development

Keep in mind

  • This is not an introductory book on software
  • I am writing this because it’s what I truly believe in and want developers to do

Core philosophies

  • Mindfulness and introspection apply at the team and company levels NEW CONCEPT
  • Companies have emotions and thoughts expressed through the employees NEW CONCEPT
  • Predictive adaption instead of reactive adaption creates healthier companies NEW CONCEPT
  • The people doing the work know it best LEAN
  • Respect is crucial to creating an environment of cutting edge, productive work LEAN
  • Empathy is the only way to keep the best people NEW CONCEPT
  • No one way is always going to be the best way NEW CONCEPT
    • Time degrades a process’s fit to the problem (why mindfulness is required)
  • Employees invest in your company (their time), the money you pay them is not ample reward NEW CONCEPT
  • Solving problems from the inside out (using internal resources) keeps the value within the company NEW CONCEPT
    • Consultants are okay, but, their purpose should be to educate, not to provide change
  • Theory of nurture in management NEW CONCEPT
    • Managers are made, not born
      • Having bad managers throughout a manager’s lifetime makes her more likely to have bad management tendancies
  • Disasters and failures do not just happen NEW CONCEPT
    • Mountaineering: we know the wind direction, temperature, seasonal conditions, etc. that all lead to an avalanche; so, we shouldn’t get stuck in one!
    • Early warnings: canary in the coal mine

Outline

CHAPTER ONE

Question: is software development being done wrong?
Purpose: to convince readers that we may be doing it wrong right now, and, more importantly, if we’re doing it well right now, that’s not a guarantee that we’ll be doing it well tomorrow.
New concepts: software development has a human toll

  • Software development is fluid with ever changing best practices, technologies, and philosophies [agile today, scrum tomorrow, lean in the future].
  • The majority of software fails, and fails hard.
  • Good software developers are few and far between and a single guru can be worth upwards of 10 developers.
  • Generations of bad managers trained by generations of bad managers before them.
  • Big companies can’t get it right and most small companies die.
  • Most software projects are over budget, under featured, and not on schedule.
  • The human toll of software development
    • Relationship strain
    • Anxiety

CHAPTER TWO

Question: is there a right way to develop software?
Purpose: to show that there is not a single right way to develop software, but there certainly are bad ways to develop software
New concepts: humans are more powerful than ideas/concepts, humans can make or break companies and projects
Hint at: companies have emotions & schemas

  • We’ve been searching for the right way: Agile, Scrum, RUP, AUP, I&I, Spiral, Waterfall, Lean Development, XP, Cowboy
  • Dangers of wrong fit
  • Dangers of integrating system and then not having the strength to uphold it
  • Dangers of not fully understanding the system
  • Dangers of mandating change from the top-down
  • Training only part of the team
  • Philosophy vs. tool sets
  • Development methodologies do not address the system
  • Leveraging the individuals in a company can alleviate these issues
    • People are the ultimate solution to any problem
  • There are more people than there are management
    • Self-learning organizations
    • Trust
  • Companies are composed of people, making them human endeavors
    • Concept of “corpus”, should be “mind”

CHAPTER THREE

Question: What really is the human cost of development?
What’s wrong
Well, I immediately am explaining why the book is needed. That’s not the goal of the book. I’m really not trying to persuade people that I know any better. Rather, I’m attempting to challenge traditional thinking and ideas and bring together a collection of thoughts, processes, and so forth that I’ve had and experienced throughout my career and research.
What’s next
This is the cheapest point of iteration! Outlines are easy to tear apart and rewrite. So, rewrite I shall!
Wish me luck!