Nick Sarlo is a Software Developer and a Viking Code School alumnus helping build with uShip in Austin, TX.
In this Codecast, Nick breaks down vital "must-do's" as a newly hired software engineer to protect your own and collective team's project goals, how work/life balance pans out for developers in great companies, shares his view on the agile process, and gives props to the benefit of Scrum Masters!
Key Theme » Own The Position
"You’re going to get a lot of curveballs, you’re going to have libraries, you’re going to have new languages, you’re going to have libraries in these new languages. Don’t expect to walk in on Day One and really know what’s going on, or be able to be productive in any meaningful way."
"...keep in mind that as a developer you are not usually there just to write code. You are there to be the technical voice and the technical implementer of the business decisions that are made... Just as much as you should make sure everyone knows the cost of what you’re doing, make sure you know why. Make sure you understand why this view should be served, why they want to change different things in design, why they want to make this button bigger. Just try to be aware. That will help you in general in your career – I can’t emphasize how much they don’t people to just code things – they want people to really be involved with the company."
Full Episode » Transcribed
Alright, hello and welcome to the Viking Codecast!
With us today we have Nick Sarlo who is a former student of Viking and who is now working down in Austin for uShip as an engineer down there. He’s going to talk to all of us and all of you about what it’s like to kind of make that entry, that transition from the end of a bootcamp into the real working world, and working on a software team.
Nick, it’s my pleasure to have you with us, and so I guess the first question is always the same: it’s kind of who are you, why are you here and let’s take it from there!
Yes, thanks a lot. So, like Erik said, my name is Nick. I have been programming for about three-ish years off and on, but the part that everyone probably cares about is I am a Viking graduate. I was graduated from the first full time cohort in October of 2015, and was fortunate enough to immediately be hired with uShip, down in Austin. We are sort of an online marketplace for shipping things. If you need like a car or a cat, anything shipped, you put your item online, and then carriers come and say I will take your cat or car to where it needs to go.
It’s pretty cool working there because it’s very interesting working on a product – as opposed to making like, a website in support of a product. I am involved with making the product. I love what I do! I worked hard to get here and I’m really happy with where I am.
Hopefully, I can share some experiences with everybody here about my transition. Not too much technical talk here, but more just hoping that you can learn from my experiences. Any questions that you have feel free to ask them. I’m sure we’ll have time at the end.
So, without further ado I have a little – it’s more for personal notes – but I have some slides just to keep track of everything, something to look at besides my face.
We’re going to be talking about getting acclimated as a software development teammate. These are the confessions of a bootcamp graduate which is particularly relevant, because many of you will also be graduates of bootcamp or self-taught. Just nontraditional but quickly growing ways of becoming professional software engineers.
I think we went over a lot of this already. My job at uShip is my first full time software development job, so it was a big hurdle, a lot of challenges, pretty nerve-wracking walking into that environment. But I learned a lot from it and it’s really exciting and like I said, I’ve realized that a lot of the things I was worried about I probably shouldn’t have been, but we’ll get into that.
Just a quick overview: like I said my intention is to sort of share my experience and help everyone prepare for their transitions into the professional workplace. Everyone’s experiences are going to vary drastically, which is why I can tell you how to learn a codebase, how to learn a workflow, how to participate in your agile team. But your experience is going to vary pretty drastically based on the size of your team, the maturity of your codebase.
If you’re on a big team, the dynamic of your agile team – if you’re even in an agile environment – which you probably will be, but it’s going to vary drastically than if you were in a small team. For example, uShip has about 40 developers plus designers plus QAs, plus Scrum Masters, plus Product team, plus executives. There’s a lot of moving pieces. So, where you fit into that is going to vary a little bit but there are some generalizations I can make that I’ll share.
Also, young versus mature, sometimes big complex codebases with legacy code and several languages, different workflows using different choices for distributing source control, testing, integration – there are so many different things. We’re going to focus on just learning the codebase, my experience learning a new codebase. Unfortunately mine was the ladder, the mature big and complex codebase, but it wasn’t nearly as bad as I thought when I walked in on day one.
Adjusting to the new workflow going from Viking’s actually very adequate teaching of a professional workflow to an actual professional workflow which is different in some ways and it can be intimidating.
Then sort of learning your place on your team, on your agile team and your place in the company and how I sort of came to terms with what I thought my role was going into it, and what my role ended up being. I’m still learning that to this day. I’m sure I’m going to keep learning and growing in that sense, for a while.
And then questions, if we have time and I’m sure we will have time for questions at the end. Feel free to ask me about who’s hiring, anything – I am a graduate of Viking – so pick my brain, whatever you need I’m here.
It felt like it was really taking a while for me to get integrated to the codebase. I’ll share my experience how I learned that in a second, was that the codebase is new to everyone. From junior developers to senior developers alike. Everyone has growing pains and they are all pretty significant. It’s especially true for more mature codebases, for example after I had been with the company for a little bit and I was pretty well versed and pretty grounded in the codebase, and I had been productive for a while, I was asked to onboard a new senior developer. This is someone who was going to do almost exclusively back-end code which I am still new to C# and .NET, and everything, so I was supposed to onboard this person and we were given a ticket to create a new API endpoint.
I assumed that I would be able to sit down with this person, sort of be able to help her navigate the code where things are and then she would be able to do a lot of the heavy lifting because she is this senior developer who has worked in C# and .NET and worked on defense systems her entire background. But I felt that she would be able to sort of step in and do all these things. (Laughs) It’s the exact opposite, she was not familiar with almost anything, she knew the basics. She understood the language but our file, our directory structure, just our design patterns and everything were so new to her and also this other senior developer that I helped onboard, that I ended up doing most of the work. It actually ended up being really good because one: it helped me get better at my backend code and two: it also helped me realize that no matter what level you are, when you start at a new company, at a new codebase you’re going to feel new. When you walk into your first job on day one, as a bootcamp graduate, don’t feel inadequate! Don’t get that down at the fact that everything is new to you because it’s new to everybody.
I think when you’re a senior developer, and you’re bounced around between a couple jobs for a while the only thing you know is that you know nothing! Codebase is pretty drastically — for example, we just had a uShip Director of Development start and he’s spending the first six months of his tenure working directly on a team. Our directors don’t code – but he’s going to be coding, he’s going to be shadowing and working, just so he knows what’s going on. You can’t assume anybody actually knows from day one what’s going on. You’re in good company in that nobody knows what they’re doing on day one.
Use the people around you. Ask questions. Use code reviews. Look at what other people are doing, be careful about copy-pasting, there’s been a couple of times when I copy-pasted code because I thought it was easy...and I have gotten caught doing that. It just doesn’t work like that, but you know that because you’re a great programmer! But sometimes you have moments of weakness.
Learn and master the debugging process.
The biggest tip I can tell you is learn how to debug. You want to be able to solve problems in this new code. The quicker that you’re able to debug, to figure out the debugging tools and be able to step into code then you can see how things are happening. I know when I was using Visual Studio and working in C#, which I have never done before – that stuff of just learning how to debug in this code, learning how to identify on my monitor what elements are what in this code was a huge step for me understanding. After that point, then it’s just code and we know code. If you’re a Viking student, then you have been doing code for a really long time preparing for this moment so it should not be new to you – regardless of what the language is.
Adjusting to the workflow. I mentioned earlier that I felt like Viking prepared me pretty solidly as much as you can, for getting into a professional workflow. But it’s almost guaranteed going to be different from what you know. Don’t stress about it. It’s very similar to new code where the new workflow was going to be different everywhere you go, therefore, everyone who is new is going to need to learn the new workflow. However, also don’t assume that you know how to do different things. If you walk into a place that uses Git – don’t just assume you know how they implement Git, especially because Git I am finding is very flexible and gives you a lot of different ways to sort of do source control. Just use documentation, ask people, find out – they should give you resources, if not, just don’t assume anything.
It was very overwhelming when I started, I didn’t know any of the tools. I went from using Git to using Mercurial and continuous integrationand automated testing and Team City and all kinds of different software tools and things that I had never seen before. So learning all of that on top of everything else was pretty stressful – but, you’re well prepared. It’s the same thing as programming: you know the basics of source control, you know why you’re doing it, you know why you do different things. So, you have a pretty solid foundation using Git already and working in teams. Especially working in teams. You don’t really appreciate how many people – junior level developers – don’t get the opportunity to work in teams on projects before they actually step into their first job.
Like I said: expect to run into a lot of additional tools, even Git has different ways of doing it. You’ll run into things like local sites, development sites, personal development sites – (laughs) there’s a lot of different things.
Get used to ongoing, intensive code reviews.
The next big thing to be prepared for are more rigorous code reviews. Now we do code reviews a lot in Viking, I’m sure everyone has done code reviews. They are not going to be the same as what you do (now)! They may be the same as when one of your instructors pulls up your code and asks you to break it down and looks at it – that’s going to be for every code review, more likely than not.
Just be ready for it. Use it as an opportunity to learn design patterns and the ways things are done in your shop. Code review is a very collaborative process, so if you have a reason why you did something a certain way, be able to explain it clearly. Just because someone disagrees doesn’t mean that they’re correct. My first couple of code reviews were very much just saying, "OK sure, he said it so he’s got to know," but it’s very much not that. If you can explain why you did something a certain way, a lot of times they’ll agree – they just want to know why you did something. Code is a very creative thing, and so it’s not too clear to people reading it. But, you know that because as I said you should be well prepared to read code but you’re going to get better, you’re going to do a lot of it, and you’re going to have a lot of people reviewing your code.
Being "initiated" to the QA realm.
I guess the last big surprise for me was just the QA process. QA is a completely separate part of the process, or a completely separate team involved in the process, was very new to me. I remember QA-ing for me in my personal projects, and even in Viking was like "OK, does this work? Fine, it seems to work there." Because you’re so busy, you have so much going on and you’re trying to cram so much into a small period of time. So now, QAing becomes this very big, very thorough process. Even the most basic of Quality of Assurance, I suppose I should specify, but just making sure everything is functioning as it should – and trying to break it.
Any time you’ve tried to break your website, or you have other people trying to break your website, that’s what they’re trying to do! Some of them are almost evil in how much enjoyment they get out of it. (Laughs) But that’s what they’re going to do – they’re going to take your code, they’re going to try to break it in any way possible. So just be conscious that that’s part of the process, but also realize that QAs are part of your team. You want to work with them to get your tickets complete and integrated. It’s everyone’s job at the end of the day to get your ticket from your backlog to "integrated" or "done," whatever the end of the process is.
One big suggestion – two big suggestions. One is don’t take it personal, they are not trying to make you look bad. They’re not trying to make your job harder, they’re just doing their jobs because you have thousands and thousands of people using your site. If a QA person finds it, it’s probably going to be a couple dozen or a couple hundred people that run into the same problem. The biggest thing I can suggest is try to self-QA as much as possible. Test things: find out all of the browsers that you’re supposed to support. Sometimes, that will take a little digging, a lot of times even some of the best onboarding processes won’t just tell you basic things like what browsers do you support, what versions. So try to find out from day one, don’t just shift code in Chrome or don’t just expect to finish code in Chrome and then it will work perfectly on all view sizes on Safari and then be surprised when it just doesn’t. (Laughs)
Self-QA as much as possible, try to really find those bugs yourself before it gets to QA. It requires a little bit more work on your end but I found personally that it ends up decreasing the time from backlog to integration significantly. It’s kind of like the more times you check it the less times you have to redo it. It definitely helps be more efficient.
Be ready to break things. Sometimes things get through QA, sometimes you break the build. A lot of times that will get caught in your continuous integration systems and testing and everything like that. But sometimes even you just push production, like bad code to production, so you’re going to break stuff. The most important thing I can say from day one is to know how to fix it. Know how to back the changes out, know how to do things that can undo the damage that you do and then just accept it. It happens, we have a "broken build bear" that we pass around our office for people that do it as a shaming mechanism, but it’s mostly in good fun. But it is important to sort of know how to undo.
One big thing that you can learn from day one is when it gets to QA is just know how to back up changes and know how to undo things that you break.
I like the "broken build bear."
Yeah, I had the build bear already. Yeah, it does its job well, it’s definitely an effective shaming mechanism when it sits on your desk and everyone is walking by.
The last part I want to talk about a little is sort of learning your role in your team. Now this is specifically, at least from my experience, on an agile team – but it could be just your team, just your role in the company in general. I am still learning things about what my role is today, but it’s really important to get a feel for what that is. It took me a while to realize, for example, that Design and Product aren’t all powerful. My first couple tickets design or product would tell me to do things one way and I would say, "yes ma’am may I have another?" Or, "how high?" In pixels of course! I thought and assumed my role was to make whatever they threw at me happen.
Contribute with a (respectful) panoramic view & fervor.
Regardless of your level of experience before, you’re part of a team and companies want people who are going to contribute as a part of a team. They don’t want code monkeys – they don’t want people who are just going to mindlessly churn out whatever. Even the executives, whatever anyone gives you, you don’t just make it happen and that’s it. You want to think about – you want to be familiar with the business decisions behind it. You want to be familiar with metrics and why they’re doing things. Because it’s your job to sort of take that into consideration and consider the technical implementation and decide sometimes whether or not it’s even worth it.
Some places will actually give you that much power – to an extent – but they don’t just want code monkeys. They want intelligent people who can comment on business decisions in intelligent ways – from a technical perspective. They want to know if it will look this and your job is to tell them at what cost, and to know at what cost, and to have that in your mind. Don’t just assume that they’ve considered everything that goes into your ticket, because I guarantee that they haven’t! Your Product (team) is being told from executives they want this and your Designer is being told this looks good or is telling people that this looks good. So it is your job to pushback, don’t be afraid to. I was afraid to like I said, the first couple tickets was just churning them out, and now different levels of pushing back.
If you know something is a really bad idea, pushback more. You can’t, and definitely won’t win all of your battles, but that is part of your job as a developer. It’s not just to write code, but it’s to make sure that anything technical – it’s to take all things technical into consideration. You are all responsible for the final product: Design, Product, QA, Developers are all responsible for what actually gets to the consumer on the other end.
(Inaudible)...this..."Oh! I knew it wasn’t going to work..." That’s not an acceptable response. Take ownership – take pride in what you’re creating and what you’re doing. A lot of this comes down to asking questions in sprint planning. Don’t just sort of let people talk about the implementation of what you’re going to do. Ask questions, understand the ticket, understand everything that goes into it. If a ticket needs to be more granular – say so. Generally, your Product Manager won’t be offended if you say this ticket is not granular enough. If a ticket is not specific enough – say so. Just communicate, because like I said, everyone is working together at the end of the day to create a product – regardless of what that product actually is.
Scrum Masters have your back!
Your role will vary. So this is speaking from experience, but this is speaking from experience after speaking to other people who have worked at multiple places. You definitely don’t want to just accept what’s given to you. Be part of the process, be part of creating it, instead of just implementing it.
Like I said, ask people who have been around for a little bit. One great person to ask is your Scrum Master. When I started, the start of the role of Scrum Master was pretty unclear to me still, but I’m starting to learn that Scrum Master can be your best friend. They can tell you exactly, 'cause they are sort of responsible for the dynamic of the team so they can tell you exactly what your role is. If you feel like Product isn’t listening to you they’re the ones who can say "listen", that can sort of bring you together and make sure that everyone’s opinions are being heard.
Ensure work requests are aligned with team goals.
This is sort of a side note: but another big thing is because you’re working as a team all of your work has to be OK'd by the team. Make sure that nothing that you’re doing is out of scope of the team’s goal. Like I said, this is generally speaking, but I feel like that speaks for most agile shops. So don’t do the work without your team knowing or agreeing to it!
You’re going to get ad-hoc requests from other teams. "You know, this is broken can you fix this?" You’re going to get ad-hoc requests from people like Data Analysis and executives. I had a Vice President say to me (to our team), he directly emailed our team and said "this needs to be fixed!" We have people in Reporting and Accounting saying "this needs to be fixed." From Customer Service – "this needs to be fixed." You’re going to get a lot of noise coming from the outside. And like I said, even if the CEO himself tells you to do something – don’t just do it – consult with your Scrum Master, consult with your team, consult with Product because it’s more likely than not, it’s not something that absolutely needs to be done right there. Because it’s a team effort, you don’t want to hurt the team’s velocity and hurt the team’s ultimate goal because you’re not running ad-hoc requests by them.
Generally, follow the process. The process should become pretty clear. Follow the process, let your Product Manager and Scrum Master do their jobs – let them sort of filter out the noise that’s coming in and help you sort of stay focused on the work.
That was really a big moment for me when I realized that, because, I would get ad-hoc requests from people, from senior developers, from a lot of higher people and I would just think I had to do it immediately. Then I would learn that that is not the way that it happens, sort of accepting that. I’m not joking when I say the CEO sends you an email – if you’re on an agile team and the CEO sends you an email, personally, saying you should do this – I’m really not joking when I say just run it through your team. The process exists for a reason. Like I said, that’s something I learned from experience.
That’s pretty much all I have. I can take questions now. I know there wasn’t too much content there but, those are some of my experiences and some of the things that I’ve learned walking in day one, about green as a developer as you can be – from a professional stance. Just some of the things that I picked up along the way and some of the things that I stressed about, and some of the things that I’ve realized during my first couple of weeks and that I’m still learning to this day.
That’s all I really have as far as that goes. If you have questions I guess this is the time for them.
Absolutely. Just a reminder if you’re viewing right now you can use the Q&A app. Otherwise feel free to chime up.
STUDENT Q: [Jeff]
I definitely have a question.
STUDENT Q: [Jeff]
I am definitely in a good position; I have been working for two days now after graduating Viking. I just want to first second that everything you said is completely spot on, it is exactly per my experiences, your advice is amazingly great.
I guess a big question I have is: because you’re in such a very agile focused work environment, do you feel in any way limited by it? In that moving forward in your career you’d want to try something else or do you actually enjoy the structure and having Scrum Masters, having it very, very agile?
On the 'efficacy of agile.'
(Laughs) I am going to say first off, that is a debate that’s going to be had amongst developers over lunch probably for the rest of your career. The efficacy of agile and how agile is "too agile," so it’s something that people are very opinionated about. Personally, at first, it seems like a lot of fluff around the process. Just a process just for the sake of the process. But I’ve learned that it really helps to sort of get big tasks done – and make sure that your team stays on focus. I say that from my experience – where we had our team getting a lot of ad-hoc requests.
When I first joined, we had a very big project that we had finished. People thought that we weren’t doing anything so we were getting people emailing us and our Scrum Master sort of stepped up to – I’m going to be honest. When I first started I didn’t know what the heck the Scrum Master did! But, then when he started stepping in and insulating us from these ad-hoc requests and keeping us focused, I realized just how quickly it can get out of control. Especially when you have pretty solid sprint planning. We work in three week sprints, when you have all three of those weeks pretty planned out as close as you really can be, it’s important that everyone stays focused. You can really get some cool product out pretty quickly and you can pivot really quickly with it. It does seem like a lot. It seemed when I first started that it was a lot for nothing...but I think, as of now, I think I like the process. I like what comes of it, and it seems to produce a pretty productive environment. For example, we’re able to get a lot of business value quicker, as opposed to the alternative which is more "waterfall," which is where you have to wait until something is done to get any business value out of it.
My personal opinion is, I’m OK with it. But if you ask other people, they’re going to give you very different opinions about it. We have these discussions all the time. Some disgruntled developers who hate it and just want to have a coding anarchy where they can just code whatever they want and they can make all the business decisions, to people who actually like the waterfall process.
That’s my opinion on it. It (agile) works. I like it so far. But you definitely have to realize what you are in it, because you also get a lot of say in a lot of input into what you’re doing because you’re working on a team of five, six, seven, ten developers, product managers, QA, everything. So it’s really great because you can take a big company – we have 40 developers, for example. And it feels small because we have a team of nine people total with developers, QA, design, product and everything. You really feel like you’re making an impact, in that sense, because you’re not just lost in the sea of developers.
I don’t know if that answers your question, I kind of rambled a little bit.
STUDENT Q: [Jeff]
No, great answer actually. Coming from the structure of Viking it’s something that I learned to enjoy and it’s actually good to hear that even after working for a while you still enjoy the structure and it’s not something that’s holding you back.
Yeah, Viking was great in that sense because I was used to it. I hadn’t worked professionally in an agile environment but I had worked in an "agile" environment for four months. Perspective employers were very impressed by that, too. So, that’s something for anyone who isn’t hired yet to really focus on because it’s something that people sometimes struggle to adjust to.
That’s a good point. Anyone else?
STUDENT Q: [Andrew]
Thanks for a great talk so far, great advice. I had a question specifically from your transition from doing your final project at Viking into a professional agile environment.
Is there like one thing, some things that you could have done better as you were working on your final projects? I know in a professional environment you have product managers, you have a general sense and direction of where you’re going. But for the final project I was wondering what are steps that we can do to kind of streamline that process?
Yeah, that’s a great question. Not even so much streamline but just to improve. So you really have to think about what your final project is. Your final project is the culmination of all this – ton of work that you’ve put in over these past couple of months and it’s really going to be what you want to showcase when you’re looking for work.
You want to be able to speak to it from a pretty deep level. For example, with your project you want to be able to say that you "QA’d it." For example, when you step into a professional workflow you’re going to have QA. If you say that, when you’re talking about it, when you do your presentations, "we did as much QA as we could, we tried it on different screen sizes."
That’s another thing that employers care about that you really want to have the awareness that things don’t function the same in similar browsers, sort of getting used to that now is really big. If you can sort of incorporate all of the aspects of an agile team into your process that will really help.
It’s not easy, there are reasons why they’re separate on real teams, but just making sure things work and being able to explain – this may be a profitable business venture but you want to treat as such. Being able to take almost a product standpoint from it and being able to explain why you did certain things. Being able to explain clearly your goals and what you’re looking to do with it, I think is really important.
I don’t know if that answers your question but the final project should be really exciting because it’s a chance to sort of showcase all of that, and you can sort of take that agile environment and use that when you’re describing your project to really beef up what you have there.
If you can say, "we were looking at, it works on different screen sizes; we tested it on different things, being aware of that. We did this for these reasons; we decided to do this for these reasons." I think that’s a pretty cool thing that you could do with a project that will really help, and it’s really going to blow away people if you could do something like that and just be aware of what goes on in a professional workplace. A big thing is going to be selling the fact that your experience while not professional work experience is very applicable. If you can show that you’ve been doing things as professionally as possible I think that’s really cool and perspective employers are really going to get a kick out of that.
If I didn’t answer your question let me know.
STUDENT Q: [Andrew]
No, that was great. Thank you so much.
OK, so I have some questions on the right here. I don’t know, can you see those Erik?
Yeah, we have a prospective student so I’ll select that now. I’ll just read that one off.
(Laughs) ...and then we have the continuation shortly thereafter.
Okay, I see that now.
For some reason my screen size is off. Thank you Google for not QA-ing the screen size of your Q&A app! (Laughs) Prospective student here: I’m curious about the prerequisites, I have been bouncing back and forth between Odin and the Viking prerequisites. Which subjects, languages, concepts did you find to be the most valuable while completing the actual Viking curriculum?
When you look at code you can generally tell, regardless of language, what’s going on. That’s really what it is, I think when – (0:37:22 lost connection to Nick).
I don’t know if its me, or ... did we lose Nick?
STUDENT Q: [Andrew]
Yeah, I think we did.
I think maybe he’s just meditating, collecting his next thoughts. (Laughs) Do any of you guys out there have thoughts and opinions about what was valuable to you going into the program, given that you’re almost done with it?
STUDENT Q: [Andrew]
I completely agree with what Nick just said, you know the language. Like learning specific syntax and memorizing it might be helpful but it’s not the most important thing. The most important thing is learning how to program.
Sorry guys I’m back, I don’t know what happened. I don’t know where I got cut off, either, but really the thing is, the most important thing is just knowing how to program. I’m not sure where I left off or what. I was kind of just going and all of a sudden "wait a second I’m not online!"
But yeah, it’s just finding really solid good resources to learn. I could speak from experience that Viking is one of those resources! There were Python, C#, a bunch of different languages that I really did not have solid experience or even a solid portfolio in, and they were willing to hire me. So it really is all about the fundamentals and understanding what you’re doing – without worrying about the language.
Like I said earlier, you want to be a programmer, you don’t want to be an insert "language of the month" programmer.
Right – "fundies" (fundamentals) first! Other questions from anyone outside, or in?
STUDENT Q: [Thomas]
Hey Nick, I have a question. You talk about the importance of finding your role in the team. I was curious, is that something you can work towards, or is it something that (audio distortion)?
That’s a good question. You absolutely have to work towards it. You’re not going to be told that from day one. You’re going to be jumping into a team that may have been together for weeks, they could have been together for months, they could have been together for years. They are generally going to expect you to sort of step in know – but you’re not going to. I know I was hesitant, for example: pushing back was the most anxiety filled things I have ever had to do because I had someone in Product who was directly speaking to executives and getting this, I assumed, fed down from them to her and I’m just being told what to do. Learning that I should be able to push back – not should be able to – I’m supposed to pushback if they are telling me to do things that I know that are bad practice or that I know you can’t actually implement without some kind of cost. Because there’s a cost to everything that you do, as a process.
It’s very much a process. Don’t worry about knowing all these things going in. It’s going to be different, you know? I know our Product Manager for example she almost served as QA at her last job because it was a much smaller team, so what you’re doing is going to be pretty different so just try to talk to people who have been there for a while. Just keep in mind that as a developer you are not usually there just to write code. You are there to be the technical voice and the technical implementer of the business decisions that are made. Which is another big thing that I recommend is knowing why you’re doing things. Just as much as you should make sure everyone knows the cost of what you’re doing, make sure you know why. Make sure you understand why this view should be served, why they want to change different things in design, why they want to make this button bigger. Just try to be aware. That will help you just in general in your career because places want that. I can’t emphasize how much they don’t people to just code things – they want people to really be involved with the company.
It’s something that you learn, I’m still learning. I’m still really trying to get a grasp of my role on the team and in the company, but yeah.
STUDENT Q: [Thomas]
Thanks, that helps a lot.
Good, good question.
STUDENT Q: [Jeff]
One more question from me, if I could.
Because you had to jump onto a foreign language, foreign framework, everything foreign to you, I guess work/life balance for at least the first few months... How much did you find yourself doing outside of work and just spending your free time studying? Did you ever get into a good balance, or no?
Work/Life balance insights while acclimating.
So, uShip is a great place to work – they emphasize work/life balance pretty strongly. Generally what a good place to work will do is they will give you small – maybe defects, maybe bugs, small things to work on. Because, like I said, they don’t expect you to be immediately productive.
I didn’t have any problems with a work/life balance. I have a book that I read, I didn’t even read the entire thing through, just sort of skimmed through. Whenever I had some downtime I was just reading through code and when I was solving these little bugs and defects that came my way, I was really trying to make sure that I understood what I was doing and also knowing when to ask questions. They want you to sort of bang your head against the wall, in a sense against a problem. But there’s a point where you have to know whether or not you should ask for help. It’s just making sure that everything you do you use. Like with me, they ramped up so at first it was very, very simple tasks just to get me used to workflow and the deployment process. Then it ramped up to now you’re on a team and now you’re working on these tickets, and then now you’re doing pretty big work part of a bigger project. So, they should ramp you up, I wouldn’t worry too much about that.
But – that being said, it’s in your control. The more time you spend on it the quicker you might pick it up. I definitely suggest going out of your way and doing what you can to sort of get acclimated and to learn things as quick as possible, but don’t expect them to expect you to be ready – too soon.
I don’t think you should worry about stressing too much over it. They’ll give you resources and you’re at this point if you graduated, you are intelligent enough to seek those resources out to learn things at an appropriate pace.
STUDENT Q: [Jeff]
Honestly from my side it’s been weird I guess, because I feel like I’m not doing enough just because we worked so hard in Viking and now this seems easy.
Lengthy onboarding periods are common – don't fret!
Yeah, that’s not going to go away for a while – for a couple of reasons. One because when you have a professional agile environment you have things like QA, you have things like code review so it feels like Viking is 100 miles per hour constantly. Whereas this there’s a little bit of downtime where you’re not just coding, you’re not just solving problems sometimes, it’s meetings. I have so many meetings they drive me insane – which I never expected as a developer. (Laughs)
It’s going to be a while until you start being productive. You can Google it right now and you’re going to see the same thing. You can Google onboarding developers where companies ask how long before their developers are supposed to be expected to be productive and it’s generally a while. Senior developers that I helped onboard, it was probably two sprints of work before they were actually doing stuff. These were very, very senior level people who have worked at a couple of big places and have a lot of experience, and they took a little bit of time. Our Director of Development is spending six months before he even starts doing "director of development" stuff just programming and trying to learn what we’re doing.
So you’re not alone, it’s stressful. Me telling you you’re not alone isn’t going to make it any less stressful – but I promise you you’ll get there, you’ll get to where you’re actually helping and feeling productive. It’s normal. I felt useless my first couple of days. (Laughs) I sat in a dark room and I was trying to figure out how to push code to get a developer profile, which was just like my face and a little bio about me onto like this page. That’s what I did for like three days, just learning their code base and picking up C# and the deployment process.
Because even the deployment process, too, to deploy something – in Viking it’s pretty easy if you use Heroku or whatever you end up using, to get something from your computer to production. For professional environments, I know ours takes up to three hours, sometimes. You’ve got a whole bunch of tests, you’ve got tests against regression, for SQL databases, you’ve got all kinds of these...this entire process that takes forever. You’re sitting there waiting until it’s done.
It’s just different, but don’t stress about it.
STUDENT Q: [Jeff]
Alright, so I think we have time for one more here, which is: we have a whole bunch of students who are right now at the beginning of their final projects. They have to come up with all the agile stories, they have product owners, they have mock ups and then they have two weeks ahead that they’re going to be putting together these two large group agile sprints. They are also going to be working in groups of four and five people.
So, from your perspective, knowing that they are currently in the planning process of that – what advice do you have to be successful in the planning process to save pain and suffering during the development process?
Project planning & deployment tips.
OK! So planning: just make sure your tickets are as granular as possible. I remember doing my final project and at that point an "epic" could have been the same as a "story" for me. Just do this and then I wanted to just code and get into it. But the more granular that you have everything planned, broken down, the more smooth it goes. If you just focus on adding this feature, just doing things and tackling it in as small of pieces as possible really lets the whole process go a lot smoother. And also plan, give yourself some time – don’t just assume that you’re going to be coding perfectly the entire time.
Plan for QA, self QA. Plan to be able to test things, plan for code review. If you don’t plan for those things, those things are going to happen anyway or things are going to break and it’s going to make things take longer anyway. So if you plan for it now, it can really improve your efficiency. Plus just knowing about that, like I said, just knowing that that kind of stuff goes into planning is good when you’re presenting these projects. Being able to speak to it and say "in planning we set aside time for code review and QA, we made sure that things were working in different browsers" and things like that.
Nice. Alright! Well I think that’s all we have time for tonight. Nick, thank you very much. Nick again is a developer at uShip in Austin, a former Viking student, providing some wisdom on what that transition is like going from student to developer. Thanks a lot Nick for joining us! Thanks a lot everyone all our fabulous students who are here with us and everyone who is out there watching. We’ll be back next week with another conversation with a developer, and happy to answer questions in the meantime.
Have a good night.