Programming as a career

"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

git is good but has way too many options so takes forever to learn.

And then there are current best practices but some people didn't upload their brains so are still stuck on outmoded best practices.

goddam I really messed up this whole career thing lol

crushed some SQL today lads

xp -- this isn't career stuff, the only code I've done in the past month is a dumb reverse engineering project

lol sorry that was just a general scream into the void

Scream away!

I was scanning over my old posts, and I'm kind of stunned at how far I've come. Granted, that was (yikes) more than 10 years ago, but the industry's changed a load too, especially with the rise of bootcamps. I think those alone would've helped me out back then, and they're probably the best avenue for people thinking of getting into industry as a part of a career change.

I am proud to have leapfrogged from bash scripts into management like the ambitious careerist motherfucker that I was raised to be

Or basically “I realized I sucked at code so I volunteered for everything else I could do until it worked”

volunteering to do things where you've found a strength is seriously underrated and doesn't work in all organizations, but it's a good strategy

git is good but has way too many options so takes forever to learn.

I think git is great but to me its very much a secondary thing, I don't want to do anything more than the 8 or 9 commands I use. And if I found I was doing anything more than that I would wonder what had gone wrong that I needed those things.

Although hmmm, having said that github actions might be something worth looking into one day

I’ve done some vile things with git

surprisingly, vilegit.com seems unregistered

a foul repository

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/