So you had to go to the lab to find a computer beefy enough to do your work on.

It's not a home "lab for experimentation.".

It's a home "lab for getting work done."

Additionally, you seem to have diagnosed yourself as having a skill deficit with interviewing. This is also a great position to be in. If you want to work on interviewing, which based on your message it sounds like is your weak skill, then invest time (and maybe money) in practicing that skill with the added understanding you have (and skills you are building) about your managing your ADHD.

One way to think about this is to treat interviewing as a separate skill set; there really are lots of online resources that teach you to interview these days. Practice interviewing as a separate skill set.

You can invest in this skill with money; leetcode and other sites really package this as a service. The benefit to you is not that they will grant you a job offer; it's that they will grant you the opportunity to practice in low stakes environments. There are also places online that are pairing people for interview practice.

You can also reach out to people you have worked with previously and say: I want to practice interviewing; would you spend 30 minutes with me doing a mock interview? People love to help each other.

At the same time continue to invest in managing and understanding your ADHD by working with professionals to develop those skills. Combine the two and some time and you can do this.

You'll get this. Hang in there! Feel free to email me if you would like to talk more.

Here you have an app on everybody's phone that is such a useful tool that the government isn't even thinking to turn off in the middle of a war even when it's providing real time intelligence in the open about what is happening on the ground.

This seems like a great example of how openness in technology can overwhelm even one of the least Democratic governments through transparent infrastructure.

I bet when they were building Google maps back in the early/mid 2000s they never thought their tool would be used for real time tactical war reporting on civilian and troop movement.

I think over time (say the next 5-10 years) there will be upward pressure on remote salaries and eventually they will normalize to being approximately in the same range as the Silicon Valley ones because of economic pressure: everybody is still going to be competing for workers everywhere. The competition is simply going to get bigger as firms realize they can hire top talent from other places and they need to in order to find and keep the best people.

From the lens of the internet as means of disintermediation in society this makes sense. Using this framework to reason about the internet, we might think of different ways that the internet removes barriers to communication; recently there are several social phenomenon where the internet has removed geography as a barrier to communication enabling lots of different social changes. In this framework, salary and employment markets were just slowly going to eventually get geolocation disintermediated. The pandemic has just sped that up 5-10 years. Now instead of taking 10-20 more years it'll take 5-10.

You want to avoid single points of failure, optimize bottlenecks, build in redundancy in similar ways etc. Etc. It's a great insight.

I think this is also the kind of magic that happens when a business is operating well and it's employees have empathy for each other.

If Engineering and Product are well aligned it should be a matter of habit to be looking for and executing on regular projects like Olaf's new menu item or the auto fill of a new account form mentioned here.

As engineers and engineering management we can make sure there is room in our schedules for these kinds of small projects.

And if we develop well our relationships with our product managers we can make those conversations like the one about the form auto filler easier to happen: "this is three hours of work tomorrow that will save this team 10s of hours each week until we get the new system built, it's worth an afternoon one sprint for a developer".

But also what I think is best displayed in this report is empathy :). Organizations that show empathy for their users are ones that tend to be the best to work for because they actually care about people who are using their products and the people who are making their products. And in general, over time, I think empathy builds better customer and employment relationships which then builds better businesses.

We do billions of requests a day on one of the teams that I manage at work, and that team alone has sole operational and development responsibility for a large number of subsystems to be able to manage the complexity that a sustained QPS of that level requires. But those subsystems are in turn dependent on a whole suite of other subsystems which other teams own and maintain.

It requires a lot of coordination with a spirit of good-will and trust among the parties in order to be able to develop the organizational discipline and rigor needed to be able to handle those kinds of loads without things falling over terrible all the time and everybody pointing fingers at each other.

But! There are lots of great people out there who have spent a lot of time figuring out how to do these things properly and that have come up with general principals that can be applied in your specific circumstances (whatever they may be). And when executed properly I would argue that these principals can be used to mitigate the burnout you're talking about. It's possible to make it through those rough spots in an organization (that frequently, though not always, come from quick business scaling -- i.e. we grew from 1000 customers to 10,000 last year) etc.

If you're feeling this kind of feeling and the organization isn't taking steps to work on it, then there are things you can do as an IC to help, too. But this is all a much longer conversation :)

It works really well. It has the playlisting/queueing metaphors that I prefer and it has a decent interface for finding things or even playing all of the albums from a specific artist.

This and the .plan/finger posts from a few days ago are playing to the nostalgia of a better time on the internet. :). Iirc you could also do fully animated .plan files on VAXes at the time.

https://www.irs.gov/e-file-providers/free-file-fillable-form...

I'm hiring for several senior/staff engineering positions working on distributed systems in Erlang with some elixir, go, and exploratory rust sprinkled in here and there. If you're interested please feel free to send an email to the link in my bio.

I mean -- I kind of feel like if you're going to store your core business information in software, you're just going to have to deal with the fact that software has bugs. It's the nature of the beast. So, is it really something they owe compensation for?

Probably they owe a bugfix, that I grant you, but compensation? I mean I guess if there was an explicit contract for the feature that tied compensation to it I could see a good argument that they owe compensation. But do they owe compensation to the good people of Hacker News who are suddenly talking about DDOS-ing the feature? That seems like a much harder case to make.

Anybody with your hand raised should be ashamed of yourself because I bet it's not true :)

Sure they should fix this -- but is this something they should be fined for? Or be DDOS-ed by Hacker News readers? Or GDPR reported for?

It's just not a great way to get help from up and coming businesses to force major financial pain on them and it's certainly not empathetic to what's likely a hard working, reasonable set of people on the other end of this service.