matthewbunge

It can depend on the company, but some companies literally don't have a public facing email anymore. I was trying to get in contact with Bank of America of whom I am not a customer because they were (and still are) spamming my inbox and the only human contact I managed at all was via their support Twitter page.

Not that it got me anywhere in the long run.

I think you'd find other physical engineering jobs are very similar at scale.

Most poeple out there building new rail are building them in situations similar to how other people have already built rail: apply known best practices given the intricacies of the current situation. Very few people are doing things like "building the worlds first rail line across a floating bridge" (Seattle I-405).

Even something like DeepSeek in China, wasn't necessarily so much about big AI breakthroughs as it was low level optimization of existing hardware. At the end of the day, even big achievements are built on piles and piles of what seems like drudgery, I guess it's just about feeling like that drudgery is contributing to something great.

I went to a fairly well off public high school for my area and our food was horrific. I'd be curious to hear from anyone who went to a public high school in the US in the last 15 years where the food wasn't horrible, nutrition wise or taste wise.

Man the number of times while I was at UW that a cyclist just sideswiped me while I was in the middle of a crosswalk instead of just reducing speed momentarily. And they didn't even need to be on the road! Burke-Gilman is right there!

My current job didn't come via HN, but around the time I took it I got several contacts for several very promising opportunites otherwise.

In terms of ratio between effort expended to leads generated, those hiring threads are A+.

I generally appreciate the opportunity to do things like dishes/laundry/make fresh lunch during the work week that WFH provides, however I've also had days where it was either ludicrously noisy outside or I was having some technical or it was 100 degrees in my non air conditioned apartment where I thought "man, being in the office sure sounds nice right now".

That's super cool, I've known about OSU for years and had no idea the whole thing was Open Source. I highly recommend anyone who has inclination towards rhythm games who hasn't heard of it to try it out. Very unique rhythm experience, multiple modes, lots of well made free community maps. My only big advice when looking through community maps is to favor ones made in the last 5 years or so, some of the very old maps are a little, stiff, for lack of a better word.

This is an interesting post, because it squares with my personal small team experience with rebase which goes against what I perceive as the common opinion. We were having some serious merge conflict issues and I explored rebase as a tool to avoid them, and in the process we definitely had some lost history. Really once the branch reaches any appreciable level of complexity, I think it's best to leave it as is and start up a new branch if you really need to redirect the PR.

I strongly agree with the author's experience. I recently totally redid my personal site with Hugo so I could simplify it and learn technology at the same time. It's absolutely great if you want a landing page and blog, really terrible if you're trying to actually do anything custom not related to the layout, however the layout tools are plentiful.

> {"message": "Adapter not found"}

That's a new one.

It would appear you linked to the NatGeo API for some reason, here's a link to the actual article: https://www.nationalgeographic.com/science/2021/01/has-scien...

I built my own computer, I will probably continue to build my own computer in the future. I also am very sympathetic to anti Apple arguments framed in the context of their proprietary standards which just seem obnoxious.

BUT.

Neither of those imply to me that people should be building their own computers. My life revolves around computers, either at work, or in my primary leisure time. I am well incentivized to learn more about them. My mom's life does not, it revolves around her garden. My best friend's life does not, it revolves around his wife and son. Could these people learn to build a computer and get a better one for cheaper by building? Yes. Would they rather pay someone or some company a small premium to build it for them so they can live their life? Yes.

This also pertains to the car example leading the article, as well as the existence of professional accountants, stock brokers, paralegals, lawyers, librarians, dietitians, electricians, plumbers, arborists, etc. I could do anything I want for cheaper by putting my own effort into it, but life is way too short to do everything, especially things I have no interest in.

Looks like it's just a basic tutorial on Statiq. Doesn't really answer the question of "Why should I, a .NET developer, use this tool instead of my normal workflow".

I always think debt is a loaded term because a lot of people reflexively hate debt. I think viewing it in terms of Accounting's "Liabilities" makes it a lot more clear.

So the basic accounting equation is Assets = Liabilities + Equity. Any increase in liabilities must be balanced with an increase in Assets (you use a credit card to buy a lamp) or a decrease in equity (taking out a predatory payday loan to cover utilities).

The flipside of this is if you increase your liability to gain an asset worth even more, your equity goes up (take out a loan to buy a house that appreciates in value beyond the interest rate). This is what the goal of technical debt should be, increasing the "equity" of the software.

The current hotness is "Agile". A government contractor friend of mine cynically calls it "Waterfall but with 1 week, rather than 1 year, deadlines". Atlassian[0] has a good guide to generally understand what it is I think:

As far as tools, any of the big git providers (GitHub, Atlassian, GitLab) generally cover most of your bases. That kind of stuff is referred to as DevOps.

[0] - https://www.atlassian.com/agile

Yes with caveats.

The overall test coverage of the code I'm currently unit testing is 63%. This does not mean the remaining 37% will ever get tested, it means around 63% of the codebase is worth testing. What's more relevant is the individual namespaces. For example: Services is at 100% test coverage, because everything in Services actually does something worth testing. Models.DTO, that's more like 50%. I do not need to test every auto getter and auto setter.

I view test coverage like a log curve, more is better, but the returns can get very diminishing.

As far as the tool, working in C# I use JetBrains dotCover.