Soft Skills Engineering - Episode 14: Web developer prejudice and legacy code

Episode Date: June 7, 2016

In episode 14, Jamison and Dave answer these questions: Since I am primarily a web developer, I often find there is a bit of developer prejudice, against web developers from software engineers of other categories. Often I find they think I am not capable of anything other than jquery dom manipulations, and talk down at me like I wouldn’t understand their expertly setup mysql queries. As it turns out, I too have my CS degree, and start new projects in all kinds of programming languages just to learn them. Any tips for breaking the web dev stereotypes? How to deal with legacy code and legacy coders? The code was probably good once, but it is impossible to maintain and doesn’t work on new hardware. You know the best approach is to scrap it and start from scratch but the original coder is resistant and wants to find a way to “make it work”. What do you do? In my situation, this legacy coder is a peer, and the only person above us doesn’t want to take a side on the argument, so we are left at a stale-mate.

Hello everyone and welcome to episode 14 of the soft skills engineering podcast the podcast where we discuss All the non-technical things the everything else in software development. I'm your host Dave Smith No, I'm your host Jameson dance, and now we shall fight to the death It's hard over Skype Who can send the most horrifying Skype emoji Those things terrify me. They really do. The animation is like too good.

Yeah, it's uncanny valley. Oh, Skype, we love you. Yep. Great. So what's going on in our world, Jameson? You just got back from a foreign country. Yeah, I was in Oslo for Web Rebels, which was maybe the best conference I've ever been to.

It was amazing. Like the quality of the speakers and talks was really high. I was kind of blown away. And you're only sort of tooting your own horn since you were one of said speakers. No, I don't include myself in that assessment. Yeah, I spoke about Elm and then I got to sit and listen to lots of smart people

talk about lots of great stuff. So cool. I can't wait to get caught up on those. Yeah, yeah, they were really good. So I think we have a couple of questions from some of our beloved listeners today. Would you like to kick us off with our first one? I would love to.

Since I am primarily a web developer, I often find there's a bit of developer prejudice against web developers from software engineers in other categories. Often I find they think I am not capable of anything other than jQuery DOM manipulations and talk down to me like I wouldn't understand their expertly set up MySQL queries.

As it turns out, I too have my CS degree and start new kinds of projects and programming languages just to learn them. any tips for breaking the web dev stereotypes i like how he used mysql as like the the expert source of the prejudice yeah i'm a masterful mysql query author um i think you have to defeat them in a test and in a feat of strength which is like who can invert the binary tree the fastest and then whiteboards ready yes and then you cow them and then they accept your authority uh i think this is a great question especially because there

are so many people from so this person cites their cs degree there are tons of people without cs degrees and a lot of them from for me talking to them a lot of them have this kind of fear that like someone will discover they're not real programmers because they don't understand some arcane cs concept and and even if people aren't explicitly kind of looking down on them they they just feel like that themselves. So I think this, this applies in this situation, but it also applies to just people who have maybe non-traditional backgrounds. Hey, so before you change the background color of that button, are you serious that you don't know what the pumping lemma is? Oh, I can't even believe they hired you here.

I have also seen this prejudice, uh, actually both in others and myself. yeah um so full disclosure james and i are both in the web development world right now and uh but i wasn't always so about four years ago i came into this area of the development world i came from a c++ background a place where i consider myself to be pretty hardcore you know and and we used to use terms like well that developer's not classically trained what are you kidding me i actually heard that phrase it was only half joking i think oh my gosh oh what nerds no but i have seen i have heard things like well you know in c++ we have a linker command

but in javascript they just use the cat command yeah yeah so this is a real thing i think is what you're saying that that there are definitely people who feel this way that like either the closer to the cpu you are the closer to assembly you are or um i think there's also people that feel this way about like their preferred esoteric programming language paradigm like if you're not functional you're not oh you're not anything and then they just talk about monads until you die um yeah this this is a real thing i i have i don't like it i guess that sounds dumb but um i don't think you you get to look down on people just because your tools suck like if you are a hardcore c dev or whatever and then you you you have to like it is kind of hard

