Joseph Lozano, Software Engineer: Surviving the First 90 Days as a Developer

Joseph Lozano, Software Engineer: Surviving the First 90 Days as a Developer

Advice, tips and resourceful sneak-peeks into the first few months working on a software development team.

Joseph Lozano is a Viking Code School alumnus and Software Engineer working with Connexity, living and working in Southern California.

In this Codecast, Joseph gives great insights into what language stacks he uses most often for company projects, which unforeseen but needed responsibilities he holds as a teammate, why he enjoys working on a team versus going solo, and shares how crucial it is to continue growing your skills as a software engineer – well beyond the job description.

Key Theme » Appreciate Your Team

"It’s really awesome just to have a team around you – going solo is something that’s difficult. I know that because when my coworkers are on vacation, (laughs) I have had to do that for bits at a time...But it’s really all about trying to connect with people. I don’t have the greatest story – I (wasn't) building websites since I was eight and building supercomputers at nine and stuff like that. I just kind of got into it. They saw I am really interested in that, I asked questions...Being really interested in how all the different applications fit together and how they communicate. People like talking about what they do, they like being proud of the work they’ve done: "yeah, I did this." If you ask them about that they’re really happy to tell you and it shows initiative on your part, something I definitely recommend." – Joseph Lozano

Quotes

"I think the most important thing is to try to stay curious and stay (in a state of) learning. Try new things and try different things. You want to be really good at Rails, and you want to be really good at Ruby. You want to be really good at all of that but it’s also really important to have some breadth."

"Reusable stuff is very important. I don’t look at online resources for SQL so much, I’m more dependent on looking at stuff that the people before me have done, and the old queries that are in there and how that’s done. That’s kind of getting a grasp of that. Sometimes just grabbing a marker and going to the whiteboard and trying to figure out what tables you need to join - I’ve done that more than once."

The Codecast

Watch on YouTube

Full Episode » Transcribed

ERIK

Hello everybody, welcome to the Viking Code School Codecast. My name is Erik Trautman, I’m the founder of Viking Code School and the Codecast is our weekly chat with developers and other folks from the technology community to give us insights about what life is like behind the curtain, teach us stuff and generally just get us connected to what the world of technology development is all about.

This week we’re joined by an esteemed alumnus of Viking Code School, Mr. Joseph Lozano who is doing work down in L.A. at the moment. We’re actually going to hear all about it. Joseph is here today to talk to us about what life is like beyond the bootcamp and how to survive your first few months on the job. He’s been doing some really cool stuff I’m excited to hear about. Thank you everyone for joining us, and specifically Joseph thank you so much for taking the time to chat. I really appreciate it.

JOSEPH

Yeah, so I guess I’ll get started with what my company does.

ERIK

Actually before we dive into that, do you mind - I guess if you want to make a quick introduction of your company and then we can start from the beginning and hear a little bit more about how you got there.

JOSEPH

Yeah, I was going to move into that right after, or I guess I could do that first. We do online advertising.

ERIK

What’s the name of your company?

JOSEPH

My company is called Connexity – formerly called Shopzilla which you might have heard of. My part of the company does online advertising, so we’re the ones kind of keeping track of you and following you around and showing you ads for things you’ve already bought. The way that it works, I just want to give a quick rundown of the technology just so you have some context.

When you visit a website – let’s say that website they’re using Google to serve their ads. Google will receive a you visited, some information, an IP address, where you are, if you visited that website before, things like that. They then send off what are called “bid requests” to a bunch of companies including ours who will then decide whether or not they want to show you an ad and bid on that. If we win that bid, then Google hooks us up with that user and we send the ad along.

What I do at our company is I work on the Rails application that our campaign managers, internal people, use to control what ads get shown, what campaigns are running, what sites are turned on and off for those. The admin dashboard for controlling all of that. It’s kind of the brains of the whole operation.

Initial job search process.

I found this company on Hacker News, actually. I finished Viking in October of last year (2015) and looking around doing the normal stuff, sending out cold calls, I saw the Hacker News hiring ad. They do that once a month, it’s definitely a good resource, they do it on the first of the month. It was in the location I wanted in Southern California in Ventura County, so I sent them off an email. We had a quick discussion about the bootcamp especially, since I didn’t have a lot of experience before that, the kinds of things I learned, what I’m good at.

One of the interesting things I credit with actually getting the job is they were showing me an HTML table with some fanciness and colors and bolding here and there, highlighted lines. They asked how I would recreate that, what the box model might look like, basic HTML stuff which I answered to the best of my ability. After that was all done though, from memory, recreated that table in HTML and sent along that file. I feel like they were kind of impressed with that initiative and we wound up having further interviews which I’m sure Erik will ask me about, and then I wound up getting this job.

I got into coding – I have always been a little interested in it from the beginning. I remember I took a class in C in community college probably ten years ago. So that was fun and definitely a different kind of coding than Ruby is. Then I have always been interested in science and technology, and building things and making them work and breaking them apart – especially just websites and programs and little scripts here and there. I found out about Viking and hopped aboard and now I’m doing that and getting paid for it - so that’s good.

ERIK

Huzzah! Let’s start at the end of Viking. I guess take me back to your job search and I guess it doesn’t necessarily have to do with Connexity - I don’t want you to give away their secret sauce or anything.

But, how did you approach the job search and what were those interactions with companies like? What do you feel worked for you, what didn’t work for you? You had mentioned the hustle of going above and beyond after the interview as being something that was helpful, but how did the rest of the process go for you?

JOSEPH

I took kind of a shotgun approach which I guess, is what most people do who don’t already have a lead or something. I was kind of on every website you can name, I was talking to people that I knew, people around. I had some interactions – I don’t know if I’d call them interviews, but phone screens, beforehand and there was one I thought was going to be really close to bringing me onsite or going further into the interview process. But I actually felt that wouldn’t have been a good fit. I would have been the only Rails developer there, which was something that I didn’t want to do, just yet.

I don’t know if I ever want to do that because it’s really awesome just to have a team around you – going solo is something that’s difficult. I know that because my when my coworkers are on vacation, (laughs) I have had to do that for bits at a time.

But it’s really all about trying to connect with people. I don’t have the greatest story, I’m not building websites since I was eight and building supercomputers at nine and stuff like that – I just kind of got into it. They saw I am really interested in that, I asked questions, especially I kind of went into our platform, our architecture and kind of how that stuff works. Being really interested in that and how all the different applications fit together and how they communicate. Kind of asking questions and being really curious. People like talking about what they do, they like being proud of the work they’ve done: "yeah, I did this." If you ask them about that they’re really happy to tell you and it shows initiative on your part, something I definitely recommend.

ERIK

If anybody has any questions about the interview process you’re definitely welcome to ask, again via the Q&A app or right here. I’m going to move on to sort of the first days, I just wanted to make sure we could pause for a second if anyone has any questions.

JOSEPH

Maybe I will go into kind of the basics of how that works. Like I said I reached out on Hacker News, I left an email address. We had a Skype screen and then they brought me onsite. I had an interview with the people who developed the application and were kind of moving onto other things, with the people who were still developing it, with the manager of that local office and then they I guess liked me enough to ask me to come down to their headquarters in L.A. so I went down there.

It was actually pretty interesting because I had a technical interview with somebody who didn’t know Ruby, he was a Java developer, I think. He's like a director or executive now, but he didn’t have Ruby experience so we kind of had to pseudocode our whiteboarding problems. He wouldn’t let me take advantages of some of niceties that Ruby has, like some of the iterators and things like that. I had to do things the old-fashioned way.

That’s kind of interesting, but really it is kind of just a basic whiteboarding problem. I don’t remember exactly what it was, but along the lines of "reverse the string" or "find an anagram in a dictionary of words." Kind of the basic stuff that you can see in any kind of interview question book.

PARTICIPANT

Did you do any live coding whenever they brought you in, or it was mostly just algorithm questions?

JOSEPH

No it was just - it was all on the whiteboard, I didn’t have to actually do on a keyboard. The kind of questions that were asked were just pseudocode algorithm stuff and also actually a lot of SQL. I was grilled on SQL pretty good. I do that a lot now, that’s kind of like my non-Rails responsibilities. There are some pretty mean queries I’ve had to write.

ERIK

