Page 456«..1020..455456457458..470480..»

It Keeps Going and Going and Going – Engineering The Trade – tastylive

tastylive content is created, produced, and provided solely by tastylive, Inc. (tastylive) and is for informational and educational purposes only.It is not, nor is it intended to be, trading or investment advice or a recommendation that any security, futures contract, digital asset, other product, transaction, or investment strategy is suitable for any person. Trading securities, futures products, and digital assets involve risk and may result in a loss greater than the original amount invested.tastylive, through its content, financial programming or otherwise, does not provide investment or financial advice or make investment recommendations. Investment information provided may not be appropriate for all investors and is provided without respect to individual investor financial sophistication, financial situation, investing time horizon or risk tolerance. tastylive is not in the business of transacting securities trades, nor does it direct client commodity accounts or give commodity trading advice tailored to any particular clients situation or investment objectives. Supporting documentation for any claims (including claims made on behalf of options programs), comparisons, statistics, or other technical data, if applicable, will be supplied upon request.tastylive is not a licensed financial adviser, registered investment adviser, or a registered broker-dealer. Options, futures, and futures options are not suitable for all investors. Prior to trading securities, options, futures, or futures options, please read the applicable risk disclosures, including, but not limited to, the Characteristics and Risks of Standardized Options Disclosure and the Futures and Exchange-Traded Options Risk Disclosure found on tastytrade.com/disclosures.

