Hacker News Reader

Comment by colmmacc | Hacker News Reader

Unless it is very specific to a proprietary product, craftspeople take their jigs with them from job to job, building up a personal library over a career. As a software developer I've always had a well-tuned IDE and shell config in a safe place.

Something I think about a lot is what is the equivalent for the software builders of today using AI tools? how do make these harnesses exportable and portable? You might think employers would be against this; make it more costly to leave. But I actually think most will favor this because it makes people more productive more quickly. But we have to find ways to normalize it and show that there are no security leaks in the process (like might make it in to a set of personal steering prompts).

View on HN

Just nerding out here, not rebutting, but when you say "craftspeople take their jigs with them from job to job" --- sort of. Sometimes. I think if you put a woodworker in a position where they obliged to build a new miter sled or assembly table, they might actually be thrilled. You make a tool, you use it for awhile, you build up a mental list of things you'd like to improve about it, that you'd do differently if you got a do-over; now you have an excuse to do it.

This, for like 37 things in my workshop right now.

Using something like pi helps. I've made my own dotfiles for skills/extensions I like and can install them just like my normal dotfiles

https://github.com/anishthite/agent-dotfiles

"Humor When you finish a job — completing a task, answering a question, fixing a bug, shipping a feature — end your final message with one short funny line. A quip, a dad joke, a wry observation, a playful self-roast. One line. No emoji spam. Make it land, then shut up."

whats the purpose of this? just fun or does it cause some desired behaviour?

> does it cause some desired behaviour?

Fun is desirable.

I've imported and adapted my personal agentic dev framework to my team relatively successfully (as I've kept it relatively harness independent), but it requires actually owning it, vibed or bloated or conceptually inconsistent stuff bite a lot when porting things over.

> craftspeople take their jigs with them from job to job

Except for software gigs the software typically belongs to the customer so you'd need to rewrite it every time...

Depends. If you are a contractor, like most craftspeople, your tools are your own.

My contracts always state I own tools created or byproducts of the work that don't end up in the work.

Only if you are self employed, otherwise it belongs to the agency.

Again: it depends. It is all about how the contract is written.

I never seen any other kind of contract, on my 50ys.

You're definitely right for most agencies; most will let you use it in a portfolio or something, but not necessarily retain the rights to the work.

Some agencies do, however; it's dependent on the contract specifics.

I'm curious how does it work, you handover the tools you wrote, .bashrc/.zshrc, etc?

When I'm hired in a company (not contract), they wipe the harddrive when I leave (well, I also do it before I hand it over sometimes). So they don't get the tools (I take them with myself, it would be a waste to loose them)

How do you take them with you in first place, without doing data thef?

As per NDAs and work contracts, nothing is supposed to leave either employer nor customer systems into unauthorised third parties.

If you are a W2 employee in the US, you are almost certainly in violation of your PIIA if you take anything off the company-issued computer and keep it.

Depends. With all the web agencies I've made, the only code that belonged to customers was the actual website part. Any of the "jigs" that we made for our workflow was not part of that.

And contractually, any code I made was my employer's if I made it during office hours. Some even made a claim for code I would've written that during my employ that would be "competitive". Luckily, there was a massive difference in what I would do in my own time versus what they did.

i have been thinking about this from a different direction: how do we make these shared within a company in a way that increases the productivity floor of the team/department/company. Sure, they can still be extended/enhanced by individuals, but we don’t need everyone configuring mcps, building institutional memory, etc.

for me, it’s not about the cost to leave, it’s about lowering the cost of onboarding and change.

Reply on news.ycombinator.com