Programming as a career

Lol

Don’t know if it’s a religion thing but why do some people hate to do a git rebase and then do a fast-forward merge.

we banned merge commits on our project because of one guy

Not surprised. Did the graph look like the one shone here in The Problem? https://mtyurt.net/post/git-using-advanced-rebase-features-for-a-clean-repository.html

Can you lock out all merges? We have fast-forward-only some branches but then I recently noticed that some of the more unenlightened just merge that branch into theirs and then they can fast-forward this merged melange back.

I missed out on the TDD conversation but I wanted to mention that my one experience pairing with a TDD disciple involved watching her create a bunch of tests that were logically incorrect, getting them to pass, and missing giant pieces of logic that interconnected subsystems of the module we were working on and actively mocking other pieces of functionality we were supposed to be testing, so technically we wrote passing code according to the tests but, because the tests weren't actually right, the whole thing was super buggy and caused a bunch of later rework.

I know this isn't the fault of TDD per se but it did play into a lot of my preconceived notions against it.

Re: merge commits, I don't see why anyone should care what I do on my feature branch as long as I squash-merge into the main branch.

Yeah we don’t care what you do on feature branches but main (nee master) is ff only enforced via our code review thing (gerrit). What this means in practice is you hit “merge” and gerrit rebased your change into the tip of main then merged by ff. if there’s a conflict you have to resolve it and resubmit the review. We used to let people do that without running the tests but the number of people who committed the string “>>>>>>>>>” was getting out of hand so it has to at least build after a manually resolved merge conflict.

Doowatchyalike, just don't create a twelve-lane merge superhighway and then (DEAD) BEEF when your merges ultimately break down.

https://www.destroyallsoftware.com/blog/2017/the-biggest-and-weirdest-commits-in-linux-kernel-git-history

Thanks.

Also, I misspelled Doowutchyalike.

It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge".

I would just like to take a moment to say javascript sucks and lodash sucks and _.times REALLY sucks

Why does every fucking thing have to be a function, how about you () => juggle(myBalls)

Not only does it all have to be a function but there’s a strong convention that functions be anonymous whenever possible because fuck the reader, right?

Isn’t most of lodash in es whatever these days though?

our linting rules haven't been updated yet to favor the native implementations, why because fuck everything and everyone

imo this is what happens when you let Perl aficionados design everything

Don't worry, Dan, it will be updated just as soon as Perl6 is production.

Why does every fucking thing have to be a function, how about you () => juggle(myBalls)

juggle(this.nuts)

everything being a function is good not bad tbh

fuck state, keep it in a box

counterpoint: nah

Mutable state is a turd on the polished marble floor of my exquisite grand hall hung with crystal chandeliers

https://www.youtube.com/watch?v=Xwm3eW9YyFw

Classic or dud: late night email from colleague cc-ing management saying he can’t figure out something you gave him a few weeks ago and it is crashing and you need to put in more error checking etc. ( because his time and productivity etc)

Well this has been sorted for now.

# get password via terminal without echoing
password = STDIN.noecho(&:gets).chomp

reasonable, right? sentence in english explaining the cryptic command that follows. i don't get the "document WHY not WHAT" review comments i always get.

coming new to this code, debugging it later say, such things let you understand which part does what without having to decode the code. = useful, especially if you're in a mixed ability team.

also, review comments from people you haven't asked for reviews, classic or dud?

Leaning towards dud.

Codesplainers gonna codesplain.

If people would just put in fucking comments saying what they were trying to do and what their expectations were, basically defining the contract they're trying to fulfill, it would be about 8 billion times easier to identify logic mistakes than it currently is.

https://www.hillelwayne.com/post/what-comments/

i have an issue with that

> //f.ex $F1a3

f.ex? for example? what's wrong with 'ie' or 'eg'?

(my whole script only exists because someone checked in an aws kms encrypted key without explaining how it was generated, and 3 years later we needed another - lack of documentation again)

I can see where the anti comment review on that is coming from. The comment duplicates stuff that’s in the docs, right? It’s not a “trick” that depends on undocumented behaviour (like the fact that piping to xargs is a way to trim leading and trailing white space?! Did you all know this?!). It’s just something that’s not obvious from reading the code. That’s not where I draw the line and your point about mixed ability teams is a good one, but it’s not a terrible place to draw it.

Whoa, xargs trick is neat!

I am old. I still use xargs -i and never switched to -I

Also can never remember that xargs idiom using the shell trick.

Ah, xargs -0 will keep the whitespace

Feel like comments should be judged on their practical effects rather than from some philosophical position. If it takes 2 minutes to figure out a chunk of code without comments and 10 seconds to figure out the code with comments, I don't care how "obvious" or "self documenting" the code itself is, the comments are good.

otm

I say this as person who long ago took a course - in Pascal! - nicknamed "Commenting For Credit" in which people were expected to do things like

  i := I + 1; //increment I 

(input wants to uppercase every i)

 i := i + 1; //increment i again

Next topic: git commit messages.

//increment topic

ruby doesn't let you i++. spent a chunk of sunday looking at cryptic error message and not seeing the problem.

Feel like comments should be judged on their practical effects rather than from some philosophical position. If it takes 2 minutes to figure out a chunk of code without comments and 10 seconds to figure out the code with comments, I don't care how "obvious" or "self documenting" the code itself is, the comments are good.

Can we attach this to everyone's monitor?

I think I only write comments that are at least 100 words long

I'm the only one reading my code/commenting so too many of my comments are targeted at my osteoporosis of a memory, e.g.,

// The + 16 offset is event type, commenting so I don't forget it yet again
// The + 16 offset is still event type, it appears I forgot it again

(4000 lines apart, to be fair, and not my code but decompiler output)

public static final int EVENT_TYPE_OFFSET = 16;

trust me that's not feasible in this thing, it's certainly possible but this is 240K lines of code and I can't just ctrl-f

Btw, my posts from a few weeks ago was about colleagues who are part of the development process and are participating in alpha testing but seem to want to behave as if they are end users and are shocked - shocked! - when something breaks. Perhaps this is a touchy subject.