Hacker News new | ask | show | jobs
by battery423 2181 days ago
It could also mean that they are more active and creating more chaos due to more changes.

shameless and useless advertising.

4 comments

On my team our downtime is very closely correlated with how much we're working and changing the product. I'd be surprised if GitHub is much different.
Or in other words, facebook is more stable on the holidays.
exactly. Before M$ there wasn't much product movement at Github :/
I think they got out of the rut before Microsoft's involvement, but I suspect MS has allowed them to accelerate a lot of it with more investment and a more defined direction.

I've heard that for a number of years the Product org at GitHub essentially considered the product "finished", and that it did not need more features. Things like the rise of GitLab and the "Dear GitHub" letter, plus I believe a change of leadership, helped that completely turn around. Obviously that took time to yield benefits, so I think they've been in a much better place for quite a few years now.

> and a more defined direction

Except for Atom :(

That's pretty much their conclusion

> [..] GitHub has been down more since the acquisition by Microsoft. But that could be all a part of coordinated effort to be more transparent about their service status, an effort that should be applauded.

That's not a conclusion, it's a theory.
Or hypothesis.
Personally, I'd prefer some availability over sparkly features.
Not counting the redesign, there haven't been "sparkly" features. Sparkly features are the kinds of things the old management used to let engineers have free reign to implement.

Github pre-Microsoft was rudderless. They were more prone to implementing silly 3d model diff tools and things instead of supporting enterprise features or building powerful CI/CD tools and automation.

New Github is on the right track.

- Personal Status

- Round Avatars (all catgirl ears are now cut off)

- Collapsing of some similar messages on the Dashboard into one (i missed some things because of this)

- Not just one, but several redesigns (im old)

- The whole "marketplace" functionality (imitation of an app store)

- The "explore" and "trending" functionality (i see this like a Facebook feed)

Not sure about others, but i used GitHub as a git host and issue/MR tracker. All the other stuff is just distraction in my eyes.

> (a bunch of comments about the UX redesign)

I agree. I'll add one: README files with tables now require horizontal scrolling, and that's utterly disappointing.

> The "explore" and "trending" functionality

I do work in ML and computer vision, and this is how I discover all of the new models and code people are using. It's awesome.

> Not sure about others, but i used GitHub as a git host and issue/MR tracker. All the other stuff is just distraction in my eyes.

You're missing out! Deploying code is so easy once you're using CI/CD. Github actions are powerful.

Many of my projects have a fixed scope and thus are 'done' at some point. If you develop like this, CI/CD is rarely worth the effort. Its better suited for projects that suffer from scope creep or regular upstream breakages.
But before that ‘done’ point or maybe for a new project, Github Action is a good feature introduced by Microsoft.
Yeah it's only needed for projects that might change. Anything you can guarantee will never change, is fine.
changes = downtime. Has been since the advent of computing
Not if you have a competent devops team and a deployment pipeline.
Nonethless we are building and operating complex systems.

Testing something 100% has diminishing returns.

Therefore -> you will never be able to prevent all issues. As you are not aware how many changes are happening, you don't have a value which could indicate the healthiness of it.

I personally think that when i'm getting older and better in my job, i still make errors, the amount and severity is going down though.

I'm sure they have both but complex shit breaks when you change it often.
Your devops team assures software quality?

But well, no QA effort is complete enough to really assure the quality of a large system. Thus, the GP holds true.