Ask HN: What are the “best” logging practices to learn for a Junior Developer?
A short while ago I read in the comment section of an article here on HN regarding things to ask before joining a startup as a developer. The article itself was fairly interesting, but the comment section was booming about logging practices. So my questions are, from a Junior Developers stand, what is considered good logging? How often should I commit? What do I commit in regards to big changes, and what do I commit if there is only a typo correction? What and where are good ways to learn about this if my current job does not practice this?
1 comments
Got a bit confused about terminology, I normally call putting a message in a log file "logging" but here you are referring to "source control" I believe.
I think it varies from company to company, some are more strict that others. Big changes you write a brief summary, leave a line and write a full on description. Small changes a small one line message is enough. Both can reference a ticket too. For pull requests, always squash your commits to one commit and make that as descriptive as possible (if required).
I think it varies from company to company, some are more strict that others. Big changes you write a brief summary, leave a line and write a full on description. Small changes a small one line message is enough. Both can reference a ticket too. For pull requests, always squash your commits to one commit and make that as descriptive as possible (if required).
I was not aware of logging of this type, I am mainly familiar with Source Control. Could you explain to me the purpose of the Log file compared to Source Control? Do you usually use both?
What you are talking about is called "commit messages". Logging is used by an application that you are building to store information that is useful for helping find out what happened in error conditions.
As for your questions, I tell junior programmers to try to commit their code at least once every 20 minutes. That seems like a very short time! However, when you are first starting out, it is easy to take on pieces that are really large without realising it. This helps you keep the work small. It also helps you understand when you are in trouble. If you find that you can't commit something in 20 minutes or so, it's a good indication that you probably need some help.
When making your commit message, you should have a short message at the top explaining what you did. To understand what is good to write, imagine that you want to know, "How do I do X". Ideally you can search through the commit history for "X" and you will find a commit that does it. That's a good way to learn how to do things in the code. Now that you know what you want to look for, try to write a message that makes it easy for the "future you" to find it.
Finally, underneath the short commit message, try to write a brief description of why you made your change. If you think it is obvious, there is no reason to write anything. But I find that I write something about 2/3 of my commits. If you find that you can't think of something to say, maybe you are having difficulty understanding why you are doing it yourself! It's sometimes a good idea to ask someone "I know I have to do this, but I don't really understand why. Can you explain it to me?" Very soon, you will understand most things in the code.
As for your questions, I tell junior programmers to try to commit their code at least once every 20 minutes. That seems like a very short time! However, when you are first starting out, it is easy to take on pieces that are really large without realising it. This helps you keep the work small. It also helps you understand when you are in trouble. If you find that you can't commit something in 20 minutes or so, it's a good indication that you probably need some help.
When making your commit message, you should have a short message at the top explaining what you did. To understand what is good to write, imagine that you want to know, "How do I do X". Ideally you can search through the commit history for "X" and you will find a commit that does it. That's a good way to learn how to do things in the code. Now that you know what you want to look for, try to write a message that makes it easy for the "future you" to find it.
Finally, underneath the short commit message, try to write a brief description of why you made your change. If you think it is obvious, there is no reason to write anything. But I find that I write something about 2/3 of my commits. If you find that you can't think of something to say, maybe you are having difficulty understanding why you are doing it yourself! It's sometimes a good idea to ask someone "I know I have to do this, but I don't really understand why. Can you explain it to me?" Very soon, you will understand most things in the code.
Thank you for your answer! Figuring what to do is not always easy, but I will most certainly follow your tip about "How do I do X".
But regarding logging, is this a file called log, or are there programs where you write the log?
But regarding logging, is this a file called log, or are there programs where you write the log?
There are lots of systems. Obviously the easiest way is to just write some text to a file. There are some libraries that make logging easier and give you some extra facilities (like formatting the time every time you write to the file, etc). There are also some services that allow you to manage logs for a lot of systems. Google has a service called stackdriver. You send messages to stackdriver and then you can go to the stackdriver service to see all the logs for all your systems.
Logging is a big topic and there are as many ways to do it as there are programmers. Some people like to log a lot of stuff (for example, every time you enter and exit a function, some people will write an entry to the log! That way they can see how the program is running. Personally, I hate that :-) ). Some people like to write only error to the log.
Logging is a big topic and there are as many ways to do it as there are programmers. Some people like to log a lot of stuff (for example, every time you enter and exit a function, some people will write an entry to the log! That way they can see how the program is running. Personally, I hate that :-) ). Some people like to write only error to the log.