• 7 Posts
  • 243 Comments
Joined 3 years ago
cake
Cake day: June 20th, 2023

help-circle
  • I mean I’m not a fan of Ai but that kinda makes sense to prevent expensive loops. An example being I know Google gemini has(and has had for several versions) a bug where it can get stuck repeatedly reading a file. I saw a video from a YouTuber which got stuck in this loop, it cost him 183 dollars in 40 minutes. What if he started it and then went home on a Friday evening? I just did a quick calculation based on it running 5pm Friday till 9am Monday and it would cost $17, 568 setting a limit to prevent this type of issue makes sense. Fun fact, by random chance there’s exactly 96 intervals of 40 minutes over that time frame.




  • In my experience code review is often about the logic rather than the code itself. For example do you really need to copy the whole user object just to read their username? Can’t you just pass the username in as a string instead? Static validation and test suites should already of eliminated any code errors. If you show up to a code review and the code doesn’t compile, you’re going to have a bad time. Stuff like calculating the same distance between two objects multiple times should be called out in code review, maybe extract that into a function. Reaching out to a database to get the same value repeatedly should be called out, maybe store it as a local variable.

    One time I was reviewing some code which interfaces with an external third party piece of hardware which the api required the serial number for licensing. The programmer hard coded the serial number into the code. If we swapped it due to hardware malfunction we would need to update the software. If we got a second one we would need to maintain two code bases. This should be in a configuration file or something. Ai will not catch that. Static testing won’t catch this. Test suites running on the piece of hardware we had, wouldn’t catch this. Only a human reviewer would.







  • I love using interns for this. Typically they 1. Have some free time to test things out. 2. Smart enough they won’t try to eat the mouse. 3. Dumb enough they won’t be able to figure out those 20 obscure steps to make it work like the senior dev would.

    It won’t find all bugs, finding ui/ux issues or common bugs they are great at. One example that I can think of is our badges had 2 barcodes on them, one assigned by new company who bought us and one assigned by original company(for legacy and regulatory reasons). If you never worked for old company the second bar code was all zeros. Most employees knew this and new to always scan the new one to log into software. An intern didn’t. They ran a bunch of tests but reviewing the data the “operator” was listed as all zeros. This could have been a legal issue if released into production. Thankfully it was caught because intern didn’t know which bar code to use, a check was implemented in the code to ensure the user was not all zeroes(as well as other tests to make sure it was new company and not old company but I can’t go into detail on those).