I was explaining to my mom how my company is in need of developers and how we'll need more of them in the future - to which she replied:

"oh... what are you going to do? You can't live without a job!"

- erm? What?

"Well - you're not smart like those guys. You'll probably get fired now."

- Wtf mom!? I'm a friggin lead dev and i've been a developer for like 10 years now!? 😳

*silence* "is that what you've been doing? I thought you just kept clicking on stuff"

How to talk as a dev to a dev:
1.) Talk normally
2.) Start shouting
3.) Slow down but say it more aggressively
4.) Realise you made a mistake and/or misunderstood something
5.) Explain why it's not your fault
6.) Explain why it's someone elses fault
7.) Repeat

!dev !sex I promise this is a good read

I once read the whole bible.

Not in one sitting, ofc. I read it in a period of a year, just 3-4 chapters a day.

Is it something to boast about?
I'm not sure.

I mean, I guess being able to read through it despite not being exactly entertainment material (except some fun parts) kinda is. So I might feel a tad bit proud about that.

But I'm actually more happy that I did instead.

The reason I'm more happy than proud is because I took awareness of the religion I was in.

I became christian when I was an early teen. I grew up in an agnostic family. My dad was kinda hippie and my mom was into leftist ideas.

So me becoming a christian was a bit orthogonal to their philosophies.

I started assisting a church because I was very alone and misunderstood, and found some people there that seemed to get me, and viceversa.

But as time went on and I got more exposed to christian doctrine, my level of commitment grew.

I wanted to save people from going to hell. It sounds funny, maybe egotistical, but it's true.

3, 4 years of being in the church go by. I collaborate in the church, I make some very personal friendships, I was very deep in church by that point.

I then decide that I should take it to the next level and read the bible. So I did. And unknowingly, it started this feeling in me that I didn't liked being a christian at all.

I'm not gonna deny there are some christian values that are still compatible with today's modern society, such as being a good samaritan, working hard, being honest.

But there were too many verses in both old and new testament that I found morally repugnant,

The ones that made me feel the worst about christianity, though, were the ones that condemned homosexuality with death.

Since my dad was a hippie, he used to be in artsy things, like theater or music, and through that he had some gay friends

And for real, I think they were the nicest and most cheerful people I'd met as a kid. So I could not be part of that anymore.

Let me clarify that I didn't stop being a christian immediately after finishing the bible, but it did start a spark "of "what tf do I even believe in...?"

That spark turned into flame when I started the university, a place where people think for a living.

It's no wonder my mind started completing the puzzle, and slowly I started liking church and christianity less and less.

Until one sunday I didn't want to go, and I didn't, and from then on, I pretty much severed ties with that church and christianity.

Which is crazy considering I went every sunday without interruption for 6 years, and several saturdays too.

Anyhow, that's my story of me getting in n out of christianity. Like in the previous post, it sure how to end this, so go fuck a rock or something.

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