Excellent. First of all, just welcome. This has been an amazing day. All of the talks have been terrific and I just want to give a big shout out to the speakers, the organizers, and then especially Hannah and Desmond who have worked so hard to make this amazing event in this venue. So just please thank you. I also wanted to give my bachelor rose to Andrew who gave me the clicker. His clicker when my battery died so you can get this after. My name is Sarah and I introduce myself as a programmer comma person and sometimes I switch it up and say person comma programmer and for work right now I'm in the middle of a sabbatical adventure and so this talk is going to address the programmer comma person aspects of all of us. So I was really honored to be asked to speak here and one of the reasons is because this conference right on its web page says it's for curious people and I love curious people. And because elixir is a relatively new language by default everyone here is an early adopter. Someone who gets excited is someone who plays with languages in their spare time and because elixir is near the beginning of its journey that means that everybody here by default is at the beginning or early middles of our journey with elixir. So also we're in LA which is super exciting and I bought my conference outfit at the airport gift shop. I have LA fan I don't even know why I just have LA fantasies it's so great. People come here they dig gold they try to become movie stars they try to write programming applications with hot swapping capabilities and concurrency but in this idea in this country the idea of go west is very powerful whether it's the physical spaces or imaginative spaces going into the new is something that we put a high premium on here and so we are all here today both physically west and new ideas sharing this day together so just cheers to that. And before I get into the meat of the talk I want to go over a quick legend so we're all in the same page this is a shark and this is an Erlang shark and I'll just take a moment to remind us that in our metaphorical understanding of sharks and also probably in our actual experiences with them sharks are scary you could say they represent the deep the unknown sudden death will surfing. This is a galaxy shark and there's like three or four documentaries about this recently like you're not even safe in space anymore so yeah so this keynote is unequally divided into the following sections and I want to begin with who we are and by we I mean software developers and as software developers we are asked to constantly learn new things languages frameworks domains but at the same time we come to understand that our role is managing change we build new applications we phase out old ones we change the way business is done effectively and managing change means talking to people and working with people and that is often the same again and again so in short we're asked to get on the rocket ship and go to new exciting places but we also need to be able to sit in a living room and have conversations with people we need rocket ship skills and living room skills and probably in the proportion that we see in this slide developer architect and teacher learner these are two of the roles that we tend to think of ourselves as filling most often and there's lots of titles surrounding these roles like look at some of these I'm sure you've had some or all or variations of these or even ones that aren't on the slide and then take a minute to think about other professions like lawyers law or medicine and they have hierarchies and titles but you don't really hear lawyers calling themselves like statute hackers or law gurus and doctors aren't you know body crafts people are lung architects but I mean to me what the plethora of titles really indicates is that software development is truly fluid what a title means and what you do while you have that title is not predetermined which speaks to the nature of the field and while we spend a lot of time focused on developing and teaching one of the things I've learned is that the skills in the bottom two quadrants which I've bucketed under productivity expert and business partner are skills that you develop or become aware of you may already have them after many years and are as important if not more than the first two in a given job these roles all merge and their lines blur and in fact in any given product or launch we flow in and out of these different roles on a frequent basis we are not individual contributors we are imperfect circle squares so as imperfect circle squares let's go forth and talk about what and why and how we learn and so since we're at elixir conf which is focused on teaching and learning and being productive in a relatively new language let's start with this balance individual contributor individual learner so as a day to day dev you're responsible for many things so while the sun is up and you're at work if that's how you do it you're responsible for getting your stories done and being productive but when the sun is down and you're on your own time you can choose to learn without worrying about output and our career cycles between the two and in fact we cycle between productivity and learning on many time frames you can cycle in an hour a day or you can take longer dives spending months or years focused in one area than the other and I see them like day and night office time and home time focused in the world time and introspective time and you are the craftsperson the hacker guru make your way along the path so why do we keep learning new things because it's not always fun and arguably once you've mastered a skill you can choose to ride that skill for a while but you know there's lots of reasons and basically we're a curious field and one of the things that drew me to software and all of us I think is how full of challenges it is there's always something new to learn something exciting and different and relevant and delicious and as curious people we are drawn to new adventures this is a sticky I made from a project I was prototyping last year and I've been thinking about learning and the balance of productivity and learning because I'm in the middle of I would kind of choose your own adventure learning journey and I'm going to share some stories from the last couple years as a way to give context for my thoughts on software as well as to present different paths that you can take to build your careers or the adventures that you want so yes I've spent the last 18 months entirely learning new technologies since June of 2016 and usually this like a learning journey phase is something people do early in their careers or when they're students but for me but I've been paid as a dev since 2001 and I plan to be coding sort of well into my 80s so you could say I'm about a third of the way through my career and that's all the age math you're going to get this journey started unexpectedly though the stage was set and about 18 months ago two things coincided and I'm not going to speak to the image on the left but the implication of this event was that the person pictured was going to be the republican nominee for president and to the words on the right however I had been working with a great team at a great company for about four years and it helped steer the company through a lot of growth but I wanted to stretch my brain in new directions and to paraphrase the great thinker Sophie Kinsella I felt like technologies were moving on without me I had a suspicion I'd fallen onto a manager track that was going to lead me to skill atrophy and they don't all not all manager tracks do but in my case that's what was happening and this state of mind coincided with an amazing opportunity to join Hillary Clinton's technology team and that aligned with my values and gave me a place to put my energy as well as a place to channel my abject terror so I jumped at the chance and I went to Brooklyn and this I will say was not a stagnant environment it was you can see many people at a desk many desks at a people it is crazy and there were there's really been few times in my life where software deadlines have really had like actual meaning but working on a presidential campaign was one of those times and on my first day it was June 27th I was I got there and I was told I had to have a product it wasn't even fully conceived yet but it had to be launched by July 17th because that was the day of the counter convention which is a thing like after the republicans do the convention the democrats get to speak back but yeah and you don't get to say like oh that's hard it'll be ready the week after the counter convention or this other thing uh how about November 10th like you just don't so instead you get to say holy shit I don't know any of these technologies it's a completely new team and environment but by god I will learn and this will be out by the counter convention on July 17th hello 3am and it was and we had a great team and we worked long hours and we got it done and the team that I was on it was focused on engagement and we launched seven projects in five months and prototyped about 10 others and there were also seven other engineering teams focused on different aspects of the campaign and everybody worked very effectively and not everything didn't always go smoothly for for example two hours before the second debate we had written some fact-checking software and our our CI system just slowed down and so I was literally sitting there watching the critical release as the secretary walked on to the stage and it was terrifying but it got there and she used it and it was okay and I made mistakes temp files do not clean themselves up people but none of them had lasting production level impact and one of the things I've been thinking about with this whole campaign is how is it possible that we got so much done and one of the reasons was that the tech team had worked as well as it did was because it had excellent leadership and it was highly diverse and just a fact there were over 10 senior female engineers on that team including the CTO which was like a first in my career ever it was the most diverse tech team I'd ever worked on and just in terms of conversation and experience and collaboration it was the most high performing and also unforgiving of subpar work and nicest team that I had been on so if you ever hear that line where people say oh we don't want to lower our standards it was culture fit is wrong and blah blah blah like that's that's some bullshit and when you bring accomplished people from all walks of life who know how to write software together with great leadership amazing things can happen another reason things worked so well was there was a specific process for design thinking an idea sharing that was used at the campaign it was brought over from someone from Google and so in the midst of all of the long hours and all of the shifting focuses and everything every time any team embarked on a new project we went through a design review process which was effectively a structured conversation in a living document in which all the devs could participate by asking questions participate asynchronously and then at the very end of this get in a room together for an hour and solidify choices and the project that I initially showed I was designed and built and launched in under two weeks and a lot of that is interesting because of the security and scalability concerns on the campaign but in that time in that two weeks over 30 engineers participated in the design process even though there were just three of us on our team building it and a wide range of questions about security and scaling and product and operations and user experience were highlighted and brought to the fore to the fore so this type of process is a way to structure conversations such that effective software gets built and so these structural pieces the diverse team this great design process were in place and supported me through multiple projects multiple technologies and multiple awesome dogs this is pocket and with pocket I learned to use build and automation tools like Gradle and a customized CI tool that created immutable AMIs on AWS and I'm going to come back to this a little bit later but one of the things I've been noticing in the past few years is the increasing divide between dev and dev ops in tech orgs and in fact one of the harder pieces of campaign technology work for me was getting my head around the dev ops piece but I'll come back to this um this is pupperton and have you ever seen a dog that is like more white space uh honoring than pupperton I he I became proficient in Python and its frameworks with his help um Winnie was there and neither Winnie or I knew what Lua was but I learned it enough to simulate high load on our services to identify any bottlenecks for election day and then social Tito here guided us through multiple cases of Facebook's open graph API it was very very fun very costumed dog campaign environment one of them had a drawer of sweaters but working on the campaign was an amazing experience and I had thought when I joined like it just might be like this chaotic thing where everybody's in a corner kind of freaking out but it was a high functioning well run tech org and I'm proud of my team I was proud of the candidate and I was proud of our work but when it was over without the result that we had hoped for and that we had worked so hard for I realized I wasn't ready for a full-time job do I look ready for a full I can't even tell if that's my actual arm or just like a stick with a hand on it that's holding up some booze for me um and so time passed and to make myself feel better and more optimistic about the world I rewatched the entire five seasons of Breaking Bad which was like genuinely calming um and then just to do something trivial and lightweight I decided to learn blockchain I don't know I was like I want to learn blockchain now so I took a contract at a company that was doing some blockchain R&D and what I got to do was DevOps and this was interesting because as I was mentioning before one of the big gaps in dev teams I've seen over the past few years and experience as a dev is the space the growing space between dev ops and dev and both of the ecosystems are getting more complex there's more organizational silos so that's just something to think about it's almost an aside as we move forward I think we need roles sort of cross-functional roles to straddle those two areas but I certainly wasn't there yet I was grappling with Docker and Kubernetes and Helm and Geff and JavaScript and since I decided to make 2017 the year of learning to program for the Ethereum blockchain I also took a very difficult course and this was also hard but I became at the time at least the first female certified Ethereum solidity developer from that course so um I say these things not to say fun things I've done but sort of reflections on a journey through a bunch of unknown landscapes and a journey that I started when I said to myself I'm feeling stagnant and reflections on the fact that I basically spent the last 18 months not knowing what I was doing taking a deep breath and figuring it out and we are all figuring it out as we go and taking a deep breath is actually a true statement because it was about 12 months ago it was actually during the DevOps phase that I started feeling like I had ADD anxiety-driven development and so I started doing a daily meditation routine so thanks to DevOps again daily breathing became a way to stay centered so why why all this why do all this like it was rewarding but it was clearly hard and stressful at times and why should I tell you the story of me jumping off a bunch of cliffs into new environments in one part it's to show how many options you have in our field all of us you can go in you can explore something completely new and come outstanding I expanded my boundaries and when you expand your boundaries your world becomes bigger I tried new things and this gave me renewed empathy for beginners and also showed me like new insight into what are some current business problems or it maybe it just boils down to get comfortable with being uncomfortable and we hear this a lot Jillian Michaels said it here and then this guy Eric Thomas changed a word or two but he said it as well and Lupinella who was a New York Yankee in the 1980s also says it and then this guy this guy says it which he doesn't look even remotely comfortable he looks miserable well look at that dude and then this one and there's like this tuxedo hobo also says it and is that what it's about is being comfortable being uncomfortable what it's all about no this is my cat Squeaks she is not remotely comfortable I also realized that I am not remotely comfortable when I am uncomfortable in fact what I am is comfortable being uncomfortable being uncomfortable which I also admit might be a kind of personal masochism seeking out discomfort for Lord knows what kind of familiar territory but the fact of the matter is that when you're uncomfortable you're uncomfortable you just are and so the best thing to do is accept that fact that discomfort comes with the territory it's not going to feel good and it's not going to be with you forever and I don't know but maybe people relate more to this than the other the other one I don't know maybe you all feel super comfortable when you're uncomfortable but actually if you think about it it's recursive and it can go on for quite some time does anybody know like the time complexity of this but I mean part of our job it's our job to learn languages domains patterns problems technical specifications etc and so we go from learning to stability back to learning to stability in the cyclical fashion but every time we learn something new we have our previous learnings about learning to keep us company and we also become more stable even in times of unstability so even though for me even though I was learning I was able to be high functioning in professional environments because as time progresses one is able to be more consistently productive just simply because you're adding to your arsenal of things that you already know and things that you've already experienced some things get easier with time like debugging and picking up new languages and some things stay the same like the learning process you know every time you're faced with something new it can feel like you're looking into a void and you know there are sometimes in the first few weeks of every like if I'm learning something really new and unfamiliar where I just have a good old-fashioned cry you know you start with your little home and you need to move away from it in order to learn new things it can feel like you're on a tightrope over an abyss there are surprises in the waters you can lose your bearings and then gradually gain your footing again demons are smaller until finally they become friends and and it happens every time and I'm sure everyone here can recognize that body shift that physical shift from uncertainty and fear to a gradual sense of competence eventually followed by confidence and knowing that you can do that as a developer and being familiar with that flow is what gives you more freedom over time and just just to revisit what I said earlier about crying I don't cry every time I learn a new thing if I'm learning something at home or for fun it's no problem but just let's say my time was spent getting headless javascript tests to run a nightmare js against a closure application linked to an instance of the gath ethereum blockchain inside a docker container communicating with another docker container running on a parallel thread in Jenkins this is the most buzz worthy wordy thing I've ever done in my life and there were tears involved what the fuck seriously what the fuck I would cannot spend all our time learning or wouldn't ship product pay our job our bills or keep our jobs which is one of the ways that elixir comes in so elixir is a language that was created specifically to introduce new tools functional programming concurrency a message passing actor model to a trained fleet of productive developers with as little downtime for ramping up as possible we heard about it in a talk earlier about how the three new developers came in and rewrote a system in elixir because it's that easy and my friend and elixir developer joe harrow puts it with elixir you can stage a coup from inside a rail shop he actually said literally and then he's like you can't use the word literally but he said literally um elixir has two parents and we know the origin story joseph valine was working on adding concurrency to ruby on rails when he discovered erlang and erlang was perfect at doing things natively that he was trying to add to rails but he found the syntax and ecosystem off-putting and so he decided to dip the erlang chocolate in the ruby peanut butter and he came up with elixir and i'm really sorry that i could not not make this joke but this is a screenshot from a 1980s television commercial for Reese's peanut butter cups and you must hunt it down on youtube and watch it and and right in the middle of this encounter this like benign patriarch of branded candy shows up in the background so perhaps that's joseph and elixir anyway back to elixir um languages combining and influencing each other happens all the time and the lineage it's not as straightforward as this slide would suggest i found this it's a fascinating programming languages genealogical tree you can't even see it that's erlang doesn't even have elixir um but languages combine and recombine but the truth is for web application developers and business owners there are two roads that lead to elixir and one is through a rather obscure language invented for telephony applications and the other is down a familiar road that you are probably proficient in and this is a straightforward choice um i i had ruby and rails and i decided to try erlang but that was because a i was in my spare time so i had the time to just sort of struggle with it and also at the time i personally felt a little sheltered in my languages and i wanted to grapple with something like really different um and it was hard but i grew to love the syntax and the language though i found the ecosystem difficult for example at the time i was learning erlang this book was the main resource i found for deploying and managing erlang apps in production i mean look look at the title and the imagery on that like it says it all and i was great on local host i was so good on local host but deploying and managing apps was something i struggled with a lot and clearly not alone um so the practicality of being able to use existing developer talent and deploy is huge if you're trying to run a business and make money and there are real and important improvements in elixir over erlang and we've heard so many of them here today i just didn't highlight a few but just listening to everybody talk about how easy it is to pick up and what you can do but string manipulation just for one is anybody here worked with strings in erlang would you agree it's easier in elixir yes she didn't know what it was yeah yeah you're like oh it's actually a string i i spent a bunch of time in erlang trying to do a tweet parsing api and so i was wrote an oauth library and tried to parse json out of these chunks of tweets that weren't connected and oh my god it was like the worst the worst use case for erlang possible so this is much nicer in elixir um like we again like we saw out today deployment is so much more easy there's people are using docker there's distillery there's ci there's just so many more straightforward and familiar tools around deployment um the web framework is straightforward and i think like wall phoenix offers similar functionality to what we might we what might we might be used to from rails or jango it's also nicer than rails because it simply supports elixir instead of that thing where like in rubyland people can say well i learned rails but i don't know ruby like phoenix supports the elixir application ecosystem and doesn't try to like be its own thing um and it just opens up so many new domains like we've solved as an industry we've solved crud and we've solved services and apis and now with elixir's ease with concurrency and the ability to pick it up so quickly it just opens up so many new business domains and performance improvements so my question is which was the trojan horse bringing erlang to more people was it the productivity or was it the syntax you guys um i guess it really depends on what path what your path was maybe ruby people came for the syntax and erlang folks came for the productivity maybe vice versa but you end up with the same value but i wanted to show this slide this is um from a 2014 elixir con um where josé is describing his first draft of elixir and i paraphrase but he talks about how he initially tried to fit erlang constructs into ruby shapes he understood and he used this image to represent i know what shapes i want but i don't know how to get there and he describes going through a depression when he realized his early work on elixir wasn't good which is his words not mine and then he reapproach the project with new understanding and the reason i bring this up is i think it really exemplifies how grappling with new shapes through the just natural filter of what we already know um can lead to these round peg square whole moments and so if you've learned erlang through elixir i would encourage people to take some time to go grapple with erlang just to get a deeper understanding of that path to it um i found when i was reading elixir books to me they seemed a little bit less in depth on some of the core erlang concepts and the erlang books that i had read were and maybe i didn't read all the right books but it made me wonder if i might have missed some of the nuance so my advice would be in your learning time if you haven't already pick up erlang and just spend enough time with it until you are like oh i kind of like this syntax and see if it gives you any insights into elixir um or if it takes you anywhere new because spending time with languages that are different from ours or with people who are different from us basically making ourselves the ones who are getting into new uncomfortable shapes is a way to deepen learning and productivity and take a quick moment here to talk about this wall we have in our industry and in our speech about software and this wall stems from conflicting beliefs on one side software is magic and it's easy and then the other is like writing software is hard and this conflict often blocks us both from learning and from communicating and this word is just and just is an odd word because it capitalizes on a secret belief that software is easy and if it's not it's our fault and also project managers use it a lot um so when we hear it from others just represents all these extra judicial process requests we get last minute feature request or just one more small thing ask from someone who's not on your team and i think it's a word that's used to make you feel bad for not being able to fulfill an unreasonable request um but we use it with ourselves as well and it reflects that same belief like software production should be quick and easy it's the way we talk to ourselves when we feel bad about not being as fast as we think we should be or to avoid specking something out in full so i just when you hear that word just from yourself or from others i would suggest pausing i want just to ask like what's being avoided or is there something we need to are there conversations that we need to be had which brings me to um the final piece of this which is what i call our secret skills and what is what is it what is our secret sauce um and so to do that i'm going to come back to this earlier slide and look at the bottom two cases productivity expert and business partner these are things that software developers also are but maybe you don't notice it as much much in your daily work but the tools that we use to write effective software and the learnings from working with stakeholders again and again and again are tools that could augment any business venture like look at all of these techniques and practices that we use to write effective code and launch product quickly these are absolutely tools that could be used outside of the software development cycle as well and i have found that many i won't say most but a lot of non technology companies just don't have processes in place that technology the processes that technology shops rely on so and so they run ad hoc processes to get things done but without understanding the role that process and feedback play in developing product building software can become but can be seen as some kind of magic materialization of things and then this idea that software is developed like a thing by people who know how to develop things can lead to an artificial boundary between the business and tech parts of an org in which like one side ideates and the other side builds a little like elves um and it's it's i'm not saying like all devs should go to all business meetings all the time but recognize from all of the experiences that you have um how many informed ideas that you have just because of the knowledge of our tools and how the patterns that you know how to recognize about what software is going to work or when it's not going to work um and so if you see these boundaries rising up in your organization so see if you can talk to somebody about eradicating them so that there's more communication there's a little sidebar but in 2012 my partner and i started this a consulting service and we gave pro bono technical advice to non-technical people and entrepreneurs because we found that they had they kept running into these really costly mistakes with regard to technology and this often came from acting on this sort of unexamined belief that software is a thing that you get by like buying it from india or getting a student to build it for free and they you know that lose a lot of money and get these complicated things and so we sat down with about 400 people over the course of this year and what we found was most of the time we ended up giving business advice or just applying the productivity and business experiences we had just because we were devs not because we're MBAs um just applying that to their business ventures and helping them think more methodically about what they were trying to build and what they needed and what they didn't and i think through this i really learned that building software while it involves code is not about code it really is building software is a conversation about what a business is and you talk together and you figure out what are the business priorities what are we going to build first like what what actually is the business you try things together change them get feedback you know we have conways law which tells us that the shape of our teams determines the shape of our software um and secondly software is not a thing it's an interaction and this is why there are very few cases where you can have your team in india or your team in kansas just build it for you because it's difficult sending a spec to an offshore team because you lose out on that back and forth part of the process and you instead encode this kind of we think it you build it mentality and businesses fail because conversations fail like they really really do and you know from a tech standpoint like we know this slide and it's awesome and we or me as a dev or i'm sure all of us at different points tend to think well if we get our tech working right it's all good right but that's that's not true um and i'm sure regardless of your tech you have all experienced dysfunctional business situations that have impacted development you know a known poor performer is promoted and that deflates morale and delivery or a fast technical talker kind of intimidates management and so common sense is overridden a company builds a giant product without talking to users and then it's like hey nobody's using this like why or a team of 200 devs moves like so much slower than a team of three devs and i know you've seen these and more i'm sure you can list them out but all of these are instances we're not having difficult conversations or we're assuming that there should be some minimal interaction has material impact on the morale of a team and the success of a venture and it's not fun you tune out you go somewhere else you quit your job the software stalls it gets caught in endless cycles and at the end it's just all that's left are clinch fists and i i feel like the the most relevant thing i've learned in 17 years of developing software and weirdly the thing most likely to guarantee technical success is that software is a conversation and i literally mean this literally and i and conversation i don't mean prepared speech like i'm doing up here but like the result of listening and going beyond what you know and understanding what someone really wants and also understanding what their fantasy is and how their fantasy of a magic software business is leading them astray you know conversation is a generative act where two or more people end up with something that just couldn't exist without them and then also the output of successful software is actually conversation like think about we interact with other humans in order to build experiences that facilitate interactions between other sets of humans and i sometimes we build software to replace people's jobs or to kill them but for the most part software is about facilitating a conversation or an interaction that wasn't there before the connection or an interaction and so these things that we think of as soft skills are hard and not only hard difficult but hard technical these so-called soft skills are often and not always but often the difference between successful and not successful ventures so what can we as our imperfect circle squares that we are what what do we do about this how can we get better at both the hard and the soft aspects of our jobs obviously experience is one teacher and then just here's some other suggestions there's there's some wonderful non-technical reading these two books crucial conversations and radical candor both address how to broach difficult topics in an authentic way and they're worth reading and possibly introducing in your organization this one's kind of weird but take an improv class his improv improv is like not about telling jokes and being funny it's actually um about learning to listen to someone else and then spinning an idea together in like spinning an idea together together sentence didn't work but i think you get the idea and i did this once i didn't do it to be fun funny but i actually thought oh you take this to be funny but you really it's a really about listening um and you can ask me about it um learn a new language which really frankly that's what everybody here is doing so just keep doing the thing that you're doing but for your next one either like pick one that you're curious about or maybe pick one that you think you might hate just like something different from your most familiar language and go into it you know you'll get better at learning you'll know another language and then the one you pick up right after that will be that much easier doesn't really matter which just whatever um find a diverse team or make your team a diverse team or join a diverse team like look at how well these four animals are doing together and the crab is an introvert but it's okay with the others and it's not because it's not because his bubble wouldn't fit on the slide it's nothing to do with that yeah uh this this process implement that i described in the context of the hillary campaign it's a wonderful it's a wonderful process and it's super concrete um for vetting and explaining a technical idea and so i encourage you to look at bringing like bringing the system into your own companies uh this is what i've done over the last year and a half and so i would say to anyone who's an expert in their field i'm sure there's people here who are very experienced an expert and go back to school or be an apprentice on something or put yourself in a work position where you really don't know anything like join a modern dev ops team for one jesus christ but like just going back to beginner state will help you like identify other leaders that kind of lighten the load of like trying to make decisions and regain empathy with actual beginners um but on the other hand if you are a beginner or you kind of like fall back into like i'm always learning like become an expert for a while just be like fuck it step into a leadership role you know see what it feels like to take on responsibilities make decisions like get comfortable wielding a little bit of power um this is nice i've liked this just find a few moments every day to center yourself and give yourself some space and finally what whatever the fuck it is that makes you look like this dog do it and that's it thank you so much have fun at the party


