They maybe have the same human brainwaves; but they can’t be the same because each programmer is unique (unless that programmer doesn’t think and relies only on someone else who knows how to implement a certain feature).  Although at some point their respective codes will look similar with one another, still as a whole their individual codes can’t be the same because each programmer has his or her own coding style.

If a team of programmers are working on the same project and have decided that one of them will work on a certain module and the others on other modules then they will surely speed up the development process.  If they initially agreed to use a certain framework for the project, then they should be using the same framework throughout and not the framework that another suddenly decides to implement.  It is also best if they brief each other on the various modules that they individually created so that nobody is left in the dark about the features that each of them did.
If you happen to be part of a team of programmers it is usually a good idea not to brag about a certain feature or skill that you can do if you can’t really implement it in the way you just described.  Parsing a text file can be done, and should be done using a script.  It’s not bad to take someone’s advice if you’re having a tough time implementing a feature (or performing a skill). It’s also not bad to take good advice to pass on features that you’re not confident about or have enough knowledge to implement. 

I personally don’t accept projects that I think I can’t finish within a given time frame required by a client.  When a client asks for the time frame I always take into account a reasonable period for adjustments to make sure that I won’t screw up the project because of delays.  You see, you never know when something might go wrong along the way and that usually is the cause of project delays.

Probably the worst thing that one teammate (if you’re part of a programming team) can possibly do to another teammate is when the former reports that a certain feature was implemented without giving proper credit to the latter who worked on the feature or module.  It is right to let the client know that a certain feature was implemented but if you’re not the one that implemented it and you don’t give credit to your teammates then the client will think that you are the one that developed it and that’s really unfair to the person that implemented the feature.  It becomes even worse if your not the team leader because you are by-passing someone’s authority.

Every programmer has an ego and some can’t live without it; but if you’re not working alone on a project, then you should forget your ego or, better yet, flush it down the toilet.   Your ego may just hinder the development of the project and, instead of you being an asset to the group, you’ll become a liability and that’s not good for anyone.  Nobody wins when the client backs out because one colossal egomaniac caused delays in the development of the program.

So, if you are working with a team and you don’t know the whole nature of the program you should give way to someone that has and learn from him or her.  Graciously accept suggestions that can help speed up everyone’s jobs even if it’s just for the sake of the team.  Leave your egos somewhere else and don’t bring it with you when you start working on programs.