God Bless and Goodbye

A couple of months ago, I received a thick packet in the mailbox. Inside was a questionnaire, asking me to participate in a scientific study. "Oh?", I wondered curiously. Having had a closer look at the purpose of the study, I dutifully complied, filling out the forms to the best of my ability and promptly mailed back the results. The eagerness to complete this survey was quite personal. Here's the title of the survey:



Lymphoma. Cancer. This survey brought back a flood of memories, things that I scarely want to remember, but things that nevertheless gave me great insight into myself. After returning the questionnaire, I opened my filing drawer and pulled out a folder thick with dated reading materials. Here's a small sampling:



There were brochures, pamphlets, information guides, medication descriptions, fact sheets, phone directories, and yes, even scientific papers from the Journal of Clinical Oncology, something that I requested of my oncologist to provide for me. As an aside, I'm surprised by the rather low numbers in the sample size of these papers. One paper had a study size of 17 patients, and the other, 65 patients.

Amongst all that reading was, of course, that one single piece of paper that started it all. A blocky looking fax titled Surgical Pathology Report. You can see a snippet of the report below.



If you think I've focused the camera too close, well, those were really the only words that stood out when I first read the report. Lymphoma. Positive.

I kept my cool, mostly, until I got home and sat both of my boys on my lap. Neither of them at the time were yet of kindergarten age and they did not know why their father was crying. But that was the first and only time I shed tears for this. Life went on as before, save for occasional trips to the hospital and a couple of longer trips to Toronto for a second opinion. If one were given the chance to choose the type of cancer to get, mine would be it. My course of treatment was to not treat it at all. Wait it out. See if the body can fight it off. With my faith sustaining me and by the grace of God, I sit here today typing out this blog, cancer-free. One very important note: my decision to do nothing is peculiar to my form of cancer and not a general recommendation to other cancer patients.

Despite what I've written so far, this post isn't really about my cancer. It's just background information. To be a father and a husband, this is what is most important to me. Having been diagnosed with cancer didn't change this priority, but it did bring it into sharper focus. I know I need to take care of myself so I can take care of my family, so I can enjoy my time with them. But over the years, that focus slowly became blurry again as the emotional impact of that diagnosis slowly wore off. I consciously knew that I needed to take care of myself, but I also consciously committed myself to more and more projects that took time away from my family. That was the way it was until that questionnaire prompted me to re-evaluate how I was living my life. I was becoming more and more exhausted and it simply wasn't sustainable. I wasn't living up to what I promised myself years ago to take care of myself.

Having that clarity again is refreshing. What I thought I held dear I really didn't. This includes the online persona that I've cultivated for myself these past two and a half years. It includes my involvement with the successful Engineer Blogs. And yes, it even includes the Flying Flux. Once I came to this realization, it wasn't too hard to take the next step.

I am permanently leaving my blogging life behind and moving towards more meaningful things in the real world. I'll be making a similar announcement on Engineer Blogs later today. When politicians say they're stepping down to spend more time with their families, it usually means they're being forced out or were caught in some hanky panky or dirty money scandal. But in my case, I really am stepping down to spend more time with my family. I rather leave on a high note, on my own terms, than to let things slowly deteriorate into disrepair. And I do this with bittersweet feelings. After all, the Flying Flux has been my personal platform these past 2+ years to rant and rave on topics big and small. Where now can I publicly complain about the obtuseness of management, the paranoia of my colleagues, and the idiocy of my government?

But no matter the amount of fun I've had in maintaining the Flux and writing at Engineer Blogs, it pales in comparison to my real achievements in life, namely that I've managed to convince someone to bear my children (twice!) and that I've been able to keep these children alive for nearly a decade.

So thank you readers for your patronage. I shall miss you all. And on that note, it's time for me to take my plough and head back to the farm. God bless, and goodbye.

Heavy Breathing

