|
Super Lloyd wrote: 2. ... And his way is better, there is no need to talk about it!
Just remind him from one of those egoless programming commandments[^].
Code horror wrote: No matter how much "karate" you know, someone else will always know more.
Wonde Tadesse
|
|
|
|
|
|
4!!
He does that often. Not consult. break other people's code once they are done.
Half of the data is then missing but he replace it by a nice "not implemented" string! To show it's the newer better version!  
|
|
|
|
|
I thinks he need all commandments. May be it's better to email him the whole points.  He might get a relief.
Wonde Tadesse
|
|
|
|
|
I must give him credit for his enthusiasm over patterns. He strikes very much the same characteristics of my brother. (who is classified as a super developer) I've also heard someone give the exact same criticism about his work. (sometimes implement complex solutions to non existent problems... to refractor this I'd say complex solutions to problems to which a simple solution can suffice). He admitted to this flaw (seen by other as one), but also added that in order to better himself/his skills, he had to practice them. Today he uses patterns by nature... You tell him about a certain design problem you have, he responds with aaah, use the X pattern to solve it. What he has become as a result of this attitude is a master problem solver, no really... I work in the same company as him although in a different province, our company is an international company. He's is well known throughout the company, both locally and internationally as the best c++ developer we have, and more specifically the best problem solver... to the point where if any major software/system problems arises, in whatever project, he is the one that gets called up to find the solution.
90% of c++ developers when trying doesn't understand his code, unfortunately. And in understanding, I don't mean that it is ugly... Its just, his knowledge of the language is miles ahead of 90% of c++ developers. And it is the first time in my life that I've seen that too much knowledge of something can be a disadvantage to some degree... He recently join another company where he has no name and is working for a new boss and with a new team... He had to downgrade his style of programming before they would accept any of his code he written for them... They didn't understand his code, and because of that didn't want it in there source base. He says to me that his new challenge is to write code as he's done in the past but, to make it a bit more simple/understandable to the regular c++ developer.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
Don't worry that not the case here!
At least I must give you he is very good at reducing the productivity and increasing ignorance. Now no one has any clues about what they should do, we rely on our old spec to do the screens... 
|
|
|
|
|
lol, ok. 
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
R. Erasmus wrote: 90% of c++ developers when trying doesn't understand his code, unfortunately.
Sounds like he uses crappy naming conventions. Even complicated C++, if well named, should not give 90% of developers difficulties.
|
|
|
|
|
If you read and took in anything what I said, you would realise that the comment you made was not well thought out. Directly after above sentence you've quoted I specify "in understanding, I don't mean that it is ugly". To answer your speculation, his naming conventions is not crappy at all. It's is better than most. I have to admit, I have not gone into the effort to calculate the statistics of developers that doesn't understand/or have difficulty in understanding his code. I merely took an rough estimate from feedback or talks I have had with people that has worked with him.
P.S. Go troll somewhere else.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
modified 30-Jun-14 7:39am.
|
|
|
|
|
Sorry you think that's trolling, but it is a fact: if 90% of all programmer's can't (or 'won't') read it, it must be ugly in some way. And that way isn't imposed by C++ itself.
Happy coding!
|
|
|
|
|
Firstly:
In my books if it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
Secondly:
You're changing the word I've used, 'understand', to the word, 'read'. These words have completely different meanings.
I repeat: if it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
R. Erasmus wrote: 90% of c++ developers when trying doesn't understand his code, unfortunately
Obfuscated code isn't anything to be proud of -- its unmaintainable by others. He can't be that much of a super developer if he doesn't explain what he's done to others.
R. Erasmus wrote: He says to me that his new challenge is to write code as he's done in the past but, to make it a bit more simple/understandable to the regular c++ developer
Kudos to him.. when he masters this aspect, then he will truly be a super developer.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Actually I think there are 3 kinds of super-developers:
Those who are capable of writing ultra-hard code to solve ultra-hard problems;
Those who are capable of writing ultra-easy code to solve ultra-hard problems;
Those who are capable of writing ultra-hard code to solve ultra-easy problems.
Well... actually the first and the last may be the same. Some developers are really good with complex thinking, so they don't see any need to make things simpler and they end-up making everything complex.
But to me the real super developers are those of the second category. In a team, they are the ones that must write the code to solve the hardest problems, yet after the solution is written, the other developers are capable of understanding what's happening and are also capable of using the created classes/methods with ease.
|
|
|
|
|
I agree with you here... I think he would probably be classified in the 1st and 3rd category you've mentioned and trying to move into the second category due to being forced to do so because of circumstances.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
Super Lloyd wrote: I think I just understood the origin of an urban legend where some developer are allegedly 100 times more efficient than others!
Sackman Erikson and Grant (1968), "Exploratory experimental studies comparing online and offline programming performance"
according to this[^] it was about measuring batch vs. interactive; found a 28x difference "best vs. worst" - which is a pointlessly useless measure Sample size: 12 programmers for an afternoon. 
Followup study used 54 programmers for up to an hour.
|
|
|
|
|
Haha, thanks for the erudite correction! ^_^
|
|
|
|
|
As a manager, I am forced to asked:
- Where are your rules of engagement (open communications among developers)?
- Where are your coding standards?
- When do you meet to do Code Reviews?
- What are considered Must and Optional points of contention in the code reviews?
In our environments, the group would start pointing out, upon reviewing his code changes,
that he is being over-zealous, and no longer adding value (Typically after asking WHY he made
those changes, and what was the loss of continuity to the other developers).
Whenever someone new joins the team, we have MORE code reviews. In fact, I usually setup DAILY
code reviews of their changes with the most Senior people, and they sit in on the Weekly code reviews
to comment and learn the process. It typically takes 2-4 weeks for someone to come up to speed. After
the first week, we do PRE-COMMIT code reviews... And when they go a decent period with out a "revert and
try again", then the leash is loosened even more, but they are encouraged to discuss best approaches with
others.
This creates a TEAM OWNERSHIP of source code environment, which helps reduce the ONE EGO knows best
Good luck with it.
PS: Since this is a lead, and it is already down this path, I would do a private meeting and simply explain the situation... "Hey, I love how committed your are to the code, but I think your overstepping a bit, which is
coming off as disrespectful to the other developers, myself included, and I fear that if it continues, the attitude will become to write LESS QUALITY code BECAUSE you are going to rewrite it after we commit it anyways. Before you got here, the team ownership felt different, and I think we would like to find some middle ground, if you are interested?"
Their response will tell you everything you need to know!
|
|
|
|
|
We do no code review...
We do kind of peer programming but we both (us 2 original developers) gave up on programming with him or asking him for any sort of improvement as it leads to nothing but you are wrong you will see...
|
|
|
|
|
The other programmer has good contact with the PM and will ask for a code review when she comes back....
|
|
|
|
|
Quote: PS: Since this is a lead, and it is already down this path, I would do a private meeting and simply explain the situation... "Hey, I love how committed your are to the code, but I think your overstepping a bit, which is
coming off as disrespectful to the other developers, myself included, and I fear that if it continues, the attitude will become to write LESS QUALITY code BECAUSE you are going to rewrite it after we commit it anyways. Before you got here, the team ownership felt different, and I think we would like to find some middle ground, if you are interested?"
Their response will tell you everything you need to know!
I will ponder those words! ...
|
|
|
|
|
People of the type "it's my way or the highway", especially when they love unnecessarily complex solutions, are always a burden for a team, I would look for a way to get rid of him, as it will always drag your team.
|
|
|
|
|
Yesterday i suddenly realized i have been thinking about a possibly dead cat in a box for 25 years now.
In my front yard i have a little pond with 2 fish in there.
But sometimes i don't see them at all for months, and sometimes i see only one.
It is just a tiny pond.
So maybe quantum mechanics isn't about cats but about fish.
Or are they just better at this?
|
|
|
|
|
Depends which fish they are.
Have you heard of Ghost Koi[^]?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Try putting a cat in the pond with them -- cats seem to have a good handle on this whole quantum mechanics thing.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
borchef wrote: But sometimes i don't see them at all for months
Maybe sometimes you don't look at the pond for months? 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
