Hacker News new | past | comments | ask | show | jobs | submit | nj5rq's comments login

Ubuntu is supposed to be the most intuitive or friendly distro (very arguable), but it's a shame how bad and bloated it is.

I have been using steam in arch-based distros for a very long time and I have had no issues at all running most Windows games (see https://protondb.com). As someone else mentioned, the only real issue might be anti-cheats in competitive games.


Basic/minimal designs are fine, but just by looking at the brand logo the buyer isn't really showing that he supports free open source projects, at least right now. Perhaps adding some tech-specific designs, as the other user suggested, would help associate your brand with that. I wish you the best.


Thanks for the feedback! The plan is to have the brand synonymous with supporting FOSS projects, which will hopefully come over time. We're also looking into different designs that can show this more clearly, but we still want to keep our design ethos of keeping it more minimal and avoiding the current tropes of "engineer clothing"


Source code is not public? I rather read with my eyes.


Say whatever you want, but this is how websites should be designed.


Advocando pro diabolō, I disagree. Since the width just expands to the size of my screen, and I have a rather wide screen, I found this design (or lack thereof) sufficiently obnoxious that I added a touch of custom CSS.

Setting a static max-width, increasing margins, and playing with the font made the page much more readable for me.


It's the first time I ever see the function parameters declared like this:

    int my_function (a, b)
    int a; char *b;
      {
      ... body of function ...
      }
What do you even call this?


K&R C


Altho idiomatic that is perhaps slightly confusing because K&R 2nd ed uses the modern way of specifying parameters. I would prefer to say "pre ANSI C" or something of that kind.


You would be rewriting history if we changed that now. It has been referred to K&R style C since the ANSI standard. The second edition of the C Programming Language was ANSI. My copy of the second edition has "based on the draft-proposed ANSI C" on the cover, but later ones just have "ANSI C". I think mine is almost identical to the ANSI version.

Every copy of K&R that uses ANSI has ANSI written somewhere on the cover. I've seen the first edition, and the content is pretty similar if not identical, save for the ANSI changes. But it is all in the K&R style.


> They really want you but don't want you to think that so they can get you to accept less in the negotiation.

I wouldn't call this shady, it's just basic business. If you want to buy a house, and you want to lower the price, you can't act all excited.


That's an arm's length transaction with a counterparty you'll never see again.

An employer-employee relationship lasts for years, perhaps many years, and requires the employee to act as the agent of the employer, repeatedly.

Would you accept this kind of thing if you can help it from a potential future spouse?

Come on.

They're welcome to try this stunt. They're also welcome to lose their best candidates who would have been most loyal after showing a lack of capacity for loyalty on day zero, and instead select for only those candidates who are equally disloyal in return.


> They're also welcome to lose their best candidates who would have been most loyal after showing a lack of capacity for loyalty on day zero, and instead select for only those candidates who are equally disloyal in return.

I have been contracting for little over 8 years now and I can tell you this happens a lot. Likely, really a lot. Very often.

And then they moan that programmers are overpaid divas who can't achieve anything, while just yesterday their 20-year old HR girl refused yet another NASA level 40-50 year old guy who can practically solve half the tech problems of the company, because she couldn't relate to him in a semi-informal interview.

Yep. This happens. All the time.


> modern HR philosophy seems to be "Always keep the employee/candidate on their back foot." Always make sure the corporation is Alpha Dog.

This is absolutely true. A good way of accomplishing a more submissive team is by making it more diverse. If the members of the team can't relate to one another, the less personal connection, and the more submissive each person is to the guys on top.

I am sure some people will think this is not the case and that companies just care about "making things right".


Learning how to understand, relate to, and collaborate with people who are different from you is part of growing up.


Sure, but do you think that's the reason why there is an interest in promoting diverse teams? For helping the people "grow up"? Besides, that's only true if the differences are relatively small, you can't understand and relate to everyone. You can obviously collaborate with them on a professional level.


I think mature individuals will be able to overlook significant differences in one another and focus on the outcome: helping the team and the business succeed. If I picked up a signal that a candidate wouldn’t meet this bar, I wouldn’t hire them.


Reminds me of working with Japanese teams.

Some of these guys hated each other, but, when the boss said "Go!" they put their differences aside, and all gave 110%, to meet the goal. They helped each other out, shared information, and never sabotaged anyone else's work.

Japan has the strongest teams that I've ever seen, but there's cultural reasons, and it would probably not scale to many other cultures. There's also tradeoffs, and many people would not be happy with those.

If you want a culture that is really good at ganging up on a problem, then Japan is a good bet.

They wouldn't dream of testing for "cultural fit," because that is assumed.


> "Tell me about a change that's been made with the support of senior leadership to improve engineering culture." [...] If the answers I get are too diplomatic, then my suspicion is that changes aren't being made to improve culture.

There is no "engineering culture" in a company. I don't know why everyone loves that word so much.


> There is no "engineering culture" in a company

There is, with out doubt, engineering culture. Culture really means "what customs we use and how we work." Every single company has a set of customs for working. Sales customs, engineering customs, management customs, etc.

Engineering customs, or culture, dictate how the org approaches software development. Code reviews? How deep? Quality checks or not? Is quality encouraged?Level of collaboration between teams and teammates? is there a partnership with Product or does product dictate? How much and what gets written down? How are new solutions brought forward?

Does the company intentionally grow/weed-out these customs? That is engineering culture. You should work somewhere where their customs are things you can adopt. Else, you are not a culture fit.


I agree there is no company culture, unless it is really small. Culture of a team, of a department - sure, but not a company, especially if they have offices around the globe.

There could be company values promoted by CEO, but they are marketing bullshit created to look good for the shareholders.


The larger the group, the harder to have a homogenous culture, sure. But there can absolutely still be a company culture somewhere big. Let's grow the company up to the size of a nation state. Not everyone will behave and believe the same things. But there is most assuredly general commonalities, else there would be no difference between the US and Europe or Asia.

Bringing it back, while I have not worked at Amazon, I know they favor smaller teams that are self owned / directed. Yes, one team may suck (different subculture) and not mesh with another. But, in general, you can expect for some commonality. And it will be very different than a start up culture where everyone shares the root account and password to all dbs and env.

In my ~1k person company they have traditionally favored moving fast and validating code in prod. A new culture pushing higher quality to support larger, more demanding customers is being pushed from leadership and demanded by many developers and teams. The culture is changing. What other word could that be other than "culture"? Processes? Those are just codified customs (which is culture)


But that changes from team to team, and sometimes even from individuals to individuals. It’s rare the company (not faang level) that invests that much in engineering culture.


Of course it verifies from to team. Just like culture varies between any in-group. The culture of a larger group is kinda like the average of smaller inside-group customs.

A company that does not consciously cultivate culture will still have a culture, but it may be like driving a car with no hands on the wheel. At 5 companies so far, someone or group is ay least attempting to steer.


I was going to type something like this. I don't know how the interviews are in your country, but in mine the interviewer doesn't take this well.


Outside of FAANGs, especially in lower cost of living countries (e.g. here in Poland) and high demand jobs (e.g. mid+ software engineers) employers compete for employees most of the time. The reason is simple: nobody's offering above market rates so you have dozens or hundreds of same-y softwarehouse-y companies to choose from. Most of my friends do not apply for jobs because they actually need them. They're looking around for something better while already working for someone.


I was intimidated by these math books, but I was able to find a lot of interesting stuff in "Applied Discrete Structures" by Al Doerr and Ken Levasseur[1]. I was attracted by the "Logic" section, and I was not disappointed. You can download it for free from their website.

> It’s a bit old and unfortunately not free

It's available on Anna's Archive, in case someone is looking for it.

[1] https://discretemath.org/


Hey, that's my school! I didn't have Doerr or Levasseur (before my time), but James Propp did a phenomenal job of teaching the material. I don't know how discrete is taught in other schools but I thought having two dedicated classes for it was helpful.


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

Search: