Transcript: Project Beacon - Jackson Wilkinson

I'm Will Vincent joined by Carlton Gibson.

Hi, Carlton.

Hello, Will.

Hi, Jackson.

So nice to see you virtually.

Uh yeah, it's one of those uh weird situations where we actually met in person first in software as opposed to you know it corresponding online first.

And now here we are in COVID times and it's mandatorily virtual.

So you know, funny how things get mirrored up.

Um and turns out you're deeply involved with Project Beacon, which we'll talk about um among other things.

But maybe we so maybe what's Project Beacon, right?

That's the most timely thing.

And then I'd love to get your backstory of um getting into Django.

So uh Project Beacon uh I've been with since uh since late June of 2020.

And it's a it's a really interesting organization.

It was started uh in the spring, funded partially by uh GV, formerly known as Google Ventures, and uh F Prime, which is sort of a similar venture arm for Fidelity, as well as the Broad Institute, which is a major genetics and genomics lab uh affiliated with Harvard and MIT.

The three of them got together in the spring and said, uh, we need to increase the capacity and availability of testing in Massachusetts, here in our home neck of the woods.

And uh they started Project Beacon, which uh is not technically a nonprofit.

We didn't file the paperwork, but we're chartered to not make a profit and basically do everything we can to drive down the cost of testing uh in this area.

And so um, you know, we we basically at this point do uh a handful of different things, but uh early on, my mandate coming in as as chief technology officer was to figure out how to duct tape together a bunch of vendors in the right way to start COVID testing programs.

And we figured out that that was going to be a really bad experience for everybody, and we needed to become a software company, which is not what we expected to do.

And interesting.

I thought that was, you know, because they, you know, you have a software background.

I thought that was uh

And it was it was just not going to be able to do it.

And w think again about the thesis of driving down the cost of testing.

Um, we don't own the lab, so there's a lab price that we kind of can't control.

There are all the vendors that are associated with swabs and tubes and all the other things that go into it, and we can't control those either.

But there is the human cost of testing and the efficiency of having somebody who's there and staffing a site and puts a swab in your nose and collects it and brings it to the lab and so on.

And we thought that technology could drive down the the amount of time that it took people to test you, uh, and that could drive down the cost.

And so uh we now operate uh six large high-capacity regional testing sites here in Massachusetts, each of which uh do you know thousands of tests a day uh for free, paid for by the state.

Uh but in the background, uh we are driving the cost down by making it uh the type of experience where you're you get from check-in to check out in three to five minutes, you pre-register online, nobody needs to do data entry and make errors at the site.

Uh, you show up with your QR code, they scan the QR code, you get a swab in your nose, you head off and you get results in less than 24 hours, uh, all you know in an automated fashion.

So there are sort of no data uh error issues along the way.

And as a result, um the cost of testing in Massachusetts, the cost of an individual test has gone from over $100 uh to, you know, generally speaking, you can pay $50 or $60 now.

Uh, but we uh we charge uh $26.50 in in some of our programs for uh for a PCR test with 24-hour results, and that drives everybody else to lower their prices as well.

And uh we're now uh you know pretty much the state with the most robust testing uh infrastructure in the US.

And we've been doing testing elsewhere and and and we also do testing like uh in other ways like uh antigen testing and this cool technology called pooled testing, where

I'm pretty sure your your school system uses Project Beacon for uh for

So I'm in Brookline, which is just outside of Austin.

So they've been using it.

I've gone to the with my family, the Revere um state testing, the Framingham one.

Um we probably don't need to get get into what a disaster testing has been, but it's been yeah, everywhere I've seen it, you know, a solution, it's been Project Beacon.

What's the pool testing?

Like what is that?

That sounds really cool.

It's uh so let's assume that a that a COVID test costs $25 uh you know at it at its cheapest for one person.

Uh but what if we could put 10 people swabs into the same tube?

If that tube comes back negative, then you know all 10 of those people are negative, and suddenly rather than costing $25 a person, it costs $2.50 a person.

Okay.

So we do we do this for schools.

You you don't want to do it in a place where there's lots of COVID.

Yeah.

But if you have if if you have high confidence that very few people in an organization like an employer or a school or a college uh have are are likely to have COVID, then it's a great way to do sort of weekly surveillance testing.

