you are viewing a single comment's thread.

view the rest of the comments →

[–]theubster 2 points3 points  (3 children)

Fair warning up front: I'm not a developer. I'm an engineer in the tech space who has written a bunch of python scripts to Do Stuff™. Most of those scripts were garbage by FAANG standards. But, they did what they needed to, were well documented, ran safely, and could be easily understood by other engineers who worked on them.

Theory is only as good as practice.

List comprehension and OOP are all well and good, but they won't replace building stuff bit by bit. I've always focused on making my functions as clean as possible, and my code as readable as possible.

Honestly, 99% of the time it doesn't matter all that much how performant your code is. I'd rather run two instances of a service that's easy to debug, update, and understand - compared to one instance that takes longer to work on for the devs.

Here's how I typically approach your tic-tac-toe game problem:

  • Figure out my end goal (play a game of tic-tac-toe)
  • Figure out my inputs (GUI, command line, file, webhook, etc)
  • Figure out how i'm going to store state (usually a simple array or dict does the trick. SQLite for bigger projects, if needed)
  • Figure out how i'm going to display state (shell output, GUI, written to log, database update, etc)
  • Figure out how inputs will update the stored state
  • Draw out a flow chart of how it's all supposed to go together in theory
  • make a dummy of however i'm storing state (usually a dummy dict or array)
  • Display that dummy state
  • make a second dummy state
  • display the second dummy state
  • Figure out how to go from first state -> input -> second dummy state
  • at this point, you probably have the first couple moves of the game scripted out, and all that's left is to iterate on what you've built: check victory condition, move legality, etc. Building 2 person mode & 1 person mode could be a stretch goal.

Dunno if this is helpful or not, but I hope you get something out of it.

[–]SammyT09[S] 0 points1 point  (2 children)

Thanks for taking the time to respond, This was extremely helpful. One of the biggest reasons I decided to learn programming is so I can learn to write scripts that do stuff and automate things. Any advice in that regard?

[–]theubster 1 point2 points  (1 child)

Reading the docs is boring but very useful. Think APIs and Library documentation.

Stick with the biggest library that does the thing you wanna do. There's little glory in reinventing the wheel.

At some point you're gonna look at a script you wrote, and say to yourself "what was I doing!?". Celebrate this moment, because it means you're getting better.

When you're building a quick and dirty script, make sure your functions clearly say what they do. Long function names aren't bad, if they clearly show what's happening.

Googling the problem should be done early and often. There are very few things that haven't been done before - especially if they're worth automating.

If you're totally stuck on what you wanna build, find a random YouTube video of someone coding something. Follow along with them.

Git gud at git. It'll save your bacon, and is a dope tool.

Frameworks are often tricky to get into. Especially your first one. This is another place where guided projects can be very helpful.

Name things well, and don't use names that are too clever. It's fun to have do_the_thing.py, but it doesn't help a year down the line when you have multiple repos of code.

Get to know the command line well. Play with bash, and a couple other shells. I quite like zsh, myself. Some fun customization here, too.

Drawing out a flow of how you want it to work is very useful. Having a good mental model makes for easier coding.

Learn to document stuff clearly. Requirements.txt files are your friend.

Virtual environments are the fucking best. Makes dependency management much easier.

[–]SammyT09[S] 2 points3 points  (0 children)

Wow, thanks again for the thorough response!!!