Programming as a career

I am surprised vilegit.com hasn't been snapped up by VI purists

I am a vim purist but I stopped haranguing people about it 10 years ago

Some helpful but less-trafficked git commands that I use:

git ls-files -m

git add -p /path/to/file

My most recent git discovery was -v on git commit (which I’ve now made the default behaviour). It appends the diff (along with the list of staged and unstaged files) in your editor when you edit the commit message. It’s in the commented bit so it doesn’t go in the commit message but it’s useful to refer to, and most useful for catching stuff you shouldn’t be committing.

Oh, nice!

git add --patch whatever.js

is essential for a hygienic commit log

Thanks for the reminder! Any pro tips for using stash?

I always forget stash options so I have to look it up every time:

https://stackoverflow.com/a/10726185
https://stackoverflow.com/questions/3573623/is-it-possible-to-preview-stash-contents-in-git

And a whole bunch here!

https://www.freecodecamp.org/news/useful-tricks-you-might-not-know-about-git-stash-e8a9490f0a1a/

Thanks. Have also started using “git stash push” so that I don’t stash everything, just the files that are causing a merge conflict, say.

Wow just found out you can stash hunks as well.

If that's what you're into.

Lol

And now I have an even dorkier d/n.

https://i.pinimg.com/originals/7f/cd/36/7fcd3690d0e1b184c2d8d9fef6cbac98.gif

If only!

I'm learning tmux now!

[
git add --patch whatever.js
]

is essential for a hygienic commit log

i visit this page once or twice a month:

https://sethrobertson.github.io/GitFixUm/fixup.html

neat

I decided at some point that I hated trying to remember command line options and started using GitExtensions as my Git IDE; I have never looked back.

Sourcetree is nice on Mac.

not found anything decent on linux yet. and the one i did like (gitg) lost a lot of the things i liked about it from one version to the next (and gets confused by binary files, like 100% cpu confused)

(svn is generally better for my use case anyway - large document, lots of tiny changes - than git anyway because it stores the diffs and not a complete copy of each like git does*. i had a git directory that was 40x the size of the original document once)

(* git will compress eventually, i'm told, and i'm sure i could force it to happen faster than it does, but svn does it by default)

We onboarded a new hire recently who came from a bootcamp, and I realized that of our entire engineering team at the local office (we have presences in multiple regions), only our VP and lead security guy and our worst (by far) developer have CS degrees. That leaves a director, a devops lead (who has an EE degree), and two senior engineers (including me).

Actually the other senior eng has an interdisciplinary degree that can definitely fall under the CS heading.

aren't you the one who was trained not to say 'onboarded' though

Me? Not that I remember!

well obviously not now, you've been corrupted

As long as we're talking jargon, yall have permission to FP me if ever use these:

- solutioning
- grow (i.e. grow a business)

My god I use a lot of these I have become that which I hated: https://www.trustradius.com/buyer-blog/27-most-annoying-business-buzzwords-of-2019-explained

"double click"

Is the word “wheelhouse” in that list?

Ha, of course it is

remote pairing with a TDD pedant is killing me.

he writes a test, i write something that implements it (there's a huge clear spec so i know what needs to be done exactly, this is also not the first of these we've done), the change is literally 7 lines - i set a flag in the constructor, test that flag in a later method and call skip() twice if it's true.

"That commit doesn't really feel like the minimum required to make the test pass. It's jumping ahead too far."

yes, because if you insist on backwards and forwards a line at a time then we'll still be writing this when the 2024 olympics rolls around.

seventeen years in startups before this job. the whole thing would be done in a day and just as solid.

ffs

you must now reveal the truth -- the commit itself was a test. and you've good news: they passed. make a certificate, print it out, and mail it.

the certificate should say "Top Asshole" of course

our JUnit stuff is so ramshackle, it's almost not worth doing it at all. either the tests aren't meaningful or they're designed to break on every change. most of them make no sense at all.

I’m not saying it’s impossible to write tests but I can tell you I don’t know how to do it

i like writing tests very early. it speeds certain things up a ton IME. i can see the appeal of writing tests _first_ but i never actually do it myself. but TDD goes beyond that.

that said: all js testing frameworks are dogshit, and i miss pytest.

Static typing is my god now.

TDD* seems inefficient as a concept at the best of times, constantly overwriting tests and implementations. seems like pussyfooting towards something you could just rattle off.

probably wouldn't be so painful if we were sat together but the remote working aspect means i don't even know whether he's there! or whether i'm waiting for him to get back from lunch / meeting.

(*Test Driven Dev, not Top Down Design. too many acronyms, not enough alphabet)

> Static typing is my god now.

nasa swear by it. and yet java has just introduced 'var'.

I'm a big fan of TDD, even though I don't adhere to it strictly (I don't write every test covering every scenario off the bat). I guess overtesting is technically possible, but I don't see how high coverage can be a bad thing? Like if what you're testing is trivial, then the test should also be trivial.

coverage is orthogonal to TDD

"That commit doesn't really feel like the minimum required to make the test pass. It's jumping ahead too far."

^^^ TDD

What? That sounds antithetical to my understanding of TDD.

TDD as I understand it:

- write tests before you write code
- write only enough tests to prove the code works for your use case's defintion of "works"
- stop writing code immediately when these tests pass

I agree with point 1 (though the practice and theory can be pretty distant IME), point 2 seems nebulous, but point 3 seems like an uncharitable interpretation.

since we do mostly services, our version of test-driven is we do OpenApi (swagger, whatever) definitions of the API, someone writes tests against that spec (call a url, validate the returned data is in the expected format and schema, no errors returned) and someone else can code the service at the same time

so you can set up static endpoints with both good/bad data to make sure your tests work properly and then when the actual service is ready you just point it over there and run

integration tests are only good for spotting erroneous changes and regressions imo, good for big infrastructural open source projects

testing code with artificial things is a pain in the ass