there's all these horrible gotchas you have to know about how the like the physical computer actually works or some weird little arcane uh like i don't know edge cases in your system that doesn't make you better than someone who uses a tool that that protects them from those things like they probably get a lot more done than you honestly because they don't have to worry about like uh on the x86 architecture on tuesday a one is actually a zero the thousandth time through this loop like i i don't know i so some of it is just like yeah you you write in languages that suck more and yet i do have a certain degree of envy for people for example who work on the linux kernel like i don't know why but i just think wow those developers are heroes like they're

gonna walk through some doors in slow motion like like in armageddon or something and like carrying their pocket protectors or whatever as they write their block device yes i don't know i do have envy for that kind of developer i just think i don't know i think they're hardcore air quotes yeah that's something i think of a lot so maybe the prejudice exists in both ways it's like i not only think that you know jquery script kitties are not hardcore but i also have like anti-prejudice for people who work in more challenging environments than i do so the the real thing you can do is you probably get paid the same amount as this air quotes hardcore developers so you can just pull out your paycheck and shout scoreboard and say if their

argument is like i work so much harder and my job is way more difficult you can be like well sucks for you because i do easy stuff and make as much or more than you do and i and i will actually back that up i think generally speaking at the companies i've worked for the engineers who are working on say you know front-end web dev versus like back-end uh tend to make about the same amount of money so um i don't think i really don't think that the economics justify the prejudice yeah i think building good and responsive user interfaces that are easy to maintain and work on is an incredibly difficult skill and uh let's see how do i say this probably the closer someone is to the the back end that i i think the trend is they will probably care less about user experience

oh okay so maybe some of it is um the things that people are that do front-end web development are skilled at they just don't they don't appreciate maybe yeah they don't care if they have to click through like 15 screens or the ui is just like a checkbox for every column in the database it's a one-to-one mapping of your data yeah it's like that that doesn't bother them but but uh people besides them care a lot about that stuff so maybe maybe it's kind of a lack of appreciation for what makes a good product so are you saying jameson that this might just be so ingrained that there's nothing we can do to fix it uh no i mean the scoreboard thing i think we'll fix it i already gave my answer yeah no i i think earlier when we were talking about

this you mentioned respect and i think you have i want to hear your thoughts on that yeah so there are really two kinds of respect and uh what we're talking about here is the second kind the first kind is basic respect for other human beings, which means treating them with dignity regardless of who they are, what they are, what they believe. The second kind of respect is respect for someone's authority. And generally that respect is earned. The first kind of respect I think should be given to all human beings regardless of any circumstance. But the second kind of respect is the kind that's earned. And I think what we're talking about here is a lack of that kind of respect for the industry that we're talking about. So hopefully we're not talking about the first kind, because if someone

is falling into the first kind, that's just totally out of line, just completely, uh, what's the word out of line, right. And, and completely bad. But the other one, uh, that respect has to be earned. And, um, a lot of times there's nothing you can do to, uh, force someone to have that kind of respect for you. And if you try really hard, like I'm going to make sure they respect me. um that's like that's like the worst way to get that kind of respect yeah awkward teenage comedies have taught us that that won't won't work yeah um while you were talking it made me think of of there have definitely i've talked about this before but there have definitely been times in the past where i have not appreciated people who aren't developers as much as i should and i

had this same hierarchy thing except it wasn't like what kind of development you do it was like are you a developer or are you like overhead you know are you either you're either writing code or you're slowing us down that's right and and that changed as i got older and more mature and um i think that the key is that uh people can be good at their job whatever their job is and and recognizing that skill and the value that everyone has is is pretty important and like you said you can't force that on someone to some extent you can do that yourself and maybe maybe this experience will help you avoid uh treating someone the way that this person is treating you in the future um just one one little like tactic you might use though is just pair programming like if your

relationship is is good enough that you could program together um if it's if it's horrible this might not work out super well but uh i think you would both learn things from each other you would maybe get a better understanding of kind of the the back end like air quotes hardcore stuff they do and then this other developer might appreciate the the trade-offs and the decisions that you have to make as a web developer and what makes that hard and what what makes you good at it i guess so you're saying it's a good way to give them empathy yeah yeah you can't you can't force someone to have empathy but but you can force someone to work with you and then hopefully that leads to empathy unless they're a monster yeah one of the uh one of the ways that we have