And uh so we do that in Massachusetts for hundreds of schools now, and it's uh three dollars per as low as three dollars per person per test.

That's amazing.

I mean, you've talked a lot about the price, but the the thing that keeps coming into my mind as you're talking about bringing down the price is that of course you're increasing the capacity to do the testing as well.

And that strikes me as you know, money, money's kind of fungible, right?

It can it they can come up with that, but the ability to get the entire population through a testing program in reasonable time, that's that's something that we're still coming up with.

And so as we look toward May and June, there's a situation where the vast majority of people, uh adults perhaps, have gotten a vaccine.

Uh, kids won't have been vaccinated at that point.

But if we have robust infrastructure at schools to be able to do pool testing easily, inexpensively, uh, and and and that exists at you know, wealthy schools, less wealthy schools, et cetera, then we have a really good system in place where we can monitor and make sure that new variants aren't creeping up and uh it's it's it's a pretty robust look at um at the state of of health here in Massachusetts.

So we're we're pretty psyched to have been a part of it.

Like that's important.

That's right.

Um so that's partly why they're doing or that is why they're doing the pool testing to coincide with that opening up for uh full time.

They've had a hybrid.

I mean, every school is doing it a little differently, but my my schools have had a hybrid um the last

few months.

Um I'm the next town out in in Newton, and we're uh I think April 5th, it goes back full time.

So you're looking forward to it.

Spain was

We were hit hard at the beginning.

And so they locked down very hard over the um before the summer last this time last year, and that worked really well until the summer, and then of course they opened up over the summer, and all the tourists came from all over Europe, and there was it was a particular genetic variant of COVID the or of coronavirus, which is detectable all over Europe because and it came from Spain, it came from the costas.

It's like you know, people bought it and it mixed and took it back home, and so the um, but they've managed to keep this the the vaccination situation in Europe's not great.

Um, it they've been a bit slow off the mark.

I think the UK and the US have and Israel have got off much quicker, and the EU's been slow off the mark.

But I think that's hard part of it is about um you know the industrial pipeline ramping up to produce the vaccines in the quantities for you know the population of the world.

So I don't you know if we'd have said a year ago that we're where we are, I don't think you would have complained complained.

I just think you know people in Europe are feeling oh, why have they why have they got it and we haven't?

I think that's the thing.

That's the the main thing.

So my my um we got four, three of them are at school.

One's off because there was a case in her class, so she's off now until, you know, and until after Easter because um if a case comes into an hour, they shut down that whole uh classroom.

Sorry, they shut down that classroom.

Um but the schools have been open, and so each of my children have had a a week off or two weeks off.

Celeste, the the one who's off now, she's on a third time of being off.

But generally speaking, they've been there, and that's been a um, you know, an absolute blessing because I don't think I could have taken another six months of them not at school.

That was just, you know, 2020 was pretty fierce.

So anyway, that was all cool.

That was all cool.

Project Beacon.

Um, this is Django chat.

Does it use Django?

We do, we do.

Uh and and so, you know, I think when we when we started this up and decided that we needed to build our own software platform, it was um we knew we would need to do custom stuff.

Uh this was not, you know, you couldn't grab off-the-shelf libraries for COVID testing.

You know, that's not not the type of thing that exists.

Uh so we needed a lot of flexibility, but at the same time, we needed to work quickly.

Uh the the difference between shipping something two weeks earlier uh might have been thousands of people's tests, right?

Like we're we're sort of racing against the clock in a in a public health situation.

So um so in July of 2020, we we started kicking this off.

And uh as as Will knows, I've spent a lot of time with Django over the course of my career.

I'm very familiar with it.

Uh and uh in in talking to, you know, obviously uh didn't have time to to hire FTEs, full-time uh folks, uh and I'm not really sure who would want a full-time role, knowing that as soon as COVID is done, who the heck knows what's going on with your job.

Uh, you know, I was willing, I was willing to do that, but I don't know what everybody is.

But uh, you know, so so I I started talking to uh an agency that I'm friendly with because I'm I'm an alum.

I I it was one of my first jobs after school.

I worked at at this agency uh called Viget, which is which is great.

