Me: *uses google chrome*
Parents: Stop, log out of everything, you're hogging up the internet, omg
Me: *unplugs computer*
Parents: *their computer still not working* You downloaded a virus to our wifi you're grounded for a month

I spend a night in the woods from time to time. 🏕️ It really gets you grounded and helps to take a step back on all those dev / work related issues.

do you have a GREAT eye for design?!

can you write a bubble sort algorithm in binary?!

do you know native, desktop, embedded, AND web programming languages?!

do you know you can go fuck yourselves?!

good luck unicorn searching 🤡 companies. there is no human that can do all of those on a level that you want. but, go ahead and set yourself up for failure. i'll remain firmly grounded on planet earth 🌎

This morning in the office:

- bumblebee grounded
- diagnosed low fuel level
- refueled bumblebee with sugar water
- system check pass, airworthiness restored
- bumblebee asked tower for take-off
- tower opened flight window
- super-clean take-off
- bumblebee left control area

:-)

Having robot parents is hard. I got grounded for getting 100 on my test!

The GitHub of the people who have answered the questions I look for on StackOverflow! It always keeps me grounded.

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

!dev

i havent been on dr in a while, but here goes nothing. i started going out about 3 months ago with a girl who i've been texting a while.

she's everything i've ever wanted and i think about her all the time. this may also be a good time to mention i'm fifteen. well, i'd hang out with her all the time. it's the most fun i ever have. i tell my parents i'd be seeing my friends but i'd be with her or walk to her house. time with her was the best.

and, more recently, i've been engaging in some not-so-appropriate physicality with her.

a few days ago i asked my parents to drive me to my friend's house when i saw the look on their face. they found a used condom with a pregnancy test and some lube too, and they made me spill everything.

it's been a week since i last saw her. she decided to tell her mom what we did on the off chance my parents decided to tell her mom we had sex.

this fucking sucks. i'm grounded and can't do anything. does anyone have any suggestions on what i could do? i think i'll wait out my grounding then just see her whenever i can.

My anxiety is over the roof. I have keep 3 media players simultaneously playing Pink noise, Sounds of raindrops and lofi hiphop just to keep my brain grounded.

I choose to believe performance self assessments are useful. Not for, like, my actual job, but they keep me grounded. Nothing like seeing your entire body of work for a year summed up in 30 to 40 bullet points to deflate your ego. Also it gives me a chance to work on my skills in what some of you might consider "lying" though I consider it more along the lines of "creative truth telling" and "having a loose grasp on reality".

Official documentation > StackOverflow.

StackOverflow sometimes has well-grounded and elaborate explanations on a question by well-meaning and knowledgeable developers, but oftentimes the answers also contain outdated or 'dirty' solutions and so it's always to be taken with a grain of salt.

However, in cases like the official Spring documentation, the IETF RFC's and the MDN, those provide a correct explanation to the problem, even if it requires some reading around. When it comes to serious and correct work, I favor these over the bro-zone that is StackOverflow.

> How do you spot a technician at a young age?
> He likes being "grounded".

Offence taking Siri. :)
"I heard what you said about the new macbook. You're grounded." deletes 4 apps.

Looking for time management tips or apps or tricks you use to keep grounded. What works for you?

Why is it that people start to care about quarterly objective key results only at the end of a quarter?

You know, those stretch goals decides by management grounded on wishful thinking rather than realistic planning.

I should plan my vacation on the last weeks of the quarters.

Making music definitely made me a better programmer. In fact playing lots of instruments showed me the different roles that exist on a team. Lead guitarists are kinda like programmers, constantly looking for the next challenging song to make. Singers and rhythm guitarists are like the team leads and PMs who want a nice bow on the product. Drummers are like designers really, they kinda show up and make something bad ass and disappear. Bass players are like solid backend or ops folks silently making stuff stable and grounded.