What type of low level programming jobs are there?

[Cubbi]

Also, programmers should not write tests for their own code

I couldn't disagree more, but that takes this thread even further off-topic.

I asked how many?

I only worked on the other end of that spectrum (RT), and it was more than your estimates. I don't know how many people IBM has working on AIX, but comparing their SLAs to ours, it has got to be more still.

this is like recommending a physics student that he will be able to get a job as a nuclear reactor designer after he graduates

Did anyone suggest designing new OS kernels? There are many jobs at nuclear power plants that require physics degrees. (although a CS graduate could certainty get a job designing kernels, if he studies some more and can live on a postdoc salary)

[moorecm]

rapidcoder wrote:

Not just any M.S. grads, but grads who have already some substantial experience in the field, not just a few college assignment projects.

Not necessarily but often grads from specific schools. For example, my organization recruits most of their engineers from Carnegie Mellon.

rapidcoder wrote:

Full unit test coverage is wasting time and resources. Such stupid guidelines result in writing tests for getters and setters. I'm working in a decent company, and we don't have even 50% unit test coverage, because there are much better and more efficient ways of achieving high code quality (like static code analysis / reviews or functional testing).

That's the kind of thing some of my co-workers would say. Unfortunately, it's absolutely false and the code maintenance costs are high because of it.

rapidcoder wrote:

Also, programmers should not write tests for their own code. Giving tests to interns/juniors is actually a very good way of improving the code quality and letting interns/juniors know the codebase quickly. But of course it depends what you mean by junior. Juniors at our company have already usually 5-10 years of experience, so this might be much different that your definition of a junior.

No. Not even almost. This would remove accountability for writing testable code (also read as quality code) from the 'non-junior' members of the team. This leads to tight coupling, low cohesion, and intertwined dependencies that usually result in objects that can't even be instantiated in the test harness. There are entire books written about addressing the problem of introducing unit tests after the fact. Working Effectively with Legacy Code, for example, is on that topic.


BTW, I agree with nearly every word Cubbi had typed.

[N36fSL3A]

well you could ask to get a job with microsoft OS programming.

I was thinking about being a government programmer but I don't know how you'd be able to even find a hirer.

[rapidcoder]

This is offtopic, but quite interesting actually.

This would remove accountability for writing testable code (also read as quality code) from the 'non-junior' members of the team. This leads to tight coupling, low cohesion, and intertwined dependencies that usually result in objects that can't even be instantiated in the test harness

Nope. Such code would be thrown out immediately by reviewers. And if static analysis tools are used, it would also trigger some alarms.

Cohesion, coupling and code complexity are measurable things. This is totally crazy idea - using tests to force good code structure. It is not what tests are for and there are better ways to do that. If you need unit-tests to guard you against such things, you have a much bigger problem.

And here is example of heavy unit-testing working exactly the opposite way - leading to bloaty, messy code, which funny doesn't even work:
http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html

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. Most often those tests test only scenarios the programmer was thinking about when writing his code. Therefore they protect only against trivial bugs of a kind "oh, my code is not doing what I wanted it to do", but they do not protect against bugs of a kind "oh, I haven't thought that the input list might be empty; seems I misunderstood how this is going to work". If I haven't thought the list might be empty when writing the code, I would for sure not test it!

Maybe bugs of the first kind are more common in C++ (oops, I'm
dereferencing invalid pointer, segfault), but they are actually much easier to catch by good static analysis tools than the bugs of the second kind (logical ones). I have to really think hard, when did I encounter a bug of the first kind in my code, especially if it was Haskell or Scala, which signal those kinds of bugs most often by compile-time errors.

It gets even worse if you force programmers to write unit-tests *before* they write code. This leads to non-generic, bloated code, written on a case-by-case basis. It can also lead to bugs if you tests have bugs in them, and they definitely will at some point of time.

Don't get me wrong, unit-tests are awesome to find regressions or to test *some* code that has a simple API, but complex implementation (e.g. all the complex algorithmic stuff). But their value as the a true way of finding new bugs is highly overrated.

Unfortunately, it's absolutely false and the code maintenance costs are high because of it.

<sarcasm>Oh, yeah, because 100% test coverage costs you nothing<sarcasm>.

IMHO having only 50% test coverage would save you 90% of cost. This saving then can be used to hire a good QA team that would find many more bugs (the function of code coverage to size of tests is not linear; as well as code coverage to number of found bugs; beyond some point you don't gain really any improvement in quality and you pay a huge cost of maintenance of tests).

I only worked on the other end of that spectrum (RT), and it was more than your estimates. I don't know how many people IBM has working on AIX, but comparing their SLAs to ours, it has got to be more still.

Sure, there are banks who still need to maintain their systems in COBOL. The only difference is that not many coders know COBOL, contrary to coders knowing C and being able to jump into UNIX hacking. Therefore it might be a better strategy to look for a COBOL job than an AIX job. Both are shrinking niches, but with COBOL at least there is less competition for a job.

There are many jobs at nuclear power plants that require physics degrees

Sure, you can be an operator. Aka sysadmin. What else did I say? Plenty jobs for Solaris / AIX sysadmins. Maybe you'll get a chance to write some shell scripts or if you're very lucky, something simple in C. On the other spectrum, maybe some device driver or app for an RTOS. That's it. But for core OS development, you'd need to be hired by Oracle, IBM or Microsoft. Guess how many open positions they offer, especially recently when their revenue is going away to OpenSource market (BigData, NoSQL, Linux)?

BTW: I asked you for open job list for someone who is willing to do low-level OS development (not writing apps or administrating). Where are they? I'm really curious.

[moorecm]

I smell irony.

[Cubbi]

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)
            return 1.0;

        double probability = 0.0;

        for (int i = 1; i < numPeople; ++i)
            probability += (1.0 - probability) * i / 365.0;

        return probability;
    }

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.

[rapidcoder]

That example has exactly nothing to do with unit testing.

It shows no amount of unit-testing or "testable design" can save you from bad code. I opposed to your claim of keeping 100% test coverage, not unit-tests generally. And your claim was unit-testing with huge coverage improves structure and maintainability of the project. In this case it didn't.

The programmer is in the best position to know about the edge cases he's introducing. If he does not, he is incompetent.

If programmers were fully competent, unit-testing would be unneeded at all. Edge cases can be sometimes quite hidden like in your example, and handing your code to be tested by someone else increases the chances your code is testable and all the important edge cases were checked.

[N36fSL3A]

You know what? The replies are getting so long and uninteresting even I don't want to read them.

Maybe you guys should stop and come to some type of compromise and just post that.