inadvertently helped to mitigate this problem at my company is we encourage uh rotations which is where a developer will change the functional role that they participate in every six months to year or sometimes longer for example we have people who are on the back end for a year or two um They usually volunteer to do this, but they'll move to the front end and be like, I'm going to get exposed to front end for a while. We're going to have a back end engineer move to mobile. You make it sound like it's radiation. I'm going to get my dose of front end until the badge turns red. And by having people rotate, I think you get a lot of benefit because suddenly those other people's problems are your problems.

and even when you move out of that role you have you still have that leftover empathy i think from oh yeah having to deal with those yep i want to say one more thing which is i think i've been i think some of this could come from a place of jealousy i have been on teams where i have been kind of the back-end developer and all my work is is uh it feels kind of like laying the ground for other people so i'm like working away working really hard to make good apis and make stuff scale and all that and then there's there's a ui developer either kind of native or mobile or sorry native mobile or or web or something and they put in like a cool animation that makes something flip around from some library that they downloaded and then the whole company just like

freaks out and loses their mind like that's the coolest thing i've ever seen and and i have felt unappreciated in that moment like this person spent two hours plugging this library in to make something flip and i've been working for weeks to like support the query to give them the data that they need to put on the back side of that flippy thing and they they get like applause and and i get nothing so like did your rest api flip even once i mean come on it will it will soon so some of it is the the closer you are to the front end the the easier it is to get validation and recognition from non-developers good point um and and that can feel really good and it can sometimes feel bad if you don't get that especially if you work in an organization that uh is is made up of

more non-developers so you you don't have people to kind of slap you on the back when you do good work yep very true um so maybe you could help by by appreciating the work the other people do as well good point good point thank you yeah and then the other thing i would say is next time you have a really nasty z-index problem just call over one of the back-end developers and have them try to help you figure it out yeah oh and then pull up that firefox 3d visualization thing that makes people think you think you're more hardcore than you are but tell them you made it just now this is something i threw together really quick like why does this say mozilla ignore that cool i think we answered that question yeah this is this is definitely a hard one so i you know

i don't think that there's any one silver bullet for this this is i mean this is another reason why working with people who are good with people is great because even if people feel this way if you can talk about it openly and and have empathy with each other then you can you can solve hard problems like this right on cool should we do the next question let's do it this is another one from a listener that says how do i deal with legacy code and legacy coders the code was probably good once but it is impossible to maintain and doesn't work on new hardware you know the best approach is to just to scrap it and start from scratch but the original coder is resistant and wants to find a better way to make it work what do you do in my situation this coder is my peer and the only person

above us doesn't want to take a side on the argument so we are left at a stalemate well i didn't notice this when we were looking at it before the thing about hardware it i'm gonna guess this is probably a mobile app and probably some android thing uh and and it just uses some old deprecated apis maybe it could be yeah it could be i didn't i didn't notice that wrinkle before so the question is do you rewrite it or do you like try to put in place some wonky abstractions to work with old apis or something yeah that's uh that's an interesting wrinkle this changes everything um so first of all i want to talk about some assumptions that i think that the question asker is making um one is that the best approach is to scrap it and start from

scratch and the other one is that uh the original coder is well i guess this isn't an assumption never mind the one assumption that the best approach is to start from scratch i i think that is often not the best approach especially if something is in production and has users and it's working there's an enormous amount of institutional knowledge in that code um which is hard to replicate in a new system without running into the same problems or different problems that they have avoided uh so so starting from scratch is scary to me because you throw away everything that you've learned and and you start a new project and new projects fail all the time and they overshoot their deadlines and like just taking on a lot

of risk for for something that i don't see as a lot of reward often let's let's talk about that for a minute. I think when you say, let's throw it out and start from scratch, unless you have gone through the rigorous list of all the stuff that this code does, and at least written it all down, I don't think that you have fully appreciated how hard it will be until you do that. And sometimes when you get down that list, you know, you think the list is, well, it's like a dozen things this code does, you know, and then you get into the rewrite and suddenly you realize, no, it's more like a hundred or 500 you know that has literally happened to me and um and saying let's throw it out uh and rewrite it oftentimes comes from a position of not actually fully appreciating

just how much this code does yes i uh let's see it's also possible that this rewrite is more of like a product driven thing where maybe the direction of the product has changed a lot and that seems like a better candidate for a rewrite um another thing that might be going on that's happened to me is i bet that the legacy coder in air quotes feels pretty defensive i i bet that they helped write this system and when people talk about how broken and horrible and unscalable and just like it's not even worth saving i bet they feel really defensive because they helped create it um i yeah like i said that's happened to me before i've written things that were just hacked together and really quick and dirty and then we had to work and maintain them over time

uh and and it's really hard to disentangle your personal feelings from the thing that you have created like software is awesome because you make stuff but then sometimes people tell you that the stuff you made sucks so that probably doesn't help the the the attempt to come to an agreement about what to do with the code that they probably feel kind of attacked and they can yeah they can yeah so i don't know what to do about that besides just recognize that that might be a thing that's occurring and and you might say like well it's it's just code like people need to disentangle their personal feelings from code and and think about it kind of rationally and they do but but that's people the harder to do than it is to say to do yes it is but it is a very good thing

to do yourself yeah um let's talk about that for a minute so how do you show someone who wrote the original code that it is hard to maintain for you and others and i think one way to do that is to bite off a small piece of the code that needs to be rewritten just maybe not because it's just bad but because there's a new product requirement and it needs to be rewritten naturally and try using this new technology or this new thing that you want to use and let the other developer work in that technology and if it really is better like you think then it should become obvious to them that it is and help them to see it firsthand rather than shoving it down their throat sure i think you identified a solution there which is that you you bite off a chunk of it

um i think it's often less risky to rewrite something than it is to start from scratch and that allows you to work in pieces over time and and sometimes the working by pieces will involve more work than it would have if you just started from scratch but you get to maintain the the product you get to make sure it's working you don't have to deal with like stopping work on your existing product or doing parallel teams where you have to build a new product but also keep up with the features that are getting added to the old one and um so so it's harder but i think it's less risky to the business it can be so i think this is a good time to share a couple stories from other companies that we've heard about um do you think

so yes so i use a service at work called pivotal tracker probably a lot of our listeners do and uh about three four years ago they decided to embark on a complete rewrite of their front end and i think they actually made a whole new api as well and what this meant for users like me was that we got no new features for literally a year and they had some major problems they had some really slow page load times like 30 to 60 seconds for some of their stuff it was super bad for large projects like mine and then after a year they rewrote it all and they released this new beta ui with this new api and it was different and it was a little a little bit better but not a lot better and then over time over the next several years they started doing feature after feature

after feature and the ui got faster and faster and it was like a whole new product because they took the time to just completely shut down new product feature development and rewrite so that's a case where it actually worked but the company was willing to shut down new feature development for literally a full year yeah um while you were talking i actually remembered a time a few years ago that we rewrote um like a pretty major chunk of our internal system it was this large data import that had to consume this gigantic uh batch of xml files and kind of parse them all and stick them in a database and it was um pretty buggy but it worked but there there were just issues where it would sometimes not make relations properly or it would like

silently not import some of the data and and it was kind of old and the people that had written it didn't really um they weren't around anymore so it was it was intimidating to work on and we actually did rewrite it uh we didn't throw away the existing one though we kind of used it to check our work um and and that ended up working the new system was faster and it was easier to maintain uh because of some choices we made around around testing and tooling and languages that we picked um so i did actually have a story about how it did work to rewrite i forgot about that cool um but i also have a story where it didn't work so netscape back in the day uh they were rushing to release their software to avoid microsoft from killing them basically um they

were trying to to release a browser and release updates to it because they knew that microsoft was working on a browser and they were going to bundle it with their operating system and it was going to just destroy them. So they cranked out under insane deadline pressure, some pretty horrible code, uh, that worked and got to market and got users and users enjoyed it, even though it did have some technical issues. And then they were successful, made a big company, uh, and they went to rewrite it. They hired a bunch of people. They brought in some, I think they acquired some companies and some consultants and stuff. And they had like the big rewrite to fix all the architectural problems and they just never finished and and the company died and part of it was

because of that there were some other issues too but but it just took them so long to release the next version of their browser um and and jwz is a famous developer there that was there in the early days and there during the rewrite and he blames it pretty much on on the rewrite that they they took too long they started over and they lost all the market position that they had because of it um so maybe sometimes it's bad so jameson you know there's really only two kinds of startups right uh sure what what are they those that fail and those that are embarrassed of their code that is so true um i i know ryan florence talks about that a lot that yeah um he that's all i have to say about that okay do you freaking name dropper well when i was uh

