David

That sentence confused me, too, but it's clarified in the next paragraph:

> Children who grow up with high economic connectedness earn 20 percent more as adults on average than otherwise similar children who do not, a gap equal to growing up in a family making 47,000 dollars a year instead of 27,000.

ie: knowing wealthier people has as much impact on your income as growing up in a family making $47k/year instead of $27k/year

This bothered me at first but I think it's about ease of implementation. If you've built a good harness with access to lots of tools, it's very easy to plug in a request like "if the linked PR is approved, please react to the slack message with :checkmark:". For a lot of things I can see how it'd actually be harder to generate a script that uses the APIs correctly than to rely on the LLM to figure it out, and maybe that lets you figure out if it's worth spending an hour automating properly.

Of course the specific example in the post seems like it could be one-shotted pretty easily, so it's a strange motivating example.

> We still start all workflows using the LLM, which works for many cases. When we do rewrite, Claude Code can almost always rewrite the prompt into the code workflow in one-shot.

Why always start with an LLM to solve problems? Using an LLM adds a judgment call, and (at least for now) those judgment calls are not reliable. For something like the motivating example in this article of "is this PR approved" it seems straightforward to get the deterministic right answer using the github API without muddying the waters with an LLM.

No, they've been doing "managing stacks of dependent pull requests" for a lot longer than AI code review. I've mostly been a happy user, they simplify a lot of the git pain of continually rebasing and the UI makes stacks much easier to work with than Github's own interface.

Bandwidth is the limiting factor in a lot of circumstances, and networks are very challenging to manage. Especially with an increasing number of users on mobile connections, reducing network usage can be the right call.

But performance matters, too, of course. It's tricky to balance them.

Video encoding and decoding is expensive! Especially as cameras improve and users' expectations of quality increase.

On the other hand, tls/443 is pretty undesirable for media delivery in videoconferencing because a) it's tcp-based and the required ACKs mean a big reduction in throughput and increase in latency, especially in the presence of packet loss, and b) most video services these days (and open source servers) use webrtc which encrypts the data in transit already--so the tls encryption is a waste of resources

Though tls/443 is usually still supported because it's most often allowed by even restrictive firewalls and networks

I read the article as saying you can't solve everything yourself. That's different than saying you should ignore problems. Instead you need to communicate when you see a problem that you're not positioned to solve, because you don't have the bandwidth or you're not in a position of authority for that domain

> you should be working on properly communicating the gap and its risk to the business (and risk to which part of the business) and NOT attempting to solve everything.

That's way more computationally expensive and only available if the camera is on (and the user's mouth is visible).

Very much this, it takes time to recapture the microphone and it's really annoying to lose the first part of what you say every time you unmute. I lead the video team at a videoconferencing app (gather.town) and we keep the microphone active when you mute for this reason.

As seems to be pretty common, for the sake of privacy we do stop sending audio to the media server. That's a tradeoff, since we're still susceptible to losing a little bit while the audio connection resumes.

Edit: as others have mentioned, also useful to keep bluetooth headsets in two-way audio mode rather than reverting to audio output mode, since that's really disruptive.

