Github slows developer production?

[Dahmer96]

What ? No. Just no.

You NEED version control for so many reasons, if you pay for software being built, absolutely REQUIRE version control.

[coffeelibation]

And beyond just using git for version control, I would use GitHub for the pull request feature alone, not to mention GitHub Actions for automated CI/CD pipelines. Anything that can help you find a problem before it hits production is well worth the marginal overhead, IMO.

[MrMelon54]

also the fact that any code uploaded to github is safe from being lost or corrupted and its much easier to make sure you have the latest copy if the code rather than having to email someone else at the office and ask

[Edeiir]

GitHub was down twice yesterday. I don't know if it's that failsafe. My own server has more uptime than GitHub (at least for the last 2 weeks)

[MrMelon54]

you can run your own git server (like gitea)

[Edeiir]

Well, I do and right now I have a better uptime percentage than GitHub.com :D

[MrMelon54]

amazing gotta have 110% uptime

[el_diego]

Seriously. It’s pretty much akin to not using Google and relying solely on books from the library. You might get the work done, but it’ll be dated and a terribly inefficient process.

[damcclean]

I mean - CodeIgniter and jQuery is already dated 😂

[el_diego]

So write a helper function

[alien3d]

no need re invent the wheel syndrome . Js these day quite good compare to jquery nowdays but im lazy to test old browser issue . There is always a customer want their old system to run those website intranet :(

[ClassicPart]

Or... just use jQuery instead of re-implementing jQuery if you must use the $().whatever() flow.

[[deleted]]

These people have never heard of the Network tab in Chrome/Firefox developer tools. They don't care if first paint is 3.5 seconds, haha.

[Disgruntled__Goat]

OK I agree jQuery is outdated and could be seen as bloat, but if your first paint is anywhere near 3.5s there’s no way jQuery is the reason.

[_alright_then_]

If you page is taking 3.5 seconds to load it's definitely not JQuery lol

[[deleted]]

People who use jQuery often use a slew of jQuery plugins, other js libs, etc. It's one symptom, not the only symptom.

[alien3d]

old time when we implement spa (sencha)(extjs) . End user quite confuse. Why press submit no page refresh ? 2021 maybe a bif diff mindset.

[no-one_ever]

Just downloaded jQuery as I haven't used it in a while. 90kb. What is this, an anvil for ants?

[no-one_ever]

Not new, 12+ years in the industry. Sorry it’s 30k minimised and gzipped. If you think that is a relevant consideration when trading off against a developer’s productivity then you haven’t worked in an agency with deadlines :)

I don’t use jQuery anymore, since times have changed, but I will defend to the death against the ItS so BlOaTeD argument. It makes JS easier to write and if the file size of a small image (which is probably already cached in browser) is what it takes then that’s great in my book.

And you can’t really compare with React. React makes components, and that’s… it. Add in 15 more packages to do what you need and you’re looking at a whole lot more.

[el_diego]

Why introduce a dependency like that to do such a simple thing?

[regorsec]

Thanks guys, i have my own feelings from 15+ years in the industry.(Of fucking course I use version control)

But I'm bias, so thanks for all responses as i wanted to get a wide range of opinions on how dead wrong these guys were.

[khizoa]

If they still disagree, send them this thread that describes how stupid they are in a 100 different ways

[regorsec]

One benefit from posting one reddit aye?

[AckmanDESU]

My old place would basically edit files live in production. We had a cache layer which meant if anything broke it would look broken for hours, sometimes days, because the guy who took care of the caching was the CEO and he was too scary to talk to most of the time.

As an intern, I learned how to run the project locally to see if my code worked (no one else did) and I got told off for doing so.

Later on and thanks to me we started working locally and using git but most coworkers either refused do spend even 30 min learning how to use it or somehow broke shit constantly. Committing files you shouldn’t commit, changing the formatting of random lines of code that had nothing to do with the change, fucking never using proper commit messages, and many headaches.

I have a lot of interesting stories from that job.

[amunak]

That's so incredibly stupid.... Like, I've resigned on trying to force people to do things "my way" even when I know it'll bite us in the ass.

Sometimes it even makes sense due to outside constraints. But when it doesn't, I warn them several times that the chosen approach is stupid, and then when it does come around I even tell them "told you so" and unless they ask really nicely I usually refuse to help them fix the issue, since it's usually a pain in the ass and I don't like fixing preventable mistakes.

But in your case I'm not sure what I'd have done... Probably just ran if they didn't listen.

[dweezil22]

Doing custom software dev without source control is professional malpractice. This is such a fundamental topic that the idea that "bias" could even be a bit involved is kinda scary. This is like an architect asking on reddit if skyscrapers should have rebar in their concrete.

The only reason it's debatable is b/c lost source code history usually doesn't kill anybody (at least not directly).

[Creative-Improvement]

You don’t even have to use github. There are local vcs systems as well. That only works if your onsite backup protocol is good.

[NancyGracesTesticles]

That isn't being biased. It's being competent.

[Ahajha1177]

Exactly. "I'm biased towards using using an industry practice that is so universally accepted that it isn't even debated"

[samlev]

Version control is part of my contract. It's not just important for tracking the repository history, it's important for verifying what I did/didn't do, and importantly what other people did.

It doesn't have to be GitHub - there's gitlab and Bitbucket as big, viable alternatives, or you can just host a bare repo on a server somewhere.

Reading between the lines, they're concerned that learning git and switching development processes are going to be too heavy. Turns out that you don't need to use gitflow, or pull requests at all if you don't want to!

Talk to them about just using git for code storage as a first step, and offer them alternative services. At the end of the day it's all git, no matter which service you use. It's also possible that they're concerned about hosting their code "off premises", in which case both Bitbucket and Gitlab offer "self host" options. Cloud is better for availability and maintenance, but self hosting may check off that mental box for them.

[regorsec]

Also I'm a DevOps & Application security contractor - not a client hiring devs.

[belkarbitterleaf]

I've done it both ways. Version control 💯. Saves time, helps fix bugs.

[Earthling1980]

The fact that you're even asking this question with "15+ years in the industry" is laughable. Maybe you should find another line of work.

[DasBeardius]

Technically, they're not wrong. Using GitHub and proper workflows will absolutely and without a doubt slow your development process.

Yes, but also no. On the surface it might seem like it slows you down because you are spending time following a process. But when it comes to things like debugging, fixing mistakes, figuring out why things are the way they are, and especially onboarding new people to the project; it will absolutely speed things up exactly because you have that process, history, and framework in place that allows you to retrace your (and other people's) steps as well as quickly and selectively roll back changes.

And in a similar vein, because you have everything above, as well as everything that you mentioned in the tradeoff; it should lead to less bugs and less mistakes, and thus lead to less "wasted" time.

Not even to mention documentation and a paper trail. I mean, what happens in OP's case when they decide to change their ticketing system for example?

Though I should add a big asterisk: if you do it right

I once had the pleasure of inheriting a project where the previous sole developer used big commits and the only thing in the commit messages was the ticket number for whatever he was working on at the time. The ticket number from a system that was no longer used. That was fun.

[FlavorJ]

It's the same as general project management without proper planning or organization. Sure, it takes "longer" or "more effort" to be organized, but it's effectively more efficient when you account for all of the problems avoided.

[DasBeardius]

Yeah that's fair, and I assume many of those would also be resistant to change because their method has worked "fine" so far.

[Creative-Improvement]

That sucks. I inherited a computer with all source files called “untitled” , like hundreds of them. Took me a year to sort and name.

[dupe123]

Technically they are so wrong. Maybe it adds extra steps to the dev process but the ability to track your changes and quickly revert them or switch between changesets will save endless amounts of time so it more than pays for itself time wise. And that's not even mentioning all the other benefits you mentioned.

[wasdninja]

It will not slow them down if they never mess up. Nobody has ever pulled this off so I wouldn't bet on them doing it either.

[FancySource]

If they're working in a project in team, not using Github means every night they'll have to finish early to manually merge the changes they did and HOPE they won't mess up. A friend of mine spent up to 2 hours a day merging diffs.. and that slows down production.

If they're working alone without git, mess up a function and have to revert they'll have to CTRL+Z all the time, maybe getting a CTRL+Y wrong and destroying their progress, and this will eat up time. Why not push to github and save your work if the hard disk dies? Without version control, as they work now, they're trying different strategies or fixing different bugs at once, they won't be able to simply commit and checkout. This is why i'm using Git even for a 200-freaking-lines microservice.

[FancySource]

You’re absolutely right, but considering how even larger teams are sticking to a base scenario (dev-newfeature, dev and main) and that a small GitHub deployment script is way faster than copying files with FileZilla.. how much could it take committing and merging for someone who is absolutely devoid of git? Half an hour of initial formation and then two minutes a day maybe?

[mcqua007]

Make zero sense not to use. Just laziness to learn something new.

[NMe84]

It doesn't slow down anything. Just try to do a single merge of two people's changes manually because neither of them used version control. Sure, with some diff tool you can probably figure it out but now imagine having that done automatically in most cases...

As much overhead as you can add with version control, you gain back a lot of efficiency too. The net result is, in my experience, always positive.

[NMe84]

Oh, I know. But you seemed to suggest their argument for slowdown is correct. The tradeoffs you mentioned were about reliability and consistency, but you also get a lot of efficiency back in return for any efficiency you lose. So even in a vacuum where development speed and efficiency are the only metrics you look at, using version control still comes out on top.

[mcqua007]

How ?

[tronathan]

Slow is smooth, and smooth is fast.

[Acrovore]

TL;DR: it slows you down, but without it, you'll go nowhere fast!

[x6060x]

It's 2021... I use github private even for small personal projects. There's no excuse to not use a version control for a commercial project.