Saltar al contenido

Interview with a Back End Programmer

30 noviembre, 2017

My name is Andy Isaacson, and I'm a Fullstack engineer at Udacity When I say I'm a Fullstack engineer, it kind of means I do a little bit of the both, right

I kind of do some front end and some back end My background, when I first started out programming, I was doing hardcore computer science And I kind of got interested in thinking about the user more, so looking at aspects of psychology Thinking about how people learn and how people think about the systems that they're using I really was interested in building interfaces that worked well for people

And the more projects that I did, the more I found myself kind of floating to that role within my team, being the guy who put together the system that everything was talking to And actually since coming to Udacity, my sweet spot is really thinking about how to build the systems that power the front ends The front end is cool because it exists right in the moment that someone's using it It's right just on their screen But the back end sort of covers everybody who's using a big system at the same time

And so it's really kind of fun to build the sort of larger piece that's kind of underpinning everything, and thinking about some of the unique problems that come up there One of the backend pieces that I'm working on right now is what's going to be the foundation of the next iteration of the Udacity platform So we're migrating from what was kind of a monolithic application on top of Google app engine into a network of micro services And so, putting all the backend underpinnings in place, before we can even think about building out the interfaces With the backend you really want to take that step back and think critically about is this going to slowly eat up all my memory and destroy my server? Is this going to create a security hole that somebody might be able to use to get information they shouldn't? Or is this going to be a performance bottleneck that'll screw everything else up? And so, yeah, there's a little more kind of structured thinking, I think, that goes into that

If you've got a problem with a frontend system, and you're debugging it in your machine in front of you, you can put a breakpoint in, you can stop it in the middle, you can just kind of poke in and see what's happening And you're going to figure out on a very detailed level what the issues are But with a production system, you can't really just stop it and go with that You want it to keep serving, keep running, keep possibly working for all the other people who are using it And so some of the tools that I'll employ, I mean, first off, there's logs

That's number one, hands down, the way you're going to look at any problem Look back at the logs and see did the usual thing happen,or was an error thrown somewhere along the way? But sometimes the logs look fine And it doesn't help you any All it says is maybe it's really slow, maybe this step took ten minutes and you don't really know why It definitely takes putting on your detective hat sometimes and thinking really carefully about what the code is doing under the hood

It's not like you get direct access all the time Sometimes you have to be a little indirect about poking at it from outside