• 4 Posts
  • 74 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle




  • I’m also a software engineer (at least in title). I agree with the social skills but a different thing came to mind. The ability to actually watch and understand what people are trying to do. I’m lucky as all my software is internal to my company. I don’t make what we sell, I make what tests the products we sell. And yes I test the tests and also test the test’s tests 😭.

    I’ll give an example. I have an operation where the operator is to scan a number off a paper before testing. That number is for traceability we need to know which test results are for which unit. Previous engineer said since it’s scanned off the unit it will never be incorrect as long on the printed barcode is correct(separately validated) so no need to verify format.

    I ran into an issue where units had an extra zero either before or after the number. So if number was 12345 sometimes it would be 012345 or 123450.

    I went to watch the process. The operator scanned the unit( I watched them work all day, this was 1 unit out of a whole days work) and when they put the scanner down the scanner’s corner was on the 0 button of the keypad.

    We did a 2 phase remiduation. Stage 1. Operator instructed to log in and then place keyboard on shelf away from workplace. Stage 2. Verify the number is in correct format in code. Yes the code update is simple but in our field needs weeks of work to test, validate, and release.

    Actually watching the operator closely identified the problem. The code was not the issue, the code passed all requirements and tests. The issue was the tests and requirements did not match the user’s experience but if I stayed in my cube as for weeks I would not of been able to find the bug.



  • It might be a side effect of my work environment. I make the equipment that tests electronic medical implants. Theoretically if a unit put 1A of charge out instead of 1ma that could kill a person. Now on a practical level that’s not possible with our devices and even if it was we should be able to identify and prevent that unit from reaching the field.

    Yes you are right, you want 99.99% uptime you need this stuff. In the field I’m in a single case escaping test can be months of engineering time to investigate, root cause analysis to determine the actual cause, expensive fixes for the short term and even more expensive fixes in long term to upgrade everything so it never happens again.

    Boss being unhappy that you missed something is minor. Their boss’s boss’s boss is the real issue. That said we get regularly audited both in-house and external agencies so it’s unlikely. Multiple lines of defense, have a computer check it, have a person check that the computer actually checked it, have a computer verify that the person actually verified it. Have each of those systems regularly audited and verified to be effective.

    It’s expensive but it is what is needed to be in this field.


  • Ok,this maybe too nerdy of a topic for here but that’s why I love unit tests.

    Basically I write a piece of code that gets this input and generated that output. I also make a test to verify that I get a certain output given a certain input.

    Now if I spend all day futzing within that code , changing variable names, refactor and extract a large function to 10 small ones, decide to re-write all the SQL queries to linq arguments…I can fuck up and tests may fail. I fix the failing code to still pass the test. I know I delivered code that met the requirements, hopefully improved it, but I know I didn’t fuck it up enough to not do what it’s expected to do.

    Plus source control…I mess around with code, my tests all pass…I commit it…I mess around more, can’t get the tests to pass, oh well quitting time roll back to previous working commit. Boss may be mad I didn’t improve it but at least I didn’t break it. Zero gain day is better than negative gain…