Guild Structure

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!

My husband loves me a lot... despite the task I make that :p

Me, in a jolly mood, once again forgetting to do volume control: "GOOD MORNING HUNEY!" Husband ( In the most loving but tired voice ): " Stop screaming in my ear... you... colossal... moron."

Like... You know how sometimes when you hear people speak you can HEAR the punctuation mark at the end of that sentence. It was NOT a exclamation mark or no punctuation whatsoever.

It was not "moron!" or "moron" It was "moron."

Oh absolutely. I have written every single report and paper that non-programmers ( Users, pruduct owner, whatever ) in LaTeX.

It is Word. But you can do ANYTHING you want, work in the same updated file if you use overleaf ( Like google docs.... But you know... good... ).

And if you just want to write a basic report with a few diagrams. LaTeX just makes it nice and easy and looks good, dry and professional.

But markdown... Oh markdown is for documentation. And it is perfect.

It is super super easy to use. The "Cost" of this, is that you only have few features...

And that is KEY. Combined with you being able to put pictures in what is otherwise basically cleartext, means that you MUST be able to clearly explain whatever it is you are documenting with nearly no fancy text, colors, weird structureing with the words or whatever.

No. You MUST do it in text... Or use a diagram.

It forces you to use DIAGRAMS in your documentation. Glorious easy-to-read better than a thousand words diagrams.

It removes the horrible middle-ground and lets you focus on making documentation super super fast, with text and diagrams.

Fun fact. Markdown... is a markup language

If you do not know what markup is... you should look it up. It is basically HTML that works both encoded and as clear text. Meaning it is the perfect note taking "language". In reality it is "just" "a convention for how to write super nice-looking notes that have been tested by millions of people to be the very best it can be. No big deal. Oh also it is free, you do not even need a special program to look at it. Your browser can do it perfectly.

Stop teaching top down!!!

So I am trying to learn GoDot because... Well, a game engine can make games, sure... but it can also do a lot of other things when you realize it really is just a GUI renderererer (help! How do you stop spelling renderererererer???) + physics engine. Anywho, so I started following the "official tutorial" (In quotes because I am honestly not sure... It is a big open source project so it can get muddy). And... Once again I am faced with a tutorial that teaches me the larger constructions and the orgenization before telling me anything about how the smaller bits work... This is called top down teaching. And it works, WHEN (And ONLY when), the person you are teaching, are already familiar with what the smaller things can do. It can work when teaching someone who already knows object oriented programming, functional programming. They already know how functions, variables, processes and code execution works. It does NOT work when people haven't gotten the faintest idea of what these boxes and structures you are describing are. We do not teach kids algebra before they know division and multiplication. When writing tutorials like this you cannot write for everyone. You have to go with assumptions of the majority. And it is not a great idea to assume that the majority of the people who tries to learn GoDot are veterans of game development. Sure, your tutorial will be slightly better for veterans, but you have just made sure that newbies have an even harder time starting learning your engine... Whenever I start feeling like I have a solid grasp on this, I will start a tutorial on this... BOTTOM UP!

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

This is freaking amazing. And I think you are making good choices in simply cutting away what is not working so you can make your deadline.

I am still curious though.

Power banks are freaking temperamental little bitches ( There is NO standard for when they should give charge, other than the vague " When a phone is connected" ). How did the environmental sensor not like it?

And did the programmable RGB have a datasheet to explain the logic of how to address LEDs?

And would it be possible to adjust the addressable LEDs by powering them with a PWM signal? ( IE, is it powered by 5V? )

Servo skull integration is underway!

I have run a few tests and the core functionality seems to be working fine - so I can press the button and it'll take a picture with the camera embedded in the left eye socket, briefly illuminating an led that's in the right eye socket and playing a buzzer briefly.

The green led turns on when the program I wrote is running, and if it's connected to a network the orange led will also turn on(so I can tell whether it's accessible to get the pictures off of it)

So it should be all good for MCM London on Saturday at this rate, just need to check that the cranial casing for the left hand side won't affect the picture too much

Had to remove the environment sensor as it didn't like that it was being powered from a power bank - so no temperature alert when it gets too hot for me(It was going to light up the remed if the temperature got above 30°)

Also had to take off the programmable RGB array, as whoever wired that integrated circuit was clearly on a great many things when they designed it - Trying to just access specified lights was madness. The first led was accessed through (0,1) whilst the 2nd was (1,1) and the third (6,0). And having all of them on made it looks like the skull was about to self-destruct with how bright they are