user15672

If valid criticism is rude, we're all doomed here on HN. The parents point is valid. If you don't like it, that's fine, but rude it was not. Google doesn't know anything more than DDG, so you're just plain old wrong on that argument.

This made me chuckle, since modern Python and Java styles are very, very similar, if not identical in places, to those of 10 years ago. Some of the libraries have changed, but many are the same as well. Shoot, I can still run Python code I wrote 10 years ago on the latest version (yep, that means something originally written for Python 2.3 can run fine on Python 3.6).

And no, that doesn't make Python and Java old hat or redundant.

You are correct, Google trends is pretty much irrelevant here. You would be surprised by Gitosis (and many others you've dismissed). It's pretty much in every company I've worked in over the last 7 years. It's never well liked, but it works just fine. Most companies don't need bells and whistles that come with GUI based git installs, so they don't waste the money switching away to them.

Bitrise seem to deal with a niche market (mobile development), so claiming their study shows a general trend in the self hosted git market is a stretch at best. I'd imagine boring old git itself and non-website backed things like gitosis are still a massive part of the overall install base. In any case, the claim that gitlab's on 2/3 market share just screams disingenuous marketing fluff to me and cheapens gitlab as a whole.

They've been promising to fix performance and the UI for years now, so I wouldn't hold out much hope. It's a shame, but there are better open source products so it's not like there are no other options for self hosted.

This really isn't true and I really wish this myth would stop. Sure, if you go into the financial sector or find a startup where they don't know their arse from their elbow about software workers, you can dupe them into giving you more money. But 55k in London is a good wage for a software developer and you're definitely not looking at that if you're mid-level and working for a regular company.

Source: I've lived and worked (and continue to do so) as a software developer, technical lead and CTO in London and have been in several different sectors.

Calling the argument contrived is really rather immature. It's not contrived, it's very real and important. Please stop being so quick to dismiss those that you disagree with as it's childish at best.

You speak of cargo cult, but your entire comment reeks of it. Ok, we understand, you like being able to isolate yourself. That's nice, and I'm glad you found a niche, but it's not the same for the vast majority of jobs and people. You call other people lazy, but I think perhaps that's just you. Social interaction and moving above an intermediate level where you can isolate yourself is hard work. Don't be so dismissive of others that strive for more.

Working remotely is great for the unambitious and the antisocial. Please stop trying to put those who do more down though.

Don't see why you were voted down on this, since it's true. Slack working to get things running again doesn't mean they're prioritising your companies particular instance or region. They're likely to be making sure their own region and their own stuff is up and fixed first, so anyone away from the east coast of America is likely to get seen to after that. It would be stupid to do it any other way, since slack employees are likely affected as well and they're the ones trying to fix it. Down voting someone pointing that out is pretty fanboi-esk or really naieve.

Pretty much, if you don't own the service, you don't get to decide where in the queue you are for a fix.

I'm guessing from your posts here that you're either very naive and/or too young to have been in a hiring role.

Yes, it does indeed work both ways. Just because you don't understand this doesn't make you in any way correct.

I'm not really sure what your second paragraph means. Are you saying you job hunt while at work? That's not a professional thing to be doing. In any case, writing a cover letter is very easy, so being unable to do that probably means you need to work on your communication skills. Heck, with the amount of posts you've stuck onto HN today alone, you could have knocked up a short cover letter that would suit 90% of technical job applications, so this can't be a time problem for you.

Please, please, please get rid of the scroll hijacking. It's really horrible to use the site.

I hate to say it, but I think the answer is "with difficulty".

From my own experience, it's really hard to know what's bad, what's good and what's an acceptable workaround if you've never seen anything different. Myself, I got lucky and ended up working on a project after the start of my career with someone who could explain the whats and (more importantly) the whys of bad/good/ugly code bases.

Generally, try and get some skill in being able to view a codebase from a high level. Draw it out on a whiteboard in boxes. Perhaps do this on other, pet projects first as it's nearly impossible to do this with a spaghetti-code project. If you can't pick out modular parts, then you have a big ball of mud. If you can, try and work on making and keeping them uncoupled. If you can, try and work on finding the natural boundaries of the other code you couldn't break up, and make those less coupled (you don't need to solve the coupling problems all at once!).

Are there a mix of architectural patterns in the code? This is pretty common when you're working on a legacy project. It's what happens when you get someone who doesn't really know how to architect, or there were a bunch of folks throughout the history of the project who (probably) had the right intentions, but didn't get it finished. Or, and this is the worst, you had two or more team members trying to bend the project to their own preferences without communicating with each other. If this is the case, talk to your team, agree on one and then you can work towards getting the style consistant. You don't even need to pick the best one. Getting a project into a consistant state is better than having an ugly mix and match.

Are there a bunch of mixed up design patterns floating around? Try and refactor those out as much as possible. Design patterns are great, and you should use them where appropriate. But if you find a lot of them nested within each other, it's not a good sign and probably indicates someone at some point swallowed a design pattern book and thought it would be a good idea to implement them. All of them. Nested patterns can more the likely be refactored out to simplify the code. Though again, make sure you understand what they are there for first. Otherwise you may be unpicking something intentionally complex that needs to exist to remove complexity elsewhere.

What does the DB look like? Is it designed around the projects business logic? Is this sensible for your project? Personally, I dislike putting any business logic into the data storage layer but it might be sensible for your particular project, so YMMV. If business logic in the DB is causing nasty workarounds, then you may have something else to refactor there, though this may not be possible.

Never refactor just for the sake of it! If you don't have buy-in for your ideas on how to improve a code-base from the rest of your team, you're going to be creating problems. You may also be missing critical information that your tech-lead knows about and made design decisions based on it. There have been several times I've tried to make things better as a Junior dev, only to find out I'd made some bad assumptions and created a mess.

Don't refactor without tests either. The system may be reliant on strange code, so make passing tests before changing things. That way you at least know the behaviour hasn't changed.

Except in reality we get people who are bad at dev and bad at ops pretending they can do both