Plorkyeran posted:

I've literally never seen anyone advocate this, so I'm pretty sure you're just misunderstanding people talking about doing WIP commits on a personal branch that you then rewrite into something sensible before mixing it with other peoples' code.

Volguus posted:

It may be the case, if everyone is saying this then that must be it. Still, in a world that has merge --squash rewriting history is never needed. While is true that on a private, only you work on it, branch anything goes, why would you have one workflow in one instance and another workflow when working with other people when is trivially easy to just merge -squash and not carry the WIP baggage with you?

Plorkyeran posted:

A PR may have multiple things that should remain distinct commits when merged, but there really isn't any value to preserving "oops fixed a typo" commit.

Helicity posted:

The downside to that approach is getting in the habit of force pushing on your feature branches all the time - the last two times I've had to rewrite git history is from people accidentally force pushing on master when trying to do the above workflow and just whipping through commands too quickly.

Volguus posted:

Perfect, then you merge --squash from multiple branches. you can go as deep as you want in this rabbit hole. The only time I had to use push --force was when

Plorkyeran posted:

Why would I assemble several different branches when I can just have several commits on one branch?

Plorkyeran posted:

Nah, I think I'll continue to use git features rather than jumping through dumb hoops to achieve the same thing.

Volguus posted:

push --force is the nuclear option. Sure, it's nice to have it when poo poo hits the fan, required even, but just like the nuclear red button that US presidents have, exercise caution when using it. Preferably, never touch it. Use the better suited features for your goal.

ultrafilter posted:

The number of people who can handle web apps and the statistics side of things is small. That might be a good niche to explore in the hopes of finding a job that you like better than the one you might get if you just do web apps.

downout posted:

Im really confused by this conversation. Why wouldnt it just follow the standard process of branching, dev changes, commit, merge? Ive done some full discards in a local branch but once i push, i fix and push again. This is all internal repos. What am i missing on this discussion?

pokeyman posted:

git is hard to use and even more confusing to talk about.

Helicity posted:

I'm not either, but it's interesting getting their point of view and reading the associated comments on HN. Things to think about.

quote:

As time went on, we added over 50 new destinations, and that meant 50 new repos. To ease the burden of developing and maintaining these codebases, we created shared libraries to make common transforms and functionality, such as HTTP request handling, across our destinations easier and more uniform.

For example, if we want the name of a user from an event, event.name() can be called in any destination’s code. The shared library checks the event for the property key name and Name. If those don’t exist, it checks for a first name, checking the properties firstName, first_name, and FirstName. It does the same for the last name, checking the cases and combining the two to form the full name.

code:

Identify.prototype.name = function() {
  var name = this.proxy('traits.name');
  if (typeof name === 'string') {
    return trim(name)
  }
  
  var firstName = this.firstName();
  var lastName = this.lastName();
  if (firstName && lastName) {
    return trim(firstName + ' ' + lastName)
  }
}

The shared libraries made building new destinations quick. The familiarity brought by a uniform set of shared functionality made maintenance less of a headache.

Volguus posted:

Exactly. And what's even more baffling, is that there are few simple rules that one should follow to not shoot oneself in the foot and make life simple and easy for everyone (including himself). And then there are still those that come and say: naah, i'll keep shooting, since not once in the last X years i blew my foot off. Which is technically correct i guess.

pokeyman posted:

There are no simple rules when it comes to git, that’s what I was saying. I’m glad you’ve found a way to make it work for you though.

Dren posted:

There were a looooot of comments on HN about how the use of a shared library between the microservices was the real problem. Saying things like if you have a shared dependency you are missing one of the fundamental requirements of a microservice which is independence. This smells to me, a shared library that doesn’t change much is fine. Doesn’t matter if it’s your code or third party code.

quote:

a shared library that changes a bunch is fine too so long as the build/test/deploy complexity is well managed.

Helicity posted:

This is exactly the problem I've struggled with the most using microservices, and why I'm currently a big fan of monorepo microservices until I need differently.

