Episode 27

Creating Products for Enterprise Customers: Falko Buttler and Daniel Dietzel with Jiff.com

Show Details

Today we have Falko Buttler and Daniel Dietzel from Jiff.com on the show. Falko is the Senior Director of Engineering and Daniel is a Senior Frontend Engineer at Jiff. They are joining us today to discuss their extensive frontend engineering experience. During this episode, we’ll talk about implementing Angular JS as a startup creating products for enterprise customers and also delve into some other exciting topics.

Once again, thank you for tuning in, and let’s welcome Falko and Daniel.

Show Transcript

Carlos: Hello everybody! Today we have Falko Buttler and Daniel Dietzel from Jiff.com on the show. Falko is the Senior Director of Engineering at Jiff. And Daniel is a Senior Frontend Engineer also at Jiff. They are both joining us to talk about their frontend engineering work, and during this episode we’ll talk about implementing Angular JS as a startup creating products for enterprise customers. We’ll also dwell into couple of other topics. One that might be very interesting for you and it is how Angular JS has helped their team at Jiff standardize their hiring processes and also kind of the profile of people that they hire for their engineering teams. So well, I hope you’ll enjoy this episode. If you like it, please don’t forget to rate it and subscribe, and leave me any comments. So you can always reach out to me at carlos@G-I-S-T-I-A-.com, carlos@gistia.com. And once again, thank you for tuning in.

Carlos: Thank you guys for coming on the show! How are you doing today?

Falko: Very good, very good.

Daniel: Good. Yup!

Carlos: Doing good, doing good. Really happy to have you guys on the air and we had some scheduling issues so I apologize for that. I thank you guys for the patience and making it today. So tell me a little bit about your backgrounds and how did you end up in software. I’ll let you go one at a time.

Falko: Sure. So my name is Falko and I knew very early on that I wanted to get into software. Even like during High School I already work in it. And it was always fascinating to build something out of nothing because you’re writing code, and you can basically imagine whatever you want and you can actually do it. And that brought me to Silicon Valley about four years ago when I joined Jiff. And now, I’m a Senior Director of Engineering here and I’m heading the frontend team so iOS, Android and Web.

Carlos: How about you Daniel?

Daniel: My name is Daniel, and I actually, I got into software on accident. I came to America to study art, actually Fine Arts. And after graduation I needed to pay some rent, and the only real skill I had was Photoshop because I studied Photography. And so I actually started by slicing up Photoshop templates into HTML, and then next thing I learned HTML, then I learned JQuery, then JavaScript, then real engineering with Backbone and Angular, and next thing you know, uhm, I end up in Silicon Valley working for Falko.

Falko: [laughs]

Carlos: In our conversations before, it seems like you guys have a very strong team. And kind of have built a really strong way of working together which is of course really good and part of our topic today of course. So today we’re going to be talking about the decision making process behind making a frontend framework. Some companies might be in a position where, again they’re looking towards the future but you guys have been doing this for some time already. So you guys have some visibility that others might not have so, you can look back and say, “These are some of the wins and maybe some of the issues we had with this or that”. So let’s just jump right in, so at Jiff though before we jump into the framework. What is Jiff? What you guys do over at Jiff? Like what does the company do?

Falko: Jiff is basically providing health benefits platform. And what that means is that we are working with Fortune 500 companies and then other larger companies and helping them defining and rolling out digital health incentives and benefits. And that includes challenges that people compete against each other where people get rewarded for doing certain healthy steps and will personalized it based on your needs so that. The whole idea is we want to make you healthy, you’re more productive as an employee and help you reduce your health cost.

Carlos: In terms of your stock, maybe we can talk a little bit about how your system or sort of your architecture is laid out. So there’s, from what I understand from our previous conversations there’s a couple of products or a couple of systems that make up Jiff and you guys use Angular JS for those.

Falko: Yes, so our backend is mainly in Ruby, and newer parts in Java, and then we have two native iOS apps that are written in Objective C and Swift. And then we have three Angular apps that are in production so, two are apps that our users use and one app is more for administrator usage and for the health benefits administrator. And those are all Angular apps.

