Dev anons, how do you deal with bullying at work? what do you do when someone says your code is shit? no logical...

Ask them to elaborate. Explain what they mean and give examples.

Start a #StopCodeOppression campaign.

This, and if it doesn't stop
This

>i'm thinking "too much into the future"
You're prematurely optimizing your code. You just cannot predict what the future will hold, what's gonna be the next step from sales, C-level executives, etc that could drastically change the direction your software is going. You're wasting your company's resources, time and money by doing this. I'd also bully you for this.

I would say you're in right, but it still sounds like good idea to consider less skilled colleagues who need to interact with your code.

Still, don't let them bully you.

Attached: boy trapped in.jpg (900x583, 478K)

Stop being a faggot. Either you step up and take charge or you do it the way your boss demands

Do you pair program with them, user? Brainlets often can't into generics unless someone holds their hand through a few implementations.

is this a real life

Sounds like people are trying to give you constructive criticism. You should try to think critically about what they are saying and how you can use it to improve the code that you write. Everyone can improve the code that they write, dont imagine youre some code god with perfect code or something.

The world is against you. Socialize harder and train your social skills. Become machiavellian office politics king.
When commented on, turn it around. Plant seeds of doubt in their head. Steal their flame away. Put out their fire. Cause depression.

How do you find the line between situations where proper answer is "Ah, i see, i will try to do better" and "fuck off and get on my level, kiddo".

Next time they say something negative pull down your pants and start shitting while maintaining eye contact

move to california

I'm the bully.

Also I make sure the code is as autistic as possible. So you'd never think too much into future or use too much genericity. I even rewrite whole subsystems in my free time if I came up with better solution because of my OCD. I also asked to assign all PR to me so I can make sure everything is perfect.

This. Make sure you do it on a public channel.

Attached: 85e.jpg (764x551, 263K)

i see it as ensuring that the product will be ready for that unpredicatble future by being generic enough to modify it at low cost. i see it as being against technical debt.

example that will probably identify me if any of those fuckers browse Jow Forums:
protobuf is used to define protos between two message passing components, req-rep clientserver. there are:
- definitions of actual messages
- definitions of client-tx, client-rx messages with appropriate server-rx, server-tx (so client-tx -> server-rx & server-tx -> client-rx) that import the actual messages and wrap the appropriate messages in a oneof.
so it'd be like:
message sub_req {...}
message sub_rep {...}
message notify {...}

message client_tx {
oneof type { sub_req sub; }
}
message client_rx {
oneof type { sub_rep sub; notify noti; }
}
message server_tx {
oneof type { sub_rep sub; notify noti; }
}
message server_rx {
oneof type { sub_req sub; }
}

i was told this is unnecessary duplication. i believe it's not, because:
- it ensures that client uses client-type messages, server uses server-type messages
- the type names allow one-glance identification whether it's client or server code
- decoupling of client-types and server-types allows later insertion of an intermediary between client and server that will modify the messages type (not just conent), with minimal disruption of existing code-base
- the actual messages are not defined twice, just imported into almost zero-cost wrapper, that will generate an union anyway.
- it just looks goddamn nice to me

Write less shit code, don't overabstract

also using oneof when there's only one message ensures that unpacking all cient- and server- message types looks the same, and if i wanted to add another message type to the oneof, it would oly require minimal code changes.

don't think that would work
to show your dominance, instead, try pulling down your pants and start beating your monkey

Think with the management's head. Technical debt doesn't exist in their mindset. What usually exists is "Is this a new feature we could sell for more bucks?" or "Does this bug serious enough to hurt customer retention?". When you're refactoring or overengineering stuff you appear to wasting time in their eyes. Ship the minimal viable solution they ask for and try to smuggle small fixes along the way.

I don't think beating his coworkers will solve OP's problem

They sound jealous and stupid. Just code their style and watch it fall apart quickly.

I get all angry and stop being cooperative.

Attached: nobully.jpg (210x230, 11K)

