There are things we do for the reward. And then there are things we do just for their own sake, driven purely by internal motivation. It looks like the latter is the case for Julia when it comes to teaching computer things. Being able to choose a lifestyle where you can pursue things that intrinsically motivate you is probably the ultimate form of professional satisfaction. Congrats Julia! I'm really looking forward to see what comes out of this.
While I've never bought anything from Julia, I smile every time I see her illustrations online. Those of us who are attracted to tech fields also have a sense of wonder and intense desire to learn and share information. So, when we see others sharing information in ways to help them learn, we respect them tremendously!
In the 1980's I learnt to program on a Commodore 64 with one of Usborne's many computer books (see at the bottom of the page on [1]). Julia's zines remind me of a similar aesthetic and I hope she is also successful at inspiring the next generation of software developers!
I saw Julia speak at KubeCon last year in Seattle. She’s a talented engineer who has found a unique and approachable way of teaching DevOps/SRE tooling and concepts. I wish her much happiness and success in the next year!
I don't want this to be read badly, so let me start with stating my greatest admirations for the author.
I have never bought any of the zines she produces, I am aware of that, and I also check them out several times. What I don't understand is why people bought them.
Do you find them informative? Do they help you somehow? Do you find them cute?
I may not be in the target market, but I don't find them informative, they are so undense of information, moreover are very easily available informations.
Really, let me restate my admiration for her and the ability to run a business, but again I wonder why people consume that kind of content.
The main reason I hear that people buy zines from me is that they find them informative.
I've honestly learned a lot about this from writing zines -- for example my bite size command line zine (https://wizardzines.com/zines/bite-size-command-line/) is mostly composed of things that feel "obvious" to me after using Linux for 15 years ("how to grep recursively"). And I initially also doubted that it was really worth it to write these things down ("won't people just read the man page / google for it instead?")! But:
1. it turns out that things that seem "obvious" when you're experienced are definitely not obvious to beginners, and the man pages are much easier to read when you already understand the tool :)
2. figuring out what the right things to learn even are is difficult, you can't Google for something if you don't know it exists yet
3. many people who aren't beginners still sometimes have some gaps in their knowledge, for example this tweet about CORS has a lot of experienced web developers replying to it saying that they've really struggled to understand CORS and that even a small simple explanation helps them. https://twitter.com/b0rk/status/1162392625057583104
I think of my main audience as being developers who have a couple of years of professional experience but are still missing a lot of fundamental knowledge that can really help you out as a programmer. (like "how does HTTP work?")
I can confirm that I had to show some pages of yours to some people who worked for more than a decade, exclusively writing C++ on Linux but never learned what you so nicely presented in some of your articles.
A lot of people simply stick to the minimum needed to do something. And then they need something condensed enough (and reliable) to make them doing something a bit differently.
In short, I'm very glad you're doing that work. Nobody who hasn't tried know how they poorly most of them would do it: everybody can write long winding rants about some minuscule detail of their own work. Writing a good, reliable and effective broader summary is much harder.
Please also consider having the dates on your work, or connection to the versions of the stuff you write about, you can also sell the new versions with the same title when the topic changes due to the new developments.
That's another weak point of internet: there's so much outdated information still floating as "the" solution.
> Do you find them informative? Do they help you somehow?
Yes. For any area in which one is not already a specialist, it's good to have some source that can give you a reliable starting information.
The internet is full of false, misleading or plainly wrong information, to which I stumble all the time. It's even frequently multiplied across many sites where the "content" is produced by rewriting (or mostly stealing) the content from some other site, and the quality of the information multiplied is irrelevant. So you can even get the impression that the answer is right, because you see the same on many places!
So it's worth having a source even for the introduction-level information for which you know that is reliable and nicely summarized. I've already recognized that Julia's material is that. I can surely recommend Julia's work to anybody who needs a reliable start in some of the topics she covered.
I haven't bought them either, but I do think there's a market.
There are some people who are in technical departments that are not necessarily software developers but due to their responsibilities have a need to understand some technical concepts. I know we have at least one in our department. For him to spend $12 on something that will help him understand what we do better would certainly be money well spent.
They kind of remind me of the Heads First Design Patterns book.
one potential motivation i would personally consider is to support her work. her style feels somewhat refreshing for the content she delivers.
diversity in the approach of tech teaching, i believe, can only be a good thing.
i also think that the alternative method she imploys, with cartoons and colloquial language, helps engage some people who find traditional teaching formats unengaging.
Yeah - especially for those of us that get lost on the big picture when the material gets too deep too fast. Hard to find creative ways to teach GIT for example.