Cool. What exactly were you hired to do, so like what was your job description basically? Then what was that very first week like when you sat down at this seat and it was go time and you had to figure everything out?

First week on the job.

JOSEPH

Like I said I was hired to work on this Rails application that is used to control all the different campaigns and things like that. It was legacy, it’s always legacy, it was on the thick Rails 3.0 when we started it and we’ve recently upgraded to 3.2 – which was a pain. That’s when I brought in the asset pipeline which we still don’t have, because it won’t work. (Laughs)

So I was hired to work on that application. My first week consisted of basically the manager sitting me down and trying to walk me through the whole architecture of everything that wasn’t the Rails application. So our campaign manager that basically decides whether or not to bid and controls the state of things, our actual bidder who does the bidding and communicates with the Google or Yahoo, whatever ad API’s. All the different kind of file storage we have for looking things up later, and then how they all talk to each other. It was a whirlwind! We did a couple of hours long sessions on that and it’s still something I really can’t wrap my head around. There’s probably a dozen different applications that all talk to each other and are all critically important to what we do.

That was the first few days, and at the same time trying to work my way in adding little features here and there. I don’t know how many specifics online I’m allowed to talk about, but – really little stuff. So if we have a table for example with data, just adding a column to that just to make things easier. Or doing little things like that, changing the way the page works. So a little later on we’ve got more aggressive with what we’re doing and the changes we’re making, such as the Rails upgrade which that was a lot of fun and it didn’t work the first time.

ERIK

(Laughs) Did you have to revert?

JOSEPH

Yep. So we had to do that kind of off hours so we all got up online at nine o’clock at night, and tried it and it didn’t stick so we had to revert at around eleven when we gave up and then we tried it again the next day, we changed some little things, some conflicts here and there and it wound up working right away the next day.

Another kind of interesting thing about the Rails application I work on is that it actually doesn’t have Active Record. We use DataMapper which is not maintained anymore. So that’s kind of another whole challenge in itself.

It has some different syntax and also different behaviors, it does different things. I know a lot of our problems came when we upgraded that, it didn’t go along with Rails. It didn’t behave the way we expected it to and that was kind of a combination of the legacy code being inefficient and DataMapper wanting to take advantage of that inefficiency and do things even more inefficiently.

All those different challenges that you’re not really prepared for – but you should definitely try to learn a little bit about DataMapper. You might not have to use it but just having experience with another ORM tool could ... if you need it, you need it. Not everything is done the way Active Record does it. I don’t even remember Active Record anymore to be honest, it’s unfortunate.

ERIK

As long as you know SQL you can do anything.

JOSEPH

That’s true - it true! Learn your SQL, you can anything in SQL it just might take a few joins. (Laughs) But yeah, you can do it.

ERIK

So how do you get up to speed with legacy code base?

Dealing with legacy code.

JOSEPH

There’s actually a lot of different tricks that you can do - we’re trying to Pry into DataMapper and see what it’s doing. Actually one of the things we had to do was "pry" into DataMapper itself. So we find wherever RVM installed the gem and Pry it into that and jumped around and try to follow exactly what steps it was taking, what method was being called and which method. I like to call it "following the code," trying to go line by line and seeing where things go. That’s kind of where you see when things get stuck in loops that take 10,000 iterations. That’s where you see all those inefficiencies - it’s unfortunate, but just kind of having to go line by line with Pry. Pry is like the best thing ever.

That’s kind of one way. The other way is just an experience thing, it’s doing it day in and day out and it takes a little while. You kind of get used to what exactly is going on and where everything is. Our name spacing is absolutely terrible – I want to tell you that. We have the same name spaces but in two different places, so eventually, it just becomes a matter of memory of trying to find out where this particular method is, or where this controller is.

There’s a neat little trick that actually I learned the first day – which I’ll just type it into the chat, if I can figure that out. If you do Rails, and this is something I didn’t learn at Viking, so maybe you guys can take it.

ERIK

You will now – if you're watching the Codecast!

JOSEPH

I think I got that right. I put that in the chat.

Rails.application.routes.recognize_path 'some/path'

