Pro tip: If you are a junior, or senior but new at the company, don't start your conversations with:

"We're doing X wrong. At my previous company we did / at school I learned /in this book I read / according to this talk I watched, the right way to do X is ..."

Instead try:

"I'm curious why were doing X this way. I'm used to doing it differently."

I love flat-hierarchy teams, and people who think about flaws in procedures and proactively try to improve the tools we use are awesome, but the next kid walking up to me yelling we use git flow "wrong" will be smacked in the face with a keyboard.

If you come to me with curiosity and an open mind, I'll explain, and even return the favor by behaving the same way when I'm baffled by your seemingly retarded implementations.

Maybe we can learn from each other, maybe discover that "how I learned it" is sometimes good, sometimes bad.

But let's start with some social skills, not kicking off into every debate with a stretched leg and a red face.

This++++++

You should print it and stick it on a wall at your work or something.

True

You use git flow? I've heard about it but haven't used it. Is it good?

Uuh, you're using devRant wro... Oh wait

Jk,++, exactly this

The way I do this is to just find out as much as i can about the current solution and then if i still think my way is better, write out a proposal that objectively states what benefits it has over the current solution.

Being more familiar with one way of doing things is rarely a good reason for a change.

@samsepiol

Git flow is an awesome model for how things can be done, but whether it makes sense for you depends on your release method.

Pure git flow works very well for games and mobile apps with releases and version numbers. For backend and devops it's often a good idea to scrap away the overhead.

Git flow is an "overengineered, perfect" solution for large active projects, and for small teams it might make more sense to just have master and short-lived feature branches, or even just a master branch! It all depends on team size, release cycle and project activity.

@tenCharacters

Yup. What newbies at the company often don't realize is:

1. There often is a reason for our odd adjustments to industry standards, because we're doing non-standard things. We're not building a to-do app, were building a large million-user platform.

2. Every company older than 6 months has legacy code. Yes, we would all love to migrate to Postgres, it's adorable that you think you can do it in one weekend, but I've already lost 4 devs to insanity trying to migrate millions of lines of backend code, I'm not going to send you in after them.

It's very tiring to start every conversation with "We should rewrite everything as microservices because that's what Netflix does".

But devs who come to me with friendly suggestions, and are open minded to a realistic conversation about realistic improvements, they get hugs.

I find this is *especially* the case with fresh grads.

"At university we were taught to comment every single line of code with a paragraph, you guys should do that"

Though that's better than just going ahead and deciding you know it all and implementing those changes, as one guy did once:

"We used Github, Github is great, you guys use some weird thing which doesn't have a web interface, I've decided to solve that for you, I've put all your code on Github, here's a link to the repo, you guys should fork and submit via PR so I can check your code is all good before I accept it"

@irene Commenting once every line is a stupid idea.

Everyone knows that's not enough. You should be commenting at least 5 times for every line. ;)

Every answer I've got to that "why" question thus far:

1. We built it like that and it grew too big before we could change it.

2. Slight variation of #1 but adding "... we are going to refactor it" (this lie has usually been told since day 1).

3. Previous dev worked alone and had very bad luck with thinking. The design is the result of a thousand brain farts woven together like shitty tapestry. This explains the code smell. Also, we are going to refactor it when we have time.

4. Herp derp.

So, my approach is to open up with something along the lines of "we're doing x all retarded-like and every minute not spent on refactoring is a huge loss in productivity because no one can make sense of this mess except for that one guy who has stared into that abyss for way too long and it shows. Our Bus Factor is 1 and just thinking about the code might be enough to give me an aneurysm. Btw my name is ihatecomputers, I don't think we've met."

A lot of practices are objectively wrong; people should be direct in communication.

*this* I’ve just started a new role and they’re very old school, only just now getting used to things like Linq, certainly no unit testing experience really, and definitely nothing as exotic as mocking.

I’m going in with an open mind, explaining how it’s all a matter of exposure as opposed to “better”, the best thing is that they *know* their way isn’t great, but they’ve never had the time / expertise to guide it elsewhere.

So I’m pretty excited.

Well said my dev

@varikvalefor

There is a difference between being direct and being borderline hostile though.

I think if you've worked for a while at a company and know your coworkers, you can drop some of the social etiquette without looking like a toxic little shit...

... It's just that I have to deal with kids who read a blogpost about React and start screaming at me that we have to ditch Vue, or yell about Uber/AirBNB/Google/Apple/etc having pink toilet paper so now WE MUST BUY PINK TOILETPAPER.

And then there are all the little shits who keep trying to push THEIR linter/stylefixer configs and tooling, because their previous company used a line break where we don't.

Followed by a backend newb storming into my office "we have to use Mariadb because MySQL sucks" after which another comes in "NOOO we must store it on AWS"!

I'm a reasonable guy. I don't mind switching to better technology, if there's good arguments. I'll even defend it to product owners, I always prioritize infrastructure improvements and bugs over features.

But "Google uses it" is a shit argument. Even "It's faster, cleaner and provides free oral sex" is just empty words. "We should do"... Ehhh no, there's probably no "we".

I'm an old, bittersweet Tech Lead.

A well-written paragraph of research, both pros AND cons, maybe even a preliminary test implementation, works so much better than yelling that you know everything better.

In the words of Torvalds: "Talk is cheap, show me the code!"

Me 2 years ago when I joined the team: you should prioritize reducing the technical debt, the code is shit.

Boss recently to the whole team: we need to clean up the code and increase test coverage to improve stability and move towards a weekly automated release schedule.

I would love to ask questions like that, IF I HAD SOMEONE TO ASK THAT IS.
I'm a junior backend developer and my company decided to fire the other 2 backend developers after 3 months of me working there to save money.
They didn't even say a word to me about them leaving.

@WinterCore

Well fuck... that's annoying.

Let books & courses be your senior. If shit needs changing... at least you can say "Listen, I'm the lead backend dev, I decide how to implement it" 🤷‍♀

@bittersweet You're right.
I'm the one who ends up making decisions, but I always feel guilty and not happy with half the code I write.
I always question myself "is there a better way to do this" and sometimes I know that there are better ways but I just don't know how.
I started programming about 3 years ago and I still have a lot to learn.
I've been thinking about looking for another place that has senior people and a proper team leader, and I don't care about whether I'll be working or interning there.
But I'm scared that I might regret that decision.
This is my first first time working at a company.

@WinterCore For you personally it might indeed be better to move, it's good to have people you can learn from, or who are at least at equal level so you can brainstorm together.

When you think "this is not optimal" about a part of the code, that's totally fine. Try to isolate it a bit, write it as a "module" which can be replaced easily. That's a good idea for all code, but especially when you think you need to replace it later.

there's an old fuck on my team that criticizes actions we take by saying "IN MY OLD TEAM WE DID BLAH BLAH BLAH AND DIDNT DO BLAH BLAH BLAH"

@vlatkozelka There are situations where it might be better to move. The alternative could be to write an improvement, and push that in their face.

True, I realize I have some of those symptoms after reading your post. Lesson learned! Thanks, dude!

I opened up to juniors, I listened, I explained reasons, pros & cons of refactoring, technical debt, business goals.

They persuaded me to rewrite everything using best practices, I finally accepted. After 5 months into rewrite, they left.

Now I have more interesting things to explain to new juniors.