coverclock

Small tech companies tend to be design or engineering led. Organizations grow and evolve, and as they become large they become marketing or finance led.

I too have tried to use a USB power bank as a kind of DIY UPS to power a Raspberry Pi SBC. What I learned - which may be unrelated to your experience - is that all of the several power banks I tried can be either charging, or powering a device, but not both at the same time. So my Raspberry Pi would run until the power bank got low, then the power bank would cut power to the Pi and charge itself, then power the Raspberry Pi up again. I had to buy a power bank specifically advertised as a USB UPS; that worked fine. The normal power bank seems to be designed to charge a battery powered device like a mobile phone (whose own battery can be thought of as a kind of UPS for the device), but not a device that requires continuous power (like the Pi).

I wrote a blog article on this very topic several years ago: https://coverclock.blogspot.com/2012/12/passion-practice-pro...

Yes, lots of them. I hate reading on the screen, enough that I own a color laser printer more or less just to print articles that I want to read that are online. But for the most part, I find articles in print magazines to be far superior over what is online: better moderated, more interesting, better written, etc. This probably isn't a complete list, but I pay for: THE NEW YORKER, BUSINESS WEEK, THE ATLANTIC, TIME, WIRED, MIT TECHNOLOGY REVIEW, HARVARD BUSINESS REVIEW. I also take advantage of online content that my subscriptions provide. You'll note that none of those are computer related stuff; that I do get online, but that's in part because all of the print computer magazines I subscribed to went out of business.

Being able to get feedback can be both a pro and a con, depending on the nature of the feedback.

Sometimes you can use information asymmetry to your advantage; thinking in public may work against that.

For sure thinking in public can be a form of marketing, especially if you are self-employed, like I am.

Having said all that, I've been writing a public blog since 2006, and have 39 repositories in GitHub, most of which are public, and that is a form of thinking in public as well. So I guess I cast my vote on the issue a while ago. I try to be authentic, honest, true to my values, open to change, and be the best person I can be, when I share my opinions.

I also have a MacBook Pro and a GPD Micro PC. The latter is ideal for taking into the field (in the case of my GPS work, literally a field) to connect to the various pieces of hardware I deal with. It's really a pocket-sized industrial PC, in the sense it has a lot of physical ports, e.g. Ethernet, a DB9 serial port, etc. taking it quite useful for hardware hackers.

Historically, this is what people have used public libraries and university libraries for. They're typically not internet-free spaces, but a little discipline on the user's part solves that.

Some time ago I wrote a blog article about the lab notebooks I use.

https://coverclock.blogspot.com/2008/07/daily-organization.h...

I'm an embedded/real-time/systems software developer. The realms I work in tend to be either the very small or the very large. When I wanted to learn Rust and Go, I coded the same application in both of them, one that I had previously coded in Java, C++, and C: I implemented the Generic Cell Rate Algorithm using a virtual scheduler. The GCRA is a traffic shaping algorithm that takes as parameters a desired peak rate, sustained rate, and maximum burst size, to meter or police traffic. I coded it as a library function, and provided a unit test to convince myself that it worked. I can only learn by doing, and that's what I did. One of the reasons I like this approach is it requires a lot of stuff: threads, synchronization, modularization, etc. https://coverclock.blogspot.com/2018/11/vamoose-rustler.html

We were lucky that the recent tragic Marshall fires in the Boulder Colorado area didn't directly affect us, even though our home was near the boundary of a pre-evacuation area. But I have two colleagues who lost everything, and had almost no warning when the fire swept through their housing developments. So I finally put together a go-bag, a second go-bag just for our Beloved Feline Overlords, and put all our really important documents in a portable fire safe with a handle. I hope I never have to test this scheme.

"Measuring and Managing Performance in Organizations" by Robert Austin [Dorset House, 1996].

Austin, who at the time he wrote this was an executive with Ford Motors Europe, was working on his Ph.D. in Organizational Research at (I dimly recall) Carnegie Mellon. He writes about "measurement dysfunction", when human resources etc. policies drive organizations sideways, based on his application of Agency Theory (an offshoot of Game Theory) to incentive programs. This book is based on his dissertation. Very short. Extremely readable. Completely changed my worldview.

Related: my Hazer (com-diag-hazer) LGPLv2 repo, which makes extensive use of Diminuto, is my go-to tool for evaluating GPS/GNSS/IMU devices or building geolocation tools. I do use stuff like the GPS Daemon (gpsd) in many of my precision timekeeping projects. But if I need to get closer to the direct output of the device (which is typically the case), step 1 is cloning, building, and installing Diminuto and then Hazer. I find I can only learn and internalize stuff by doing, and Hazer is my mechanism to keep abreast of technology in this field.

At last count I have 36 repos on GitHub - some private - but by far the one that has been the most useful is my Diminuto (com-diag-diminuto) LGPLv2 repo that is a library of C/GNU/Linux-based functions and tools that provide simpler (for me anyway) APIs for tasks that routinely crop up in the kind of embedded programming I typically do: logging, time keeping, sockets, linked lists, red-black trees, GPIO, threads, etc. It's saved me a lot of time in other C development, both my own side work (e.g. com-diag-hazer), and in several commercial products I've worked on for clients, to have a library that is already unit tested and with which I have years of experience using.

Everyone has their own preferred mode of learning. Mine is hands on, learning by doing. I can't learn new material just by reading a book (although I have friends and colleagues that appear to be able to do so). I have over thirty repos on GitHub, most of which are the result of one learning experience or another: GPS, SQLite, yacc/lex, Go, Rust, etc. For some of these, I had to buy hardware, e.g. an eval board, GPS receivers, etc. That's what works for me. Your mileage may vary.

1. I can only learn by doing. If I can't turn it into a project, then I'll never internalize the details, and cannot really claim to have learned anything. 2. For it to be a project, there has to be a deliverable. Could be a repo on GitHub, a clock sitting in the living room, a blog article, or something repaired around the house. But there has to be an artifact I can point to when I say "I learned this." 3. Don't get stuck. If progress gets delayed on one part of the project and you have to wait for something - whether it's a part, or it's just going to take some time to figure something out - then work on another part of the project in the meantime. Keep moving forward, even if it's not the central thing in which you're interested, even if forward motion is slow.

I do embedded, real-time and distributed product development for clients in the commercial, enterprise, aviation, defense, and big science domains. I probably own two dozen Pis of various vintages (and just ordered one of the new Pi 4 models). It's my go-to platform for prototyping, especially for ARM-based systems. I keep one on my LAN just to regression and unit test software that I otherwise developed on an Intel platform. I've also used Pis in devices that are more-or-less permanently deployed, like an NTP server that uses a GPS-disciplined chip-scale cesium atomic clock as its oscillator, and a home-built WWVB clock. I'm currently using three Pis in a Differential GNSS system I'm prototyping.

Unless you're a computer scientist studying algorithms, probably not. But when I defended my Master's thesis in CS way back in 1983 - yes, I'm that old - my fiancee[1] gave me the three-volume set of Knuth as a graduation gift. I had used his algorithm for arbitrary precision arithmetic in my thesis project. I had figured out addition and subtraction trivially, and had gotten multiplication on my own, but division eluded me. I credit Knuth in part for my being able to graduate with my M.S. Also: my thesis advisor had found a mistake in an earlier edition and was credited in the notes in the back of one of the volumes. So: your mileage may vary. [1] Still married, 35 years at last count.

"Measuring and Managing Performance in Organizations" by Robert D. Austin, Dorset House, 1996. Changed my entire world view. The basic idea - which Austin arrives at using an offshoot of game theory - is that all incentive systems will be gamed by the people to which they are applied, and there is no way around it.

MEASURING AND MANAGING PERFORMANCE IN ORGANIZATIONS by Robert D. Austin

Austin, who is now on the faculty of Harvard Business School, wrote this seminal book on measurement dysfunction and how incentives in the information age drive misbehavior while he was an IT executive with Ford Motor Co. Europe. This very readable book was derived from his dissertation in operations research at CMU. It completely changed my world view, and continues to do so.

I'm a little surprised at the number of people that are saying "paper" or "printer". I agree. The technology to read complex technical topics online just isn't there yet, remarkably. I do plenty of reading online as I'm working on stuff, and I read recreationally (fiction and non-fiction) almost entirely on a Kindle. But for some stuff, there's just no substitute yet for paper. High contrast, portable, annotatable, and persistent.

It's very rare for me to read a technical book cover to cover. I recently read IPv6 FUNDAMENTALS by Graziani (Cisco), but that was more an act of desperation. The best CS-related book I've ever read was probably MEASURING AND MANAGING PERFORMANCE IN ORGANIZATIONS by Robert Austin. It completely changed the way I see the world, both professional and personally. Austin uses agency theory, an application of game theory, to show how incentives in an information economy drive dysfunction into organizations because not all metrics of behavior can be adequately or economically measured. This is extremely applicable to, for example, incentive programs in high tech organizations. At the time he wrote it, Austin was working on his Ph.D. in (I dimly recall) operations research at Carnegie Mellon while working as an executive in IT for Ford Motor Company Europe. Now he's on the tenured faculty at Harvard Business School.

1. Started working full time at 19. 2. Still alive at 60. 3. Worked hard in every job. 4. Maximized retirement contributions. 5. Only owned two houses. 6. Paid off current home as quickly as possible. 7. No debt other than credit card paid off monthly. 8. Only married once (and still) 32 years ago. 9. Spousal unit has same fiscal strategy as me. 10. We never had kids. We can both afford not to work, although we both choose to. I can't say we're especially frugal. I own four Swiss mechanical watches, a brand new Subaru WRX Limited, and lots of other toys, and have traveled all over the world, all of which I paid cash for (or paid card off each month).