You have 6 microservices that all use the same ThingyParser module/class/whatever. You confine ThingyParser to a single lib, you're wary of violating Open/Close and you're promoting DRY - you're a good developer(tm). Microservice 1 needs a new feature that the others don't care about, so you implement/test/PR/deploy the change in the lib and MS1. You keep doing this for a few weeks, and MS1 is quite a bit ahead in versions than MS2-6. Johnny got some new feature into MS4 that's kind of prod ready but not really and it's checked into master. A big bug is found and now MS1-6 all need to go to the latest version. Johnny's change has to piggyback along on the ride to prod even if it's not fully ready. That's also 7 things you need create PRs for and maybe even get change requests and releases scheduled for. You finally get through all that ceremony and process, go to a meeting, and there are new requirements for MS5-6 that are at odds with the others. You question the decisions you've made and why you're even a developer. You comfort yourself in the knowledge that in 10 years your code probably won't exist and in 50 years you'll probably be dead.

Helicity posted:

The downside to that approach is getting in the habit of force pushing on your feature branches all the time - the last two times I've had to rewrite git history is from people accidentally force pushing on master when trying to do the above workflow and just whipping through commands too quickly.

TooMuchAbstraction posted:

Grant people power only after they've butted up against at least a few cases where not having that power legitimately interfered with their workflows. At that point you've demonstrated that they do actually need it, and they've had a few chances to see how things are done properly (by having to get someone who's already been through the process to help them).

And naturally, if you have someone coming in and saying "give me admin i need to force push" that is the last person that should be an administrator.

Helicity posted:

I've found that most developers like and understand git a lot better when they do two things: start using the CLI almost exclusively, and understand that it's a https://en.wikipedia.org/wiki/Directed_acyclic_graph at heart and what that means. There are simple rules, but git gives you a million ways to violate them.

quote:

A UNIX programmer was working in the cubicle farms. As she saw Master Git traveling down the path, she ran to meet him.

“It is an honor to meet you, Master Git!” she said. “I have been studying the UNIX way of designing programs that each do one thing well. Surely I can learn much from you.”

“Surely,” replied Master Git.

“How should I change to a different branch?” asked the programmer.

“Use git checkout.”

“And how should I create a branch?”

“Use git checkout.”

“And how should I update the contents of a single file in my working directory, without involving branches at all?”

“Use git checkout.”

After this third answer, the programmer was enlightened.

pokeyman posted:

The git cli is exhibit A in the annals of awful interfaces. You can bang your ahead against the wall so much that it starts to "feel alright", it’s still a bad idea.

Many guis simply replicate the awfulness but with a couple edges filed off, ensuring that someone who knows the cli can’t help someone struggling with the gui and vice versa.

In conclusion, sourcetree.

AFashionableHat posted:

Helicity posted:

I'm getting asked this more and more, and I've had mixed results on how the advice is received.

Thermopyle posted:

Some advice is just not pleasant and you can't expect it to be well-received.

Helicity posted:

On that note, from a skills/knowledge perspective what are the 2-3 biggest things a developer can do to go from being a junior or average developer to something better? I'm getting asked this more and more, and I've had mixed results on how the advice is received. An example is that I found picking up a second language (and third, etc.) to be incredibly helpful to my career, but some devs don't want to be polyglots, and I'm not convinced you need to be a polyglot to be a good developer.

ultrafilter posted:

I think there's a pretty standard career progression these days, particularly at the early stages.

Love Stole the Day posted:

I think there are some things you're not taking into consideration when you say that. I wish I could agree with you but from my perspective it's exactly the same as it was during the recession.

Love Stole the Day posted:

I think there are some things you're not taking into consideration when you say that. I wish I could agree with you but from my perspective it's exactly the same as it was during the recession.

Helicity posted:

Do you live in a rural swamp or have a swastika tattoo on your forehead? Even during the recession, developers had a pretty easy go of it.

Helicity posted:

Apologies for not being clearer - I was thinking along the lines of learn a second language, get good on the command line, really understand functional programming, etc. Things anyone can do while they're in the process of getting more experience that in retrospect are like "holy poo poo I leveled up when I did that". The interns and other new devs I end up interacting with are begging for advice that is beyond "get more experience". Just looking for more ideas outside of my own experience that I might be able to share with them.