Hacker Newsnew | past | comments | ask | show | jobs | submit | Kpourdeilami's favoriteslogin

Man, I'd avoid anything Dell. Our whole company switched to new Dell laptops running Ubuntu, and it is a complete mess (and I've been running Linux since '96, Debian since '00, and Ubuntu since '05).

There are OS issues, hardware issues, and driver issues. In terms of OS, Ubuntu/Gnome 3 still hasn't quite figured out hiDPI. Wayland isn't quite ready either. But these are relatively minor nits.

The CPU constantly throttles. It has power management issues where the USB isn't providing enough power if the laptop is running off battery. One of the fans in my 3-month old laptop is making funny noises. I'm constantly fighting limited USB bandwidth on the USB-C port, where I have to decide which 4 of my 6 devices to plug in. I get lots of kernel oopses with dropped/hung PCIe transactions.

And that's just my laptop. The other folks in the company are having similar problems. Basic stuff, like the camera doesn't work at all in the latest XPS 13 on Ubuntu 18.04.

It is pretty frustrating dealing with this relative to my Mac laptop experience which is essentially everything just works.


When you work for very intelligent and driven people, they tend to be disgusted with incompetence or in my case lack of drive, which is the same thing, I noticed. It is completely counter to what they are. This happened to me when I did not have the same passion as one of my supervisors (as a remote contractor working for other clients as well) and did not want to put the same level of care/hours and extremism as this person had. The intelligence part was debatable but he has his skills etc but I know he was certainly obsessed with moving forward as fast as possible and was a standout in his company because of it. You cannot blame him for his drive as in the end it brings results and its who he is from the core. But of course, I disliked him and still do. Regardless, so what. He still is doing well I'm sure. Elon is probably the most amazing human being to ever have lived in terms of intellect/drive/passion/ability etc that I've heard maybe besides Ghengis Khan so of course he is going to be so much more like that to absolutely repel others not inline with his pace and vision. He could be no other way.

100% would recommend doing code reviews.

The most effective way I've found to do code reviews is to create a pull request for the code you would like to have reviewed. Send it out to someone or a few people that you would like to take a look, get them to approve or reject it, and then take a look at their comments and see what you can do to address them.

Some guidelines for code reviews:

1. Build each other up. The purpose of a code review is to make sure the code is good, but also to help the team grow together. If growing isn't the focus, then code reviews can quickly become harmful.

2. Get code reviewed early, often, and in small chunks. No one wants to review a 1,000 line change spanning several sub-systems, and this is the quickest way to get people to just blindly approve or to discourage them from taking the time to review. Smaller changes make it easier to justify taking 10 minutes to look over the code and make some good, constructive suggestions. It also makes it easier for the person writing the code to implement the suggestions.

3. Don't take it personally. It can be easy to let our ego get in the way when reading someone's comment about our code - after all, we might be proud of it after having spent 45 minutes on the 10 lines that someone just said "could be cleaned up"! Keep in mind that code reviews are about growing and learning, building better systems, etc.

4. The review is about the code, not the coder.

5. Honesty is key. Don't be a jerk, but don't avoid making suggestions just because you're worried it might offend someone. That just makes the review pointless!

6. Be willing spend time with the reviewer if you wrote the code, and vice-versa if you reviewed the code, to go over the suggestions made. Sometimes a comment isn't enough to adequately explain something.

I could probably write more suggestions, but I think these cover the basics.

As for tools, I just use PRs. Create one, either add certain people as reviewers or put a link to the PR somewhere that you can ask for reviewers, and then await their approval/rejection/comments. Once you have approval from the reviewers, merge it. From there you can start to build out different processes/rules around it as you see fit, but it doesn't have to be complicated and doesn't require anything fancy.

I would recommend doing them more async as opposed to scheduling "code review meetings" however. These tend to be more wasteful and can introduce a lot more stress.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: