aka Jim Winstead Jr.
Hire me! (click for details)
I am a software developer. After teaching myself to code on Apple II computers in junior high school and building software for our family-owned telecom business, my degree in Computer Science from Harvey Mudd College gave me the grounding for a career in software development where I was able to let my programming freak flag fly: I worked for Knowledge Adventure, an educational/games software company (where I first started leading teams of developers), HomePage.com, an internet startup (where we developed a white-label free web hosting platform), and MySQL Ab (where I led the web development team and then transitioned over to the server development team).
Through this time I was also involved in the open source community. In college, I was involved in the very early days of Linux, and I took over maintenance from Linus of the “root” disk used to install Linux before distributions. While working on websites for Knowledge Adventure, I got involved with the the PHP project, and became a founding member of the PHP Group. I helped set up and maintain some of the collaborative development infrastructure, including the mailing lists and online documentation feedback system. Then at HomePage.com, I contributed work we did related to `mod_perl`, and became a member of the Apache Software Foundation.
After MySQL Ab was acquired by Sun Microsystems (and then further by Oracle), I co-founded Raw Materials Art Supplies, a retail store in downtown Los Angeles which I have been operating as general manager for the last 15 years. I built Scat POS, a point of sale and ecommerce system using PHP and MySQL that we are using to run the business. It has involved a lot of integration work (payment processors, product feeds, shipping), and I automated as much as I could to focus on our artists' needs. This enabled us to build our business from scratch into one of the top independent art supply stores in the country.
I'm looking for individual contributor roles. PHP/MySQL is the core of what I do best, but I'm comfortable with full-stack web development, Linux system administration, C/C++, Docker, and confident in my abilities to jump into any tech stack and get up to speed quickly.
View my LinkedIn profile for some dates and details, and my GitHub profile for some of my open source contributions. Contact me to discuss opportunities.
Kill It with Fire
Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones) by Marianne Bellotti was recommended to me by a college classmate on a post I made on LinkedIn a while back. (Part of a series of observations about how terrible ZipRecruiter is.)
This book is great, and I would highly recommend it to any software engineer. It’s not only about modernizing software applications, but has a lot of insight into how being a long-lived project is a reasonably likely outcome for any project, and you can save someone in the future from a lot of trouble by making some better decisions up front.
It also leans into the human factors and business realities of how software is developed, something I feel like I have been complaining about here and elsewhere.
Something I had to flag
“We had the chance to review your application and while your experience is impressive, it doesn't align perfectly with what the team is looking for so unfortunately we won't be moving forward with your candidacy.”
I can’t help but feel that I dodged a bullet on this one, because looking for “perfect” alignment from a candidate is a huge red flag.
It is also a really strange thing to say when you put this in your job description:
“P.S. If you don’t tick every box in this ad, please don’t rule yourself out. We take pride in inclusion and hiring incredible human beings with great potential over ticking boxes – so if this role resonates with you, hit that apply button!”
I’m a white guy with an enormous amount of privilege, so whatever. But I hope that Linktree isn’t sending this awful form rejection to the diverse candidates they claim to be trying to include.
The Mountain in the Sea
The Mountain in the Sea by Ray Nayler explores what happens when humans create and encounter other intelligent life here on Earth. There’s an artificial intelligence in the form of an android, created as a Frankenstein’s monster from bits and pieces of the minds of humans but becoming something else, and then an emerging civilization of octopus that appears to have developed a written language. The backdrop is another hyper-capitalist dystopia where automated trawlers staffed by human slaves are scraping the last bits of protein from the oceans.
It’s a richly-drawn world, but the novel feels a little unfulfilling because it doesn’t just tell a complete story. There are a few parallel story lines that really only come together in the last couple of chapters, and clearly there could be a lot more to the story.
This speech by Martha Wells at the annual Jack Williamson Lecture at Eastern New Mexico University in Portales, New Mexico helped me connect some of the themes between The Murderbot Diaries and this novel.
Somebody thought of that
I get a little antsy when all of the posts with images have fallen off the front page of my site. The other day, I took this picture of a rainbow from our window and I had been trying to find something appropriate to say to go along with it, but have not.
Certifiable
Because I am paying for a “LinkedIn Premium” membership during my job search, which has mainly been useful for letting me see who is looking at my profile, I decided to see what other benefits I could wring out of it. Access to their library of online courses was an obvious one to check out, and after a day of going through some lessons on Docker, I am the official holder of a “Docker Foundations Professional Certificate.”
As a software engineer with a fancy degree from a fancy school, the idea of certification feels a little down-market to me. It’s on the other side of that strange divide between computer science and information technology. That line has gotten a lot fuzzier over the years, with “DevOps” trying to give a name to that overlapping space between developer and system administrator.
(Look at me, calling myself an engineer instead of just a developer. Funny that the most prestige seems to have gotten attached to engineer instead of scientist. My fancy degree is in “Computer Science” but I don’t know that I’ve ever seen someone call themselves a computer scientist outside of academia.)
Another time I found myself facing that sort of divide was in high school when I mentioned to a classmate that I was thinking of taking a “shop” class as an elective and they were horrified. I was supposed to be on the college-bound, AP-class-taking trajectory.
Did I learn anything from the training on LinkedIn that I didn’t already know? Not particularly.
Is the certification that I earned on my profile now? Of course.
Now I’ve got my eye on that “Career Essentials in GitHub Professional Certificate.”
System Collapse
System Collapse by Martha Wells is the latest entry in The Murderbot Diaries series. The series is made up of short stories, novellas, and novels, so I always feel awkward referring to the individual components.
Whenever I read the latest Murderbot installment, I am reminded of the story I told a long time ago about how I took offense to another customer at the bookstore describing the book in a series I liked a “popcorn” book. It would be easy to see how I could say the same thing now about the Murderbot books and similarly offend a fan, because calling it a “popcorn” book seems reductive and dismissive.
The series is sort of infamous for strongly connecting to a neurodivergent audience. The main character, whose inner monologue narrates the stories, is non-human but very directly inspired by the author’s own experiences with depression, anxiety and not being neurotypical.
I certainly feel that connection. I have a constant inner monologue that I am very much reminded of by the writing of Murderbot. I’ve never been diagnosed with ASD or ADHD, or even anxiety or depression, but I certainly have self-diagnosed to varying degrees with all of those. I look at information about monotropism and see myself in much the same way that I see myself in Murderbot. It’s not directly me, but has helped improve the context in which I understand myself.
This story, like most of the others, is compact. There is action, but if I think had to describe what it is about I would say it is mostly about Murderbot deciding how to open themselves up to others and connect their own story with theirs. It’s about post-capitalism up against a hyper-capitalist society. It’s about how media informs how we view ourselves.
It is a wonderful series of stories, and this one is no exception.
It will be really interesting to see how the Apple TV+ series based on the series will turn out.
Breaking down the profitability of a online retail sale
I saw a small business owner post on social media somewhere complaining about how hard it was and part of what they complained about was how much they had to pay in sales tax. That is one of those misconceptions that irritates me because the way you have to think about sales tax as a retailer is that it is money you are collecting for the state from your customer, not money that you as the business are paying to the state.
That money you collect for sales tax is never yours, although you may get to hold on to it between the time you collect it from the customer and you submit your monthly (or quarterly) payment to the state.
So you should never, ever, ever include sales tax collected in your sales figures. It’s not really ever your money, and it only seeks to confuse things if you think of it as such.
But that led me to thinking it might be useful to some people to break down an actual sale to an online customer from our store on March 31, 2023. The customer was in Nevada, and they paid us with PayPal. Here’s what it looked like from their perspective:
Quantity | Description | List Price | Discount | Sale Price | Extended |
---|---|---|---|---|---|
2 | 6x12 3/16in MDF Panel | $4.19 | 50% | $2.10 | $4.20 |
1 | 4oz Gloss Waterborne Acrylic Varnish | $13.69 | 30% | $9.58 | $9.58 |
Shipping & Handling | $7.80 | $7.80 | $7.80 | ||
Subtotal | $21.58 | ||||
Tax | $1.80 | ||||
Total | $23.38 |
The MDF panels were sold at a 50% discount, and the extended price on that line is a demonstration of how your method and timing of rounding in calculations can lead to results that may surprise someone. You might think two items that cost $4.19 that are 50% off will cost $4.19 in total, but if your calculation actually looks like: $quantity * ROUND_TO_EVEN($price * $discount)
that will give you a different result than ROUND_TO_EVEN($quantity * $price * $discount)
.
Okay, so our gross revenue for this sale is $21.58. (Remember, don’t count the tax!)
Now I’ll pull back the curtain and reveal our costs:
Quantity | Description | Cost | Extended |
---|---|---|---|
2 | 6x12 3/16in MDF Panel | $1.05 | $2.10 |
1 | 4oz Gloss Waterborne Acrylic Varnish | $5.61 | $5.61 |
Shipping & Handling | $7.80 | $7.80 | |
Subtotal | $15.51 | ||
Transaction Fee | $1.31 | ||
Packaging | $0.87 | ||
Promo Items | $0.50 | ||
Total | $18.19 |
Okay, nothing too shocking there. We did get fortunate and the shipping calculation done our website matched our actual shipping cost exactly.
PayPal collected $1.31 in transaction fees ($0.49 + 3.49% of the full transaction amount - one place where the sales tax does cost us).
We didn’t really account for it on a per-sale basis like this, but I added in the expenses for the box we shipped the order in, and the promotional items (branded pencil and stickers).
So after adding up all of these costs, we ended up with a net profit of $3.39. That’s a net margin of about 16%.
That didn’t all end up in our pockets, of course. We had employees, rent, insurance, other business expenses, and debts to service.
A difference between this and an in-person sale is that the shipping stuff would be a non-issue, of course. Another is that our transaction costs for payments in person were much lower (about 2% on average for cards, or essentially zero for cash).
A larger online sale might have triggered our free shipping, but the per-sale costs (fixed part of transaction fee, the box, the promo items) wouldn’t have taken as much of a bite on a percentage basis.
In conclusion, the margins weren’t great, and without enough scale, the overhead will kill you.
Open source and anxiety triggers
I have been thinking more about bullying in the open source community being a security problem and how part of the process of getting the XZ backdoor into play was playing into the mental health struggles of the original maintainer.
It reminded me of a flawed system that I found having a large impact on my mental health while running our store. Like any diligent small business, we claimed our listings on Yelp and Google and the other major spots where people leave reviews.
I can still feel my stomach dropping when I would get a notification from Yelp that said someone had left a review. Thosee notifications didn’t give the single most critical bit of information: how many stars. Was it going to be a nasty one-star review, or was it someone leaving a wonderful five-star review? No clue! First you have to log in to the Yelp for Business website to see how the rest of your day would feel.
It was the “we need to talk later today” message from your boss that anyone could lob at me at any moment, maybe without even knowing they were doing it.
This was also brought to mind when I read about Daniel Stenberg’s experience with AI-generated security bug reports for curl
and besides the aggravation of the reports being nonsense, I could only imagine that adrenaline spike when the report first comes in.
And bringing this back to something I linked to yesterday, where someone from Microsoft reported an issue with ffmpeg
as “high priority”. Again, I can imagine one of the maintainers reading this request and feeling that adrenaline spike, that anxiety trigger.
It turns out that it wasn’t even a bug in the project, the reporter just didn’t know the right command line options to use. (I will also point out that they also said they were going to provide updates on whether the free support they received worked, but then they never did.)
Maybe the ffpmeg
maintainers and Daniel are good at shrugging this stuff off. I thought I was, but one of the lessons that I learned from running our store is that the effects are cumulative even when individually small, and it is a good idea to figure out how to combat it.
And while there won’t be any simple technical solutions to these human problems in open source, it is very important to make sure whatever tools are being built don’t create these same sorts of anxiety spikes. We need to make sure to build kindness into the tools, whatever they may be.
Maintenance engineer, slightly used
A popular response to the attempted backdooring of the XZ Utils has been people like Tim Bray talking about the maintenance of open source projects and how to pay for them.
When I transitioned from leading the web development team at MySQL to an engineering position in the server team, I spent the first year as a maintenance engineer. I blogged a little about the results of that one year and calculated that I had fixed approximately one reported bug per working day.
But you’ll also notice that I had to heap some praise on Sergei Golubchik who reviewed fixes for even more bugs than I had fixed. (He also was responsible for working on new features. He is extremely talented, and I’m not surprised to see he’s the chief architect at MariaDB.)
That sort of reviewing and pulling in patches is a critical component of maintaining an open source project, and a big problem is that is not all that fun. Writing code? Fun. Fixing bugs? Often fun. Reviewing changes, merging them in, and making releases? A lot less fun. (Building tools to do that? More fun, and can sidetrack people from doing the less-fun part.)
It is also a lot different for projects with a lot of developers, a small crowd of developers, and just a few developers. The process that a patch goes through to make it into the Linux kernel doesn’t necessarily scale down to a project with just a few part-time developers, and vice versa. A long time ago, I made some noise about how MySQL might want to adopt something that looked more like the Linux kernel system of pulling up changes rather than what was the existing system of many developers pushing into the main tree, and nobody seemed very interested.
Anyway, as people think about creating ways of paying people to maintain open source software, I think it is very important to make sure they don’t inadvertently create a system that bullies existing open source project maintainers to make them focus on the less-fun aspects to developing software, because that’s kind of how we got into this latest mess.
You already see that happening with supposed-to-be-helpful supply chain tools demanding that projects jump through hoops to be certified, or packaging tools trying to push their build configuration into projects (with an extra layer of crypto nonsense), or a $3 trillion dollar company demanding a “high priority” bug fix from volunteers.
I am curious to see where these discussions lead, because there is certainly not one easy solution that is going to work everywhere. It will also be interesting to see how quickly they lose steam as we get some distance from the XZ Utils backdoor experience.
(Also, I’m still looking for work, and I’m willing to do the less-fun stuff if the pay is right.)
But I still haven’t found what I’m looking for
I’m still looking for a job.
It is a new month, so I thought it was a good time to raise this flag again, despite it being a bad day to try and be honest and earnest on the internet.
I wish I was the sort of organized that allowed me to run down statistics of how many jobs I have applied to and how many interviews I have gone through other than to say it has been a lot and very few.
Last month I decided to start (re)developing my Python skills because that seems to be much more in demand than the PHP skills I can more obviously lay claim to. I made some contributions to an open source project, ArchiveBox: improving the importing tools, writing tests, and updating it to the latest LTS version of Django from the very old version it was stuck on. I also started putting together a Python library/tool to create a single-file version of an HTML file by pulling in required external resources and in-lining them; my way of learning more about the Python culture and ecosystem.
That and attending SCALE 21x really did help me realize how much I want to be back in the open source development space. I am certainly not dogmatic about it, but I believe to my bones that operating in a community is the best way to develop software.
I think my focus this month has to be on preparing for the “technical interview” exercises that are such a big of the tech hiring process these days, as much as I hate it. I think what makes me a valuable senior engineer is not that I can whip up code on demand for data structures and algorithms, but that I know how to put systems together, have a broader business experience that means I have a deeper of understanding of what matters, and can communicate well. But these tests seem to be an accepted and expected component of the interview process now, so it only makes sense to polish those skills.
(Every day this drags on, I regret my detour into opening a small business more. That debt is going to be a drag on the rest of my life, compounded by the huge weird hole it puts in my résumé.)
Frozen Soup is now based
Frozen Soup, my Python library/tool for creating a single-file version of an HTML page got another release that adds handling of <base> and specifying selectors to knock out.
This is another one where I had to re-do the release because of something dumb. This time it was forgetting to bump the version in pyproject.toml
. I should look into how to have it automatically figure that out from the tag during release.
Monolith is another project like this that is written in Rust.
Is GitHub becoming SourceForget v2.0?
Back in the day, open source packages used SourceForge for distribution, issue tracking, and other bits of managing the community around projects but it eventually became a wasteland of neglected and abandoned projects and was referred to as SourceForget.
As I have been poking around at adding Markdown parsing and syntax highlighting to my PHP project, I can’t help but feel like GitHub is taking on some of those qualities.
Parsedown is (was?) a popular PHP package for parsing Markdown, but the main branch hasn’t seen any development in at least five years, and the “2.0” branch appears to have stalled out a couple of years ago. Good luck figuring out if any of the 1,100 forks is where active development has moved.
I think it would be good if more community norms and best practices were developed around the idea of the community of a project being able to take over maintenance when the developer steps away. What’s the solution to the thousands of open issues on GitHub that ask if a project is abandoned?
Here is an issue I found on one project where the developer is trying to hand over more access to community members, and I wonder if a guide to taking your project through that transition would have been valuable to move it along.
Another way this comes up that is very relevant is the assertion put forth in “Redis Renamed to Redict” which really asks the question what moral rights the community has to a project.
(SourceForge also came to be loaded down with advertising and I remember it being kind of a miserable website to use, and as GitHub loads up with “AI” features and feels increasingly clunky to use, it’s just another way I wonder if we are seeing history repeat itself.)