If I cared about doing such things, it would be quite easy to assume the ID of Mr. Poker. It's not hard to find out his credit card numbers, expiry dates, passport number, birthday, his wife's birthday, etc. The reason is that Mr. Poker has a high speaking volume. Very high. So much so, when we're on teleconference calls, I take off my headphones when he speaks. I can hear him loud and clear through the cubicle walls. The same is true when he makes personal phone calls, such as buying things over the phone, talking to people at the passport office, etc. His booming phone voice has driven other co-workers not on our team to move their desks to the other side of the office building. Unfortunately for the rest of us, we're stuck.

But Mr. Poker isn't just a loud talker. He's a loud breather. In conference calls, when he isn't speaking, everyone can still hear him pant like a perverted crank caller. And even after I asked him (nicely) to please put himself on mute when he isn't talking, he doesn't do it. I think he thinks the heavy breathing is done by someone else. Oh well. I guess this is what makes life interesting.

Evergreening the Geosphere

I learned two new managerial buzzwords recently. The first one is an adjective -- evergreen. It means refreshed, never old, never stale, never withered, always new, always green. For example, let's make sure we have an evergreen view of the Gantt chart that doesn't reflect reality. The second is a verb -- to geo-scale. It means hiring, or scaling up the organization, will take into account all geographies in which we operate. To translate this into more concrete termes, it means we're going to hire people in China and India. To the rest of our geographical centres, here's a big f*&k you.

It's disheartening to see this kind of language being employed internally. Engineers are pretty straightforward people. We'd like straightforward statements. All this obfuscation through word-play doesn't mean squat to us. In fact, it comes across as insincere bullsh*t. If you're going to hire in India and China, just say you're going to hire in India and China. To spin it any other way just means you're no better than the guy that forces us to fill out meaningless forms for the sake of process.

Oh wait, never mind. You are the same guy. Carry on.

When Meaningless Forms Affect Your Salary

Our super duper director, the one whose bright idea is to require engineering to design a zero-bug prototype, has been hard at work implementing new ways of doing things this past year. New ways of documenting. New ways of presenting data. New checklists. New ways to track schedule. It's all part of the zero-bug effort. And how did he come up with all these new ways of doing things? By not asking, even once, the people who were to actually going do these things -- the engineers.

When we mentioned that all these new processes will cost a lot of schedule overhead, he insisted that it would not. In fact, it'd be barely noticeable above what we're already doing today, he tells us. One of those fun new it-will-take-no-time documents is filling in the design checklist. Often, he'd get angry when he'd check our design documents repository to find it sparsely populated with these checklists. He'd threaten us, telling us that he doesn't want this intransigence to show up on our annual reviews, but he's willing to go there. The checklist is filled with useful items, like "Are all input and output labels spelled using all capital letters?" The answer for us is no, as we have been using lowercase for all of our designs for the past 7 years. There are many, many other useful checklist items, like "Has the design been simulated across all possible corner case permutations?" The answer is strictly no, but we do simulate a relevant subset. Else, the design will take ten years to complete.

So basically, the checklist is meaningless. We already have internal checklists and design reviews that are much more useful than this new fancy schmancy crap on which we were never consulted. And the only thing our director does with these checklists is to see that they exist. He doesn't actually look at them. Process for the sake of process. But if your annual review and salary is still important to you, then process is what you shall do.

Cognitive Dissonance #2

Snapped this pic on vacation last year north of Toronto. Wonder if the fish and chips come with sweet and sour sauce.

Intent vs. Implementation

When designing anything, there's what you would like to design, and what you ended up implementing. The design intent may be elegant, beautiful, even sublime. But overlook one small issue and the whole thing can fall apart.

During the last several months, I've been embroiled in issue which directly impacts FluxCorp's bottom line -- manufacturing yield. It all boils down to a bug in the design that causes intermittent failure in a small percentage of parts. The bug is quite simple. The design intent was to add two variables, i and j, together, or i+j. But we ended up implementing was i+i. A typo? Yes. A typo that's causing months of headaches? Yes.

My example here may be a bit abstract, so let me give you a real world example. Here are two pictures of a five star hotel bathroom in India. Beautiful bathroom, except for one minor implementation flaw that renders the bathtub mostly usable. Spot the problem?

Scolded by a Child

This past week, the manager of the digital design group decided to give a good scolding to us analog guys. His frustration is due to the analog design changing on a regular basis, which sometimes require associated changes to the digital logic. He wonders why we analog guys can't do a bit of up-front feasibility study (let's say, 10% of our design time) and then finalize our designs' pin-outs, specs, and footprints up front. After all, the digital guys are able to do it. When Mr. Halal responded that analog is more complex, we got the "yeah, I knew you were going to say that" response. The manager may have known how we were going to respond, but he didn't seem convinced.

In the digital world, functionality is implemented in software-like code call RTL. Thus, when one finds a functional bug in a digital design, changes to a text file fixes the problem. Functionality aside, there are three other major specs that needs to be met -- power, area, and clock speed. Three variables. That's it. I'm not saying it's trivial work; it isn't. But let's go through an example of what an analog designer needs to worry about when designing an amplifier:

- frequency response
- gain
- phase margin
- gain margin
- biasing
- headroom
- DC offset
- slew rate
- power
- input impedance
- output impedance
- compensation capacitance
- area
- matching
- common mode
- common mode feedback stability
- common mode rejection
- power supply rejection
- gain compression
- intermodulation
- parasitic coupling
- ground loop
- package inductance
- electromigration
- over-voltage

I'm sure there are others I haven't thought of. To top it all off, changing one spec can ripple through and affect ten other specs. Sometimes, the inability to meet one spec means one must throw the design away and start over. And that's just an amplifier. There are many, many other analog circuits that go into a complete system. That's why analog design remains an art created by manual labour while digital circuits are synthesized, created by a software tool using RTL code as its input. By the time enough feasibility has been done on the analog design, the design is pretty much more than half-way finished.

I don't expect the digital manager to fully grasp the complexities of analog design. But at the very least, he can drop his condescension thinking that he knows it all. It's like being scolded by a child who's telling you that rocket science is easy because he just made a rocket yesterday out of paper-mâché.

I'm not big on EE class warfare. But in light of his most unwelcoming comments, perhaps I should just forward him this lovely poster (grabbed from The Amp Hour):

Losing Trust

One of the new ways of doing things here at FluxCorp is to start tracking bugs we find in verification, no matter how large or small, so (a) the issue doesn't slip through the cracks, (b) management gets to see how hard we're working, and (c) the rate of bug finds is a loose indication of how robust the design is. We're also employing a new web-based bug tracker, something that I personally setup for this very purposed.

But old habits die hard and old perceptions are hard to change. Recently, a bug was entered into the system due to a typo in someone's design. Instead of typing something like "out = in + 5", the line ended up being "out = out + 5". The typo caused the entire design to fail during simulation. The engineer doing the verification (me) logged the problem and indicated to the designer that the problem was a typo. The response was quick. The bug was fixed in minutes and I got an e-mail from the bug tracking software, saying the problem's status has been changed from "open" to "fixed" along with the designer notes. The note said that logging every tiny little bug into the bug tracking system is f%^king bullsh*t.

It's easy to point fingers with a self-righteous sigh, blaming this colleague for being unhelpful and uncooperative. But I do understand where he's coming from. Through the grapevine, I've heard that the digital team has been burnt in the past by logging all of their bugs. Some upper management idiot had used the list to blame the team for too many bugs in their designs. Ever since, the team has been wary of maintaining such lists, or at most, having a list of serious issues shared amongst only a limited handful of people.

Often, management do not see the long term effects of their actions. Once trust has been violated, it is extremely difficult to gain it back again, even many many years later.

A Matter of Scale x3

Over at Engineer Blogs, I've put up a series of posts discussing the challenges of designing circuits in the nano-world. The posts so far are:

• A Matter of Scale: Electromigration
• A Matter of Scale: Well Proximity Effect
• A Matter of Scale: Moore is Dead, Long Live Moore

Last week over at EB, we've also been discussing networking as it relates to our careers. I reminisced about how a friend help me land my current job at FluxCorp. So have a look. And leave a comment while you're at it.

Cognitive Dissonance #1

Spend money? Save money? Here's a partial screen capture from CNN's website a little while back.


And no, this isn't an April Fool's joke.