Friday, April 25, 2014

BEWARE THE FLAVOR OF THE MONTH

    "It's like a Swiss Army Knife for propellor-heads."

    — review of the NeXT Cube (1990)

This blog entry is written from the point of view of a software guy, so I apologize in advance for the specialized examples, but I believe the lessons are universal for any technology.

One of the fun things about being a techie in the Internet Era is watching the accelerating pace of fads as they sweep across the meme-space. In my field of software development I've seen the following come (and often go):

  • ALGOL
  • Backus-Naur Form (BNF)
  • PL/1
  • structured programming
  • Nassi-Shneiderman Diagrams
  • waterfall development
  • Ratfor
  • UCSD PASCAL
  • LISP
  • SQL
  • UNIX
  • object-oriented programming
  • SMALLTALK
  • C++
  • TCP/IP
  • workstations
  • client-server
  • Solaris
  • multi-tiered
  • CORBA
  • PCs
  • patterns
  • Visual Basic
  • Java
  • Javascript
  • Java Beans
  • Objective C
  • C#
  • LINUX
  • Tcl
  • Perl
  • Python
  • AJAX
  • agile development
  • open source
  • XML
  • PHP
  • Ruby on Rails
  • SaaS
  • Go
  • Node.js
and I know I could think of more examples if I took more time. Some of these have made a permanent difference in the way software is created, others not so much. But hindsight is 20/20 — foresight, of course, is harder to manage. Who knew, for example, how big Javascript would become when it was introduced as a proprietary client-side web scripting language by Netscape in 1995?

The Devil You Know and the Devil You Don't Know

The big question we face when we evaluate new technology is "Too Soon" vs. "Too Late." If you are too early an adopter you can suffer from bugs (especially "infant mortality" type), an undersized installed base and user community, and skepticism from many quarters including managers, clients and investors. There is also the danger that a proprietary solution from an unprofitable startup may simply go away, making you a technical orphan. Of course popular open-source projects can also lose favor and fade away. But on the other side a mature technology can fade away as well, if it gets too much "bit rot" to be fixed or is not adapted to its changing environment. Old software is well-known to frequently suffer from the effect that fixing one bug causes two more.

But timing, of course, is everything. The earliest of early adopters almost always suffer for their innovations on the "bleeding edge." As they like to say, "A pioneer ends up with an arrow in the back." But there is a "sweet spot" — for example, Apple's entry into the music player business with the iPod — that maximizes "lock in" and other early benefits. And on the other side, there are technologies like FORTRAN, COBOL, DOS, and XP that seemingly just won't die and are remarkably stable, if not feature-rich.

I have seen extreme examples of the failure modes of both "horns" of this technical dilemma.

