In this episode of the NerdCast Brian Rowe interviews Nerdery Java developer Sarah Olson and he asks the all important questions, “What would you say ya do here?”. They talk Java, new frameworks, the pending release of Java 8 and much more.
Host: Brian Rowe (UX Manager)
Guests: Sarah Olson (Software Developer)
Listen Now: Running Time: 0:21:25 / Subscribe on iTunes
S1 00:00 This is the NerdCast, building upon great solutions with Java. I’m Brian Rowe, UX manager here at the Nerdery. And today, I’ll be having a fantastic conversation with one of our Java developer extraordinaire, Sarah Olson. She gives us a great rundown on where she comes from, how she got into Java, what she does here at the Nerdery. She touches on some interesting technologies and assistance in the Java world, like Play, Scala. We talk a little functional programming and what’s on the horizon, potentially with Java 8. Stay tuned. It’ll be fantastic. You don’t want to miss it. This episode is brought to you by the Nerdery, a developer driven, interactive production company that specializes in custom software development and user experience design. It’s been voted by its staff onto numerous top workplace lists. And they have offices in Minneapolis, Chicago, and Kansas City. Developers, designers, and other aspiring nerds can learn about joining our team online at nerdery.com/jobs.
S1 01:01 Thank you, everybody for joining us here at the Nerdery today. I’m Brian Rowe. I am UX manager. I’ve served several purposes around the Nerdery in my time. But today, I have the lovely pleasure of having a conversation with Miss Sarah Olson, one of our esteemed Java developers here at the Nerdery. So Sarah, thank you very much for joining us today.
S2 01:19 Thank you.
S1 01:20 I wanted to have this conversation because– Well, in part, I know our audience is going to be very interested in what our Java devs do here. But also having some of that background myself, I’ve been curious too as to the adventure a Java dev takes once they joined the Nerdery. Just to get things rolling, what I’d love to hear is a little bit about what you actually do here day to day.
S2 01:46 Day to day, we’re typically working on– With Java, we’re working with larger clients, usually. We’re working with clients that are more typically enterprise or corporate level. Some of the larger clients out there are the ones that are using Java for their enterprise. It runs the gamut from small web apps to really large web apps. Sometimes we’re doing more of a support-based project, where we’re bringing in existing code. Other times, we’re creating something from scratch. Sometimes we get to use some of the newer technologies. Play and Scala is one of those latest ones I was working with. But a lot of times, the clients are the ones who are dictating the technologies we’re using, so a lot of it depends on our clients. And we can jump in to learn technologies that we don’t necessarily know right off the bat. So being able to pick up new technologies is pretty critical for our Java devs.
S1 02:59 Absolutely. Obviously, some of that– Even if you’re doing more open-ended work, creating this thing from scratch – like you’ve said – there’s probably within a larger enterprise client plenty of other systems that they need these things to hook into that probably help dictate some of that stuff that you need to do. Cool, so you mentioned a couple of things, Play and Scala. So for those of us who don’t know what those are.
S2 03:22 Play is a framework that is good for REST-based web applications. So it’s a way of implementing an application more as a rapid development framework, where you can get things up and running really quickly. Scala is a language that runs in the JVM. So it’s like Java, but more on the functional programming side.
S1 03:54 Interesting.
S2 03:55 So, it’s a mix of the two.
S1 03:57 And for the audience, REST is?
S2 04:01 REST is just a format for web applications to follow that is a best practice for APIs, which we deal with a lot here – either building an API or working with an API.
S1 04:17 It’s a little bit more semantic, right?
S2 04:19 Yeah.
S1 04:19 I request a thing, and a web browser gives me back something – human, readable, understandable.
S2 04:24 Right, it works really well with the HTTP protocol. It’s meant to really flow with that well.
S1 04:31 And then – in terms of frameworks – what it sounds like too, for those who do have more of a Java background– I had some familiarity with things like Java Struts and Struts 2. It would be something like that – in this case, Play – to allow me to basically govern what happens, step by step in a web application. And when you say web apps– just because, again, I’m curious. This is different than what we usually do. We’re not talking about necessarily building a brochure website. These actually might be what? Internal, real, full-blown business applications that just happen to be on a website?
S2 05:07 Yeah. Typically, if we’re building a brochure site, we’re going to use different technology – like PHP, or something like that. So if we’re doing Java, it’s usually because the client is already using Java and wants to continue. Usually, they’re more complex applications. And they’re connecting with multiple– other applications or systems, or an ESP, or something along that line where it makes sense to have a more robust application.
S1 05:37 Absolutely. Do you do more of the upfront work? That means anything that might be in the browser that a user is actually going to see day-to-day when they use it? Or do you do more of the back-end connections and hookups?
S2 05:52 We’re definitely more on the back-end. There is usually some integration of the front-end work that we have usually another developer do. And then, we usually come in and integrate the two. So we put in our hooks for the back-end into those files that another developer has made for us.
S1 06:15 Does this require an awful lot of back and forth with people who might be IT resources at one of your enterprise clients as well?
S2 06:22 Yeah. With the Java, we’re definitely working a lot with other developers. Whereas, the projects I’ve done in other technologies like iOS and WordPress, we’re working more with either marketing or even the end client. So it’s definitely a different client relationship with the Java side.
S1 06:44 Now, you mentioned a couple of different things that you’ve done. So how, why Java? How did you end up here doing that at the Nerdery?
S2 06:53 I had experience with Java for 13 years, so I came in as a Java dev. Because we are so good here at training– in cross-training, I’ve picked up iOS and I’ve picked up WordPress while I’ve been here. But my background for the last 13 years has been Java.
S1 07:19 What are some of the key challenges that you see or face routinely now? Some of those big hurdles that as a Java developer here at the Nerdery, dealing with these kinds of clients as you described, what’s really the struggle or the interesting challenge?
S2 07:38 Typically, our challenges are working with existing technology. We don’t always get a lot of documentation on what that technology is doing or the business logic that’s being used. A lot of times, the– sometimes we have clients who are unhappy with the current system they have. And it’s working with them – especially with UX – to figure out what they actually do need. And then, trying to either work with their existing code to make it do that, or to start from scratch and rebuild in certain cases.
S2 08:17 A lot of times, we do have existing code. That makes it a little bit more complex, because we’re trying to fit things together that don’t necessarily want to go together. When we’re working with other clients, we have a little bit more freedom to do what we want when we’re working with other developers or even other vendors that this client might have. It gets to be a lot of requirements gathering, and everyone has to agree on it. And it takes longer to come to that agreement, because there are so many parties involved and they all are very technical. So it definitely requires a lot of documentation and discovery, a lot of meetings, to try and figure things out and all come to that agreement.
S1 09:14 Obviously, conversations, meetings – either face-to-face, remote, what have you. How does someone like yourself here manage to broker a lot of those interesting relationships and negotiate some of those tradeoffs? Because it sounds like, as you describe it, there are [chuckles] a lot of parties involved that might not all have the same vision in mind. But to make any of this work together, you’re going to have to come to some kind of unified idea.
S2 09:40 Going into things with a mindset of, ‘We need to do what’s best for the client or for the project as a whole.’ It gets your focus in the right spot. While we might have our own internal project that might be successful, if the entire project is not successful for the client, they’re not going to be happy. So we need to look beyond our own requirements that we have, and see the project as a big picture deal. What is going to make the client happy in the end is really what we need to be striving for. So a lot of those discovery meetings and other things are really critical for that to say, ‘I could just gather my requirements for this tiny piece that we’re doing, but that’s not going to– we’re not going to have insight into whether this whole project’s going to be successful if we do that.’ So I think that reaching beyond what we’re exactly going to be doing, and to see the whole– what is the client trying to do with this project?, really helps ensure the success of the project as a whole.
S1 10:57 Fantastic. I would assume, but maybe I should ask instead. A lot of years of solid Java development experience in your past before you joined us here at the Nerdery. Was a lot of that time spent doing something very similar? Meaning, being able to reach out and form that broader, bigger picture of what’s really required and to make something successful.
S2 11:21 I come from a background mostly working in the corporate arena. We’ve had to work with overseas companies, a lot of companies are doing outsourcing as a supplement to a lot of the local development they’re doing. There’s a lot of back and forth with that. So that helped prepare me for a lot of this work, because we’re working with other developers – especially in other countries with other time zones.
S1 11:55 Language constraints sometimes.
S2 11:57 Definitely language constraints. So, I think that a lot of that really worked in my favor coming here.
S1 12:03 Absolutely. Well, I’m sure too, even just being able to communicate those requirements back out to other people that you partnered with would be very detailed, I’m sure–
S1 12:11 –to avoid some of those missteps when, ‘Hey, we need this team in the Philippines to build this. They’re going to be doing it overnight while we’re working on something else.’ And trying to share what exactly you need to have happen.
S2 12:21 We’ve had clients come to us that are outsourcing a lot of their work. So we’re working with those parties here as well, or bringing in code from parties.
S1 12:31 Since you get to see it from the inside, what do you think is one of those attracting factors for an organization like that to come to us with that help? Hey, if they’ve got a ton of offshore developers, what do we bring to the table? What do you bring to the table that’s different?
S2 12:47 For the most part, the things that I’ve seen– the issues that have arisen are a lack of architecture in future consideration for where the project wants to go eventually. A lot of the projects that we’ve taken in have really have not laid the groundwork for good architecture, so they end up with performance concerns, or they can’t modify their code for new requirements. It works the way it does, but it won’t support any future work that they want to do. One of the things we do, especially with UX, is where do you want to go with this? And let’s build a strong foundation so that it can grow with you, instead of having to scrap it and rewrite a whole new app every time you want to add some additional functionality.
S1 13:38 So we’re talking about things where… again, back to how you phrased it, “this bigger picture, broader picture.” I’m trying to craft something here at the Nerdery for these people that ideally is extensible and maintainable. Someone else down the road – years on, perhaps – is going to inherit this thing. There’s going to be different needs, and they can still take this foundation that we’ve built and leverage it going forward.
S2 14:02 Yeah, and a lot of– some of the key things that we look for in Java and other object-oriented frameworks or any frameworks really is reusability. Not repeating yourself, so you have the same chunk of code in multiple places and things like that. Those are the main things that we see coming in, is that these things weren’t implemented. So when you make a change, you have to make it in ten different places. Or you make one change and it breaks ten different things, and there’s no unit test to back it up. There’s no documentation on it. So that’s stuff that we all very much focus on here, is to make sure that at the end of it, the client has unit tests. They have documentation. They have QA. They know that these processes were followed, and they have outputs from it that will help them keep going in the future, that they can run these tests and our code still works. When they make a change, it’s there to help ensure that the change didn’t break anything else.
S1 15:06 Fantastic. So, they even inherit – after you’re done with the project – potentially, something like a road map so they can do regression testing in the future and not have to rethink and rewrite all of that?
S2 15:16 Yes.
S1 15:17 Fantastic. You also mentioned one of my favorite terms, which is OOAD – object-oriented analysis and design.
S1 15:24 Java, of course, very much at its core, one of the earlier robust object-oriented languages. I’m thinking– since we’re highlighting and featuring Java here, that – to me – seems like a language and a framework that gives one like yourself opportunity to really think through that more of an object-oriented design mindset as well. Is that true here at the Nerdery?
S2 15:50 Yeah, definitely.
S1 15:53 Do get to actually participate in activities? I’m thinking, when you mentioned earlier, opportunities to create something from scratch. Do you actually get to architect more or less at the whiteboard wall or on paper that object model of how you’re going to structure your code, and then develop? Or is that not quite the way?
S2 16:10 That’s definitely the way I work. I came from a more database background. When I architect, it’s definitely starting from the data model, and then building from that. So, I’m definitely in that camp. I would assume that most Java devs are also taught to architect that way, but I can’t say for everybody else. But we’re definitely architecting a lot of applications here, or at least a portion of an application. So there’s a lot of opportunity for that kind of work, which I really enjoy.
S1 16:50 I can see why. It’s fascinating to be able to think through that. And it’s interesting that– some of these other languages that we touch here at the Nerdery so often are starting to, or are have already – for a number of years, now – inherited a lot of those same principles too. I’m thinking even some of our PHP people, who are now thinking more like what I would imagine a Java dev would be thinking in terms of object-oriented.
S2 17:13 And then, we have the other way around too, where Java is getting more functional with languages like Scala. So, we’re coming both ways [chuckles]. Other languages are getting more OO, and we’re getting a little bit more functional.
S1 17:28 Obviously, OO – object oriented. We’re trying to model– represent essentially things that I can interface with in the real world, more or less. I can capture that thing. I can encapsulate some information about its state and its behavior, and bundle it all up into an object. I can inherit from that – children – and have that percolate through my design, and really leverage it in that way. That, I get. Functional, I don’t. So please–
S1 17:56 –help me get with it on functional programming.
S2 18:01 Functional is more the other side of the coin, where you just– you don’t really encapsulate an object so much as do things in order, ‘We’re going to run this, and we’re going to run this, and then we’re going to run this.’
S1 18:18 So much more procedural, and almost like scripted languages in that way?
S2 18:19 Yes.
S1 18:21 But that can’t be the sole benefit of it though. It seems like functional programming is more– I don’t know, tricky than that.
S2 18:28 I haven’t thought of how to explain it in a non-techie way yet.
S2 18:40 But definitely, trying to bridge the gap between the two, where it’s less strict on the whole object design, and trying to reduce the redundancy in the code. If you’ve done any Java, you know that there’s a lot of boilerplate code. Scala is trying to get rid of that to save time for the developer. So when it compiles, it’s actually compiling to Java. But it’s taking out all that stuff that you don’t really need to worry about as a Java dev, and just focusing on what you actually need to put in the code to make it do what you want. So it’s following that “don’t repeat yourself” principle, where– let’s take out the public-class statement, because that’s going to be in most Java files anyway. And just– not necessarily using that as an example of Scala, but an example of code that’s going to be reused throughout a class that the class should know about already.
S1 19:56 Got you. It seems like when I’m thinking functional now in Java, I’m thinking more back to that behavior again. I’m worrying less about some of the hang-ups and some of the conventions of the language itself, and I’m getting back to, What do I actually need this to do? What does it need to know about itself? Or what does it need to know about some other player in the system somewhere? And that’s it. That’s where my thinking goes. Scala helps me build up a skeleton–
S2 20:24 Right.
S1 20:24 –behind the scenes, as I go. Fascinating. Well, that brings us pretty much to the close of our time. Sarah, this has been really, really lovely. I really appreciate talking to you. It’s been a lot of fun, and happily for me – and hopefully for our audience – really informative as well. So with that, I thank you for your time, and it’s a pleasure getting to work with you here at the Nerdery too.
S2 20:43 You too.
S1 20:44 All right. With that, I’ll bid everyone a good day.
Podcast: Play in new window