They're historically like a Rails and React shop, uh, but they've they've done some stuff with Django, and obviously, you know, those those two uh frameworks are you know cousins of each other in in a lot of ways.

Uh and so had a quick conversation with them, said, Hey, do you guys think you'd be able to support me?

And and this might be a this might be a four-week project, this might be a four-month project, who the heck knows?

Uh, and and we uh we got to work really quickly.

And um, you know, by the by the end of August, we uh were getting ourselves into gear and had some some early launches, and and that uh test site in Revere, Massachusetts, that that Will mentioned earlier, uh was our first one to open up in terms of high capacity test sites, and we did that in October.

Uh, and pretty quickly we were we were doing um you know the plurality of public testing in Massachusetts before the end of the year.

So it was uh you know a pretty rapid pace.

And and Django was that was the key part of it, right?

Like it was we had we had to build quickly and we needed to to to do it in a way that was uh where new members of the team could pick it up uh easily and and get a handle on what we were doing.

And and and so it's React on the front end, uh a GraphQL interface to to Django on the back end, uh and um and then we we hosted on Apptable, which is a uh hosting provider that's built on AWS.

It's kind of like Heroku for healthcare, I guess is like one of the easiest ways to describe it.

So sort of a Git and Docker-based uh deploy process.

Okay.

Uh that uh again, I've been using for years on on most projects, and um, and so I'm really familiar with it.

So it's it's it's really like what's the hammer in my tool belt and can I force other people to use those those same hammers along the way.

And when someone can't you talked about getting a new person on to use the same tools.

When if you can onboard them, say, look, it's just vanilla, this, it's vanilla, that.

It's you know, if you need to learn this library, it's just read the readme that you know it's it's not complicated.

It's not, you know, I haven't done anything homebrew.

Right, right, right.

And you know, there are things that are not always perfect about Django, but I think it's a really good Swiss Army knife for a lot of these types of things and and can go a long way in a hurry.

So that's all like a probably a mobile-friendly website would would react.

That was sort of a constant question that we got early on.

But um I'm a pretty big believer in in the open web.

And you know, we this way we can serve anybody who has a modern browser at their disposal, uh, whether it's probably

And um we also are we're translated into seven languages, so uh that's you know something that you don't often have to do for you know an early stage uh product here, but um we needed to manage that kind of stuff as well.

So uh it's uh accessibility is pretty pretty huge to us.

Uh we want to make sure screen readers have you know a as close to a first class experience as they possibly can.

So all those types of things you have to worry about early on in public health situations.

But you've got that.

In this case, this isn't technically uh like a government um website, so we we don't have those specific types of restrictions, but um we would hold ourselves to accountable to to those types of bars anyway.

It's just you know

So fantastic.

I'm really curious to ask.

So we've had a a number of consultants on um from your side, what was the you know, so you already knew Vaguette, um, but what is that process like?

So presumably you said, okay, here's what round one looks like in terms of functionality.

Um can you talk about on your side of how you interact with them um and then it grows from there?

Like you said, you know, we need login, like like Y GraphQL, for example.

Like how how are those decisions made, I guess?

Is it all just you saying, hey, I want this, or how much back and forth

is there?

So I I would say it's it's probably a little bit different from the normal uh client-vendor relationship in that uh every day, you know, at 10 30 a.m.

uh we have our stand up and I'm in it, I I lead it.

Uh and you know, so so unlike probably most client relationships in this context, it's it's very, very hands-on.

They're full teammates of mine, um and uh we we interact that way.

But when it comes to uh decisions around architecture and and tech, uh I think in in the early days, it was uh often me making a proposal and seeing how that how that stuck with the team.

But GraphQL, for instance, um I'm I'm probably more of a GraphQL skeptic than I am like a GraphQL fanboy.

Uh and you know, I think that there are uh really nice things about it.

It's really flexible.

Uh but at the same time, if if I'm this is how old I am.

If I'm looking at like web logs to get a sense of like how certain features are used, it's just a bunch of post requests to GraphQL.

Like I can't see anything, right?

Like it, and and so you know, the the the ability to to track and measure certain things.

You're the youngest one on this call, by the way.

