I Am So Happy For You! Congratulations! I Hope It Will Be An Awesome Place To Work!!!

I am so happy for you! Congratulations! I hope it will be an awesome place to work!!!

Here is a good tip for whenever you join a new company, no matter which number of job it is for you

Write down things you wished to had when you started. List of Libraries to download, instructions, tutorials in how to do things, set up ID. Virtual machines...Whatever.

And then offer to your supervisor after some months that you spend a few work-hours making those ressources.

From then on, make it a task of every new hire to update this packet.

That way it comes easier and easier to be a newly hired person at this company.

This trick takes advantage of the fact that YOU are right now the best and most experienced in the company at "Being the newly hired person", and so are by far the most competent to do this.

First day at new job!

Monday 8th January 2024

OMG today was the best! The new job’s office (not in the picture background, I'm at the doctor's there...) has so many cool chill people in it, so far I wanna stay here forever!

Had induction meetings, and a tour around the office, everything was so cool! Another 2 people joined so I wasn’t entirely nervous thinking I’m the only one who would be confused on the whole onboarding process. Work’s in an old-like building with a Grunge aesthetic vibe going on, absolutely love it! And music plays in the background which is so much better than the old job which was in complete silence 🤐

I'm just super excited to start working on the project + the team seem, and are, super friendly and helpful! Thank God for a smooth process getting here, yay!

New Years Resolutions #3: Work hard and do well in new job!

And code coverage is not at 100% ( Making it useless) and the company says there is no time for making automated tests because we are too busy fixing all the constant bugs

Guild Structure

Wanted to write a long reply to this post:

Spreading experience around is always awesome! :D

It is good for the firm you are working at as workers perform better.

it is good for whoever is getting taught since they get smarter.

And it is good for the one teaching, both for the pleasure but also because you learn a LOT by being forced to explain what you know to someone else. It crystalizes the knowledge and experience you have acquired, and forces you to go through the basics again, but this time with all your knowledge and experience, you often learn deeper, more complex truths, methods and skills from doing so than it is POSSIBLE to do when you learn them while having little clue what they are ( Function pointers and their safer class versions is a classic for OOP programmers ).

There is a structure a firm can use as soon as it starts having separated departments. Departments, while necessary, makes a firm more segregated, and makes it harder for knowledge to flow around.

It is called Guild Structure Or rather... some important context if you google this: "Guild Structure" is the only way I have heard of it, but "Guild Structure" is also a product from a firm called FourWeekMBA... which is a consulting firm that sells services that firms that is... basically helping them implement these ideas... So you can easily risk finding overcomplicated explanations for what it is, since if they made it easy to understand... then they do not have a product...

And it is super simple. Normal development work for engineers and software is done in smaller teams... usually 4-8 people. sometimes all are in a domain (like software, electronics, finance, marketing, etc), and sometimes mixed. Often... either being mixed, or having several teams with different domains meet relatively often, like several times a month is a good idea. Because it stops misunderstandings from developing, since they are caught early. It is a waste when the software department develops functionality that it turns out no one actually wanted (Which happens... a lot more than anyone likes)

Firms, managers and workers are often afraid to do this. Usually for 2 reasons. One bad, and one that Guild structure fixes. The bad one is not wanting to risk looking stupid in front of other people. When software, marketing and finance people talk about what to develop... each domain is asking questions in a domain they are not experts in. That is the symptom and consequences of toxic firm culture. Talk about it in the open, communication is how you slowly work on and attack this, both in firms and personal relationships. Because they are both about making humans work better together.

The other is a fair enough one. Software people will learn a lot of software tricks that are only helpful to other software people. And if software people are spread around in these teams the knowledge cannot flow very well. Basically, while mixing domains fixed a whole bunch of knowledge flowing issues... it created a new one for domain specific knowledge...

This is where you make guilds. Make public guilds. There are clear lists of the guilds, explanations of their domains and several example for each guild for what kind of domain they are covering.

In some firms, a software guild is enough. In others, embedded software, high level software, front end and back end are different guilds. It depends a lot on the firm.

The guilds have communication between all members ( chatrooms usually ) and meetings every month. They will try to encourage knowledge sharing by giving tools, like shared drives where good guides, tutorials and tricks are shared. Sometimes written by guild members, sometimes found online (If you just had the though "Wait... is that not what Codeblr does?" you have just realized that Codeblr is a naturally formed guild), having people who have good ideas they want to spread give presentations during the monthly meeting, rewarding the best idea of the month. People can participate as individuals, or small groups (Tricks are often found by 2-3 people working together).

Meetings can be physical, or remote, or switch between them, doing both.

This basically solves the issue of knowledge sharing. It also empowers workers while making the firm better. Everyone wins!

I... I feel like I am getting diabetes by reading this post!

It is SO sweet and positive and wonderful and just... "chef's kiss"

✧･ﾟ: Customize your highlight color! :･ﾟ✧

I recently came across a blog where when I went to highlight some text I noticed it was a unique color!!! (」°ロ°)」

AND IT'S SO SIMPLE TO DO

all you do is go to your css file and add this:

::selection { background: <hexcolor> }

Enjoy!! ♡⸜(˶˃ ᵕ ˂˶)⸝♡

You made me wake my dog up from laughter! :D

programmers will complain about how C++ is too complicated or arcane or whatever and then will literally go and write in JavaScript

When to add delta in GoDot?

So I am slowly eating my way though the tutorial for GoDot. I already have some experience with moving things in space and calculating inputs for individual objects.... That is essentially half of robotics software. So in every frame, a function called _process is called. this function takes a number called "delta", which is the amount of time passed since last frame ins seconds (Usually close to 1/30 or 1/60). You add delta to the calculation of certain variables. The first example usually found is position, which is done like so:

position += velocity * delta

To me that was all good and obvious. But I found a lot of posts of people being confused when to multiply delta and when not to. And apparently doing it in wrong places is a quite common bug in GoDot games. Here is to figure it out! Think in term of units

Velocity is distance/time Position is distance

So you cannot add velocity to position. They are 2 different units. How to fix this? Remove the time component.

Since time is distance is divided by time, we simply multiply time onto it. You know what have the unit of time?

delta is time

Meaning it is obvious why you need delta in the line! :D position += velocity * delta

Because distance += distance / time * time