I appreciate it! This site is actually already one of the many git related tabs I have open :D

this book/website has saved my bacon more often than i'd like to admit. good luck brave programmer.

https://git-scm.com/book/en/v2

Trust in your heart and the diffs shall become as one

oh no

i was extremely excited for a first person terminal

All the kids here pronounced Quake as "Guahkeh" here so the name is super amusing to me. I'm the kind of a super nerd who uses the Xmonad window manager and typing "Windows key + p + xterm" each time I want a terminal truly is pita so I'll give this a shot. Function keys are pretty neat and ought to be used by more software imo so just hitting F12 is super convenient.

i used to use this quite a bit! i stopped when i moved away from GNOME because it doesn't play very nicely with other desktops. then again i don't think i've tried it in many years. i should give it another whirl.

i love linters especially when they can autoformat to a particular style. elixir has one built into its build tool and i've also had good luck with rubocop in ruby and eslint for JS.

Linters are, imo, pretty damn good. Honestly I like all kinds of static analysis things. They also end up being kind of stealth tutors pointing to problems you couldn't have known (yet) and you can learn stuff genuinely out of a need.

I've read some of TeX book and a little bit of Knuth's journal articles, but face the facts, dude rules and when it seems like he's wrong (like with goto), he always had something interesting to say about it.

this!! holy shit this.

and it's funny that you mention the knuth books because reading knuth is what got me into literate programming tools that would send comment hater types into apoplexy.

they shall be memorialized in commits

bugs are friends :'(

I feel like this is, again, some Uncle Bob bullshit. Seriously, fuck that sexist prick. He has this schtick about how TDD is all and other techniques to improve reliability and reduce errors are bullshit. Like I would be much more congenial to the attitude if it implied things like (choose your own picks):

1. programming by contract
2. property based testing
3. fuzzers
4. unit testing
5. integration testing
6. good method documentation, perhaps with (an) example(s)
7. literate programming
8. code review
9. formal specs
10. some nicer type system
11. pair programming
12. safer languages - if there are no segfaults, you don't need to advertise the risk of one
13. Have some people dedicated on hammering your software in evil manners
14. proofs (but that's avant garde tbh)
15. stats on commits/bugs per product, project, package, module, file, method/function. If something gets a lot of work done, unleash the testers.
16. Outsourcing to Donald Knuth

I think it's the case usually that this comment hater has one or three favorite techniques they like and thus disregard the rest of the universe and I bet they don't even have TAOCP on their book shelf.

that's exactly the common attitude i hate so much and it drives me batty. to me, a lot of comments indicates a lot of complexity, not necessarily bad quality. sometimes the things you have to do are just complicated! and it doesn't mean the code is bad, just that you're doing something hard. and if you don't write a ton of comments about it then when you have to understand it again in six months it's gonna be just as hard, and take just as long, as arriving at the solution the first time.

i'd rather just take the risk of comments getting out of sync with the code they decorate, because at that point they'll be about as useful as no comments, and then you've only wasted whatever span of time it took you to write them, and i think most everybody can write comments faster than they can write code.

It has this cute logic of "excess comments indicate poor quality" and also this hidden thing where you don't need to write comments that you find boring to write anyway but now you have a virtuous reason not to.

If I was an instructor on some software course, I'd make an online assignment to come up with 5 excuses for not writing documentation and share the best answers with the class afterwards.

Class invariants are imo cool and underappreciated part of OOP. It's also my belief, untainted by any real research though, that designing, verifying and testing them would kill lots of bugs.

my code is self documenting! :^)

tbh I didn't know about 'class invariants' until just now, but Wow these all Hurt to Read

"comments are bad" is a surprisingly common opinion in the industry and also one of my least favorites

"I don't write comments because comments and code drift apart."

"See the unit tests if you really want to figure out how it works."

"I'll document it later now that I got it working and it made it into the API."

"I'll lock down this method's name before writing its documentation."

"Contracts? Code is law."

"We use test driven development here so we don't need dedicated testers."

"The language I use doesn't support checking class invariants well so I just ignore them."

"It was clear enough for Torvalds."

"Commit it now, compile it later."

"I don't write documentation for functions besides types, since types are compiler verified and they are plenty good anyway. Everybody gets these things just like me."

Uggggggh lol

Interview isn't a job. This sort of thing isn't uncommon in tech industry.

Did they not give you a name and phone number you can check on an Amazon directory of employees?

Developers at all levels have to not fall for a phishing attack: verification of contact isn't a bad thing, and actually shows a level of consciousness in the role all employees play in security.

Ooh this makes the most sense.

I ended up emailing them back before I saw your reply. I said "thanks but i got a job sorry", I'm wondering if I should have said "also i am basically a babby programmer"

maybe i can put "got an email from amazon, so you know i'm good" on my resume