Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Things That Scare the Bejeezus Out of Programmers 641

Posted by Soulskill
from the it's-just-a-matter-of-code dept.
itwbennett writes "Software developers are, by and large, a cool and analytical bunch, but there are a handful of things that strike terror in their hearts. Phil Johnson scoured developer forums looking for an answer to the question: What's your biggest fear as a programmer? The answers clustered into 5 broad groups ranging from being forced to learn or use a specific technology to working for and with incompetents. What's your biggest fear?"
This discussion has been archived. No new comments can be posted.

Things That Scare the Bejeezus Out of Programmers

Comments Filter:
  • by AuMatar (183847) on Wednesday July 03, 2013 @07:03AM (#44174751)

    Automated tests do two things. They make sure you don't make the same mistake again, and they give you higher confidence levels when you refactor. They definitely improve quality when done right- which means testing what needs to be tested, not relying on your tests as documentation or correctness proofs (I'm looking at you TDD), and not spending time writing tests that aren't really useful or for modules that aren't really easily testable (for example, testing that the UI is right).

  • by Anonymous Coward on Wednesday July 03, 2013 @08:00AM (#44175201)

    If you use shared memory there is no practical difference between multi-process and multi-thread. You have all the same disadvantages. It's just now you (apparently) have the illusion that you don't. This is not a recipe for success.

    Contention on shared resources is contention on shared resources, no matter what OS subsystem you use to create parallelism. But now you're using heavyweight IPC mechanisms to solve contention instead of lightweight intra-process mechanisms. Yay for a kernel transition and possible context switch on every lock call.

    If you'd said "assuming you do not use shared memory" - e.g. you communicate over pipes or sockets - then your statement would make more logical sense - isolated agents are a proven and robust technique in parallel programming. Except in that case fork() is exactly the wrong model.

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn