I've been writing with FPs since 1987, and only figured this trick out this year.
I've been writing with FPs since 1987, and only figured this trick out this year.
We met on the school bus one of the first weeks of school when I was in the 1st grade, and completely new to the area. He decided we should be friends, and thus so we were. He was a big happy guy, despite his family's grinding rural poverty and the death of his father to lung cancer.
We stayed best friends for the next 7 years, until I left NC in 1982 at the age of 13 to move to UT. This was, of course, long before email and facebook, and cross country phone calls were expensive, so we promptly fell out of touch with each other.
A few years ago, I started considering finding him again, and hoping to discover him owning his own machine shop somewhere around there in NC. Last week I discovered that my sister Suzanne was FB friends with one of her old friends from NC who also lived on that street, and so I asked her about Michael.
Two years after our family moved away, in 1984, he and his mother were killed in a serious traffic accident. He would have been 17 at the time.
Goodbye, Michael. You are remembered. You were the first real friend to a shy scrawny overly smart kid who didn't know how to be friends with anyone until then.
When someone was hired, by the time they got to their new desk, there was a computer on it with the correct image on it, their desk phone worked, their email worked, the calendaring and scheduling worked, and all necessary passwords and ACLs were configured. The internal ethernet networks all worked, were fast, and were properly isolated from each other. The wall ports were all correctly labeled, and there where the right kinds of wall ports in each cubical and conference room. The presentation projectors and conference room speaker phones all worked. The printers all worked, printed cleanly, were kept stocked, and were consistently named. The internet connections were fast and well managed. Internal and external security incidents were quickly recognized and dealt with. Broken machines were immediately replaced with working and newly imaged replacements. If someone accidentally deleted a file, getting it back from backup typically took less than an hour. Software updates were announced ahead of time, and usually happened without issue.
The IT staff did not seem noticeably bitter, angry, harried, or otherwise suffering from the emotional costs traditionally endemic to that job role. In fact, they were almost invisible in their skill and competence.
So, of course, came the day when the senior executives said "the carpets are just naturally clean all the time, we don't need all these janitors!". IT was "reorganized" into a smaller staff of younger and much less experienced (and probably cheaper) people.
Of course, it all went to shit. New employees would go a week before they had machines, phones, passwords, and ACLs. Printers ran out of paper, projectors ran out of lightbulbs, servers ran out of storage, networks got misconfigured, and so forth. The total time lost and wasted across the whole company was most certainly greater than the savings of laying off the expensive and skilled IT staff.
This is not to say that the reorganized IT staff were stupid or lazy. They worked very hard and ran themselves ragged trying to keep up with the cycle of operations, while trying to skill themselves up in their "spare time" and with a slashed training budget.
The lessons I learned from this experience speak for themselves.
What lessons that may have been learned by any of the other people involved, especially the executives who made these decisions, I cannot say.
I asked for the source code for the driver for the IR receiver, and for the driver for the CATV RF digital transceiver, and for the peer code that was driving the cable digital that ran on the main device.
The driver for the CATF RF digital transceiver was handed to me the first time I asked. And by "handed to me" I mean that I was pointed to where it was sitting in the source repo.
The business partner / hardware supplier who was supplying the IR glue and drivers just , after giving me a runaround, finally just flat out refused, citing trade secrets, confidentiality, secret sauce, and similar bullshit.
So, I finally "stole" the source code with a disassembler. And found the sources of many of my problems. It was complete shit. "Unexpected" input from the silicon would cause wild random pointer writes. And random sunlight on the receiver optics would cause it. "Expected" input of undefined remote commands wasn't much better, generating and handing back blocks of garbage with incorrect block length headers.
I ended up writing, nearly from scratch, a replacement IR receiver driver.
The peer device driver code was written by a developer in a different group in my same company. I finally got the P4 ACLs to read it after loudly escalating, over the objections of it's developer and his group manager. It was also complete shit. I cannot even begin to remember everything that was wrong with it, but I not only figured out may of the sources of my own pain, I also found a significant source of crash and lockup bugs that afflicted the main device.
I was not allowed to rewrite the peer code, as it was not in my remit. However, I was able to sneak in and check in a large number of asserts, using the excuse that they were "inline documentation".
On, and the device driver for the CATF RF digital transceiver? The source code I got for the asking, without a fight? When I reviewed it was easy to understand, efficient, elegant, and as far as I could tell, bug free.
In the end, I made my part work. It just took over two months instead of the original guesstimate of less than two weeks. This caused a schedule slip in the release of the satellite box. Which would have been a more serious problem, except…
Except there was also major schedule slip for the main box. A significant reason for that slip was because the peer code that I had filled will asserts was now crashing with assertion failures instead of emitting garbage. I was lucky that I was not more officially "blamed" for that. The reason why I wasn't, was mainly because the people who understood what I did understood the problem, and the executives who didn't understand what the problem was were also too clueless to blame anyone, let alone me.
My lesson learned from this experience is: if someone is refusing to show the source to suspect driver code, citing trade secrets, confidentiality, secret sauce, partnership agreements, or similar excuses, it's not because they are protecting their magic. It's because they have screwed up, and they are trying to hide it.
A second rule of thumb I have is: source control systems that don't allow any developers to check out and review any arbitrary source code file are expressions of moral failure. It is unethical for an engineer, designer, or other technologist to ever sign off on a project that has been mutilated by such a broken tool.
I just went on a half-hour binge reading about pertussis, as a result of reading that WA state has an epidemic outbreak that the public health agencies are struggling to stop.
Reading people's first hand accounts of having it will cross your eyes in empathized pain. One person described that she has given birth, has suffered a compound fracture of a leg, has passed a kidney stone, and has had whopping cough. Only one of them made her wish for death. It's been described as feeling like an asthma attack while someone is punching you in the ribs. Oh, and most all cough medicines do pretty much nothing for it.
You, reading this. You. Right now, pick up your phone, and call your doctor's clinic. Ask them if you're up to date, and if you're not, go get your freaking DTaP shot. You can get one at Walgreen's for less than the cost of a high-end Starbucks drink. You owe it to yourself, you owe it to public health, you owe it to your friends and coworkers, and you owe it to every pregnant woman, every newborn, and every immunocompromised person you share this biosphere with.
This personal blog is entirely for stuff about my personal life, and if you don't know me personally, you will probably find it utterly uninteresting.
It's now been three years since I wrote Love Stinks, and a year since I wrote Love Stinks, Two Years Later
I read them, feel the scars again, and muse. Any fundamental change? Not really.
I do not retract a word of it. But my outlook has become more nuanced.
Some of that nuance is even more bitter, some of it more gentle.
I understand more. Understanding does bring peace. Or, at least, it moderates ineffective action.
Things that use to hurt all the time, now only have the occational pang.
I've gotten better at keeping my teeth together, and my tongue still.
I have gotten better at knowing how and how much to trust people.
Some people are selected out from my life.
Some people have drifted into my sphere.
Some people have drifted out.
With some, there has been rapprochement, and a friendship again.
Some old acquaintances, have become new friends.
Some old friends, have become new friends.
And there have been some pleasant surprises, and some new adventures.
I still don't trust "love", but friendship and affection are nice, and I try to enjoy what of it I have, from where and when it is offered.
The racial mix is significantly more white. The people are generally taller and more stocky. There are a lot of people with tanned skin. Many of those tans are leathery. Faces, hands, arms, and necks, everywhere I look I see signs of significant long-term sun damage and other weathering, almost as bad as what I saw in Los Angeles. Their clothes are just as layered as in Seattle, but significantly more warm, and in darker colors. Lots of heavy wool full jackets, and lots of heavy weather coats. A lot of blue denim jeans. Lots of waterproof shoes and boots with high-traction soles, and showing a lot of water, salt, and snow damage. What "flair" there is, if any, is of a southwest and/or cowboy theme.
A large black woman, her hair short dreads. Wearing black t-shirt layered with green vest with jenin jacket. Brown socks with sandals. She's reading a technical manual.
An elderly woman with pixie haircut, sky blue northface coat, open, with two layers of thin sweaters, over a bloase. And a hand knit scarf. Yoga pants. Brightly colored knit socks with sandels. Her eyes look at nothing.
A muscular white man in his late 20s, tightly stretched blue t-shirt with ironic text, blue jeans with rolled and ironed cuffs, scuffed leather ankle boots.
And so on. About 2 dozen people, a mix of white, hispanic, asian, native, and black.
All wearing relaxed layers, mostly in subdoed earth tones, water resistant sport wear, comfortable shoes. Lots of dyed hair in subdued colors, crazy tights, nose rings on office workers, and hoodies. There is not a bit sunlight tanned skin in sight.
If I didn't already know I was in Seattle, inside the city proper, one look at this crowd would tell me where I was.
The first customer was dealing with the aftermath of an all-to-common PayPal issue. Her account had been emptied via PayPal charges and/or chargebacks. The BECU agent said they see that sort of thing all the time. He had the information on hand to report a fraud to PayPal if her account had been compromised, or how to start fighting with PayPal to get her money back if PP themselves were grabbing her money. He also had a process in place to set up a "valve" account keep PayPal at arms length from one's money.
After she left, the next customer sat down. He was a trim white-haired guy, a prototypical small businessman. He was holding a big stack of envelopes branded with the blue Chase logo. The BECU agent asked him what he needed, his response was a blunt "I'm tired of these fuckers, what can you do for me?"
And then it came to be my turn at the ATM.
- Take on as little student loan debt as possible. And if someone will not pay you to get a post-grad degree, don't waste the debt and the time. Keep out of debt. You never want to feel stuck somewhere so to make rent and pay bills.
- Learn to write. You learn to write by writing. Take writing classes, read about good writing, and practice writing. It doesn't matter what kind of job you get or life path you take, you need to know how to write.
- Get involved in some open source projects, and make real contributions to them. The Google Summer of Code is a good thing to get involved in. A portfolio of demonstrated contributions to open source projects is more impressive than a GPA on a new resume.
- Get involved. Find your local makerspaces, hackerspaces, and barcamps. Volunteer and participate. Go to Ignite. Speak at Ignite.
- Always be fluent in at least two programming languages, and practice learning new ones. Languages and frameworks come and go, learning new ones is forever.
- When getting a job, beware of the non-compete and copyright assignment clauses in the employment contract. Push back on them. If they are non-negotiable, too onerous, are enforceable, beware and be careful of taking that job. Keep your list of "personal and outside projects" ready to attach as an appendix.
For years I have been wishing for a "Netflix for Books", for physical books.
Here is how I envision it working:
A large municipal library, or a consortium of them working together, set up a site and paid service very similar to Netflix, only for books.
I, as a user, select how many books at a time I want to rent. There would be different monthly payment levels, just like Netflix.
Books in my queue get checked out from the library or via inter library loan. They get mailed to me, along with a return mailer. Postage would be book rate, of course. Unless I am willing to pay extra for Priority or Express mail.
I read the book, keep it for as long as I want (maybe with a one year maximum), and then either return it with the return mailer or by dropping it off at the library like a regular book.
I could keep using my muni library "for free", or use this service for the convenience factor. It could even be a source of much needed funding for the amazing public library system that we all too often take for granted, and do not use enough.
Jenkins is a pretty standard Java-based web app. The configuration settings are stored in XML files, and that configuration is manipulated using "easy to use" Web GUI.
The "old skool" UNIX-like way to keep configuration settings is in a text file, which is edited with an ordinary text editor, and is read by the program daemon on start or SIGHUP. This is considered "scary", "hard to learn" and "hard to use" by novices.
There is a big problem with GUI-only managed configuration, text file configuration has a major advantage.
I did not set up the Jenkins server or nodes. I am not the only person with admin access to it. Several other people have set it up, set up various projects in it, and added new nodes and new types of nodes.
As I work on it, and look at the existing configuration, I often find things that are "surprising", things that make me say "Is that right? That can't be right? Can it?". And then I have to spend time digging into it. Something it IS right, for reasons I didn't know at that moment. Sometimes it used to be right, but isn't necessary any more. And sometimes, it just wasn't right.
In a textual configuration file, you can put comments. The purpose of a comment is to communicate into the future, to tell those who came after you (including your future self) what you were intending to do, and why you selected some "surprising" option or way of doing things.
There is no good way to put comments into GUI or WebGUI configuration, even if it has a freeform field labelled "comments".
This is actually one of the first and greatest innovations Linus Torvalds achieved with Linux. While the GNU folks developed the idea of free software, they limited themselves by sticking with a just a tight group of core developers, who largely would ignore suggestions and patches from outside. It was Linus' belief that everyone had something valuable to contribute that led the style of open-source development that now dominates the world.
It is maybe an excess of hope to say it "dominates the world".
There is still entirely too much "fauxpen source" software, where corporate dev teams or small mentally incestuous groups emit "releases", while sitting behind legal and social barriers to outside contribution and feedback. The tightly coupled development process results in tightly coupled and poorly documented software, which is hard for "outsiders" to contribute to, and the resulting feedback loop spins around until the software is so knotted up that useful development basically stops. (Of course, closed source software has the same problem, only worse.)
The open development open community model does avoid this problem, and so it's use is spreading.
Mixed in with the mass is the occational business card. For some of the cards, I can remember the person who gave me their card and the context of the meeting. Such cards are much more likely to go into my contacts database.
And a number of the cards are from "social media experts" and look a lot like the "I hate your email signature" part of The Oatmeal: If you do this in an email. And I have zero mental impression of whoever gave them to me. Which is odd, since I am pretty sure that I was there when they were given to me.