this post was submitted on 14 Mar 2024
82 points (97.7% liked)
Programming
17484 readers
137 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The O'Reilly "In a Nutshell" and "Pocket Guide to" books are great for folks who can already code, and want to pick up a related tool or a new language.
The Pocket Guide to Git is an obvious choice in your situation, if you don't already have it.
As others have mentioned, you're allowed to ignore the team stuff. In git this means you have my permission to commit directly to the 'main' branch, particularly while you're learning.
Lessons that I've learned the hard way, that apply for someone scripting alone:
git
will save your ass. Get in the habit of using if for everything ASAP, and it'll be there when you need itgit
, and keep them close. Usually listening politely to them wax poetically about git will do the trick. Five minutes of their time can be a real life saver later. As that friend, I know when you're using me for my git-fu, and I don't mind. It's hard for me to make friends, perhaps because I constantly wax poetically about git.I've been known to print things to the console during development, but it's like eating junk food. It's better to get in the habit of using a logging framework. Insufficient logging has been in the OWASP Top 10 for a while so you should be logging anyway. Why not
logger.debug("{what_the_fuck_is_this}")
or get fancy with some different frameworks andlogger.log(SUPER_LOW_LVL, "{really_what_the_fuck_is_this}")
You also get the bonus of not going back and cleaning up all the print statements afterward. All you have to do is set the running log level to INFO or something to turn all that off. There was a reason you needed to see that stuff in the first place. If you ever need to see all that stuff again the change the log level to whatever grain you need it.
Absolutely true.
And you make a great point that:
print(f"debug: {what_the_fuck_is_this}")
should absolutely be maturing intologger.log(SUPER_LOW_LVL, "{really_what_the_fuck_is_this}")
Unfortunately I have found that when print("debug") isn't working, usually logging isn't setup correctly either.
In a solidly built system, a garbage print line will hit the logs and raise several alerts because it's poorly formatted - making it easy for the developer to find.
Sadly, I often see the logging setup so that poorly formatted logs go nowhere, rather than raising alerts until they're fixed. This inevitably leads to both debug logs being lost and critical but slightly misformatted logs being lost.
Your point is particularly valuable when it's time to get the system fixed, because it's easier to say "logging needs to work" than "fix my stupid printf", even though they're roughly equivalent.
Edit: And getting back to the scripting scientist context, scripting scientists still have my formal official permission to just say "just make my print('debug') work".
Along a similar vain to making a git friend, buy your sysadmins/ops people a box of doughnuts once in a while. They (generally) all code and will have some knowledge of what you are working on.
That is great advice that has served me well, as well!