Learning Fabric in public

Running StoneHavenSMP gives me plenty of reasons to ask, “Could this work a little better?”

Sometimes the answer is a configuration change. Sometimes it is finding an existing mod and figuring out how it fits into the server. Other times, the behavior I want does not quite exist, or a tool I enjoy using has not kept up with the version I need.

Those gaps are what pulled me toward Java mod development.

I am learning as I go. Moving from configuring someone else’s software to building my own means getting comfortable with unfamiliar code, tools, and mistakes. Having an actual server problem to work on gives that learning a purpose.

Start with something you care about

An open-ended goal like “learn Java” is difficult to turn into an evening’s work. A specific goal gives me somewhere to start and a way to recognize progress.

Dynamic Join Greetings came from wanting player arrivals to feel more personal. Trowel Continued came from wanting to keep using a building tool that was stuck on an older Minecraft version. Steward grew out of wanting staff tools to feel more organized and accessible.

Each project gives me a question I can work toward answering:

Can a player joining receive a greeting that makes sense for them? Can this building tool work in the version our server uses? Can a moderator complete a common task through a clear interface?

I still have to learn the underlying concepts, but now I have somewhere to apply them. Reading unfamiliar code becomes easier to stick with when I understand what I am trying to accomplish.

Configuration experience gives me a starting point

Server administration has taught me to pay attention to how software behaves in practice.

I think about what happens after a restart, what a setting means to the person editing it, and how a change might affect players who were comfortable with the old behavior. Those questions carry over into development.

The difference is that I am now responsible for more of the answers.

When configuring a mod, I work within the options its developer provided. When writing one, I have to decide what those options should be, what the defaults mean, and how the code should handle unexpected input.

That has given me a better appreciation for the work behind tools that feel straightforward to use. A simple experience often requires a lot of decisions underneath it.

Build one complete behavior

One approach I am learning to prefer is building a small feature all the way through before expanding it.

For a greeting system, that might mean getting one message to appear when a player joins. For a block, it might mean getting it to place, save its state, and appear correctly after loading the world again.

That gives me something concrete to check. I can follow the behavior from beginning to end and see where my understanding is incomplete.

It also makes progress easier to recognize. A small working feature gives the next session a dependable starting point. Several unfinished experiments can leave me spending most of that session remembering what I was trying to do.

There is room for experimentation, but I want each project to keep returning to something usable.

Follow the behavior beyond the happy path

Getting a feature to work once is encouraging. The next questions are usually where the deeper learning starts.

What happens after a restart? What happens when a setting is missing? What does a player see if they do not have permission? Does the feature still behave sensibly when someone uses it differently than I expected?

Running a community server makes those questions feel practical. Eventually, someone else has to live with the decisions I make in the code.

I want to build the habit of checking those situations while a feature is still small. It is easier to understand a problem when I have changed one behavior and can explain what I expected it to do.

Make room for the rough parts

Learning development includes sessions where the visible result is very small.

Sometimes the useful outcome is understanding an error message. Sometimes it is discovering that an assumption was wrong, or removing an approach that made the feature harder to reason about.

That work can be frustrating, especially when I started the evening hoping to finish something players would notice.

Writing down what happened helps. A short note about the problem, the cause, and what finally worked gives me something to return to. It also helps me distinguish between understanding a fix and merely getting past an error.

I want these devlogs to preserve some of that process. The rough edges are useful context for anyone else making the move from server administration into development.

Learning where people can see it

Sharing unfinished work means being clear about its state.

An idea, a working experiment, and something ready for other people to use are different stages. I want my project pages and devlogs to communicate those stages honestly, including what still needs testing or further work.

Publishing the process also gives other people a chance to ask questions or notice something I have overlooked. Explaining a decision in plain language often helps me understand it better myself.

I do not need every entry to announce a major release. Sometimes there is value in describing one problem clearly and showing how my approach changed.

StoneHaven gives me a place to find meaningful problems. Mod development gives me a way to work on them while building skills I want to keep developing.

For now, my focus is on taking one manageable feature at a time, understanding the code behind it, and leaving enough notes that the next step feels a little less unfamiliar.

— SwornHero
Owner of StoneHavenSMP