I should not give high expectation on the abilities of software programmers?

[stereomatching]

When I was a student, I believe that most of the software programmers of every software companies must be
very talented, brilliant, skillful and much more experience than me, at least before I got my first job,
I really believe that every software companies could let me learn a lot.But now, when I look at the source
codes of our company, I really believe that there are some(or a lot of) programmers don't even have the
abilities to write a simple fizzbuzz program.

This post would introduce some horrible errors and many less efficient codes of our companies,
I post this because I feel frustrated and agony since our codes are flooded by the "weird codes" I list.
And I would like to know that--am I asking too much on the abilities of the programmers?Are those weird codes pretty
popular between c++ programmers?To tell you the truth, most of our directors don't
think these kind of codes are weird, not only that, they keen to produce them.

I only have one and half year experience on C++(including 4 months of working
experience).

Maybe they are not that bad, if I give any wrong comments on those codes, please correct me, thanks.

[stereomatching]

I only post some of the weird codes(please correct me if they are not
weird) for now.

Weird codes 0 : pass std::string by value instead of pass by reference without any reason

void kkk(std::string data)
{
//blah blah blah
}

void weird_func()
{
  std::string weird = "idiot";
  kkk(weird);
}

Meaningless and expensive, it is acceptable if they want to construct the data directly like this
(rvalue reference may give us another choice)

void meaning_func()
{
  kkk("hehe");
}

[stereomatching]

Weird codes 1 : Don't use boost::any + typeid + any_cast + if...else to instead static binding when static binding could solve the problems.

void kkk(boost::any& data)
{
  if (data.type() == type(weird)) 
  {   
    //call any_cast blah blah blah
  }  
  else if (data.type() == type(very_weird))
  {   
    //call any_cast blah blah blah
  }      
  else if//blah blah blah
}

just do it like these

void kkk(weird &data)
{
  //blah blah blah
}

void kkk(very_weird &data)
{
  //blah blah blah
}

Later one are much more easier to maintain and more efficient, boost is good, please use it wisely and don't abuse it.

[stereomatching]

Weird codes 2 : Please use new and delete instead of malloc and free at least you make sure you need malloc and free.

struct kkk
{
  std::string temp;
  std::vector temp2;
}

void dont_do_this_please()
{
  kkk *buffer = (kkk*) malloc (sizeof(kkk));
  memset(buffer, 0, sizeof(kkk)); //extremely dangerous and meaningless
}

Please make sure you know what are you doing about when you want to mess with those manipulation of low level, please call placement new instead of applying memset on non POD, I am very "lucky" to discover the codes like these(lingering in our codes more than one year), and "none" of the directors and seniors know these codes are dangerous, how could this be? Is this a popular phenomenon of the software companies of Taiwan?

Don't find any excuse or pretend you are innocent if you write something like this, don't shoot
your or your comrades foots(produce by our director, a "senior C++ programmer", suxk).

[stereomatching]

Weird codes 3 : We don't need the smart pointers to handle the resource of std::string

void kkk()
{  
  std::shared_ptr temp(new std::string("ooo"));
  std::cout<<*temp;
}

The resource of std::string would be handle by itself we don't need to use std::shared_ptr to wrap it again

void kkk()
{  
  std::string temp("ooo");
  std::cout<<="" pre="">
}

[stereomatching]

Weird codes 4 : use object to handle the resource please~~~~~ Instead of writing

struct kkk
{
  weird *i_am_weird;
}

please leave the resource to different smart pointers

struct kkk
{
  //or boost::scoped_ptr, std::unique_ptr
  std::auto_ptr i_am_weird;
}

[stereomatching]

Weird codes 5 : Please use boost::scoped_ptr, std::unique_ptr or std::auto_ptr instead of std::shared_ptr if you don't need to share the resource

void waste()
{
  std::shared_ptr weirdd = std::make_shared(weirdd);
  weirdd->go();
}

just use cheaper smart pointer

void dont_waste()
{
  std::unique_ptr weirdd(new weird);
  weirdd->go();
}

[stereomatching]

There are no doubt that why there are so many c programmers would believe
that the codes produce by C++ are big and fat. Because there are too many
weird codes produce by C++ programmers.

I only work at this company 4 months and I am trying to find another job, I
really really don't want to look at those weird codes and fix them again and again.
How could you design a good software if you don't care about fundamentals???

The codes I posted are just "a few of" them, there are many of them I haven't listed.
I never expect I could work with those beautiful codes like sgi stl, yet I never expect
that the codes could be so...weird.

Those seniors told me the codes have many factors of "history", every line have their
"meaning", but when I ask them--those seniors of our company, they know nothing and have
not ideas what is wrong with these codes.

[WaltP]

You have 4 months of experience, therefore you need to use these programmers as learning tools. If you see something weird, take it to them and ask them why. Use it as a learning tool. A few things can happen:
1) you learn why they did it and you see why your idea was in error.
2) they learn a better way to do something.
3) you both learn that there is more than one way to do anything.

Be sure you go to them expecting to learn, not to point out how dumb they are.

[deceptikon]

Those seniors told me the codes have many factors of "history", every line have their
"meaning", but when I ask them--those seniors of our company, they know nothing and have
not ideas what is wrong with these codes.

You're treading on dangerous ground. It's very important not to think of yourself as superior, because there's nearly always a reason behind the way code is written. The reason may be forgotten, but there was almost certainly a reason. One day you'll be on the receiving end of a bad situation and discover that your own code becomes weird. ;)

In an ideal world we would write code following best practices, but in the real world there are compatibility issues, and deadlines, and any number of factors that decrease the academic quality of our code that armchair critics looking on after the fact won't see.

[stereomatching]

Be sure you go to them expecting to learn, not to point out how dumb they are.

It is what I am always doing, I post them because I already fix it and they
agree with my ideas(there are still many of them)
I am extremely shock that they don't know what I was
talking about before I explained to them, are they cease to study after they graduate?

One day you'll be on the receiving end of a bad situation and discover that your own code becomes weird.

I will be happy to learn from my own faults.

but in the real world there are compatibility issues, and deadlines

No matter what, case 1 and case 2 are totally unacceptable
We have too many codes design by the way of case2, do you know the response of
the seniors who design something like these after I ask them why?Because they don't know
the different between overload and override, they also don't know overload
could be binding at compile time.
And they claim they have 5 years or even 10 years experiences.
Could you believe that a senior C++ programmer don't know the different
of overload and override?And those programmers are in charge of the
framework of the projects?

What I could learn from this company is some domain knowledge,
how to use some software to speed up the speed of developing,
like SVN, google-test and so on.

The most serious problem is, I find out that many of them don't care about basis,
only care about how to find a new tool to help them solve the problems.

[mike_2000_17]

Most examples that you posted were indeed bad style, wrong and/or inefficient. As for the weirdness of it, generally, straight-out weirdness usually originates from Frankenstein code, meaning that the code is often the result of piecing together inharmonious codes and/or the result of trial-and-error where a previous version used to require a particular thing (like using a shared_ptr instead of a unique_ptr or auto_ptr) which is no longer relevant or useful in the "final" version.

Now, of course, as WaltP said, some code might look alien to you, but that doesn't automatically mean that it is bad. There could be a justification that you don't know about. Certainly, AFAIK, this is not the case for the examples you posted. So, you should always question these things with an attitude that welcomes the "seniors" to teach you something new. However, that doesn't mean that you should accept empty arguments like:

> "there are historical reasons for doing this": historical reasons are not good reasons to justify a particular programming pattern, at best, it can serve to justify not changing something too much. Like if you had an old house that was partly damaged, you wouldn't destroy all that is left just because you could re-build it all with better materials and techniques, you would instead do a good job of fixing the damages with good and new materials and techniques and leave the rest as is. In other words, historical reasons don't serve to defend methods that are old, obsolete or just plain wrong, it only makes the case for preservation and restoration, as opposed to destruction and reconstruction.

