I’ve done this enough times I chain the desired command and the cd together:

    cd ~/x/y/z && my-command

So that when I CTRL-R for my-command it automatically reminds me.

If you’re doing this for history value put it in a subshell so it doesn’t change your working directory in a confusing way:

    (cd ~/x/y/z && my-command)

Neat idea, definitely going to use this! Thanks for sharing

cwd is one of the default fields. Here's my first nushell command:

    $ history | get 0
    ╭─────────────────┬─────────────────────────────╮
    │ start_timestamp │ 2023-12-15 15:39:12.872 UTC │
    │ command         │ ls                          │
    │ cwd             │ /home/matt/src/configs      │
    │ duration        │ 31 ms                       │
    │ exit_status     │ 0                           │
    ╰─────────────────┴─────────────────────────────╯

It would take some smarts to figure out when to bind the cwd and when not to, but that would be the interesting part.

I used to feel this was true for me, and to a large degree still do. But lately I’ve been wondering to what extent this is a self-limiting belief, and how much I can train myself to remain productive in the face of interruptions. My life is more complicated now than when my career started, and the interruption causers seem to be multiplying, so I’m seeing it as something I need to learn to deal with if I’m going to be able to stay in the field.

I will tell you what. When I joined this field (decades ago) an entry level engineer would (after rampup) do more than whole teams do today.

This is not because people were somewhat better back at that point in time.

We had trust, respect for people's time and overall everyone was at least directionally pulling in the same direction.

Today we have a low trust, hustle and micromanagement culture. I am shocked every time people with experience simply don't help grow a junior engineer (because fuck em and they're gonna find a better job if they grow, amiright?). I am shocked whenever we throw people at a problem while it was shown over and over again the approach does not work for that problem. Shocked when trivial improvements are hailed as the ultimate engineering feat and impressive engineering feats are met with meh. I am shocked when people do not think (at all, zero, nada) about the performance and maintainability of the code they bang out.

People just started giving zero fucks. The future is bright.

> Today we have a low trust, hustle and micromanagement culture. I am shocked every time people with experience simply don't help grow a junior engineer (because fuck em and they're gonna find a better job if they grow, amiright?). I am shocked whenever we throw people at a problem while it was shown over and over again the approach does not work for that problem. Shocked when trivial improvements are hailed as the ultimate engineering feat and impressive engineering feats are met with meh. I am shocked when people do not think (at all, zero, nada) about the performance and maintainability of the code they bang out.

Do you work at my company?

This is basically what every company is like nowadays.

I think we can thank the MBA-ification of the workplace for that.

I'm "secretly" pondering a formula where a group of employees share an assistant rather than a manager.

In stead of a layer of management above the people manager the assistants also share an assistant.

With a small salary comes a rigid job description without free styling.

1-4 times per year you bring in a consultant/freelancer to read the reports (AI generated abstractions) and twiddle the knobs for however long it takes. Say 1-2 weeks with nothing but meetings. It should probably involve a hotel, resort or boat trip.

How do you manage hiring and firing from the team?

That's ultimately why Managers wind up "on top", they can make choices about who to bring on, and who to let go.

And since they are "on top", they say they deserve more money and more control, etc.

You're half joking probably but this is what a manager should be. Someone who enables you, not someone who makes your job hard.

Since having kids I’m a lot more able to get in the zone for 1-2h at a time since I rarely get a whole day free (also due to a more senior position). I think it’s largely procrastination. But I also try to batch and minimize the meetings the engineers on my team have to take

Database indices.

Possible, yes, and frequently used I’m sure, but entangles the retirees financial future with the business’s future — the retiree loses if the new owners make bad decisions, overleverage, and end up defaulting / bankrupting themselves. I don’t think it’s reasonable to force all businesspeople to retain this risk after disposing of the business concern.

Building inspections are not really the same as purchase inspections, or at least don’t seem to me like they should be. Purchase inspection generally might not see a partially-constructed building or blueprints or otherwise be able to verify the engineering plan is being followed—They’re looking for broken/nonfunctional appliances/mechanicals/systems, clear fire hazards, mold, infestations, and the like.

The outcome of a building inspection is a certificate of occupancy where the authority is stating the home is safe to live in, the outcome of a purchase inspection is a report of things to ask for a discount on, part of the purchase negotiation.

The Chatham County thing is crazy, I’m hoping the family manages to find someone accountable in that mess — clearly either the original architect, the builder, or the county let them down somehow. I’m just not sure it’s really an indictment of the “inspector” profession as discussed in this thread.

found the neteng guy

maybe they used gitops

I had a manager — who I basically loved — that loved to say “assume positive intent”, perhaps from teammate $T

And I tried!

But my priors were that teammate $T has rejected ideas from most of my design documents for (imho) inconsequential reasons — Eg there were framework scalability concerns of using a framework that handles 1x-1000x the projected growth of the current project.

Telling me to “assume positive intent” from feedback saying it wouldn’t work “because scale” (when we were comfortably 4-5 orders of magnitude away from those problems) felt pretty empty.

More honest pushback would essentially be “this solution didn’t need this scale yet”, or “we can afford to re-architect this right now” — “finding deals” becomes a rent payment from someone figured

Ok, so there was a disagreement on how to move forward. How did you resolve it with your teammate?

I read as “only one person on the team I was interviewing for”, not “only one person was swe”

I use a similar setup to store code snippets (certain Java annotations for integration/unit tests, various things like that), vehicle license plate/vins, internal (but nonsensitive) ids for test accounts, tons of things like that.

Honestly a password manager would probably be technically better—or a bunch of flat files lol—but there was a certain charm to having it displayed / function exactly as I like it, and lightning quick with nothing I didn’t need.

IDE would be another natural place for a lot of my usages, but I kept finding I needed to leave it in a pull request review or slack conversation or similar, not necessarily programming myself.