Contact

The Rabbit Hole Podcast

Welcome to The Rabbit Hole, the definitive developers podcast. If you are a software developer or technology leader looking to stay on top of the latest news in the software development world, or just want to learn actionable tactics to improve your day-to-day job performance, this podcast is for you.

rabbit-hole-with-tail.jpg

87. Developer vs Engineer

On today’s show we discuss whether we can call developers engineers! For a long time, the term software engineer has been thrown around but there has also been some debate about its accuracy and whether it is appropriate to use these titles so interchangeably. We look at some of the initial differences between certified engineers and the wide range of developers and then address responsibility and the seriousness of consequences in different fields. The discussion also covers how programmers might be able to be called engineers more accurately but in the end we seem to agree that the simplest solution is to do away with the term engineer when it comes to software. For all this and much be sure to tune in!

Key Points From This Episode:

  • An introduction to the debate of the differences.
  • A question of life and death and what are the consequences.
  • Who is responsible in the case of a hack or failure?
  • The actual ramifications of bad coding and badly coded websites.
  • How much specialized knowledge do developers actually need?
  • The ongoing debate and the responsibility we all have to bear.
  • And much more!

Transcript for Episode 87. Developer vs Engineer

[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today.

[0:00:09.8] DA: Dave Anderson.

[0:00:10.8] MN: Our producer.

[0:00:12.0] WJ: William Jeffries.

[0:00:13.9] MN: We have a question I’d like to solve. It is, are all software developer’s engineers? I think in the industry right now, we use software engineer as a title that get’s to use but there are some people who are upset at the fact that we call ourselves software engineers.

[0:00:31.4] WJ: It’s a lie.

[0:00:32.1] MN: Is it really? We’re building stuff,

[0:00:37.1] DA: You’re all just coders. It’s all coding.

[0:00:39.0] MN: Just coding, computer programmers, yeah, that’s what you really are, that’s the thing,

[0:00:46.0] DA: Barely. Trash talking.

[0:00:48.7] WJ: There are engineers who actually go through certification processes and have to sign off on the work that they do. You know, if you go to build a bridge, you have to sign the engineer who comes up with the design for the bridge has to sign off that it is structurally sound and they’re consequences too making mistakes there. When I write shitty code and ship it, there is no consequences for me at all.

[0:01:13.4] DA: You just roll back.

[0:01:16.3] MN: Just roll it back, come on, it’s not like a bridge, you can’t roll a bridge back but I do imagine that – I mean, there are certifications that can exist for certain software fields. I mean, some people look at certificates from like code schools or like your degree as like hey, you know a thing or two but it’s not to the level of that of an engineer as William mentioned where you build a bridge, you got to make sure it doesn’t topple over.

[0:01:43.5] WJ: Yeah, your nano degree is not the same thing, nobody –

[0:01:47.4] DA: Nano degree, stop trash talking.

[0:01:51.4] MN: Nano degree.

[0:01:52.5] DA: I paid $90 for that. Yeah, it’s a pretty lively debate, there’s an article on the Atlantic a couple of years ago. That was really digging into this and Atlantic fashion where it was, dozens of pages long and just railing about you know, engineers and how they’re kind of ruining everything and since then, we kind of have ruined a lot of things. There’s still a lot of things that are broken.

[0:02:22.5] MN: I mean, I think yeah.

[0:02:23.8] WJ: Engineers are terrible.

[0:02:25.6] MN: Wait, what? Software engineers are terrible?

[0:02:27.8] WJ: Yeah, I just did it.

[0:02:29.6] MN: You just do it.

[0:02:30.1] WJ: Calling programmers software engineers.

[0:02:33.9] MN: There you go. Software engineers are terrible, is that what you were saying William?

[0:02:37.9] WJ: I think I’m a software engineer, I think that I’m great. You guys are great.

[0:02:43.2] MN: Yeah, of course. You know, we got test driven development, we have a process that we use to ensure that our work doesn’t fail us.

[0:02:52.9] DA: Yeah, but it’s interesting because like, the infrastructure that we rely on that we’re using to get stuff done every day like GitHub and the internet is kind of brittle still. I mean, this is kind of a larger like security related question but like.

[0:03:10.7] WJ: Hired paid action?

[0:03:12.8]DA: Yeah, hired paid or something more lifeless, subtle and more dramatic like when GitHub went down, was it like last year? I mean, it has superior colleges but there was that time when it just got DVOS by all of these like bot netted, IOT devices.

[0:03:32.1] MN: Devices, yeah.

[0:03:33.3] DA: Which was just completely wild.

[0:03:35.5] WJ: I mean, AWS went down. I remember that was a big deal.

[0:03:39.4] DA: Yeah. We were working together at time, we’re trying to look at the status page for S3 and it’s just green because the red light was an S3.

[0:03:55.9] MN: That’s great.

[0:03:57.3] DA: That was traced back to like programmer error, right?

[0:04:00.7] WJ: Yeah, were there any consequences for that guy? Definitely not. Well, actually, I have no idea.

[0:04:06.4] MN: I mean, it depends on all the –

[0:04:07.8] WJ: Now I feel bad, if he lost his job, I feel terrible. That could have happened to any of us, I could have easily made that mistake.

[0:04:13.2] DA: Yeah, I kind of googled that right now, whatever happened to S3 guy?

[0:04:17.8] MN: The S3 guy, that’s his name.

[0:04:19.6] WJ: That should be a meme.

[0:04:20.4] MN: That’s the guy, S3. Going back to that article as you mentioned before, it notes that things like this is catastrophic but there are no repercussions for these kinds of issues that occur, is that correct?

[0:04:34.5] DA: Yeah, I guess in general, it seems like these issues don’t have any immediate ramifications like maybe there’s like loss of time and productivity and frustration. So far, we’ve been pretty lucky.

[0:04:50.8] MN: People can’t sue. Let’s say for example, let’s go back to the AWS. Let’s say many different startups use AWS, when sure that their product is running fine. They sell t-shirts and use AWS.

AWS goes down, right? They lose money and they lose revenue, they can’t sue AWS for this thing that cost them X amount of dollars because you're using their product and I’m pretty sure it’s in the terms of service that you can sue them if it’s down for whatever reason.

If a bridge, if I’m transporting goods and the bridge doesn’t exist or like -

[0:05:33.1] WJ: Or the bridge collapses while you’re on it.

[0:05:34.5] MN: Yeah, while you're on it then it’s like ramifications.

[0:05:37.8] DA: Common errors.

[0:05:40.0] MN: I imagine that there are ramifications for something like that, for the engineer who built that bridge and not for the engineer or the software developer I’m going to say who introduced this bug in AWS.

[0:05:54.6] DA: Right, yeah, there will be like some kind of a review, there will be like pretty deep questions, maybe even at the federal level like how did this horrible situation happen?

Even more recently, there was a bridge collapse in Italy and that was very tragic and you know, people are trying to figure out why this happened but that bridge was there for many years before it collapsed even. It was kind of doing its job up until it stopped.

[0:06:25.2] MN: Until it didn’t, yeah. I think like going back to what you had mentioned where it goes to like a review, suppose, okay, it’s a new day where engineers – software developers are now responsible for the work that they do similar to how we treat infrastructure engineers, people who built bridges.

 

[0:06:45.6] WJ: You talking about like in extreme cases where people are working on something that actually could kill someone, like if you’re working on some kind of med tech application or you’re writing software to runs people’s pace makers.

Are you just talking about like, some guy making a home page for some restaurant?

[0:07:05.9] MN: Let’s use the extreme because I guess the question that we would have to find out is what happens to a software developer who creates a pacemaker, who develops software for pacemakers and it messes up, right?

[0:07:21.1] DA: I think they do like pretty rigorous like traceability and documentation and risk analysis. Actually talked with some people at PyCon in Cleveland earlier this year about like Python in space. Have you read software to go to space and it actually sounds kind of boring because there’s a lot of risk management involved and you know, they really test it pretty rigorously.

[0:07:47.1] MN: Right, for software like that, I guess there is a lot of test in risk management and that goes into play that a bridge engineer would deem respectful to the name engineer. But William, as you mentioned, going to – for someone, say Bobby to build a website.

[0:08:07.0] WJ: Who cares?

[0:08:07.9] MN: Who cares, right?

[0:08:08.7] WJ: How big of a deal is it? Do you really need this guy to sign off? Do you really need that kind of assurance? Are you willing to pay extra for that kind of assurance and how much?

[0:08:19.4] DA: I think people want things pretty cheaply like the technology is pretty flexible and you can pretty easily, you know, flip a switch and you know, revert your restaurant website changes like you know, if you accidentally push the Chinese food restaurant on to the pizza restaurant website be like “Shoot, I got a backup.”

We have some practices like dev ops that help us with that.

[0:08:46.0] WJ: We want our code fast, we don’t want to wait around for you to figure out to make sure that it’s stable. I mean, they say that they do but then they’re like, “We need this by yesterday, cut corners.”

[0:08:57.2] MN: Make it happen. Well, what happens to, here’s an example, Facebook recently got hacked and a lot of people had their information, they had the account breach for example. I’m sure that’s happened many times at Facebook. What are the repercussions for that? Does Facebook get sued, is the developer get fired?

[0:09:16.2] DA: I think in that case, I think the EU might be taking the hammer to them because they pass a bunch of laws recently about privacy and they’re pretty aggressive about fining. I don’t know if anything’s going to happen to the US. Right. We’re pretty willy-nilly.

[0:09:34.0] MN: Yeah, exactly and that’s like as problem because people’s information should be – you know, privacy is important but in the US, Facebook has to run around and do all sorts of things and I’m curious, doing back to – you had mentioned the review process, is it the developer who coded it, is it the person who reviewed the poll request? What if there is no poll request process and it’s like you merge straight to master, then, who is responsible for it?

[0:09:59.5] WJ: What if you’re using like any external library? Are you going to audit every single package that you include?

[0:10:04.9] MN: Yeah, I mean, it’s going to be tough.

[0:10:08.1] WJ: Are you going to re-audit it every time that you have to upgrade a package?

[0:10:12.6] DA: Yeah, I do appreciate how MPM does that to a degree. But who’s going to audit that audit? Like MPM tells me, there’s something wrong and I’m like, all right, I trust you. Right, thank you.

[0:10:26.4] MN: For every release, supposedly we were taking this very rigorous process. For every release, you would have to then do another audit on everything that you currently have, all the features that you have currently built.

[0:10:37.6] WJ: It sounds like what we’re talking about is completely antithetical to AGILE.

[0:10:41.3] MN: Yeah, it does but that’s the thing. As agile developers, are we unable to call ourselves software engineers then?

[0:10:50.7] DA: Yeah, it’s kind of interesting, I think about like where the term software engineer even came in but that didn’t exist for – like in the beginning of the industry like they didn’t have something to call it and I think they branded it as engineering to try to sell it as something that is more risk averse than it actually was.

Because it was people figuring out how to build ginormous systems on really limited servers and you know projects just running away over budget and not having the tools and techniques they need to actually deliver. So yeah, they’re like, “Oh just call them engineers.”

They come up with these practices, these waterfall practices and now things are kind of going the other way because it was just so easy to continuously release.

[0:11:45.1] MN: So if you wanted to be somewhat more aware, I am going to use the word aware but  think about all the safeguards that we would have to do to be software engineers as agile as possible what are some things that we can do about that?

[0:12:03.9] WJ: So given that software developers are not real engineers which just seems like we have pretty conclusively established at this point, what do we do about it? Should we become real engineers and start holding ourselves to a higher standard? Should we just acknowledge the fact that we don’t really care that much about safety and move on with new titles?

[0:12:28.5] DA: Software person.

[0:12:30.1] MN: The software person, I personally feel like –

[0:12:32.9] WJ: Some software schmuck.

[0:12:35.0] MN: Well somebody over here writes software. I think there is some kind of responsibility that we need to have as software developers. I think one of the things that I’ve noticed in my career that gets a lot of light is can everyone browse your website comfortably.

That includes like people with disability and then the one that I often overlook is people who are unable to see certain colors. So if you have a website that has a red and someone cannot see red, I don’t remember what that –

[0:13:10.2] WJ: Yeah, red-green color blindness is extremely common.

[0:13:13.1] MN: You as a listener right now, think of all the websites that have the color blue on it. There’s tons. You can just think about Twitter, you can think about Facebook, you can think about Google and all sorts of stuff and I am sure they have taken into account these things and color blindness and amongst other things, there is all sorts of devices that allow users who are blind to view your website in brail with all of these different tools that are often overlooked.

And the problem that I have seen happen is if you have a website that gets a ton of viewership and you don’t look out for this then you get a fine that your website is not like ADA approved and then what does that mean?

[0:13:53.6] WJ: Well sort of, do you get a fine?

[0:13:55.9] MN: No, I believe you do. I believe you either get a class action lawsuit from that.

[0:14:00.8] WJ: Somebody might come and sue you that’s true. They also have to go through a whole lot of leg work to find other members of that class. Like if you are blind and you can’t order on an article of clothing or a piece of food or something from somebody’s website, you know that may be a problem for you but unless you can get a hold of a meaningful number of other blind people who have tried and been unsuccessful on that same site, you are not really all that big of a risk.

It’s only big companies that have enough customers for there to be enough disabled people to come bring into a serious class action lawsuit.

[0:14:41.5] MN: Right but if you are, if you have the opportunity where this happens to you then you should be responsible to ensure that all of your customers are able to go to this website and I think that gets often overlooked because even right now as an engineer, try to find a list of ADA related bullets you have to have.

Like for example, I know that in React, every button needs to have an ID tag I believe because it’s ADA like certain devices for people who are disabled use the ID tag rather than the class name to find it.

[0:15:21.7] DA: Right like Aria, Aria compliance.

[0:15:24.7] WJ: You need Aria labels for everything, you needed tag index for everything. It is selectable. If you use a model then you have to implement it escape.

[0:15:34.5] MN: How do you know that?

[0:15:35.7] WJ: I had to study web accessibility. I had to implement web accessibility on progress.

[0:15:42.4] MN: Where did you learn that from? Was it a course, was it a list of documents you got from the government website, was is it just finding online, here are some things you need to do, like -

[0:15:51.5] WJ: Part of it was a course, part of it was going through the docks on the W3C website. Part of it was learning from other people who have done it before.

[0:16:01.0] MN: Was it easy to find?

[0:16:02.9] WJ: No, definitely not.

[0:16:04.8] MN: Exactly that is the problem.

[0:16:06.2] WJ: I don’t think I have ever seen a website that I think is a 100% compliant. I think that you know that is one of those things, there are so many regulations. You can pick any website on the internet and somebody with enough expertise would be able to find the problem with it.

[0:16:17.3] DA: Have you ever tried to use the biggest screen reader?

[0:16:19.5] WJ: Yes. I had to use a screen reader in order to test the website to see if we’d made it accessibly and we have not and using the screen reader was really painful. You can actually speed it up so that it reads really quickly which I think at first blush seems like it would be really obnoxious but when you actually have to use one regularly, oh my god it is a lifesaver not having to wait for the person to finish their sentence.

[0:16:46.6] DA: Okay, so my question about that is do you feel like it is necessary for all developers to get that specialized knowledge?

[0:16:56.5] WJ: I mean if we wanted to live in a world where all websites are accessible to people with all disabilities which sounds like a wonderful objective then I think in order to do that effectively, you would need most developers to be able to – we would need most developers to have that expertise. Is that are we willing to accept the consequences of insisting that all of our developers to be trained on that and that they hold themselves to that standard?

[0:17:28.3] DA: At least there is also the consideration that all of those developers are figuring out Aria compliance and whatever they also need to figure out, you know if they are left pad is key logging you or some other security vulnerability and all of the other numerous things we have talked about earlier that could be like the bridge that comes crashing down.

[0:17:52.4] WJ: And some other company could come along and not implement any security procedures or any web accessibility and then beat your company competitively and you could go wonder because you were doing the right thing and they were moving faster than you.

[0:18:07.1] MN: Right.

[0:18:07.6] DA: Yeah, first to market.

[0:18:10.0] MN: The competitive edge of just being able to move and not have to look over these different restrictions I am going to say. And it truly does suck because we want to make sure that everyone is able to view your website in the way that it was supposed to be viewed but if you want to move fast then you are going to have to overlook some things and that includes maybe overlooking people’s disabilities which is late.

[0:18:35.0] WJ: So what do we do? Do we create a government agency that is responsible for going around and finding everybody when they –

[0:18:41.2] MN: Space force.

[0:18:42.7] DA: Spice.

[0:18:45.0] MN: It’s space force.

[0:18:46.1] DA: Spice software programming.

[0:18:50.0] MN: That’s spice. Yeah I think the easy solution right now would be to downgrade to the software developer because that is what we do and we don’t do the things that of engineers.

[0:19:01.8] WJ: Just stop calling yourselves engineers.

[0:19:04.1] DA: Yeah, that is something. I mean that is not the acknowledgement of a reality. I mean we can also just consider that there are things that we don’t understand and make more considerate efforts to educate ourselves about what those things are and at least be aware of the limitations.

Which I think is a really good thing that the Atlantic article ended on which is the ritual calling of the engineer. So I think that is a good oath to think to yourself when you are approving that pull request. Maybe you could get a little check box in your PR template and you have to check that little box.

[0:19:49.5] MN: I will even read it. I’ll go ahead and read it.

[0:19:52.1] DA: You will read it? Okay?

[0:19:53.1] MN: It is the following. “My time I will not refuse. My thought I will not grudge. My care I will not deny toward the honor, use stability and perfection of any work to which I may be called to set my hand.”

Yeah, if you had to read that out loud like, “Hey everyone, I am about to read the oath. It’s serious business right now.”

[0:20:18.3] DA: You ring the bell. The Wikipedia entry for this was walking about how they have this iron rings that they wear with this engraved in it. That seems like so extreme.

[0:20:30.8] MN: That is awesome, they can wear this thing to ensure that I am doing the right thing every time I develop.

[0:20:39.2] WJ: Oh man I want a ring now.

[0:20:40.8] DA: Yeah that sounds pretty sweet.

[0:20:42.2] MN: One ring.

[0:20:43.5] DA: With your powers combined.

[0:20:46.5] MN: Yeah, the ritual of the calling of an engineer.

[0:20:48.1] WJ: The ring has a bug in it, there is a security back door. There is a back door that allows that one guy to control everyone else’s ring.

[0:20:55.8] MN: Wait a second.

[0:20:56.4] DA: Oh that is the plot, oh my God and you call yourself ring engineers. Get out of here elves.

[0:21:04.8] MN: Get out of here. Get out of here.

[0:21:06.9] DA: Go back into the west.

[0:21:07.8] MN: Get out of here. But yeah, so I don’t know if we end to with a question.

[0:21:12.8] WJ: We are going to have to throw that software back into the source forge from where that came.

[0:21:16.9] MN: Oh man the source forge.

[0:21:19.0] DA: Oh my precious.

[0:21:21.8] MN: Did we solve the problem right now? I don’t think so and I think this could be an ongoing conversation.

[0:21:27.9] WJ: I don’t know if there is a solution. I think that is always going to be debate.

[0:21:32.0] MN: Right.

[0:21:32.5] DA: It is an acknowledgement you know? That is going to be an ongoing Atlantic article that never ends.

[0:21:39.9] MN: And will never fade. Follow us now on Twitter @radiofreerabbit so we can keep the conversation going.

Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.

On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.

Links and Resources:

The Rabbit Hole on Twitter

The Atlantic

GitHub

AWS

PyCon

Python

React

Comments