David
> 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
Of course the specific example in the post seems like it could be one-shotted pretty easily, so it's a strange motivating example.
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.
But performance matters, too, of course. It's tricky to balance them.
Though tls/443 is usually still supported because it's most often allowed by even restrictive firewalls and networks
> 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.
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.
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.
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.
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.
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
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
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.
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.
In essence, I agree with you but I don't think the slides do.
- 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.
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?
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)
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?