emerongi

I have it on good authority that Putin woke up, took a big fart (the housemaid was surprised), thought the smell was an Ukrainian attack and decided to retaliate. That's how the war started.

Your claims about Putin are just as good as mine.

This reminded me of my own story, when I was 15 and had phimosis. I was embarrassed to talk about it with anyone, so in my desperation I posted about it on a forum that claimed to help kids in need of help. Someone responded and gave me instructions that they claimed had a high success rate at treating the condition.

I followed the instructions for a few months and it fixed it. I went back and sent the biggest thanks to the responder. I did not expect to get any help from a random forum.

There has to be swathes of kids struggling with "embarrassing" (in quotes, because they actually aren't embarrassing at all) issues like this. I hope today's internet can provide help to the ones that have nobody to discuss them with.

Exactly. I like my own farts and I don't mind that everyone else thinks it stinks.

I find the title not very well thought through, because smelling your own farts is unlikely to lead to change.

My farts always smell good to me.

Start small, with things that don't require any preparation or commitment. Go walk a bit, aimlessly. It's a difficult time for you and you might simply need to back off for a bit. Eat well, sleep, exercise.

Definitely avoid any social media, youtube, etc. I'd suggest to limit your screen usage to just your work-life. You do not want to compare yourself with people who are not in your position. Spending time on the internet is not fulfulling.

Once you have a healthy daily routine down (which you might have already), a lifehack is to challenge yourself to get good at something that you would never have imagined yourself doing. The idea is that you will fill your head with thoughts about how to improve, rather than thinking about other things which might be too much to process right now. This is why the "start lifting" suggestions work. You don't have to lift, but simply set some random goal. Avoid trying to achieve some big ambition that you've always had.

Once you're on this path, with time you will recalibrate. It seems you are a social person and I bet you will find other people to connect with.

From my own experience, switching from a remote job to an in-office job helped when I felt too isolated. The job market is tough (from what I've heard), so you can check if you could join a coworking space or simply go to the local library to work. I've had friends that are happy to just work together in the same space.

The point of my response is not to tell you "how to be alone", but helpful advice if you want to make changes to your life, if you are unsatisfied with it. If you are unhappy, you could fill all your time thinking about how unhappy you are. It's not helpful, though. For now, find ways to fill your time, and while you do that, I truly believe you will find your footing again.

I review PRs daily and people are pushing changes that have basic problems, not to talk about more serious flaws. The amount of code an engineer can produce is higher, but it's also less thought through.

There will be more code with lower quality. If you want to be valued for your expertise, you need to find niches where quality has to stay high. In a lot of the SaaS-world, most products do not require perfection, so more slop is acceptable.

Or you can accept the slop, grind out however more years you need to retire, and in the meanwhile find some new passion.

All public culture documents are bullshit. It always comes down to your direct manager and what they believe in.

It's already becoming a common strategy

I've taken mental health leave (not due to a PIP) and my productivity before and after was significantly different. It was great for my employer that I took it. I'm quite sure I would've eventually ended up with a PIP if I hadn't taken it sooner myself, and the best remedy on a PIP would have been to take mental health leave. Not as a strategy as such, but literally because it would have been the best solution (and I think the only one).

Remember what? That people have different preferences, workflows and methods of staying productive?

Someone voiced that they liked a certain tool for a certain feature and suddenly we are judging them for it? I like that people share their thoughts and opinions.

Central to it being that you consider it unjust. The other option is to take into consideration the perspective of the maintainers, find their feedback to be just and then decide whether you want to contribute in the manner that they expect or you're not ready to do that kind of work.

You don't have to stop loving a project just because you're not ready to put in the work that the maintainers expect you to put in.

When I open a PR without discussing it at all beforehand with anyone, I expect the default to be that it gets rejected. It's fine by me, because it's simply easier for me to open a PR and have it be rejected than to find the people I need to talk to and then get them all onboard. I accounted for that risk when I chose the path I took.

Thank you for the PDF version!

Spreading the two parts across separate days would be interesting. There would be an extra element of trying to predict what part 2 will be like.

Within the past 2 months, as I've started to use AI more, I've had this trajectory:

  1. only using AI for small things, very impressed by it
  2. giving AI bigger tasks and figuring out how to use it well for those bigger tasks
  3. full-agentic mode where AI just does its thing and I review the code at the end
  4. realising that I still need to think through all the code and that AI is not the shortcut I was hoping it to be (e.g. where I can give it a high-level plan and be reasonably satisfied with the final code)
  5. going back to giving AI small tasks

Big-picture coding is in my hands, but AI is good at filling in the logic for functions and helping out with other small things.

You can get comfortable with it in 5-10min and after that you will slowly discover that it does absolutely everything you could wish for.

Today I'd honestly suggest to skip learning about git altogether (besides the basics, like branching, staging etc) and just start using lazygit immediately.

I've seen people claim that having a clean git commit history is not worth the time, it takes too long to have it nice etc, opting to just stuff their refactor, renaming and new feature changes into one commit. With lazygit I spend a few extra minutes a day to make it nice and I've gotten compliments for it from others when they review my PRs, because it makes the review much easier.

It feels validating that other people have a similar experience. I simply can't take in that much information. It eventually starts making me feel terrible.

The big issue is that I'm not very good at moderating my intake. I'm a crack addict for information and one small dose will turn into a bender.

My grandparents had a hunting dog. She did not care about "play-time" at all. On the other hand, she got excited when she heard "forest" or "rabbit". Had to be careful with those words.

I think when she wasn't in the forest, she was just waiting to go there again. Instead of ball, it was forest.

Probably by this point my fingerprint is tainted. I appreciate the suggestions, thank you.

Another part of a good code review is to pick your battles. I used to comment on every little thing. Now I have a threshold below which I won't bother unless it would significantly improve the readability or runtime characteristics. Your coworkers' sanity is just as important as the code to ensure that the team achieves their goals.

If I feel like the author might just not be aware of some "better" (subjectively) way of doing things, then I'll leave a "FYI: could also do this in X way" type of comment.

Specialising is only possible in larger companies (more than 500 employees). What size have these companies been? A smaller company might want to hire a backend expert, but who might have to jump into front-end for short periods - sort of an 80-20 split. Communication during the hiring process can be suboptimal for a lot of reasons: one person does the job posting, another does the interview, a third actually knows what the job entails, but they were never involved in the process. You have to account for that yourself: request a "get-to-know-eachother" with team members and ask them what they do daily. That's the only way to figure out what your own job will be like. If they are set on hiring you and are a good employer in general, they will not have a problem with a request like that.

5000 / 17 ≈ 295. Is it a fair assumption to make that a commercial program of equivalent complexity would take 295x fewer man-hours?

Besides all the other good feedback here, I will offer my extremely petty reason why I wouldn't spend much time evaluating this product. In the FAQ, under the "Are transactions fully ACID?" heading, there is a typo: "simultaineously". It gives me the impression that not enough care has gone into an important part of this product. I know it's not a fair jugdgement, but first impressions matter.

Spent months building an application that I knew would never ever be used by anyone. It was actually highly stressful as for some reason it was considered a big opportunity and I was pressured to deliver quicker. I was young and didn't know how to deal with that.

I have now used a Mac for a little while as my main machine. The Apple ecosystem is amazing, but macOS from a UX perspective leaves a lot to be desired. I'd take Gnome or i3 over it any day. The Mac saves me time in my current stage of life though, so it wins out for now.

I recently had to install Windows on a machine and the installation process drove me insane. There's tens of things you need to disable to avoid being tracked on a machine _you own_.

Linux is the only OS that leaves the user in the position of power. Treasure your i3 setup. I really hope it lasts for more decades to come.

Plus, unlike Docker their containers bow to SELinux definitions, so I have repeatedly struggled with containers unable to access mapped directories.

Add the following to containers.conf if you don't want to deal with it:

   [containers]
   label=false

https://en.wikipedia.org/wiki/%C3%95

It's a pretty rare character indeed.

Every non-trivial production system is a distributed system.

In the HN bubble, yes. From the perspective of the average business, definitely not. Or at least, doesn't have to be.

The worst is when you have a passion that you love, but it turns into a job you hate.

Tools like https://comby.dev/ help with the refactoring itself, but I'm never really 100% confident.

When applying for senior positions, a 4-day work week is already quite an ask. I feel like the whole agile/scrum approach is so deeply rooted into modern companies that ironically they are unable to adapt.

We had somebody in a different timezone join the team and there was a long discussion about when we should do stand ups. I almost suggested just dropping it, but that would have been heresy.

This is why working in a company with async communication is quite nice as you can do whatever works for you. I'd do 12h*3 and ~30min on the other days to answer any urgent questions from people working on a different schedule. Sadly I don't work in a company with that culture anymore :(.