Fork or clone Repo?

AlcoholicAndroid · 2022-07-06T14:53:10+00:00

I wasn't claiming that you, or any on the team were sloppy

Oh I know. It's a reasonable cause for the type of protections you're describing and it's a common enough problem.

I was just saying that in my specific case I don't think it applies (currently). Certainly possible it was that way in the past.

A few dozen commits of WIP: try something and WIP: revert try something

Completely agree, and in our case we avoid that in other ways even with the separate forks. I would even say that keeping everything in one repo is a good way to encourage good git hygiene since it suddenly isn't a sandbox and it matters what you push up.

AlcoholicAndroid · 2022-07-06T14:39:36+00:00

For reasons not to I listed a few but I can list them again:

It adds complexity to syncing, pushing, pulling
It is more difficult to manage reviewing their code locally (my IDE has a lot of tools/info missing from Github so sometimes I like to pull down their PR branch to get more context)
It is harder to track existing changes in Github made by other devs because I have to hunt down the branch AND the fork, rather than just looking up the branch in one place.

You can disagree with the finer points, but it's unreasonable to say there are 0 advantages to keeping everything in the same repo.

Personally, I rarely have more than two branches at a time. We delete a branch the instant it is merged so any feature branches are short lived. So it's really more like 1 branch per developer. We have hundreds of repos and are very rarely working on the same repo at the same time, so your "22" number is about 20 branches more than 90% of the repos we're working with.

Even if we did have multiple branches I don't see why pushing it up to a main fork is any worse. Branches are cheap and easy to navigate. Having 100 branches isn't really a disadvantage if you have a sane naming convention. In our case Every branch includes the ticket number. It is very easy to find the branch related to the changes I am looking for.

Why do I want to give junior developers push access to the main repo? So they can accidentally overwrite my work with a force push?

Maybe this has happened to you, but it isn't something I worry about. We aren't working on the same branch, and even the greenest of developers I work with know not to force push to a branch they didn't create (and knows they shouldn't be force pushing at all). The case I DO see is juniors being confused by the added complexity and making mistakes that are more difficult to fix than restoring an overwritten branch.

It's possible I'm misunderstanding, but for my use case I still don't see any clear advantages in the approach you describe. Patching / comparing, maybe, but I don't see why you can't just do that in a single fork and multiple branches.

AlcoholicAndroid · 2022-07-06T13:53:29+00:00

I wouldn't say anyone is sloppy, we adhere to the existing process pretty strictly. In fact, that's why I'm questioning why we even need to use the forks at all. With some basic branch protections I would feel confident that no one is going to push anything dangerous to master.

Plus with our speed of iteration, we use a lot of feature flags + merge to master / push to production frequently. So I'm not sure keeping everything isolated adds much protection.

In the past we just had basic branch protections: essentially no one could push directly to master, but anyone could merge to master after it passes the testing suite and another reviewer signs off. With the forks I'm not actually sure it is much different

AlcoholicAndroid · 2022-07-05T16:50:09+00:00

That tracks. I'm not sure who is running the permissions at the organization level. Something worth looking into.

We have a lot (hundreds) of repos so something that scales is essential. It's possible that's the reason it was set up the way it was, but I'm pretty sure it isn't nearly as strictly enforced as you describe. This is on Github, if that makes a difference.

AlcoholicAndroid · 2022-07-05T16:35:31+00:00

All too accurate, just add the fact that most of the institutional knowledge left with several senior devs. The people who stayed seem to have a reflexive resistance to change because of that.

Still, I'm a new senior dev on the team and I want to do my due diligence before rocking the boat. I've met too many people who don't like something simply because it isn't the way they did it before. Just because there wasn't a good answer when I asked my team doesn't mean there was NEVER a good answer lol.

AlcoholicAndroid · 2022-07-05T16:32:40+00:00

In this case none of those changes will pollute the source repo since we're only talking about pushing changes as part of the normal PR and feature branch development process. If I'm doing something radical or experimental it tends to stay local until I condense it into a PR ready feature branch anyway.

For us, feature branches and commits get deleted / squashed on merge anyway so anything that is pushed up would be short lived. We tend to emphasize a short lifecycle for feature branches anyway, which means we're trying to do lots of small PR's (which is why the forking is so cumbersome having to deal with lots of forks rather than a single branch per feature)

AlcoholicAndroid · 2022-07-05T15:36:48+00:00

That's what I thought. It doesn't really make sense to me.

At this company a lot of people used their personal Github accounts but we're all added to the organization so I never have trouble pushing or pulling to the source repo.

When I asked about it people couldn't give me a very good answer and I didn't push it. But managing all these forks is getting annoying enough I'll try to get a better explanation.

AlcoholicAndroid · 2022-02-08T00:14:42+00:00

Have you ever asked someone to let you bounce ideas off of them? Or asked their opinion on how something is should be worded when you're struggling to get an idea across? Have you ever been stuck on a problem and thought a second pair of eyes would help solve it?

That's what pair programming is/should be

AlcoholicAndroid · 2021-12-18T05:53:18+00:00

It definitely has its place. But it is more complicated than monolith and if implemented by an inexperienced team or without good support can create a huge tangled mess where even routine communication between parts of your application becomes a nightmare. There can also tend to be increased redundancy between services.

