Software Engineering at URBN

Between Wednesday Sips and weekend brunch and countless escapades through the city this summer, I began my career as a software developer.

I got to attend daily stand-ups and work on tickets for the Urban Outfitters and Anthropologie iOS apps with the other engineers, and had an opportunity to lead a three-intern team in developing Snap & Match as part of my intern project. This internship made me learn a lot about good software engineering habits, both technical and non-technical. Here are some of the big ones.

1. Don’t be afraid to ask questions

The people around you are part of your team — your success is their success too. If you’re stuck or you don’t really know what’s going on, don’t be afraid to speak up!

2. Good Git practices are key

Constantly committing to GitHub (or whatever version management software you’re using) is the software engineering equivalent of remembering to hit “Save” every few minutes when you’re writing a paper. Make sure you don’t lose any important changes by committing often.

3. Keep a resource doc

Looking at a page with too many tabs open is like having a messy room. It’s tolerable but also kind of annoying to live in, and no one but you could ever find their way around the clutter. And let’s be honest — when you’re deep into a program, are you really going to remember that the perfect Stack Overflow snippet is three tabs to the left from the one you’re currently on? For every project, I have a Google doc with descriptions and links to all resources, divided up into different sections for each part of the project (Networking, Views, Image Processing, etc all have their own sections). From there, Control + F gets me results in a simple, quick, and efficient way.

This doc can get messy, too, so make sure to go through and weed out the unnecessary resources at the end of each day.

4. Task and Subtask (and Subtask Some More)

Your team may have a Scrum or a Kanban board. You may have tasks on it already. It’s so easy to take a card and start hacking away, but it often pays to subtask those tasks into more sizeable chunks. “Create a camera view” is too ambiguous to start with. “Set up Image View”, “Authenticate User”, and “Design Overlay” are concise and specific.

I found that subtasking with my own Trello board, and then writing out exactly what I wanted to build on paper first, helped immensely.

5. Always spec things out beforehand

Before you start any programming project or task, it’s a good idea to have what you want out on paper. Be as specific as possible — for example, if you’re going to be writing an app, have the views and general navigation flow down, but also think about what sorts of databases you’ll be utilizing, the API calls you’ll be making, and so forth. All specs change, but the more specific you are, the more you’ll understand your problem domain, and the better time you’ll have with your project. Go in with as clear of an idea as possible.

6. Code review is your friend

You know those people who go through your pull requests and add tons of comments and suggestions on how to improve your code? They are crucial and they’re important. Take their recommendations into account, especially if you’re just starting out. Don’t take criticism too harshly — the goal is to improve!

7. You don’t need to know everything

Looking back, this was one of the biggest misconceptions I’d had as a computer science student. Before my internship, I was That Kid (you know the one) who read each coding book cover-to-cover and took meticulous notes on the most obscure features of every language, because what if I needed to know that keyword someday? Honestly, Google is your friend, and there will often be other engineers who can help you find the solutions you’re looking for.

Learning on the job is a big part of being a software engineer. I still remember my surprise when the engineer I was pair programming with told me that he didn’t know any more about a certain part of the Swift language than I did; rather, he had an idea of how to solve the problem at hand and picked up the knowledge he needed to implement the solution along the way.

It’s a lot less important to know specific information, and a lot more crucial that you know how to solve problems. What’s the use of a bunch of discrete, dead knowledge sitting around in your brain if you’re looking at a ticket and have no idea how to even begin?

That was my biggest takeaway from the internship.

Software Engineering at URBN

After three months at URBN, I no longer feel like I’m hacking my way through projects. That in itself is a big thing 🙂 My manager at URBN stressed how the main goal was for me to learn and improve as a developer. I can’t wait to continue my journey and see what comes next!

Mimi Chenyao

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment *