Programming as a career

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

The thing that makes me crazy about writing tests is I understand kind of how to write tests for pure functions on data but that’s only about 5% of any actual application, the other 95% is doing bookkeeping with resources like databases and external services and god knows what, setting up mock everything just to test that stuff feels tautological and maddening. I just can’t.

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.

― AxoLOLtl (Leee), Friday, July 10, 2020 2:15 PM (two minutes ago) bookmarkflaglink

i don't understand if you're agreeing/disagreeing with these practicies, or with the claim that they describe TDD.

Point 1 is an accurate description of TDD, though my adherence to it is not complete.
Point 3 does not accurately describe TDD, IMO. In my practice, I'll write the easy tests first, then as edge cases crop up, add appropriate tests (though I probably add it to the code before I add these scenarios to the test suite).

well sure point 3 elides the fact that it's supposed to be a loop in which you get the tests to pass, then add more tests, then get the new tests to pass by writing more code, add more tests, etc.

but the point (and the definition of TDD AFAICT) is that you're supposed to stop writing code on this iteration as soon as the tests pass. you may opt to refactor (and you have tests so that should be easy). but you're done implementing new *features* or *behaviours* until you write more tests.

that's part of the *definition* of TDD AFAICT (based on the wikipedia page haha), and it's certainly consistent with the practice of TDD according to koogs' pairing partner: "That commit doesn't really feel like the minimum required to make the test pass. It's jumping ahead too far."

an example of one of his implementations.

method takes a structure containing a value and two flags. if either flag is true return the value.

so the tests were something like

structure.value = 2
retval = test(structure, true, false)
assertEquals(2, retval)
structure.value = 3
retval = test(structure, false, true)
assertEquals(3, retval)

and his implementation was

if flag1 return 2
if flag2 return 3

which just seems perverse when you could've written

if [flag1 || flag2] return structure.value

and be done with it.

or is that "jumping ahead too far"?

it's not always insane to overtest simple code because:

1. tests are incredibly valuable if/when you refactor/add features later
2. the easiest time to write tests is when the implementation is on your mental stack, not months later, and definitely not if someone else did the implementation.

*that* is insane though.

It’s definitely perverse to write a wrong implementation just because it passes your first stab on a test

Actually I think I’m going to throw up

Like does this guy ever want to get anything done in his life