mden

A significant part are though and it would be helpful for that segment.

Just curious why you think so. Bash manuals tend to be pretty long and it seems they also provide a quick reference for commands right in the same docs page. Is it the "book" aspect of it?

For anyone who hasn't done interviews and are curious, the interview chain is not vetted in any way or form at most places. Typically in bigger companies there is a one or two hour session where you are told what you can and can't ask from a legal perspective. Sometimes there will also be a tech question bank you might be expected to ask questions from.

Having worked at four companies I have yet to see there being any serious discussions on merits of which questions to ask, the style of interview to be conducted, how to grade candidates reliably, or the amount of help and guidance to give candidates. In short as far as I can tell the whole tech interview process is generally a mess.

I have tried to push for discussions on all of the topics above and most engineers simply do not find the topic interesting enough to engage at length. There's a lot to discuss and everyone complains about the current state of the interview process across the whole field yet few do more than complain. Alas that is life.

As for vetting for "positive-only", I am not sure that's something that can even be done. Usually conducting interviews is part of your performance and you are expected to do them or it will reflect poorly on you as an employee. So every senior engineer or above typically will aim to do some amount of interviews and, let's say you are one of them and you are not very happy, when you get asked by your manager whether you are a positive employee, you are very unlikely to say no.

Also unhappiness is a pervasive quality regardless of title and you can very easily find high level managers and one year out of college engineers that are equally unhappy if you were to ask them candidly. This is a separate topic, but we as an industry have potential to make our workplaces incredibly engaging and rewarding but that potential somehow seems so very hard to achieve.

Great list, two nits.

"Open Source means it has fewer bugs and is more secure."

Maybe not in the absolute meaning of that expression, but I find it true when you only consider the higher quality open source projects, e.g. say the top 10k open source projects. The code that most professional software developers produce at big and small companies alike makes me in awe that their final products work as well as they do.

"Being able to program is the most important aspect of being a good software engineer."

Ehh, I would say this is true. Certainly not the only aspect but if you can't code then you just end up being someone playing office politics all day trying to hide that fact.

Also R

Maybe misunderstood what you meant, but vim's undo is not linear but rather tree-like. You can undo, make a change, and still get back to the initial state. https://vim.fandom.com/wiki/Using_undo_branches

Edit: this also seems to be in the original post

So if Chrome added a donate link, you would be okay with them..?

  and no one is willing to say so.  

Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number.

On the reverse of course it makes sense to have estimates otherwise how should managers or product people decide what should be done next?

A big part of the issue is we don't have good knowledge how to estimate work. It's not a skill that is heavily invested in and is wrongly assumed as an inherent ability.

The first point sounds like a defeatist mentality (of course assuming we share the ideal of our location data not being sold and if possible even stored) - at what point would we be able to push companies away from using location data if we are afraid it will make the others more powerful?

Sure "unmask" their motives, but it's also worth considering if their actions are a net good or not.

While I understand the sentiment of this comment, isn't it still a good thing to reduce the number of companies with this data? As the companies that track your location goes down, it becomes easier to argue against the other ones doing it. Plus in the very least less places that could leak the data, so it would still be some form of progress.

I felt that way when studying math in college, but after sometime I actually came to like the use of "clearly" and the like as it can be used as a check on whether you've spent enough time internalizing the previous information. It's one thing to have a text or a person hold your hand through algorithms or theorems, it's another to be able to do it yourself. So getting hit with a "clearly" that feels unjustified is often a signal to let go of the guiding hand and go back and review until the statement in question does become clear.

I would say that. Most other tools have a "pull" dynamic where the user has made the decision to use them. Instead, while phones also have this dynamic, they also have a "push" dynamic where someone else, or even just an automated notification, can demand your attention.

The second noteworthy distinction is phones' ability to solve many different problems as well as provide many different willful distractions in a very accessible manner. A tool that can be both productive and entertaining requires a higher amount of willpower to use productively without succumbing to the desire to use it for entertainment.

Some of the most productive coding I've done has been in places where there was no internet to temp me with distractions.

My initial impression is the same as the parent. Juxtaposing microservices and KISS seems weird as the "architectural complexity" of microservices is several times higher than a monolith. You're not only multiplying the points of failure but also increasing the difficulty of translating the domain into code, especially when it comes to reading and writing from a db in a safe and efficient manner. Someone will need to come up with an answer to handling transactional operations that span multiple services sooner or later (or I guess the team can just accept some small percent of data corruption, which is what I'm guessing most companies that do microservices actually do, willingly or unwillingly). Ironically I think the benefit of an architect is a lot more evident in a microservice architecture than a monolith.

Edit: though maybe my view on what an architect should do is different? I think of a software architect as the person that lays out the skeleton and foundations of a project and has the answers to hard questions. Very likely someone who actively codes or has solved very similar challenges to the ones being solved.

