https://herman.bearblog.dev

ᕕ( ᐛ )ᕗ Herman's blog

https://herman.bearblog.devᕕ( ᐛ )ᕗ Herman's blog2024-03-09T04:36:57.936684+00:00hermanhiddenpython-feedgenHi I'm Herman Martinus. I'm a maker of things, currently working on Bear Blog and JustSketchMehttps://herman.bearblog.dev/why-pictures/Why Pictures2024-02-28T12:59:30.496864+00:00hermanhidden

For a brief period circa 2016 I wrote and published a weekly webcomic. I wanted to run a successful webcomic along the lines of Poorly Drawn Lines, Oglaf, or The Oatmeal. I love reading these and am always thrilled when one pops up on my RSS feed.

Prior to this experiment I didn't appreciate the sheer amount of effort that goes into ideation, creation, and publishing of even short webcomics, let alone full-blown comic books. Needless to say, I've come to respect comic artists even more.

Considering I released the domain whypictures.com about 2 years ago, I thought it may be nice to archive my abandoned comics here. Some of them are funny, most of them are just plain dumb.

Enjoy!

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

ᕕ( ᐛ )ᕗ Herman's blog

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2024-02-28T12:58:09.793252+00:00https://herman.bearblog.dev/the-future-of-self-driving/The future of self-driving2024-02-15T07:37:02.878097+00:00hermanhidden

Modern self-driving technology still has a way to go before it becomes generally safe, and useful enough for broader adoption. While I do believe that at some point in my lifetime I'll be able to hail an eTaxi, it'll really depend on where I am, the road infrastructure, and the local laws and regulations.

Fully independent autonomous vehicles have a few other shortcomings (assuming we get the tech right). The first is that traffic will not be a solved issue. In-fact, it may become an even bigger issue once the friction of learning to drive (or even being old enough to get a license) is removed.

This is compounded by the natural "rush hour" cycle (which, lets be honest, isn't an hour) where the suburban population surges into the city in the morning for work, then out again in the late afternoon, competing with one-another to get home.

Let me propose a radical new idea: The hitched pod.

Instead of fully independent vehicles which cause traffic and phantom traffic due to how they accelerate, hitched pods are mechanically bound to one another. This creates space efficiency on the roadway, and due to their mechanical linkage they all accelerate uniformly.

These hitched pods would not have to be independently owned either, reducing the commuters high up-front cost of vehicle ownership. Instead they could be operated either privately or publicly since vehicle time-usage for the average commuter is only about 5-10% of their day with their vehicle sitting dormant and depreciating the other 95% of the time. This is the real "sharing-economy" at work.

Not only does this make trips cost effective for average commuters, the hitched pods could also be time optimised using algorithms to ensure they handle the flow of commuters as efficiently as possible (eg: in the morning more pods bring people in from the suburbs, and vice-versa in the afternoons).

This also frees up parking space in cities, which reduces the burden on local governments and independent car drivers looking for a place to park their vehicle, but also creates a better overall atmosphere for residents. Parking lots could be transformed into apartments (increasing urban density and housing availability), businesses (increasing livelihood through more foot traffic), or green spaces (which are just great).

There are a few optimisations that could make hitched-pods the de-facto transportation of the future.

  1. There could be consistent hop-on hop-off points with fixed times (say every 15 minutes) so commuters can easily plan their commute.
  2. Payments could be made simply by tapping a bank card reducing the need for apps. It also means commuters can get on a hitched pod even when their phone is dead.
  3. Open the mechanical linkages between the pods so commuters can easily find a place to sit (or stand) during transit. This would allow for better space efficiency and reduce the cost of the system per commuter.
  4. The city could create dedicated lanes for hitched-pods so that they avoid traffic. This is both a boon to the hitched-pod riders and independent vehicle users since there will be less vehicles on the road overall, and therefore less car traffic.
  5. Instead of using a self-driving pilot car (which relies on fallible AI and complex sensors and systems to operate) we instead use a mechanical direction system. I propose 2 steel beams which the pods rest upon on conical wheels. This will ensure the pods do not go off-route, and also reduces rolling friction and, therefore, the energy required to move the pods.

I know the idea of transporting hundreds of thousands of people efficiently seems neigh impossible. But I think this idea just might work if we put our minds to it.

...trains. I'm talking about trains.

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2024-02-15T06:46:39.889626+00:00https://herman.bearblog.dev/ai-tutoring-what-works/AI tutoring; what works?2024-02-01T06:44:43.202693+00:00hermanhidden

It's 2024 and LLMs are still the "hot new thing". Looking back on 2023, I'm surprised how quickly I went from, "Wow! My computer is speaking to me in fluent and comprehensible English," to, "Eh, that could have been phrased/executed/generated better."

Back in the early 2010s, my mother created and ran a non-profit project called Dr Math. This used volunteer students from the University of Pretoria as math tutors via Mxit (the mobile IM popular in South Africa at the time, running over WAP).

The infrastructure was fairly simple. Volunteers would use a computer at the institute loaded with software that allowed them to tutor multiple students at once. They’d do this after school hours into the early evening, giving students whose parents couldn't or wouldn't help them with their homework a helpful nudge in the right direction.

And it worked pretty well! Within a few years, Dr Math had tens of thousands of students all over the country using the service for help with their math homework, studies, and exam prep. And all for free.

For those who don't know, South Africa is a country of contrasts. There is extreme poverty and extreme wealth living side by side. If you fall within the lucky ~20% of the population, your lifestyle looks something akin to Europe or certain parts of the USA, but at a much lower cost of living.

The majority of the population suffers from poor service delivery and other socioeconomic problems, with education falling way behind the developed world. It's like two distinct countries overlaid on one.

And this was where Dr Math fit in.

It wasn't supposed to be "the perfect education tool". Instead, it was a step up. A foot in the door for those students who were the most underserved.

Unfortunately, due to some government-funded institution bureaucracy, the project was shuttered once my mother left the institute, and the whole project ground to a sad halt.

It has been sitting at the back of my mind ever since, and with the release of the GPT 3.5 API, the idea of using it to tutor maths (and later other subjects) with the Socratic method was the perfect catalyst to reignite this project.

The prototype of the project, built in collaboration with my mother and a friend (now business partner), used GPT 3.5 with two agents watching one another to make sure the conversation didn't go off track (this was before the easily steerable and much more powerful 4 came out). This prototype allowed us to get all the infrastructure in place and test our assumptions until gaining access to the GPT 4 API. We hooked the chatbot (Prof Pi, later Botsy) up to WhatsApp and ran a few pilot projects.

There are a few reasons we chose WhatsApp:

  • Smartphone penetration is great in Africa, and even inexpensive phones have WhatsApp pre-installed here
  • WhatsApp is used as the de facto means of communication throughout Africa
  • Some cellular service providers zero-rate WhatsApp data, making using the service completely free to the end user

And incredibly enough, this worked as well. Arguably better than human text-based tutors (although more on that later). While LLMs in general are not great at calculations (this issue has since been mostly solved with code-interpreter), using the Socratic method of teaching meant the onus was on the student to do the calculations with the tool prompting them and helping them along. LLMs are also infinitely patient, unlike human tutors, and so would stay cheery and online, helping even the most frustrating of students.

We had multiple pilot projects running throughout Sub-Saharan Africa. There were 2 large high-school cohorts and a university-level cohort in Tanzania, and an interesting and tragic cohort at a University in North Sudan.

The latter pilot was based in Khartoum, and it happened to be running when the unrest started and students couldn't leave their houses due to shooting in the streets. Many used our tool as their sole means of studying during this time, asking it to generate practice problems, as well as discussing concepts and exploring the curriculum material. All this in fluent Arabic.

There are many things we learned about AI tutors during this time. But a few are fairly novel.

They say that you can give a sufficiently motivated student a library card and they will become a physicist. But most students with library cards aren't physicists.

This holds true for AI tutors as well. While they are a fantastic tool for assisted learning, they only have the ability to respond. They are unable to engage a student. Instead, the AI tutor may assist or prompt them, leaving the responsibility of learning on the student and their personal reserve of motivation.

One of our other pilot projects partnered with a South African eLearning company that provided low-cost, live video lessons. The AI tutor shone in this particular case since it complemented the classes instead of trying to stand-alone as an education tool. The teachers would act as the prompter, providing the content and structure of the lesson. The AI tutor would then act as a teaching assistant, helping students who were stuck in understand concepts and work through problems.

We also had a few discussions about whether we needed to explicitly state, "This is a chatbot". On the one hand, there are the ethical implications of AI impersonating real people, which is dishonest. On the other, when students knew they were speaking to an AI instead of an actual human, many would try to game the system to get it to do their homework for them.

This was mostly impossible with a sufficiently good prompt. However, the relationship between the tutor and the student would degrade. In a few cases, we would even see students "mistreat" (if you can call it that) the AI, calling it names and being mean and demanding.

I don't believe in AI's ability to feel (yet). However, it's the spirit of the thing that bothered me, and it obviously wasn't good from a learning standpoint.

That being said, the vast majority of students used the bot as intended, and we are confident in the learning outcomes and assistance it provides.

We're currently working with a non-profit in South Africa, trying to make the tutor bot generally available to as many underserved students as possible.

We're also in the process of exploring other ways AI tutoring can be used in education. If you're interested in having a conversation with us, check out our website.

2024-02-01T06:30:50.451733+00:00https://herman.bearblog.dev/how-i-learn/How I learn (making games for the Playdate)2024-01-17T07:27:54.996478+00:00hermanhidden

I (finally) received my Playdate, after about a year and a half of waiting. To be honest, I'd kinda forgotten that I'd ordered it and was pleasantly surprised when it showed up.

Playdate

For those who don't know, the Playdate is a niche handheld gaming console, similar to a Gameboy. It has a black and white screen, and an odd crank on the side. This crank isn't a dynamo for charging the device, or anything like that. Instead, it's a fairly novel input controller which can be used in a game mechanic to do things like reel in fish; crank open doors; and control the flow of time.

This seemed like the perfect gaming device for me. Not necessarily because I wanted to play games on it, but because I wanted to make games for it.

I've written previously about the power of constraints when building creative products. By having a narrow focus and sometimes arbitrary boundaries it can be easier to experiment and do something novel within this smaller possibility space. With traditional game engines the possibility space is huge. You can build anything from a Pac-Man clone, to a real-time, first-person MMORPG.

The Playdate, by comparison, has a much tighter set of constraints:

  • Everything is 1-bit (black and white, no shades of grey). This is pretty neat since I got to play around with 1-bit pixel art and learnt about dithering.
  • The screen is tiny at only 400x240 pixels.
  • The processor isn't powerful enough to do anything more complex than 2D or (very) simple 3D rendering, so it relegates all games to the 2D space (unless you really set your mind to it).
  • And there's the crank. This isn't technically a constraint, but it was for me. If there's a crank, you can be damn sure that I'm going to find a way to use it.

On to the learning!

I was completely unfamiliar with the Playdate SDK, and had never coded in Lua prior to this project. All the game engines I'd used before had visual scene interfaces and object hierarchies with attached scripts and attributes. The Playdate SDK, by comparison, has no interface at all, so I had to get down and dirty.

When learning a new language or framework I like to break it down into 2 steps:

  1. Figure out what is possible.
  2. Build a small project.

Too many novice programmers get stuck in the tutorial phase of learning. The issue here is that the guardrails never allow them to make mistakes. Mistakes are where the learning happens. Instead the tutorials lead them along the happy path the whole way, and in so doing generally teach them very little.

Here's an analogy: There's good evidence to suggest that using apps like Google Maps for turn-by-turn navigation can make it harder for someone to learn their way around their city. On the other hand, if instead they check the location of the destination and try to self-navigate they, naturally, become more familiar with that area. They need that friction. They need to actually think about what they're doing.

Tutorials are the turn-by-turn navigation of learning. It'll get you to the end of the tutorial, but there's a good chance you won't be able to navigate that language/framework/library once completed.

Figure out what is possible

So while I don't find tutorials useful for learning, what they can do is show me what is possible. I like to watch a handful of them prior to jumping into building just so when I'm confronted with a problem I know what to look for to solve it.

This is like looking at the map prior to heading off on my journey. I don't know the area, but I have a rough approximation of how to get where I'm going. This doesn't necessarily have to be a tutorial, I could theoretically read the documentation, but that's really dull.

After a short bit of scouting I found a great YouTube playlist by SquidGodDev that perfectly illustrated what is possible with the Playdate SDK, and watched about an hour of his videos before continuing.

Build a small project

During my time teaching, one pattern I noticed consistently was new programmers learning a new tool (let's say a game engine) would bite off way more than they could chew for their first project. Instead of creating a small game about trying to cross a busy road, they'd try to build a multiplayer FPS. This generally broke down pretty quickly since they'd get stuck on one complex problem early on, and after a bunch of spinning, give up entirely.

Instead, having a small scope with a pretty solid definition of "done" is an ideal way to learn. Taking a project from start to finish gives a good overview of the larger picture. In the case of the Playdate, it meant building a small game, publishing it for free, and getting actual people to play it.

I also time-capped it at 4 weeks. I had to have something playable and published before Christmas.

And so I created NIGHT RAID, a game set in World War II where you control an anti-aircraft gun (using the crank), as well as a set of spotlights to hold off waves of Axis bombers, zeppelins, tanks, and a few other enemy types.

NIGHT RAID

There are no levels, just an algorithmic increase in difficulty and a high-score system, which meant that I could focus on learning without spending too much time on level design.

And I did it! And it was super fun! Not only did I learn a great deal about Lua and the Playdate SDK, but also about 1-bit pixel art, animation systems, and optimising code for slow devices. I even tried my hand at sound effects but eventually just bought a big ol' library of sounds.

By taking the small project from concept to publishing also taught me about distribution methods of Playdate games, and introduced me to the community. There's a good subreddit and Discord group for Playdate developers, and it's a niche enough device that the players are actually friendly.

Conclusion

This method of learning isn't universally good, but I find it great for craft-specific learning. To apply it to carpentry would look something like:

  1. Watch a bunch of carpentry tutorials on YouTube (preferably involving only the tools you have access to).
  2. Choosing a small project to build, such as a side table, or jewellery box (as opposed to a vanity or large office desk).

And that's how I (usually) learn new skills.

This year I'm going to be working on a Playdate game I've had in the back of my mind for quite a while. Something something ninja something kitty. Stay tuned!

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2024-01-17T07:26:31.146173+00:00https://herman.bearblog.dev/the-two-kinds-of-writing/The two kinds of writing2024-01-10T07:44:55.976157+00:00hermanhidden

There are two kinds of writing. Writing for yourself, and writing for others. Both of these can, naturally, be broken down into various subcategories. For example:

Personal

  • Journaling
  • Note-taking
  • Poetry (although this can be public)

Public

  • Blogging
  • Academic papers
  • Letter writing
  • Book writing

I've written rather extensively on the idea of keeping a daily journal (personal). But while I have written a decent number of blog posts (public), I haven't really touched on why I write a blog.

There isn't one overarching reason as to why I write in public. However, there are a few things that happen when I write for others.

It's a way to formalise my thoughts

I'm sure you've heard the adage that "writing is thinking". This is an oversimplification, but still rings true. Writing is the process of structuring and expressing my thoughts. I find that writing helps me better understand the underlying material and forces me to query it in a critical manner.

The mere process of writing leads to better retention (hence why note-taking has been done for centuries), and so when I write about a topic, not only do I understand it better, but I can recall the nuances with greater fluency.

It's a way to connect with people

Quite a few years ago I deleted all my social media accounts. Since then I have focused on in-person relationships, and tried my best to break free from the doom scrolling of the modern internet. There is, however, something to be said about having a low-touch circle of acquaintances with common interests.

This has historically been expressed by letter writing, especially amongst academics, who would write to others in their field to explore ideas and exchange information.

To a certain extent, my blog functions in a similar way. I regularly receive emails from my readers who expand on, and challenge my understanding of the world.

It also allows people who are close to me to follow what I'm working on and thinking about, but in a less snipped-up manner than Twitter permits. I much prefer this kind of digital relationship to Twitter followers since the context of the communication contains nuance by default.

It's a way to share something I've learned with the world

Tangentially related to the last two points, when I learn something new, or stumble upon a novel idea and write about it, not only am I learning and internalising it by structuring my thoughts. I'm also creating new material on the topic, adding my own interpretation, and distributing it within my circles.

In a world where ChatGPT generated content is quickly becoming the norm, it's more valuable than ever to have an honest, human-crafted writeup on an interesting topic. In a way I think ChatGPT has made human writing even more precious.

It makes me a better writer and communicator

The only way to become a better writer is to write. My journal isn't the medium for this since no-one reads it but me. But when I write online I have to ensure that I am making sense, and that people are engaged. In-so-doing I become better at my craft (hopefully).

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2024-01-10T07:40:55.307432+00:00https://herman.bearblog.dev/on-goal-setting/On goal-setting2024-01-04T07:54:00.750803+00:00hermanhidden

2024 has arrived and with it aspirations to "do better". That isn't to say 2023 wasn't a good year. Not by any means. But the earth has reached the specific point in its trajectory around the sun where we define the year as "new" again, and so we arbitrarily decide that it's the time to do certain things.

I like that. There's a lot of hate for New Years Resolutions™. Why choose this time of year to make a change? Any time will technically do. But humans are like that. We like round numbers, symmetrical shapes, patterns, and the beginnings of things.

At the end of 2023 my brother, partner, and I sat down at a local coffee shop and had a mini-retrospective of how the past year went. It was both a bonding experience, sharing the wins and hardships of the year, but also an external perspective which helped me recognise aspects of the year that I had previously overlooked. It was refreshing.

We then got to speaking about goals and resolutions for the new year.

Here's how I like to set goals:

  1. Keep the main focus on 3 goals or fewer
  2. Define what hitting these goals looks like
  3. Specify how I will achieve each goal
  4. Revisit the list a handful of times throughout the year to make sure I'm still on track (or whether my destination has changed)

This is similar to the SMART goal-setting system, where instead of just trying to do things that feel aligned with my goals, I'm instead proactive about the what and the how. I also find that having only 3 goals is much more sustainable, since reinventing oneself is neigh impossible on January 1st.

Here's an example of one of my goals for the year:

Spend more time with friends and nurture existing relationships

What does this look like for me?

It means that in a given week I will have the "full" feeling that comes with spending quality time with people I love. It means doing neat activities together and creating memories that I will look back on fondly.

And how will I achieve this?

The first step is to make plans with friends during the week. This could be dinner, or just a walk in the park. Thursday evenings are generally free (the alternative is finding something good on Netflix, which is getting harder and harder). If I try to make time for an activity with one or a few friends every Thursday evening, I'll already be in the green with this goal.

The second step is to nurture existing communities. I am part of a group of other bootstrappy founders who meet about once a month for a good dinner and chat. I find these dinners to be both stimulating and motivational (although the last one left me a bit tender the next day). So, explicitly making time for this and taking initiative in the organisation if necessary are both happy-paths.

The third step is to plan larger activities like getaways, hikes, or festivals. I'm off to a good start so far just arriving back from a particularly good New Years music festival up the East coast with a great set of people.

And finally make more time for video calls with friends and family who are in other cities or countries. A big reason "nurture friendships" is a goal for me this year is that there has been an exodus of friends from Cape Town over the past few years (mostly to the UK) and I miss them.

And that's how I goal-set. It's not a perfect system, but I feel it works well for me and it feels right.

Have a spectacular 2024!

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2024-01-03T15:33:22.984253+00:00https://herman.bearblog.dev/how-bear-does-analytics-with-css/How Bear does analytics with CSS2023-11-09T11:23:29.760205+00:00hermanhidden

Bear Blog has a few design constraints for speed, efficiency, and stability. There are many great open-source, privacy-focussed analytics platforms out there, but I wanted to build one native to Bear.

tldr;

One of my constraints for Bear is to not use client-side javascript. This applies to the analytics system as well. Client-side javascript can be tweaked to determine the authenticity of traffic to a page and determine (partially) whether it is bot traffic or not, which is very useful for analytics. The main downside, however, is that most adblockers block analytics scripts. And not just the bad ones, like Google Analytics. Even Fathom and Plausible analytics struggle with logging activity on adblocked browsers.

There's always the option of just parsing server logs, which gives a rough indication of the kinds of traffic accessing the server. Unfortunately all server traffic is generally seen as equal. Technically bots "should" have a user-agent that identifies them as a bot, but few identify that since they're trying to scrape information as a "person" using a browser. In essence, just using server logs for analytics gives a skewed perspective to traffic since a lot of it are search-engine crawlers and scrapers (and now GPT-based parsers).

So instead of using server logs, I trigger a read with CSS. Here's my slightly boutique analytics system.

When a person accesses the website the page is loaded. On each page I have the following CSS:

body:hover {
 border-image: url("/hit/{{ post.id }}/?ref={{ request.META.HTTP\_REFERER }}");
}

The only info I need to actively re-add to this request is the referrer (yes, HTTP\_REFERER is spelt incorrectly).

Now, when a person hovers their cursor over the page (or scrolls on mobile) it triggers body:hover which calls the URL for the post hit. I don't think any bots hover and instead just use JS to interact with the page, so I can, with reasonable certainty, assume that this is a human reader.

I then confirm the user-agent isn't a bot (which isn't perfect, but still something). I also extract the browser and platform from the user-agent string.

My second constraint is to not store any identifying information about the reader either in browser cookies, or on the server. In order to do this I use the IP address of the request to determine the country, then hash the IP address along with the date. All subsequent requests to the page are checked for matching IP address + date hashes and duplicates are discarded.

In this way each IP address per day constitutes one "read" of the page. No IP addresses are stored un-hashed and the IP-with-date-hash creates a convenient built-in expiry time.

Here's the code if you're interested:

user\_agent = httpagentparser.detect(self.request.META.get('HTTP\_USER\_AGENT', None))
if user\_agent.get('bot', False):
 print('Bot traffic')
 return

ip_hash = hashlib.md5(f"{client_ip(self.request)}-{timezone.now().date()}".encode('utf-8')).hexdigest()

country = get_user_location(client_ip(self.request)).get('country_name', '') device = user_agent.get('platform', {}).get('name', '') browser = user_agent.get('browser', {}).get('name', '')

referrer = self.request.GET.get('ref', '') if referrer: referrer = urlparse(referrer) referrer = '{uri.scheme}://{uri.netloc}/'.format(uri=referrer)

Hit.objects.get_or_create( post_id=self.pk, ip_address=ip_hash, referrer=referrer, country=country, device=device, browser=browser)

edit: The IP address hash's only use is to prevent duplicate hits for a given day. This way all page views are unique by default. I then have a background task which runs at the end of each day to scrub the hashes from the hit logs, so as to not step on any over-zealous GDPR advocate's toes.

The only downside to this method is if there are multiple reads from the same IP address but on separate devices, it will still only be seen as one read. And I'm okay with that since it constitutes such a minor fragment of traffic. This provides an accurate count of reads and I feel is more concise and simpler than many other forms of analytics capture.

tldr;

I use CSS to trigger a url analytics endpoint on body:hover, determine useful information from the IP address and user-agent, then hash the IP address with the date to create a unique "read" of a page.

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2023-11-01T07:36:52.167544+00:00https://herman.bearblog.dev/teaching-tax-in-school/Teaching tax in school2023-10-18T13:15:43.061279+00:00hermanhidden

On becoming an adult, one thing has stuck out to me as a huge oversight in the high school system is that we never learnt about tax1.

I'm constantly shocked by the lack of tax literacy in the broader population. I'm not even talking about the logistics of filing tax returns, but on what taxes are, the different types of tax, and how they work.

I also regularly hear wide-spread simple misconceptions about tax, which illustrate a gross misunderstanding of the system. I recently heard someone say that they didn't want to get a raise since that would put them into a higher tax bracket, and they would therefore earn less take-home pay. That's...not how that works.

This is an oversight by the government, who sets the (public school) curriculum. We're taught many things in school that have marginal use later in life. I personally love poetry and finding subtle meaning in words, but it's not for everyone. It's not a prerequisite to operate in society. Whereas, everybody is required, by law, to pay taxes.

By not providing education around tax-literacy many people break the law without even knowing it. They are also much less likely to pay tax due to the daunting, complicated nature of a system they are unfamiliar with.

Misunderstanding tax also leads to mistrust in government. And a healthy amount of mistrust is necessary in a functioning democracy, but when the system is too opaque, problems become harder to address. Most people have a vague notion that tax is used to pay for things like roads and other infrastructure. However, I think if people fully understood the purpose of taxation and the way that money is regulated and spent, they would be slightly less bitter about it. Maybe.

I propose making financial literacy a mandatory subject for high school students, with a focus on understanding tax (and a few other things like real-world credit and debt). Teach them how to calculate income tax and capital gains. Show them how to be tax efficient without breaking the law, and about different tax jurisdictions. Hell, teach them how to register a company and the basic structure of a small organisation.

If we want a future where young people innovate and contribute to the overall well-being of a country, we need to get this right. Knowledge of taxation leads to compliance. And a well funded government (all other things being equal) is better than an underfunded one.

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
  1. I'm a South African tax resident, but this applies to many, if not most other countries. Especially the US, which has an even more convoluted tax system.

2023-10-18T11:14:54.196436+00:00https://herman.bearblog.dev/how-i-stay-motivated-as-a-solo-creator/How I stay motivated as a solo-creator2023-10-05T07:11:12.027125+00:00hermanhidden

Working solo has its difficulties. For one, my income is somewhat tied to my productivity, and my productivity highly correlates to my state of mind. This is combined with a lack of co-workers. Comrades in the trenches, if you will. And finally there's the ability to not do anything, which can be quite nebulous and dangerous if not managed.

One nice thing about being employed is when you wake up, you know what you're going to do. You're going to work. The choice has been made. The structure around that work, and the underlying purpose are set by others and you just need to make it happen. Yes, there is a big variety in occupations, but in general, an employee has to go to work, receive direction, and be productive.

When you're working solo, however, there isn't a specific thing you have to do. No pre-set route to take. If I decide to not do any work today, no-one will notice. But if I continue doing so for too many days things start falling apart. Slowly at first, then rapidly, until everything I've built comes toppling down around me.

Listed below are a few ways I try to stay motivated as a solo-creator:

I work on things that I find engaging

This is the most important point for me, and perhaps the hardest one to fulfil. When going down the early stages of product development the main question on my mind is "If this project works out, do I want to spend the next few years working on it?"

If the answer is yes, awesome. I keep at it. If no...well, it's probably not going to succeed anyway.

Smarter people than I have written at length about finding engaging work, so I won't delve into it too deeply. I can, however, recommend 80,000 Hours for those interested in the topic of finding meaningful and engaging work.

I build routine into my day

Since I don't have a boss to ensure I put in the hours, I have to choose to do the work. This is surprisingly difficult at times, especially when the less-interesting things need to be handled (tax returns/bug reports/refund requests).

And so my day has a fairly simple but dynamic structure:

  • Coffee and a walk with my partner
  • Gym for about an hour
  • Journal and write
  • Work block 1 (about 3 hours)
  • Lunch and chill
  • Work block 2 (also about 3 hours)

The exercise and writing sets me up for the day. It's my primer and gets me into the right frame of mind.

The first work block is where I try to tackle the most difficult problems or the tasks with the least inertia. I don't check my email until after lunch. This is important since I want to focus on the big tasks while I'm fresh, and email has a habit of stealing that freshness away.

After lunch, and if the momentum is good, I may continue working on my big tasks, but now I allow myself to check my email and open Slack to see if anything else needs my attention. This is my second work block, which handles the myriad of small tasks that come with running a company.

Do I manage to keep to this structure this every day? No. But I try and mostly succeed. It's a framework. Sometimes I'm just not feeling it and allow myself a day off to read or play Playstation. Without forcing myself to grind I never get too ground down.

I'm intentional with my down-time

I'm not on traditional social media so don't have that eating away at my attention, but Hacker News is pretty good at derailing my day. So is YouTube to a lesser extent. To preserve my focus I don't engage with any of these platforms until the end of the work day. It's way too easy to open Hacker News and then get nothing else done for the next few hours.

At around 4 my work day is generally complete and the rest of it is mine to enjoy. I try to not work past 5 since I want to spend time with people I love, get some fresh air, cook a good meal, and decompress so I have the energy and drive to jump in again tomorrow.

"You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again."

~Earnest Hemingway

This leaves me with something to pick up in the morning, and makes getting into the zone slightly easier.

I hang out with people in my field

Since I don't have any coworkers, I don't get to hang out and talk shop during the work day. To address this I stay active on a Slack community of devs and creators in my country, as well as go to meet-ups and events in interesting communities. I have lunch dates with other creators and founders where we can shoot-the-shit and talk product.

This keeps me social and sane, provides a sounding board for ideas, and is a nice way to have low-touch, semi-professional relationships. I have my close friends who I enjoy spending time with, but they don't share my problems, and having the catharsis of being "in the trenches" with others is something I appreciate.

I write about it

And finally, I write about my thoughts and experiences. Things I've worked on and what I would like to work on next. This post is an example of exactly that.

Through writing I better understand what I'm doing and how I'm doing it. It's a public self-retrospective, in a way. I sometimes receive feedback, opinions, and advice from strangers and friends alike. And, most importantly, I enjoy sharing my journey with the world.

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2023-10-05T07:11:12.023361+00:00https://herman.bearblog.dev/the-creative-agency-of-small-projects/The creative agency of small projects2023-09-28T07:48:03.541692+00:00hermanhidden

Since I moved out of the startup world I've exclusively worked on small projects. Niche, simple tools packed with love and attention to detail. I've written about my approach to building, and how it impacts my life and outlook.

Today, however, I want to write about a less-obvious benefit of building small: The agency to be more creative.

I used to frequent game-jams back in the day. At the beginning of a jam teams are presented with "the theme". This is a mechanic, or even a single word, around which your game is to be built. It's a seed from which to grow your own novel idea.

For example, one game-jam I attended back in 2018 had a single word theme: "waves". During this event I saw interesting interpretations and neat ideas ranging from a game about surfing (a pretty literal interpretation, for sure) to one about trying to figure out if a person on the other side of the street is waving at you, or someone behind you (where you lose points if you awkwardly wave back). There were a few that played with light and sound as well, which I thought was a cool "waves" interpretation.

Our game was called Wheelchair Wizards, where 1-4 players control wizards in wheelchairs (moving around by shooting fireballs). All the wizards spawn atop a tower and have to hold off waves (yeah, it's a pretty loose interpretation) of goblins crawling over the crenelations. We had a great time building it and managed to nab the "most fun" game award for that particular local jam.

Circling back to building non-game products, having something small creates space to play with new ideas. The first reason is that your "theme" is set and (hopefully) well defined. For example, it's difficult to pin down what the "theme" of Wordpress is. Whereas Bear's theme is simple "a super fast blogging platform that gets out of your way".

The second is that experimentation isn't expensive (both in terms of time and money) when you build small. A new feature only takes a day or three and many can be easily abandoned. Most ideas aren't good. Other times you strike gold and merge to master. Now that's satisfying.

Then there are self-imposed constraints. At some game jams you can choose to do these optional constraints to receive extra points. Think of them as "achievements". Here are a few examples:

  • Your game must be controllable with only one button.
  • You can only use a 2 bit colour pallet.
  • Local multiplayer.
  • All sound effects need to be voice recordings.

This adds delight to the building process. Many issues are simple to solve by breaking one of these constraints, but much less satisfying.

Here's how I used self-imposed constrains on Bear:

  • No client side Javascript.
  • Synchronous everything.
  • Pages need to be under 5kb.
  • It needs to run on any device (including my Kindle's browser).

And I've held pretty tightly to these constraints. Even Bear's analytics system is fully server side rendered using SVG graphs. Yes, there's technically a JS library for that, but then I'd be cheating.

Am I saying that this is the optimal way to build software? Certainly not. Is it the way I like to build software?

Absolutely.

Finding joy in what you're working on is the difference between a product that feels loved, and a sterile tool. It's the difference between a hand-made teapot with the oceanic glazing, and the white one you get from Ikea.

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.
2023-09-28T07:44:24.319755+00:00