I can understand that I'm not alone. It's reasonable to think so.
I cannot find support anywhere, though. Which makes me feel isolated. I have nobody to share my struggles with. No place to vent. No space to process it.
Only thing that has helped is therapy. After so many years I'm craving a group, though.
Yes, it is that bad. I used to do it a lot. Didn't help the slightest. As soon as I adopted an "I'll do it for you" strategy everyone's lives started to improve. Even mine.
Yes, it is that bad. I used to do it a lot. Didn't help the slightest. As soon as I adopted an "I'll do it for you" strategy everyone's lives started to improve. Even mine.
The thing about configurable vs non-configurable in this case is that when its configurable then people will spend time debating how exactly they should configure it.
You could always have your editor reformat files in gofumpt's way before viewing code or diffs, and reformat with go fmt when committing.
I've never seen anyone with a workflow like this (lots of people have the second part, of course, but not the first one), nor tooling that makes it a really natural thing to do, but wouldn't it work? There are some pain points if you ever want to pair program or if you use multiple tools to collaborate on code.
> [...] nor tooling that makes it a really natural thing to do [...]
If we ignore the fact that switching between those two formatters would "break" the formatting: There exist clean&smudge filters in Git, which could accomplish this technically.
I see! Seems like neither formatter is completely rigid, and both respect some style decisions made by the programmer, so this level of automated reformatting isn't possible.
Yeah, there's still a few options. But try running `perltidy --help`. Even that doesn't really give you a sense of how many options there are because many of the options are not booleans, but instead take several enum values indicating which style to choose.
I hate formatters like this with a passion. I realised when I tried it that there’s hundreds of tiny editorial choices I make throughout my source files. For example, I use different numbers of new lines between functions in a file to indicate similarity or to group functions together. Sometimes I’ll put a simple function on one line - like lerp or vecadd and then make a block of similar functions in my code. Stuff like that.
By removing the maker’s marks, these tools make my code less readable. While, in my opinion, adding practically no value. I’m more than happy for every line of code to have consistent indentation (of course, but it did already). I also don't have a problem with silly but arbitrary formatting choices - like sorting my import lines. But these tools seem to drive so far for consistency that it costs readability.
These tools, like any tool of the type, bring your code to the 90th percentile. This is good for nine out of ten people, because it improves their code. It's also good for the tenth person, when he has to read the code of the other nine.
If you're the tenth person, and you work alone, or with other fastidious people, you won't like the formatter. That's fine, you don't need to use it.
It's easier to read and refactor code when it's all formatted the same way. Otherwise diffs end up with tons of extraneous noise. Plus it adds needless decisions. If I move a function in a file with Person A's style to a file with Person B's style, do I reformat it?
What about when someone leaves the company? Is it free game to reformat everything they wrote?
Why do you need to put your mark on code at work? It's not _your_ code. It belongs to the employer. The best work is work that is useful and not an irritant long after you're gone.
> It's easier to read and refactor code when it's all formatted the same way.
Sometimes it matters: indentation, naming_style and bracing should match throughout a codebase.
Sometimes it makes no difference: I really don't care about the order of your import statements. It simply doesn't need to be consistent throughout a program. It doesn't matter.
And sometimes making code "all formatted the same way" makes it all worse. I think thats true for spacing between functions. Functions simply shouldn't have the same spacing between them. Nor should lines of code within a function. Whitespace is a wonderful tool for telling the reader how lines of code group together. Gofmt erases all of that to make sure "code is formatted in the same way" - but in doing so, readability is actively decreased.
> If I move a function in a file with Person A's style to a file with Person B's style, do I reformat it?
Thats up to you! Why does everything have to have a right and a wrong answer? Obsessing over this stuff is a pointless waste of time. I guess thats the point of gofmt & friends - that you don't need to think about it. But, you can also not think about it by just not thinking about it, and letting your codebase be a bit inconsistent. Its not a crime. There are no consistency police. You won't go to jail.
> Why do you need to put your mark on code at work? It's not _your_ code.
You have an identifiable style whether you like it or not. Its evident in how you name your functions and variables. In how you write your comments, and where you put them. How you order functions, and where and when you split code between files, classes and modules.
Your style is inescapably everywhere in your work. And it will always have been written by you, long after you're gone.
Are you ashamed of how you write code? Why go out of your way to write and run tools that delete your mark on your work? It doesn't make the code better. Your team will not be more productive as a result. And it doesn't improve quarterly profits.
Like it or not, we're "creatives": That is, we're people who create. The software we write is distinctly our own. Having a little pride in our work is a very healthy thing.
These were the observations that made the most difference in my life too. I also only learned and internalized them after my child was born. He's 3 now and I'm happy to admit that I've grown a lot thanks to him. For the first time in my life I look forward to what's to come next and feel confident to face the challenges.
I use a similar system, but I duplicate and rename the file at the start of each day. Then I remove stuff that got done the previous day. Or stuff that is old and not relevant anymore.
The system has evolved over the years. The greatest thing about it is how flexible it is. When faced with new requirements (new projects, job change, etc) I can just start taking notes in a different way and see if it sticks.
I also commit it to git every 30 minutes using a cron script. Its awesome.
Doing the exact same thing using Obsidian and the obsidian-git plugin, which allows for automatic git push at a given interval. Works very well and it's very convenient to use.
Same setup here and pretty happy about it, only minor issue is the `Update time on edit` plugin creating some conflicts if I have my vault opened on two machines.
I don't usually take the time to write out a daily to-do list, but I do keep one for long-term projects that I tend to lose track of. Each line is a task and at the beginning of the line is the date it was initiated/requested. It's semi-structured but doesn't take any longer than typing out a note.
At the beginning of the month I duplicate the file and rename it for the new month, then I clean out just like you do.
I've tried apps, I've tried tracking systems, and this seems to work best for me for now. I can keep it open all the time in a tab of my text editor which I would have open anyway and it backs up with the rest of my files.
What are the benefits of keeping it in git? Are the commit messages useful?
Not trying to knock the idea, I just can't imagine branching or reverting or being curious about the history of a to-do list. Maybe it could be cool for statistics over time.
But I'm really curious to hear how you're using it!
I find that files under revision control have one awesome property:
they can be ruthlessly minimal.
The intermediate note-to-self stuff, the reference material, the stuff that was cancelled, all can be deleted.
But you have the peace of mind that you can get it back.
This might be especially important if it is a text file you run your life with.
My neighbor needs the name of the plumber we used. What was the amount of the bill? When did I order xyz last? What was the size of the wiper blades of my car?
> My neighbor needs the name of the plumber we used. What was the amount of the bill? When did I order xyz last? What was the size of the wiper blades of my car?
I have a similar setup as far as git is concerned - I use it to push a backup of my Joplin notes (note that I don't sync multiple Joplins, just backup the current one).
Pros: pushes only the differences, keeps history, can be rolled back, works offline (push fails but commit works), offers a time log of changes.
Commit messages are not needed really - the timestamp is enough and rolling back is only for exceptional events (e.g. accidentally deleting important stuff, etc.).
I've landed on a similar process, but one file per sprint instead of one file per day.
I take the last sprint's file, save a copy for the new sprint, summarize what got done to report in sprint meeting, then add the tasks for the new sprint to present at the meeting as well.
Still have JIRA tickets to track tasks in a more formal way. But the text file is far more flexible and easier to quickly edit and view everything at a glance, as well as including things that don't fit cleanly in a ticket.
I do the same in vi/vim/neovim, in a custom filetype with syntax highlighting for TODO items, status markers, tags, code blocks, etc:
"my/work/xxx/201810.notes" 34502L, 1946600B written
5.5 years on this particular file, but I've been using the same system for at least twice as long as that.
The datestamp is the most recent time I thought it might be useful to rotate into a new file. It was not! I find it much more convenient to have everything in a single topic-based file, although I do separate personal from work, and employers from each other.
I've described it as feeling like you're thin, stretched, like butter spread over too much bread. And people promptly reply "like a robot, am I right". It's definitely a thing.
I used to have a lot of trouble when trying to not care about stuff. I didn't care about most stuff, but it used to be impossible to not care about stuff I was naturally interested in.
Now after almost three years raising a toddler I can see clearly when people are behaving like babies. And I'm used to handle a stressed baby who is not cooperating for God knows why. It happens quite frequently and I just play along. I got used to being there, offering support without any expectations (because he usually doesn't want any at that point), trying things out just to give him a chance to take the bait, etc. Now it just feels like life is finally making sense to me. I catch myself applying this to my relationship with my wife, to my work, etc. I feel like I would probably not make these realizations nor develop this mindset if it wasn't for my kid.
I don't have kids, but I can totally understand how that would increase one's tolerance for chaos.
I think I "don't care" because I'm very analytical. Already at a very young age did I realize that this world doesn't make much sense in that it's not very logical, consistent or fair. It's more like a game to play.
So you develop a kind of "humans going to human" attitude where you detach from drama. Or at least pick your battles.
I cannot find support anywhere, though. Which makes me feel isolated. I have nobody to share my struggles with. No place to vent. No space to process it.
Only thing that has helped is therapy. After so many years I'm craving a group, though.