Considering the lousy end products I have to deal with on a daily basis, paying programmers more money won't improve the skillset. You want to be paid more money? Produce a better product.
When the PHBs conspire to make that (producing a better product) impossible, it doesn't matter what engineers you employ or how much you pay them.
The relentless push to cut costs, do "more with less," let the staff numbers dwindle through natural wastage and lack of vision, invent fantasy project schedules (requiring weekend, evening and holiday work) and no resources (what do you mean you need physical hardware to develop and test on? I just sold the test kit to a customer. It was revenue just begging to be had...) catches up with every company eventually.
My current employer is now in this state, and almost everyone (who knows anything) has left and I'm about to as well, however as far as the PHBs and VPs are concerned, everything's fine and dandy. Targets are at 100%, the share price has doubled and we're making a consistent profit.
The fact that tumbleweeds are blowing through Engineering hasn't quite registered...
It's the natural cycle these days. They call it "capitalism" but it's not the capitalism I understand.
Train for Management, Business Administration and Making Tough Decisions(TM). There is no way that our corporate masters are going to outsource/offshore/automate their own cushy positions or let the great unwashed get their hands on the robots producing the goods.
So you nicely repeat the lies they have fed to you ?
What lies? That there are a bunch of murderous thugs trying to take over the Middle East and impose a 1500-year-old fascist dictatorship on the 99.9% of ordinary people that live there?
The lies about the suicide bombers with surgically-implanted bombs?
The Isis thing is once again financed by the Sauds. YOUR friends.
Yes, I know who finances them. They're not "my friends." I've never met any of them personally, and I don't approve of any of it, whichever of the warring sides you care to mention.
Anyway, the new dude is Abu Bakr al-Baghdadi and he's assimilating Irag, Syria and probably Jordan, Saudi Arabia, Israel, Somalia, Nigeria... you name it... into his all new "proper" Islam state.
A number of armies in the region are already squaring up, including Iran and Saudi. There have been some murders of Israeli and Palestinian teenagers by terrorists too, probably trying to goad each side into action.
A simpler, more efficient high-level (higher than C++) language that is more expressive with fewer lines of code, less prone to introducing silly bugs caused by human error, and more readable by other programmers.
C++ is for those serious programmers who want to get real work done, and who don't have time to waste with overhyped crap.
C++ is for conformists and trend-followers lacking in enough critical thinking skills of their own to investigate and adopt better tools for the job.
The end of quarter profit is what matters. Suck it up and take it like a man! Pull your weight like a true team player or you'll be let go to make way for a flexible, empowered, dedicated business-oriented go-getter from the thousands of them queuing up at the door.
If you can't do it right, or don't like it, get out. Don't drag the team down with you, loser.
Okay, there's the misunderstanding - I hadn't understood you were talking about automated pre-checkin testing. I still am not seeing the need for "multiple compilers, multiple OSes, and multiple binary architectures" mentioned by the original poster for a product that is intended for a single platform
Different compilers on the same platform find different bugs (warnings, errors).
Different static analysis tools also find different defects.
Different numbers of CPUs/Cores find different timing bugs, deadlocks, race conditions, corruption etc. on concurrent code.
Different binary architectures show up endianness bugs and subtle corruption bugs due to alignment of data in memory.
Different OSs find different run-time behaviour problems and dependency problems. They also find problems in any OS abstraction code.
The more compilers. analysers, machines, architectures and OSs you use, the more bugs you find, and the more bugs you find and fix, the higher the quality of your product.
It's always easiest to develop on top of a high-quality code base. That's when you're fastest.
You don't need a QA department. Automation can get you 80-90% of the benefit.
You don't need to do everything all at once. Start adding new tests, builds and platforms as you go, a bit at a time. You should see your velocity increase very soon.
C and C++ were designed on the principle that the fundamental language constructs should be as fast as possible.
C was designed to be as simple (and flexible) as possible. It (the compiler) had to run on tiny machines, by modern standards. Speed (of the object code) is a consequence/coincidence of the simplicity of the language and the fact that simpler languages tend to produce tighter (and faster) object code when compiled.
C's simplicity can be summed up by the following rule of thumb: if something can be calculated at compile time, the language usually supports it. Everything else (like handling array dimensions and strings) are left up to the programmer.
When computers were small and slow, C was ideal for programming them when FORTH wasn't big enough.
What you should be doing outside the CS class and in the so-called "Real World" is "being productive". That usually means screw the warnings, it has to be completed ASAP or we'll find someone "more productive" than you are.
I'm having a sense of humour failure at the moment, so apologies if this was not taken in the spirit it was intended but: that sort of attitude tends to get you eaten by the Real World for breakfast.
I've very recently found myself working for a company that has gone in that direction due to incompetent management and greedy VPs. I and my colleagues have been pressure into fixing bugs with no proper bug report, no access to the production hardware and no integration and test facilities "by lunch time" with all the corner-cutting that implies.
The company is now paying for it, and I am on the verge of accepting a new job with another company.
I didn't RTFA because I could tell from the summary that it was a lot of nonsense.
or c++
I understand enough about C++ to know to avoid it wherever possible. I freely admit that my brain isn't big enough to fight against C++ with enough perseverance to get it to do anything useful correctly. I'll stick to C and scripting languages thank you very much.
or unit testing.
*cough* Test Driven Development *cough*
To become half way good at C++ you either need to devote you entire life to it over decades (somewhat like a monk) or have an IQ of at least 200. Life's too short and my IQ is miles too low.
Why not just say that you should always build against the latest official working source before checkin? It has nothing to do with unit testing.
It does. You shouldn't be putting in new logic bugs with your deliveries. The code should compile cleanly and you should do due diligence to avoid putting in new bugs.
Bugs are expensive to fix, in terms of debugging time and refactoring of broken code to change additional changes built on top of the broken code.
It's amazing how much real progress you can make if you follow these simple rules.
And of course everyone always builds with the same configuration, same compiler, on the same platform.
Yes, they should, and it should be scripted so that it's trivial so that there's no excuse for not doing it every single time.
Multiple compilers, multiple OSes and multiple binary architectures should all be used and they should all be available to every developer on the network. There should be enough network, storage and CPU capacity to make the builds quick so that there is no excuse for not doing them.
Because you have to build your code to run the unit test. The two are (should be) intimately linked. And you should always be building against the latest official working source from the upstream repo.
When in CS, I had a prof that had one rule that for release (not beta/alpha/dev) code, if the code had even a single warning, it was unshippable unless there was an extremely good reason (which would be part of the README) of why it happened. Yes, this was a PITA, but he was trying to teach something that seems to have been lost.
You should be compiling with warnings as errors as soon as you start coding, and you should fix each one as they occur before you move on to write the next line of code.
Putting off fixing these problems leads to bloated and fragile code and wastes much more time debugging and fixing later.
Slashdot Mirror
Considering the lousy end products I have to deal with on a daily basis, paying programmers more money won't improve the skillset. You want to be paid more money? Produce a better product.
When the PHBs conspire to make that (producing a better product) impossible, it doesn't matter what engineers you employ or how much you pay them.
The relentless push to cut costs, do "more with less," let the staff numbers dwindle through natural wastage and lack of vision, invent fantasy project schedules (requiring weekend, evening and holiday work) and no resources (what do you mean you need physical hardware to develop and test on? I just sold the test kit to a customer. It was revenue just begging to be had...) catches up with every company eventually.
My current employer is now in this state, and almost everyone (who knows anything) has left and I'm about to as well, however as far as the PHBs and VPs are concerned, everything's fine and dandy. Targets are at 100%, the share price has doubled and we're making a consistent profit.
The fact that tumbleweeds are blowing through Engineering hasn't quite registered...
It's the natural cycle these days. They call it "capitalism" but it's not the capitalism I understand.
Train for Management, Business Administration and Making Tough Decisions(TM). There is no way that our corporate masters are going to outsource/offshore/automate their own cushy positions or let the great unwashed get their hands on the robots producing the goods.
Cutting yourself to prosperity doesn't work.
And how would you know, Mr Smartypants? Name one company that's lasted long enough to find out!
Sing: "Send me your money."
So you nicely repeat the lies they have fed to you ?
What lies? That there are a bunch of murderous thugs trying to take over the Middle East and impose a 1500-year-old fascist dictatorship on the 99.9% of ordinary people that live there?
The lies about the suicide bombers with surgically-implanted bombs?
The Isis thing is once again financed by the Sauds. YOUR friends.
Yes, I know who finances them. They're not "my friends." I've never met any of them personally, and I don't approve of any of it, whichever of the warring sides you care to mention.
...and his side-kick Blair.
Anyway, the new dude is Abu Bakr al-Baghdadi and he's assimilating Irag, Syria and probably Jordan, Saudi Arabia, Israel, Somalia, Nigeria... you name it... into his all new "proper" Islam state.
A number of armies in the region are already squaring up, including Iran and Saudi. There have been some murders of Israeli and Palestinian teenagers by terrorists too, probably trying to goad each side into action.
It's a bloody miserable state of affairs.
Indeed, they're a swivel-eyed loon.
And C++ supports recursion, immutability, and the other hyped features of functional programming.
Yes, and at this rate, perhaps in another 20 years, it will have caught up with LISP (from the late 1950s).
And if you aren't a dumbass, you'll use ...
A simpler, more efficient high-level (higher than C++) language that is more expressive with fewer lines of code, less prone to introducing silly bugs caused by human error, and more readable by other programmers.
C++ is for those serious programmers who want to get real work done, and who don't have time to waste with overhyped crap.
C++ is for conformists and trend-followers lacking in enough critical thinking skills of their own to investigate and adopt better tools for the job.
That's what it is.
The end of quarter profit is what matters. Suck it up and take it like a man! Pull your weight like a true team player or you'll be let go to make way for a flexible, empowered, dedicated business-oriented go-getter from the thousands of them queuing up at the door.
If you can't do it right, or don't like it, get out. Don't drag the team down with you, loser.
It's always nice to bring a little light into someone's life.
And I meant to post that anonymously :-)
Heh. There's probably about a thousand C++ turds for it.
Okay, there's the misunderstanding - I hadn't understood you were talking about automated pre-checkin testing. I still am not seeing the need for "multiple compilers, multiple OSes, and multiple binary architectures" mentioned by the original poster for a product that is intended for a single platform
Different compilers on the same platform find different bugs (warnings, errors).
Different static analysis tools also find different defects.
Different numbers of CPUs/Cores find different timing bugs, deadlocks, race conditions, corruption etc. on concurrent code.
Different binary architectures show up endianness bugs and subtle corruption bugs due to alignment of data in memory.
Different OSs find different run-time behaviour problems and dependency problems. They also find problems in any OS abstraction code.
The more compilers. analysers, machines, architectures and OSs you use, the more bugs you find, and the more bugs you find and fix, the higher the quality of your product.
It's always easiest to develop on top of a high-quality code base. That's when you're fastest.
You don't need a QA department. Automation can get you 80-90% of the benefit.
You don't need to do everything all at once. Start adding new tests, builds and platforms as you go, a bit at a time. You should see your velocity increase very soon.
C and C++ were designed on the principle that the fundamental language constructs should be as fast as possible.
C was designed to be as simple (and flexible) as possible. It (the compiler) had to run on tiny machines, by modern standards. Speed (of the object code) is a consequence/coincidence of the simplicity of the language and the fact that simpler languages tend to produce tighter (and faster) object code when compiled.
C's simplicity can be summed up by the following rule of thumb: if something can be calculated at compile time, the language usually supports it. Everything else (like handling array dimensions and strings) are left up to the programmer.
When computers were small and slow, C was ideal for programming them when FORTH wasn't big enough.
c++ is great.
Keep repeating it often enough and people will believe you.
A build system can help you modularize your build so that a complete recompile does not occur after a syntax or linker error.
For C++? Are you nuts?!
What you should be doing outside the CS class and in the so-called "Real World" is "being productive". That usually means screw the warnings, it has to be completed ASAP or we'll find someone "more productive" than you are.
I'm having a sense of humour failure at the moment, so apologies if this was not taken in the spirit it was intended but: that sort of attitude tends to get you eaten by the Real World for breakfast.
I've very recently found myself working for a company that has gone in that direction due to incompetent management and greedy VPs. I and my colleagues have been pressure into fixing bugs with no proper bug report, no access to the production hardware and no integration and test facilities "by lunch time" with all the corner-cutting that implies.
The company is now paying for it, and I am on the verge of accepting a new job with another company.
I don't think you understand the study
I didn't RTFA because I could tell from the summary that it was a lot of nonsense.
or c++
I understand enough about C++ to know to avoid it wherever possible. I freely admit that my brain isn't big enough to fight against C++ with enough perseverance to get it to do anything useful correctly. I'll stick to C and scripting languages thank you very much.
or unit testing.
*cough* Test Driven Development *cough*
To become half way good at C++ you either need to devote you entire life to it over decades (somewhat like a monk) or have an IQ of at least 200. Life's too short and my IQ is miles too low.
Why not just say that you should always build against the latest official working source before checkin? It has nothing to do with unit testing.
It does. You shouldn't be putting in new logic bugs with your deliveries. The code should compile cleanly and you should do due diligence to avoid putting in new bugs.
Bugs are expensive to fix, in terms of debugging time and refactoring of broken code to change additional changes built on top of the broken code.
It's amazing how much real progress you can make if you follow these simple rules.
And of course everyone always builds with the same configuration, same compiler, on the same platform.
Yes, they should, and it should be scripted so that it's trivial so that there's no excuse for not doing it every single time.
Multiple compilers, multiple OSes and multiple binary architectures should all be used and they should all be available to every developer on the network. There should be enough network, storage and CPU capacity to make the builds quick so that there is no excuse for not doing them.
How does a unit test prevent a build error?
Because you have to build your code to run the unit test. The two are (should be) intimately linked. And you should always be building against the latest official working source from the upstream repo.
When in CS, I had a prof that had one rule that for release (not beta/alpha/dev) code, if the code had even a single warning, it was unshippable unless there was an extremely good reason (which would be part of the README) of why it happened. Yes, this was a PITA, but he was trying to teach something that seems to have been lost.
You should be compiling with warnings as errors as soon as you start coding, and you should fix each one as they occur before you move on to write the next line of code.
Putting off fixing these problems leads to bloated and fragile code and wastes much more time debugging and fixing later.
I worked on features that let Visual Studio talk to SAP.
Well, that explains the rest of your post.