...then you you put in your path. That will basically run it through the router and it will return to you what method and what controller is being called, and what parameters. That’s actually really helpful when you have a route. You’re on your page and you want to say "what controller?" I want to fix this page, what controller do I need to go into? Sometimes it’s not named very well and it’s kind of hard to figure it out. You can just throw it into that and I don’t know exactly how it works internally, but it will spit out the controller that it uses and the method and any parameters along with it – so that’s a neat little trick.

ERIK

That’s actually a great little trick - yeah.

JOSEPH

A lot of it is just figuring out what exactly is happening with the code and trying to make it better, writing tests is very important. When I started our test suite not only didn’t pass – it didn’t work. So we spent a good couple, maybe a week, trying to get that going and getting that all setup. Now we have maybe, five or six percent coverage but all of the tests we have are green and the test suite works. Now we can make changes without having to worry about things breaking down the line – at least where there’s coverage.

PARTICIPANT

I was wondering, how big of a consideration is efficiency with your code? I know with high level languages with Ruby and stuff it’s not as big of a deal as C and what not. I’m still a beginner mostly, but whenever I code I kind of just do it and I don’t think about efficiency or data structures or whatever.

Efficiency considerations in code structure.

PARTICIPANT

Yeah - so the approach that I take and I think most people take is: getting it working first. Once it’s working then you could worry about optimizing it.

On the other hand, you want to be careful because you don’t want to tell your manager: "hey it’s working" and then all of a sudden now you have to move onto the other thing and it’s left inefficient. It’s definitely a consideration, it’s something that we think about, but there’s always trade-offs. When money is on the line and the company is spending dollars for having you work you can’t make something one percent more efficient in a day. It’s not sustainable for the company, so it’s definitely kind of a trade-off.

There are different tricks you’ll have to pick up. So Active Record is kind of notorious for lazy loading. So when you loop through your stuff in your view you’ll get your N+1 query loading things one at a time. Try to be careful of stuff like that, and load everything you need all at once in your controller, and there are different tricks you can look up for that.

It’s kind of the usual things. That’s a big one that you want to watch out for is your N+1 queries. Because that’s more than anything else what’s going to - at least in my application, in our application, is what’s going to bring it to a grinding halt.

PARTICIPANT

So kind of just things you remember you have to watch out for and you just watch out for them each go around?

JOSEPH

Yeah, and good coding practices will get rid of that. Not having "model logic" in your view, for example, will solve that problem.

PARTICIPANT

True. Cool, okay thanks.

ERIK

So how about your team? What’s the size and composition of the team that you joined and then what’s it like actually being sort of like being the new guy stepping into a team?

Team acclimation as a new developer.

JOSEPH My team is fairly small, we have I guess two and a half developers. One of them only works with us part time, so he’s the "half." There’s another guy who is the Senior Developer and I’m the Junior. We have a QA person and then "half" a Manager I guess – because he’s also doing other things half the time, but he’s also kind of the Business guy to make sure that, "yeah this is good." Then we have our Project Manager and then our Project Owner. So, it’s weird, because Product Owner – it’s not like working at a consultancy where you’re building an application for a client. We’re building it for ourselves. I guess she’s ... I don't’ want to say high up the food chain, but high enough up the food chain to where she’s the bridge between us and the people that actually use the application. So big features especially, will kind of go through her. We’ll demo them for her and see if she has feedback on that. Little stuff, our manager just looks at and then we also have a QA person who will go through and make sure we didn’t break anything.

Team division of responsibilities.

ERIK

So what was it like, how did you actually get up to speed with what your role was. Actually was is essentially your version - what are you working on versus what is your Senior Developer working on? How do you guys divide responsibilities?

JOSEPH

We pull a story, and we work on it. We don’t pair except when there’s not a whole lot to do or we don’t have anything that’s ready to go. So we kind of have our backlog of stories, but a lot of them are not filled out all the way.

If things kind of get backed up, we’ll pair on something and kind of work on it together to slow things down, I guess. It’s also a good opportunity for me to learn from him. One thing he’s really good at is seeing all the different patterns that you could use. So I can't ever name them off the top of my head now but I remember in the JavaScript, especially, there’s all these different patterns you could use and how to solve a problem. He’s excellent – we’ll use a "decorator pattern" for this and we'll build our decorators and things like that. Whereas I know how to code and I know how to do this but what I lack is that kind of experience to know exactly what to do to solve a problem, in a non-brute force, ugly kind of way.

