What's Your Favourite Fact?

What's your favourite fact?

Don't really have many favorite things.

But I will tell you the best one I can think of right now:

"Human eyeballs are all the exact same size. "

Now. In fact, they grow a little bit ra little while after birth. And "Exactly the same size" means "Within 1-2mm" but I think it counts.

Why do I know that fact? Because I make robots. And robots can get the distance to something on the camera IF they know the true size of an object next to the target.

And eyes are quite easy to spot with peogramming. So robots use all the human eyeballs to constantly calibrate their distance measurements.

Now THAT is a neat fact!

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!

hey. hey guys you know what would be funny.

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!

OMG I LOVE IT!

What is the dumbest thing you have coded and gotten to work?

a discord bot in my friend group server where it would scold people if they swore XD

An example hehe

Sharing knowledge is awesome! This inspired me to write... a small novel... which did not really fit as a reblog so I will post as its own thing :)

What’s your take? Should senior developers spend more time coding or coaching more junior peers?