As an IT person, hearing that someone has already restarted to try to fix it, gives me mixed feelings.
First, they might be lying. I’ve had it happen that people tell me they’ve done something when they have not. Restarting is usually an easy one to verify, just check the uptime of the system.
Second, maybe they did everything right, and actually restarted, that’s cool that they tried something before calling in. I appreciate that.
Third, if the second thing is true then, I’m now frustrated, because now I have to get dirty with whatever is happening since a reboot that should have fixed the problem, didn’t fix it. I know it’s not going to be an easy fix. Most of the time, I’m right, unfortunately.
I’m all for users trying stuff before calling in. But recognise that you don’t, and shouldn’t have access to some things. Sometimes that’s administrator rights, sometimes that’s a piece of software, sometimes it’s the ability to turn off the AV/firewall.
It can be a lot of things. If you’re not sure if what you’re trying won’t screw things up more than they already are, then don’t do it. If it’s something simple that you know how to do, go for it. If you happen to get it fixed, so much the better.
“Customer self resolved” is usually the fastest way to get a problem resolved. That’s good for you, for me, and good for everyone.
Lemmy is a selfhosted, federated social link aggregation and discussion forum. It consists of many different communities which are focused on different topics. Users can post text, links or images and discuss it with others. Voting helps to bring the most interesting items to the top. There are strong moderation tools to keep out spam and trolls. All this is completely free and open, not controlled by any company. This means that there is no advertising, tracking, or secret algorithms.
I asked this question ages ago and it was pointed out that “sub” isn’t a reddit specific term. It’s been short for “subforum” since the first BBSes, so it’s basically a ubiquitous internet term.
“Sub” works because everybody already knows what you mean and it’s the word you intuitively reach for.
You can call them “communities” if you want, but it’s longer and can’t easily be shortened.
Meanwhile I had an IT guy think I was just being an idiot. He was so confident I hadn’t checked something. Felt good when I showed him where it went wrong.
As system administrator, yesterday, one worker told me that they accidentally exited email and couldn’t get in, guess what, i just hit the log in button and it entered, guy just wanted a smoke break
Mandating UTC everywhere and eliminating the concept of time zones altogether is all a political candidate needs to do in order to earn my vote in 2024.
Seriously, what is the point of time zones? The only explanation I’ve ever heard is “well if we didn’t have time zones, half the world would be expected to be awake when it’s dark out!” No. We could all just literally adjust the times of our business operations based around when daylight is usual for the different geographic regions as they have the sun shine on them. The physical “zones” of time zones could remain the same, and in those zones “noon” would just mean something other than “12:00.” “Noon” for one region could be 2300 while what is considered “noon” for another region could be 1800.
(And for my next rant: why the 24 hour clock is superior to the 12 hour clock… reason number 1? There’s 24 hours in a day…)
Implementing such a change has another problem: Who gets to have the time-zone that's noon at noon?
Are we going to let the British continue to get away with it? Even the excuse of "that's the way it has to be to keep things simple" would cause the French to revolt. Again. They still don't like to talk about the fact that it's Greenwich and not Paris that's the prime meridian.
Swatch's "Internet time" was a decimal system designed to mitigate the problem because no-one would have any idea what the old time was supposed to be, but people are used to the base-60 system. It didn't and won't catch on.
And it doesn't fix the "0 isn't my midnight" problem, which is pretty close to the original.
It also doesn't fix the "what time of day is it elsewhere in the world" problem, which still requires knowledge of time differences. You know. Time zones.
Too high, duodecimal flips at the 50 minute mark or right after 7:4E. Though you could get away with doubling the length of an hour easily enough with duodecimal or just ignore minutes and seconds completely and make everything just be an hour as the standard measure( so that 7;50 is actually seven hours and 26 minutes). It’s such a better base for doing mental math.
I was using a Swatch-like duodecimal system of 12³ = 1728 beats per day. This is actually more accurate than minutes of which there are 1440 and actual Swatch beats which are 1000 per day.
Since I haven't stated (or decided, for that matter) where the meridian is, we have no idea where this is, but it's clearly morning. Or is it. It's probably 10 minutes to some hour or another, or thereabouts, if midnight aligns with old time somewhere. Which it doesn't have to.
Who gets to have the time-zone that’s noon at noon
I am asserting that we abandon this concept of “noon” having to be precisely when the pixels on the my clock take the form of “12:00”.
Who cares? Just let “noon” be whatever mid-day is where you live.
0 isn’t my midnight
Same thing, why does it matter? Why do people cling to this? Midnight should be when you are mid-way through the night, regardless of what time a clock shows.
It also doesn’t fix the “what time of day is it elsewhere in the world” problem, which still requires knowledge of time differences. You know. Time zones.
I don’t have time zones memorized, so I have to look up this information when I need to know it anyway. I did say in my post that the [time] “zones” would still exist if I had my way with UTC. I do still think it’s valuable to know the operating hours for different parts of the earth- I just think we can track this without having to have the madness that is time zones. However, while answering this, I do feel what you’re saying. Perhaps we do keep time zones, but only as a way to tell time that is secondary to UTC? (As compared to today, where UTC is often an afterthought, if people even think about it at all.)
Stealing from another commenter: Are you OK with referring to days of the week as Tuesday/Wednesday, or do you propose abandoning day names altogether? If you say your local day is Tuesday which doesn't align with someone else's Tuesday, you've still got the old time-zone problem just at a coarser grain.
As for "secondary time" yes. That's called local time. Which is what the initial proposal was trying to be rid of.
Now riddle me this: What time do you have your computer's motherboard set to?
I never said the time zone was GMT, only that the meridian is Greenwich. Subtle, yes, but if the meridian for UTC isn't the one running through Greenwich, let me know.
Actually you only mentioned timezone “who gets to have the time zone where noon is directly overhead” and then went into a rant about England vs France. You never once mentioned the meridian.
So organising a meeting for 03:30 has the problem of that not being working hours for some people, and you have to look up what working hours are in each area. What problem is that supposed to solve?
What you’re proposing is literally time zones but without shifting the actual clock, you still end up with all the issues and you remove the link between the hour of day and the sun’s position for people lol
Plus who gets to decide that everyone switches over and what is the new global time?
You do not still end up with the same issues. Somebody booking a ticket for a hotel room to be available at 1300 from a different time zone than said hotel will not arrive at the hotel to learn that the check in time is different from their expectation.
Regarding “the link between the hour of the day and the sun’s position,” I’m asserting that we should recalibrate this expectation based on time zones, rather than changing the clock to some fictitious time based on “noon” always equaling “1200.”
who gets to decide that everyone switches over and what is the new global time?
“Global time” in this context is already decided to be UTC. And no one gets to decide on the switch. This is a dream that will never come to fruition. 😕
Yes. Many people already work shifts that have them do exactly that (show up to work on Monday, go home on Tuesday).
My first job had me work all sorts of shifts. Anything other than the day shift, I was showing up early or late evening one day, and leaving work early or late morning the next day.
Haha, let’s inconvenience 99.9% of humans so some programmers have a slightly easier life. I’ve had my share of frustration with time zones, but this change is so enormous, that it’s in no way appropriate.
I don’t think it’s actually realistic that this would ever change at this point in the game. I do think we could have adapted to all using UTC if we never started with time zones in the first place.
The things is that time zones are a natural part of the earth. Back when people told time by the position of the sun, people in different places would naturally observe a different time. Should everyone around the globe have somehow established contact and said, hey one day we’re all going to be in constant contact, could you change your sundials to read the time where I am instead of where you are? At the end of the day, although time zones and daylight savings time have created some slight variations on this concept, noon/midday was defined by the concept of the sun being directly overhead. Since the origins of time telling are based on the sun, there is no first place where we didn’t start with time zones. Unless we somehow advanced as a society to create computers and the Internet without having ever created a system of time.
Boy, I would love to live in a place where store hours would be like this. So convenient.
And I’d love to have the change in the day be sometime in the middle of the day so that “see you tomorrow” means sometime later in the day. Or maybe different areas would use different conventions to refer to the time when the sun is out and most people are doing things and the time when most people are asleep.
It would also be so pleasant and relaxing to visit a new country and constantly have to calculate the country’s time offset in my head. There would probably be an app on my phone that I would constantly look at that would convert the time where I am to the equivalent time I am used to. I won’t have a sense of when meals are or when I should expect stores to be open, or when it’s reasonable to wake up without converting to the time I’m used to. Some might say the thing I’m used to is my time “zone”.
It would also be great for TV shows and books to always run into issues when talking about the time because there’s no universal reference.
Even the actual convenience of scheduling a meeting with people in different parts of the world has issues. Now, you know that whatever time you say is the time for all people. But instead of being able to just look up each person’s time zone and see “oh, it would be 3am there, so they’d be asleep”, you’d have to go to some website that tells you what time most people sleep or what time most people eat meals, or whatever, and see by how many hours it differs.
You already have an entire vocabulary for solar time (sunrise, morning, noon, evening, sunset, night, midnight). This being all of a sudden assigned to a different time on a clock does not change things in any dramatic fashion. It would also be a consistent change for your current location, guarantee it only takes you less than a work week to acclimate.
All the things you’ve described I’ve literally been doing for 6 months now. It is not a noticable difference and does not impact me.
Also, a book that says “it was 5 o’clock” is objectively more boring than one that describes the shadows of twilight blanketing the scene in a checkering of shadow. Also TV shows show outside, where solar time is visibly apparent. The specific time is not nearly as relevant.
Also, you already look up time zones when scheduling international meetings, and those aren’t going to tell you about siestas or other local practices which might affect scheduling. Maybe just actually ask the person what times will work when trying to schedule, and now since you’re both using UTC, you both can figure it out together without looking up timezones.
I absolutely agree, and I too hate this stupid idea of “good code documenting itself” and “comments being unnecessary”.
I have a theory where this comes from. It was probably some manager, who has never written a single line of code, who thought that comments were a waste of time, and employees should instead focus on writing code. By telling them that “good code documents itself”, they could also just put the blame on their employees.
“Either you don’t need comments or your code sucks because it’s not self-documenting”
Managers are dumb, and they will never realize that spending a bit of time on writing useful comments may later actually save countless hours, when the project is taken over by a different team, or the people who initially created it, don’t work at the company anymore.
I’ve never had a manager that was even aware of the comments vs. no comments issue. If I ever had, I would have just told them that a lack of comments makes the original coder harder to replace.
Code should always by itself document the “how” of the code, otherwise the code most likely isn’t good enough. Something the code can never do is explain the “why” of the code, something that a lot of programmers skip. If you ever find yourself explaining the “how” in the comments, maybe run through the code once more and see if something can be simplified or variables can get more descriptive names.
For me, that’s what was originally meant with self-documenting code. A shame lazy programmers hijacked the term in order to avoid writing any documentation.
I don’t think they’re lazy, I think they’re not good writers. Not being able to write well is very common among programmers (not having to communicate with written language is one reason a lot of people go into coding) and in my experience the Venn diagrams for “not a good writer” and “thinks comments are unnecessary” overlap perfectly.
And isn’t it such a dangerous overlap! The coder whose writing (in their native language) is unclear, repetitive, convoluted, or hard to follow too often produces code with the same qualities. It’s even worse when the same coder believes “code is self-documenting” without considering why. Code self-documents with careful and deliberate effort, and in my experience, it is the really good writers who are most capable of expressing code in this way.
Its definitely a balance. Good code shouldn’t need much commenting, but sometimes you have to do something for a reason that isn’t immediately obvious and that’s when comments are most useful. If you’re just explaining what a snippet does instead of why you’re doing it that way, there’s probably more work to be done.
Comment should describe “why?”, not “how?”, or “what?”, and only when the “why?” is not intuitive.
The problem with comments arise when you update the code but not the comments. This leads to incorrect comments, which might do more harm than no comments at all.
E.g. Good comment: “This workaround is due to a bug in xyz”
Bad comment: “Set variable x to value y”
Note: this only concerns code comments, docstrings are still a good idea, as long as they are maintained
In my opinion, it strongly depends on what you’re coding.
Low-level code where you need to initialize array indices to represent certain flags? Absolutely comment the living shit out of that. → See response.
High-level code where you’re just plumbing different libraries? Hell no, the code is just as easily readable as a comment.
I do also think that, no matter where you lie in this spectrum, there is always merit to improving code to reduce the need for documentation:
Rather than typing out the specification, write a unit/integration test.
Rather than describing that a function should only be called in a certain way, make it impossible to do it wrongly by modelling this in your type system.
Rather than adding a comment to describe what a block of code does, pull it out into a separate function.
Rather than explaining how a snippet of code works, try to simplify it, so this becomes obvious.
The thing with documentation is that it merely makes it easier to learn about complexity, whereas a code improvement may eliminate this complexity or the need to know about it, because the compiler/test will remember.
This does not mean you should avoid comments like they’re actively bad. As many others said, particularly the “why” is not expressable in code. Sometimes, it is also genuinely not possible to clean up a snippet of code enough that it becomes digestable.
But it is still a good idea, when you feel the need to leave a comment that explains something else than the “why”, to consider for a moment, if there’s not some code improvement you should be doing instead.
Hard disagree on your first point. Name the flags with descriptive name, move this initialisation to a function, and there you go, self-documented and clear code.
Hmm, maybe my opinion is just shit in that regard. I don’t code terribly much low-level, so I’m probably overestimating the complexity and underestimating the options for cleaning things up.
That was kind of just a random example, I felt like there were many more cases where low-level code is complex, but I’m probably basing this off of shitty low-level code and forgetting that shitty high-level code isn’t exactly a rarity either.
I’m with you but sometimes you don’t have the chance in low level. Max you can do is create local variables just so the bits you’re XORing are more obvious. And whenever you’re working with something where that’d be wasteful and the compiler doesn’t rid if it, you’re better off with comments (which you need to maintain, ugh)
Good code is self documenting as in you don’t need to describe what it is doing and it is clear to read. Whoever says that and isn’t just repeating what they heard understands that whenever you are doing something not explicit in the code it should be on a comment.
Workarounds and explaining you need to use this structure instead of another for some reason are clear examples, but business hints are another useful comment. Or sectioning the process (though I prefer descriptive private functions or pragma regions for that).
It also addresses the hint that the code should be readable because you’re not going to have comments to explain spaghetti. Just a hint, doesn’t prevent it. Others also said it, comments are easier to get outdated as you don’t have the compiler to assist. And outdated comments lead to confusion.
I follow these simple rules and encourage my colleagues to do so
If I’m just shuffling jsons, then yes, the code should be self documented. If it’s not, the code should be rewritten.
If I implement some complex logic or algorithm, then the documentation should be written both to tests and in the code. Tests should be as dull as possible.
If I write multithreading, the start, interruption, end, and shared variables should be clearly indicated by all means that I have: comment, documentation, code clearness. Tests should be repeated and waits should not be over 50ms.
What they mean is that the variable names and function names are documentation.
For example changing “for( i in getList() )” to “for( patient in getTodaysAppointments() )” is giving the reader more information that might negate the need for a comment.
I actually agree that “good enough” code can be self-documenting, but it isn’t always enough to achieve my goal which is to make the code understandable to my audience with minimal effort. With that goal in mind, I write my code as I would write a technical document. Consider the audience, linear prose, logical order, carefully selected words, things like that… In general, I treat comments as a sort of footnote, to provide additional context where helpful.
There are limits to self-documenting code, and interfaces are a good example. With interfaces, I use comments liberally because so many of the important details about the implementation are not obvious from the code: exactly how the implementation should behave, expected inputs and outputs under different scenarios, assumptions, semantic meaning, etc. Without this information, an implementation cannot be tested or verified.
Have you ever worked in a place where every function/field needed a comment? Most of those comments end up being “This is the <variable name>, or this does <method name>”. Beyond, being useless, those comments are counter productive. The amount of screen space they take up (even if greyed out by the IDE) significantly hurts legability.
I get what you’re saying. Perhaps I just haven’t had too many variables and such that have had such comments. VsCode shows the comments on hover when you’re in other parts of the code base. Which makes most any comment useful because something that is obvious in one part of the code isn’t immediately obvious in another. Though, that necessitates making comments that actually help you figure that out.
I have worked on larger older projects. The more comments you have, the larger the chance that code and comment diverge. Often, code is being changed/adapted/fixed, but the comments are not. If you read the comments then, your understanding of what the code does or should do gets wrong, leading you on a wrong path. This is why I prefer to have rather less comments. Most of the code is self a explanatory, if you properly name your variables, functions and whatever else you are working with.
One example for self documenting code is typing. If you use a language which enforces (or at least allows, as in Python 3.8+) strong typing and you use types pro actively, this is better than documentation, because it can be read and worked with by the compiler or interpreter. In contrast to documenting types, the compiler (or interpreter) will enforce that code meaning and type specification will not diverge. This includes explicitly marking parameters/arguments and return types as optional if they are.
I think no reasonable software developer should work without enforced type safety unless working with pure assembler languages. Any (higher) language which does not allow enforcing strong typing is terrible.
This is absolutely fundamentally wrong. What you’ve described is what Nodatime calls an Instant, and it’s a very important data class, but there are valid reasons to use other classes.
A LocalDateTime cares about the date and time locally. An event scheduled for 8am every Monday might use this. It would update accordingly if you move locations to a new locale.
A ZonedDateTime can almost be directly translated into an Instant, except that one time zone might change. If you go into or out of daylight saving time, or your region decides to change its time offset. Oslo time is still Oslo time. You use this if your event occurs at a specific time in a specific location.
An OffsetDateTime is like a ZonedDateTime, but instead of being tied to a specific time zone (e.g. “Oslo time”) it’s tied to a specific UTC offset (e.g. UTC+1).
You don’t have to use Nodatime, but you should at least think deeply about what your time objects actually represent and what is the best way to represent them.
It might also work with some right-wing trolls. I’ve noticed certain trolls in the past only monitored certain keywords in my posts on Twitter, nothing more. They just gave you a bogstandard rebuttal of XY if you included that word in your post, regardless of context.
My old reddit account was monitored and everytime I used the word snowflake I would get bot slammed. I complained but nothing ever happened. I really made a snowflake mad one day.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.