And you know, where restful stuff, you you're like, oh, these are the features that are most used, right?

Like as a as a product person and as a as a sort of exec um, you know, GraphQL doesn't make my life easy.

But uh on the other hand, you know, it really came down to speed and being able to do it.

And and since speed was was gonna win here, it was hey, we we can really iterate on this and and expand our our scope in this API a lot faster with GraphQL than we'd be able to do with a RESTful framework.

And I was like, all right, that's a convincing argument, let's do it.

Um, and I still complain about the the measurement and you know logging uh abilities there, but but on the whole, it it has been uh I think the right decision from from sort of a speed and uh and effectiveness front there.

So a lot of that was give and take.

Um you know, there there were we sort of had, again, I'm I'm an old man and and so you know single page uh front-end frameworks are occasionally tough for me to swallow when it comes to you know the challenges of how those get debugged and you know not necessarily having a full request associated with each thing that you want to do and and so on.

There's a double-edged sword to all those things.

And so, you know, we have those conversations, and um, ultimately, I want the team to be able to uh do something that they're comfortable and confident in.

And sometimes that means I'm gonna bend, but other times I need to push the team to uh to to take on some things that might be a little uncomfortable for them because either you know we need good audit logs of what's going on because this is healthcare, and uh, you know, those types of concerns uh might ultimately just need to to win out.

And so it's it's been a really great collaborative um relationship that that we've had over these past you know eight months or so that we've been working together.

And uh but it but it's different from from your normal uh client vendor relationship, and I I think, at least from my experience.

So it's uh it's been really great.

I mean, not just the software testing, but you know, because it's healthcare, like you know, when I'm in line in Revere, you want it to work.

Is is there any way to to test to do a dry run, like with the physical the online and the offline?

I uh how does that work?

We we have a great relationship with our lab, which is which is the Broad Institute.

Uh, and so you know, we have a we have a staging environment with them as well, so we we can you know end-to-end uh throw stuff through this, but you know, I'm folks are presumably not seeing video most of this, but I have like barcode scanners sitting on my desk and uh you know label printers for for all sorts of stuff.

So a lot of the folks on our team similarly are sort of equipped with everything that you're gonna have at a testing site, which you know, uh iPads and and MacBook Airs are sort of the hardware that we use there.

We have these consumer grade Dymo label printers, we have these, you know, Amazon's bought $60 barcode scanners.

Nothing is like special or you know super hard to come by.

And so we can we can put them in the hands of even in this sort of COVID everybody is remote world, we can, you know, have folks on our team who have access to the the same type of equipment that we would use in revere at the testing site.

Uh, but then you know, when a testing site is going up, then we spend, you know, a day in advance uh running some folks through it and making sure that everything's everything's working.

But um in the end, it's it's just like keep it as simple as possible so that we have as few things that can that can go wrong as as possible in the end.

And most healthcare systems are overcomplicated.

And uh in our case, we only need to do COVID testing.

We don't need to do other genetic testing, we don't need to do flu vaccines or anything like that.

If you show up, we know what you're getting.

Uh you you just get into one line and we need to do exactly one thing right.

So uh that gives us a lot of flexibility and a lot of freedom and and helps us do a good job of it.

There must though have been in production errors.

So how are you tracking those?

So we use we use sentry to log any exceptions, um, you know, uh familiar tools, right?

Uh Century's

I think uh it's it's the clear, it's it's the clear go-to uh in in any of these events.

I think in in our case, we don't we don't have things like Google Analytics or or anything of that nature on there.

We only collect the information that uh you have shared to register with us, and the only information that you share to register with us is what we are required to report for, you know, like uh state public health reporting.

So we often don't have a lot of information uh about you know the users who are going through our product, and that sometimes makes it a little more tricky than it might be if we had a you know if we were a more typical consumer platform that might have a robust set of JavaScript-based uh you know tracking tools.

And we don't have those, but uh we we can we can generally do what we need to do.

Uh there are some challenges.

One thing, uh speaking, thinking about Europe, uh Carlton, uh we obviously focus on Massachusetts and and uh more generally New England, which is the northeast US.

And um we do some testing for businesses uh that want to test their employees, and one of those uh employers has is a multinational uh corporation that has employees in Europe who occasionally travel to the US and they need to schedule testing.