If their criticism has genuine merit then you try to do better. If they tell you that you dont need to free up memory after a malloc then they can fuck off. Sometimes this involves discussing: "well that implementation has x tradeoff while this implementation has y tradeoff. What are we trying to optimize?" Many things in programming are about tradeoffs, and you have to figure out whats best for a given situation. Either way, having functions that are too rigid is definitely not good, though it may serve small purposes here and there. At least consider what the person is saying, think about how to rewrite it in a way that averts that problem, and use critical thinking to ascertain whether that is better or not.

Oldanon here. Bully programmers are simply bully. They are doing it not because of your program but because it gives them a hard-on.

If your code is (a) functional (b) appears to be bug free or close to it (c) meets deadline then tell the bully to explain exactly the problem or shut the fuck up. If they don’t like the code then fucking call them out on their bullshit and make them explain, in hair splitting detail, the problem. As they explain the problem as they see it make sure they are clear, no weasel words or bullshit. Every time a weasel word comes out, question it in patient detail. This constant wearing down will make them look like the incompetent assholes they are. More often than not it comes down to (1) they are hiding how fucking incompetent they are or (2) their shit is waaaay overcomplicated so they can protect their job I.e. “you need me because I’m the only one that understands how stupidfuckingfunctioncall() works.

Be patient. Be calm. Question everything. Stand your ground.

how do i know when my shit is overcomplicated and when it's just very good?

Have you explained your position? Have they explained theirs? If all they said is "unnecessary duplication" with no reasoning then ignore them. If they have a counter proposal, or a thought why it is too much duplication, then it is worth thinking about -- though who knows they may still be wrong after all.

Are the things you are futureproofing into your code ever going to come to fruition? Are you worried about x when you should be worrying about y? If you spend time making sure something works, but that thing never ends up being used, it was wasted time. If you only need one way communication but code for two way, and that extra code passes some threshold of time it takes to develop, then its overcomplicated.

many junior like yourself like to write convoluted code instead of simplifying and augment maintainability, since they only have short term vision

in the long term or big companies the code your write will most likely picked up by other people, which will have to unveil your 1 liners and lose hours to maintain your shit

follow the advice of others and start working like you're in a team, you're not in your basement anymore kid

cry to hr like a bitch you are

how the fuck is code bullying real
just close your ears

What you've basically done is say "The server speaks English and the client instead speaks American. They're basically the same."

I agree with your coworkers. This is bad design.

>- it ensures that client uses client-type messages, server uses server-type messages
The point of a protocol is to speak the same one.

>the type names allow one-glance identification whether it's client or server code
If the client and server is using DTOs as business objects then the code is doubly bad. If it doesn't, only a tiny bit of the system will refer to them

>decoupling of client-types and server-types allows later insertion of an intermediary between client and server that will modify the messages type
If you want to change the type, you'll have to change the client and/or server anyways. Unless it's transparent to both, in which case you've gained nothing.

so...

>what do you do when someone says your code is shit?
You listen to them because it is

Paraphrasing what I was told and follow:
Simplicity, strait forward easy to read with the simplest approach. Make what's necessary not what you imagine may be needed sometime.

holy shit
was getting bullied part of your plan?

i see it that the point of a protocol is to define your input and output.
for me it's easier during implementation to think about the messages from the point of view of a single entity. when i debug and i see a message called client-tx i immediately know that this part of communication is uplink, etc.

the names are meant to be meaningful and descriptive.

Offer to remove them from the project, for their sake. In fact, maybe they can be removed from all future projects. You're the lead, stop being a bitch and put your foot down.

also consider that i may have a server talking with two entirely separate types of clients:
message client1_tx {
oneof type { sub1_req sub; }
}
message client2_tx {
oneof type { sub2_req sub; }
}
message client1_rx {
oneof type { sub_rep sub; }
}
message client2_rx {
oneof type { sub_rep sub; }
}

message server_tx {
oneof type { sub_rep sub; }
}
message server_rx {
oneof type { sub1_req sub1; sub2_req sub2; }
}