So would you say you hate 'hate'? If you don't hate 'hate' and it's "absolutely binary" then doesn't it follow you love hate? If you do in fact hate 'hate' then it must also mean you hate yourself.

Absolutism like this often leads to logical traps. Even when it doesn't it's still unhealthy. Besides, the only way to exterminate an idea is to exterminate the people that might embrace that idea which in itself sounds pretty wrong.

Thank you and @hfourm, I will try out the redux solutions proposed.

Maybe this is either an uncommon use case or I'm missing an easy way to do it, but when you have a component tree like A->B->C (-> denoting child relation) and A contains most of the state and B contains many (say > 1k) children, and you keep updating state in A which only affects one or a few of C, the diffing process as I understand will check all of C whether they need to be rerendered. So if you update the state super frequently, let's say on mouse movement, you are doing at least O(C) checks just to update one or so C components.

So maybe you can pass forward refs from A to all the C's and then bypass B in the cases you want to directly trigger rerender on the individual affected C components. Is that the way to handle this scenario?

It's pretty late so the above maybe doesn't make sense, but to try to summarize, having a solution for updating deeply nested children without diffing all of the related components to see if they need rerender.

Thanks for the link, that's really awesome!

Eh, all things equal, the less the number of lines the more readable.

Thanks for the reply!

"The point is definitely not about prepared presentation" - to me this doesn't ring true at all, but I am sure it depends on the person who is getting interviewed. When I'm asked about times I've argued with my manager nothing really stands out but I'm sure that's not an acceptable answer either. Of course there are disagreements but they have never resolved to any serious argument or escalated to involving HR and even if they had I think it would be prudent to avoid talking about them. So I end up having to make up BS about something but now I'm the territory of exaggerating some minor disagreement and what I learned from it and it ends up sounding insincere. So the only way to avoid it is to prepare something for a lot of situations and to some extent rehearse before the interview. I've never had any significant interpersonal issues and I've been in the industry for six years. Most of the questions just leave me in a confused mumbling state as to me they sound a little ridiculous but at the same time I'm not allowed to just say, "no I've never had that as a problem".

Some companies in NY hire for software engineering without requiring a comp-sci degree. Used to work at Bloomberg and a lot of the people there were hired without a classical programming background but still with some programming experience even if not professional; a lot of physics, biology, and mathematics people for example. Then they put them through a 4 month internal coding course teaching them C++, JS, git, etc. and a lot become surprisingly competent. And then they go to Google once they are all trained up :)

Edit: point being is that there a number of companies that don't look only for traditional hires. Networking (via Meetup for example) helps. Also going through a recruiter or (Recurse if you have the time!) is also helpful.

Maybe it's not easier to start depending on languages you are familiar with, but I think after the starting phase it gets easier by having standard libraries for common things like hashmaps, by having a much easier to configure build system, and by having a very solid package manager. Longer term into a project the actual language's features remove a lot of C or C++ snafus you can run into, though in fairness they also make certain common patterns obsolete which can be very frustrating until you get used to them.

Did Screenhero not work with the slack add-on? I think I made an account without an invite recently just to check it out.

Agreed, as long as managers, business, or generally people who talk a lot weren't stationed there. And other people coming for discussion or just to chat weren't allowed either unless it involved the entire team.

One or two seconds sounds pretty long to me. I think I close accidental ad clicks well under a second a lot of the time as I realize what I did without waiting for the site to load.

I'm assuming parent is thinking of Rust. And more generally type systems relying heavily on linear types (I believe).

Why not? Newspapers are fairly complex websites too and React is amazing at reducing code complexity, especially when compared to using vanilla js. There are other libraries that would also work great, but then it's comparing pros and cons and there is little reason React can't win in such a comparison.

On a first look, it looks amazing. This is actually what I've always imagined "graphical" programming to look like.

This unfortunately does not account for different groups having different starting luck. I suppose you can in part handle that by having very large groups but since luck is luck simply the process of selection, even if random, is biased which gives you another problem.

They can effect change in an overall uncaring system.

Edit: From an ethical perspective it can be argued that a person who is "good" but does not help less fortunate "bad" people is not in a morally superior position (however you want to interpret that to make the sentence work).

This is something I've had a lot of problems with. I understand the benefit of small diffs, but I can't seem to find a way to really apply this for any actually meaningful changes. In my experience I would spend some time coming up with a system of multiple abstractions that are interdependent and then getting single logical commit for proof of concept would require hundreds of lines. Splitting the abstractions into separate commits would be confusing so I don't think that's good. Maybe I should stub functions a lot more aggressively and truly aim for minimal. The other problem is when you are replacing an abstraction in an already large code base, the raw number of changes required could easily be in the hundreds or even thousands of lines.