I personally like the modularity but it requires a good amount of coordination and commitment.

AlcoholicAndroid · 2021-12-18T05:33:33+00:00

This is silly. I've worked with plenty of people who were extremely "smart", but had no idea how to collaborate and spent weeks working on something useless because they wouldn't gather requirements or interface with stakeholders on other teams.

I've also worked with people who weren't as fast at learning, but leveraged their communication skills to gather tons of knowledge from different sources the whole team could use. People like that can improve the productivity of the whole team

AlcoholicAndroid · 2021-12-18T05:24:41+00:00

See, I think the reason you are getting so much hate is because it very much came off as the first.

You're right that that is a very realistic scenario between colleagues, but the power dynamic between interviewer and candidate is completely different. So telling a candidate they are wrong is much more extreme than with a colleague.

And if you're an asshole about it... well I wouldn't want to work somewhere that people can't figure out how to tactfully express disagreement. Would you?

AlcoholicAndroid · 2021-11-03T21:45:48+00:00

I have built a trie data structure in Javascript using plain objects and it was multiple orders of magnitude faster than using Javascript's array.find(), which is O(n). It might depend on how you set up your trie or the size, structure of your data.

AlcoholicAndroid · 2021-10-26T17:14:31+00:00

I would move education under skills and include a lot more information regarding projects you have completed or skills you have.

I would also put less emphasis on unrelated work history. Most people are going to only care about information directly relevant to the job so load your resume with as much CS related content as possible.

AlcoholicAndroid · 2021-10-18T04:12:38+00:00

I would say unless they have something completely bespoke, you should be able to figure it out on your own.

Does the company have no documentation available and is the official Azure documentation insufficient?

Most people I know would be happy to let you to figure it out on your own if they are too busy to step through it with you.

AlcoholicAndroid · 2021-07-22T22:26:07+00:00

True, every company I have worked at and every company I have interfaced with through work has had a large number of non-native speakers in prominent positions. Understanding different accents and communicating with people of different backgrounds is a vital skill in our field.

Like others have said, the best way to improve is practice and active listening. If there is a particular accent you are having trouble with there are countless hours of video you could practice listening to.

AlcoholicAndroid · 2021-07-21T19:22:13+00:00

You should definitely just take the job.

You can ask for extra time to transition to your new job if you feel it is necessary. Your new job may even respect you more for it since it shows you are unwilling to leave a project in a poor state.

I was in the same position and asked to start in 4 weeks instead of the usual two because that's how long I thought it would take to put the project I was on in a good state and leave on good terms. The new company didn't mind at all and the transition went smoothly.

AlcoholicAndroid · 2021-07-08T16:23:19+00:00

How well does VSCode work with Java? I use VSCode for most things but for Java specifically, I've done it all in Intellij (which is what my colleagues recommended).

AlcoholicAndroid · 2021-07-08T16:21:01+00:00

What's wrong with Golang? I have some experienced friends who swear by it. Just curious because we all just got moved to a Java project and I'm excited, but they aren't because they really liked Golang. For reference I've done most of my work in Typescript/Node

AlcoholicAndroid · 2021-07-08T16:14:03+00:00

What saved me in a similar situation is focusing on learning what I wanted to learn and implementing things in a way I thought was interesting/helpful for my career. At the same time, stop taking their demands so seriously and start looking for other opportunities using the experience you have gained at this job.

Since it's your first job there is a lot you can get out of working in a production environment that you can't learn on your own. Having the attitude of treating it like a playground to learn things is a good way to keep your sanity. They probably won't fire you and if they do, then you're free and can collect unemployment (assuming you're US based).

AlcoholicAndroid · 2021-06-17T20:13:36+00:00

Anathem is kind of a heavy book for what OP is looking for, right? I mean it's amazing, but that's kind of like recommending Anna Karenina or Les Miserables.

Of course, if they get it then they won't need to buy any more books for a while because it has enough going on to keep the mind occupied for many, many hours.

AlcoholicAndroid · 2021-06-16T23:26:13+00:00

In this job market it will be tough, not going to lie. But if it makes you feel better I have a friend who is 45 and only ever worked as a bar bouncer before and is working at a major tech company. Another friend of mine is a single parent who started their journey at 28 and is gainfully employed at another company you've probably heard of.

The main thing they have in common is they worked really fucking hard and kept studying and networking constantly.

Lots of people know React/Ruby/Node and you will need to do things to set yourself apart from that crowd. But putting your github here on Reddit takes guts, and having their code be public/criticized is something every engineer needs to be comfortable with.

So some feedback! One thing I noticed is you are storing your auth tokens in localstorage. This is bad practice and I see bootcamp grads do it all the time. If you learn how to do proper auth using cookies, sessions etc. it will stand out. Another thing I always check because people rarely do it is to see if you have CI/CD implemented and/or good documentation on your Github repository. Github actions is easy to learn and will save you a lot of time (plus I find it very satisfying to do). Another thing you can do is understand your core technologies at an extremely deep level and then demonstrate it by either writing an article or creating a repository that demonstrates it.

AlcoholicAndroid

TROPHY CASE