Notices by Fernando Mumbach (fermuch@mastodon.social), page 17

@lain did it end well?

@sydneyfalk

Well, I think we finally understood what both of us meant by those initial comments.

As for me, I'll try to be more wary of my code. I've been thinking, and I wouldn't use most of what I write to teach someone the languages I use, so it might mean I'm overengineering my code or writing too few comments.

@sydneyfalk once you feel comfortable with what you do, at least in programming, it most probably means you're closing doors for new ways to solve problems.

You will never be superior to others in this career. There's no way to be superior. At least not for now. Not everything is solved and that's why we create new paradigms from time to time.
The best thing you can do for your career is to get to the level of switching languages and style as if it means nothing.

@sydneyfalk
> People often assume that "obvious" to them is "obvious" to everyone else.

He assumed his style was better than hers, without re-thinking the why. That's proof enough that the one needing to take some time reading more code was _him_, not _her_ (in this case)

@sydneyfalk it's an easy trap to fall onto, indeed, but he blocked himself into not reading _why_ using strict mode.
Being an expert on a language doesn't mean you know by memory each and every function, but knowing how and when to use the tools provided by your language.

He was just a bad professional, ignoring the knowledge of others because it wasn't what he's used of writing.

Sorry if my comments don't make a lot of sense, I'm a bit drunk.

@sydneyfalk
Oh, so we were talking about totally different topics then.
I was _only_ talking about the perspective of a team, since that's when comments are most needed (if you know this block goes out of the style for the project, but is necessary, then write a comment pointing others (and your future self) why it is written this way and what it does)

@sydneyfalk

> Funny enough, that's what the "hotshot" thought too.

That's a conflict of ego ("my code is superior because I wrote it and I'm older than you").
If he played that card, he was just stupid. If you work with people, you need to, hum, work with people. That's what teams are for, but out of the scope of what I'm talking about (I'm going with: "joining a project with its foundation already set")

@sydneyfalk well, if a lot of my code can't be understood by my team, it means I'm not following the team. I'll need to take some time to re-read how they write and migrate to that style.

The same goes for the other way around: if I can't read the project's code, it means I still need more practice before joining the project. What level of contribution can I aport if I need guidance for each block of code I stumble upon?

@sydneyfalk I've never used Perl, but it sounds like the problem was with the newcommer.

If the project was built around an already defined codestyle, he needed to follow that style, even if it meant learning a lot of things from scratch.

You need to follow a project's codestyle, even if it means getting out of your comfort space.
That's why I follow PEP8 for python, for example. Modern linters help a lot in these cases.

@sydneyfalk
[2/2]

* If you read the code and skip the comment, you might lose an important detail the author wrote in the comment.

* If you make your code as concise as possible, then both you and others only need to read the code, which always yields the same result.

@sydneyfalk

> if you see an extra line there you experience (I'm assuming) the minor irritation of skipping past "another obvious comment"

And losing the train of though on what I was thinking before reading the comment, most of the time.

> someone seeks enlightenment

That might mean that (a) I don't have fluency enough with the language yet, or (b) it's smelly code.

* If you read a comment and skip the code, smelly code might hide behind.

[1/2]

@sydneyfalk that's why I also like types in languages. I can see what a function expects and returns without you writing docs for it and I don't have to read the function.

When I read or write code, I'm thinking in logical terms. I keep in memory a map of how this piece of code connects to the rest of the codebase, but when I read a comment, I have to switch to reading what the author though at that moment was the scope of that block of code.

@sydneyfalk don't take this personal, but I think we see comments in different ways.

I use comments for describing things that are not obvious when you read over the code, or when there's needed complexity in the code (i.e: needed optimizations which are hard to read)

But, if I join a project where docstrings are heavily used, I try to adapt to that style.
That's usually how it goes with python. Every class/function has a docstring, as it is recommended by PEP8.
[1/2]

@sydneyfalk I'm on your side with "it's better to comment than not", but understanding code is part of the job of being a dev. After all, we read and write a lot of code.

Code and comments are different languages. Code is objective, and does only one thing, while comments are subjective and may be interpreted in different ways. Switching between the two is what takes time.

How much you need to comment is normally defined in the project, by following author's rules.

@Gargron @sydneyfalk experience tells you when a comment is needed and when your code is small and concise enough to be understandable by newcomers to the project.

No comments: good luck when someone else or future you tries to touch it.

Too much comments: you're stating the obvious, making people have to read first your comments and then your code.

@rw @xj9 is that lisp? You're truly a madman.

@emelie good luck! I hope you get the job!

@inmysocks on systemd restart=always is a good enough way to keep services running, even if they crash all the time. But don't tell anyone I told you that!

@Gargron they say creative people can see anything as an empty canvas.

@cypnk the real question is why the key bind for taking a screenshot uses the keydown event instead of keyup.