Python devops automation developer with 25+ years of experience in application development, including Java, SQL, GIS, and a variety of other technologies. Always looking to learn new things.
Don't be afraid to put comments in your code. But remember that comments are usually for explaining WHY (rather than WHAT). The code itself should be simple enough to show what its doing.
Do the simplest thing that works. Working code is more valuable than showing your "brilliance" with some esoteric approach.
Don't be afraid to make mistakes. But always own up to them and correct them quickly. We all make errors. Just be transparent, learn from them, and do what you can to prevent making the same ones again.
Share your knowledge and discoveries. If you find a new tool, library, or technique that makes your life easier, chances are that it will benefit your team members, as well.
Be gracious and grateful. It's a truism that everyone is fighting some battle that we know nothing about. Lighten everyone's load by showing kindness, compassion, and joy whenever you can.
Comments aren't usually good in modern development. A lot of seasoned devs will tell you descriptive variables are usually better than comments.
E.g.
Instead of doing this:
//this function formats a date to a string readable format and displays the date with the time
Const dateFunction = () => {...}
Do this instead, and eliminate comments:
Const formatDateToReadableString = () => {...}
Avoiding comments keeps your code way cleaner and much easier to read.
This also distinguishes between an experienced and non experienced dev.
Uriel give @timothydjones comment a chance. It's actually not true that comments are a bad thing. I've been a programmer for over 20 years and what I've learned is that comments are very important in your code, even to yourself. The key in comments is to try never to write WHAT your code does, you write WHY that code was made for. Your code must be clear enough to understand what it does. And now yes, to be clear, properly rename the variables, the functions, the same as the parameters. Avoid short names, unless short names are enough.
I agree that we should name or functions and variables in a descriptive way and write code that's as self-explanatory as possible.
But there are still several kind of useful code comments:
code comments that improve tooling (like JSDoc / PHPDoc type definitions helping your IDE annotate, suggest, and warn)
code comments that explain something not obvious, like an unusual requirement / feature request, or a reason for an ugly workaround that might seem unnecessary or erroneous out of context
TODO comments, e.g. remove this workaround when bug 123 got fixed, see example.com/issues/123
Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
Comments aren't usually good in modern development. A lot of seasoned devs will tell you descriptive variables are usually better than comments.
E.g.
Instead of doing this:
//this function formats a date to a string readable format and displays the date with the time
Const dateFunction = () => {...}
Do this instead, and eliminate comments:
Const formatDateToReadableString = () => {...}
Avoiding comments keeps your code way cleaner and much easier to read.
This also distinguishes between an experienced and non experienced dev.
Uriel give @timothydjones comment a chance. It's actually not true that comments are a bad thing. I've been a programmer for over 20 years and what I've learned is that comments are very important in your code, even to yourself. The key in comments is to try never to write WHAT your code does, you write WHY that code was made for. Your code must be clear enough to understand what it does. And now yes, to be clear, properly rename the variables, the functions, the same as the parameters. Avoid short names, unless short names are enough.
I agree that we should name or functions and variables in a descriptive way and write code that's as self-explanatory as possible.
But there are still several kind of useful code comments:
As a veteran developer, the thing I always want is context; sharing the why of the code in both comments and commits.
Exactly! Commits with proper descriptions (and the ticket number ideally) can take you through the code of the feature in steps.