This new junior dev was going pretty well, learning pretty fast and working pretty fast from when I talked to them, but I wasn't seeing his changes up on GitHub.

Me: Hey have you finished *feature X*

Junior: Oh yeah a few days ago.

Me: Why aren't your changes up on GitHub?

Junior: Sorry, my bad, im not used to pushing stuff during the development since i was used to do all of my stuff on my own
(No kidding!)

Me: ok then push them

Junior: Emmm... I don't think I should... I kinda already started working on *feature Y* so it's full of bugs...

I don't wanna be mad at them they're pretty good at their stuff, and he's got some good comments on the performance of the program. But UUGGHH 😠
Rookie mistakes I guess

  • 16
    At least they realized it might be a bad idea to push it right away? 🤷🏻‍♀️
  • 2
    Do you assume that you might've actually misjudged them? Did you walk them through the usual process of how things work?
  • 9
    Educate, don't scold. If the commits have been made, then he can branch locally into a new feature branch from a specific commit (the one before starting feature Y), push that branch up, PR merge into master and then switch back to his feature Y branch
  • 2
    I use this excuse if I'm lazy, I even convince you the app has feature XYZ
  • 14
    Teach them about feature branches!

    It was amazing when they finally clicked for me.
  • 2
    Growing pains, painful, but at least they're learning ... also time to get those features their own branches ;)
  • 0
    More often than actually separating fixes and feature branches from the start, i actually do all the things in my feature branch and later extract fixes and features out of it after the fact.
    My commits in the main branch rarely have a one-to-one relationship to commits on my dev branches.
    I tried to strictly separate work into independent branches. But it really did not work for me (my brain doesn't work like that).
    Extracting new commits after the fact thankfully is rather easy on GIT.

    Maybe your new junior dev has the same problem and could profit a lot from you teaching him the magics of GIT (especially branching, rebasing, merging, resetting - and especially the incredible usefulness of mergetool and gitk).

    Extracting feature and bugfix commits after the fact isn't as efficient as proper branch separation from the start.
    But it would allow him to deliver features and fixes as they get completed.
  • 1
    Git is also kinda an amorphous thing until you really work with a group of folks to see it.

    Any rando jr. who just did it themselves or with a small group... probably hasn't seen much of it.

    Hell I don't think I've seen much of it ;)
  • 1
    @Elyz yeah, although I hope they push to a dev branch and not master.

    I think a basic introduction to git would be good, to make the difference between committing on my local branch Vs pushing and merging clear
  • 1
    Not to be a downer but it sounds like he's lying to you.
  • 0

    Doing workflow organisation together can work miracles against migraine from having to fix up mistakes made from not knowing stuff....
  • 1
    @LotsOfCaffeine I think every dev should learn basic vcs shit from day one!
  • 0
    @saynah yeah learning the basics of git is fairly important
  • 2
    Brilliant education opportunity for a junior.

    Teach him how powerful git is - in the longer term, feature branches should of course be used for this sort of thing. In the shorter term, get him to rewind the history to the point where Y was ok, and push that (or branch from that point to make further changes to Y.)
  • 0
    As the superior its your job to monitor and mentor the junior to ensure they learn these things.
Add Comment