Not an issue

[HelloThisIsFlo]

Hey,

I wasn't sure where to leave a comment, or contact you. I couldn't find any email address. So I figured an "Issue" might do.

I just wanted to say that I am literally blown away by your coding style, especially the tests. Rarely have I seen open-source projects with such level of readability in tests. They express intent so unequivocally. On top of that, the code and architecture are clean and easy to navigate . . . it's beautiful.

Great job!
I'll surely be referring to this project as an example of good design. Thanks for your work 😉

[rndusr]

I took a second look at my sarcasm detector and there was no indication whatsoever, so I'm going to trust it and just say:

Thank you!

The reason I was suspicious is because, even after years of development, I constantly have to revise and rewrite stuff because that thing doesn't fit into into that other thing. To me, my tests are a nightmare especially. They are extremely complex, most of them are a weird mixture of unit tests and integration tests and they are in various states of completeness. Many of them were written just so I could wrap my head around what I was trying to achieve exactly.

Thanks again, this means a lot after all the work I put into this project. But I can't really agree since I know about all the dead rats in the nooks and crannies.

[HelloThisIsFlo]

Of course it's not perfect, of course it was difficult. But you know what is perfect, or not difficult? An ideal. Making an ideal reality, that, however, that's tough. And I think you did a pretty good job at it.

I even tried to go back to the very first commit, facing similar struggles to the ones you described, when writing tests and architecting my applications, I was curious to see the genesis of this project. Unfortunately, it seems it was imported from somewhere else. Btw, if you have a version with full history somewhere, I'd love to take a look

But honestly, in the end. What's the point of unit testing, or having a clear architecture ? It isn't about an ideal after all, it is about one very real thing: How easy it is to work on that particular project?

Literally 2 hours after discovering the project, with limited knowledge of python, and absolutely no idea of how the hell asyncio works . . . I was able to push a change in a way that didn't feel like a hack. And that is a win on your side. I am not the genius here, it was just that simple to follow.

Anyway, great work, and don't let that impostor syndrome get the best out of you ;)

[rndusr]

Thanks for the ego boost. :) I'll try and put that energy back into stig.

If you're going to make any non-trivial PRs in the future, please open issue first. I often (e.g. right now) don't commit stuff until I know it's not garbage, which means you may make changes to code that doesn't exist anymore.

if you have a version with full history somewhere, I'd love to take a look

Sorry, I worked on this project for about a year before using any VCS, so there is no commit history except what's on GitHub. I haven't used asyncio or urwid before and for every line of code you see now I probably wrote 100 lines that went to the garbage bin. I spent months trying to implement something one way before giving up and doing it completely differently. That means there'd be lots and lots of huge changes that replaced whole subsystems - only to be replaced again in the next huge commit. It was just too messy for coherent commits.

What's the point of unit testing

Tests are supposed to remove, or at least reduce regressions. You should be able to change code and immediately see if and why it doesn't work. Messy tests do the job of alerting you if your code sucks, but make it harder to understand why or adjust tests if you're sure about your changes.

[HelloThisIsFlo]

If you're going to make any non-trivial PRs in the future, please open issue first.

Noted! Although for that particular PR (empty username) I needed the change for my use case anyway, otherwise stig wasn't working for me. So I went ahead with the change even if it never got merged in the main project. In that scenario, would you still recommend to open an issue at the same as a PR, or discuss on the PR directly like we did?

Tests are supposed to remove, or at least reduce regressions. You should be able to change code and immediately see if and why it doesn't work.

Oh sure I agree that's the basis. It's just that sometimes people forget it's not just about that, at least not in the literal sense. And you end up with tests that "test" the current implementation works as the current implementation was coded to work . . . but don't test the intended behaviour. Tests get coupled to the implementation and change become more difficult and risky, sometimes even more than without any kind of test at all. That's why, when I see Tests that have been thoughtfully implemented to make sure they each showcase a particular behaviour and are not a simple reflection of the code . . . it makes me happy to work with that particular project :)

I haven't used asyncio or urwid before and for every line of code you see now I probably wrote 100 lines that went to the garbage bin.

Do you TDD? If so, how are you dealing with working with concepts you do not master (async & UI) ? How to begin writing a tests . . . when you have no idea how the application is supposed to work or how it's going to end up looking like ? I often hit a roadblock of frustration when that happens. I manage to get past it by first protyping and then doing TDD, but it still feels like a clunky process. I was curious about your workflow (if you know of any book on that particular topic I'm also interested ;) )

[rndusr]

So I went ahead with the change even if it never got merged in the main project. In that scenario, would you still recommend to open an issue at the same as a PR, or discuss on the PR directly like we did?

No, I don't mean you should open an issue alongside the PR, you should open an issue before you work on the PR. I just don't want you to waste your time. If you don't mind putting work into a PR that I can't pull, I don't really care either way.

you end up with tests that "test" the current implementation works as the current implementation was coded to work . . . but don't test the intended behaviour.

Yeah, I really struggled with this distinction for a long time. But it's slowly getting better now.

Do you TDD? If so, how are you dealing with working with concepts you do not master (async & UI) ? How to begin writing a tests . . . when you have no idea how the application is supposed to work or how it's going to end up looking like ?

Those were exactly my questions after reading every article on TDD. I never understood how it's supposed to work. I think the TDD people know before-hand how the project is broken into modules, classes, functions, etc, either because they have enough experience or some kind of supervisor.

If you only have vague ideas, you pretty much have to just throw code at your computer, see what happens and think about that. You're also likely going to be confronted with questions you didn't expect. A CLI parser is pretty straight-forward to reason about once you have an implementation. But the implementation itself has to cover all the corner cases that you won't know about until you've written a CLI parser at least once.

Sometimes I find it helpful to write tests to examine a piece of code in a controlled environment so I can better understand what exactly happens and how multiple pieces fit together.

And you just have to fight through frustration periods. I've actually given up at least twice when I started implementing stig. When I gave up in a different way and thought "this is never going to work, but I don't care", I eventually got to this point.

I can't help you with books, unfortunately. The only computer-related book I ever read was "Learn you a Haskell for great good". I only got half-way through but I think learning about functional programming vaguely improved my Python code.

[HelloThisIsFlo]

Thanks for your last message. That was very helpful, especially the last part.

And you just have to fight through frustration periods. I've actually given up at least twice when I started implementing stig. When I gave up in a different way and thought "this is never going to work, but I don't care", I eventually got to this point.

I usually end up with the same pattern. Wanting to do things "too good" . . . and end up being stuck in analysis paralysis. Only to, after a lot of struggle, tell myself that very thing: "It doesn't matter if it's f***** up, at least it's going somewhere" . . . and eventually this allows me to gain the insight I needed to unblock the TDD workflow I was craving for :)

But each time it happens, before I "let go" and experiment, it's almost like I'm fighting myself. One side wants to be free and experiment, and the other side is arguing that I just haven't tried hard enough to do thing "properly". So hearing about your very similar experience is really helpful. Next time I'm facing a wall, I'll remember our conversation, and maybe It'll appear to me slightly sooner than usual that the "proper" way is any way that's moving forward.

Thanks ;)

[rndusr]

Also remember that you're building experience and training your brain muscles while you're desperately running against that wall and getting nowhere. Even if no production code comes out of it, you'll have at least that.

[HelloThisIsFlo]

🙂

It was a really nice conversation. I'm glad I left this message :) If you're curious about what I do, feel free to check my blog or Twitter - @ThisIsFlorianK. My blog is totally outdated, but a new rebrush is coming in the next few weeks/months 😃

Also, given how you care about your code, and about sharing your knowledge, you might be interested in the SoCraTes conference this summer. I'm definitely going, registration is up to the end of the month. :)

See you around 🙂