Episode 2

Engineering service through software

"As a Software Engineer, customer service is making the right engineering decisions that put your product in a positive light for the end user, making whatever compromises that are possible to make the best experience you can for the customer..." Read More

Featuring: Alex Dennis
Sponsor: Twist


Host:: Omar Samuels
October 1, 2018




Host:
Alright, welcome to this episode of The Serve! Show podcast, brand new. Today we're going to be talking to, well, his real name is Carlton Alex Dennis, but I've known him for many years. And I just call him Alex. We've been friends for a while. Now. How long has it been? Alex?
 
Alex:
I would say maybe 15 years? Somewhere around that
 
Host:
Around that, wow. Well, Alex is here because, you know, we're talking about customer service. And he is a software developer. In many ways, he fits the mold, and in many other ways, he doesn't fit the mold. At the end of the episode, we're going to be sharing Alex's social media details, you could probably follow him on Twitter. And if you already do, you will know that he's maybe a little bit of a philosopher in-waiting. So I'm pretty sure we're in for some interesting insight. But let's just get right into it. Alex has been doing software development for a long time. He's worked at places such as Lexis Nexis, which some of you may know.  Right now, he's an Amazon developer, but his views today are his own. He's not speaking as a spokesperson, or anything like that. So... welcome, Alex.
 
Alex:
Glad to be here.
 
Host:
Alright, so like I'm going to do with all my guests, I want to just jump right in and make the first thing I want to ask, to set the mood, to give us your perspective... I want to know, what is customer service to you? How do you see it?
 
Alex:
Customer service, I mean, for me, from the point of view of a software engineer... and there's lots of ways you can think about customer service, but from a software engineer standpoint, I kind of see customer service as, making the right engineering decisions that would put your product in a positive light for the end user. So making whatever compromises that are possible but make it the best experience you can.
 
Host:
Okay. So it's sort of bringing into it already, the whole product aspect, which I've recently realized... how important that is to the end product. It's, it's not just the software people, but product development seems to lean heavily on everybody - the designers, the marketers, the support representatives, everybody. So that's an interesting take on it. And your particular perspective would be strongly as a software developer. How long have you been doing software development?
 
Alex:
I think professionally... I've been doing software development for roughly 14 years now, for me.. or 13.
 
Host:
Are you sure? Because for as long as I've known you, you've been doing software development.
 
Alex:
Yeah, I mean, if you're talking about pre-college days, I mean, I, I've always done software development on the side doing websites. And yes, when I was in high school, if you add all that time, then it's probably closer to two decades, almost 20 years. Yeah, actually.
 
Host:
How did you get into it? Would you say it's something that maybe you sort of felt drawn to? Or did you like, just get defaulted into you know, a situation where you were at high school, you ended up doing computer classes, you liked it, and then one thing led to another? Or did you feel some personal call towards software development?
 
Alex:
I think it's basically just luck, luck of the draw or happenstance, because my father was working on a PhD in a school that required everybody to have a laptop. So from a very, you know, before everybody else knew what the Internet was, my father, had to use the Internet and we had to have a computer for him to work on his dissertations. So, because of that, I got introduced to computers from a very early age, and I think that's, that's sort of is the genesis of it.
 
Host:
Okay, so you've been at this a while and you've been sticking with it. So you've seen all kinds of changes that the software industry development industry has gone through. I myself, I've been at this for a while too. I've been, you know, coming from the BBS and the dial-up modem days, and starting out, maybe with Assembly and Pascal and Basic, and there's something that I've been looking at.  Even from back then there was this notion that programmers are not people person, they lack interpersonal skills, they don't have good social skills, or the ability to interpret what user needs are, you know, they're just nerds that you stick in a room and slide pizza under the door. That is the kind of the way that people have seen programmers is over the years. Have you seen a change at all in that? How people see programmers or software developers in today's world?
 
Alex:
Yeah, I think it's changed quite a bit. I mean, I remember when I was in high school, and I would save my lunch money to buy, you know, computer magazines, and programming magazines, and people just looked at me and say, "Nerd!", like "What are you doing?" These days, now, I would run into someone and say, I'm a software engineer, and then all of a sudden, they're like, "Oh, that's really interesting". I have people coming to me and asking me,"How do I do that? How do I become a software engineer?" So there seems to be, a growing recognition that it's a valid job,even sought after.
 
Host:
Do you think it's maybe the change, to the word "engineer", that could be making a difference, where people have always sort of respected the engineer as opposed to the software developer? Do you think that plays a role at all, where "Engineer" is now being accepted as describing what you do?
 
Alex:
I think it's less about the the wording and more to do with the fact that computing has become more and more important in everyday life. Things like the iPhone, things like smartphones are now coming to the point where they're front and center, social media front and center. And not only, you know, the minute entertainment sector, but there's also public sector, with politics. And, you know, it's a huge part of today's culture. So I think people are just kind of recognizing that it's an important part of every day life.
 
Host:
You can't escape it. We were just talking because you just took a Lyft, and we were talking about, that it was so good. You said it was so good to be in the in the car, listening to classical music. And I was joking that you could have just fallen asleep, which you know, where we're going now, with autonomous vehicles, that could be really where we go with smart car. You jump in a car, you fall asleep, you reach home, it beeps and wakes you up. But one of the things now is when you have software developers... because the smart cars are operating on machine learning, maybe A.I., there is a, let's say, a team of software developers somewhere in that chain. And so they have a responsibility now to determine how that piece of tech relates to the real world and deals with people, which in essence, is customer service. So do you think that there is a heavier weight of responsibility on software developers these days than it was in the past?
 
Alex:
Yeah, I think that's definitely being recognized. In everywhere that I've worked. Especially since you have people who are setting setting standards, like you know, Apple's famously been very very strong on design and other companies are trying to get in. Google's trying to get strong on design.  So people are getting used to very good experiences in their personal life and they want that at work. They want it everywhere!  They want it in all their apps, they want that fluid interface. And because the affordances that we have in some of our old technology have been so well-modeled some people say, "Why use an app?" or "Why use computers?" when they can do things the old way, because they're so used to it. It's gone through a long history of refinement that certain others... like say... just calling a cab.  Going out there, hailing a cab and the cab looks the same all the time. And this is like a certain protocol and easy. Yeah, and so the question is, how do we make digital, all these new systems as easy as the old systems and at higher scale? And I think that that's why the human in the humanities is a huge part in where technology goes.
 
Host:
I agree with that.  You mentioned the old ways. And one of the other changes that I I've noticed over the years is when I did software engineering, one of the things that the lecturer and the teachers and everybody would harp about is that it's very important, when you become a software developer or programmer to make sure that you have excellent documentation. And I remember back in the days when you bought software, you had to get a manual.  These days, if you buy something...  I couldn't tell the last time I got a manual. You might get like a quick start guide. But nobody really gives a manual. You could probably go online and download a PDF. So it's like user experience and intuitiveness is front and center. And it seems like humanities, that whole industry of human psychology and computer interaction... human computer interaction is a bigger deal. Now, do you think software developers are sorta having to become more rounded? So they have to become psychologists, they have to be sort of have their feet dangling in the whole user experience, expertise and design areas? Do you think software developers are mandated then to be more more rounded techies?
 
Alex:
I mean, I think there's a place for it. I think there's a certain product discipline that software engineers need to know about. There's a a great book called "Don't make me think" by Steve Krug, which talks about this whole idea of usability and that applications should be more or less intuitive. And it talked a lot about how you build applications that are like this. And I feel like all software engineers should have some base understanding. But I also think that this is hard. This is a really hard thing to do. And I feel like there are certain people... there's actually a new discipline that's evolving, called a UX Designer, which I feel like... is someone who should work along with software engineers, not that a software engineer shouldn't know this stuff. But just to say, that more attention DOES need to be to be put into building good experiences.

Affiliate link: Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) (Voices That Matter)
 
Host:
Okay, you touched on something interesting there that I'm going to ask you about. Let's dive into roles a little bit. You mentioned the, the UX Designer. So we have UX designers, we have Designers, we have software people... do you think the software developer role is now more of an overarching role, and then "What kind of Software Developer are you?"is becoming a real thing?
 
Alex:
There's definitely that. That's definitely happening. I mean, you hear it. If you take a parallel in the old world, you have mechanical engineers, electrical engineers, you have all these different types of engineers. This is happening in software. I mean, you have Machine Learning Engineers, you have, you know, Distributed Computing Engineers that are doing things at scale. You have... Front-end Engineers is now a thing that's really, really coming around, because everyone's realizing that there's, there's more to it than just programming, there's some amount of understanding the constraints, understanding what you can do within those constraints. And so it really becomes a discipline.
 
Host:
There's a book that I read recently, I really enjoyed it, it's Deep Work by Cal Newport. And it really looks into being able to go deep in something that you need to learn, whatever it is that you need to accomplish. And I've been thinking a lot more about, especially us as techies, becoming masters of our world. Again, back in the day, when you were becoming a software developer or engineer, you kind of had to know a little bit of everything. And the technology was moving so fast that you had to just just learn what was on the surface and move on. But it seems these days, you really have to pick maybe a few areas that are related, and go real deep with it, so that you can have a better contribution... you can be master of your area. So these days, where you need a backend engineer, you need a backend engineer who understands everything. And so that's kind of what I'm wondering, when you say, software developers these days, it's not what it used to be back in the day, software developers seem to have to be more mindful of all the facets of what it takes to produce a "Product". And when you look at things, for example, the smartest assistants... when you say, "Hey, Google", or "Alexa...", or whatever the trigger word is to wake up the smart assistant... from that moment on, as an end user, you don't really think about what happens behind it... unless you hit a bad experience. But for it to be a good experience, it takes everyone.  It takes a Front-end Engineer and a Back-end Engineer, the persons doing the translations, because everything has to be localized nowadays, with our global village.  Do you in your, maybe your regular work and projects over the years... Do you find that you've been forced to go deeper? And maybe, I don't know, let go of some of the things and just say "I'm just not gonna be able to be an expert in everything"? Is that something you've seen going?

Affiliate link: Deep Work: Rules for Focused Success in a Distracted World
 
Alex:
Oh, yeah, definitely. That's become more and more of a thing. What I do, though, I do feel like as an engineer, it's good to go broad and deep. That's particularly my, my personal strategy.
 
Host:
 How does that work?, I mean, you're a dad, you're a family, man, you've got things going on. That sounds impossible.
 
Alex:
So one of the things that's very interesting about engineering or computer engineering, software engineering, in general, is the proliferation of content online. This is kind of how I taught myself how to engineer I think, maybe, in some ways, because in the very early days of the Internet, it was that people who were building the Internet, were putting things on the internet, and they talked about what they knew. So there was plenty of information about how to build a website, kind of where I got started. So I kind of feel like, you know, every new technology comes out, it's sort of... I think it makes sense to go and investigate it, you know, spend maybe a weekend doing a tutorial, because there are plenty... and then just get, like a working understanding of what that technology is, but then also know within yourself, when to just stop pursuing a particular thing, but just to know it exists. Oftentimes, knowing that it exists, will come back around to help you when you have to engineer a solution with people who are working in those domains.
 
Host:
That makes sense, that makes a lot of sense. I want to pick up on that... when you have to, you know, work with other people working on other things, related things. We're gonna take a quick break, when we get back, we're gonna we're gonna pick it up right there and talk a little bit more about that. We'll be right back after giving our readers an opportunity to support us by checking out this little Advertisement...
 
 
Host:
We're back. We're still talking to Alex, software developer extraordinaire. We're looking at software development and the software developer role holistically. And kind of trying to see a broader picture of what it is and how it impacts on customer service, consumers, the end user who uses it, people who enjoy it in their daily lives.  We want to talk a little bit about, about roles, about the different roles that the software engineer plays, and how he interacts with other people. Where I want to start is... there's a show, it's one of my favorite shows, it's called "Office Space", I'm sure you've watched it.  I'm gonna let us listen to a little clip, and then we'll discuss a little bit.  Just to set it up, it's a software development company, and they're going through some, let's say, "restructuring". So they brought in consultants to start to evaluate everybody's roles, and you know, your purpose at the company, and there's this one guy... well I'm gonna let you hear what happened...
 
Clip - Consultants 
What you do at Initech, is you take the specifications from the customers, and you bring them down to the software engineers?
 
Clip - Product Manager   
Yes, yes, that's, that's right.
 
Clip - Consultants
Well, and I just have to ask, why couldn't the customers just take them directly to the software people?
 
Clip - Product Manager   
Well, I'll tell you why... Because engineers are not good at dealing with customers.
 
Clip - Consultants 
So you physically take the specs from the customer?
 
Clip - Product Manager   
Well... no.  My secretary does that, or they're faxed
 
Clip - Consultants 
So then you must physically bring him to the software people?
 
Clip - Product Manager   
Well, no. Yeah, I mean, sometimes
 
Clip - Consultants 
What... what would you say... you do here?
 
Clip - Product Manager   
Well look... I already told you, I deal with the g******n customer. So the engineers don't have to, I have people skills, I am good at dealing with people! Can't you understand that? What the hell is wrong with you people!?!?

Affiliate link: Office Space
 
Host:
That's a scene from one of my favorite shows.  Now,as funny as it is, um, it's not fiction.  I've worked in enough development houses to know that this is a real thing. it's becoming, I think, less so now. But people, as you talked about, before, had programmers...  the interpretation there, the way they saw them was that they just... you just got to spit out technical code to them... what exactly you want, and they just spit something back out at you. You had to have this intermediary who would humanize what they do. But it seems, um, that's not the case anymore. I'm not sure what exactly to attribute that to, if it's that the technology is just gone too deep. But the roles HAVE changed.  You are now dealing as a software developer with... you have to work off specs, you got to work with the product team, you have to work with the designers, you have to work with the translators, even the customer representatives, who often times are the biggest voices and representatives of your customers inside the company... you have to listen to them, because they are in the trenches, they know exactly what customers experience a lot of times.  What would you attribute this change to? Why are we now having situations where, the software developer has to be more sensitive to the customer service needs? What do you think is causing that?
 
Alex:
The success of software.
 
Host:
The success of software?
 
Alex:
Yeah, because I think I think in the earlier days, when software just started out, it was very esoteric. It's being used in labs being used in government, it's being used for high science things. Then, when we got on the Internet, the only people who would, who found it, were people who are loners are in the corner, and they were just, you know... btw this is this is all speculation. I don't have any data to support this, but in the early days, you could do so much on your own to get an MVP (or Minimum Viable Product), something just out there. Yeah, without talking to anybody. So those skills just, weren't stuff engineers necessarily needed to develop.
 
Host:
Hmm. Okay. So the picture you painted was that in the early days of the Internet, which I can relate to, there weren't all these browsers that you could just hop on and browse to a site, it was about lurking in IRC channels, and finding, all these different little gatherings and your little, your little tribes of people who like what you like, and that sort of thing. So maybe a lot of these persons were like myself, people who were very curious, in my own small corner. And so I probably didn't talk to people a whole lot. And so I was able to think, oh, this is what your need is, until I could interpret it into software back in the day.  And what I've seen, I could be wrong. But it seems to me that the particularly successful techies, the ones who kind of have the tech skills, but as well as some of those soft skills.  Some of the rockstar techies who made it... a lot of them have been able to interpret what was coming, what the needs of people are, and then sort of build something to meet that need. And some of them have really been able to I guess run ahead of the curve and so "head it off at the pass" so to speak, and by doing that they've just, you know, hit pay-dirt... and maybe some people have just gotten lucky.
 
Alex:
Well, I mean, this is a really complex thing to unpack. One thing you said there, I think that was particularly important where, maybe these engineers didn't know how to talk to people necessarily, because it wasn't a required skill for them. But you did touch on an important point where they talked to  each other very effectively... but then that creates a subculture, which, you know, isn't mainstream,  So that's One.  Two: there're lots of problems that you can solve without necessarily talking to the rest of society. I actually feel like things like Google, things like Facebook were things that you could build them and scale them, without necessarily having a lot of input from the rest of the world. But now we've come to a point where, because things are becoming so important, and things are getting more nuanced in terms of their applications. Who that now we require a much stronger relationship between those who are building this stuff, and the people who they're serving,
 
Host:
This is deep, this is deep. Wait, let me unpack that. So, you could basically build any platform to a point, but once it grows and takes on this life where it becomes adopted by society, almost, you start to impact enough people who are not like you, who are outside of the, you know, the techie circles, or, you know, these unique esoteric kind of groupings, and then you have to start thinking outside of your own box. And now that, as you say, with the success of software, and it gets taken general technology has really grown, it's like ushering in a new day where you can't just sit down and have a platform go from zero to super hero without contemplating the impact on society. And, you know, especially with what we're talking about, the customer service angle of it... when Facebook maybe gets some kind of backlash or criticism about some kind of privacy issue, it really is a customer service issue as well, because the customer for Facebook maybe doesn't want things this way, they don't want their data gathered, they don't want you to share this, they don't want you to sell this. And of course, you know, everybody has those problems. It's a tightrope between collecting data and analyzing it, and sharing it and selling it. And people really feel strongly about those sort of things. So what I'm seeing is like, it's technology maturing in such a way, and we have the sort of platform infrastructure, everything now, where you can't go it alone as a techie.  You have to consider how does it impact the end user? How does it impact users... people.  Now "users" even feels like a misplaced word when you talk about some of these things. It's just people. Especially when you're talking about things like self-driving cars.  I mean, the truth is, you get in a car, you are a "user", but it's, it's closer to being people. And once you start dealing with people, you kind of have to think "people first". I'd love to hear some more comments from our listeners on what they think about that.
 
Host:
But let's stick a pin right there. And let's talk a little bit more about people. You've been a software developer for a while now. And you've been at it so long that you're kind of senior and over your career, you've been a team lead, and a manager, which is kind of almost inevitable in today's world, where you move from, a senior developer to managing a team.  The first thing I want to ask you is, what advice would you have for new, maybe even struggling developers who found themselves turned into managers, and they have to manage people? They have to basically not sacrifice internal customer service levels, which is dealing with, you know, people on your own team, because Customer service is not just inside out or outside in, it's also within the company within your own teams. How can they maintain productivity, as leaders, as managers, without sacrificing the all important customer service that they give intra-team and inter-team?
 
Alex:
There are lots of ways to think about that. Because, say, for instance, if you're, an engineer, you become, team lead, probably because you're doing the right things for the customer... And so you have very good knowledge of the product... and now you've transitioned to manager. So you already have a high bar on quality. So then now the question is, how do you  keep that quality high when now it's really primarily not you who are supposed to be writing the code, but other people? There're a lot of people who say, "Well, you're a manager, but you're an engineer. So maybe you could still write code." I have tried this. I've written code as a manager, I've written a lot of code as a manager, until at some point, I realized that it wasn't really serving the company best
 
Host:
Why is that? Is it that you have to pick one?
 
Alex:
Mostly because there's only so much that my mind can actually take at once. I think there's different mental processes, with programming, versus when you're coordinating across multiple programmers. It's a different type of skill set. And so I think that if you are constantly trying to be the programmer, you could drop the ball on inspiring the rest of the team to do work.
 
Host:
Would you say that maybe one of the main goals of a team lead is to inspire?
 
Alex:
Well, when I say inspire I mean, not really inspire as much as to bolster, more as in to give them the support that they need. So when I think about in terms of going from an engineer to a manager, and what I realized eventually, is that my role was to actually be the manager that I wanted. That is, when I had managers who didn't understand anything about the code. And they set these ridiculous deadline, or they didn't give the support, they didn't feel like we should go to conferences, or we didn't want to give us time to do learning, be curious, like, just some time to just go and, test out new ideas that will be useful for the business. Someone who's an engineer knows how important that is, to engineers.
 
Host:
You're just describing that scenario for me and I'm already feeling stressed out.  It's like, this is expected of you, but you don't have the manager who understands what you need in your role and as a person to grow and to develop. And it sounds to me like, what you're talking about is trust, maybe? Learning how to trust your team and have your team trust you?
 
Alex:
Well, a lot of it, what it is, is giving them the opportunity to be their best. So if you're writing code, you're now writing code that someone else could have written and learnt something from. You've now solved the problem that someone else could have solved and really understood it. Because... one things I've learned in software engineering, is that you learn a lot more when you do it yourself.  Sometimes you can do it yourself and you fail, and then someone explains to you how you failed. You learn a lot more than if you never failed in the first place.
 
Host:
Ooh, I like that. And I also... I've noticed a trend where failure...  it's a paradox... failure is becoming something that's (it sounds bad) a little bit more acceptable than back in the day. And I say, it's a paradox, because I'm thinking about how much more dependent we are on technology. And I'm thinking "You can't fail!" You don't want a self-driving car to fail, ever! We were talking about this earlier, and you were saying, statistically, it must happen, it's gonna happen. But what's important is how we deal with that, maybe that first event, but it's hard. How do you put that message out there? Let's say, from a customer service standpoint, I want to use your self driving car, but you're going to say to me, "You know, statistically, one of you must die someday". That doesn't seem like great customer service. How do we approach that in this in this new day, this new age that we're living in?
 
Alex:
One of the things I think that's interesting about software engineering these days, is that we're beginning to sort of get a stronger understanding about how to actually architect good software. So certain patterns are now repeating, to the point where they're kind of solid.  in the early days, it wasn't quite clear what you needed to do. And so you need to have this iterative sort of mentality, because you need to try a lot of things in order to get things right. Now that we've gotten to the point where we have a better understanding of what does work well, you could argue that now it's time to step back and actually try and  do what other engineering disciplines do, which is to have stronger requirements, and stronger upfront quality measurements. But then once you do that, you're going to slow down.  There's a trade off between, you know, how fast you want to go, and how much quality you want to have. And I think that's a problem every industry faces.
 
Host:
Is it just something that comes with maturity, where you just have to be responsible? Because if you even look at Facebook, they started out with the, I guess you could say, the mantra of just move fast and break things. And there came a point where they realized, as we were saying, before, it's no longer, some group of techies enjoying this thing, it as a company, it has to be more responsible. And so that couldn't work anymore. So maybe it's just a matter of realizing as your impact on the world gets bigger, you have to step up your level of customer service, thinking about people thinking about how you impact them. And I guess as inevitably things go wrong, as you said, How do you make it right, when it goes wrong? You have to think about that as well.
 
Alex:
Yeah, I think that's hard. That's definitely an important thing. I haven't read enough on this about what do you do when your service goes out, and it affects a billion people. I mean, we're talking about, you know, the sort of scale of some of the systems that we have today is so huge.  It's sort of unprecedented in terms of its scope. And then you almost want to say, well, we need better regulation, or there needs to be sort of third-party verification groups. But then there's a whole set of politics that comes with that. I think that most often, software engineer people want to get away from that. Worse, you don't want people policing you who don't know anything about technology, and as you said, it slows the whole thing down.
 
Host:
But as you said, everything's kind of a balance and the industry is changing all the time. And we just hope that it changes in the right direction.  And I guess the last thing I want to kind of talk about that is on my mind is that I've also noticed that, um, you know, as people get more senior in their career as software developers, software engineers... it's almost like, as that whole field matures, they're now realizing that not everyone is cut out to be a manager, not everybody can do that kind of people management. And even though you're a great developer, you've been doing this for years, there really are more like two tracks. One is the Leadership Track where you want to be that senior developer and you're like a black belt in all things, whatever you specialize in, and you're not really managing people, you're just leading the industry, you're making waves, you're setting the specs, you're blazing the trail. And the other side is managing people. And for people managing people, they inspire them, they maybe stop writing code, they don't review Pull Requests or anything like that, but they inspire people to to be their best selves, as you say.  But either way you take it, I think there is that responsibility to people in both tracks.  In your own sojourn. Do you think that that's a good way? Do you think that these are the two paths? Do you see a third path? Or do you think we need to converge again, because maybe everybody has the capacity to inspire others?
 
Alex:
I mean, this is one of those psychological puzzles out there in terms of why are some people good at some things versus other things? Different people have posited different things about this. And now I'm stepping out of my expertise here, but I kind of agree with this sense that... I can't remember who came up with this idea, but they posited that if you could live long enough, you could learn to be everything. I think there is some merit to that it's really more a matter of where your motivation lies. If you're motivated enough, you can change your brain. I believe, with enough data points given to it that you could completely change or in a large way, change the way that you you operate. But that being said, I do think that, you know, right now, there's emerging a non-managerial path of leadership, which is more of like a thought leader. That's more of like, you know, the person who can design systems across organizations... and I think that because software has been so successful. And because now it's been gaining global reach, we have these particular companies and systems that are big enough that they do require someone who's an engineer at a higher level... an engineer who can work with more junior engineers, or, you know, intermediate engineers, and collaborate with them. And those people tend to, probably, really more produce specs, but they can take all the things that they've learned when they're building smaller components, to think about building larger components that are going to have sub-components built by other people.
 
Host:
Have you been involved in the specs building process? Have you ever worked along with someone, or even had to roll specs out yourself?
 
Alex:
I have.
 
Host:
When you're putting that together, like, you know, the draft or the final specs, how much forethought is given to it so that you think about the end user? Is it a little or a lot at that time when you're writing specs?
 
Alex:
So this is where it gets interesting, right. Because as you know, in terms of specializations, there's another particularly important role that has emerged and that is the Product Manager.  This is the person who would be that guy that talks to the customer and can speak in "customer terms", and should be a super user.  They should really know how to use the product inside-out.  It's an advanced users should know they should be able to talk to new people. They know exactly what the struggles are for new people, they are the people who collect all the user data in their mind. And those people should be able to then disstill to the engineer, you know, these are the requirements. And then the engineer says, "Okay, these are the requirements, I'm going to build a system that fits the requirements". Now, often what happens though, especially when you're starting a new product, which there is no data, there's very little customer data... you're going off of speculation as to what you think the customer wants.  Maybe that visionary knows something about that space, because they worked in that space.  Maybe they were a travel agent before, and now they're working on a travel product. But what often happens, though, and I think this is where the engineer does have some responsibility, is that I think oftentimes the customer experience, degrades to what the software engineer decides is most important, especially when you have time pressures. If you know, that you have the UX designers, and they say, this should be the experience, and your designers, say that this is the color scheme... and you have product managers that say, this is what's most important to the customer... and the engineer comes around and says, "Okay, this is the time you want me to get this done? This is the compromise that, I'm gonna make".  So then the engineer ends up deciding that customer experience.
 
Host:
What's interesting is that a year from now, when the customer complains about something, and then you go and say, "Why is this like that?", and somebody says: "Oh, it's because... ... I don't know why". And then when you check the history, it's just that there was what was essentially a sprint of some sort. And that was just the time we had to do it. And it impacts the customer. But it was never intended to be a long term thing, it was a decision that snowballed, sometimes out of control. So I'm wondering if in the future, we're going to start seeing roles (I've seen different terms floated around, like, support heroes) and people within the team structure and organization and a company whose job it is to follow these things up. Because oftentimes, as you said, developers are working under pressure and they don't have time often to stop and say, "Okay, let's clean up code debt", or to go back and say "We did this and there's like a 'TODO:' in the code as a comment and everything, how are we going to fix this next time on the next cycle?".  It just never happens. Do you see where maybe we're looking at a role where Customer service is going to start taking on some additional roles that will cauterize this sort of thing?
 
Alex:
I think it's already happening. I mean, you see certain companies have a role called a Site Reliability Engineer, where their stated purpose is to make sure that the system runs well. They're not doing new features, necessarily.  What they're doing is watching the metrics, and they're seeing what customers are doing and their optimizing the system so that the users have the best experience, making sure availability is up, making sure things are fast.  Now, you could take the same realm (to software development) in terms of making sure features are refined, like you could take that one step further and say, you know, is there a role for someone who's going to refine features separately and apart from the engineer who's doing the Greenfield work.
 
Host:
That's what I'm talking about. Because right now, it seems like what you described is more of a Back-end Engineer kind of role. And they're looking at crash logs, and looking at what sort of things are happening, but they're still on the back-end and, and fixing it from the back-end without much connection to the customer. And I feel like as, you know, the whole industry and the whole role develops, we're going to start seeing more... I don't even know what the role is going to be, but some roles that are dedicated to connecting those dots in-between... and not in a way that we just saw in Office Space, but it's going to be more respected, it's going to be a respected position where people start realizing that these platforms that we're dealing with now, it's not just all fun and games... it's peoples' lives. And so it's very important to kind of sort out what the customer wants and how this can really badly impacts someone. So I'm looking forward to that day. Looking forward to that day.
 
Alex:
I'm sure many people are.
 
Host:
Yes, indeed. This has been a great talk. Thank you so much, Alex, for, coming to sit down with us, this is an exciting time, and I feel like we've only scratched the surface. I'm pretty sure we're going to have a part two with you at some point.  For users who are going to be listening to this podcast, I want to allow them to be able to continue to follow up with you. What's the best place to keep in touch with you? Whatis your watering hole online, so to speak?
 
Alex:
Yeah, so this is interesting. I I tend to post quite a bit on Facebook, but I keep that kind of private. But I also have a Twitter: @Alex_Dennis so I mainly post there and I also, every now and again, post on Medium also @Alex_Dennis.
 
Host:
Yeah, I've seen some of your long form articles. They're really thought provoking.  Listeners, please be sure to check it out. So once again, this has been a  Serve! podcast episode. We've been talking to Alex Dennis, philosopher in-waiting and software developer extraordinaire. Please tune into our next episode, like us, follow us, share us. We have some awesome things in store for you. Thank you again for listening. And until the next time, serve!

SHARE

Listen to this episode and share it with someone who would love to learn and be inspired today.