|
|
Re: The Positive Legacy of C++ and Java
|
Posted: Apr 14, 2009 5:40 AM
|
|
> In smaller companies,
> programmers tend to do whatever they want.
It all depends. IMO, in small companies were mostly average programmers with some good will are left to do what they want they tend to do so as a group/team/quite well functioning social system, not as individuals. Which usually leads to agreed upon and reasonable processes and standards, and what's more important, to a healthy no BS attitude. But I have also seen small companies where management interferes, or where big egoes collide, and where the type of work performed favours a way of working that you describe. Each programmer does what he wants the way he wants. Code reuse is not even an afterthought, there are no defined standards and processes, and quality assurance is missing completely. But I think the issue of operator overloading is orthogonal to the issue of whether a team chooses to work as a team or is split into individuals by internal or external influences. Good programmers working individually are still able to deliver better code with operator overloading than without. Well-knit-together teams can easily train the less well prepared members to understand operator overloading.
> This doesn't
> seem like a problem until later when someone else needs to
> understand what was done. These prima donnas often are
> unwilling to consider how their choices will affect others
> and get angry when someone tries to prevent them from
> making a huge mess of things.
This argument is in some way supporting my statement. Programmers left to their own devices tend to isolate and elliminate prima donnas. Which is something unlikely to happen in larger companies, because ordinary programmers don't get involved into HR decisions. In small companies, it's unlikely that the manager of maybe two or three specialzed teams will risk blowing up one of his teams just in order not to react to the problem of having hired a primmadonna.
> They are sure they know
> best and refuse to learn from others. This is also a
> personality trait of a lot of consultants/contractors.
Consultants/contractors are also a trait of large companies, from what I've seen. Small companies hire consultants for trainings or the like, and even this they do seldomly. Small companies do the actual programming work 100% in house, and allow programmers to research and learn new technologies and applications on their own. In a normal small company, there will always be a few people which will bring technical novelties into the team, and teach others. In a large company, even if there are such people, introducing new technology is always a management decision.
> Unfortunately, since many (most?) people confuse being an
> n asshole with being smart, these people are given free
> reign to terrorize other developers.
Programmers don't make this confusion. In general I think it's not "most". Most people cannot tell the difference between an asshole, a smartass and a really smart guy when it's about something they don't really understand, but they do very well make the difference when it's about something they know about. Especially in larger companies management usually has no clue about the technical aspects of stuff upon whoch they decide (they usually never got to work as workers before becomming managers), but gets to make all or allmost all decisions, which is another reason why larger companies are less capable of making good decisions than smaller ones.
My conclusion: there might be issues with more advanced language features, potentially not easily understandable by all programmers in some environments, but IMO this is no reason to leave such features out of languages, especially when there are plenty of reasonable good uses for those features. From your take on the problem, I understand that what may look as organizational or political reasons are likely just the reflection of non-technology problems elsewhere in the organization, and to try to solve them through technology is unlikely to work.
Toyota's way comes to mind: fix any problem at the source. Based on this principle, I think that trying to fix programmer stupidity by giving them only tools that limit how stupid they can be is stupid. It's like getting only pain killers for a broken bone: it won't fix your bone, but it will make you feel better. The source of programmer stupidity is bad HR policy, bad working processes, bad working environment, or whatever makes smart programmers leave, average programmers be unwilling to learn, or bad staying on a team they're too stupid for (it may sound offensive, but nevertheless it happens). Trying to fix this by giving smart programmers an additional reason to leave or to work less well than they are capable of will only make things worse, IMO.
|
|
Previous Topic