And we found out that if you are on the east side of uh of the UTC line, uh we have a front-end bug that just like totally borks the process for getting an appointment.

Like and we had no idea that this was the case because none of us were east of the UTC line.

You you built this in Boston, right?

And so we we started getting these complaints like, do we have restrictions that mean people from the Netherlands are not allowed to book appointments?

I'm like, no, we definitely don't have those restrictions.

And we're like, it all seems to work for us, and then I change my time zone and suddenly you know it all blows up.

So uh the time zones are always the thing that bites you, right?

Like I've got the do you remember Darcy Lee and Muttley?

I've got a picture of Muttley in my mind now for Russian, Russian, Russian, Russian time zones.

Totally.

Do you have more questions, Carlton?

I think we should swing all the way back to the beginning, though, and do it, you know, and ask, you know, well, okay, so that's what you're doing right now, but how did you get going, Jackson?

Like what was your how did you get into programming in Django and all those things?

That's your origin story.

So I was a nerdy kid in a lot of ways, and I I think there are pictures of me programming in TI Basic when I was like, I don't know, three, uh, like a sort of ridiculously young age.

I think part of me learning to read was reading these T uh Texas instruments, TI994A, TI Basic books, and like copying them in onto the computer and trying to see if they would run and then making changes to them to And

They had had no clue.

My parents are were totally uh non-technical for for at least most most of my life.

And um, you know, then eventually I I uh had like a couple of neighbors who were mentors who would sort of show me the ropes, and eventually I had you know a four-color CGA display where I could, you know, do more interesting things, and it was it was it was pretty pretty amazing and intense.

But um, and so I I uh yeah, I was sort of like my life was baseball and computers for you know most of my childhood.

Um, and then I kind of put it away in college because it was sort of the dot-com bust uh immediately prior to me going to college.

And the the impression of people who worked in technology at that point was sort of the guy who lives in his parents' basement and spends his days and nights in his underwear and and and that kind of stuff.

And and I didn't see myself in in that role at the time.

What goes around comes around, right?

But uh uh so in college I was uh I was a music and philosophy double major, so to entirely, entirely non-technical.

Nice, nice.

Uh but you know, uh even even through college, I I I worked in the Network Operations Center and was, you know, building websites for faculty and and that kind of thing.

So I I sort of stayed technical, but I never took a CS class.

Um and then uh and then after school, I I took a job at uh at a public affairs firm as like an entry-level web dev.

They were like, you have no credentials, do you know what you're doing?

I was like, I think I know what I'm doing, we'll find out.

Um and and yeah, it I was I was in DC for that, uh Washington, DC, and um ended up working on some some pretty great sort of public affairs uh campaigns.

After a couple years, I I took uh a job at VIGET um and started their user experience program.

So I I kind of got a little bit more into design at that point.

Um and uh I think I might have just gotten a ding.

Let me put myself back on do not disturb.

So uh yeah, I took a I after that I took a job at Viget and uh started their user experience team, and and that sort of took my life a little closer to uh to design.

Um there are a couple funny stories about how I sort of got into that um relating to uh, you know, at one point our at this at this public affairs firm, our designer had had quit, and uh we got a request to do a site for um, you know, I think uh Hillary Clinton's uh Senate campaign uh way back in the day.

And we had to come up with some mock-ups and there was no designer around.

And so we were like, what are we gonna do?

These are due on Monday, it's Friday, or something like that.

I'm like, hey guys, you guys keep looking for a contractor.

I'm gonna see what I can come up with.

If we like my stuff, then great.

And uh we ended up using it for the pitch, and and I think we we won the the contract, and and so I sort of became like the de facto.

Right, right, right.

Exactly.

Who knew?

And um, so yeah, at Vigot I started the UX team and maybe wrote a total of seven lines of code during the entire time I was there.

I was definitely a a designer, and um then I I went out west to say I want to be at a startup and went to LinkedIn.

And uh it by that time I was maybe the 250th employee, so it was not a startup anymore, and I didn't I didn't know the difference at the time.

And uh it was it was definitely in growth mode.

I worked on um a bunch of features that uh still live to this day.

