I'm boiling mad at Patreon. They just shifted their fee structure in a way that increased the cost of my pledges by a whopping 30%, while simultaneously charging Creators a flat 5% fee. That's 35% of my contribution that does NOT make it to the Creators I sponsor!
I prefer to give many small pledges to a large set of Patreon Creators, rather than larger amounts to a few. I feel this best represents my interests, and also ensures I support the less popular of the Creators I admire.
Until today, I have heard nothing negative from the Creators I sponsor about the cut Patreon takes to process and deliver pledges.
I'm listening, and am acting.
I have now decided Patreon has become a vampire, a leach on the system, and is no longer a suitable platform for supporting Creators.
I have halted all my Patreon pledges.
I hope to soon hear what new funding mechanisms my favored Creators prefer, and I will follow them there.
Go to Hell, Patreon.
OK, I feel better now. The underlying problem would appear to be that the US (and the world?) lacks a cost-effective micro-payments system. Which in turn sets the stage for vampires like Patreon to appear and flourish.
Everything is strangled by the 4 major credit card networks, whose fees are growing despite a reduced cost (as a percentage of money transferred) of doing business in general, and a lower cost of transactions in particular.
The excesses in the credit card system are made perfectly evident by the presence of so many "Cash Rewards" cards, which are simply refunding some of the excess to their customers. If you don't have one, get one soon!
A better route may be to use the ACH (Automatic Clearing House), the network used to process EFTs (Electronic Fund Transfers) such as checks, which has a vastly lower transaction fees (though this comes with lower guarantees by the network itself, which are instead taken up by the financial institutions themselves).
The best route may be to build a new micro-payments network from scratch, or expand an improve an existing one.
The Patreon debacle should hopefully cause some engagement on this important financial infrastructure issue.
Thursday, December 7, 2017
Friday, December 1, 2017
How and Why Did I Become an Engineer?
During a recent interview I was asked why I had become an engineer. In that context I gave a few key reasons. Here's the full story.
In high school back in the early 1970's I loved all things Science and Math, but of them all I liked Biology best, by far. When I got to take a computer programming class (using FORTRAN IV), the first program I wrote on my own was to help me calculate the metabolic rates of the rats were were raising in the Biology lab. At that point, I saw programming as a useful tool to know, but not as anything I'd want to pursue as a career.
After high school I chose to join the US Navy rather than go directly to college. There were many reasons encouraging me toward this path, and it turned out to be fantastically right for me. While in the Navy I was trained in several areas, including Nuclear Propulsion. I got to operate a nuclear reactor at the tender age of 19! I also learned lots about gyrocompasses, jet engine control systems, other types of electronics, mechanical and hydraulic system, and a ton of engineering in general.
As I was nearing 6 years in the Navy, I realized I was more than ready to start college. During my last year in the Navy I bought an Apple ][+ with the Language Card and UCSD Pascal. My experience with Pascal was so different from my days with FORTRAN that I immediately knew I wanted to write software for a living. I chose to attend UCSD because I wanted to be associated with a school that not only developed useful technology, but also got it into people's hands.
While applying to UCSD I learned about their Computer Engineering degree, which combined all of a Computer Science degree with the digital half of an Electrical Engineering degree. It let me combine my desire to write software with my military engineering experience.
Upon arriving at UCSD I was immediately overwhelmed. Six years away from high school had taken a toll, and I was far from ready for the rigor of an academic environment. As a Freshman I was struggling to get through the brick wall of the Math sequence, though I had lots of fun with the Physics sequence, particularly the associated lab class.
In my Sophomore year I got to start on some of my technical electives, so I decided to revisit my first science love, Biology. I was extraordinarily fortunate to be taught by Dr. Paul Saltman, a world-renowned molecular biologist who loved to teach undergraduates. I took to the class like a fish to water, my mind absorbing the concepts like a dry sponge, and I aced nearly every test.
Dr. Saltman was unusual in that he created his post-test answer key using not his own answers, but the best of the student answers. I didn't know this at the time of the first mid-term exam, and was surprised to hear my name and several others were called to meet with the professor one day after class. He told us of his answer key approach, and asked if he could use our answers. Of course we all agreed! He then went around the group asking what year we were and what our majors were. It went something like: "Biology", "Bio-Chemistry", "Molecular Biology", "Biological Physics", and when he got to me, I said "Computer Engineering", the only non-bio major in the group.
The same thing happened again for the answer key on the second mid-term, and Dr. Saltman started trying to convince me to switch majors. This was two class sequence, and in the second class he really turned up the pressure, even inviting me to work in his lab if I changed my major!
I kept saying no, but I didn't really have a set of reasons he would understand, much less accept. Then I finally came up with an analogy that worked!
I told him that every time I tested a program I was developing, it could crash and burn in any of a long list of ways, not only ending the program, but sometimes also causing the host system to lockup and reboot. Were I to do similar experimentation in a biology lab, I told him I'd need a Biosafety Level Five containment system. Unfortunately, the Biosafety levels top out at 4. He agreed his profession, and likely the planet, would be safer were I to stay with software, where at least we can pull the plug on the computer.
My engineering experience pointed me toward writing software that interfaced directly with the real world via sensors and actuators, rather than interacting with "users". These are called "embedded" systems, and often require the software to work as fast as things happen in the real-world, called "real-time". So I called myself an embedded/real-time systems developer.
My education, experience and career desires came together in my first job after college: I was hired by General Atomics to write software for radiation monitoring systems for commercial nuclear power plants. I next worked on nuclear reactor monitoring and control systems for a new Navy nuclear submarine. At my next job I worked on automated X-Ray inspections systems for munitions, and on a neutron beam system used to inspect aircraft wings for corrosion.
I've also worked on ultra-high-speed digital video cameras (100,000 fps), on instruments for aircraft, on satellite electronics (for a mission that unfortunately never launched), communication systems for small UAVs, and on many other fascinating systems.
I had many opportunities to step into management roles, but I always chose, perhaps selfishly, to remain a software developer specializing in instrumentation and embedded/real-time systems.
My focus on instrumentation meant I did only a minimum of user interface and web development, and no mobile development at all (other than writing the occasional device driver). I wrote no business or enterprise software, and had only a minimal grasp of IT principles.
While there will always be a need for instrumentation software, my specialization forms an ever smaller fraction of the overall software development landscape. Which has made job searches increasingly more difficult, and interviews more frustrating, as fewer HR people know how to specify and fill positions for instrumentation developers.
That's not to say there's no hope! The explosion of the Arduino and now the Raspberry Pi into the hobbyist market bodes well for a healthy population of embedded/real-time system developers.
After 30 years I'm finding that choosing to stay out of management has made me a relative fossil among the applicants for instrumentation/embedded/real-time developer positions. Rather than beat my head against the wall, I've instead decided to take my skills and experience in a new direction: I'm going to become a STEM teacher, and see how many folks I can convince to become the next generation of engineers!
In high school back in the early 1970's I loved all things Science and Math, but of them all I liked Biology best, by far. When I got to take a computer programming class (using FORTRAN IV), the first program I wrote on my own was to help me calculate the metabolic rates of the rats were were raising in the Biology lab. At that point, I saw programming as a useful tool to know, but not as anything I'd want to pursue as a career.
After high school I chose to join the US Navy rather than go directly to college. There were many reasons encouraging me toward this path, and it turned out to be fantastically right for me. While in the Navy I was trained in several areas, including Nuclear Propulsion. I got to operate a nuclear reactor at the tender age of 19! I also learned lots about gyrocompasses, jet engine control systems, other types of electronics, mechanical and hydraulic system, and a ton of engineering in general.
As I was nearing 6 years in the Navy, I realized I was more than ready to start college. During my last year in the Navy I bought an Apple ][+ with the Language Card and UCSD Pascal. My experience with Pascal was so different from my days with FORTRAN that I immediately knew I wanted to write software for a living. I chose to attend UCSD because I wanted to be associated with a school that not only developed useful technology, but also got it into people's hands.
While applying to UCSD I learned about their Computer Engineering degree, which combined all of a Computer Science degree with the digital half of an Electrical Engineering degree. It let me combine my desire to write software with my military engineering experience.
Upon arriving at UCSD I was immediately overwhelmed. Six years away from high school had taken a toll, and I was far from ready for the rigor of an academic environment. As a Freshman I was struggling to get through the brick wall of the Math sequence, though I had lots of fun with the Physics sequence, particularly the associated lab class.
In my Sophomore year I got to start on some of my technical electives, so I decided to revisit my first science love, Biology. I was extraordinarily fortunate to be taught by Dr. Paul Saltman, a world-renowned molecular biologist who loved to teach undergraduates. I took to the class like a fish to water, my mind absorbing the concepts like a dry sponge, and I aced nearly every test.
Dr. Saltman was unusual in that he created his post-test answer key using not his own answers, but the best of the student answers. I didn't know this at the time of the first mid-term exam, and was surprised to hear my name and several others were called to meet with the professor one day after class. He told us of his answer key approach, and asked if he could use our answers. Of course we all agreed! He then went around the group asking what year we were and what our majors were. It went something like: "Biology", "Bio-Chemistry", "Molecular Biology", "Biological Physics", and when he got to me, I said "Computer Engineering", the only non-bio major in the group.
The same thing happened again for the answer key on the second mid-term, and Dr. Saltman started trying to convince me to switch majors. This was two class sequence, and in the second class he really turned up the pressure, even inviting me to work in his lab if I changed my major!
I kept saying no, but I didn't really have a set of reasons he would understand, much less accept. Then I finally came up with an analogy that worked!
I told him that every time I tested a program I was developing, it could crash and burn in any of a long list of ways, not only ending the program, but sometimes also causing the host system to lockup and reboot. Were I to do similar experimentation in a biology lab, I told him I'd need a Biosafety Level Five containment system. Unfortunately, the Biosafety levels top out at 4. He agreed his profession, and likely the planet, would be safer were I to stay with software, where at least we can pull the plug on the computer.
My engineering experience pointed me toward writing software that interfaced directly with the real world via sensors and actuators, rather than interacting with "users". These are called "embedded" systems, and often require the software to work as fast as things happen in the real-world, called "real-time". So I called myself an embedded/real-time systems developer.
My education, experience and career desires came together in my first job after college: I was hired by General Atomics to write software for radiation monitoring systems for commercial nuclear power plants. I next worked on nuclear reactor monitoring and control systems for a new Navy nuclear submarine. At my next job I worked on automated X-Ray inspections systems for munitions, and on a neutron beam system used to inspect aircraft wings for corrosion.
I've also worked on ultra-high-speed digital video cameras (100,000 fps), on instruments for aircraft, on satellite electronics (for a mission that unfortunately never launched), communication systems for small UAVs, and on many other fascinating systems.
I had many opportunities to step into management roles, but I always chose, perhaps selfishly, to remain a software developer specializing in instrumentation and embedded/real-time systems.
My focus on instrumentation meant I did only a minimum of user interface and web development, and no mobile development at all (other than writing the occasional device driver). I wrote no business or enterprise software, and had only a minimal grasp of IT principles.
While there will always be a need for instrumentation software, my specialization forms an ever smaller fraction of the overall software development landscape. Which has made job searches increasingly more difficult, and interviews more frustrating, as fewer HR people know how to specify and fill positions for instrumentation developers.
That's not to say there's no hope! The explosion of the Arduino and now the Raspberry Pi into the hobbyist market bodes well for a healthy population of embedded/real-time system developers.
After 30 years I'm finding that choosing to stay out of management has made me a relative fossil among the applicants for instrumentation/embedded/real-time developer positions. Rather than beat my head against the wall, I've instead decided to take my skills and experience in a new direction: I'm going to become a STEM teacher, and see how many folks I can convince to become the next generation of engineers!
Subscribe to:
Posts (Atom)