He’s actually also pretty new as well. So it’s interesting because we’re kind of learning the application together and how the business side of it works, too. It’s not like there’s a big distinction between us as senior and junior in terms of workload. He tends to take the bigger stuff, the stuff that will touch more things or require more complete rewrite. He’ll take some of that stuff and I’ll work on the more medium or smaller sized things. Other than that, we grab a story and we work on it. We look at each other for code review, then we send it off to our QA to make sure everything’s working.

ERIK

And how does that whole code review process work?

JOSEPH

It really is just kind of a second set of eyes, it’s making sure did you think about how changing this variable will affect this other part of the controller or something.

Brief peek into a code review session.

ERIK

But actually explicitly, do you sit in a room together and look at a projector, or how does it work?

JOSEPH

We just send a link to the full request and we’ll look at it when we have time. (Laughs) It’s very informal. Then, we’ll just comment on the pull request or send other comments in Slack, saying "yeah, to-do." But really it’s sending a link to the full request, nothing fancy there.

PARTICIPANT

That’s another thing on the note of informality, I guess. You kind of dig the smaller size of the company or the next time you go to get hired at a different place are you going to choose a bigger company. Or, do you prefer the smaller?

Small development teams versus larger ones.

JOSEPH

I can’t really speak as to what it’s like at a big company – we actually are a big company, it’s just a small team. So I kind of have all of the perks of a bigger company as far as having things around. If I go to HQ, they have catered food and all this stuff you can’t really do in offices of four or five people.

I think as a whole, the company worldwide – there’s probably 500 or maybe 600 now. Then in our division there’s a couple dozen maybe? Then on my team there’s just the four or five of us, depending on how you count it. I like the freedom of being in a smaller team. I like not having to be just a "cog" but also I have my opinions as to how things should look. When I say, "hey, we should design it so it looks like this," they’ll be like "okay, that sounds good." Rather than having this is what our design team says exactly what it should look like and make it look exactly like that.

I don’t know if that’s how it works at a big company, I imagine that’s how it works but we have pretty free rein to design the things ourselves. It’s also kind of a double-edged sword, because we’re developers of the application we’re not users, and it’s a pretty complicated one. So we don’t exactly know how this - or if a feature will be used. We are kind of trusting our Product Manager and Owner to put stuff at the top of the queue that’s going to be used, but there’s trade-offs. I like working at a small company, I’d probably stay at a smaller-sized one, or a medium-sized one.

I don’t know if that answers your question at all.

PARTICIPANT

Yeah, thanks.

ERIK

How about specific projects. Maybe what’s an example of something that you work on maybe where the name is changed to protect the innocent, that kind of gives us a sense of what is the technical complexity of the kinds of API’s you’re working with and stuff like that?

One technically complex project example.

JOSEPH

I’m trying to think of an actual project or feature. Here’s one, I didn’t work so, so much on this, it was more of the senior developer.

One of the things we did recently was we changed the campaign – the alerting page, for example. In our company, you have account managers and campaign managers who are actually managing our ad campaigns and we have different alerts – which are basically SQL queries to find out if a campaign is at a certain state.

For example, if you’re going to run an ad through Google it has to be approved through Google. So if you have a campaign that’s live and running but the creative, the ad, isn’t approved they should know about that. There’s some SQL there to check on the approval status and the campaign, and then the manager who runs that campaign and bringing that altogether and making a page to display that when you log in as a campaign manager, to see all of those alerts. That was kind of a bigger feature that we worked on. Now when they login they see these are all my campaigns that have various things, maybe not wrong, but things I should know about. A lot of those are written in raw SQL, they are just too complicated to do in an ORM.

Another thing that we’re working on right now is trying to immigrate mobile applications – ads on mobile applications into our architecture. There are some very unique problems that come along with that I’m not working on, but I’m the one trying to make everything work in the user interface. Having to coordinate with the other teams who are working on those problems and making sure the interface is going to talk to those applications in the correct way. Which fortunately since everything goes through a middle, usually Redis, I just make sure it writes this to Redis. That’s all I have to worry about.

ERIK

So, you've talked a lot about SQL ...