> "I can't remember it just now, but I'm sure there's a good reason for that" (basically the argument deceptikon makes): Assuming there was a good reason behind it, then they should care about remembering it and should be willing to spend some time analyzing the code to find out what that reason was (if they are not willing, then they are lazy slobs, programming skills have nothing to do with that). If there was a good reason then, there should still be a good reason today (unless it has become obsolete), and therefore, you should still be able to figure out what that reason is today (hopefully with the help of those who wrote the code in the first-place). If you fail to find a good reason, and if the "seniors" fail to find a good reason, then, in my opinion, the most likely is not that they forgot it, but that there was no good reason to begin with (or the reason wasn't that "good"). This argument from senility is basically a way to say "I cannot believe or admit that I was wrong before, so I'm gonna pretend that I was right but forgot why". It's an argument from authority, and thus, it is not surprising that its main objective is not to get to the true justification of the piece of code, but rather to preserve the authority of the person making the argument (not admitting it was wrong or sub-par).

In the last several years, I have often looked at code that I had written some 1-2 years prior and found it to be really horrible, wrong, bad-style, wasteful, ignorant, ineffective, etc. etc. Not only is that a sign that I'm actually getting better and better all the time (which is great!), but it is also a sign that I am humble enough to admit having written rather ugly stuff in the past, and that I am rational enough to cast the same shadows of doubt and critical inquiry on my own code that I would on others. And that, I would argue, is critical in taking your programming skills over-the-top, much more so than the amount of years of experience or accumulated knowledge. If you find you colleagues closed-minded to questioning themselves, don't be surprised if their level of skill seems vastly under-whelming given their experience.

So, I disagree with what deceptikon seems to imply (using the empty argument from authority explained above). Surely enough, you should not approach anyone with the attitude that you are superior and that you set out to prove that they are dumb. However, you shouldn't approach it from the opposite angle either (as deceptikon implies, nor should you abstain from inquiry on the basis of "they know better than me"). The approach to take, in my opinion, is that of free inquiry, that is free of bias towards yourself (proving you are right), and free of bias towards the authority (letting them get away with empty arguments to save their own facade). You seek to find the justification for a particular piece of code, and to do so, the first place to go is to the one who wrote it (not to prove him wrong, but to inquire!), then to those who might have more experience than you do. But all through that process, you are the inquirer and as such, you should question everything that is either unclear or fallacious, and demand evidence when needed.

Of course, in the real world, you might not have time to do all this, and you can't spend all you energies proselytizing good programming practices. People might also get fed up with your inquiries if they are too much, especially because some people rather dislike being challenged (generally, because they take it personal and adopt a defensive stance on any challenge as if it was an "attack" on them). With some people, whatever attitude you take, they will never accept to be challenged, and at the end, they will be the biggest losers, pity them, in 10 years they still won't know the difference between overloading and overriding.

Another nifty way to approach this situation is to propose code in the style that you consider to be better while almost ignoring what was previously done (which is a bit hard), and that will require the "seniors" to get proactive about giving reasons why your approach is bad and why theirs is better. Now, they won't feel as threatened (i.e. you are not explicitly criticizing their approach, you are proposing another one), they will come at you with a superiority complex (or shall I say "seniority" complex), and if you have solid and valid arguments in favor of your approach and evidence that it works well, then they won't have a leg to stand on. And if they actually have a good rationale for their approach, then you will learn about it, and be prepared for that to happen as it might, and welcome that situation if it occurs. This "role-reversal" technique can be very effective if it seems like the normal thing doesn't work.

If you want to be a little bit manipulative, you can also propose changes that you know are not much better than previous ones (but that shouldn't be obvious at first) and let the seniors tell you why their approach is better, and embrace that "new" lesson you learned. This somewhat dishonest tactic can, ironically enough, help to build a relationship of honest and rational discussion about programming issues between you and your seniors. They have to know that what matters to you is the truth, i.e., the true justification for a piece of code or design pattern, and that you are not there to stur the waters or prove that you know better, that you don't care who "wins". And that is sometimes hard to show when you are always start on the winning side of an argument (whether you win it or not is another story), so, being on the losing side of an argument once in a while can be a good thing (even if you intentionally set it up that way). Attitudes of others are hard to change, the only thing that seem to work is making sure you have to right attitude and that it shows (with subtlety), e.g., if you want people to accept changes when justified, show them that you accept their approach when it is justified. Also, finding peers that seem to share that desirable attitude and ganging up works great too. If your company is truly rotten with seniors with very doubtful skills and really bad attitudes, then you might want to let your survival instinct kick in and leave the place before it implodes or rottens further (infecting you too).

Finally, YES, the majority of programmers are mediocre at best. Don't expect most C++ programmers to program in STL or Boost style, don't expect them to even be able to understand the code in STL or Boost, certainly don't expect them to understand the design choices it makes, but at least, you should expect them to be able to use some of the STL or Boost libraries.

[VernonDozier]

It all depends on your demeanor and approach. If you come up to a "senior" as a rookie and have a know-it-all attitude, no one is going to want to hear it, regardless of whether you're 100% correct regarding the code. You haven't made your bones yet. If you're more diplomatic, you may or may not get better results. Some people can't take criticism no matter how constructive it is. No "senior" is going to take criticism from someone with four months' work experience if you aren't diplomatic. If everyone there truly is a moron, then find another job. Some places everyone truly is a moron. I'm optimistic enough to believe that's the exception, not the rule. Almost certainly there is someone there who is not a senior, but also not a rookie and not a moron who can show you the ropes.

You're the low man on the totem pole at the moment and the seniors are the ones evaluating you, not vice-versa. Get crosswise with them and you lose. You need to display situational awareness and take a look at the culture at the place you work. The culture might well be that you are expected to learn how the place works for the first six months or a year and keep your opinions to yourself during that time. Other places will encourage you to express opinions right off the starting block.

[WaltP]

> "I can't remember it just now, but I'm sure there's a good reason for that" (basically the argument deceptikon makes): Assuming there was a good reason behind it, then they should care about remembering it and should be willing to spend some time analyzing the code to find out what that reason was (if they are not willing, then they are lazy slobs, programming skills have nothing to do with that). If there was a good reason then, there should still be a good reason today (unless it has become obsolete), and therefore, you should still be able to figure out what that reason is today (hopefully with the help of those who wrote the code in the first-place).

This analysis I disagree with -- at least on the surface. If the code in question is working and no changes are required to correct errors or make enhancements, why bother spending time understanding why something that is working used the technique in question? It's immaterial at the moment and not worth a senior's time nor effort to dig into it to assuage someone's curiosity. They have more important things to do than relive the past.

On the other hand, if an error or enhancement is being made, understanding the code is extremely important -- to make sure the new changes don't have hidden complications.

[stereomatching]

This analysis I disagree with -- at least on the surface.

I agree with mike_2000_17, I could remember my decision choice
one year ago when I look at my codes,because I try my best to make sure my codes
readable and write a lot of comments. I could tell you why did I did it like that
in a few of minutes even just a few of seconds, including those less efficient
and wrong decisions because of my incapability.

In the last several years, I have often looked at code that I had written some 1-2 years prior and found it to be really horrible, wrong, bad-style, wasteful, ignorant, ineffective, etc. etc.

I have the same feeling as you, and I always could find a way to tune my codes
after that.It is very excited to find out that I could make my ex codes become
better(or worse, I am not 100% sure that all of my codes become better after refactor).