Hey want to know a neat git trick, something clever that you'll rarely use but will impress the troglodytes you work with?
Screw you.
No, seriously. Stop it. Stop abusing git and github for your own personal jollies and use it like you'd use a damn source repository.
What does that mean? Well, a few things:
1. Your code should have a "master" branch. It doesn't have to be called that, but this is the most stable, public ready version of your stuff. This branch is ready to roll, rarely has the latest features, and is as bullet proof as you can make it.
2. You should have at least one "dev" branch. This is where you work and frankly where you may show your work. This is the code that may not work, have bits missing or have the latest features that might also turn your mouse into a chicken.
3. If you know that anyone, anywhere has grabbed a copy of your code, THOU SHALL NOT DICK WITH THEM!
What dicks with them?
- git commit –amend
- git rebase -i
- git push -f
Don't do those or anything else that requires them to do anything other than
git pull
restart
Let's discuss why those are bad, shall we?
Davinci wasn't famous for twirling pens
Git, like vim, emacs, compilers and keyboards, is a tool. A tool that you use in order to craft Interesting Things. What you should be focused on, is the Interesting Thing. That's the new bit that other folks will also find interesting. If you spend hours learning fascinating things you can do with a tool while building your Interesting Thing, neato, but realize that you've also lost hours you could have been putting into the Interesting Thing. If you then require other folks who are willing to help you on Interesting Thing to then spend hours learning all the marvelous tricks you now know about a tool in order to help, that's also time that they're not going to spend helping make the Interesting Thing.
If there are bits of code that do require very clever utilizations of said tool you can do one of two things:
- Limit the modifications of that bit to only those who have invested the time and effort into learning the tool that well
- Re-evaluate why the hell you built something that way.
(i'd opt for the second solution.)
Show your work
Ok, this one is more around github. Yeah, so, lots of companies are asking developers to point to projects hosted on github instead of asking for code samples. Heck, i love it when folks add links to their github repositories on their resume.
Know what i don't like? When i can't see your work. i've never written a perfect program the first time. Well, not one that exceeds a few dozen lines of code at least. i tend to build methods first, and then convert them into API functions second because my principle interest is getting things working. Plus, as an object gets used, it will become fairly clear what elements are actually needed rather than an "EXPORT ALL THE THINGS!" approach. If you look at my development code, you'll see that.
This is not to say that there aren't folks who are like Michelangelo and are able to wrought things of pure beauty in a single go. i'm just not one of them and i'm comfortable portraying myself as such. If i'm hiring Michelangelo, (and asking my employer to pay accordingly) i expect to get Michelangelo. If i find out you ain't him, i'm not going to be very happy and yes, you will know that.
Plus, if i see you having trouble with a bit of code, i know to pay attention there. Maybe there's a different way to do it. Maybe i can help write tests to really pound on that bit. Maybe i might appreciate the effort it took to do that rather than glaze by. Gates writing a BASIC interpreter that ran on the first go was a fluke, not an aspiration. (And he put in a helluva lot more time and effort on it than you're doing with that routine.)
It's just a goddam tool
No, really, it's a tool. Honestly, nobody cares how clever you are with it. Or how you've mastered it's nuanced complexity. It's like saying that you're exceptionally good with a socket set, but you're hopeless as a mechanic. Or that you've absolutely mastered the tape measure but can't build a shelf. Unless you're looking for a career as a tape measure performance artist, you're wasting your time.
i use vim as my editor and like it. i use maybe 5% of the functions and features of vim because that's all i need to write things. If i need some larger, more esoteric thing, i search for how to do it, maybe try it a few times, but unless it's something i plan on doing every day, it's not going into long term memory. Vim, is just a goddam tool. i'm saving those neurons to remember a better way to exchange crypto keys or note how to swap system disks on linux while not shutting down, or, hell, what i had for lunch because that's more important.
And, no, i'm not impressed by your skill and mastery of your tool if your code is broken.