JOSEPH

Yeah, SQL has been the most important thing!

ERIK

...how have you upped your game in SQL? Obviously we cover that during the course pretty heavily, but then you probably had to go even deeper I’m sure, afterwards. How have you turned your brain into full-on SQL mode?

What have been the best resources and how does that work?

Tips for working with SQL in-depth.

JOSEPH

The real trick to SQL is trying to write a query you can reuse and just change a little bit. (Laughs) I've spent hours trying to build just the right query and then...Let me back up a bit and say why I’m writing so much SQL – because it’s not entirely for the Rails application.

Our transactions are stored in a hadoop cluster and you don’t need to know what that is and I don’t know entirely for sure, myself.

But that’s accessed through an interface called Hive which will take a SQL command and convert it into something that can access that. So it’s not really SQL in a sense it’s not really querying a relational database – but it looks like SQL and it talks like SQL and it quacks like SQL.

For example, if one of our clients wants to have a special request, say: "I want to know how many impressions, how many ads were served to people grouped by zip code", that’s a more basic one. I hop in and write yadda-yadda, "find all, group by, where this is at" and then I have that. Later on, when they come to me and say: "now the client wants things grouped by metro code", for example. If you write the SQL in such a way that you could just replace zip code with metro code, this will take a tenth of the time, if even that.

Reusable stuff is very important. I don’t look at online resources for SQL so much, I’m more dependent on looking at stuff that the people before me have done, and the old queries that are in there and how that’s done. That’s kind of getting a grasp of that. Sometimes just grabbing a marker and going to the white board and trying to figure out what tables you need to join - I’ve done that more than once.

Then sometimes it’s just trying things over and over again. I had to have one query I think with three joins and it didn’t work. I changed them all for left joins and it worked! (Laughs) Sometimes it’s just trial and error and you’ll get there. My manager knows somebody who used to work at Oracle and was one of the designers of SQL and said "nobody understands joins, don’t worry about it."

ERIK

That will make a lot of people feel good.

JOSEPH

(Laughs) Yeah, don’t worry about the specific left right join, a lot of the stuff you can look up when you need it, and it’s really hard to wrap your head around but knowing that you need to use it, I need a join of some kind and I still don’t know why it didn’t work with the inner join. I had it working, so I don’t really care. I moved on, as it were.

Cell phone ring

ERIK

Do you mind talking about what you’re doing now – when you were able to address that? What your role is with being "on-call?

JOSEPH

That was ESPN ... not being on-call.

ERIK

(Laughs) I was hoping that was a creative pager notification.

Other unique responsibilities as a developer.

JOSEPH

No, no, that was definitely ESPN – something about the Lakers.

One of the other responsibilities I have is on-call: I mentioned we have all these different applications, only one of which is Rails. They all could fail in all sorts of different ways, and they all could go into warding states in all sorts of different ways.

So we have a software as a service called LogicMonitor which monitors all that stuff and will alert me, and here comes one right now, fortunately I can ignore that one. But I do have to acknowledge it!

So here’s a live demo of what I do - I get an alert, it says "the up time on this application is not what it should be", but I know somebody is in our data center moving hard drives around so I will acknowledge that – and ignore it, because I can. So part of my responsibility, it’s a weekly thing is to just kind of be on top that. If something happens with one of our applications the alert will go to me first as the on-call. Then I determine if it needs escalation, or not. That’s something, I’m dealing with a lot of applications that I don’t know, that I’ve never looked at, I’ve never even read one line of its code base. I have to determine: is this important, or not? Does this need escalation, or can I just acknowledge it and let it go?

This is probably my third time doing this. One of the things we use at our company that makes it really helpful is a wiki. We use an Atlassian wiki product.

So if I have an alert that I don’t know what to do with and it requires a lot of work to figure out what happened, I’ll write that up in the wiki or somebody else who is on-call will write that up. Later on when it comes to me, I search for that, this alert, this warning and I see it and it says do this, "restart this application" and everything will be okay. I restart it and everything’s okay. That’s more of an outside teamwork kind of thing, having a common wiki, common knowledge source that we could use for the more business-y, more domain specific kind of knowledge.

ERIK

Remind me, what’s the actual service that provides that, is that a pager?

