Troubleshooting

3 comments

1. 1
   

   sailor1031

   March 5, 2013 at 2:28 pm (UTC -7) Link to this comment

   Yeah. Process developed by people with explicit domain knowledge!

2. 2
   

   Peter B

   March 5, 2013 at 3:12 pm (UTC -7) Link to this comment

   I would change those percentages to 80% process and 20% domain specific knowledge. For example:

   I brought a little piece of knowledge to a problem. That knowledge: on 32-bit 80×86 systems there is a bit in instructions to differentiate between for 8-bit bytes and 32-bit word addressing. That knowledge was instrumental in understand how a C language BOOL defined as a 32-bit integer was almost certainly not the same size as a bool in C++.

   Process was compiling a C and C++ module with a temperately added sizeof for the likely offending structure. Then looking inside the executable for the sizes. They were different.

   The process proved the size difference. A little inspection showed the BOOL/bool problem which I knew to be important from my domain specific knowledge. Changing “int” to :”char” fixed the problem that puzzled my less experienced coworkers.

   On my latest effort – if I had more USB domain specific knowledge with emphasis on its implementation in STM32F4 products I would have not torn out most of my remaining hair.

   Bottom line: one needs both process and domain specific knowledge. Lack of the latter seriously inhibits the former.

3. 3
   

   Grumble

   March 5, 2013 at 3:55 pm (UTC -7) Link to this comment

   You’re just wrong, CPP. At least for some cases.

   What if you’re a molecular biologist, trained and practicing as such for 30 years, and you realize you need to do some electrophysiology experiments in your lab. So you get a post-doc to set up a rig, but for the life of her she can’t get the weird noise out of her recordings. I submit that you will be utterly useless in helping her.

   And the same goes for an electrophysiologist trying to figure out why the post-doc’s gel won’t run right.