With sustainable agriculture, data really plays a key role, really in two specific areas. The first one I would say is precision agriculture. A second area is with carbon markets. A lot of companies want to see proof that the practices farmers are implementing are actually having a changeable impact to the world. So farmers will use data from precision agriculture directly on their farms by taking measurements across fields to know, for example, how much nitrogen to apply. And this has been especially important when we come to times of high input prices. Right now, cover crops are used on about 8% of farmland across the state, and 27% of farmland uses no-till, which are both either in line or above what's going on in the United States as a whole. These rates are maybe a little bit lower than we might think, but that really brings in the role that data can play by seeing what successful farmers who have used these practices have seen to their operation. That could really help encourage other farmers to adopt these practices and see these rates increase even more in the future. So producers have really shifted towards these sustainable practices in part because of the economic benefits they bring to their operation. And it works out well because a lot of these practices like cover crops are no-till. They both have the on-farm benefits of agronomically improving farms. But the off-farm benefits, which transfers to environmental benefits, either talking about improved water quality or carbon capture from the atmosphere. But they also directly impact the farmer's bottom line. For every dollar that's spent on food, farmers only get about 16 cents of that. And on the other end, their prices have really gone up, the prices they're paying for input. So trying to be as efficient possible both economically and from a sustainability standpoint is one way farmers can really help themselves in these tough economic times. If farmers are using practices that are sustainable practices, but they're also more efficient at farm production, we would expect consumers to benefit by getting essentially some of those savings passed down to them overall. A lot of this shift towards sustainable agriculture has been driven by consumers. Consumer preferences have evolved so that a lot of consumers, a huge segment of the consumer base, really cares about the food they're eating, the clothes they're wearing being made sustainably. I chose to be an economist because I see economics in large part as sort of the science of promoting human happiness. And with agriculture, anything I do is really directed to help being farmers or people in general make decisions that can improve their lives. My goal is to take the complex nature of data and economics and bring it down to earth to farmers and consumers.


The Community Scientist Academy, CSA, was designed to increase community members' understanding of the research process and encourage them to become more involved in clinical and translational science. The CSA was piloted twice with community members and patients who had not previously been involved in research. After attending the CSA, many participants expressed interest in reviewing grant applications and attending additional training. This suggests that the CSA has successfully demystified the research process and encouraged greater participation from underrepresented groups in clinical and translational science. This article was authored by M. Catherine Stewart, Nicholas Spencer, Anna H. Davis, and others.