Fine, I'll indulge you for one more post
|And here is example of heavy unit-testing working exactly the opposite way - leading to bloaty, messy code, which funny doesn't even work: |
That example has exactly nothing to do with unit testing.
|There is a much bigger problem of writing tests by the same person who writes the code being tested (and this is also documented in many books FYI). Chances such tests miss important edge cases are very, very high. |
The programmer is in the best position to know about the edge cases he's introducing. If he does not, he is incompetent.
Borrowing an example from ACCU a few years ago, imagine you wrote a function that returns the probability for N people to have the same birthday (assuming 365-day year):
double sameBirthday(int numPeople)
assert(0 <= numPeople);
if (numPeople > 365)
double probability = 0.0;
for (int i = 1; i < numPeople; ++i)
probability += (1.0 - probability) * i / 365.0;
What QA or college graduate hired to write your tests for you would know that you have a boundary condition between 183 and 184? You're lucky if your reviewer understands what you just wrote and points out that it needs a test there or if your hired test writer spots the problem when testing around the interface boundaries. Good design here would be to change the contract so that there are no surprise boundaries -- that would be an example of testable design
, not test-driven design
which your sudoku link talks about.
Code reviews, static analysis, and QA are also indispensable steps of software development, but they cannot replace white-box unit tests. They serve different, complementary, purposes.
|Where are they? I'm really curious.|
Do I have to teach you how to look for jobs in software? Seeing as you think indeed.com can tell you something about senior salaries, I guess I should.
For junior positions in not so giant companies, you could start by going to the websites of the OS vendors themselves. I'll visit a couple for the sake of this post:
I see Lynx (I'll never get used to 'lynuxworks') is looking for a bunch of new software engineers for their QA department (bachelor degree, 6 moths combined exp/training/academic work in software) - someone could easily start there and change over to another department later on.
Looking at their more retail-oriented QNX, there's more activity for the beginners - here's a few I see posted:
bug fixer "Analysis and resolution of reported problems related to all technical areas around the OS, file system, drivers and hardware" - bachelor or masters degree, "expert C" -- it's very hard to know C well after college, but possible if you're passionate
OS dev "directly contribute to the design and implementation of the QNX software platform in areas as varied as backup and restore, desktop integration and core software installation services", Bachelor’s, 1-3 years of software development (junior position)
field guy "work together with our customers to create and realize software solutions in response to the customer product development activities", no degree listed, 1-3 years experience in diagnosing and troubleshooting operating system software (could go here after Lynx's QA team)
embedded UI dev "Develop and maintain device drivers/frameworks for state-of-the-art UI technologies." Bachelor's, 2+ years exp C (supposedly they want "Junior to Senior Developer")
car software dev - they list everything from text-to-speech and UI to twitter connectivity, but only list bachelor's degree, probably a new team.
With big companies, hiring procedures can be different - I don't have time to web surf anymore, but to give an example, my firm (financial sector) just hires a hundred or so college grads once a year, puts them through several months of intensive programming training, and assigns to the teams that need fills. With several thousand developers, there's enough natural churn.
One advice to the original poster: be mobile. If you want to get as far as possible, don't think twice about moving to another state or country for an interesting job. I moved 7 times all over USA in the first ten years of my software engineering career, and visited other states and Europe for interviews.