I worked for a midwestern startup that had probably adopted a technology too early. They had a mapping suite of software written in Smalltalk, an early object-oriented language, that depended on an "object-oriented database" (OODB) to store its data, and that database had some operational bugs as well as design flaws that made the software pretty much impossible to deploy. One of the operational bugs was that entities in the database could not be completely deleted; their names remained as "ghost objects" forever and could not be re-used.` One of the design flaws was that only one program could use the database, unlike every "real" database I've ever used. These and other problems caused the product, and the company, to fail.

On the other extreme I once worked on an accounting application (in this century I should add) based on an obsolete database from the early 1980s that was so old it didn't use the standard Structured Query Language (SQL) of all modern databases. The vendor was no longer supporting the database for any other customers, and gave the bare minimum of support to my employers. This company was limping along in a fragile and vulnerable state, performing accounting services for scores of clients in a mode that could fail dramatically at any moment, with no short-term disaster plan and no long-term road map for migrating off of this ticking time bomb. They are still in business but I'm glad I'm not one of their investors.

Criteria

So how do you decide when it's too early or too late?

My hierarchy of criteria goes like this:

  1. stability
  2. deployability
  3. portability
  4. maintainability
  5. longevity
  6. security
  7. features
For example, I have found that up to this point the C programming language wins or draws on every point except maintainability and features, and those can be addressed with good programming practices and the right libraries. This helps explain I'm still fond of it, even though I began learning over thirty years ago. Here are some more details on why C remains popular:

On the other extreme I began learning PHP a few years ago and was dismayed by its lack of maintainability and difficulty of deployment. I have written precisely one PHP app, which you can see on-line at:

Deployment was easy because the web hosting company already has PHP installed. If I suddenly had to port this app to run on someone's local computer, I would allocate at least an afternoon to install and test PHP and the Apache web server it needs. I would probably end up using this manual:

Since going through this process I have learned that PHP has some security issues as well. I certainly don't need much security for my little "page-a-day" calendar app, but most uses I'm aware of are for e-commerce, where it really matters. This is why I currently take a "wait and see" attitude with PHP, and only use it when I am given code by others in the language.

Another point to consider when selecting a technology is how to deal with worst-case scenarios. I've noticed that both automobiles and software libraries tend to break down more often after 5 PM on Friday before a long holiday weekend. I have found I would rather tell my boss or client "We're going to work all weekend to find the bug in our code and meet the Tuesday deadline," rather than "The problem is in a library, we don't have time to write a replacement, so we'll have to wait until Tuesday to call tech support. There's no way we can make our deadline."

I know what you're thinking: what about open source software? Well, I have found it is both a blessing and a curse. Its a blessing if you want source code to everything and have time to find and fix other people's bugs. It's a curse when you pile on too many open source pieces under a tight deadline and then have trouble integrating and debugging them. I have learned to approach every such decision with risk management foremost in my mind.

Strategies

There are two main strategies I like to employ to mitigate risk in dealing with new technologies: pilot projects and modularity.

  • pilot projects

    In classic treatise on software development "The Mythical Man-Month" (1975)

    Frederick P. Brooks Jr. says: "Throw one away — you will anyway." He is referring mainly to prototypes, which test technology, architecture, and even spec all at once, and result in something you can set in front of the customer or user and ask, "Is this close to what you need?" Once these issues are resolved by testing and evaluation, real development can begin, often by starting from scratch with revised plans.

    In contrast, a pilot project is a complete project, from design through development to deployment, mainly designed to test technology. A key factor is that it is a non-critical project. If you can afford to utterly fail on this one the team will be less tempted to lie to themselves or their bosses. (The idea that something "has to" work is so toxic to projects.) The solution if it does fail is to reject the technology and go back to an older, more reliable one and re-implement the project, but only if it is really needed at all.

  • modularity

    Simply put, if you break functionality into interlocking pieces and implement the pieces separately, it makes it easier to test, debug, maintain and if necessary replace or totally overhaul each piece. I have found the advice in the book "The Pragmatic Programmer" (1999) by Andrew Hun and David Thomas

    — as well as other books in the series — to be helpful in this architecting for modularity. It is a lesson I learned originally from the classic software engineering text "Software Tools" (1976) by Brian W. Kernighan and P. J. Plauger.

    Thought their examples re in FORTRAN and PL/1, I find their design principles to be timeless. I use them all the time in my work.

    In addition I've found the following abstraction useful: break things into pieces horizontally and vertically. In a famous tutorial on the UNIX shells we are shown how to print out a file listing in order of size: largest to smallest, starting at the current folder and moving away from the root. The command is: 

      du -k -a | sort -nr | more
    This actually uses UNIX "pipes" in the form of the vertical bar which connects three programs: du (disk usage), sort and more. Each does of a piece of the job. I think of this as horizontal partitioning of a task; each piece does a part of the job "on the same level" so to speak.

    In contrast, a vertical partition involves breaking things into layers, a concept which is a little more subtle. An example will probably help. I'm involved in a software project currently in which we are still debating how to have programs communicate: using shared memory, or sockets, or "RESTful" web services, or even dropping communications files in a designated folder. I suggested we add an "abstraction layer" by writing a set of communication functions/methods, and have the discipline to always use them. Then the underlying technology can be "swapped out" seamlessly.

    One of the most powerful tools in layering software is emulation in which one technology emulates another. I'm old enough to have used a VT-100 terminal from DEC before they became obsolete in the 1980s as we switched from minicomputers to PCs, But there are still mainstream programs which emulate that old terminal, including the Linux console.

    A pervasive example of software layering is what is sometimes called the "network stack," though nowadays it's usually called the Open Systems Interconnection (OSI) model.

    The technology that makes the Internet work is broken into seven layers. Numbered from "bottom" to "top" they are:

    1. Physical Layer
    2. Data Link Layer
    3. Network Layer
    4. Transport Layer
    5. Session Layer
    6. Presentation Layer
    7. Application Layer

    The Network Layer is where the Internet Protocol (IP) is found, and the Transport Layer has the Transaction Control Protocol (TCP). Together they are called TCP/IP. Ever heard of that one? Part of the genius of the internet's design is the breaking of these functionalities into layers, which can each be improved or replaced independently.

Non-Technical Example


a railroad date nail from 1918

If this discussion of the innards of the internet has been too geeky for you, my last example is from a century ago: an obscure industrial artifact known as the railroad "date nail."

My friend Bob and I discovered this delightful collectible while visiting the Western America Rail Museum (W. A. R. M.) in Barstow, CA.

They have a whole room of the things. They're small and sturdy enough to make great collectibles, and have rich histories that can usually be documented. They are nails with dates or other codes stamped into the head that are nailed into lumber used as railroad ties and trestle beams, so their age can be determined when they must eventually be replaced. The types of chemical treatments applied to the lumber were sometimes noted along with a date.

What do we learn from this practice? A surprising number of lessons can be extracted:

  • plan for change

    Understand that you can't keep using techniques forever; each will have to someday be replaced.

  • everything is an experiment

    You can never test things enough in engineering, so every field deployment is really an experiment.

  • document results

    You can't manage what you can't measure, and you should plan ahead to make measurement and records keeping easier.

  • be prepared to change course

    Every change can prove disastrous, and you need to be able to back out and return to a previous method.

  • try multiple approaches

    Test technologies against each other. Make sure you have choices informed by performance measures.

Now that's the way to run a railroad!

Disclaimer

I receive a commission on everything you purchase from Amazon.com after following one of my links, which helps to support my research. It does not affect the price you pay.

This free service is brought to you by the book:

A Survival Guide for the Traveling Techie
travelingtechie.com
Posted by at No comments:

Friday, February 28, 2014

A Traveling Techie's Tale: MY FIRST OVERCOAT

    "Well, let me tell you of the story of a man named Charlie
    On a tragic and fateful day
    He put ten cents in his pocket, kissed his wife and family
    Went to ride on the MTA.
    Well, did he ever return?
    No he never returned and his fate is still unlearned.
    He may ride forever 'neath the streets of Boston
    And he's the man who never returned."

    — "MTA" by Bess Lomax Hawes & Jacqueline Steiner (song, 1949)
          performed by the Kingston Trio on the album "The Kingston Trio At Large" (1959)

True story, bro. On one of my first business trips as a traveling techie, back around 1984, I went to Cambridge, Massachusetts in the winter to help install a computer graphics system and train programmers how to use it. I didn't have an overcoat at the time, living as I did in San Diego, California with it's famous "Mediterranean climate" (found nowhere else in the U.S.), so I figured I would make do with layers. It was only supposed to be a two day visit, and though I wasn't able to rent a car, I had rides arranged and taxis where necessary; I saw no reason to venture out after dark and I didn't think it would be a problem.

Well, the installation didn't go so smoothly. The graphics system was a fragile prototype that used "wire wrap" technology, and this was the first time we shipped one across the country. Something shook loose and the system was dead on arrival. I tried being the eyes and ears of the chief engineer over the phone, but after a few days of frustration he needed to fly out to fix the problem. Of course my training had to wait until the system was up, so my stay was extended from two days to five.

This meant I had to buy extra clothes to last me, and locals directed me to take the Metropolitan Boston Transit Authority (MBTA) Red Line light rail across the Charles River to the famous Filene's Basement in downtown Boston, where I stocked up on shirts, socks and underwear.

I also began to get bored in the evenings, so I ventured back to Boston one night to explore. Fearing being mugged I took only a small amount of cash (it was in the days before ATMs and debit cards) and caught a cab from my hotel to a Cambridge light rail station on the Red Line, bought two subway tokens, and from there rode to the area of Boston Common. Since I still didn't have an overcoat I wore a sweater with a nylon windbreaker over it, and no hat or gloves.

After a mildly interesting evening wandering around the area and having an Italian dinner of sorts in a little storefront restaurant I decided it was time to head back shortly before midnight. I descended the stairs into the Park Street station to the Red Line platform. While waiting I noticed a crumbling old staircase that went up into darkness. I climbed it out of curiosity and found a dead-end at a brick wall. While I was on the stairs I heard a train come and go. I stepped back down on the platform and sat on a bench to wait for the next train, which I figured would be in 20 or 30 minutes.

Now, I was under the mistaken impression that the subways ran all night. This was not the case. The train I'd heard was actually the last train bound for Cambridge that night. I sat there for a long time in the quiet before I figured that out. Then I tried to walk out of the station, but at the top of the stairs I found a steel door had been lowered and locked. I then explored the station and discovered another locked exit on the opposite side of the tracks after taking a pedestrian tunnel to the far platform. Further exploration revealed that there were walkways through tunnels that connected four stations in the area: Park Street, Government Center, State and Downtown Crossing. The tile walls looked like they had been there since the 1940s. As I methodically explored, I found each station had two locked exits, so by the time I arrived back at Park Street I had found eight locked doors at the top of the stairs leading out of the four stations.

Well, now I didn't know what to do. I was there on a bench for a while considering my options. (Some of you young-uns may be wondering why I didn't use my cell phone to call for help. It was 1984, remember.) While I was pondering, I heard some noises and then spotted a small group of maintenance workers walking along the tracks. One of them had a metal rod with an insulated handle, and was using it to test the third rail by shorting out the power to ground and looking for sparks.

I hailed them and explained my predicament, and they began to harass me in the good-natured way (I think) that Bostonians have of hazing clueless Californians. The told me about people injured in the subways by rat attacks and exploding fluorescent bulbs. Finally one of them agreed to let me out. He took up the stairs to the locked metal door, pulled out a huge ring of keys, and began trying them one by one in the padlock. He got to the end and said, "I must have missed it," and then started over. I'm pretty sure he knew which was the right key, and was just "pulling my chain" as they say. Finally he found the right key and let me out into the Boston night. It must have been about 2 AM by then.

I knew I didn't have cab fare back to Cambridge, so I began to walk back, following Beacon Street through the Back Bay, slowly approaching the iconic Citgo sign in Kenmore Square.

It began to drizzle on me in my sweater and nylon windbreaker with no hat or gloves, and then the temperature dropped below 32 degrees Fahrenheit and the drizzle turned to freezing rain. I had my hands jammed in my pockets but little icicles were starting to form on my head and shoulders. I was thinking, "This is a fine mess I've got myself in." Every now and then a cab sped by. Finally I could bear it no longer and I flagged one down. At least it was warm inside. I waved my cash at the driver and explained it was all I had (which I'd estimated would get me the approximately half a mile from the Cambridge station back to my hotel), and he could drive me until it ran out. I also warned I might not have a tip for him.

Well, he drove me over the Mass Avenue bridge and right up to my destination for less than I'd expected, and I had enough to tip him as well. (Only later did I realize I had more cash in my hotel room, I probably could've talked him into waiting while I got it if necessary.)

The next day I returned to Filene's Basement and got a fine beige overcoat plus a wool hat and gloves, which I stuffed in the pockets, and they served me well for decades, not only in Boston (which is actually rather mild due to the proximity of the ocean), but in much colder locations such as Des Moines, Iowa and Calgary, Canada.

And I learned some obvious lessons that night. I leave to the reader to deduce what they were.

Disclaimer

I receive a commission on everything you purchase from Amazon.com after following one of my links, which helps to support my research. It does not affect the price you pay.

This free service is brought to you by the book:
A Survival Guide for the Traveling Techie
travelingtechie.com
Posted by at No comments:

Thursday, January 2, 2014

SEX ON THE JOB

    "She said I'll show ya how to fax in the mailroom honey
    and have you home by five"

    — Steven Tyler, "Going Down/Love In an Elevator" (song, 1989)
          performed by Aerosmith on the album "Pump" (2001)

According to Business Insider, a 2013 survey shows about 54% of people have had sex with a colleague. (And 49% of those people say they have had sex at the office!)

Well, I'm here to tell you people to knock it off!

Respect

Now, I know what you're going to say, "What are you, some kind of prude?"

Actually, no, I'm not. Let me give you an example. I'm involved with a computer graphics society called SIGGRAPH.

Once at a big planning workshop a fellow volunteer told me about a party held at the previous year's annual convention, at which the planner had hired women dressed as bondage queens to come out and mingle with the crowd, followed by a whipping demonstration.

"That sounds like a great party," I told her. "I'd love to go to a party like that. But it doesn't sound appropriate for a SIGGRAPH party." I went on to explain that people from all over the world from many cultures came to this event. Very shy Japanese people showed up. A lot of Mormons came, especially from Utah where computer graphics is very big. Kids came — we even had a SIGKIDS program to drag them in. None of these people had signed up for a kinky party, and it could upset, embarrass, or offend them and "turn them off" to what our society was all about.

In this case, it wasn't really about sex, it was about respect.

Risk

    "Now wait a minute!
    Okay, this guy is a real zero. That's true.
    Think back to when you were freshmen.
    ...
    I myself was so obnoxious the seniors beat me up once a week.
    So this guy is a total loser? Let me tell you the story of another loser."

    — character of Otter in "National Lampoon's Animal House" (movie, 1979)

The tale of Patrick Naughton is blood-curdling. He should be a hacker hero, having helped create the Java language among other techie accomplishments. Instead he remains a pariah — a confessed child predator — and has been partially erased from history in some quarters.

Naughton co-founded the early search company Infoseek, which was purchased by the Walt Disney Company and moved from Seattle to Santa Monica. He was tasked with helping to build the new "portal" that CEO Michael Eisner wanted, to be called go.com, and the scuttlebutt in the media press was that he was the "go-to guy" for Disney's web strategies. He also had a smart and attractive wife who was an acclaimed fine artist. But in September of 1999 it all fell apart. After contacting what purported to be a 13-year-old girl in a chat room he arranged a meeting at Santa Monica pier and was arrested in a Sheriff's sting. An article in WIRED magazine said he "lost his Seattle home, his $183,000-a-year job at the Go Network, $10 million-plus in vested stock options, and his freedom." They neglected to mention that he also lost his wife. His employers lost money as well; Infoseek and Disney stocks fell immediately.

Of course there's a moral component to this tale of woe. It is virtually a universal human value that child molestation is evil. In his defense Naughton claimed that he thought he was really chatting with an adult (and in fact he was). Law enforcement erred in the bust and was unable to prove intent. Other technicalities kept him out of jail. But let's look at this from another angle. He was tasked with providing leadership on the web strategies for the world's largest media company. What should he have been doing? How about polling fans of Disney movies, stores, parks and web sites? How about researching competing HTML standards in the browser wars? How about meeting with Disney executives to assess needs from their point of view? The company certainly wanted him to take thus kind of initiative, and took a risk in promoting him — such a young executive with more technical than business experience — to this key position. And he flamed out by any measure. Risky behavior in a chat room was a distraction from facing the awesome opportunity and responsibility before him.

In this case, it was about risk, not sex.

A good rule of thumb about the business world is that people — whether investors, managers, employees or customers — don't like surprises or drama. Predictability and reliability are key, and for you that means personal integrity.

Knowledge

Now, I'm not saying there's a moral equivalence between child predators and people who date co-workers. But you need to understand just what a fishbowl you are in. The British have a figure of speech, to "chat up" someone, which means to hit on them by making small talk. They understand how fine that line is. I once worked in a small division of a large company and met a woman in accounting who told hilarious dirty jokes. I would stop by her desk occasionally to hear her latest joke, until another, older employee said to me, "every one in the company can see how you're romancing that girl in accounting." What? I protested. I was happily married, and I wasn't the one telling the jokes, and other people would visit with her too. But it gave me something to think about, and alerted me to how appearances can be negative, and perhaps made me question my own motives.

Later, working for a small but well-funded startup company in a field office I heard persistent rumors that the married vice president of sales was having a high-profile affair with his new secretary, with lots of drama, friction, shouting and door slamming. I had met this woman at a company dinner, and she seemed rather predatory to me, flirting heavily with those having the most apparent power. But the affair rumors reached 2,000 miles away, and occurred at a time when the company was falling apart mostly due to lack of sales. The implosion took out most of the headquarters people, leaving only a division sold to Japanese investors and a small software spinoff which the philandering VP was not invited to join.

Still later, when I was senior enough to know better, I was conducting a week of software training for a customer company and met a very talented and fascinating Bulgarian woman who bragged about her mathematician father. I told her I was married early on, and we only discussed software and math. She showed me a program she wrote that played the board game "Mastermind" perfectly. I showed her an interactive 3D visualization I had done of the famous Ordinary Differential Equations (ODEs) called "the Lorenz Attractor." She offered me a ride to the airport at the end of the week. Somehow another customer figured this out and thought it was fishy. He made a point of offering me a ride himself in front of the training class, forcing me to admit I already had a ride from the Bulgarian, and then he flashed a mean grin.

Well, she took me to her apartment first, and it turned out the other customer wasn't the only one expecting hanky panky to be going on. But it gets weirder. I apparently had impressed her with my brains, and that was something she was searching for, and she announced that she wanted to have my baby! I told her that I was happily married and also that I didn't think I could stand knowing I had a kid somewhere whose life I wasn't part of. It was an unbelievably awkward scene, and who knows what kind of rumors it sparked.

Drama

If you must have drama in your life I recommend you keep it away from your career. Don't end up in jail or in the news, with visible tats, or hung over at work. Seek drama in other ways. I'm told that Internet dating can be a high-drama activity. Nearly every major metropolis in North America has "goth" clubs that feature very unconventional people in provocative outfits. Search Google images for "goth club" to see what I mean. Or you could try to get a date with a celebrity, or decide to run a marathon, or join a paintball club. But remember that in your business dealings everyone is constantly evaluating you, asking themselves if you are a risk for them to deal with. Don't give them anything to worry about. I have on occasion joked that the standard business necktie is sort of an icon that says "You can strangle me at anytime," or, more generally, "I am not a risk."

Balance

Now, I'm not recommending you seek drama in your life. It's important to find a balance. I would advise a life filled with loving family and friends, with drama as an occasional spice. There's an excellent TED talk, "Esther Perel: The secret to desire in a long-term relationship" which explains the tension between intimacy and surprise.

I would also recommend the book "Why Men Don't Get Enough Sex and Women Don't Get Enough Love" by Jonathan Kramer.

(Adapt the obvious gender stereotypes to your unique situation.) A key to happiness, I have found, is honest and good-faith negotiation for your needs. Just like in business.

Authenticity

It is a nugget of folk wisdom in business that you never talk about sex, politics or religion in a business setting. (These days I would add drugs to this list.) But countering this is the need to be authentic with your associates. Keith Ferrazzi in his book on business networking, "Never Eat Alone: And Other Secrets to Success, One Relationship at a Time" tells a story that illustrates this balance.

At a business dinner he found himself unengaged because of a recent romantic breakup. Finally he apologized to the woman next to him, explaining his situation. It resulted in a very meaningful discussion of breakups that grew to engulf the whole table because of its emotional relevance to people. But notice that in this scenario no one was arguing with, or lecturing, or hitting on anyone. It was just a conversation about authentic human emotions. That's what can work.

I remember an occasion when I was giving some relationship advice to a co-worker as we walked in a group to a lunch location together. "One big problem" I explained, "is that pop music is almost exclusively focused on the beginning of relationships — getting to know each other, falling in love and the first exciting days of a romance." I added that I've only been able to think of two songs that are about long-time love: "I Say a Little Prayer" by Dione Warwick (1967)

and "Everlasting Love" by Howard Jones (1989). "The problem," I went on, "is that after a while you begin to get the idea that you're missing out on all the fun, since the mythology of our culture celebrates only the early phases."

"So what do you do about this?" asked my coworker.

"I've found you have to create your own mythology about your relationship."

Another coworker stopped dead in his tracks. "Wait a minute, say that again," he said. I repeated myself. "Can you do that?" he asked in astonishment.

"Sure, why not?" I replied. These are the sorts of conversations you can have with your colleagues, and they can help build trust and respect.

Also, I figure if it's okay to talk about relationships in a respectful way, it's also okay to ask your colleagues to fix you up. Let your associates act as the yentas (matchmakers) like in "Fiddler on the Roof" — I've never heard of anyone objecting to dating a coworker's friend. Plus, it gives you something interesting to talk about.

Self-help guru Tony Robbins once told a story of how he met his wife when she was a stewardess on a flight he took. He asked her if she had a sister and then talked her out of her sister's phone number. Then he called the sister and asked what the stewardess liked to do for fun, what she liked to eat, what music she liked, what flowers, etc. (Market research.) Lastly Tony arranged a date with the stewardess, and surprised her with everything he learned about.

This kind of careful, respectful communication is how you build solid relationships. If you can be authentic, respectful, and risk-averse in your business communications, you can gain respect and credibility, and perhaps even have some fun.

Meta

Okay, some wiseacre will probably ask why is it OK for this blog to discuss sex, etc? That's because this blog isn't a business communication, it's a meta-communication. Got it? Don't go reading it aloud at the office. Just stay out of trouble. And get back to work!

Disclaimer

I receive a commission on everything you purchase from Amazon.com after following one of my links, which helps to support my research. It does not affect the price you pay.

This free service is brought to you by the book:
Posted by at No comments:
Subscribe to: Posts (Atom)