JOSEPH

It’s called LogicMonitor, it just emails me or sends me a text or calls me, if it’s really important.

ERIK

Got it. So does anyone have any questions here?

PARTICIPANT

I actually had a question - it sounds like you’re doing a lot of back end stuff for your role. After VCS or even during, did you know you were leaning towards the back end as opposed to the front end?

JOSEPH

Oh yeah, I hate JavaScript. (Laughs) I hate everything that has to do with JavaScript and I don’t want to have to look at it ever again - I have to but, oh yeah. I have never really liked the design features, making things look just right and having things fit and making sure everything lines up, I have never really liked that. I’m more like the logic (person) and the making things work. So I kind of knew that I wanted to do that and I avoided looking at ... there’s a lot of front end positions, and I mostly avoided that just because I didn’t want to.

PARTICIPANT

Cool, thanks. I guess as a follow up: having delved that deep into the back end and SQL, have you considered maybe data science applications or roles even, in the future maybe?

JOSEPH

Actually the person who wrote the majority of our Rails application is now a data scientist. So that’s a thing. I don’t know, I don’t know how I feel about statistics and all that. Data science is definitely a big part of what we do, just because we have so many users and there’s a lot of data that has to be dealt with. I’m more right now trying to get the Rails stuff done – and Elixir, I'm also trying to do Elixir. So I’m not really focused on that ... Although I could be in a few years, you know, who knows?

PARTICIPANT

Cool, thanks.

ERIK

Is there any other questions - feel free to unmute here if you’re inside and if you’re not, like I said you can use the Q&A app.

JOSEPH

No, nothing in the Q&A app.

ERIK

How about coming from your perspective looking back at all these fine folks – some of whom have just finished some of whom have yet to start and others who are somewhere in the middle, what is your advice?

Being on the other side of the curtain now, having officially gotten there, getting paid to learn and all that - what do you think looking back?

JOSEPH

I don’t know, that’s a good question and that’s a difficult one to answer. Do your homework, eat your vegetables!

Final tips for evolving as a new developer.

There’s the basic stuff. I think the most important thing is to try to stay curious and stay (in a state of) learning. Try new things and try different things. You want to be really good at Rails, and you want to be really good at Ruby. You want to be really good at all of that but it’s also really important to have some breadth. If somebody asks you a question about Python for example, you want to be able to say something. If somebody asks you about do you have an opinion on MySQL versus something Postgres, you want to be able to kind of talk about that. So, go in-depth for sure, but don’t be afraid of having a little bit of breadth, learning about different kinds of ways you persist. Why should I put this in PostScript or should I put this in Redis? What if you’ve never used Redis before - how do you even answer that question?

I don’t know - I can’t even remember if you guys go through Redis at all, I don’t think so.

ERIK

Some students have certainly looked into it as part of some of the projects.

JOSEPH

Definitely, build a project with Redis. Build a little pop up thing and send a message and then receive that message back. Action Cable is out now, or at least the release candidate is. Definitely try that and be trying new things and different things and get that breadth.

ERIK

Cool. If there are no last questions I guess that gets to a pretty good point here – it’s a good thing to take away. "Eat your vegetables, learn your SQL and play with lots of things."

Morgan, did you have anything left here to ask?

PARTICIPANT

No that was it for me.

ERIK

Alright. I think that takes us to the end, so basically on behalf of everyone here thank you Joseph for chatting with us and giving us the benefit of your experience, so far. For everyone who is joining thanks a lot for taking the time to chat! All of us, everyone out there I hope you have found this valuable. Join us again next week on the Codecast and Joseph, good luck fighting those bugs and staying on-call!

JOSEPH

Mm-hmm. Not next week. (Laughs)

ERIK

Thanks Joseph.

PARTICIPANT

Thanks so much Joseph.

ERIK

Have a good night, cheers!

From n00b to ninja, we'll help you to become a developer
Subscribe to get expert guidance on learning, building, and getting hired delivered right to your inbox each week.


We guarantee your privacy 100%. Your information will not be shared.
NOTE: Comments are disabled outside of the "https://www.vikingcodeschool.com" production environment to prevent Disqus from assigning the wrong URL and forcing us to map away from `localhost:3000` each time.