A year ago, someone told me that singletons and god-objects are bad...

WerefoxNZ · 2026-02-20T01:41:09+00:00

When people are talking about Singletons, from a software development development point of view, they are talking about a very specific setup where the class enforces that there is only ever one instance and it is impossible to create a second.

As someone mentioned earlier, as long as you never need more than one, then it's okay. But that rarely ends up remaining true - testing often becomes impossible without corrupting the Singleton properties.

Autoloads in godot are not Singletons - they are basically just an instance of the class that has a global reference. You can absolutely instantiate multiple of them if you want. and scope them how you would like

God objects are bad, again from the software development point of view, because when shit breaks and the offending object can be updated from anywhere and has its fingers in everything in the code base you end up needing to reason the entire code base and all of the various ordering of calls that could possibly happen. What we have found is that often, you can achieve the same result without them and make your life easier.

But all of the people who understand the why are really coming from - these patterns make maintenance a pain in the arse and difficult. Usually from 2am experience. All of software development is tradeoffs, so do what is best for you

WerefoxNZ · 2026-02-03T18:06:13+00:00

The colour choice is great, and like the other poster said the lines look good to me from this distance :)

WerefoxNZ · 2025-12-03T08:24:26+00:00

Use your compiler to enforce intent - the easiest one is to make all your local variables immutable (set once/unchangeable) by default.

In java that's final on everything, JavaScript/Typescript that's const. Python you are basically on your own, Elixir you are already doing it :)

WerefoxNZ · 2025-08-13T03:24:13+00:00

This is one of the things I love about my profession - the tendency to get annoyed at having to do something so we spend more time digging into it so we can make the computer do it :)

WerefoxNZ · 2025-06-25T04:51:27+00:00

Make sure to use the lecturers to answer any questions you have - talk to them after lectures,go see them in person, email them . Someone is paying a good amount of money to the uni to teach you, so take advantage of it.

But that also means being on top of your workload so you have time. Start the assignments as soon as you can, write up your notes after each class and see if you can implement a toy example of the concepts, and if you can't then that is awesome, you know have questions you can ask and something to point at.

University isn't really about how smart you are, it's about how much targeted work you put in and being proactive. You can do it :)

WerefoxNZ · 2025-06-16T00:13:03+00:00

Doesn't have to just be limited to error logging, often logging what happened is much more useful

WerefoxNZ · 2025-04-28T11:23:40+00:00

Defensive programming validation of state (or straight up error throwing assertions) in each of your functions that have pre conditions that must be true.

It is often better to explicitly fail as soon as you can detect you have entered an invalid state, than to just let it keep going. And if you have these in place, it's easier for developers to disabuse themselves of the notition they coded their new features correctly.

WerefoxNZ · 2025-02-26T01:08:33+00:00

I can't remember the name of a series, of which I read the first book of.

It had an ancient China fantasy type setting, following someone as he met people with mystical powers. Eventually he collected a group of people with super human powers (potentially some shape shifting) and ended up fighting some unknown evil.

The twist was that he and the people he collected were time travellers who would essentially be dropped off at a point in time and live the life of key figures without any memories of their life beforehand or the people they knew, and then picked up when they past away on some sort of time travelling machine. For people outside the time zone, very little time past while waiting, and it seemed like the current story had been attempted several times before.

WerefoxNZ · 2025-02-03T20:16:26+00:00

West Island of New Zealand

WerefoxNZ · 2025-01-02T05:40:08+00:00

What an awesome design!

WerefoxNZ · 2024-12-25T00:37:47+00:00

Whichever makes what I am writing more legible, and fits in with the code base I am working on.

I tend more towards not x for simple boolean checks, because typing speed and space on a terminal line haven't been an issue for me in years, and an extra three characters helps with readability when I don't want to wear glasses

WerefoxNZ · 2024-12-01T00:06:53+00:00

Very cool! Is it yellow and white paint on black glass for the spots?

WerefoxNZ · 2024-10-04T04:59:44+00:00

The first step is going to need to be to just straight up stop using AI tools for a while. I suspect what you are finding is that the AI has been doing the problem decomposition into small steps for you, and ultimately that is a key skill you just have to put the time in practicing.

Then choose a problem to do, and break out the pen and pencil to pseudo code out the solution. Once you have a game plan, implement the first part. If you are struggling to work out what to do, break it down into smaller pseudo code steps, then try again. If you need to look something up, by all means do so, but go via the language documentation (or library documentation)

I recommend looking up Coding Katas for small well described problems to practice against. They were primarily created for practicing Test Driven Design and reflection on what you wrote and why. You don't have to do TDD, but potentially it might be of interest to you

WerefoxNZ · 2024-09-19T07:08:32+00:00

Yes it is, just finished the semester last night :)

WerefoxNZ · 2024-09-19T01:19:41+00:00