I was uh you know partially responsible for profiles on LinkedIn, homepage, and a lot of uh, you know, people you may know and and and things like that that uh still continue to live.

So that was a that was a cool experience, but I really wanted to be at a smaller uh company.

So the the cliffs notes are I went to Postgres, which for those of you uh who've been around a while was this rad platform that competed with Tumblr in the in the early days, but you could you know post your post to your blog by email or via the web.

And uh I remember that.

Yeah.

And uh we had a great team uh in the mission in San Francisco.

Uh so that was a a lot of fun.

And then I sort of married into healthcare and started a a digital health uh product called Kinsites, which is a community for parents of kids with rare and complex diseases, that um that I was the CEO and then I demoted myself to CTO uh and and worked on that for for four years.

And uh we sold that to care.com, which brought me to Boston.

Uh care.com is a service best known as a place that you find nannies for for your kids, uh, but you can also find housekeepers and uh senior care folks.

And so I ran product and and and user experience there.

Um and that was it was a publicly traded company, so uh a lot of different sorts of skills being on the on the management team at a company like that than at a uh at a small you know digital health startup.

And then that led into Path AI, where I spent three years helping uh build the product design and engineering teams as we uh tried to implement machine learning and and computer vision to help detect uh diseases like cancer and and other sorts of things like that in in pathology imagery.

So that was a super rewarding time.

And I know that there have been folks on on the podcast who uh who've worked at Path AI as well.

So uh probably heard a little bit about that in the past.

So but that was a great experience and and I took that right up to COVID times.

Wow.

Like you've been west, you've been east, you've you know.

Just the coast, Carlton.

Just the coast.

There's what's in the middle?

Boulder, boulder.

Like I don't know.

I want to ask about um so at Django Boston, you gave a talk on a history of Django, um, which I know you said you threw together, but I found really interesting going through each of the major versions and the features.

When did you first see Django?

Because you were like really early on the Django train, as I recall.

So it was pretty early on, it was pre-1.0.

Uh, you know, the magic removal branch was the big news in in in Django land.

Uh and you know, I was I had a little bit of Python under my belt and um had been spent, it was spending most of my sort of professional day in in PHP and um, you know, sort of wanted something that was a little more MVC-ish and was looking around for what to do.

And it was like, all right, well, Rails is pretty popular, but you know, I'd have to sort of learning curve up on Ruby, but there's this Django thing.

Let me see, let me play with that a little bit.

And it, you know, it it did what I needed to do for uh for those early projects, and um, it just started becoming uh becoming that hammer in my belt.

And fortunately, it I I remember having discussions at the time uh about this, you know, fly by night, nobody's ever heard of it uh framework.

Why would we ever use this on client projects?

Uh and you know, as time went on, uh that that decision sounded a little less crazy over time.

So it was uh it it ended up serving me well.

So I'm I'm pretty fortunate in that regard.

We couldn't possibly use it now.

It's too old, it's boring.

It's like, you know, it's I don't know, it's exactly why you have to use it, but it's a different topic.

They were on something else when you joined because you joined well you were doing wearing a lot of hats, right?

You were product and head of engineering.

As as we grew, that sort of shifted.

Uh but yeah, there were a lot of hats that that were worn.

And early on when I changed the job.

It wasn't Django, yeah, right?

That's right.

Um and we had we had a couple developers who were focused on the web.

Most of the developers on the team, most of the engineers on the team were focused on machine learning, and they were all you know very heavily Python-based.

And uh, you know, we we uh had uh the the folks who were working on the on the web side of the platform uh uh were not uh they were experienced engineers, but they weren't super experienced web developers, and so they weren't um uh super tied into uh to the Java frameworks that they were using and weren't super familiar with it.

And there were a few uh sort of infrastructure choices that made it that that made most of our use cases a little bit more edge case, and so the documentation was a little more challenging, and you know, whether we were because we were in Java mode rather than Scala mode, and so most of the uh documentation sort of assumed uh that you were that you were operating in Scala.

Um, and we weren't, so the documentation was a little sparser, and and we would run into these edge and corner cases seemingly all the time.

