Might wanna read it again, it’s right there :)

The best architectures, requirements, and designs emerge from self-organizing teams.

It’s an incredibly critical part companies love to completely ignore.

If you assign devs to teams and lock em down, you’ve violated a core principle

And it’s a key role in being able to achieve these two:

Agile processes promote sustainable development.

And

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is talked about at length by the likes of Fowler, who talk about how locking devs down us a super fast way to kill sustainable development. It burns devs out fast as hell.

Note that it’s careful not to say on the same project

That’s actually a pretty important part of its original premise.

It’s a big part of why scrum meetings were a thing, as the expectation was any curious dev could just join in to see what’s up, if they like.

Not tying devs down to 1 specific thing is like the cornerstone of agile, and over many years of marketing and corporate bastardization, everyone had completely forgotten that was literally the point.

The whole point of the process was to address 2 things:

1. That client requirements can’t easily be 100% covered day one (But you still need to get as many as you can!)

2. To avoid silo’ing and tying devs down to specific things, and running into the one bus rule (“how fucked would this project be if <dev> got hit by a bus?”)

And the prime solution posited is to approach your internal projects the same way open source works. Keep it open and available to the whole company, any dev can check it out, chime in if they’re familiar with a challenge, etc.

One big issue often noted in non-agile companies (aka almost all of them) is that a dev slent ages hacking away at an issue with little success, only to find out far too late someone else in the company already has solved that one before.

An actually agile approach should be way more open and free range. Devs should be constantly encouraged to cross pollinate info, tips, help each other, post about their issues, etc. There should be first class supported communication channels for asking for help and tips company wide.

If your company doesn’t even have a “ask for help on (common topic)” channel for peeps to imfoshare, you are soooooooo far away from being agile yet.

I’ve literally never actually seen a self proclaimed “agile” company at all get agile right.

If your developers are on teams that are tied to and own specific projects, that’s not agile.

If you involve the clients in the scrum meeting, that’s not agile.

If your devs aren’t often opening PRs on a variety of different projects all over the place, you very likely aren’t agile.

If your devs can’t open up a PR in git as the way to perform devops, you aren’t agile.

Instead you have most of the time devs rotting away on the sane project forever and everyone on “teams” siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because “they worked on it so they knpw how it works”

Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.

Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.

Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.

A really helpful metric, to be honest, of agile “health” at your company is monitor how many distinct repos devs are opening PRs into per year on average.

A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.

Harpoon is pretty much just tabs, but, without the actual visual ui of tabs, from my experience.

You pin a specific buffer, and can jump back to it, but unlike normal markers it persists between sessions and has a couple other nuances to it.

It pretty much works like tabs do though.

Often people are surprised that I can walk and type but honestly I haven’t found it impacts my wpm at all.

Yup, I usually have it set to the slowest setting when typing.

I find I work much better and can think clearer while walking, as it keeps the blood flowing and makes me feel more awake and engaged.

If I have a tough problem I’m trying to work through I turn the speed up to a faster pace and sorta just work through it in my head while speed walking, often this helps a lot!

During meetings when I’m bored I also turn the speed up a bit.

I often get around 10k to 12k steps in a day now.

Note I don’t stay on the treadmill all day long, I usually clock a good 4 hours on it though.

Then I take a break and chill on the couch with my work laptop, usually I leave my more “chill” tasks like writing my tests for this part, and throw on some Netflix while I churn all my tests out.

Highly recommend it, I’ve lost a good 15ish lbs now in the past year since I started doing it, and I just generally feel a lot better, less depressed, less anxious :)

I have heard of jupyter but am not familiar with its nuances.

But doing python dev with neovim is very doable, it uses the same LSP I think.

I personally have a dedicated dev machine running debian that has everything on it, including nvim configured.

I SSH into my dev box from other machines to do work, because neovim is a TUI it “just works” over SSH inside the terminal itself, which is what I like about it.

It feels good to just

1. SSH into my box
2. tmuxinator my-project-name

And boom, 4 tmux tabs pop open ready to go in the terminal:

• nvim (pointing at the project dir)
• lazygit already open
• nvim (pointing at my secrets.json file elsewhere)
• an extra general console window opened to project root

And I can just deep dive into working asap in just those 2 steps, it feels very smooth.

I often can even just do tmux a (short for attach) to just straight re-open whatever session I last had open in tmux, instantly jumping right back into where I left off.

I try and start using it for basic tasks, like note taking, to get used to its interface and basic commands like :w and :q, as well as switching between insert and cmd mode.

Once you are familiar with switching between modes, copying, pasting, etc, then you probably will wanna Starr learning it’s lua api and how to load in some QoL plugins. Basic stuff like treesitter, telescope, and nvim-tree are good places to start.

Once you feel comfortable with swapping between files with telescope and configuring plugins, I’d deep dive into getting an LSP up and running for your language of choice so you can actually code.

In the interim I’d recommend getting comfy with using tmux in your terminal, try and open new tmux tabs to do units of work instead of constantly cding around.

I like to keep 4 tmux tabs open for a project:

• nvim
• lazygit
• secrets file open in nvim (usually my secrets file is in another dir so it doesn’t check into git)
• a general terminal tab for running commands

From my experience the only big changes I’d say I made overtime are:

1. Font size bumped up

2. Switched to neovim from visual studio, which took like a year to relearn my entire workflow (100% worth it though)

3. Switched from multiscreen setup to one single big screen (largely due to #2 above no longer needing a second screen, tmux+harpoon+telescope+fzf goes brrrr)

4. Switched to a standing desk with a treadmill, because I became able to afford a larger living space where I can fit such a setup.

If I were to do this meme though it’d mostly be #1, there just came a day when I had to pop open my settings and ++ the font size a couple times, that’s how I knew I was getting old.

The rabies vaccine seems to have an actually higher negative reaction rate in some pets.

We have had 2 of 4 of our ferrets react severely to it on the second shot, of the “emergency midnight trip to the vet” variety.

Here’s key reasons why you can’t compare this to human vaccines:

1. It’s not covered by health insurance. You too would balk at a covid vaccine if it ran you a $600 or so.

2. Pets are way more likely to get injured. Even a small child knows not to flip out and bite a doctor, or jump off the table when getting a needle. Your little dumb fuzzbutt on the other hand very well may attempt this…

3. From what I’ve been told by my vet and some others in the community, the rabies vaccine has an actually higher than usual allergic reaction rate compared to what you are used to seeing. I’ve heard numbers along the lines of 5% to 10%, compared to something like less than 1% of humans reacting to most vaccines.

4. Emergency midnight hospital trips also aren’t covered, and will run you easily another $1000+, whereas if your kid has an emergency at night you still are covered

5. Dosing benadryl for a tiny pet is way harder, it’s way riskier and easier to fuck it up and potentially cause harm. As opposed to how a small child can be given a tsp of children’s benadryl, your looking at like 1/10th of a pill for your pet. Better not have shaky hands or your pet is dead… (or be like me and happen to own a jewelery scale so I can precisely get the dose right)

6. Have you ever even tried to administer benadryl to a pet before? If you haven’t, you have no idea how hard it is. Normally my ferrets are good with meds but benadryl tastes vile to them and they make it very known.

7. Finally, it’s pretty normal for exotic pets to just… never go outside anyways, my ferrets have the run of the house but they’ve only been outside (not in a kennel) a couple times, and they didn’t really like it much. Spent pretty much the entire time climbing up me to get away from scary noises and hiding in my jacket to get away from the wind. When I opened the door to the house they bolted back inside. We don’t do outside time with em anymore, they just don’t super like it as indoor pets. Too loud, too scary, too cold.

So yeah, all the above combined perhaps makes it a bit more understandable why people are leaning away from these shots.

Larger pets like dogs and cats though are much lower risk. They can handle larger doses, aren’t exotic so can be covered by insurance, normally spend lots of time outside, etc etc.

But rabbits? Ferret? Hedgehogs? Etc etc… naaah not honestly terribly worth it. Huge risk for basically zero reward.

Your ferret/rabbit that never steps outside isn’t gonna get rabies.

Nowadays it’s less of an issue with docker and whatnot.

Just set the image to refresh every night at midnight and if they tried to make manual changes it’ll just revert back to its original state at midnight.

Customers don’t really get direct access to deployed code now, it’s buried under like 4 layers of abstraction on most CDNs now.

Simply deploying to azure already smears multiple layers of access control and RBAC overtop that it’s hard enough for me, the dev, to answer the question if “what is actually deployed atm?”, let alone for the customer to get in their and meddle.

There’s not really a nice way to frame “your post sounds like it was written by an extremely cringe teenager trying to cosplay as their idea of what constitutes a professional dev, demonstrated by the classic combination of ignoring everything prior written, attempting to represent a ball of mud as a badge of honor, and unironically trying to use lines of code count as a metric to measure by”

Literally checked off all the “lol sure bud” boxes in a single statement, and then if you aren’t picking up on the nuance, let me explain what I wrote after:

I hope you understand later how incredibly cringe what you wrote is, because the day you do is the day you have likely matured enough in knowledge and skill to call yourself a professional unironically, which is a good thing.

Until that day, stop prostrating shit like what you just wrote above if you ever want any developer worth their salt to take you even remotely seriously, otherwise you will likely find yourself the laughing stock very quickly of any serious circle.

Best of luck out there, and finally:

Next time someone is giving extremely useful advice, just write it down, don’t shit talk. That’s without a doubt the #1 divergence that separates the path between long term failure vs success.

Everything about what you just wrote, and the way you represented it, signals you are precisely the type of individual that should take everything about what I wrote above very much to heart, friend.

If you have no idea what I’m talking about, I hope one day you do :)

That’s code review.

Only on very small projects.

As the team grows, having just 1 person review your code is simply not sufficient.

Even 2-3 may not be enough to sanity check if a larger new feature on a massive project is good. If it impacts the team and means a fundamental shift in methodology, then you need more voices weighing in.

Now, can you merge the PR in first, then have the meeting after? Sure, I guess, but why would you?

If the team reacts negatively to what you built, finds flaws in it, or simply just doesn’t get it because you overengineered, now you have to revert the PR and go back to the drawing board.

It makes tremendously more sense to bring folks impacted in on a swarmed live PR review as you go over what you did, where you did it, and why… before you merge it in.

At this point you can QnA, get suggestions, feedback, etc.

Now typically most of my response to live chat feedback is “aight, can you add that as a comment on the PR itself so I can see it after?” And then they go and do that asap, usually typing it up as I answer other folks questions. Because at this stage the PR is literally the perfect place for feedback to go.

I’ve been down the path of “1 person LGTMs the PR, huge new feature is added, I document it on the wiki rigorously, I post the new feature to chat… 1/10 people bother to use it and 9/10 give blank glassy stares when I bring it up”

It. Doesn’t. Work.

Period, lol. And don’t get me wrong, I wish it did, but people just don’t RTFM mate, that’s a fact of life a d the sooner you accept that, the easier the job gets.

it’s rare that a single PR introduces anything but a small slice of a feature

Yes, I never said this was a common occurrence. This is indeed rare but it dies happen.

And we’re not really talking about a PR review at this point

No, this is 100% still part of the PR review, I was pretty explicit about that. This process should happen for a large feature/service/etc as this simply cannot be covered by a “LGTM!” Comment on a PR.

These meetings primarily cover when you’ve established something that needs to be followed or used moving forward. IE: “This new feature makes our lives a lot easier and now (annoying thing) is much easier to implement. This is how I used it in my PR and I wanna make sure all the rest of the team is on the same page about it, and everyone else starts using it in the future.”

This 100% comes up here and there and it absolutely necessitates an actual meeting, because any dev worth their salt knows what happens if you dont get everyone on the same page on it…

The inevitable “why didn’t you use (thing I made explicitly for this purpose)?” Convo comes up a month or two later, because all you did was document the new thing and open a PR, get a couple "LGTM!"s, and you posted a blurb about it in the chat and pinged some folks.

And if you’ve gone through this process before you will know that simply just never works, full stop. Doesn’t matter the team, doesn’t matter how well documented, doesn’t matter how good your write up is… People. Don’t. Read.

There’s a reason “RTFM” is such a meme in linux communities, people don’t fuckin read mate, abd that’s why critical big PRs 100% need a 20-30 min QnA meeting so people can actually talk about it.

I’d estimate tops 10-20% of devs that should read your docs, will actually do it.

Do you not do demo meetings after introducing entirely new features?

Sometimes a PR can be quite large as it involves an entirely brand new feature that simply didn’t exist before.

And if it’s an internal tool/service for fellow devs to use to make their lives easier, yes, it likely deserves a meeting so the devs can have a chance to QnA about it. Usually 5-10 minutes going over the who/what/why/where/how, then 20 mins or whatever of any needed QnA if devs are curious for more info about specifics, like performance or extensibility or etc.

If you create a new tool like that abd then just hand it off with all the devs have to go on being “here’s the manual, figure it out” you know what happens?

Almost no one reads it, and pretty much no one uses it, because parsing a giant manual of info is difficult co.pared to seeing a live demo

1. Make branch for the ticket
2. Make periodic commits to branch
3. Open PR from branch to main
4. (optional) if the changes are big, I have a meeting with devs to discuss it. If I can’t easily explain to the junior devs what I did and why, it means I did something wrong.

As a senior dev, I’ve found “can the junior devs grok wtf I did/made” to be an excellent “did I overengineer?” Litmus test.

A good implementation should be not too hard to explain to the juniors, and they should be able to “get it” in a single short 20-30 minute meeting at most.

If they are curious/interested and ask questions, that’s a good sign I made something useful and worthwhile.

If I get a lot of “I’m not sure I get it” and blank stares, I probably have overcomplicated the solution.

If that “ooooh, okay!” Comes quickly, then we are good!

The automobile didn’t put cabbies out of jobs, it put horses out of work.

If anything it actually made demand for cabbies skyrocket, because now they could do the same job but way faster, so now they were more affordable abd not just a service reserved for wealthy.

In other words, expect that AI will increase demand for programmers exceptionally, as the bar for entry lowers.

An LLM still needs a “pilot” to “drive” it, and you need to still know code well enough to interpret the output and catch mistakes or hallucinations.

But typically when a field becomes more affordable, it goes up in demand, not down, because the target audience that can afford the service grows exponentially.

“But if it’s so easy to become program now, what’s to stop people from just using ChatGPT and never hiring a programmer?”

Same reason people still, today, hire cabs even if they can drive themselves.

Convenience. Time is money and just because 1 person can do all the jobs of a company, doesn’t mean they physically have the time to do it.

I think the reason experienced devs tend to have minimalist websites that look like they are from the 90s, is because software devs aren’t UX experts.

At a senior level at large companies, someone else designs the look and figmas to make the site be pretty. I don’t do that shit.

I can do some basic stuff as a front end dev, but react has nothing to do with css animations and all the stuff you typically associate with a “pretty” website.

Reactive frameworks are just handy for updating the dom on a mutatable website (ie forms, web socket stuff, data in out, pulling data from a db)

Blogs tend to be statically generated so there should be zero reason to use reactive frameworks anyways, unless you add something dynamic like perhaps a comment box folks can login to and leave comments/likes/shares etc. Loading those comments will prolly want a framework.

Aside from that, it’s mostly css to do fancy stuff.

You can’t “invoke logic via HTML attributes,”

Oh boy a semantic argument

Proceeds to describe how you can use HTMX to invoke logic via HTML attributes

Whatever you want to call it, trigger, invoke, whatever.

You can leverage HTML attributes to automatically cause arbitrary Javascript ajax calls to happen by extension if those attributes being present.

Trying to argue the semantics of this is stupid.

You put HTML attributes on shit, and the presence of those attributes in turn causes arbitrary Javascript client side logic to fire off purely due to the presence of those attributes.

That’s like, literally it’s entire shtick.

And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.

“HTMX doesn’t bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)”

It’s bonkers how many people don’t grok this, SMH.