TEC Talks Podcast: David Koontz

You're listening to Tech Talks, a podcast by the Technology Education Collaborative.

Tech is an Arizona nonprofit that empowers people with useful information about the technology

they use each and every day.

Today we're sitting down with David Koontz.

Hello, David.

Hi.

Thank you for being here today.

Thanks for having me.

So the way this works is we ask everybody the same five questions, and we just want

to find out what a day in the life is like.

Okay.

All right.

So the first question is an easy one.

What's your title and position?

I'm a senior software engineer.

That's, I think, title and position, really.

Okay.

Nobody's not that fancy.

Fair enough.

Fair enough.

And what does that mean?

So what specifically do you do on a daily basis?

So I guess I can clarify, I'm a senior software engineer that works on the front end.

We are divided up into teams that kind of traditionally have owned part of our application,

little slice of the application, and that's front end and back end combined.

So I work on what formerly was the compliance team.

We're becoming a little more cross-domain.

They're trying to mix it up a little bit.

So in terms of what I do on a daily basis, we have a product owner that is working with

our various internal customers.

So we are servicing the other departments that go out and actually make money, that

actually keep the company in business, and they have various needs that they need.

From a sales perspective, we do a lot of, we do a safety compliance for large companies,

like for vendors going to come on site, and you want to make sure that they actually know

how to go up on a tall electrical pole and not electrocute themselves or break things.

It's usually mostly around the safety of the people who are coming to do the work, and

a little bit less about the they're not going to break things because we have liability

insurance and stuff.

So the goal is to reduce any kind of casualties, and unfortunately, these are the kinds of

industries where those sorts of things happen.

High voltage electrical, chemical, heavy industrial, confined spaces, things like that.

So we have a lot of need to do things like audits of their safety manuals, things like

that.

And so my team historically has supported all that.

We have a product owner that goes and talks to all those different departments that need

to deal with that, and they get the request list that's 10 million miles long and is way

more than any team could ever do in 100 lifetimes, of course.

And they work with the internal departments, their customers, to boil that down into, okay,

what are the three most important things you have, right?

And if we did this, does it really have a value?

And they're trying to become a little more metrics-driven around, do we just kind of

think that has value, or can we show that that actually has value, or are we just kind

of guessing here, or do we have some sort of data to back this up?

And then they come to us, and they work with us to develop a set of a little more formal

acceptance criteria around what should this thing do.

And then part of my job as a senior is to be on those calls or those meetings with our

teams almost exclusively remote.

We have a few people in an office in Southern California, and then the rest of us are kind

of spread all over.

So all our calls are online.

Then the people who are in the office, they'll all individually get on their stations.

Every once in a while, you have a couple people in a room together, but for the most part,

everyone's individually on.

So we get on calls with our product owner, and then we work out that they're not technical

usually.

They're products, so they're kind of at this intersection between business and a little

bit of tech, and they're more in a management, kind of project management capacity.

And so we work with them to sort of explain or clarify, that's easy, that's hard.

This would actually be way worse than that in terms of complexity, and if we could combine

these two things, we could do it as one thing, and it's really not that much more complex

than doing, we could do three instead of one, those sorts of things that they would not

realistically have any insight into, you wouldn't expect them to.

And so we work out our acceptance criteria, and then we can put some sort of estimate

on it so that they can sort of budget our team's time across all the different internal

clients that have demands on it that want things.

And they can say, okay, we're going to give this much of sort of features to this team,

we're going to give this much features to this team, and then they're given their marching

orders by higher-ups who have decided that this quarter maybe we're going to focus more

on this side versus that side, some sort of high-level objective of where we should go.

So we get our what are called user stories written out and the acceptance criteria put

on them, and we've given them some sort of estimate, and then finally they can be assigned

into a particular period of work, we call them sprints, because they use Scrum.

I keep advocating for Kanban, but they're pretty locked in on Scrum.

But either way, you would have a backlog of priority items, these are the next few things

that should be worked on in order to get some goal done, completed, and they're going to

be assigned out to an individual or maybe two people as a pair, and then every day you're

going to come in and you're going to have a current thing you're working on and a few

things in your backlog and you're going to pick it up and you're going to move it forward

as far as you can that day, and that's a day.

I'm going to deviate a little and add a side sub bonus question, and I'm going to ask you,

so what percentage, and I know it probably vacillates, but what percentage-ish would

you give that you spend time in meetings and kind of doing more of the business workflow

versus actual technical work?

Just to give someone who wants to get into this an idea, and then sub sub question, how

impacted is that by your seniority?

Is it that you do less technical work as you become more senior?

Great question.

This company, I think, is quite good relative to other companies I've been at, and I would

say I spend 10 to 20 percent of any given day in meetings tops, unless it's a very dedicated

week where we're doing planning, like quarterly they do kind of a planning week that's dedicated

to that purpose, and so it's all about taking a huge backlog of things and breaking them

down and kind of doing that work.

So on any given day, it might be just a half hour meeting, even 20 minutes.

It kind of just depends on what's going on.

A lot of times we try to sort of eat the elephant one bite at a time, so there's a story that's

coming in maybe two months, and we're going to meet for half an hour each week for the

next four weeks, just to kind of chip away at it, have some time to think about it, maybe

go ask, because usually the result of these meetings is, well, there's some questions

we have to answer to know if it should be A or B. We just don't know.

We need to go find someone who worked on that, who's a back-end engineer maybe, because I

have a front-end experience, but I don't know the back-end very well, or maybe the back-end

people on our team don't know that, or they couldn't attend.

So there's a lot of times we have to go and answer questions, so it's not the kind of

thing that we can do, just give us four hours and we'll just blast out the whole thing.

We kind of have to do it bit by bit.

So it tends to be a fairly small amount, 10, 20% tops.

On any given day, it might be a little bit higher, a little bit lower, and then for me,

I do get pulled into more meetings, but we tend to invite everyone as optional, and our

junior developers on our team tend to attend those, because they're very interested in

sort of being included and knowing what's going on, and our team has two seniors and

three juniors.

Well, two juniors and a mid.

She started as kind of a junior two years ago, and now I would say she's definitely

more at the mid-level, and then we have people who just moved over from QA, for example,

maybe six months ago.

And then we have a back-end engineer who cross-trained in front-end, and he's learning a completely

different language, a whole different paradigm, and so he's a senior developer in the sense

of he's been developing for a long time, but he's very junior because he hasn't spent much

time doing front-end kinds of things, so browser issues, just the kinds of things you might

run into as a front-end engineer, he does not super in his wheelhouse.

He just doesn't have a lot of traditional experience with it.

Sure.

Okay.

Good answer.

Thank you.

All right.

And then, so next question.

So what is your least favorite thing about your job, because everybody has something

they don't particularly love?

Definitely.

So I have to pick one, right?

Yeah.

And I'm not crapping on my job or anything.

It's actually quite great.

But there's always many faceted things for something that's complex.

My least favorite thing is probably that testing is, so we have dedicated QA people on our

team, which is fantastic.

I love that.

Some companies are like, half the devs be the QAs, and I always just shake my head like

those are different skills.

It is a skilled position.

It's a whole different thing, and to expect someone to be good at both of those means

they're probably going to be slightly mediocre both.

And just to clarify for people who are just entering the field or just want to learn more

about it, QA is quality assurance.

Yes.

And their job is to break the stuff that we are sitting there with our smile and our thumbs

up saying, it works.

Trust me.

And they go, I'll be the judge of that.

And then they click, click, click, click, and they're like, look, it breaks over here.

And we're like, how did you, how did you, but I just, okay, thanks.

And we are actually quite appreciative because they catch all these issues before they ever

get out to a customer, before they get to product.

So it's internal to our team.

So before the other teams, and you know, there can be a little bit of politics about, hey,

why does your team just create really buggy features, right?

They protect us from that.

They are like kind of our reputation as a development team by making sure that we catch

those things internally and fix them, and the rest of the world doesn't even have to

know that they ever happened.

I hadn't thought about that facet of it before.

That's actually really, that's really insightful.

So I love having dedicated QA.

But one of our issues is that we don't have a lot of QA resources relative to the surface

area.

And our area with like audits and stuff like that are very complex.

It's probably the most complex aspect of the application.

It's the oldest part of the application, which is its own set of issues.

So my biggest thing I dislike is the difficulty with which we can carry out like a really

robust test suite.

And I have been talking to people, and there is an effort to automate more of the testing,

but that's relatively slow.

So it's sort of like you can throw resources at it to some degree, but then those automated

tests can be also very brittle and break on you all the time, and we are changing the

app a lot.

It evolved since I've been on this team for two years.

We've changed the UI.

We've changed it again.

We've changed it again.

And that's all, I'm not complaining.

That's normal.

That's, we tried a thing.

It works in this way.

It doesn't work in this way.

We thought the customers would love this, and it turns out no one's using the feature,

or it doesn't actually make this process any better, or people are still spending a ton

of time doing these things, and we're still getting support calls about it.

And it's kind of like, well, clearly that's not giving them the information they need,

so we need to try something else.

So there is a natural, I feel sometimes developers are kind of like, oh, the product people,

they can't just get it right the first time.

It's like who gets anything right the first time?

So we're going to make changes to our UI.

That's going to happen.

But that breaks all your tests, and so we have this issue of it can be very difficult

to write your code.

What I love to do is write your code, run the tests, and then see if they work.

And some people say, well, write unit tests, do test-driven development, things like that.

And then these issues that I have any issues with get caught by unit tests.

This is all much larger level integration testing, functional testing kind of thing.

And that's the place where I am very hopeful that maybe AI can actually help us out here

and start to do.

We have a hackathon coming up, and my project that I'm running is doing local tests running

through Selenium based on the written acceptance criteria, the human language acceptance criteria,

so that the AI runner reads the acceptance criteria and executes the actions of the acceptance

criteria.

And that will do two things.

One, it will show us where our acceptance criteria is lacking, because we didn't specify

a step.

And that can be really useful, because that can surface, oh, yeah, I didn't think about

that.

You get six people in a room, and we're all kind of nodding our heads, yeah, this looks

good.

And then the theory meets reality, and you hit the brick wall, and all of a sudden, like,

oops, that actually doesn't work because of this thing.

So it would help us do some of that.

And then also, it would give us a way to validate our features at an earlier stage without asking

QA to manually go through their script that they have, where they have a 15-point checklist

that they're going, boom, boom, boom, boom, boom, and hitting.

And they're very meticulous and precise about doing that.

But that is a limited resource.

You cannot just scale that up, you know, they only have so many hours in a day.

And we can throw some machines at it to maybe go down some other paths that are at least

a first pass.

So it's done that first before we ever bring it to the QA, so we're not wasting their time.

I think that's one of the best examples of utilizing AI for impactful efficiency that

I've heard yet.

And I've had several huge AI projects, and I've been immersed in it for about at least

10 months now.

And I have to tell you, that is probably one of the best use cases I have yet heard, just

for what it's worth.

I'm sure I'm not the only one working on this, there must be a use case.

There's lots of ideas on using AI and how to use it, and you can create an efficiency

without actually increasing productivity or operational value, right?

Like something can be more efficient, but that doesn't do anything.

And I think that's something that gets lost in that discussion a lot, but that's a different

podcast.

So anyways, but I have to say, I like that.

So on a brighter note, what is your favorite thing about your job?

My favorite thing about the job, I'm going to cheat, I'm going to split it.

It's okay.

So there's technical and there's a non-technical.

Fair enough.

So my non-technical is absolutely the team that I work with.

We have a company, and I can only speak kind of to my little old department, the developers,

I can't speak to, it's a very large company, but within our engineering team, there is

a lot of camaraderie.

The UI team has its own guild, weekly meeting, chat channel teams and all that kind of stuff.

So there's a sense of like, this is our code base.

We own this.

We got to make it the nicest place to live that we can.

And all of us here, none of us were here at the beginning.

We've all inherited this thing, so it's only seven years old, but it was also built very

quickly to get something running before they ran out of money, kind of a deal.

So we have a lot of that kind of lying around, and it's also written by people who didn't

know the language very well.

So there's a lot of sort of idiomatic issues of, we probably wouldn't have designed it

that way if it was us today doing this.

We also have the benefit of hindsight, so of course we're going to make better decisions

than they could when they kind of didn't quite know what they were building yet.

So the team, and then the way the company supports people to move around.

So like I said, we have a QA engineer who moved over.

We have, at the time, a very junior woman who came on as an engineer.

We have a back end who's now front end.

That's where we're getting our junior engineers, and we'll hire mids and seniors from around.

But there's a strong sense of like, yeah, I mean, if anyone has a desire and they want

to put in the work, they can obviously train into this.

There's not like, we don't have anything magical.

It's just engineering.

Anyone can learn this.

So there's a pretty good sense of like mobility and support for that, right?

Like I never get pushback on, I'm going to go pair with a junior, and a junior hits me

up and says, hey, do you have a couple hours this afternoon to move over this thing?

And I never get any pushback on that.

That's my favorite thing kind of culture wise.

Sure.

Fair enough.

My favorite thing technically is that we work in Elm, the Elm programming language, which

is a pure functional programming language for web development.

So it compiles to JavaScript.

You can think of it the same way that TypeScript produces JavaScript.

It's kind of its own language and has its own like extra rules, but at the end, it becomes

JavaScript.

Elm is the same kind of thing, except that the rules that it has are extremely different

from say a JavaScript or TypeScript in that it's a pure functional language.

So it's closer to like a Haskell or pure script or things of that nature than it is to Java

or C sharp or JavaScript or Python.

Okay.

Fair enough.

All right.

And then finally, what is one practical thing you think somebody who is looking at getting

into your industry, like what is the like practical, actual action oriented thing you

would advise for them to do?

Like what's one practical thing somebody could do?

Is this someone who doesn't know anything about software engineering right now and is

just kind of interested in this or someone who's kind of...

Let's say they're at least enrolled in some like BIT or IT classes or CNT classes, right?

So they know they want to quote get into tech, which is basically the demographic this particular

podcast segment is targeted to.

So they've taken some classes.

They know that they like technology.

Maybe they enjoy coding.

But what I've really found is there's just complete overwhelm.

They don't know, should I get certifications?

Do I not get certifications?

What classes do I want to take?

And that's what this podcast is trying to try aiming to sort of address, right?

I could speak to software engineering more than the other tech is here, right?

Yeah.

Well, that's one thing.

If someone wants to be a software engineer, if they're like, okay, I think I want to be

a software engineer.

Gotcha.

What is something practical they can do?

Is there a class they should take, a language they should learn, a meeting they should attend?

Like what do they do?

Yeah.

So it's going to depend on location.

If you're in a big city, you're going to have vastly higher options, more options for meetups

and things like that.

For real life people, there are a ton of online communities, of course.

There's Discord groups, Slack groups.

So my starting point that I would usually point people towards would be to learn JavaScript

and to just start building things.

It's a little bit like the Malcolm Gladwell's 10,000 hours, which is misunderstood a lot.

But there is a truth in, there is some number of reps that have to be done to get over certain

humps.

A good example of this would be when a junior programmer, so I taught for a bunch of years

software engineering, like at the college level, and a very common occurrence would

be, let's say, students in there, like through their first year of like a four-year program.

And so they, you know, we're starting to write some real programs now where these are not

10, 15, 100 line programs.

These are maybe hundreds, if not a thousand lines of code.

They would have a problem and they would sit there and they would pause off for a while.

So they'd flag me down and I'd come over and they would say, oh, it's not working.

And I would just like immediately point at something and they'd say, how did you do that?

It's like, well, I noticed that you weren't indented, right?

And you're missing a semicolon here and there's not actually a brace here.

I'd say, how do you do that?

It's like, 20 years, 20 years to look at this, that's how I do it.

It's not a trick, you know, there's not a mnemonic I memorized or something.

It's just, I've looked at a lot of code over a lot of time.

And so there's elements like that, that at the beginning, everything is so hard.

It's just so difficult to get anything to work that those things do get easier.

I'm not saying everything gets easy, but certain elements become internalized a little bit

more to where it kind of fades away and you don't see the semicolons and the databases.

They're there.

And you would actually notice if they're not there or if they're misplaced, but you're

not spending much brain power dealing with those because those are the absolutely completely

uninteresting parts of programming.

In fact, those aren't even programming, that's just typing.

That's just satisfying the compiler, right?

It's like grammar.

I guess you could argue grammar's part of writing, but you know, it's the most interesting

part of it.

It's more of a mechanical part of it.

Exactly.

So those are usually, those are never part of the interesting problem you're solving.

They're a thing you have to do to make the computer happy.

So getting over that hump, I think, is pretty difficult for a lot of people when they're

first starting out.

They think, this isn't for me, I can't do this, it's too hard.

And I would just encourage people that there is a horizon, you do eventually get to where

you can see the end of that, and it starts to become easier, but it does take a certain

amount of time.

So whether you're writing something, a big project, small project, just be out there

starting to work on things, have a goal, a goal that you can fail at.

So it can't be like, I'm going to, my goal is to write code.

Okay, I mean, how do you know if you succeed or failed?

I mean, there is value in saying, I'm just going to write code every day.

That's perfectly valid.

You need a goal that you can fail at, so that you can then say, what did I not know that

I need to learn, or what do I need to go learn to finish this project?

I want to write a web page that talks, uses an API, like a Google Maps API, and talks

to a different web page.

That's a different challenge than saying, I want to make a web page that as the user

clicks on things, it's updating things and hiding and showing things and animating.

Those are two different problems to solve, both on a web page, and they're both useful

things, and eventually you will know how to do both of those, but you kind of pick

a thing, go after it, and don't alter your criteria too much to make it easier to do,

like figure out what you don't know, and then use that as an justification to then go learn

that thing.

And you can get in a situation where the thing you've picked is maybe too big for you right

now.

It's too big for challenge.

You didn't realize that integrating authentication into your app is like this gigantic thing

that makes senior engineers cry.

Okay, maybe if you get down that rabbit hole, you do decide to not go down that path, but

smaller bite-sized things, pick something, go after it, there's going to be tons you

don't know, you'll learn along the way, and then you will have a singular thing that now

you know how to do at some level of competency, pick a different thing, an unrelated, don't

do that same thing again, pick an unrelated thing, and you just do that for years.

Okay, fair enough.

And finally, what about non-work stuff?

Do you have any passion projects, anything you're working on, anything you're building,

any things you're doing, any orgs you volunteer for?

Yeah, I have way too many.

That you'd like to share?

You want to pick a favorite one?

I'm an independent filmmaker, so I do film production here in Phoenix, mostly we've done

short films, I've worked on some features as crew, and we're trying to get our own feature

off the ground.

So that's something that we do quite a lot that's totally unrelated to software.

And then I also love engineering in general, so I tend to do a lot of product development

kind of like inventory kinds of things, I guess adventure is the best term for this.

It's like, I see a problem, I could fix that, or I think I can fix that, and so I'm in Autodesk

Fusion 360 modeling something, doing test print, I do tons of 3D printing, I have a

workshop and-

Maker stuff.

Maker stuff, yeah.

But it's usually towards the end of making something that can be a product or can be

useful.

Some things are one-offs, but we built a catio at our old house for our test to go outside,

and it's typical wood frame, nail it or screw it together, and staple chicken wire around

the outside.

And there are all these things that didn't work great if the cat throws up inside, you

have to pry it off and clean it up and you can't reconfigure it once you've made it.

So I thought, oh, I'll make a modular version of that with 3D printed connectors and standard

lengths, and now you can make it any size and configuration, and that's been two years

now of 15 iterations of the connector because it's always not quite good enough or not quite

strong enough, and now I have a version outside that my cats use that's gone through an Arizona

summer to test the material property, how's it going to hold up over one year being outside

in the sun?

Things like that.

So I spent a lot of time on film and these kind of inventory things in addition to software.

Do they feel like two different types, when you're doing two different types of engineering,

does it excite you in the same way, or do they feel like two completely different things?

They're definitely different for me.

The tactileness, so the thing that I love about the more physical mechanical engineering

side is that it's so immediate.

I can have an idea, whip up a sketch, design, print it, and that might take like four or

five hours, but at some point I'm going to be able to fit two things together, and oops,

my tolerances are off, or I didn't account for this, and I go back and I do another revision.

But I'm seeing things that are physical and tactile that I can try out and see how they

work together very quickly.

With software, it's sort of like none of it works for a very long time, and then it finally

comes together, and now it all works together because you have all the pieces that you need.

Up until that point, it's difficult to know how close you are in many cases.

Some things you can be more certain of than others, but you kind of have to, in many cases,

like the back and the front end have to come together in a certain way, and that's a point

where you're not quite sure if you missed a detail, you now have this integration problem

where you have to put these things together and you're going to have to go back and do

work in one side or both.

I feel like I have more firm footing in the physical world because the constraints are

so much worse.

In software, Fred Brix said this, he said that we make things out of thought stuff like

clouds, and we just kind of will it into being and make it into whatever shape we want.

That's beautiful and wonderful and true to a degree, and the downside is that there's

no rules, basically.

You're inventing your own physics system for your world and having to worry about all these

issues, whereas in the physical world, since so much more is constrained by physics, which

is often the thing that we're fighting against, like, oh, darn, it'd be nice if it was light

and strong and cheap and 15 other criteria, and it's like, well, no material does all

those things, so, you know, plenty.

We're fighting against the physical world.

The energy didn't have heat.

Exactly.

There's no loss.

There's no entropy.

The physical world is our constraint that we're fighting against, trying to improve

our solution against, and also a thing that keeps our solutions grounded in a way that

I think I suffer from this, and I would assume other people suffer from this, is that it

can be so abstract in your head that you're kind of just like keeping this cathedral in

your head, and when you can't hold all those pieces together, it can kind of all fall apart

and you just don't understand how all these things work together, where in a physical

system, usually you can lift the lid and kind of peek inside and have a pretty okay sense

of what's going on, and there's a, I don't know, there's a nice warm feeling that comes

as a result of that.

I can see that.

Okay.

Well, thank you so much for your time today.

I really appreciate it, David.

Thank you.

Thanks for having me.

Thank you.