Im so tired of this guy.

How do you cooperate in programming projects?
I've been trying to work with this guy for a week now,
and every time i do something he's like "ok, i'll read your code later", and then he does his own implementation, or missuses my stuff since he apparently doesn't even read the comments i've written.

He doesn't want to work together, but rather sit at home and do his own thing.

Now we have ended up creating two different versions of everything, and he keeps changing the package names.
Im tired of this.
Should i just ditch him, or am i being a douche?

If he created it, make a fork.
Else, kick him out.

>>2

>>2

>>2,3,4,5

cooperation in programming
spilit your shit in a way that everyone can do his own shit
make the sketch 'design'(fuck I hate this word) modular enough
for the separately made parts fit together well enough

Srsly noone ever has time to read someone else's code,
most of team projects are work in a this way:
I hope the other guys aren't complete retards

>>2-7

>>11
Cool dubz bro.

>>6
Well, this is a networked app.

I was responsible for the client, and he for the server.

I tried to push for that we'd specify a protocol which apparently was hard to agree on.

Then he didn't like my client, so he wrote his own "just for testing", so im "well, ok, whatever, lets use that instead".

And then we where in each others shit, i was doing
the database code using his entity objects, he didn't like it apparently. He wanted to use Events instead of Exceptions etc.. maybe a good idea i don't know.

Now im forking and doing my own server since his version is storing stuff in memory that is supposed to be in the database.
I don't have time to re-factor his crap. Don't even know
how it works, and it's full of bugs.

>>9
Maybe you're just a shitty programmer?

>>8
thx

>>9

yeah, all these differences sound kind of petty. Maybe he thinks you are a shitty programmer. If you two really do have a disagreement over the design of the project, then you should be able to come to a unanimous conclusion about what will work and what wont, or what the advantages and disadvantages of an approach are. From there you can both decide what the best path to take is. It shouldn't be based on preference or taste, but on a list of reasons for why things should be done in a certain way.

/prog/rammer rule #1
there is one,and only one, non-shitty programmer in the universe, me.
This is what everybody on /prog/ agrees on.

This is actually a good lesson in prog related teamwork
Decide on a design before doing stuff.
So you don't end up putting Cubes in the Sphere hole and vice versa.
Altough in my experience there are programmers who like to ignore previously decided design decisions anyway.

maybe tell him this and not /prog/?