As an alternative to a daily chat message, a teammate and I have been meeting for ~15 minutes at the end of the day to talk about what we did and how productive we were. It's been pretty helpful a few different ways. First, it forces me to think about what it is I'm supposed to be doing and figure out the next step. Not knowing how to approach my next task is a huge cause of procrastination for me. Second, it's a chance to notice when I've gone astray, and identify factors that lead to low productivity. (Like that I procrastinate when I haven't broken down my next task into small enough pieces.)

I think for this to work well, it needs to be with someone you don't feel the need to impress. Maybe you have a teammate you trust like that, or maybe you can find a coworker on a different team who doesn't impact your performance assessments. If you have that, this feels different than a standup. Standups easily devolve into signaling to the team that you've done work. Instead, a 1:1 meeting with a coworker who you don't feel the need to impress makes it way easier to be vulnerable and admit when you screwed around on the internet for a lot of the day.

Or: Focus on finding impactful early customers that increase your visibility (and then make them happy). Finding such a great customer may require luck, but that doesn't mean the odds are fixed.

A friend and former boss of mine founded CleanRobotics which makes the TrashBot, a trash can that sorts trash from recyclables: https://cleanrobotics.com/trashbot/

I haven't seen the output so I can't comment on how well they work firsthand, but the idea is pretty cool. As far as I know (which is not far) they don't attempt to sort recyclables by material, unfortunately.

Can you cite some sources for your responses to 1 and 4? Re: 5, there's clearly a distinction between typical mutations, which have no particular effect on the virus' behavior but do allow us to trace infections, and behavioral mutations, which might allow reinfection or make the virus more or less contagious or deadly. I think GP is asking about the second kind, since they're also asking about reinfection. Maybe that's obvious, but considering that, are there sources saying that the evidence so far is that there is only one strain?

Re 6: this is an interesting question. My layman's understanding is that heat usually reduces the spread of disease in temperate climates both because the disease can't survive as well and because people spend more time outdoors and in less people-dense spaces. In somewhere really hot like Qatar, we would expect to see the opposite of the second effect; I'd think people would spend more time indoors with A/C when it's excessively hot outside, increasing transmission rates as the outside temperature rises.

Can you point to a source here? I work on Google Cloud and I don't think I've heard anything like that.

To me that actually sounds more condescending. The statement form suggests not only that I thought of the right way to solve your long-term problem in 5 minutes, but also that I'm confident you didn't know about it. The question form depends a lot on tone, but at least it admits that you might have considered the idea.

Petuum | Pittsburgh, PA & Sunnyvale, CA | Full-Time, ONSITE, VISA | petuum.com

We build Artificial Intelligence (AI) platforms and solutions to industrialize AI and enable enterprises to create and operationalize AI more quickly and cheaply. With $108 million raised in series A and B investments, Petuum is one of the highest-funded and fastest growing AI startups. Recently World Economic Forum named us as a 2018 Technology Pioneer. Join us to bring AI to all!

Pittsburgh:

Senior Software Engineer - Backend https://boards.greenhouse.io/petuum/jobs/4119580002

Senior Software Engineer - DevOps https://boards.greenhouse.io/petuum/jobs/4077368002

Sunnyvale:

Senior Software Engineer - Backend https://boards.greenhouse.io/petuum/jobs/4098278002

(Senior) Software Engineer - DevOps https://boards.greenhouse.io/petuum/jobs/4098286002

Petuum | Pittsburgh, PA & Sunnyvale, CA | Full-Time, ONSITE, VISA | petuum.com We build Artificial Intelligence (AI) platforms and solutions to industrialize AI and enable enterprises to create and operationalize AI more quickly and cheaply.

With $108 million in funding led by SoftBank, Petuum is one of the highest-funded and fastest growing AI startups. Recently World Economic Forum named us as a 2018 Technology Pioneer. Join us to bring AI to all!

Pittsburgh:

Senior Software Engineer - Backend https://boards.greenhouse.io/petuum/jobs/4077378002

Senior Software Engineer - DevOps https://boards.greenhouse.io/petuum/jobs/4077368002

Sunnyvale:

Senior Software Engineer - Backend https://boards.greenhouse.io/petuum/jobs/4095523002

(Senior) Software Engineer - DevOps https://boards.greenhouse.io/petuum/jobs/4104309002

Yes, but they do it because they can. Local talent in those places accepts lower salaries, so they're still getting good people.

There are significant barriers to moving (for the employee) and hiring remotely (for employers) which means the salaries don't equalize across regions very well. Employers are mostly competing with other local employers, so there's not much pressure to increase compensation and salaries change slowly.

Netflix pays exceptionally well and is very selective, and I understand they are quicker to fire underperformers than most. So it is fairly prestigious and ranks at the top in compensation.

Petuum | Software Engineer, Data Scientist | Pittsburgh, PA | ONSITE, INTERNS, VISA | http://www.petuum.com/careers.html

Petuum is building a platform for easily running distributed machine learning. The company was spun out of a Carnegie Mellon research group about two years ago, and we have recently raised a $93 million series B round (bringing our total funding to $108 million) to support our rapid growth.

The Petuum development platform and gallery of AI building blocks work with any programming language and any type of data, allowing managers and analysts to quickly build AI applications without any coding, while engineers and coders can further re-program applications as needed.

What we look for:

* Front-end: Experience with Typescript and Angular is a plus.

* Back-end: Experience with some of C/C++, Go, Python, CUDA, and Kubernetes is a plus

* Data science: We look for at least a master’s in data science or related. Industry experience with TensorFlow/Caffe is a plus.

Really? I didn't see that in the slides. I saw "trade classes or grades for other stuff (but still work to or past your limit)" specifically with the references to not sleeping. As a CMU alum that both hit home and depressed me. I can't, and don't want, to do that kind of shit anymore. Why are we encouraging our undergrads to work to the point of harm in order to excel? Excellence can happen without all nighters, and it's more sustainable that way.

In essence, I agree with you but I don't think the slides do.

Agreed, it seems like a lot of people think about devops as a way to make dev's lives better without actively harming ops. The article does have a section on getting Ops on board with devops, but it's much weaker than the previous section on getting Dev on board. Devops done right should really improve both sides, as it explicitly recognizes the tradeoffs involved with the added automation / processes / policies. I've been reading Google's Site Reliability Engineering book ([1], free online, highly recommend so far) and it lays out pretty clearly how to do devops in a more balanced way. Key points are:

- Define service level indicators (SLIs), metrics you can track to see how you're doing on the things your users care about: uptime, latency, security, etc. For instance, measure uptime as successful responses / total requests.

- Define service level objectives (SLOs) based on your SLIs, e.g. 99.9% successful responses / total requests (aka 99.9% uptime)

- Establish an error budget which controls your deployments. Based on your SLOs you can accept a certain number of errors (failed requests, outages, slow response times, etc) for a given period. If you spend your entire error budget, no new code can be deployed. The deployment shutoff has to be agreed upon in advance and it has to be a hard and fast rule, so it's not ops' fault that dev can't deploy code.

- If you reach your error budget, devs need to work on things to reduce error rate going forward instead of developing new features. It can be tests, monitoring and alerting, rollback process, or pretty much anything, but devs should know that they're doing it so they can deploy more code faster in the future.

I think this makes a lot of sense and helps to align dev and ops on uptime goals. Specifically, dev's ability to push code is now directly tied to service level, and ops is not shooting for 100% reliability. Dev can choose how to spend the error budget, so ops isn't dictating how they do things; and ops knows and expects a certain number of problems, so they don't resent dev every time they push buggy code.

[1] https://landing.google.com/sre/book.html

The mic drop feature did exist; I had the pleasure of actively not clicking it on an email I sent last night.

Absolutely, if you have the budget to build, maintain, and support a custom ERP, it may be the way to go. But I think it's a tiny fraction of businesses where the benefits of that outweigh the extra costs involved. You have to be very large, and your issues with existing systems have to be pretty expensive, before that's the case.

Out of curiosity, do you know / can you share what kinds of problems caused the Peoplesoft investment to fall apart? What issues did they run into?

Excellent point. A fear we see a lot in clients is that if the system's not built from scratch with them in mind, it can't do what they need. But the TCO of a system you build yourself is usually way higher than anticipated, due to project overruns and maintenance costs. It turns out software development isn't trivial, which is why we have companies that just build software.

Working on an ERP startup^, this was a very interesting read for me. Our situation is a little different, because our goal is a customizable platform rather than a single instance built for a single company.

Some points that resonated with me:

Pay your technical debt early: Cleaning up after yourself as soon as it becomes apparent you've made a mess is huge. The most painful parts of our application to use and to modify were built the wrong way (in hindsight) and haven't been overhauled yet. The amount of additional work that has gone into building and maintaining those parts over what would have been necessary is massive. Of course, you can't always know how to build it right until you build it wrong. Take the (tech debt) loan, but make sure you've budgeted for paying it back quickly so you don't keep paying the interest forever.

Show progress and Have clear metrics: These have been very important for us. We started (some time ago) using milestones in our implementations to keep client expectations in line with reality, and to keep ourselves on track and smooth out the effort/time curve. This is probably project management 101, but it seriously helps keep clients happy and reduces stressful last-minute work.

On the other hand, I have to question the necessity of a custom ERP and the cost and effort put into it. "Total effort was about 16 to 18 person years (our team size varied from 3 to 5 over 3.5 years)." It seems to me that a lot of wheels may have been reinvented. In our experience, many companies think they have totally unique processes and data to track, when they're really doing just about the same stuff as their competitors. There can definitely be advantages to having a custom, integrated system, but on the other hand, a more flexible and customizable system can be deployed much faster and cheaper. Not SAP, but there are other options.

Bob: I'm not sure what you can share, but what are the key benefits the company expects to get out of a custom ERP? How big is the company? What is the breadth of the software, here--does it include e.g. accounting, or mostly industry-specific data collection?

On a more technical note, can you expound a little on how Smalltalk factored into the design of the software? Why do you think Smalltalk was good productivity-wise?

^Bizowie (bizowie.com)

In chemistry class in middle and high school, I thought all the safety precautions we took were stupid, given that we were using harmless chemicals to do harmless experiments. I wish this had been around, and it had been required reading--I would have all about that safety gear.

It's easier to expand than contract. When the same decision is faced multiple times, it will be made multiple ways, and it's very difficult to remove one of those options once it's in use. On the other hand, if you remove the decision by standardizing on one of the options, you can always allow the other option later.

Working in Perl, I run into this a lot. When 'there is more than one way to do it' is a driving principle, it's easy to be inconsistent in usage and design. There's a tradeoff here -- it's easier to write code, because you can pretty much write your solution however it pops into your head. However, it's harder to read and maintain, because you have to recognize many many different patterns of usage. When code has been around for awhile, it starts to get an eclectic mix of patterns blended together, which can be frustrating to run into when you're trying to fix that code.

How do other people deal with this? Part of it is language choice, I'm sure. Large companies tend to use languages with less stylistic freedom, which helps teams write code more consistently. But within a given language, how do you balance freedom and consistency, so that people can understand each others' code effectively without being overly burdened by restrictions about how they can write code?

For me it seemed to happen whenever I scrolled up. It was challenging to read through to the end.