Just got a message on Facebook from a friend, asking me about getting into coding. A few seconds later, I see his status:

"Where do I download Javascript?"

I'm going to help this man.

dev, ~boring

This is either a shower thought or a sober weed thought, not really sure which, but I've given some serious consideration to "team composition" and "working condition" as a facet of employment, particularly in regard to how they translate into hiring decisions and team composition.

I've put together a number of teams over the years, and in almost every case I've had to abide by an assemblage of pre-defined contexts that dictated the terms of the team working arrangement:

1. a team structure dictated to me
2. a working temporality scheme dictated to me
3. a geographic region in which I was allowed to hire
4. a headcount, position tuple I was required to abide by

I've come to regard these structures as weaknesses. It's a bit like the project management triangle in which you choose 1-2 from a list of inadequate options. Sometimes this is grounded in business reality, but more often than not it's because the people surrounding the decisions thrive on risk mitigation frameworks that become trickle down failure as they impose themselves on all aspects of the business regardless of compatibility.

At the moment, I'm in another startup that I have significantly more control over and again have found my partners discussing the imposition of structure and framework around how, where, why, who and what work people do before contact with any action. My mind is screaming at me to pull the cord, as much as I hate the expression. This stems from a single thought:

"Hierarchy and structure should arise from an understanding of a problem domain"

As engineers we develop processes based on logic; it's our job, it's what we do. Logic operates on data derived from from experiments, so in the absence of the real we perform thought experiments that attempt to reveal some fundamental fact we can use to make a determination.

In this instance we can ask ourselves the question, "what works?" The question can have a number contexts: people, effort required, time, pay, need, skills, regulation, schedule. These things in isolation all have a relative importance ( a weight ), and they can relatively expose limits of mutual exclusivity (pay > budget, skills < need, schedule < (people * time/effort)). The pre-imposed frameworks in that light are just generic attempts to abstract away those concerns based on pre-existing knowledge. There's a chance they're fine, and just generally misunderstood or misapplied; there's also a chance they're insufficient in the face of change.

Fictional entities like the "A Team," comprise a group of humans whose skills are mutually compatible, and achieve synergy by random chance. Since real life doesn't work on movie/comic book logic, it's easy to dismiss the seed of possibility there, that an organic structure can naturally evolve to function beyond its basic parts due to a natural compatibility that wasn't necessarily statistically quantifiable (par-entropic).

I'm definitely not proposing that, nor do I subscribe to the 10x ninja founders are ideal theory. Moreso, this line of reasoning leads me to the thought that team composition can be grown organically based on an acceptance of a few observed truths about shipping products:

1. demand is constant
2. skills can either be bought or developed
3. the requirement for skills grows linearly
4. hierarchy limits the potential for flexibility
5. a team's technically proficiency over time should lead to a non-linear relationship relationship between headcount and growth

Given that, I can devise a heuristic, organic framework for growing a team:

- Don't impose reporting structure before it has value (you don't have to flatten a hierarchy that doesn't exist)
- crush silos before they arise
- Identify needed skills based on objectives
- base salary projections on need, not available capital
- Hire to fill skills gap, be open to training since you have to pay for it either way
- Timelines should always account for skills gap and training efforts
- Assume churn will happen based on team dynamics
- Where someone is doesn't matter so long as it's legal. Time zones are only a problem if you make them one.
- Understand that the needs of a team are relative to a given project, so cookie cutter team composition and project management won't work in software
- Accept that failure is always a risk
- operate with the assumption that teams that are skilled, empowered and motivated are more likely to succeed.
- Culture fit is a per team thing, if the team hates each other they won't work well no matter how much time and money you throw at it

Last thing isn't derived from the train of thought, just things I feel are true:

- Training and headcount is an investment that grows linearly over time, but can have exponential value. Retain people, not services.
- "you build it, you run it" will result in happier customers, faster pivoting. Don't adopt an application maintenance strategy

/rant

I've converted an empty bedroom in my house into an office and close the door when i code. when i finally leave my dungeon, my dogs are always laying down in front of the door, tails all a'waggin.

(mostly !dev) Fuck humans! Really: what a scum bag race. All that shit talk about human dignity, the highest values are just sugar coating the low base motives we mostly live by. Like people have such fine antennas for your income, social status, the power or lack thereof you exert over other. They know it before you open your mouth, that they can pick on you, harass you, because you're the one on the receiving end, the one that bows away. The bullies feel that. On an overcrowded chicken yard you'll find more dignity than in human society.

Everybody drooling over that polished photoshop life on facetubeinsta: materialistic, consumeristic, masturbatic wastage. At least we now say it openly: that if we were the winners, we'd also take it all, live that empty luxury, life of fame. But 99,99% of us, we aren't in that position, just working off our arse to only keep afloat. And for the stars, those fake images, we're just rats to click on ads to better train Google.

No wonder that software, as a picture of human communication is such a shitfest of arbitrary, entropic conventions and endemic epidemic of quirks, bugs and evil trap doors. As a whole: an insults to reason, a challenge to sanity. (...Conway's law)

And I'm still a bit pissed at our profession, that, you know, as engineers, scientists, physicists, we still see us in the lineage of that "great" age of enlightenment and reason,.. while it's all just a cover up. Sure science and their ideas are nice as long as you serve a purpose or make some money. Sure democracy and free speech are great achievements, but in the end some elites and monopolies rule the world at their gusto - and will not stop destroying the world unless we're already one feet in the abyss (like 1962, be we ain't had enough of that shit, hadn't we?)

When you introduce code into your game that has nothing to do with AI navigation, which somehow completely bones your AI navigation.