server speaks english, clients are american and british. separate client- and server- types allow easy extensions of that.

>you think to much in the futurr
It only appears that way to short sighted individuals
>your features allow a lot of genericity but are hard to use
only for someone who doesn't keep up with the industry

Always turn it around so it is a failing on thier part, in a way such that facts are never used in conversation.

Finally, here is your golden atomic weapon of a conversational response: "so you keep saying"

Once people start repeating their complaints, your response of "so you keep saying" makes them look like low intelligence whiners. Use this phrase as often as possible.

>i may have
If you don't have the problem, don't try to solve it. You're speculating.

it's not purely theoretical problem. i don't know because we wren't given time to explore the problem space, but i can imagine it pretty easily.
i prefer to think of a solution now and write more flexible code now instead of dealing with technical debt at 4 in the morning on a saturday, management be damned.

>i don't know
>i can imagine
This is the literal definition of speculation.

i don't *know for sure* because of stupid deadlines. but i *know enough* to be able to imagine such scenario being needed.

This is the best post in the thread.
Too bad op is too retard to understand why.
Ive used this simple trick to win many arguments,its basically throwing the ball in their court and putting them in difficult position.
If they don't have a comeback you win and if they have a comeback you just walk away and you still win by ignoring them lmao.

>separate types of clients:
once again, the point of having a protocol is following it
a different client would not send a different type of message. If identification was required, it would communicate it's type through part of the message.

Did you code break something? Did the tests fail? Did it work fine? If you code worked and didn't cause problem, who cares? If your code didn't work, then you're at fault and should fix it. Stop being an autist who cares what other people think of him.

>too generic
Tell them off like the brainlets they are. Generic code is good code

Unless it doesnt need to be generic. For example, it is not necessary to make a one-off script robust and generalized when there is no business use for further application on the script; any time it took generalizing the code would be wasteful to the business if the problem could have been solved trivially if focused on a specific use case.
It is quite easy to overgeneralize in programming. At some point you have to make assumptions about input/output etc

So then any new type of client requires something new? Why not just pass in the type as part of the metadata

I once generalized the code so much, that we used it as a boilerplate for all future projects.
It's nice that my boss is an exprogrammer and lets us have fun with the code.

Collect evidence of their failings, compile them into a PowerPoint presentation and display it in public as they watch.

If you're a junior, shut up and learn to code.

If you're medium, find a Medium article that supports your solutions and raise a discussion. Talk it over, listen, find the best way to do it.

If you're senior tell them to fuck off. Unless they run crying to your management and then the management tells you to change your way. If that's the case, tell them to fuck off but actually fuck off yourself and find a better job that will value an experienced dev more than some crybabies, simultaneously watch your old company crumble.

Seriously, in December I left a company because juniors kept crying to the management that I don't accept their merge requests and "bully" them in code reviews. After months of trying to educate them why things should be done differently, that they're not supposed to make merge requests that have hundreds of lines, shouldn't refactor or fix things that are not in the scope of a task in the same MR, I gave up. The management valued juniors more than me and preferred the fucking feature driven development over quality and future proof codebase, so I left. This month I've heard they're not around anymore because their main product bombed hard. Good.

>The point of a protocol is to speak the same one.

You don't think there's information the server can return to the client that the server has no reason to accept from the client and vice versa? Both the client and server will know about both versions because the version they don't need to send they do need to receive and understand.

>If it doesn't, only a tiny bit of the system will refer to them

But it will need to refer to them, so they will need to exist. So what's the problem?

>If you want to change the type, you'll have to change the client and/or server anyways

Or use a pipeline system. Also, isn't the entire point of protobuf that old types of requests can be translated into new types of request so that you don't have to maintain code to serve every version of a type of request?

>I agree with your coworkers. This is bad design

Api versioning with separate request and response DTOs is the only sane way to maintain an API that changes over time. This is bog fucking standard for anything other than hobbyist projects and school assignments. But I guess I forgot I was on Jow Forums.

Attached: 1503065833425.jpg (700x643, 63K)