Devs regularly complain that our skills are not valued enough and that people think what we do is easy.

But, we don't really help the cause when we run around casually claiming to be "full stack" and not turning down work that clearly isn't in our area of competence.

We act more like Victorian amateur scientists.

Every seen a "full stack" doctor when you go to hospital? "Brain to feet---I can do it all."

OK, we have general practitioners, but they are really the BAs of the medical world. When it comes to getting into the weed, everyone specializes.

Full stack lawyer? "Hey, you did an excellent job of dealing with my house purchase. I've just been accused of murder. Can you represent me?"

While we continue to say that we can provide a high quality "full stack" experience I think we are signaling that this stuff *is* easy.

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

Arthur this isn't weed

So the saga of broken fucking everything continues at work, and I'm managing it, effectively, and doing it correctly on the first go-round. It's a long process though, because the two retards who preceded me were equally inept for completely different, yet equally disruptive and destructive reasons. The first dude was just plain psychotic, probably still is. I'd post some of his code, but I don't want anyone's face to melt off like those Nazi dudes at the end of Raiders of the Lost Ark. I can handle it because I'm constantly inebriated, which is not as fun as it sounds. If you have to ask yourself if you can handle it, you probably aren't, unless you've had to Uber to/from work due to still being fucking drunk. Anyway, enough about that, and it was only like twice. The rest of the times, I was more blazed than Jerry Garcia at a weed smoking contest. Moving along.

UPS shipping labels broke two weeks ago, I fixed it, but these fucking 10xers jointly decided to not only never implement anything resembling error handling, other than EMPTY GOD DAMN "try/catch"es (empty catch, wow so efficient), and instead of using COMMENTS, which I know are a new thing, they'd wrap blocks of code in something like: if 1 = 0 {} FUCK YOU DICKFACES. As I was saying before I got emotional again, they tied the success to all kinds of unrelated, irrelevant shit. I'm literally needle/haystacking my way through the entire 200GB codebase, ALONE, trying to find all the borked things. Helpfully, my phone is ringing all the time from customer service, complaining about things that are either nothing to do with the site, or due to user stupidity, 75% of the time.

A certain department at my company relies on some pretty specific documents to do their job, and these documents are/were generated from data in the database. So until I can find and fix all of the things, I've diverted my own attention as much as possible to the rapid implementation of a report generation microservice so that no one elses work is further disrupted while I continue my cursed easter egg hunt from fucking hell.

After a little more than two days, I'm about to lauch a standalone MS to handle the reports, and it's unfortunately more complicated than I'd like, because it requires a certain library that isn't available on Winblows, so I've dockerized the application. Anyway, just after lunch, I've finished my final round of tests, and I'm about ready to begin migrating it to the server and setting up (shitty fucking shit) IIS to serve it appropriately. At this point, this particular report has been unavailable by web for about 8 days.

A little after lunch, and with no forewarning of any kind, the manager of managers runs upstairs and screams at me to "work faster" and that "this needs to be back online RIGHT NOW", but I also know that this individual is going to throw a fit if things on this pdf aren't a pixel perfect match. So I just say "that's some amazing advice, I wish I'd had the foresight to just do it better and work faster". Silence for a good five seconds, then I follow up with "please leave and let me get back to my work". At that moment from around the corner, my "supervisor" suddenly, magically even, remembers that he has had the ability to print this crucial, amazingly super fucking important document all along, despite me directly asking him a week ago, and he prints it and takes it where it needs to go. In the time that it takes him to go to that other department and return, I deploy my service.

I spent the rest of the day browsing indeed and linkedin jobs, but damn this market is kinda weird right now, yeah?