trilobyte

I think it's worth separating Twitter the product and its success from Twitter the corporation with financial obligations. The product side will be determined by so many factors outside of any one person's control it's fun to speculate on but that's about it. On the financial side, based on what's publicly known so far, it's not a great situation in terms of servicing the debt of Twitter. Elon can always pay for it out of pocket, of course, but that's not the normal approach anyone would take and as a result it's much more interesting to watch what happens there.

Exactly right. The cities had a long time to implement less clumsy plans but kept caving to local political groups funded by wealthy people. I'm not against those people having their opinions be part of a solution, but up until now it's been almost entirely driven by that group, and they were unwilling to give up enough to find workable middle ground. It was always token concessions. Maybe this will be a wake-up call.

Despite the company having a lot of problems, this is another example where an app like this does not need a huge org behind it.

This is a real inexperienced take about a codebase with a huge number of contributors and users, with a lot of test coverage, that has a history of addressing P0/P1 issues quickly.

Do you have the same concerns about your compilers? Your web servers? "More code, more liability" is a very sloganeering/cargo-cult take.

+1 for this. I have some sense reading the page but would love an ELI5.

This was a headache for me when I had teams reporting to me from Mumbai. I had to create artificial layers of job titles that didn't exist in any of our other regions because there was an expectation of moving up on a regular cadence.

On one hand it rubbed me the wrong way personally, but that's not a big deal and something I could get over, but on the other hand I was regularly having to explain to team members in other regions why promotions in Mumbai were happening so much faster than everywhere else. It was a people and perception problem, but still had people who couldn't let it go.

Looks like the Nature article (https://www.nature.com/articles/d41586-022-04440-7) is more clear about it still being a net loss. Still an important step forward, but it's important to contextualize it.

That's what I was trying to figure out. So is it still a net-negative overall?

Am I reading it correctly that they achieved a ~53% output of energy over input?

Rust, Python, Javascript gives you a broad spectrum of experience and you can probably adapt most of that to 90% of the other languages you'll probably run into.

If I had to pick one of the three, it would absolutely be Python for ubiquity. I believe the thing that makes someone confident and capable in a language is writing a lot of code, and Python makes it really easy to explore a broad range of problems-domains which means you can follow whatever interests or whims you have which will hopefully encourage you to write more code.

There are multiple types of medication for ADHD and as part of working with a psychiatrist they should be trying different options for you. It took me 3 different tries before finding one that worked for me.

Snyk is for security scanning. How is that a contradiction w/ copilot?

Cool, thanks for the reply. It definitely threw me off and if it only supports git as a backend for the open source user it might make sense if it can default that way for now.

Thank you for answering questions. I was poking around Sapling and got thrown off track pretty quickly. Just wanted to init an empty repo but on an Intel MBP I just get an error:

`abort: please use 'sl init --git .' for a better experience`

What's going on here? I couldn't find info in the `sl init --help --verbose` output or in the Sapling website.

On the reproducibility problem, there are several tools for working on the reproducibility at the byte-level. That's a strength of cargo that people can work on those problems and make it part of the ecosystem.

Cargo is one of the best package managers and build tools I've used. They seemed to really look across all of the problems in the ecosystem and try to bring in the best features while leaving it open to extension. I have yet to see another one that checks all the same boxes.

I'm kind of wondering if we work together and talked about this on Tuesday with each other. If so, as I said when we talked, this is the right mindset.

"“The way management kind of works is we never really know who our managers are sometimes,” he said. “We get shuffled around so much that our job codes, our job titles, everything changes. Because they are trying to make progress. With the Max being down, they are bringing other people down, trying to correct the issues and trying to make it a better place.”"

This is a huge management mistake. Teams need a direction, consistency, and time to execute. During that time managers often need to keep things on track and keep up team morale, but also need to know that they have to step back and be more passive while the team is executing. Constantly changing things means the teams are distracted, probably a little frightened, and not operating where they could be.

"We'll save $500k a year in licensing costs and don't need to re-negotiate a contract to update our architecture" has worked for me.

One technique I've used for 8+ years now is an in-person programming problem. The general guidelines are:

1. It is a problem representative of the work the person will normally do in the job (we use an extract of our actual data for it) 2. We provide clear guidelines and criteria for success. 3. They are allowed to implement a solution in any language they choose, using any tools they choose (we ask everyone to bring a laptop with their preferred dev environment, but we do provide one with some common tools for them if they can't). 4. They are allowed to use Google and open-source libraries to help them with the solution (we want to see how they really solve a problem) 5. We are there to interact with them and answer domain specific questions, as well as to offer advice if they are stumbling on something to help them move forward.

I've really, really gotten a lot of good mileage out of this. The range of skills that I've encountered over the years has really surprised me. The problem is pretty straight-forward, and usually involves parsing some JSON, looking at the data, and matching disparate sets of the data together. The basic O(n^2) solution can be done in about 20 lines of code and there is some nuance to the datasets that require them to think through the problem and not what they have memorized in their head. I've had programmers with years of experience from places like LinkedIn take 20 minutes just trying to read a file in from the file system, and I've had people who are self-taught developers crank through a really good solution in the same time. I like being able to see how people are writing code, how quickly they are able to lookup information they might need, and listen to the types of questions they have when trying to solve the problem.

It does scare me when experienced developers can't write FizzBuzz though, in any language of their choosing, in a reasonable time frame. The thing I tell myself is that there are so many "gotcha" style programming interview questions that people might just be nervous that there's some trap waiting for them in the question.

A few years ago I instituted an "interviewing code of conduct" for my teams with a few tenants that we've refined over the years, but the first one was "We will treat every candidate with respect and empathy in our interview process". The team has adopted some attitudes and techniques to do so while also not compromising on the talent or skills we are looking for. We've gotten very positive feedback on our interviews, so we think it's working.

That's a good point. My capitalization of the title conveyed some meaning other than what was intended.

I don't think that's entirely true that you need all of those things to get hired. Your resume still speaks volumes about you. It's just that things like github and stack overflow show an interest in engaging in the larger community of software development, and are a strong signal when evaluating a candidate. Having been on both sides of the table it's important to remember that the person hiring you is taking just as much of a chance on you being the right fit. I think anything makes that decision clearer is a positive.

What about just a way to forward on important images to authorities?

I think the point is that the bugs are being fixed in a new paid release, and not in the release many people paid for.

The only thing, imo, that this does is harm the relationship between people developing software who would like to be paid for it and their customers. If you charge people money for something it behooves you to keep releasing fixes and point releases for it regularly, not to disappear and release a paid upgrade with the things fixed that should be part of the current release. I don't know of any legal or moral obligation to do it, but it certainly is a good business move for the ecosystem.

Wow, you actually stated something that was wrong enough to force me to comment. The beauty of these tools are that they are small, fast, ubiquitous, AND easy to replace with other tools if they fit your problem better. Unix was built exactly for swapping in these small one-off programs and to deny that is to deny the beauty of it's design and to basically ignore the fact that the system is built to string arbitrary programs together to solve complex problems in simple ways.

One advantage of her Javascript replace is that she can drop it on any machine with a Javascript runtime and it will work, unlike sed.

And the real truth is, she wrote something that solves a problem she has, which is the measure of her success, not someones arbitrary comments.