on my yacht with him sipping the caviar you drink caviar right isn't that how you consume it through a very small straw okay good speaking of ryan florence he gave a great talk at react conference i was at react conference anyway it was about porting your front-end web application to react and he talked about how like a singing approach to doing that piece by piece from the bottom up as opposed to like let's just throw it all out and rewrite it because i think generally speaking that is a better approach it yields more value to your company and to your team than to do the clean slate start over thing yeah i i have some inside information on the product he's talking about though um it's not that inside because it's open source but they they have

attempted that with several different technologies over the years and their product is gigantic um and the end result is there are now these there's there are several layers of different javascript frameworks and architecture paradigms and stuff so uh the rewrite in pieces thing is great if you can be consistent and commit to it but the danger is you end up with just little islands of like someone's cool technology that they thought was going to save the day or halfway through the rewrite you start another rewrite yeah which is that that happened in this product too um yeah they're man there are all kinds of trade-offs i know i was soundly against rewriting and then uh we told three stories two of which the rewrite worked well uh but still

it's scary and and you should see if there's a way to do it incrementally the the risk is much lower. So I think in the situation specifically described by this listener, we have three parties involved. We have the listener who wants to rewrite from scratch. We have the so-called legacy coder who wants to hang on to the old code base. And we have some kind of lead in a lead role who's unwilling to make a decision. And I think that a really responsible thing to do in this situation would be to get a meeting with all three of you together and say, look, I am having a hard time working on this product and lay out your reasons. Like hopefully you have concrete reasons for this. And it's not just, well, I didn't write it, so I don't like it. And lay it out and then

look to your lead and say, help us navigate this and mediate this conversation and help us figure out a way so that all of our needs can be met. It is your lead's job to break ties and to help moderate these kinds of discussions. And so if they refuse to do that, they're really not doing their job, in my opinion. And I think you owe it to your team to sit down responsibly and say, let's talk through this together. And also try to understand the person that you're calling a legacy coder because it sounds like maybe by putting that label on them you're not really giving them uh a lot of empathy it sounds like maybe you don't fully understand where they're coming from sure so to sum it up oh and then if you don't like the outcome quit right that's

yeah if you don't like the outcome go get a different job um i hate by the way i kind of hate that we say that because it's such a cop-out and it only works because circumstances right now are so good for employees but you know yep but hey enjoy it enjoy it while it lasts ride that wave yep um so that's situation yeah do you want to summarize what we talked about so i think that um there's obviously two major paths you could take you could do the rewrite from a blank slate in which case you make better make sure you fully understand what you're getting into and there's a lot of risk that that brings with it and then there's the other approach of rewriting pieces piece by piece which carries with it its own trade-offs and i think both

approaches are equally likely to fail if poorly managed and are almost guaranteed to fail if the team isn't on board fully with the idea and so i think you need to get a consensus before you proceed i like that that um yeah that feels right to me that the determining factor over whether this succeeds or not is a lot more based on the team than than the approach although it i think it is overall less risky to rewrite incrementally because you at all points hopefully have a working product still yeah and there's no danger of like people changing their minds suddenly and then you're just left with this failed project that doesn't it's not done cool question answered question answered these were tough ones today they really are like these are the kind of

conversation i wish i could have with the person in real time and ask them like a thousand questions about their circumstance yeah but now you don't have to because you can just point them to this podcast where wisdom descends from the heavens like do yep well sorry if we completely failed you and as always if you get fired by taking our advice you should have never taken our advice yep cool well uh where can on that note the bright happy optimistic note where can people find out more about us dave check us out on twitter our handle is at soft skills eng you can be notified about new episodes and you can ask us questions that way if you want to post a question on twitter do that or if you don't like being limited to what is it 140 characters or

something you can send us that's right they're changing that aren't they um you can send us a direct message using the twitter direct message feature which is how we got both of these questions today and we will add them to our backlog and if you enjoy the show uh just tweet about it would be amazing rating it on itunes would also help us out a lot it would help more people find it we'd appreciate that yeah great thank you for listening and we will talk to you next week see ya