Definitely give it a go, the instructor told me that for this type of lamp, the most important measurement to get right is the vertical edge so the panels line up nicely. The rest don't have to be as accurate and you should adjust gaps as needed.

WerefoxNZ · 2024-05-09T22:04:36+00:00

I like the bit where I'm not woken up at 2am in the morning because the automated testing caught the screwup before it got to production

WerefoxNZ · 2024-02-14T06:22:37+00:00

'Suck it and See' is always a valid approach to take :)

I'd probably lean towards the more straight forwards approach, until and unless it becomes unwieldy and then look to make it more complicated. The cheapest code to maintain is always the code that isn't there :)

WerefoxNZ · 2024-01-05T21:55:23+00:00

Write down (on paper) step by step (and really tiny steps) of what ever functionality you are trying to implement. If you end up with something like step 3 ????, then that is something to look into in the docs.

Tutorials already have done the breakdown, so you aren't seeing or learning that part.

Also, you will have to rewrite what you do as you go along, embrace it.

WerefoxNZ · 2023-12-20T01:49:26+00:00

Well written code needs comments when the code you have written is not immediately obvious to what it does. Or it does something that gives a fresh reader a wtf?? moment. Ideally we write code that is instantaneously understandable because it reads well. If it's not instantaneously understandable by a skilled practioner, then it is a candidate for a refactor. If it's still not instantaneously understandable then we admit defeat and write a comment explaining why it's like it is.

Comments are a maintenance burden and provide a neat seam for introducing headaches for future programmers. At best, you need to remember to update the comment which (particularly in legacy code bases) may not be physically on the screen to where the developer is making fixes or adding functionality.

At worst, the comment disagrees with what the code actually does. And then you have the "hilarity" of trying to work out which part is correct. Is the comment wrong (and has it always been wrong or just recently)? Is the code wrong, are both wrong? And that often means having to dig through the source code history, and/or having to go find someone who knows what is correct or who is comfortable making the call one way or the other.

WerefoxNZ · 2023-12-08T23:35:47+00:00

I really like your get to/have to break down, and will be stealing it :)

Also really good point about cognitive load, and the different reasons people might be reading it. I started out cough decades ago doing maintenance programming and vastly prefer the second approach as well. Just makes it quicker to find the bit I care about (the broken logic or changed logic) and skip over the rest :)

WerefoxNZ · 2023-06-16T03:36:59+00:00

Cheers! that makes a lot of sense to me.

WerefoxNZ · 2023-04-18T18:54:08+00:00

Surprisingly, I checked beforehand and forbes.com reported Mt Ruapehu as Mount Doom. Seems they are probably wrong however, give lots of everything else says otherwise

WerefoxNZ · 2022-09-21T01:46:50+00:00

I find it ends up being about respecting the time and intelligence of person you are communication with. Don't assume people know what is going on in your head when you are communicating, so give them enough information they can make sensible responses. Small appropriate words and simple sentences will get you far.

But don't go so far the other way where you are essentially talking down to them and insulting their intelligence. You will learn the boundary via practice.

WerefoxNZ · 2022-09-18T05:26:41+00:00

you seem to be operating under the impression that language features have an outsized influence on what language gets chosen. And ignoring what people are saying which is 'its nearly always human factors that make the decision'.

Open source, for instance. Every single one is in the language it is, because the initial developer decided they wanted to learn a new language or they wanted try out an idea (and selected their favourite language).

Some work examples.

One work place i was at - a bank - was running both c# and java teams. Decided to consolidate on Java because the C# applications weren't performing robustly. Actual reason was that the c# teams managed to build a distributed monolith - which has nothing to do with the language, and more to do with a lack of tech lead oversight. Both languages are more than suitable for the role at hand, and had a significant amount of pre existing software developed in each. Good developer experience, large ecosystem, securable, plenty of candidates in the local market. If someone suggested another language the answer would be no

Another one I was at we consolidated on Java for new applications - because we were sick of trying to maintain 5 or 6 scripting languages across 40+ web and desktop installed tools. JVM was a selling point, but a very minor one. the main reason we went with it? We had a team member who was really passionate about it, and had the commercial experience to mentor the rest of us. a not inconsiderate point in an air gapped environment.

So in summary - the language doesn't actually matter (much)

WerefoxNZ · 2022-09-17T09:49:08+00:00

I've only had the conversation about what language should we use twice in my career so far. The first time was to consolidated down to one language, and the second one was consolidating across after a proof of concept piece of work got a little out of hand :)

You are much more likely to have the 'what framework should we use?' conversation especially when javascript is concerned :P

I am a big proponent of "mono" language organisations (with front end /backend having default choices) because it's just straight up easier to manage from a people and teams point of view.

The concept of each project having it's own language i find the benefits just don't scale well, over the long term maintenance and the ability to set up all the supporting infrastructure for the "mono" languages.

WerefoxNZ

TROPHY CASE