Programming as a career

cf git blame --ignore-rev

it's a refactor of some classes into smaller classes. so all the test classes need refactoring too. and then some test utility things have been changed to static methods so everything that used them have also changed.

(it might also be that the 84 is for the entire pull request whereas i've only looked at the first commit so far)

and some default formatter keeps dicking wih comments so you end up with stuff like

// very long comment that would be fine all on one line but the formatter
// disagrees

wait, is RAD whatI think it is? If so, condolences

I finish bootcamp in two weeks, gang! :D

Congrats...was this an online bootcamp? How was it affected by covid?

Which one did you do? Was it a Rails one, or JS, or something else?

I did ReactJS!

I went to an actual campus six days a week until the COVID lockdown

my last job the codebase had a "tabs-to-spaces" commit that messed up git blames but it's possible to skip over it/reblame starting before that commit in various ways

― silby, Tuesday, April 28, 2020 12:17 PM (four days ago) bookmarkflaglink

cf git blame --ignore-rev

― silby, Tuesday, April 28, 2020 12:17 PM (four days ago)

Oh nice! https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

Cool

lmao I didn't even realize that was a new feature, I perhaps haven't actually used that yet. idk whatever.

anyway, condolulations Whiney

Thanks!

definitely going to make use of --ignore-rev from now on but it'll be a pain to set that up for every giant squash merge.

squash mergers being fucking savages is the only programming hill i'm willing to die on

sorry whiney but you have to turn in your cool badge at the security desk now, prepare to be bullied, NERD

breh if i'm working on a giant project i'm definitely squash merging my fuckton of commits into 1 for the sake of keeping the master branch clean

smh if you aren’t interactively rebasing your feature branches into a glittering necklace of logical and well-described commits.

sorry whiney but you have to turn in your cool badge at the security desk now, prepare to be bullied, NERD

― j., Sunday, May 3, 2020 2:50 PM (two hours ago) bookmarkflaglink

going from "geek" to "nerd" will be a difficult transition but not an impossible one

It's been fun meeting people who have no idea what noise music is!

silby otm.

Just you wait, Whiney.

having a true commit history is infinitely more useful than having a clean master branch. also you should be doing what silby said

always said i'd leave ilx after stet adds inline manscaped adds

Congratulations whiney!

I did ReactJS!

Welcome fellow ReactJS dev!

"I did ReactJS!"

How is the 40 hour course on Udemy, anyone know?

Which one is it? Don't pay full price, the courses are often 90% off!

https://wesbos.com/courses is definitely worth a look

also worth noting is that react has some of the best documentation I've come across -- had to learn enough of it in about two-three weeks for a quick project, and that definitely helped

of course the downside to it is that I can't really say I know it, I just know enough of it to make stuff and google in the gaps

That describes nearly all software developers. The rest don’t know how to use google.

i was gonna say tbh

I guess my point was more, it's definitely possible to learn on your own, particularly if you have experience with coding/specifically javascript, but a course formalizes that, if that makes sense

My experience is that the formal stuff crops up more often in interviews, although at the same time there are some things that fall into that category but which I've internalized as Just Something You Should Know.

Which one is it? Don't pay full price, the courses are often 90% off!

https://wesbos.com/courses is definitely worth a look

― cherry blossom, Monday, 4 May 2020 bookmarkflaglink

It's this one:

[Removed Illegal Link]/

I have a free pass. My background is Data not web Development (SAS, SQL), know the project lifecycle etc.

I am currently picking up some Python and like R (doing a course of each for the next 1-2 weeks), but was wondering about a JS course.

Let me try that again:

https://www.udemy.com/course/modern-react-bootcamp/

(Only have it for free due to my company's account, not sure how long that will last)

I don't know that one but just the other day I was recommended 'The Advanced Web Developer Bootcamp' by the same author

My hot take is that by this point all courses are probably good. The only danger I think with courses is you follow along and build the app and maybe some of it is easy and some of it is hard, you follow along the path and get to the end, and think I kinda got this. Then any slight divergence doing your own thing and you're off the path and in the weeds drowning.

I think there's a lot to be said for the opposite approach, building things from the ground up and googling how to do each step. The reason primarily being each thing sticks a lot more, you don't lose what you've learned. There's definitely a danger with following courses/tutorials alone that it doesn't stick. A combination is best, smaller apps/projects for the second because its tougher than following a course

google in the gaps

This is the best skill to have, especially given the weird things that can come up you would never be able to prepare for!

Thats more of an all purpose answer, looks like differnt people have different needs/goals!

Lots of good courses to get a start on the basics but yes googling around the labyrinth of answers when something unexpected comes up and working through problems is almost like the key skill, whatever you code/script in.

I just want to say I was very anti-squash right up until the first time I had to rollback something out of the dev branch that hadn't been squashed; now I am all "if you do not squash that shit before merging, I will murder you"

smh

Right, BEFORE merging, not AT THE MOMENT OF merging.

If you're not committing to the trunk multiple times -- meaning that your changes are in an isolated feature branch that is eventually merged into trunk -- then you can revert all of that stuff by reverting the merge commit.

Squashing, being a manual process, always introduces the possibility of human error.

but if you squash your commits what will happen to your profanity-laden commit messages that end up here https://twitter.com/gitlost

Whats all the squash talk? Can't you just not allow the PR until its been squashed

We mostly PR directly on to master, ideally with few commits but I just reset and then PR with just the one commit (in theory not always in practice)

Yeah I commit until the cows come home into a feature branch, then squash the feature branch into dev. (I use Bitbucket to do this so there is little chance for human error.)

the trouble is the ideal number of commits to actually land for review is likely (imo) somewhere in between 1 and n

that said I don't really bother anyone I currently work with about this b/c our practices are bad and I'm still relatively new and don't want to waste my energy telling people to be better if they don't already value it

this is why when you "google in the gaps" on git you get three answers with all of them telling you definitely not to do what the other two say.

is version control hard or is git terrible? ('both' is an acceptable answer.)

You get better at googling though! Or maybe more accurately you get better at breaking down the bits so you're googling for smaller steps instead of "how do I build a moon"

I feel like git is as easy or as hard as your team makes it. I only really ever run add, commit, pull, push, merge, branch, checkout, and reset

ime it's beloved of people who like to over-complicate everything they do.

our default at work is to squash merge from feature branch into master. that way you don't get all the 'i'm trying this' or 'changed a thing' commits. before github there weren't feature branches...

I am lazy and just use a GUI

I do my adds and commits from the button inside vscode! the others from terminal

I think it would be cool to work at a shop where people had time to worry about things like squashing commits to make the log look nicer. Our logs look like a tire fire.

to be fair the only times I use git are for projects that don't remotely care about this, or for my own personal projects