4 ms·

Basically, "divide and conquer." Big things are composed of small things. I don't think this is the controversial part or the difficult conclusion, the challen

Basically, "divide and conquer." Big things are composed of small things. I don't think this is the controversial part or the difficult conclusion, the challenge is how exactly to do that.

ChrisMarshallNY 3y ago
Which is what I mentioned. I think the “controversial” part, is probably the care taken, in developing the small things. The dependencies on which I rely (operating systems, compilers, SDKs, etc.) are all very well-designed, solid, and supported. I’m not a huge fan of surfing the bleeding edge. I like to use mature tools (usually. I’ve been writing Swift, since the day it was announced). Like I said, I spend a great deal of time, on each of my modules. Often, the testing code far outweighs the product code. Documentation is also a big deal. I write code and documentation for an audience of one (Yours Truly), but I publish it for everyone. It’s not my concern, whether or not the projects get any GitHub stars. In fact, I prefer it, if they don’t. Here’s an example. I’m currently writing an SDK to provide cleaned data for ML, so I can play around with ML, but it will be quite some time, before I get to that point. I’m still working on making the SDK rock-solid. I have spent the last couple of days, just working on the parser. I still need to write the query/importer. Yesterday, was all about unit tests for the parser. The next part, will require a test harness[0] (a SwiftUI app). Unit tests won’t be useful for that. It will also be my platform for the ML application. Also, code coverage for the parser tests is only about 85%. I plan to use the test harness to test the remaining 15%. Many folks would simply rush through this part, but they would end up shipping (or throwing out) the sloppy code they wrote as a lash-up. Even if I decide that I don’t have a current application for ML, I’ll still have a top-Quality SDK, to use as a component for future work. The app I just released, has a backend server, that I originally designed as a general-purpose application server. It took me seven months to write, as it was written in layers, and each layer was rigorously tested, before moving to the next. The purpose of that project, was as a teaching exercise. I didn’t actually have an application in mind, when I wrote it. The server is a lot more complex than it needs to be, because it was designed as a general-purpose server, and the current implementation uses a fraction of its capacity. But the server was available, when I started work on the app, and I already knew it was extremely high-Quality, so using it wasn’t a big deal. It probably saved me a couple of months, and I really have a difficult time, trusting backend dependencies. [0] https://littlegreenviper.com/miscellany/testing-harness-vs-unit/ https://littlegreenviper.com/miscellany/testing-harness-vs-u...
- CyberDildonics 3y ago
  This seems like you're saying 'I do the same thing as everyone else, but I'm really good and I do it better somehow'
  - ChrisMarshallNY 3y ago
    Not really. I’ve been trained to take care on the small stuff. I’m not sure that “everyone else” spends that kind of time on the small stuff; or even cares about it, so maybe it is a unique approach. I spent most of my career at hardware manufacturers, and hardware screwups are very costly, compared to software. A product recall is a bit more involved than a software patch. There’s a lot of arguments against that kind of care, as it can be difficult and expensive. There’s a reason that a Mercedes costs a lot more than a Toyota, even though they may seem to be the same car, superficially, but Toyota is probably a more profitable corporation. It’s just the way I work. I’m not particularly interested in slagging anyone else’s work. I’m just talking about the way I do things.
    - CyberDildonics 3y ago
      How is this not exactly what I just said? There aren't any details here, you're just saying "I've been trained to take care of the small stuff" and your last posts were just you saying you're careful and you spend time on modules and time on SDKs. There is nothing specific.
      - ChrisMarshallNY 3y ago
        Why are you arguing? I'm not interested in arguing about it. My work is out there (I was actually quite specific in my examples). Feel free to peruse it. I don’t particularly care whether or not I’m “better than” anyone else. I’m not competing with anyone, and there’s a ton of folks out there, that can easily outshine me, in many ways. I think that’s pretty cool, as it means there’s a lot to learn, and I love learning new stuff[0]. [0] https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...

Basically, "divide and conquer." Big things are composed of small things. I don't think this is the controversial part or the difficult conclusion, the challenge is how exactly to do that.

ChrisMarshallNY 3y ago

Which is what I mentioned. I think the “controversial” part, is probably the care taken, in developing the small things. The dependencies on which I rely (operating systems, compilers, SDKs, etc.) are all very well-designed, solid, and supported. I’m not a huge fan of surfing the bleeding edge. I like to use mature tools (usually. I’ve been writing Swift, since the day it was announced). Like I said, I spend a great deal of time, on each of my modules. Often, the testing code far outweighs the product code. Documentation is also a big deal. I write code and documentation for an audience of one (Yours Truly), but I publish it for everyone. It’s not my concern, whether or not the projects get any GitHub stars. In fact, I prefer it, if they don’t. Here’s an example. I’m currently writing an SDK to provide cleaned data for ML, so I can play around with ML, but it will be quite some time, before I get to that point. I’m still working on making the SDK rock-solid. I have spent the last couple of days, just working on the parser. I still need to write the query/importer. Yesterday, was all about unit tests for the parser. The next part, will require a test harness[0] (a SwiftUI app). Unit tests won’t be useful for that. It will also be my platform for the ML application. Also, code coverage for the parser tests is only about 85%. I plan to use the test harness to test the remaining 15%. Many folks would simply rush through this part, but they would end up shipping (or throwing out) the sloppy code they wrote as a lash-up. Even if I decide that I don’t have a current application for ML, I’ll still have a top-Quality SDK, to use as a component for future work. The app I just released, has a backend server, that I originally designed as a general-purpose application server. It took me seven months to write, as it was written in layers, and each layer was rigorously tested, before moving to the next. The purpose of that project, was as a teaching exercise. I didn’t actually have an application in mind, when I wrote it. The server is a lot more complex than it needs to be, because it was designed as a general-purpose server, and the current implementation uses a fraction of its capacity. But the server was available, when I started work on the app, and I already knew it was extremely high-Quality, so using it wasn’t a big deal. It probably saved me a couple of months, and I really have a difficult time, trusting backend dependencies. [0] https://littlegreenviper.com/miscellany/testing-harness-vs-unit/ https://littlegreenviper.com/miscellany/testing-harness-vs-u...

CyberDildonics 3y ago
This seems like you're saying 'I do the same thing as everyone else, but I'm really good and I do it better somehow'
- ChrisMarshallNY 3y ago
  Not really. I’ve been trained to take care on the small stuff. I’m not sure that “everyone else” spends that kind of time on the small stuff; or even cares about it, so maybe it is a unique approach. I spent most of my career at hardware manufacturers, and hardware screwups are very costly, compared to software. A product recall is a bit more involved than a software patch. There’s a lot of arguments against that kind of care, as it can be difficult and expensive. There’s a reason that a Mercedes costs a lot more than a Toyota, even though they may seem to be the same car, superficially, but Toyota is probably a more profitable corporation. It’s just the way I work. I’m not particularly interested in slagging anyone else’s work. I’m just talking about the way I do things.
  - CyberDildonics 3y ago
    How is this not exactly what I just said? There aren't any details here, you're just saying "I've been trained to take care of the small stuff" and your last posts were just you saying you're careful and you spend time on modules and time on SDKs. There is nothing specific.
    - ChrisMarshallNY 3y ago
      Why are you arguing? I'm not interested in arguing about it. My work is out there (I was actually quite specific in my examples). Feel free to peruse it. I don’t particularly care whether or not I’m “better than” anyone else. I’m not competing with anyone, and there’s a ton of folks out there, that can easily outshine me, in many ways. I think that’s pretty cool, as it means there’s a lot to learn, and I love learning new stuff[0]. [0] https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...