Forem: Tracey Turner

What I've learned in my first year as a Software Engineer

Tracey Turner — Fri, 23 Aug 2019 19:56:00 +0000

Learn as much as you can

Image of man coding. Photo by @nesabymakers on Unsplash

In your first year as a new professional software engineer, you are a blank slate. A dry sponge that's ready to absorb and touch everything in sight, and you should. During your first year, you may not have the required knowledge to make an immediate impact at your new job, and that's completely okay. While it does depend on where you work (a smaller team may demand more from you straight out the gate than a larger team), most places don't expect you to hit the ground sprinting. In fact, quite the opposite, they want you to start slow and really use your first year to learn as much as you can. So, make sure you're really taking advantage of the time that's being given to you.

Closed mouths don't get fed, so stick to a senior developer and shadow them, they can be goldmines of knowledge. There's no such thing as a dumb question, so really pick their brains about the work they're doing, taking care to ask "why" and "how" questions. Finally, if you work somewhere that doesn't encourage taking time to really learn more, it's worth considering if that's the ideal place to spend the developmental years of your software engineering career.

Don't be afraid of a challenge

Facing a steep obstacle. Photo by Jukan Tateisi on Unsplash

One of the hardest things for me to get over in my first year, was the fear of accepting the big challenges. Big challenges usually come with big expectations, so it's easy to shy away from some of the bigger projects that come down the pipe because you feel like you're not quite ready for something so large yet, but in reality you'll never be ready! The only way to start is to just dive in head first and learn on the fly. Not only will you get comfortable with some of the minutia that comes with larger tasks, like time management and pre-planning, but it'll also make you better at some of the larger engineering/architectural concepts you must consider when making software. Truth be told, most of the time, you'll find that the tasks you were originally afraid of end up being pretty tame and the more senior engineers will be there to help if you need it. So, the next time you see a large ticket is coming up, step up to the plate and grab it!

Seek out responsibility

Man standing at the bow of a boat with a lamp at night. Photo by Chen YiChun on Unsplash

A very important piece of my growth in my first year, something I feel often gets overlooked, is getting involved with responsibilities that don't necessarily involve writing a single line of code. To some, this may sound like a turn-off and not what they signed up for at all, but it's important to recognize that as a new engineer you bring a perspective to the team that other team members who've been there for years don't have; you can use this to take initiative.

There may be flaws in the on-boarding process that made it difficult for you to get spun up, or maybe you think that the team's documentation process is lacking (which made it difficult for you to get up to speed). These are opportunities for you to take ownership and tackle them head on! The process and environment for an engineering team is arguably just as important as any single line of code that is going to be written.

Alternatively, there are usually some minor tasks that senior engineers are required to do as a part of their work load. It could help them out to ask if you could take some of these smaller opportunities off their hands, not only will it free up their time, but it can also give you insight on some of the day to day operations of the team.

Finally, getting involved with non-code related activities can give you an idea of your future career path. You may find that you absolutely loathe anything that doesn't take place inside of Visual Studio, and that's completely okay, code away friend! But, you may find that you actually really enjoy the administrative side of things, and perhaps a Development Manager role may of be of interest in your future. Either way, you won't know for sure until you try.

Overcoming impostor syndrome

People in masks. Photo by Markus Winkler on Unsplash

So, you came into college (probably) a complete rookie, barely understanding what a for loop is. There were moments when you thought you couldn't do it, but you kept grinding. Then, the next thing you knew, you were a senior, standing on top of the coding world. There wasn't an algorithm invented that you couldn't figure out the Big-O notation of. Create an algorithm that can find all of the Pythagorean triples in an array of ints? Ha. Child's play. Bill Gates himself would marvel at your coding abilities.

Then, you start your first day as a real software engineer, and you're asked to diagnose and squash an extremely simple bug in a code base that spans tens of thousands (possibly hundreds of thousands or more) of lines of code and you're at a complete loss. You've spent three hours trying to solve this one bug and you feel like a freshman in your intro coding course all over again. You start to wonder, "Am I cut out to be an engineer?"

Impostor Syndrome is natural, and it seems like everyone goes through at one point or another. It's important to remember though, you worked hard and deserve to be there. They know that, and that's why they hired you, now you just need to believe it. Don't worry if "simple" tasks seem hard in the beginning, that's natural. Just be confident in your abilities, and it will show in your code. No one wants to work with a Dev that has no confidence in their work and looks towards others for confirmation that they're doing things right every time they add one line of code. You made it this far, and you're the real deal! Keep the faith.

Attack your weaknesses and target your strengths

Vintage chess pieces on a chess board. Photo by Lou Levit on Unsplash

No junior engineer is perfect. You're going to find out very quickly that there are some things that you just are not good at. You will also find out there are some things that you're a natural at. These things will both, hopefully, be pointed out to you by a supervisor that wants to see you improve. When you have identified your strengths and weaknesses (honestly the more weaknesses the better!) you can start game-planning on how to improve your weak spots and leverage your strengths to create a solid foundation to build on, and to push the team to greater heights by making immediate use of them.

Don't rush yourself

Finishing the marathon. Photo by Pietro Rampazzo on Unsplash

Finally, and arguably the most important thing I've learned, is not to rush yourself. When you first get hired, you might feel like you want to just hurry up and get that senior developer title, so you stack your plate as high as you can and start sprinting. Just remember to slow down and stop to smell the roses as you progress through your first year. Really soak things in and internalize all the new information and lessons you're being hit with. This was honestly the hardest thing for me to learn, and trying to sprint very quickly leads to burnout. Your career as a marathon not a sprint, so make sure you start slow and pace yourself in your first year and you'll be where you want to be in no time.

Debugging VueJS

Tracey Turner — Fri, 18 Jan 2019 14:01:01 +0000

I love JavaScript. It’s a messy, dynamic, and sometimes tiring love, but it’s love nonetheless. JavaScript allows you to build projects your own way — you can be light on your feet and change paradigms very quickly. This permits for lightning fast development, but also permits for many bugs to creep into your code and knowing how to stomp out those bugs is critical to being a successful JavaScript developer.

For this article, I’ll be focusing on debugging using the VueJS front-end library, which is what we use here at DealerOn for our front-end development, but the process I use to debug my code can be applied to vanilla JavaScript and many other frameworks. I’ll also be using code from a personal project of mine for examples while I walk through my approach for debugging. Lastly, before we jump in, keep in mind that this is just my personal approach and is by no means meant to be seen as the only approach. If you find a personal debugging process that works for you, feel free to embrace it and go that route!

My Process

Check the Console
Manual Tracing
Vue Dev Tools
Console.log(“old faithful”)
There are Unit Tests!

1) Check the Console

Vue Console Errors

This is the very first thing you should do. Vue gives you extremely useful warnings and errors in the console that will tell you when and where something broke. This is one of the easier problems you’ll come across. If the error is screaming at you that you broke something, then you’re in luck, because it’s usually pretty easy to find and fix from there. Vue is pretty good at warning you about a problem (and what component the problem is located in) before it even breaks. Then, if your code breaks, the console gives you pretty useful information about what happened. As you can see here, somewhere I’m accessing a property of an undefined object. I just need to find where i’m accessing that property and find why it’s undefined. Easy!

2) Manual Tracing

“Oh no, but Tracey! I found where my error was in my code, but I still have no idea what’s causing it,” you say clearly frustrated. Well, before getting into some of the useful tools at your disposal. Let’s first take some time to walk through your code. This is the step that has been most beneficial to my growth as a developer. Look at your code and follow the logic. Grab a pen and paper, or do it in your head, but step through your own code without running it.

Not only does this make you extremely familiar with your code, but it forces you to think and reconsider why you made some of the choices you did. If you’re tracing your code and you find that it’s extremely convoluted and hard to follow, could your code be neater? Could the logic be redone in a simpler way? What parts can be changed to make this easier to follow? The fast-paced nature of JavaScript can lead to sloppy, needlessly complex code. Answering these questions will force your skills as a developer to grow and make your code better and less error prone in the future. But, as is often the case with JavaScript, you’ll find it was just a typo.

45 minutes of debugging for this!

3) Vue Dev Tools

Sometimes your errors aren’t as simple as a typo. Sometimes your code is “working” but it’s just not doing what you expected it to do (or anything at all). Vue Dev Tools can be extremely useful here. They can be downloaded as a chrome extension, and allow you to inspect elements as Vue components. This gives you a much more detailed view of the state of a component at any given point. It lists all of the props, computed fields, data, and events fired. This is extremely useful information.

For example, lets say you’re expecting the data of a component to change after an event is fired. The dev tools let you inspect the component real time to confirm that the data is changing how you expect. Vue Dev Tools will also allow you access any component you have highlighted as $vm0 in your console, which you can then use to check fields and call methods for further testing!

Thank you Vue Dev Tools!

4) Console.log(“old faithful”)

When all else has failed and things are looking dark, your best friend is always console.log. Sometimes the information provided by props in the Vue Dev Tools just isn’t enough, and you need to deep dive into methods and know what the state of a variable is at an exact moment or if a block of code was even hit at all. When developing your Vue project, I find it useful to intermittently place console.logs throughout your project as you’re developing. For example,

setTimeFormat () {
  if (this.e1 === ‘AM’) {
    this.ok = true
    this.collapsed = null
    this.updateSlots()
    console.log(‘SetTimeFormat AM: ’, this.e1)
    this.e1 = null
  } 
  else if (this.e1 === ‘PM’) {
    this.collapsed = true
    this.ok = null
    this.updateSlots()
    console.log(‘SetTimeFormat PM: ’, this.e1)
    this.e1 = null
  }
}

Now, when this code runs, you can confirm that it’s working correctly each time it’s called because you can make the logger tell you where the value is coming from and what it’s value is at that moment. Placing helpful and informative console.logs as you develop can be likened to creating Unit tests in many other languages. It doesn’t always seem necessary at the time, but it can save you a lot of headaches down the line.

5) There are Unit Test!

Vue Cli actually lets you build your projects with Unit Tests straight out of the box using Jest or Mocha! These JavaScript testing frameworks allow you to develop your components with unit tests built around them to ensure they’re outputting values you expect. I can’t stress enough how important this is because many developers, old and new alike, have no idea that you can begin testing with Vue straight from the jump! Vue has some amazing documentation on how to create components with unit testing in mind and they explain how to do it better than I ever could, so here is a link to that information.

Conclusion

One of the biggest complaints I receive from people that are new to JavaScript is how difficult and tedious it can be debugging, but it doesn’t have to be! JavaScript (especially with Vue) has tons of tools at it’s disposal to make catching those nasty bugs painless. I hope this article gave you some insight as to what steps you could take and what tools you can use when you run across your own issues in the future. Happy Coding!