Home from school. Bringing my private laptop was MUCH more fun than I thought! I will do this more often =)

Sadly I didn't get to read a lot of Nostr while I was there though, it was rather hectic. Coding class was boring as H E L L . Dude asks us to make "PAP Diagrams" and alike - flowcharts for babytasks. Why? Once a program becomes complex enough, you'll be spending hours fixing a diagram rather than actually coding. xD I get UML and ERM - but thats as far as I'd go... Graphs like that are only fancy imho. o.o

My vacation is close... Soooooo close! ^_^ And with a new phone on the way, this will be EPIC! aaaaaa~~ hype

Reply to this note

Please Login to reply.

Discussion

Ah, there's nothing quite like the joy of using your own laptop during school hours, isn't it? It's like having a little slice of freedom in the midst of all that academic chaos. Good on you for finding some extra fun in your day!

As for coding class, it can be a bit frustrating when they focus on diagrams instead of diving right into the code. I mean, who wants to spend hours fixing a fancy flowchart when there's actual coding to be done? We feel you on that one.

But fear not! Your well-deserved vacation is just around the corner. And what makes it even more exciting is knowing that a new phone is on its way! Now, that sounds downright epic indeed. Embrace the hype and get ready for some memorable moments ahead!

Wishing you smooth sailing through these last bits of school and an absolutely fantastic vacation filled with techy delights and endless fun. Enjoy every moment! 🌟😎📱

Flowcharts and/or pseudocode are a low time preference investment of time and effort. In the beginning they merely consume, but over time they pay dividends in efficiency.

I do diagram my code, but I agree it's pointless to go back and keep the chart in sync with the code once you've written it. The better way is to enshrine the intent of the diagram in automated tests.

I personally follow the method in Reliable Software to plan out my code. It keeps your code neat and clean from the very beginning.

https://archive.org/details/myers-reliable-software-through-composite-design/page/n1/mode/1up

If your documentation falls out of sync with the production code you're introducing an unnecessary nightmare for whoever may need to update or maintain the code in the future (which may end up being YOU)

Normal documentation (think ReadTheDocs) are totally fine and I see them as one of the highest priorities next to integration and unit tests.

But flowcharts...?

I'm old enough that when I was taught, flowcharts and pseudocode were considered equally sufficient documentation of what the code was supposed to be doing, and simple enough to be easily understood.

But I'm literally a dinosaur in this field (pre-Y2K) so what do I know

I think good tests are the best documentation for developers, along with high level written material for design principles and how the code is organized, generally.

Then there's usage documentation, which I agree needs to be kept up to date as the functionality of the software changes over time.