tastytrade, Inc. ("tastytrade) is a registered broker-dealer and member of FINRA, NFA, and SIPC.tastytrade was previously known as tastyworks, Inc. (tastyworks). tastytrade offers self-directed brokerage accounts to its customers. tastytrade does not give financial or trading advice, nor does it make investment recommendations.You alone are responsible for making your investment and trading decisions and for evaluating the merits and risks associated with the use of tastytrades systems, services or products. tastytrade is a wholly-owned subsidiary of tastylive, Inc.

tastytrade has entered into a Marketing Agreement with tastylive (Marketing Agent) whereby tastytrade pays compensation to Marketing Agent to recommend tastytrades brokerage services. The existence of this Marketing Agreement should not be deemed as an endorsement or recommendation of Marketing Agent by tastytrade. tastytrade and Marketing Agent are separate entities with their own products and services. tastylive is the parent company of tastytrade.

tastycrypto is provided solely by tasty Software Solutions, LLC. tasty Software Solutions, LLC is a separate but affiliate company of tastylive, Inc. Neither tastylive nor any of its affiliates are responsible for the products or services provided by tasty Software Solutions, LLC. Cryptocurrency trading is not suitable for all investors due to the number of risks involved. The value of any cryptocurrency, including digital assets pegged to fiat currency, commodities, or any other asset, may go to zero.

Read the rest here:

It Keeps Going and Going and Going - Engineering The Trade - tastylive

Read More..

Microsoft AI engineer says company thwarted attempt to expose DALL-E 3 safety problems – GeekWire

GeekWire File Photo

This post has been updated with Microsoft and OpenAI comments, and additional context from Microsoft engineer Shane Jones in response to their statements.

A Microsoft AI engineering leader says he discovered vulnerabilities in OpenAIs DALL-E 3 image generator in early December allowing users to bypass safety guardrails to create violent and explicit images, and that the company impeded his previous attempt to bring public attention to the issue.

The emergence of explicit deepfake images of Taylor Swift last week is an example of the type of abuse I was concerned about and the reason why I urged OpenAI to remove DALLE 3 from public use and reported my concerns to Microsoft, writes Shane Jones, a Microsoft principal software engineering lead, in a letter Tuesday to Washington states attorney general and Congressional representatives.

404 Media reported last week that the fake explicit images of Swift originated in a specific Telegram group dedicated to abusive images of women, noting that at least one of the AI tools commonly used by the group is Microsoft Designer, which is based in part on technology from OpenAIs DALL-E 3.

The vulnerabilities in DALLE 3, and products like Microsoft Designer that use DALLE 3, makes it easier for people to abuse AI in generating harmful images, Jones writes in the letter to U.S. Sens. Patty Murray and Maria Cantwell, Rep. Adam Smith, and Attorney General Bob Ferguson, which was obtained by GeekWire.

He adds, Microsoft was aware of these vulnerabilities and the potential for abuse.

Microsoft said in a statement that its committed to addressing employee concerns and has established robust internal reporting channels to properly investigate and remediate any issues, which we recommended that the employee utilize so we could appropriately validate and test his concerns before escalating it publicly.

The company said it investigated the employees report and confirmed that the techniques he shared did not bypass our safety filters in any of ourAI-powered image generation solutions. Employee feedback is a critical part of our culture, and we are connecting with this colleague to address any remaining concerns he may have.

Microsoft later updated its statement to add, Since his report concerned an OpenAI product, we encouraged him to report through OpenAIs standard reporting channels and one of our senior product leaders shared the employees feedback with OpenAI, who investigated the matter right away.

Jones provided this response to Microsofts statement on Tuesday evening:

Microsofts response is indicative of why I contacted my representatives and am advocating for an independent,effective reporting solution. I did utilize Microsofts internal reporting process. On December 1, 2023 when I reported this vulnerability to my leadership team, I was instructed to also report the issue to our internal Report It Now security incident system. I reported the issue and later that same day received the following response, which I shared with my leadership team: We monitor Microsoft corpnet and Microsoft user accounts for cyber security threats. This report doesnt seem to be impacting any of the above. I would suggestyou to submit feedback over Open AI website. I am proceeding with case closure.

In addition, as of 5:00 pm today, I still have not been contacted by Microsoft todiscuss my concerns or AI safety recommendations.

In his letter to the state attorney general and federal legislators, Jones writes that he discovered the vulnerability independently in early December. He reported the vulnerability to Microsoft, according to the letter, and was instructed to report the issue to OpenAI, the Redmond companys close partner, whose technology powers products including Microsoft Designer.

After reporting the issue to OpenAI, he says, he didnt hear back.

As I continued to research the risks associated with this specific vulnerability, I became aware of the capacity DALLE 3 has to generate violent and disturbing harmful images, he writes. Based on my understanding of how the model was trained, and the security vulnerabilities I discovered, I reached the conclusion that DALLE 3 posed a public safety risk and should be removed from public use until OpenAI could address the risks associated with this model.

On Dec. 14, he writes, he posted publicly on LinkedIn urging OpenAIs non-profit board to withdraw DALL-E 3 from the market.

He informed his Microsoft leadership team of the post, according to the letter, and was quickly contacted by his manager, saying that Microsofts legal department was demanding that he delete the post immediately, and would follow up with an explanation or justification.

He agreed to delete the post on that basis but never heard from Microsoft legal, he writes.

Over the following month, I repeatedly requested an explanation for why I was told to delete my letter, he writes. I also offered to share information that could assist with fixing the specific vulnerability I had discovered and provide ideas for making AI image generation technology safer. Microsofts legal department has still not responded or communicated directly with me.

Jones adds in his Jan. 30 letter, Artificial intelligence is advancing at an unprecedented pace. I understand it will take time for legislation to be enacted to ensure AI public safety. At the same time, we need to hold companies accountable for the safety of their products and their responsibility to disclose known risks to the public. Concerned employees, like myself, should not be intimidated into staying silent.

The text of his post is attached to his letter Tuesday morning. (See below.)

Update: An OpenAI spokesperson says the company immediately investigated the Microsoft employees report when we received it and confirmed that the technique he shared does not bypass our safety systems.

OpenAIs statement continued:

Safety is our priority and we take a multi-pronged approach. In the underlying DALL-E 3 model, weve worked to filter the most explicit content from its training data including graphic sexual and violent content, and have developed robust image classifiers that steer the model away from generating harmful images.

Weve also implemented additional safeguards for our products, ChatGPT and the DALL-E API including declining requests that ask for a public figure by name. We identify and refuse messages that violate our policies and filter all generated images before they are shown to the user. We use external expert red teaming to test for misuse and strengthen our safeguards.

Jones said he submitted details of the vulnerability via OpenAIs website on Dec. 9, based on the direction he received after initially reporting the issue internally at Microsoft. He did not receive a response from OpenAI, which led him to post the open letter to the OpenAI board on LinkedIn on Dec. 14.

I am dedicated to helping OpenAI and the industry make AI products safer and would welcome the opportunity to assist OpenAI in fixing this vulnerability, he said Tuesday evening.

Asked by GeekWire if he considers himself a whistleblower, and whether he would seek legal protection as such if necessary, Jones responded yes.

His letter calls on the government to create a system for reporting and tracking AI risks and issues, with assurances to employees of companies developing AI that they can use the system without fear of retaliation.

Jones concludes by asking Murray, Cantwell, Smith, and Ferguson to look into the risks associated with DALLE 3 and other AI image generation technologies and the corporate governance and responsible AI practices of the companies building and marketing these products.

Microsoft CEO Satya Nadella is scheduled to appear Tuesday evening on a pre-recorded interview on NBC Nightly News, in which anchor Lester Holt asked Nadella about topics including the Taylor Swift deepfakes. Nadella called the issue of deepfakes alarming and terrible, and said, we have to act, according to a partial transcript.

In a statement last week following the emergence of the deepfakes, a Microsoft spokesperson said the company is committed to providing a safe and respectful experience for everyone.

Although it was unclear where the images originated, the spokesperson said, Out of extreme caution were investigating and have strengthened our existing safety systems to prevent our services from being used to help generate these images.

Microsoft reports earnings Tuesday afternoon, and investors are watching closely for the impact of new and emerging AI products for businesses on the companys revenue.

Here is the full text of Jones Jan. 30 letter, including the text of his LinkedIn post.

AI DALL-E 3 Shane Jones Letter by GeekWire on Scribd

See the original post:

Microsoft AI engineer says company thwarted attempt to expose DALL-E 3 safety problems - GeekWire

Read More..

FOOD ENGINEERING Announces 2024 Plant of the Year Award Winner – Food Engineering Magazine

JBS Prepared Foods Principe Food Facility has won FOOD ENGINEERING magazines Plant of the Year.

JBS Prepared Foods Principe facility in Columbia, MO, facility is a 315,000-sq.-ft. greenfield project situated on 80 acres for salami, pepperoni, prosciutto, coppa and pancetta products under the Swift brand and other private label banners. Stellar performed design-build services for the state-of-the-art project.

Principe became part of JBS Prepared foods in 2021 after JBS acquired Italian meats company Grupo Kings. Principe has been delivering high-quality sliced meats for 75 years and is considered a leader in their craft. Noting the absence of a legitimate Italian meats facility in the U.S., the company sought to create a new tradition that would honor Principes Italian heritage while providing authentic quality dry-cured meats.

The project makes effective use of automation and new technology to ramp up production and throughput of uniquely Italian, old-world style dried meats. The process workflow sees raw product materials received at one end where theyre manually inspected before being loaded into receptacles to be blended, stuffed, formed and tied by an automated system.

Meats are then moved to a second area for drying. Theyre hung from a robotic gantry system thats approximately 18 ft. high that can load numerous racks at a time. The facility relies heavily on automated guided vehiclesthat can automatically track the weight of product throughout the processto reduce human intervention, particularly in the thermal processes. These vehicles are then used to take product to the fermenting, salting or drying rooms (depending on the product) to cure.

The third and final ready-to-eat area is where the meats are brought after curing to be manually peeled and either packaged straight away or automatically sliced and then packaged.

We worked to make sure products move throughout the plant efficiently, from manufacturing to packaging, using strategic equipment layout and technology, including AGVs, gantry robots and conveyor belts, says Jim Oko, project executive at Stellar.

The plant will be featured in the April cover story of FOOD ENGINEERING and the award will be presented at the annual Food Automation & Manufacturing Symposium and Expo, held April 7-9 at the Hyatt Regency Coconut Point in Bonita Springs, FL.

View original post here:

FOOD ENGINEERING Announces 2024 Plant of the Year Award Winner - Food Engineering Magazine

Read More..

D.C. Briefing: Iowa State engineers to report on soybean-based pavement technologies News Service Iowa State … – Iowa State University News…

A crew installs a test section of soybean-based asphalt developed by Iowa State researchers. The test in Virginia is part of a long-term performance study by the Federal Highway Administration. Larger photo. Photo courtesy of Eric Cochran.

AMES, Iowa Iowa State University engineers who have developed and commercialized soybean-based technologies for asphalt pavements will explain their innovations during a briefing in Washington, D.C.

The press and public are invited to Bio-Based Asphalt: Paving the Future. The briefing will be 2-4 p.m. Tuesday, Feb. 6, in Room SVC 203-02 in the Capitol Visitors Center. Please RSVP here.

Congressional staffers and representatives of the American Association of State Highway and Transportation Officials have also been invited.

Speaking will be:

Cochran and Williams have worked for more than 13 years to develop a bio-based alternative to a petroleum-based asphalt additive that extends the life of pavements, promotes pavement recycling and lowers emissions from pavement production and maintenance.

They oversaw hundreds of lab attempts to find the right ingredients, formulations and production processes for a new biopolymer. Experiments producing fractions of an ounce of material revealed soybean oil could produce biopolymers with the desired properties.

The research eventually progressed to development of a $5.3 million pilot plant with a 1,300-gallon holding tank for those biopolymers. More work led to a simpler manufacturing process and a startup company, SoyLei Innovations, which has so far sold about 1 million pounds of biopolymers.

The context for the briefing includes research projects supported by the U.S. Department of Agriculture and the Federal Highway Administration that are comparing the soybean-based pavements developed at Iowa State with other bio-based pavements in long-term, side-by-side tests.

And, two U.S. senators Chris Coons, a Delaware Democrat, and Thom Tillis, a North Carolina Republican in December introduced the Concrete and Asphalt Innovation Act of 2023 to launch a national research and development program for low-emissions concrete and asphalt.

The rest is here:

D.C. Briefing: Iowa State engineers to report on soybean-based pavement technologies News Service Iowa State ... - Iowa State University News...

Read More..

Perils, Pitfalls and Pratfalls of Platform Engineering – InfoQ.com

Transcript

Majors: Perils, pitfalls, and pratfalls of platform engineering, chosen almost entirely for the literate of title. My name is Charity.

Platform engineering, recently, when I've been telling people that I'm going to give a talk on platforms, I get a lot of grumbles like, this is just marketing. I've been doing platform engineering for forever. That's actually true. Heroku, of course, a decade ago was doing platform engineering. When we got acquired by Facebook, we joined the platform engineering org. Then, again, I think that platform engineering as a term that has meaning that people agree upon, it's only really emerged in the last two, three years, maybe five years. Let's do some quick disambiguation, because I think we tend to use these somewhat interchangeably. Platform engineering, I think of as like infra V2. Instead of running the infrastructure yourself, you're abstracting away that infrastructure for the most part. You're like the glue layer. You're responsible for crafting architecture, making choices and stuff. All of my ops people work at Amazon now, so we don't run our infra anymore, but we still have to have infra. Platform engineering, I think, is just like the discipline of doing that. We have a platform org, and for us, and I think for most people, it's an umbrella org where a lot of different teams that don't work on the core product find a home. Then there is the platform team, which is I think what this track is really mostly about and what I'm going to be speaking to the most, which is, the team that has the most responsibility and dedication to enabling engineering teams to actually own their code in production.

The question is, why now? Why just in the last couple of years? The cynical answer is there are companies who want to sell you things. The slightly less cynical answer might be, it's an idea whose time has come for reasons that we'll get into later. If you tend to follow this, you've probably seen this infamous tweet, which is literally what made me angry enough to write this talk in the first place. We can all rag on marketing all day long. There's a lot of bad marketing out there. That's because the good marketing, we don't notice because it speaks to us. Good marketing as a discipline is incredibly hard. It's about helping people who have problems find solutions and craft memorable ways of thinking about those solutions. DevOps is dead. Is it now? I don't think so. I think that's a pretty click-baity thing to say. It definitely struck a nerve.

The reason I think is that there is a kernel of truth there, which is that the need for DevOps is not eternal. DevOps, famously, it means everything to anyone. It's supposed to mean developers and operations folks having empathy, working together, breaking down silos. Developing software is eternal. Running that software is eternal. What happens when there are no more dev teams and ops teams? People are spinning down their standalone ops teams left and right. Meanwhile, the need for operational expertise has never been greater. I think this is really exciting.

When you look at software engineering careers, or building software over the past decades, it started with engineers who would telnet into their user terminal, would telnet in and open files in them and just edit it right there in the cgi-bin on the server. You write code, and then you reap the consequences. You write it, you run it. That got really complicated. We started to specialize. We're like, this is too much for one person to do, there's too much specialist knowledge, ok, you're going to write the code, we're going to run the code. In hindsight, I believe that was a mistake. You can understand why they did it, doing the best that they could at the time. It really was a mess. After a decade or two, DevOps emerges to knit the streams back together. Ultimately, what are we heading to? We're heading back to where we started, where you write code, and you run your code in production. You write it, you own it. You build it. You buy it. I think that this is a good thing in so many ways. The reason it's happening now, is that we can't not. Systems are getting so complicated that the idea that dev could do one thing, ops could do another, you're saying the line of abstraction is right there. You don't have to run it to write it, and vice versa. We were basically operating these systems, like they were full of little black boxes, just like, can't look under the hood. We're just going to set up a bunch of redundant things, and that really doesn't work anymore. You really have to open the hood and look underneath, if you want to run your systems.

The reverse is just as true. I don't think you can do a good job of building systems, unless you're exposing yourself to the consequences. Unless you're being on-call for it. Unless you've got your nodes in production every day. Unless you know not just what it's like to debug problems but what good looks like. This is one of the big trends that's really like the tectonic plates that it's really leading to platform engineering. The second one is, of course, as we all know, we're all moving up the stack and infrastructure is becoming truly boring. For those of you who are as old as me, do you not remember what it was like to have to call a taxi cab, get a ride to the Colo at 1 a.m. to flip the power switch. We didn't have remote yet, much less an API. Kernel crashes were just like another Tuesday. Now it's like, a kernel crashed. As much as we joke about how terrible it is, and it is terrible, we can take so much software for granted now, it's absurd.

We're decoupling infrastructure from operating software. Infra is becoming something you can just buy in units. It's like a fungible resource. I'm going to have n more units of compute, amazing. Platform engineering is what's emerging from this realignment. Does that mean that this is actually true? It's not. No, you have a platform engineering org, which is responsible for it. There's all these ragged edges. Other people's APIs are exposing way too much about their systems. You're responsible for that. Platform engineering is the ultimate glue role. You're literally gluing together hardware and software. The reason that I think that this is so much fun, and that people who have done ops for years find this interesting is because we do it by running as little infrastructure as possible. A really successful platform engineering team is really good at reusing components, making good choices, not having to change them too often, not having five different kinds of relational databases. It is way harder to run a little bit of infrastructure than it is to run or walk, way harder.

This might sound obvious, but let's detour to, what do we mean by infrastructure? When I think of infrastructure, I mean the code you have to run in order to run the code that you want to run. There's two kinds of software in the world. There's the stuff that is your crown jewels. It's your software. It's the software that makes you exist as a business. It's what your customers care about. It's what you have in your Git repositories. You're expected to know it intimately. You're expected to be responsible for it. The change rate is, hopefully, many times a day, or many times a week. The difference is like between words, like macroeconomics and microeconomics, or quantum physics versus regular physics. They operate in two different planes, because infrastructure changes at the rate of like Debian dist upgrades. You shouldn't have to know it intimately. The whole point of infrastructure is to not have to know it intimately. The whole point of infrastructure is to be able to take it for granted.

This is a fact that I really vigorously resisted for a lot of my career, because I'm really proud of being an infrastructure engineer and an ops person. I know just how much depth and how much art there is to running systems well. Maybe it took me starting my own company to realize. You might be great at it. It may even be a competitive differentiator for you that you can do it really well, but it's still a cost center, which means you still want as little of it as possible. Having a team that is skilled at minimizing that is an incredible asset. There are lots of reasons. The cost of hiring engineers is way more expensive than the cost of paying for software, in general. The only reason that really matters is that, in business, you win when you focus. You almost never lose for lack of resources. You almost never lose for the mistakes you make. You very often lose because you did not take the resources you have, and focus it nearly enough on something that will let you win. Software is great at distracting you. Focus is really important. Within your platform org, you may have a platform team which composes infrastructure, the product, unlike our platform where it looks a little bit like this. It's got everything from deep subsystem teams. We accidentally had to write a database. That lives in platform for us. Never ever write a database. Tell this to your children and your children's children. Ours lives under platform. Frontend developer experience. I think it's interesting how much we talk about platform. We're really mostly talking about backend platform-y stuff. The pure platform teams are the ones that we're talking about here.

What I wanted to do is just talk about some of the traps and perils and pitfalls of trying to run one of these platform teams. The number one pitfall is running too much software. Doing less is way harder than doing more. There are all these archetypes of engineers, but the archetype that I think is really successful on platform teams is the one that don't necessarily generate a lot of code. They might spend a couple of weeks researching something and ultimately come out with five lines that save the company a million dollars. It's very high leverage. Another aspect of this is just, naturally you leverage vendors as much as possible. Platform engineering in general is such a high leverage place to sit. You are wielding so many resources. This is probably very obvious to everyone, but I was thinking about this the other day, just the way that, if you're in a platform team, and you're choosing between all these vendors or whatever, you're paying tens of thousands of dollars to wield their tens of millions of dollars of engineering expertise. That's a lot of power.

I think a lot of this really starts with being crystal clear on what infrastructure means to you. It's not always as clear as you might think. You will never be able to outsource your core differentiators. I'll give you an example. Kafka sounds like infrastructure. For us, it is not. It's a core differentiator for us, because it's basically part of our database. We've had opportunities to outsource Kafka. I really like the Confluent folks, I'm sure they would do a much better job than we do. At the end of the day, we know that there are going to be times in the future where we are absolutely going to have to understand how to be good Kafka operators, and debug really sticky problems, and be able to get down into code, if we have to. We know that we rely on that heavily, and we do some weird things with it. For us, it's a core differentiator. If the idea of telling your customers, "I'm sorry, we filed a ticket, we'll get back to you when our provider fixes this," if that makes you just like die inside, it might not be ok to outsource. You should outsource as much as possible, but you can't do it for everything. This reminds me of something that my friend Peter, pvh likes to say, which is, the best code is the code that doesn't exist. The second best code is code that someone else writes, maintains, and you get to use. Everything else is terrible.

Pitfall number two is, relatedly, writing too much software. This is something that I'm sure everyone here knows quite well, which is just, the more surface that you have, the slower you can go. I've seen platform teams do things like prototype up something. Lyft started this way with Envoy, I think. They prototype something up and got it running in production. When they're like, ok, we're really going to use this and rely upon it, they handed it over to a real engineering team whose full-time job it was going to be to do that, or maybe that and some other things. Because the rhythms of being a software engineer, and writing software all day, and maintaining it are very different than the rhythms of a platform engineering team where you're lucky if you get to do that. If your platform team spends a lot of time writing software, something's probably wrong. They're probably not able to focus on some of the operational aspects of their job. Platform teams are really uniquely between these two tectonic plates of infrastructure and business code, which means that they get dragged in all kinds of different directions.

Pitfall number three, this might actually be the biggest one, is not letting/making product teams own their own reliability. If you're in the frontline on-call rotation and getting paged for their services, not good. Not good for you, not good for them. Like everything, nothing is ever 100% true. If you're in this situation, I wouldn't just go back and go, we have to change this. There are reasons why everything gets into the situation that it's in. I think that having platform engineers in a position of frontline operational alerting, should only be a temporary thing, a very temporary thing, because you don't own it, they own it. They should be better at running it than you should be. That's not your job. In other words, do not let yourself become a rebranded SRE team. SRE customers are your customers. SREs are responsible for things like SLOs and SLIs, or SRE is consulting with product engineering teams. However yours is configured, those are their customers. Your customers are them. Those engineers are your customers, not the customers who are the customers.

Pitfall number four is not giving engineers enough tooling to understand their code as well as operate it, or giving them ownership without empowerment. This is a mistake that we made hardcore at Parse. Any of you remember Parse, mobile Backend as a Service? Dearly departed. I will never forgive Facebook ever. Do you know what they did? It's not that they shut Parse down. I understand. I accept business realities. I will never forgive them because other companies wanted to buy it and they were just like, no, not worth the paperwork. This is what we did at Parse, we gave software engineers all kinds of rope. "Here, you can use our SDKs to write queries, and we'll just run them on the database, we'll make it work for you. We'll do all the indexing. We'll try and make it more performant for you. We'll do everything. All you have to do is sit in your IDE." Inevitably, they made some errors, like composing. It's actually surprisingly easy to compose a query using an SDK that actually compiles something, it does like five full table scans. I never knew you could do that many full table scans until I used MongoDB at Parse. They couldn't see, they couldn't tell. From their perspective in the SDK, it looked completely reasonable. You can't always tell what order JavaScript is going to decide to do things in. In retrospect, we gave them all of these powerful tools. The only thing that they could do to try and debug it was like, add some print statements, and pray. We could go debug it. We could do all this stuff, but like, we really didn't help them help themselves at all. The result of that, of course, was that we were miserable. Because they were constantly, reasonably, they're like, why isn't my stuff working? We're just like, you're a terrible customer. They weren't terrible customers, that was a very reasonable thing to expect.

Pitfall number five, it's being confused about who your customer is. There are SLOs and everything for external facing services. You do need to measure how well you're doing. What kinds of things should you measure? How long does it take someone to spin up a new service, or to add an index, or to do any number of common developer tasks? I think one of the most interesting things that I've seen in platform land ever, is the stuff that Abby Bangser is doing, where her startup is actually making this API for platform teams. Right now, we're empowering developers, everything's wonderful. The point where we resolve these things is the Git repo or the repository. You're still asking them to understand and do a lot of stuff. You're asking them to maybe understand Terraform, CloudFormation, whatever you're using to spin up your infra, and all this stuff, as well as their software. What if you could make an API endpoint for them to hit, and it could do it for you? Because you're always getting these random requests like, I need to be in the admin permissions for this thing. What if you could just check which MOO group they're in, and then having that API endpoint to automatically do that. I just think that's dope. I think this absolutely needs to exist. They need to hurry up and build.

This is the other biggie, which is not running your team like a product team. This is something that I am embarrassed to say, it took me a long time to realize, because I am an infrastructure engineer, I was not taught how to work with product managers when I was we. I've never had to collaborate with designers and do discovery and all this stuff. If you're like me, the number one piece of career advice I give to almost every ops engineer is, learn to do this. It is so important. This is the state that we're all trying to get to when we get out of firefighting mode, when we're getting out of all of the crap and just like being super reactive, and having everything that you do be done because it absolutely has to be done, or you're going to die. The next generation beyond that isn't just, you get to sit there and write software and anticipate these things. It's actually operating like the product org. I think this is really exciting. The stuff that your platform team should not spend time on is stuff like firefighting and stuff, but the stuff that they should spend time on, things like this, figuring out what the golden path is, talking to your stakeholders, building champions throughout the org. These are not muscles that your typical backend engineer has. Working with, not only product managers, but designers. If this sounds weird to you, think of your favorite Unix tools and ask, could this be designed better? Building out a roadmap, just communicating and baking in feedback cycles. If you work at a large company, yes, to some extent, your execs can go, "You will use this tool. I don't care if you like it or not. I demand you use this tool, because I'm spinning that tool down. If you want to have a job, you have to use this tool." Not ideal, does happen. That's not the world that we increasingly live in. It's not the world that you want to live in. This means not just building something, and then tossing it over the wall, but building in feedback from before you begin building, all the way through its lifecycle. As long as it's still running in production, as long as somebody's still supporting it, you should be getting feedback from your users on how to make it better. There are many reasons to do this. One of my favorites is because it actually reduces the number of bugs that you then have to firefight under duress.

Pitfall number seven, is very relevant to us all now, it's not paying enough attention to cost and spend. Cost is absolutely indistinguishable, inseparable from architecture and planning. These are muscles that I feel like it was a nonzero sum phenomenon, nonzero interest rate phenomenon. Money, we don't live in that world anymore. We have to pay attention to how much stuff costs. This is good. This is an unalloyed good thing for us. I'm excited that we get to build these muscles again. I think that not being able to translate the work that we do, the value that we bring into either a business language, business schools, or the universal denominator of money has really held us back. Even at highly technical companies, I see this phenomenon where VP of engineering, CTOs aren't exactly considered top-tier execs. They're not really the inner circle. I believe that this has a lot to do with the fact that they're not speaking the same language as everyone else. There's still too much work creatives. Don't look at how the sausage gets made, just trust me. We can't be an equal stakeholder with that attitude. I think every engineering manager should be given a budget. You could have people. You could have vendors. How do you want to spend this budget? I feel like we'd make such better choices if everyone throughout the org, and it feels grubby, and a little bit painful, but only at first, after a while it's just another variable. It's just another constraint. Constraints are what fuel creativity. Because, ultimately, the money isn't about the money, it's about efficiency. It's about doing more with less. It's about doing great things with the team that you have, instead of automatically going, let's hire another team. I feel like this uncontrolled growth leads to what I think of as the software development death spiral where everything gets bigger. Everything's waiting on each other a little bit more, and everything gets slower. Now everything gets slower, because it's slower. Efficiency has not been an area of focus for us as an industry.

Cost really matters. We're used to thinking about this when we're doing build versus buy. That's not the only time that we need to think about this. I really think that it doesn't sound very great, so I don't think it'll catch on. I think of platform engineering as being, in large part, vendor engineering. It's incredibly high leverage. A huge part of being a good platform team is not only choosing and evaluating vendors, making the right requests and demands of them, so that you're a good customer, and so that they're a good vendor. Being able to see around the curve and go, your roadmap is not going to align with ours. The decisions that you make are not just about today, they're about the next five years. Then, once you've made your choice, then building libraries and helper functions and providing a really pleasing interface to the engineers who are using your tools internally. If you make the right thing easy to do, and delightful, and fun, and the wrong thing hard to do, your job gets so much easier.

Pitfall number eight, this I feel like is a meta point, it's like being a juggler. You've only got so much bandwidth. Great engineering management is not just about the touchy-feely stuff. It's not even just about strategy stuff. It's the ones who know how to right-size the amount of work that they're signing their team up for. The ones who know how to push back and say no. The ones who when they're asked to do more, who will ask, and what do you want me to put down? Right-sizing your workload is difficult on every team, but I think it's uniquely difficult on platform teams because there are so many different fronts that you're always fighting on. Constantly looking for ways to deprecate, delete, shed responsibilities, hand things off, communicate that things are being spun down. Will Larson has this great post about migrations. I remember the part where he was talking about, it's the only real way to keep up on technical debt. If you think about computers, if you're working with computers, everything's always getting worse all the time. We just live in a state of entropy. That's fine. You spin up something shiny and new, and right away, it attracts bugs, and customers, and users. It's a headache. The longer time goes on, the more of this you just accrue. Unless you are very consciously leapfrogging this and making decisions that allow you to not just upgrade and offer something better, but turn things off, deprecate them, get them out. Make it so that instead of five different choices, you have one choice, and it works really well.

I made a little rude thing here, how to tell if your platform team is really a platform team or not? Because it turns out, most of the ones I talk to, are not. Are they responsible for SLOs, service uptime, reliable customer experience? No, they might be a platform team. Yes, they are not a platform team, in my opinion. Bottom line is platform teams are responsible for developer productivity. This is such an incredible mission. The Stripe Developer Report shows that 42% of our time, we just straight up waste it. That's just the low hanging fruit. That's not even talking about the times that we're making progress on stuff we shouldn't be doing. I feel like these are the keys to the kingdom, if you really care about having an impact, if you really care about unlocking value. Not everyone does, and this is fine. If you're someone for whom your sense of satisfaction and joy is tightly connected to making change in the real world, platform teams are where you want to be. Product engineering teams and SREs are responsible for customer experience. This is unfortunately the sentiment that I see many platform teams operating from. "No, they won't." You really do have to make sure you're building a platform people actually want and need. I feel like starting with the state of humility about this, like if you're the typical engineering team, you need to be not just literate at product stuff, but good at it. I think starting with humility and curiosity, and really starting to ask questions of your designers about how. How do you build something that you know people will love and use, is a really good place to start.

Vendor engineering is super important. Cost is part of architecture, high leverage. It's not enough to just know how to write code. Automation is not actually software engineering. This is the natural end state evolution. I feel like, for some of us who come from ops land, this can feel like the end times. There are people who are shutting down ops teams and talking about how. Forget shitting on DevOps teams. People even talk about how crappy ops teams are anymore. From my perspective, operations engineering has always involved writing code. It's incredibly difficult and challenging, but nobody wants to hear this stuff. I feel like if there's anything you should take away from all this stuff about platforms, it's that, your work is more vital than ever. It's harder than ever. The stakes are higher. There's less of it. There are fewer people relative to the number of engineers that are out there who understand how to build resilient, reliable, healthy systems. I feel like we should approach this world with confidence and self-assuredness. The world still needs us, and always will. The hardest part of software is operating it: always has been, always will be. I think that with the advent of ChatGPT, the whole world is about to discover this. For a long time, it's been like writing software feels pretty hard. This is pretty hard. It must be pretty hard. Now that writing code is cheap and easy, everyone's going to realize that the real challenge in software is and always has been understanding it. In conclusion, computers are terrible. Everything dies.

Participant 1: Just wondering if you have any suggestions about measuring the impact of platform engineering work across the organization. Also, just any thoughts about observing, the tooling and SDKs and things that are part of the developer experience, kind of measuring those things [inaudible 00:36:04].

Majors: I feel like we're pretty early on in trying to figure out how to do this. The thing that comes immediately to mind for me are just, what are the things that your engineers end up doing? Spinning up a new service is something we always talk about. How often do you really do that? For most of us, it's not the most common thing that we do. What are the common operations? How long does it take? Monitoring that over time. Whenever you're dealing with engineering labor, and the value associated, this can become a bit of a touchy subject. I think that the answer to this is not to not measure, the answer is to measure lots of things so that you don't focus on one or two things and then optimize for those things to the detriment of everything else. Measure lots of things. Instrument everything. You can measure things like, how long does it take to perform this operation? So much of this is sentiment. I don't think we should shy away from that. I think that, yes, it can feel very meaningless to be like, how hard is it, or how much time do you feel like you spend doing these operational tasks over time? If you ask the same questions on a regular cadence, like five super simple questions, it takes people just like two minutes to do, and you ask them every month. Watching that over time, I think is very meaningful.

Participant 2: If the product is never deprecating or shutting anything down, why would the platform?

Majors: You're not a product engineering team, you're a platform engineering team. For example, if you're moving from using EC2 instances to using Kubernetes. Hopefully, you'd spin down the tooling for like spinning up EC2 instances, once you're fully migrated over to Kubernetes. That kind of thing. If nothing is ever getting deprecated from your product, that seems like a big problem. Things get deprecated from the code base without being deprecated from the product. I just think that not enough things get killed, and we should all be doing our part to find more of them.

Participant 3: I was curious about how you resolve this tension that I sometimes see where like a product team is focused on increasing top-line revenue, and they might try to obscure or just not discuss all the costs associated with it, and just like maybe how much headcount it involved, or reliability issues. You were saying that product teams should own that. How do you create the incentive, so that they want to do that, even though it might yield to the overall result?

Majors: In theory, putting people on-call does incentivize them to write better software. That's part of the whole feedback loop. If you're asking like how to incentivize them to want to own their code in production. Where to start? If this is a problem at your company, I have many questions. Because, fundamentally, you should want to do a good job, you should want to build things that are not bad. I believe that everyone inherently wants these things. If they're behaving as though they don't, I think that there is some incentive somewhere in the organization that are causing them to warp or distort their behavior. That's mostly true. I also think that people have trauma sometimes. They're like, "I can't have production access, I'm going to die if I touch it," because they've been traumatized at past jobs. The whole point of putting software engineers on-call for their code, the point is not to be like, ops has been miserable for decades, now it's your turn. That's not the message. The message is, nobody should have to be miserable, because this is how we make our systems better. Think about, if you're not on-call for your code, and you're making someone else do it, I find it to be almost classist in a way, like engineering classist. Like, my time is too valuable, some other engineer can pick up after my shit. I get that this is a big culture change for companies who are going from like Dev, Ops pillars to owning your code in production. It's not something that any one team can do alone, or a platform team can do, but it's worth doing.

See more presentations with transcripts

View post:

Perils, Pitfalls and Pratfalls of Platform Engineering - InfoQ.com

Read More..

Choosing the Right Technique: Prompt Engineering vs Fine-tuning – Data Science Central

Artificial intelligence and machine learning applications have been revolutionizing many industries for the last decade, but due to generative AI models like ChatGPT, Bard, Midjourney, etc., they have become more popular and are being used by individuals and businesses that might never have previously considered using them.

Despite demonstrating tremendous potential, AI models, in reality, dont have true intelligence. Instead, AI and ML applications are systems that can identify patterns within large and complex datasets and then present these relationships to users in a meaningful way. These systems heavily depend on model optimization techniques to improve performance and drive desirable, context/ domain-specific results.

Prompt engineering and fine-tuning are two key model optimization techniques used in training GenAI models, especially large language models.

User inputs to a generative AI model play a pivotal role in influencing the result it produces. These inputs are referred to as prompts, and the process of writing these prompts is referred to as prompt engineering. A prompt engineer crafts optimal prompts to interact with other inputs in a GenAI tool. These prompts help coax generative AI applications into giving better answers, leading the model to improve its performance, such as writing articles, generating codes, interacting with customers, and even producing music and videos.

Your results are only as good as your prompts. Prompt optimization is the art of crafting more precise and detailed prompts or experimenting with words and phrases to elicit better outputs from a generative AI model. In other words, prompt engineers write a prompt in different ways to get the most desirable and contextually relevant results.

Here is an example. Say you need to write an email to inform about the new feature on your loan app, InstaCash. You write a simple prompt in ChatGPT: Write a crisp email regarding the additional feature to our loan app. The output looks like this:

The content is quite ordinary and is not likely to catch the attention and interest of your target audience.

Lets try again with a more carefully phrased and specific prompt: Craft an email announcing the addition of the Personal Loan Calculator feature to our InstaCash app. This feature allows borrowers to calculate monthly payments and the overall cost of their loans. The output is:

As you can see a prompt can be engineered by providing a generative AI model with more detailed and specific input.

Fine-tuning is another technique to unlock the full potential of generative AI models. Businesses can leverage fine-tuning for harnessing LLM capabilities to tackle specific tasks and achieve optimal results. The process involves building on the pre-existing GenAI model that has been trained and customizing it to suit the specific needs of individuals seeking to make the most of AI and align it with their personalized goals.

Essentially, fine-tuning is used to refine pre-trained models to deliver better performance on specific tasks by training them on a more carefully labeled dataset that is closely related to the task at hand. It enables models to adapt to niche domains, such as customer support, medical research, legal analysis, etc. The power of fine-tuning depends on the additional data and training. Additional datasets refer to new raw information, and training is often coupled with a feedback or rating system that evaluates the outputs produced by the model, and guides it to better results.

Fine-tuning an AI model incurs additional costs, but it is often much more cost-effective in the long run compared to training a language model from scratch. Moreover, using prompt engineering techniques for every single exchange with a chatbot is impractical.

Both prompt engineering and fine-tuning strategies play an important role in enhancing the performance of AI models. However, they are different from each other in several important aspects:

Prompt engineering empowers users to elicit highly accurate responses, whereas fine-tuning helps in optimizing the performance of a pre-training AI model on specific tasks.

Prompt engineering requires users to craft the prompt in different ways and provide more context by giving effective inputs, adding new information, clarifying the query, and even making requests in sequence. Fine-tuning, on the other hand, focuses on training an AI model on additional datasets to improve knowledge and tailor it to meet specific requirements of businesses.

While prompt engineering is a precision-focused approach that offers more control over a models actions and outputs, fine-tuning focuses on adding more in-depth information to topics that are relevant to the language model.

As prompts are created by humans, prompt engineering needs no or minimal computer resources. Fine-tuning is resource-intensive and involves training a language model on additional datasets, which may require substantial computing resources.

Prompt engineering and fine-tuning are both effective techniques for enhancing model performance in delivering accurate and desirable outputs. However, they play different roles in developing a model: while fine-tuning involves updating the models internal settings to customize it for specific needs, prompt engineering is the process of crafting optimal prompts during the interface to obtain better outputs from a generative AI model. The effectiveness of both techniques depends on the human experts in the loop.

Follow this link:

Choosing the Right Technique: Prompt Engineering vs Fine-tuning - Data Science Central

Read More..

Bent Water engineer and inventor makes a toast to his new appointment – Daily Item

Jere Anderson, who has served as the process engineering manager and technical director for Lynn-based Bent Water Brewing since 2018, has recently been appointed to the Brewers Association Technical Committee.

The association represents some of the most successful craft breweries in the world, including Allagash, Boston Beer Company, and Sierra Nevada.

This appointment means to me that what I have learned and things we have achieved at Bent Water are recognized by the craft beer industry, and the Brewers Association believes there is value to the industry as a whole, Anderson said.

At Bent Water, Anderson is responsible for managing the design, engineering, and maintenance of the facility and the brewerys process equipment.

In his new role at the Brewers Association, Anderson said that he hopes to gain more contacts, colleagues, and friends in the craft beer industry to increase his knowledge of the brewing process. He said he also wants to spread more awareness of Bent Water as a producer of great-tasting beer and a leader developing the science of brewing.

I believe I bring a varied and strong technical background that can contribute to advances in the craft brewing industry and value to smaller independent breweries, Anderson said.

Before joining Bent Water, Anderson spent more than 40 years as an engineer in the plastics industry. Anderson holds 27 patents, including 16 in the U.S., and has four published studies that have been presented at technical conferences.

Anderson said he has been a fan of craft beer for a long time and got involved in homebrewing through his son.When he decided to retire from the plastics industry, he said he was looking for something he could do part time to keep him busy and engaged.

I thought learning more about beer brewing would be interesting and was introduced to Aaron Reames, the founder of Bent Water Brewing Aaron asked me to come help out at the brewery and I have been here ever since, he said.

To say that were proud of Jere for this recognition would be a huge understatement, Reames, who is also the president of Bent Water, said in a press release. Hes an incredibly accomplished engineer and inventor, and were beyond lucky to have him here in such a critical capacity at Bent Water. The BA will benefit from his presence on the committee.

Anderson said some of his proudest moments at Bent Water were when he developed an improved carbonation system for beer that minimizes carbon dioxide use and improves the products aroma, and when he worked on Bent Waters new facility, which more than tripled its output capacity without missing any product deliveries.

Anderson said his taste buds for beer depend on the occasion.

I am more of an IPA, pale ale guy.If I have to pick one favorite I would say our seasonal IPA called Blast Off.When not available, I lean toward Thunder Funk and Sluice Juice but recently have been enjoying Shaka, Anderson said.

See the rest here:

Bent Water engineer and inventor makes a toast to his new appointment - Daily Item

Read More..

What is an Engineering Manager? What they do? What are their key responsibilities? – Medium

As a software engineer, I'm always trying to find ways and techniques to sharp my skills and develop them. As a engineering manager, it's not different. I want to build and maintain not a good team, but an amazing team.

And I was about to create a post about how to sharp skills as a team leader, but then a question came to my mind: The audience knows what is an engineering manager?

Let's take a look together:

An engineering manager is a professional responsible for overseeing and coordinating the technical activities of an engineering team. While their exact responsibilities may vary depending on the organisation and industry, their primary focus is on achieving project goals, ensuring team productivity, and fostering a positive and collaborative work environment.

Inspire and motivate: A leader fosters inspiration by connecting with team members on a personal level. Understanding their individual motivations and aspirations allows the leader to align team goals with personal growth, making the work meaningful. Motivation comes not just from directives but from shared purpose and passion.

Guidance and support: A leadership involves providing guidance and support tailored to individual needs. Recognising and nurturing the unique strengths of team members contributes to a culture of empowerment, where everyone feels valued and supported in their professional journey.

Positive team culture: : Leaders prioritise creating a positive and inclusive team culture. They actively listen to the concerns and ideas of team members, fostering an environment where collaboration thrives. By valuing each team members input, a leader helps build a cohesive and harmonious working atmosphere.

Efficient resource allocation: A leader is mindful of the strengths and preferences of team members when allocating resources. Recognising individual expertise ensures that tasks are assigned based on each team members unique skills, contributing to overall project efficiency and success.

Adaptive planning: Leaders must understand the importance of flexibility in project management. They are open to adapting plans based on team feedback and changing project dynamics. This collaborative approach allows for more resilient project outcomes and improved team morale.

Progress monitoring and adjustments: Instead of rigidly enforcing timelines, a leader focuses on the well-being of the team. Regular check-ins and transparent communication allow for early identification of challenges. Adjustments are made collaboratively, ensuring that the team feels supported and empowered to overcome obstacles.

Guidance through expertise: A leader uses his technical expertise not to control but to guide and mentor the team. A leader should be also a mentor, offering insights and suggestions rather than imposing rigid solutions. This approach encourages the team to think critically and fosters a culture of continuous learning.

Staying informed and sharing knowledge: Leaders stay informed about industry trends and emerging technologies, not just for personal growth but to share knowledge with the team. By facilitating a culture of shared learning, they contribute to the development of a highly skilled and adaptive engineering team.

Encouraging learning opportunities: Leaders actively seek and provide opportunities for the team to expand their technical skills. Whether through training programs, workshops, or collaborative learning initiatives, the focus is on collective growth and development.

Open lines of communication: Leaders prioritise open and honest communication. They create an environment where team members feel comfortable expressing their thoughts and concerns. By being approachable, they foster trust and strengthen the teams bond.

Bridge between technical and non-technical stakeholders: A leader acts as a bridge between technical and non-technical stakeholders. They translate complex technical jargon into understandable language, ensuring that everyone, regardless of their technical background, is on the same page. This approach promotes a collaborative and unified organisational culture.

Conflict resolution through empathy: When conflicts arise, leaders approach resolution with empathy. They seek to understand the underlying issues and facilitate open dialogue to find solutions. By prioritising the well-being of individuals involved, conflicts are seen as opportunities for growth and understanding.

Aligning with organisational objectives: A leader aligns team goals with broader organisational objectives. By understanding the organisational vision and values, they guide the team toward contributing meaningfully to the overall mission. This alignment fosters a sense of purpose among team members.

Encouraging innovation: Leaders encourage a culture of innovation by providing a safe space for experimentation and creative problem-solving. They recognise and celebrate diverse perspectives, fostering an environment where team members feel empowered to contribute innovative ideas.

Long-term planning with team input: Instead of dictating long-term plans, leaders involve the team in the planning process. By valuing the input of each team member, they create a sense of ownership and commitment to the strategic direction, contributing to a more motivated and engaged workforce.

In conclusion, the role of an engineering manager is multifaceted, requiring a unique blend of technical expertise, leadership skills, and effective communication. By embracing best practices and continuously evolving with the ever-changing landscape of technology and team dynamics, an engineering manager can play a pivotal role in the success of engineering projects and the overall growth of their team.

See you! Cheers!

Read the rest here:

What is an Engineering Manager? What they do? What are their key responsibilities? - Medium

Read More..

BLACK HISTORY MONTH: Mary Jackson Hired in 1951 By NACA, Was First Black Female NASA Engineer – SpaceCoastDaily.com

By NASA // February 3, 2024

(NASA) Mary Jackson began her engineering career in an era in which female engineers of any background were a rarity.

In 1951 when she was hired by NASAs predecessor agency, the National Advisory Committee for Aeronautics, she very well may have been the only black female aeronautical engineer in the field.

The National Advisory Committee for Aeronautics was a United States federal agency founded on March 3, 1915, to undertake, promote, and institutionalize aeronautical research. On October 1, 1958, the agency was dissolved and its assets and personnel were transferred to the newly created National Aeronautics and Space Administration (NASA).

For nearly two decades, Jackson enjoyed an engineering career, wherein she authored or co-authored nearly a dozen research reports, most focused on the behavior of the boundary layer of air around airplanes.

A native of Hampton, Virginia, she graduated from Hampton Institute in 1942 with a dual degree in Math and Physical Sciences and accepted a job as a math teacher.

In 1951, Jackson was hired to work in Langley Memorial Aeronautical Laboratorys segregated West Area Computing section. After two years in the computing pool, Mary Jackson received an offer to work for engineer Kazimierz Czarnecki in the 4-foot by 4-foot Supersonic Pressure Tunnel, a 60,000 horsepower wind tunnel capable of blasting models with winds approaching twice the speed of sound.

In 1958, she became NASAs first black female engineer. That same year, she co-authored her first report, Effects of Nose Angle and Mach Number on Transition on Cones at Supersonic Speeds.

Service to the community was equally as important as work. In the 1970s, she helped the youngsters in the science club at Hamptons King Street Community center build their own wind tunnel and use it to conduct experiments.

We have to do something like this to get them interested in science, she said in an article for the local newspaper. Sometimes they are not aware of the number of black scientists and dont even know of the career opportunities until it is too late.

CLICK HERE FOR BREVARD COUNTY NEWS

See the article here:

BLACK HISTORY MONTH: Mary Jackson Hired in 1951 By NACA, Was First Black Female NASA Engineer - SpaceCoastDaily.com

Read More..

A US engineer had a shocking plan to improve the climate burn all coal on Earth – BBC.com

By Thomas MoynihanFeatures correspondent

Less than a century ago, people believed setting alight every coal mine on the planet would be good for the climate. The fact we've come so far in our understanding since then provides hope for the future, argues historian Thomas Moynihan.

Not a week goes by without a steady stream of headlines conveying our worsening climate predicament. There are stories about lack of preparedness , about perverse incentives, about political inaction and record-breaking metrics , or about the brute complexity of the problem. Swirling together, these meld into a general sense of intractability. Given this now-familiar news diet, it's sometimes difficult to maintain optimism when it comes to society's capacity to manage the climate crisis. But as a historian, I find it helps to zoom out.

Looking to the not-too-distant past reveals that the sheer fact we are aware of the issue is a genuine achievement. Easy to otherwise overlook, history throws into relief how far we have already come in our understanding.

Less than a century ago, even the experts of the day were talking about climate change in ways that would shock our 21st-Century sensibilities. To see why, you need only look at the claims of one prominent US engineer called William Lamont Abbott, who advocated an idea now unthinkable: he wanted to burn every gram of coal on Earth and remarkably, he believed that would be a good thing.

You may also like:

Today, everyone is familiar with the idea that the Earth's climate is a complicated system. Although it contains predictable cycles and trends, even schoolchildren are aware that it can be erratic and sensitive to civilisation's interferences. But a century or so ago, people had far more simplistic outlooks.

For much of the 1800s, physicists had been led to believe our planet was, essentially, a cooling body: inexorably losing its finite fund of heat to space's void, like a hot Christmas pudding dropped in snow. People feared encroaching cold, foreseeing life withering away on a dwindling diet of warmth.

Changing these views took years of research and even then, some scientific findings were not immediately recognised as important. For instance, suffragist Eunice Foote realised as far back as the 1850s that carbon dioxide retains heat and, thus, an Earthly atmosphere with more of it would be warmer. Foote's pioneering contribution was overlooked, likely due to sexism . (Watch: " Three pioneers who predicted climate change".)

Only around 1900 did scientists begin making further connections between atmospheric CO2 and larger climate trends. This came from searching for the causes behind the Ice Ages: prehistoric pulses of planetary freezing which implied that rather than being a heated ball monotonously losing its warmth in a nosedive decline the Earth's climate is in a complicated equilibrium. One capable of maintaining balance over voluminous tracts of time, but also of severe oscillations.

Around this time, scientists also first made the link between humanity's burning of fossil fuels and Earth's future climate. Liberating colossal amounts of CO2, the planetary juggernaut of industrial civilisation suddenly seemed poised to rapidly warm our globe.

How did people respond to this conjecture? Having grown up fearing a frozen future, many rejoiced. And that brings us to William Lamont Abbott's case and his erroneous beliefs about the benefits of burning all our reserves of coal.

The plan to burn the world's coal

An engineer by trade, Abbott was not uninfluential , nor some lone maverick. Chief operating engineer of Illinois's largest electric provider, he also held other prominent roles . Fittingly, a powerplant was named after him .

In the late 1920s, he travelled the US delivering lectures to various learned societies. Talking to one room in the picturesque Pennsylvanian town of Scranton in 1927, Abbott welcomed industry's accelerating use of fossil fuels. Why? Because he had hastily concluded this could only benefit the world, by making climates more clement.

For him, accelerating consumption wasn't enough. Estimating there are several trillion tonnes of carbon still locked underground globally, he reasoned that this storehouse, if "returned to the air", could increase atmospheric levels tenfold.

With staggering self-assurance, Abbott announced such a dramatic increase in CO2 would double Earth's arable surface, by transforming polar countries into temperate paradises. He envisioned perpetual summers, jungles in America's north-east, unprecedented crop yields, and unimaginably verdant environments; an outcome, he said, which was demanded by humanity's "increasing population". He even prophesied tropical animals including elephants would return to North America, becoming "garden pests".

Abbott then arrived at his action plan. Despite nonchalantly acknowledging scientists didn't yet understand all the intricacies, he arrived at his conclusion: "Let the nations of the Earth unite", he said, in immediately setting alight all their deepest coal seams, so as to release the planet's entire "treasure of carbon".

He even claimed countries ought not "regulate the fire to the varying demand of power", but simply "let it rage day and night" luxuriantly and wastefully in order to make the world's mines into one "roaring furnace".

All this, he insisted, should be done in the name of "posterity", accelerating humankind towards future utopia: a "return" to Eden.

Moreover, Abbott was not unique in holding these beliefs. Swedish physicist Svante Arrhenius the period's leading expert on climate change had also remarked, cheerfully, that global warming will only precipitate better climates and crops. Others readily assumed similar things. When they acknowledged a hotter world might unevenly make the Global South "suffer", they shrugged rather than shuddered.

Only very few scattered voices, such as geologist Thomas Chrowder Chamberlin, were more prescient. He urged his contemporaries to practise self-restraint when it came to coal appetites, seeing this as necessary to safeguard a stable climate for future generations. But, despite sensing the gravity of the challenge, he also saw reason to hope people might rise to the task. Pointing out that, when cooperating at large-scale, humankind has so far only tended to disturb or destroy ecosystems, Chamberlin also hinted that we are the first and only animal to realise its impacts. What's more, when considering human history, people have only just begun grasping this and, thus, acting toward rectifying it.

Today's consensus concerning climate change and its consequences rests, in part, on the past's egregious mistakes. Getting closer to truth unavoidably involves being wrong before. Because of this, Abbott's case suggests that one shouldn't be hasty when it comes to acting drastically in what you think is the interest of future generations.

But the main lesson here is this: only by inspecting past mistakes do we see how far we've since come. This allows us to gain some sense of how much farther we might yet travel. Our knowledge of the imminent dangers of human-caused climate change rests on countless computer models alongside a vast, planet-wrapping array of sensors and satellites. An attempt to simulate Earth's changing states like a planetary central nervous system it is a staggering achievement . Through building up this megastructure, and through the unceasing efforts of countless researchers since Abbott's day , we've travelled leagues from the rash naivet of even just a century ago.

This proves societies can, and do, learn. It throws into relief just how much and how rapidly outlooks and priorities can change and become more sophisticated and insightful as we piece together more about the world. Several generations ago, it simply hadn't yet sufficiently occurred to scientists that climate change might unleash significant harms. Now it's overwhelmingly accepted. It's likely we are missing similarly vital insights today, insights that would enable us to navigate our world far more wisely. Strangely, this is cause for optimism, as having room for improvement is far better than having none at all.

Historically speaking, we have only very recently become aware of our planetary predicament. Perhaps, then, it's still too early to dismiss Homo sapiens as inevitably, forevermore, doomed to be a blight upon its world. It's clear that we have so much more to do to avert the worst effects of climate change, but if we look how far we've come, in a relatively short time, there are reasons for cautious hope.

*Thomas Moynihan is a historian of ideas and author ofX-Risk: How Humanity Discovered Its Own Extinction(MIT Press, 2020) . Currently, he is a visiting researcher at Cambridge University's Centre for the Study of Existential Risk. He tweets at @nemocentric and can be found at thomasmoynihan.xyz .

--

If you liked this story,sign up for The Essential List newsletter a handpicked selection of features, videos and can't-miss news delivered to your inbox every Friday.

Join one million Future fans by liking us onFacebook, or follow us on TwitterorInstagram.

Read more from the original source:

A US engineer had a shocking plan to improve the climate burn all coal on Earth - BBC.com

Read More..