- jvlake parentMakes sense. If I pick up an 8-inch or 5¼-inch and put it in a a maintained drive it WILL read it, try that with a writable CD/DVD. Don't get me started on the bit-rot you can expect from a 2024 NVMe
- Take this with a grain of salt, but I don’t see any cloud experience, I see lots of “used” which tells me very little about how proficient you are. It’s hard to tell if you’re a junior/senior, you don’t demonstrate you have good knowledge of best practices or design patterns or show team leadership skills, DevOps? Agile? Kubernetes? Not to say you don’t posses those skills but your cv doesn’t demonstrate it that well… that’s to say the 1st page didn’t and I have a stack to get through and all this work I’m still expected to complete by close of business because I’m tech lead AND hiring manager, next.
- "We think it's mostly just data found on the internet, but you're welcome to look for any breaches of copyright law" --OpenAI as they hand over the first box of printouts.
It raises an interesting point, if I train a chatbot (generative AI) on a bit of copyrighted information and it recreates substantially similar content, it's a legal problem. If a human reads the same information and tells another person verbatim it's just a conversation. Perhaps it's a quality thing, I paint the Mona Lisa badly no one cares, but if I paint it too well at some point it becomes a forgery.
- If you do ‘red, green, refactor’ TDD and write clean ‘arrange, act, assert’ tests then you’ll likely create nice single responsibility classes that are a pleasure to test and extend.
The tests usually run lightning quick because the units will be small.
When bugs occur in your codebase it will be at the right level of abstraction to write tests for the bug.
I almost never do strict TDD, I hack away to get something going and use the tests to refactor the working code into clean srp code. The end result is the same. However where I would use strict TDD is when there is massive complexity (like creating a video encoder) or if you are following a published specification.
So ‘just barely working, green, refactor, else red, refactor, green’ is probably closer to my actual day-to-day. The working code is clean, the tests are clean, and the coverage is good. The order doesn't matter.