I still play Quake 1 and 2 online, randomly pop into Tribes 2, Counter Strike 1.5....usually the community is clicky and toxic to outsiders but sometimes you bump into really neat people.
Is this game online/multiplayer only? I mean, people still play Galaga and PacMan and other older classic games so why would you think someone wouldn't still play this one too?
It is not online only as we would now understand. But it is certainly only multiplayer game. Well you can play against bots, but even then it is multiplayer.
It's worth noting if the board is full this doesn't happen. This was helpful in my strategy because I could set up several pathways like I was playing checkers without fear of losing anything.
This game was way too good. I stuck with it until I beat it and loved everything - the music, the idea, and the moves felt so satisfying - especially the final one.
The first time I played I thought king would take my pieces with some probability if they weren't guarded. I spent way, way more effort than was necessary playing with higher stakes.
I'm not the GP you asked, but distilling my own personal organization practices into the alluring "Ten Tiny Tasks" title, here's my take on it:
- Make a list of the 10 tiniest tasks with the least amount of estimated effort you can find or think of that need to be done
- Maybe save task 10 for a super quick prioritizing of the other 9 tasks, or don't because they are tiny tasks, after all
- Complete the 10 tiniest tasks
- Repeat the process until there are no more tasks (of course, there are always more tasks)
And like, tiny. Open terminal to project directory. Opeb browser window/tab to SDK/API index. Shit so easy that you can't help but do them. Repeat until you get to tasks that aren't quite so trivial, and by then, you'll be going.
IME as you approach the limit you can create an infinite number of tasks. The key for me is to pick tasks which balance expedience and bang for buck value, but if you are experiencing intense writers block then I see no problem with a task like "open editor."
Yea. It's like falling down the recursion with a stack size of 5. Do the task. Plan doing the task. Start planning doing the task. Plan starting planning doing the task...
Recursion isn't necessarily the problem per se - it's the sheer number of tasks. When you're at the level of "open terminal to project directory", it takes less time to do it than to write it down, but more importantly, you'll end up creating a 100 of those tiny tasks, and the overhead of keeping them up to date can easily suck all your motivation (and time) dry.
Yes, I have a series of nested systems/methods that are designed to build and maintain momentum. The Ten Tiny Tasks are for overcoming inertia and eliminating the small barriers that keep you from starting. I do the tasks before I have my coffee in the morning.
Everyone else presuming you need a list to keep track of them is missing the point - spontaneous and immediate action with minimal commitment.
Yes, I made a game that you controlled by whistling, back in 2018 with the WebAudio API.
My version of the cursor kept a continuous scan velocity horizontally across the screen, and you controlled the y-axis via pitch. Button presses were (intentional) collisions.
This is something I'm trying really hard to do with a client. They have a bunch of 1500+ line "config" files for products, which are then used to make technical drawings and production files. The configs attempt to use naming scheme to group related variables together.
I want to migrate to an actual nested data-structure using (maybe) JSON - and these engineers absolutely will not write code, so config-as-code is a no-go, in addition to the disadvantage you mentioned.
My next thought was that there should be a better way to show the configuration, and allow that configuration to be modified. I was thinking maybe some sort of visual UI which where the user can navigate a representation of the final product, select a part and modify a parameter that way.
Is that along the lines of your suggestion? If not will you please expand a little? Configuration is the absolute core of this application.
Sounds like you need an SQL database. You could use SQLite.
Then provide a GUI to modify that database. You could add a bunch of constraints in the database too to ensure the config is correct.
Usually when there is plain-text files though, it's because they want it that way. It's easier to edit a text file sometimes than rows in a database. Cut/copy/paste/duplicate files and text. Simple textual version control.
Sure, I agree - I'm proposing JSON as an intermediate step toward a well-defined data-model since the thousands of copied config files have evolved over time, so the data-model is a smear of backward-compatibility hacks.
What I was trying to do is get you to explain what you mean by this:
> If our code ran in real-time to show us a representation of the final configuration, and we could trace how each final configuration value was generated, then it wouldn't be a problem. [...] But no systems are designed with this capability, even though it is quite trivial to do. Configuration is always an after-thought.
This is only relevant if you allow code to define config.
If you use conditionals and loops to create config, and then view the final json, it quickly becomes annoying when you know the thing you want to change in the final json, but have to trace backwards through the code to figure out where to change it.
So programmatic configs only work if you have this "value tracing" capability. Which nothing really does.
Who said you had to create schedules as a part of accumulating information? If by schedule, you mean that a you've created a long list of topics that you haven't learned and feel you should, then of course that will feel intimidating.
But playing a game and learning about a game are two separate activities. The key is to spend your time actually playing the game. Playing the game consistently will feed the drive to learn more about it, and if both of those things feel like a chore, then why are you doing it in the first place?
Magic is just one example, but to be more specific with another hobby, I'll use music as an example.
The problem I have with music, is that I can't get it to sound like the other music that I like. And no amount of just "making music" will get me to sound like that.
Instead, what you need to do is actually study other people's music, through analysis, studying genre, watch tutorials etc. And this has helped me significantly. The reason I say that this is because I've had so many epiphanies about how I've been doing it completely "wrong" in regards to what I thought I should have been doing vs what I actually should have been doing.
In addition, if I just focus on making music I get demotivated cause it just doesn't sound like how I want it to.
The problem is that it's really hard to balance between making music and studying music. When you're studying music, it's like that becomes your focus and it consumes you. Which also demotivates you from making music.
But yeah, obviously I'm aware of what the issues are, but I'm not quite sure how to approach it all in a sustainable way.
When you are learning a skill, you have what I call structure learning, free-play, feedback and deliberate practice.
The structure of the skill is the curriculum, so to speak - but the skill itself is an action. When someone is learning music theory, they are really just learning what the structure of the skill is. If they knew the series of actions they needed to take, the goals they needed to set for themselves in practice, and the relationship between those competencies - then they would have no need of theory. The theory informs us of what the structure is.
In most skills and hobbies, you don't need much theory. This is because people have created drills and identified the fundamentals over time. Everything has been organized for you.
That's the structure. Here's the interesting thing - you don't need much structure at all. If the structure is a tree or graph representing the fundamentals you need to master, all you need to know is the next node - the next skill you will focus on.
That's where practice comes in. Practice should be your primary focus, not your secondary focus. Some fraction of that should be "free-play", or curiosity driven exploration & synthesis. You add that in because it's critical for learning, and because it keeps things feeling fresh - but the real value-add is to learn to enjoy the practice. If you "play" at practicing, then you're golden.
Practice though, must be deliberate. You don't just "make music". You have identified something you want to work on, and you attempt it through repetition. You compare your effort to the end-result (using feedback), and you repeat. This loop never ends. If you feel you've mastered something, you move on to the next thing. If you don't know what the next thing is, then you turn to theory in order to identify it.
That's all the balance you need. Learning about a thing is not doing the thing. Do the thing. Identify what you want to work on, draw a little progress meter on piece of paper, and start doing it. Do it for 20 hours, filling up the meter. At the end of 20 hours, you have a choice: draw another meter for another task, or stop doing the thing.
The problem you face is thinking that motivation is your problem. Your problem is that you are not doing the thing. How you feel when you are not doing the thing is irrelevant. How you feel after you've done the thing - and you notice that it's not what you wanted to it be - is irrelevant. You will never be at the goal, that's the whole point of practice.
I agree with what you say and I've definitely considered and thought about what you've said in the past, but it never quite works like that in practice. But that's also to say that I'm being unreasonable.
In the case of music for example, I had the realisation that part of the reason why I struggled is because I simply had no idea what I was listening to. This lead me to spend around 4 months familiarising myself with every single EDM genre and the kinds of sounds they use, and although I now find this knowledge invaluable, I'm not sure how I would have done this whilst also maintaining practice. In my mind, it was a necessary evil that I just had to knock out of the way, to the detriment of actual practice.
I guess my issue is my all or nothing attitude, which I really struggle to avoid and somehow even if I do start balanced and focused on practice, it somehow ends up becoming "all in" on a single way of learning.
But a question if you're available:
- How do you maintain that interest/curiosity without going "all in"? You say the feeling is irrelevant, but what is the drive? How do you maintain consistent curiosity?
I often think that the mania is a coping mechanism for a lack of curiosity/interest, and perhaps as well to mask the anxiety/boredom that art can bring.
1. How do I maintain interest/curiosity? I do not. I lose momentum and interest. I get depressed. So I pull out a blank sheet of paper and draw a progress meter. I commit to 20 hours of practice - dedicated either to a new skill or to generally overcoming my stagnation. I have done this dozens of times, and it has never failed, I always regain my passion.
2. How do I avoid going all in? Going all in is my default. I treat the 20 hour mark not only as a goal, but as a stopping point. I must make the conscious decision to draw another meter in order to continue, after considering how my time is being spent - otherwise I can become obsessed and lose balance in my life.
Note that your phrasing is self-defeating. You are telling yourself a story which appears maladaptive. Just listen to yourself: 4 months of valuable experience was an "evil" that you had to "knock out" to the "detriment" of "actual" practice.
You identified a weakness: You knew that you needed to develop your ear, and make sense of the territory. You might have collected a hundred brief sound clips and challenged yourself to identify the sub-genre. You might have randomly selected a genre and challenged yourself to produce a very brief (even minimal) piece that expresses its essence. You might have taken a short composition and, for any given genre, challenged yourself to reinterpret your own song in that style.
Here's an idea. Take 5 different genres, and challenge yourself to making a short piece that gradually and naturally transitions between them. Optionally ignore all other constraints, like global structure, general appeal, consistent aesthetics, etc.
You did 4 months of practice which was in all likelihood less than ideal, somewhat inefficient. So what? That's a positive, not a negative. Next time, try to incorporate "doing the thing" into your regimen and you won't feel like you've lost momentum.
Interesting, do you have any examples/literature on this idea of a progress meter? I think I might try that. Especially the whole 20 hour idea, I think will be really useful for me.
Here's an old album of the style meter I use [1]. I recommend a soothing blue & green for hobbies, I use red for client work. 20 Hours is the allocation for all skill learning. The tokens are part of a much larger whole as I've unified fun, skills, work, mental health and financial planning into a single system. I have programs that do most of it, but keeping it as a marker/paper UI is critical if you struggle with mental health or motivation, so that you can easily bootstrap yourself.
I extended the 20 hour practice idea from Josh Kaufman [2]
I highly recommend Sam Harris (Waking Up), Alan Watts, Laozi for mindfulness / meditation, as well as Iain McGilchrist (The Master & His Emissary), Mihály Csíkszentmihályi (Flow) and David Foster Wallace (Infinite Jest) for metaphorical inspiration. Learning to play at life in any moment helps to eliminate tedium & boredom from your vocabulary.
Aviation in particular has a very strong culture around (government mandated) checklists and post-crash investigations. This has both pros and cons. The pros is that every airline learns from the mistakes made by every other airline and over time the system becomes really quite safe indeed. The cons are that it is quite expensive and time consuming.
Imagine if every software company was obliged by law to:
- Every single release has to have been signed off by someone who got their "software release engineer" certification at the software equivalent of the FAA.
- This engineer is required by law to not sign off unless every box on a 534 item checklist has been manually verified.
- Any time an unplanned downtime happens at any company, a government team comes in to investigate the root cause and add points nr 535 through 567 to the checklist to make sure it never happens again.
If such a system was mandated for software companies, most of the common bugs would very rapidly become a thing of the past. Development velocity would also fall through the floor though, and most startups would probably die overnight. Only companies that could support the overhead of such a heavyweight process would be viable, and the barrier to entry would massively increase.
I wish someone would create that 500 line checklist. I've seem attempts, but they tend to be either not actionable (is the software high quality - meaningless), or of metrics that are just gamed (is test code coverage > 80%?)
If I understand his theory correctly, in your case there would be a competing metric to the "test coverage" one that said for any changeset, a test cannot itself change by more than 20% in the same changeset as non-test code. So you can change the code such that it still passes the existing tests, or you can change the test to adapt to new requirements, but you cannot rewrite the tests to match your newly changed code
I'm acutely aware this is a terrible example, the devil's in the details, and (in my experience) each company's metrics are designed to drive down their own organizational risk <https://en.wikipedia.org/wiki/Conway%27s_law>, combined with "you're always fighting the last war" :-D
> > Aviation in particular has a very strong culture around (government mandated) checklists and post-crash investigations
That's the reason why aviation can only shine when it becomes a private means of transportation, and I don't mean 70mm private jets but, 150k light helicopters.
When a critical mass is hit then accidents will become no more traumatic to the collective psyche than car accidents, the lighter the aircraft the better because it would seem exactly like a car crash as opposed to leaving a huge burning hole into the ground
I was going to mention how much I loved that game, until I realized I played UT99. Time sure does fly...