Uh so as the as the team grew and as we were making decisions about where we were going to be going and and what we wanted the future to look like, um it felt attractive to me to be able to have all the engineers uh at the company have uh Lingua Franca and uh be able to use Python more broadly and and be able to sort of borrow from the work that everybody was doing.

Um and and you know, that meant that that Django became a you know a potential option there.

So we had a lot of uh conversations with the engineering team about directions that we could go.

I piloted out Django on a couple of of small microprojects to to help uh folks get accustomed to what that would look like and and what that infrastructure felt like without having to sort of overhaul the system.

But we had we had a couple of you know smaller services, some some internal, some external, that that were uh that I just rolled up my sleeves and implemented in Django, and folks were like, oh, huh, you can do that pretty easily.

And that was pretty fast, and you know, oh that seems pretty nice.

And after you know, a few weeks of that or or perhaps a few months of that, um, we decided that it it was worth it to uh sort of deprecate the Java side and uh start to start to spin up the the Python and and Django side.

So a lot of Django REST framework, um and and in that case it was more of a RESTful uh API initially than than GraphQL.

Um but yeah, uh as as Robbie talked about, you know, we it it became a pretty robust and and pretty large uh part of what we did there.

And and we definitely did get some some mileage out of allowing people to sort of flex between um working on the on the customer-facing product and working on the machine learning platform, which uh was also in Python.

So it was it was nice to have that sort of uh commonality across the org and the ability to to share some work and and some libraries here and there.

I you know, I was afraid you were gonna ask me about that because I'm worse about it right now with Project Beacon than I think I've ever been in my career.

Oh, you're running off master.

I'd I'd have to even look.

Like it is I'm like that disconnected from it right now mostly because we you know don't always have the time to do all the hygiene things that we would totally love to do.

Sure.

But I think a a a well-run and well executed product uh that does have good hygiene does keep uh up to date on those types of things.

There are there are the obvious reasons like security uh patches and bug fixes um but also just that um you know the the features that come along the way are good and useful and there will be useful improvements and I'd rather have small projects to get us up to speed and and up to date on a regular basis than have the enormous project when you find out that uh you know suddenly you're two years behind and it's gonna take you know three months of engineering time all hands on deck

at a high risk to to get up to a more recent version so um you know I'm a I'm a pretty big believer in that and and we did a pretty good job with uh uh at Pathai and I think we're we're we're still okay it's only a it's only an eight month old platform so it can't be that terrible but uh we're we're a little further behind than I would like I think

know we we're on you know 1.2

And so you know hiring it's it's an important component.

Security and and compliance I think it's an important component.

On one hand you think of compliance as like pinning a version and having something reliable and few changes but uh it just exposes you to uh to every vulnerability that comes across and you know makes it makes it a much bigger uh decision process.

So uh but yeah engineers are generally happy when they can go and hit latest in the docs and you know actually use them.

So it's it's it's good to be in that position.

Like for just from a liability perspective you know it if there was some bug that happened because you hadn't patched a version and then you got sued for that and you wouldn't have a leg to stand on because there's no reason to be on that software.

If they're on one five it tells you

Right.

That doesn't sound really great but if you make it a a a seamless process and you do it so that there are very you know few changes that need to happen along the way because you're constantly up to date then nobody notices and you get all those those positive advantages as well.

So um you know it's definitely I I think that you either need to stay very up to date or you will inevitably fall very very far behind because those that middle of the road hey this is going to be a mid-size project for us to to update is is probably the toughest one to justify.

So um so yeah I tend to to err on the former side so I

like that.

I mean we've covered a lot of things I guess you know you don't know but at some point testing will be or what what so project beacon so the code is there a potential for the code or the company to you know who knows what will happen with COVID but variants may be around for a long time so presumably the code base is useful in some way.

So we have a really great test suite um end-to-end tests that are like Cypress and Selenium uh decent decent unit and integration tests along the way as well and and you know a good uh a good deployment pipeline that and and and CI pipeline there.

So those types of things we've we've spent the time to put into place uh so that we can be confident that will when you show up at revere and you've got a QR code to get tested that it's actually going to work.

The long term and the legacy of that is something that we you know sort of continue to talk about.

We sort of had our have our hands full with actual you know work but you know every every month or two we we kind of take stock of that and it'll be interesting to see what the timeline looks like for this.

I think that's partially dependent upon uh the effectiveness of of vaccines against these other variants.

We know that the tests that we run can detect these other variants so it's you know certainly in the during 2021 it'll continue to be important and Project Beacon will continue to uh I'm sure do a lot of testing throughout the the rest of the year uh but what things look like in 2022 is is tougher to forecast and uh you know we'll we'll have to see what what the world looks like as we get closer to it.

It would be we we certainly all want this to have as lasting an impact as it possibly can and um you know we're we're now doing a lot more testing outside of Massachusetts uh than we than we ever have before and so yeah there's a there's a world in which this can you know be a component in uh whether it's regionally or or nationally or or beyond that in the in the public health infrastructure and uh you know hopefully we can make a decent contribution to to that ecosystem.

Yeah um and it would be it would actually be like a really disparaging comment to say that Django is popular in healthcare because bad software is really popular in healthcare too.

So uh you know I I I think not uncommon is the the way that I would put it and I think part of that is uh because of all the all the great things that we've talked about part of it is also just because of the the Python ecosystem right like um the the Ruby and uh and and Node uh communities have tons of libraries for web development and you know sort of the the typical tools associated for that but um

I just think back to when I was uh working on KinSites that that community platform for parents of kids with rare and complex diseases we needed to render out growth charts to help parents just chart their kids' growth and what do you know there's a python library for for that right like in in no other ecosystem do you find that kind of stuff but because of the the scientific and medical research community uh using python you end up having a lot of these crossov

ers that uh make your life a little bit easier a little bit simpler a little bit more reliable and you don't have to reinvent the wheel all the time in in healthcare so I think that's a uh key component there too.

Oh yeah please yeah do it so um one one thing that I didn't talk about um after I left Path AI, just I think this week last year, I joined uh the US Digital Response USDR, which is a nonprofit organization that uh helps staff uh important technology projects, uh especially related to COVID and and you know, sort of the 2020 world that we're living in.

And so I I led a team with USDR for uh four or five months, had the opportunity to contribute to some really amazing projects, like um the uh in New York City that when they had the PPE crisis and they didn't have enough PPE to go around during the first surge.

Uh my team worked uh with uh eight departments across the city to help them get a handle on where PPE existed and where they were sourcing it from and help them get a get a handle on what that supply and demand looked like.

We also worked on hospital capacity planning in Pennsylvania and uh outbreaks of COVID at homeless encampments in the Bay Area, um, in addition to many other projects that USDR worked on that that I didn't have a chance to contribute to.

So I think that uh for folks who are looking for uh who are learning uh Django and learning Python and and wanting to get their feet wet, or folks who uh have perhaps a gap in their in their career or looking for something to do uh in off hours to extend their skills, USDR is a great place to spend that time and and make a contribution to uh efforts across the country that can help with all sorts of uh culturally, socially, and politically important issues and uh a

time well spent for for anybody who uh who is looking to develop those sorts of things.

So strongly encouraged that US Digital Response check it out.

I should ask you maybe offline, um, we could probably get someone from there to to come on the show and talk about that.

But we can we can do that separately.

No, I'm sure they would I'm sure they'd love to.

We just have chartered ourselves to not make a profit, but nobody has put in the paperwork or paid the lawyers to make us a nonprofit.

So you technically can't volunteer to uh to work with Project Beacon uh for better or for worse.

Um but certainly we we are hiring for uh a lot of roles, uh technical and non-technical.

So if you're in the Massachusetts area, you know, we tend to or in or in the New England area, there are definitely roles that uh that we could use some help on, and and we we pay actual uh cash money for that rather than just taking your time.

So uh so if you're interested, definitely happy to talk to to good motivated folks.

And uh and our our partners at Figet are also uh frequently hiring for more technical roles there and that applies to anybody uh at least across the country uh here in the United States.

So they're they're a great shop and do some great work and um you know would be would be great to work with with folks who uh who join their team as well.

We are at um DjangoChat.com, Chat Django on Twitter.

Um thank you again.

We'll see everyone next time.

Join us next time.

Good to talk with you guys.

Good talk to you.

Bye bye.