Carlos: Alright, so it’s, I think the area that we’re going to kind of zoom in a little bit more is going to be about the Angular world, and maybe we’ll touch a little bit on the Rails side, maybe how that has evolved. So Falko, you were there at the beginning in terms of selecting the next framework and so forth. Why Angular, and why not some of the other options?

Falko: Yeah, so we had Ruby on Rails applications at that time and it was really hard to scale it and make it, yeah, make it faster, but also make it easier for other people to contribute. And we also wanted to decouple it from the backend as much as possible especially since we also had an iOS app that also only talks to our backend through APIs. So we wanted to have the same concept for our web app as well. And I, basically I did a bit of comparison of all the different frameworks that were out there at that time. So Backbone was in the mix, Angular, Ember, and the few others. And for me Angular had the biggest community. They were the most people using it. It was still actively in development, in heavy development. There were lots of people who use it so, for me it was also a question about finding people that I can hire that know it. And it was well documented and it was still backed by Google.

Carlos: Daniel, and from your perspective, coming in as an engineer. What attracted you to Angular JS? Is there something specific that you can share with us as to why Angular is liked by engineers?

Daniel: So actually, when I graduated, me and my buddy went both into software. And funny enough I went into Backbone and he went into Angular, and we actually would have fights about which one was better. And Angular ended up winning not just between us two but in, you know, the bigger industry. I think for a number of reasons, the simplest being that, you know, like Falko said, “Google backed, Google backed Angular.” And that really made it an industry standard very quickly. The other thing is that while Backbone has a really really precise control over everything. It’s almost too complex of a tool and Angular is really easy to just, it’s easy to learn and difficult to master. And that means a lot of good talent comes in, and a lot of good people can get something up running pretty quickly. And that means, you know, whether you’re building a small project and you just want to get something out the door, or you’re building, you know, a big enterprise application. Both the tools, the tools are simple enough for people to come in the door but they’re complex enough that you can really build anything with it.

Carlos: From judging by how the Rails is still in the picture. Was your original system built on rails? And what made you guys think that it has to change towards this type of frameworks?

Falko: So yeah, the original system was build in Rails. And now, we don’t have any Rails or I would say almost no Rails in our backend. There’s still a little bit of a legacy system that is using some Rails, but nothing for rendering any web pages. It’s purely backend. For us it was, we got more customers and Rails is known for being a great prototyping tool getting something quickly out of the door. But when you get more customers, more traction and you want to scale it then it gets to its limitations. And we basically felt the same problems. Also Rails, at least the way we build, it was not really build for parallel processing or asynchronous codes and asynchronous handling of data, and we do a lot of that. And now using Angular it was really easy to translate what we had in our native app, in our native iOS app and do it exact same way on the web. So that was no difference in behavior and the difference in how we had to design something.

Carlos: In terms of hiring, and maybe you both can add to this. Do you guys think that picking a framework, maybe it’s not, my question is not about Angular specifically but overall frameworks. Do you think it has had an effect in hiring?

Falko: Yes.

Carlos: Has it made easier to find common denominators for the right type of people?

Falko: Yes. I definitely, picking Angular as a framework, or like any frameworks that you choose definitely has an effect on hiring because we use it so heavily that we needed to find people that know it, and that used it before, and have experience with it. And you also find a certain kind of people depending on what major framework you picked. So if we have chosen something like Ember at that time. I don’t know how it is now because I’m not following it that much. But we probably would have found a few people using it, that have used it for a long time but they use it for different purpose. They build web pages using Ember while we were looking for application developers who use Angular to build applications not necessarily websites. And using Angular made it easier to find these people. Also, Angular at that time when we made that call as well as today is still like hip in that sense that people still jump on the train and want to learn it so there’s a lot of people out there that want to learn it and used it before.

Carlos: And Daniel, one time, last time you spoke you said something about how you thought that Angular or let say picking a framework allowed you guys to use or hire an engineer that came from a boot camp. Well, before it was harder.

Daniel: Yeah, that’s right. The most recent hire we actually did on the frontend team was someone who had just completed the boot camp. And it was funny because we actually had a choice between an industry veteran and someone from a boot camp. And the choice was pretty difficult but it ended up being that the person who went through the boot camp coded exactly like us. We understood exactly what he was doing and he understood how we were coding and then streamline the whole process where, you know, you still have to have a good culture fit and all of that. But at least the software, and the technical knowhow, and the way of doing things is all streamline with the framework like that. You don’t have to go looking in all these different places. You just say, “Hey do you know this framework?” And a lot of time you’ll find really good talent. And we’ve got lucky this last time and we took a chance and said, “Well, let’s all see if you learned anything in the boot camp.” And then it turned out, uhm, you know, it was a really great hire.

Carlos: Do you guys find that there’s a difference between a developer mindset and an engineering mindset? And if so, which you guys prefer in a profile for when you guys are hiring?

Falko: We are definitely looking for someone who knows more than just the framework. Like someone who understands like design patterns, who understands …

Carlos: Because?

Falko: …how to design or how to build like in architecture.
Falko and
Daniel: [laughs]

Daniel: Yeah, I always joke that we should make people build Ikea Furniture in interviews because you can spot the good engineers right there. Because good engineers know that the decision you make now, if you do it wrong or rush it you know, five steps down the road if you made the wrong choice, you’re going to have to go back and redo everything. And we definitely look for engineers who, they know the decisions that they make now, the calls that they make now are going, they’re going to have to live with them and work around them or work with them in the future.

Carlos: In line with making decisions and such, what is your take on on off the shelf UI libraries, maybe Ionic Material? What you guys are using now and what’s in the future for you guys?

Falko: So we use Ionic, or we started using Ionic about a year. A little bit longer than a year ago because we, our web apps target both Android as well as desktop browsers. And we wanted to have something that makes it easy for us to build a mobile experience using Angular and Ionic. That’s kind of the purpose that Ionic wants to fulfill. Uhm, but after we use it longer and longer, it was just constraining us a lot and it made it really hard doing something that Ionic didn’t intend us to. And we actually decided to move away from it so. One of our apps is almost completely stripped off of Ionic and the other one is still in progress. And we are actually moving towards Material Design or Material Framework generally. One, because that’s what Google is pushing for Android, but also because it’s much more open and it gives you more freedom on how to use it.

Carlos: What’s your take on that Daniel? You like Material? Have you worked on Material?

Daniel: Yeah, I mean Material is what it is. It’s the next industry standard for UI, you know. I don’t think there’s, I’m not passionate about it either way. I think, you know, it has some good patterns. I think it’s just, people for a long time couldn’t figure out how to make a good UI and we finally figured it out on mobile. And I think that’s the evolution of that. But the answer I think about off the shelf thing, I have to go back to what Falko said about Ruby which is a lot of those off the shelf things are really really good to prototype. But when you get a customer and they say, “Okay, this is nice. But can you add different, you know, A, B, C, 1, 2, 3.” I say, “Oh, [laughs] well, we use this off the shelf thing and if we try to add that the entire thing breaks so.” It’s definitely a trade off if you need to get something out to proof of concept it’s really useful. But like now we’re getting rid of Ionic because when we try to extend parts of the UI, everything starts breaking. So, uhm, it has its uses, it has its downsides.

Falko: And generally, even with Material, when we parted away from, when we try to remove Ionic. We actually build it in a way so that the dependency on Material is much lower or much less than what we ever had with Ionic. So in a year from now, when something new comes out that will replace Material then the work in our end will be not as bad as we just had with Ionic.

Carlos: So talking about things that break and give you issues. Angular 2.0 is coming out of RC pretty soon. [laughs] Is Angular 2.0 in your horizon guys?

Falko: I mean, we’re definitely looking at it, but at the same time like we are bilding enterprise software, so we can’t always jump on the newest thing, on the newest shiny things so we will keep an eye on it. And what we already did is we went to the newest version of Angular 1.0, the 1.5 because that is suppose to help is with migrating to 2.0 once it’s ready. Just an interesting side note we actually got a visitor last week from Google who is working in the Angular team who used to worked for us. And he told us about Angular and obviously wanted to make us excited about it. But he also said we shouldn’t go with 2.0 because they’re still working on a lot of things to make it easier for people like us who have a bigger code base on 1.x and want to go to 2.0 or 2.x. So we actually got some insider help in that sense. [laughs]

Carlos: Yeah, that’s a big benefit of working closely with somebody from the Angular team. We are recording this on the 12th. We are hoping to be, to getting news about Angular 2.0 being official sometime this week so maybe that will come.
But what you guys think about TypeScript? Daniel, is that something that you played around with and do you have any opinions on it?

Daniel: This is where I probably get laughs at of engineering circles because I’m always the guy who asks, “Can I do anything with it in terms of building a feature that I can’t do now?” And usually the answer is actually it’s just a different way of doing the same thing. And you know, I’m way more passionate about user interface than user experience. And really coding for me is just the means to an end to build something beautiful. And exactly what the different thing is under the hood is actually less interesting for me because I’m more of a coming from the design and product side.

Carlos: Got you. Does it have any benefits though? I’ve still have to play with it in terms of anything in production of course but it seems like a lot of people are taking up to it because of ease of use.

Falko: I definitely see some benefits in it and we also discussed it internally of whether we want to adapt it or not. And we look at it awhile ago where we decided it’s not ready yet and we do not want jump on it. What definitely is interesting to me is, like I’m coming from aesthetically type language like C, C++, then Objective C and now Swift. So, for me having a language that way you have something like a compiler, or something that tells you, you are doing something wrong, or that helps you picking the right data types. That alone is definitely big advantage for me. But would I want to have everyone on the team jump on it just because of this? Not right now. We would probably do that if we jump to a newer system anyway and it’s part of it then we will do it as part of it. But not necessarily just for, like a little bit of benefits because our code base are already pretty big. And we wouldn’t want to rewrite everything so we could only adapt it like gradually.

Carlos: And I think this is a perfect segway because you both are on the same page about it’s, unless we need to upgrade we’re not going to. But with so many new frontend technologies coming out, what is the tipping point that makes engineering leaders want to evolve, right? What’s the tipping point? Where is it that you say, “You know what this is definitely something that we need to adapt.” Yes because, as you said Daniel, it doesn’t mean that, it’s probably the same tool, is it going to do it? But at what point do we find ourselves saying, “Ok, there’s a benefit.” How do you guys, how do you measure that? And how does the decision get made?

Daniel: So from our side I can definitely tell you the talent pool is the most important thing. From my side is right now we can find a whole bunch of really talented Angular developers. And maybe in 10 years the pool won’t be as big, and maybe who knows React or something, you know, will be where the talent is. And we’re in an enterprise context which is for a lot of developers, unless you’ve done enterprise before, consulting is a little bit strange because we try to mitigate risk as much as possible rather than jump on the newest technology. And that’s because, you know, with the consumer app you can make updates all you want and break or whatever, and you know, you have to answer the consumers. But in an enterprise development, you know, there’s million dollar contract with every last line of code accounted for. And if you start just randomly changing things the only you’re really introducing is risk so we try to avoid that as much as possible. If we were, you know, doing. We have some apps that are more for smaller audience, smaller sub section. And there the technology evolves much faster because there’s not 500,000 people that are expecting it to work a certain way. You know, it’s maybe a couple of dozen people. And so there, even within the organization the technology moves at different speed, and the adaption moves at different speeds.

Carlos: At what point though is it a waste of resources? You know what I mean? Like, and I think, I think we’re talking the same thing. At what point do you say, “We’re not going to migrate. Not only because of risk but we don’t want to go on the newest thing because not only we do not have the resources but it’s pointless.”

Daniel: I would say in an enterprise context it is a waste of resources by default. And the question is when it is not a waste of resources. But good question for Falko is when is the technology change is not always a waste of resources.

Falko: Yeah, I mean for me, it is like talent pool. It’s like if we suddenly don’t find people that uses certain technology. Also, didn’t we bet on something and it died. Like in iOS for example, now we’re getting like out of the JavaScript world. But we’ve picked a framework for doing JSON Serialization and then storage of data. And it was an open source project and it died and now we need to go away from it. We did something similar with ES6 on the JavaScript side where we thought we go with ES6 and then we found out that browsers weren’t ready for it yet so we have to go back. So it’s just like talent pool. Is this still does support a framework? Will there’s still be updates to it? We don’t want to bet on a dead horse. And additionally, I mean we still want to innovate. It’s not like we’re waiting until something is really dead and then jump on the next thing. We are still an innovative startup and we want to build something new. And that’s why our like UI framework for example change more rapidly than like the underlying architecture because users expect a certain look and feel, and certain functionality.

Carlos: And one of the things that you guys are talking about without saying it is that this is also why you went with Angular versus React. What are your thoughts on that?

Falko: Yes, I mean, we’re also taking a look at React and we follow where it goes. But for me at this right now it’s like, it’s a great looking framework. It has a lot of potential. But right now, Facebook is the only, like the only big one who’s betting on it. There are lots of other people obviously using it but even Facebook is not using it for their flagship products. So even they still treated it a little bit as a, like as a baby and they are still developing it and they are still adding things to it. It’s definitely very interesting. But it’s nowhere as stable and as supported as we would like it to be.

Carlos: Alright. Well, I think we got ourselves an interview. We covered all the major points. So there are three last questions that I have for you guys that might help, you know, people in similar situations as you. What advice would you give to your less experienced, younger self? This is for each.

Falko: That’s an interesting question. Definitely, and we talked a little bit about it, like don’t jump on the next shiny thing. It is definitely very compelling especially as an engineer. Like good engineers always strive to build something, learn something new, build something new. And if you see that new thing to jump on it right away and hope it will work out because it looks so great, and then like months later you found out it looked great but it’s not that great if you want to put it in production. So definitely, evaluate something before you, before you really jump on it. And build a prototype and actually see does it work. Will it work out for us? That’s my one advice. Daniel you have another one?

[everybody laughs]

Daniel: I guess this recovering hothead. Uhm, I would tell myself couple of years ago that there are many many opportunities and chances to succeed in engineering and when you’re just getting into it every fight about every technology feels like it’s the most important thing in the world. And after you do a couple of jobs you realized, you know, if the tech stack here doesn’t work out then this isn’t the last. This isn’t the last thing I’ll ever build and this is isn’t the last company I’ll ever work at into. You never lax a little about getting to into fights about technology and stuff like that you know. It constantly evolves and nothing will ever just constantly be the same thing. And to just, you know, learn to surf the wave a little bit.

Carlos: That’s been a great advice. What’s the book would you guys recommend. And you guys can recommend as many books as you want. We’ll have them on the show notes.

Daniel: I listen to an audio book recently called the Astronaut’s Guide to Life on Earth. It’s a book written by this Canadian astronaut that was the head of the ISS. And it’s really just about all the things he learned at NASA of like how to keep cool in like extreme situations, and like how to launch a space mission and how to like, you know, figure out problems the way NASA does it. And a lot of the times when things are exploding here because, you know, someone made a small mistake and you know it happens. I actually, most of the stuffs that I know about handling that I learn from this book which is uhm, and my favorite thing from the book is that it says that, “60% of everything that can go wrong on a space launch is in the first 7 minutes.” And it talks about how to get through those 7 minutes to get through the other 99% of the mission. And it’s a really good read. It teaches you a lot of the things from all walks of life.

Carlos: What is the name of the book again?

Daniel: The Astronaut’s Guide to Life on Earth.

Carlos: Great, perfect. How about you Falko?

Falko: I really like that book also.
[everbody laughs]

Falko: I would definitely recommend reading it.

Carlos: Alright.

Daniel: I hoisted it up on Falko. He loved it.
[everbody laughs]

Carlos: Alright guys. Well, uhm, and now into the last and the most important question. How can people find you guys, to find your work? And also how can they find Jiff and maybe they’re interested in applying or you guys are hiring?

Falko: Sure. So yeah, we are always hiring, so yeah, like you can find Jiff at Jiff.com. That is J-I-F-F-.com. We are not the peanut butter. Uhm, and yeah, you can reach me via email or you can find me on LinkedIn and my email is my first name so, falko@jiff.com.

Daniel: I’m at Jiff so, [laughs] just come find us and come interview and you’ll probably get asked to build Ikea Furniture by me. That’s like by me. [laughs]

Carlos: [laughs] That’s an interesting concept. I never thought of that. I like that one. Good interview.

Daniel: That’s just a surprise.

Carlos: [laughs] Alright gentlemen, well, I want to thank you so much for coming on the show and I look forward to seeing you guys soon.

Falko: Yeah, thank you! Thanks for inviting us.

Daniel: Thanks a lot!

Carlos: Thank you guys!