
Ask HN: What are the “best” logging practices to learn for a Junior Developer? - halvardssm
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?
======
paktek123
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).

~~~
halvardssm
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?

~~~
mikekchar
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.

~~~
halvardssm
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?

~~~
mikekchar
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.

