hmps

Kontrakt

Senast uppdaterad: 2013-02-20

Mellan mig, [MITT NAMN] och er [KUNDENS NAMN], [KUNDENS ADRESS]

Sammanfattning:

Jag kommer alltid att göra mitt absolut yttersta för att tillfredsställa era önskemål och behov, men det är ändå för allas bästa att ha några rader nedskrivna om vad som är vad, vem som ska göra vad och vad som händer om något inte skulle gå som planerat. I det här kontraktet finns inga komplicerade juridiska termer eller långa stycken av oläslig text och jag har ingen önskan att få er att skriva på något som ni kan komma att ångra i framtiden. Detta är helt enkelt för bägge parters säkerhet, nu och i framtiden.

sindresorhus

#!/usr/bin/env bash
# MIT © Sindre Sorhus - sindresorhus.com

# git hook to run a command after `git pull` if a specified file was changed
# Run `chmod +x post-merge` to make it executable then put it into `.git/hooks/`.

changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"

check_run() {
	echo "$changed_files" | grep --quiet "$1" && eval "$2"

getify

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.