My First Two Years as a Professional Developer

“I love programming, no matter how much angst it causes me.”

After two years of working as a professional developer, long gone are the days where I’d anxiously worry about doing a good enough job, getting enough work done, and being stupid enough to choose Computer Science as my major. Don’t get me wrong, I love programming. But I worried that I would never be good enough for the job — I didn’t want to be average or just get by, but I also knew I was way out of my league.

Two years later, I worry about the same things. The difference is that I’m more knowledgeable… maybe? Or, I’ve just come to accept that this is the job. I will always wake up wondering if I can solve yesterday’s bug, or wondering if this field is not for me and that I should’ve picked a major where I know what problems to expect each day.

Then I think about how boring that would be, and I realize that I love programming no matter how much angst it causes me. I love that each day there is a new challenge to solve, victories are always short-lived (to be followed by the next bug), I will never be the best, and there is always more to learn.

It’s normal to find yourself struggling at your first programming job. You’ll spend your lunch breaks wondering if you’re doing well, if you should be getting more done, and what you can do to be better. You’ll question whether things will ever feel normal. But you’ll learn that they will (to a certain extent), and that all of it is just part of this crazy thing called programming. If you’re starting out, I have a few tips on what to expect, when to expect it, and how to get into a programming state-of-mind.

Always use developer documentation

In college, StackOverflow is a lifesaver. Half of your assignments are copied and pasted from it. If you’re stuck on an unfixable bug, some StackOverflow page from 2013 documenting the problem is your defense.

But in the real world, Stack Overflow is your last defense and is best used when you’re at a dead end. Even then, only pages dated within the last year are considered valid.

Instead, use the developer documentation of the language or platform in question. This will often be the most accurate source and have the most up-to-date documentation. Besides, a lot of Stack’s top-marked answers are a copy/paste straight from the Developer Docs! When the docs aren’t enough, that’s when Stack may be useful to see what other devs have uncovered.

Ask questions… lots of them

Generally speaking, developers are very helpful people! I’ve worked with incredibly talented developers who doubled as great teachers. There’s a misconception that being able to do things without asking questions is smart and strong. Don’t be a hero, and don’t be afraid to ask “dumb” questions. Ask even if you think you know the answer, because developers will often add perspective and additional information.

There are times when a developer may be exploring a new area in technology or programming that you may want to know more about. Ask away. Then, there are times you get stuck in programming, especially in the beginning. To prevent that, always research first. And then keep researching. And if you’re still stuck, research a third time!

Make sure you’ve tried all avenues (assuming you have time), then ask for help or confirmation. This is where I’ve learned the most because sometimes the answer isn’t online, but a developer with experience could give me advice on what was helpful for them in this situation.

Even if you’ve come to the right answer from research, it pays to ask because the developer will usually add insight that can only come from personal experience. This is where I usually take advantage and ask question upon question, as long as the dev is game. Embrace your role as an annoying student, and ask.

Shortcuts are your best friend

Seriously, get to know your keyboard. The ability to search an entire project or file with a few short commands can make coding a whole lot easier. Not to mention, formatting code and enlarging text via keyboard commands is pretty sweet.

Everything is possible until it’s not

Ok, so sometimes I surprise myself with deep thoughts like this one. If there’s something I’ve learned from working at Small Planet, it’s that everything is possible. There is no saying “no” in programming. It may take time, it may take resources, but generally, you can create anything. If you find otherwise, then you’ve just haven’t searched well enough…. that is, until you can be certain that it’s definitely impossible.

Sometimes there are limitations to the frameworks you will be using

These are generally pretty well known once you’ve been working with a framework for a while. Many times you will be able to think of an alternate solution, but it will be pretty hacky. And if your program is supporting hundreds of thousands of users, accepting this limitation is the smart way to go. So yes, everything is possible until it’s not. But it’s rarely not.

Longer code is sometimes better (and safer)

In college, I was wowed when my Data Structures professor converted a really long C++ if else statement into a one-line conditional statement and made it the return value to a function. He essentially turned several lines of code into one or two. Short code is great — it’s nice and simple. But many times longer code can be clearer and safer, so don’t always choose short because it’s short. Be smart.

UI is important

“I’m a developer, I should be solving complicated back-end/logic problems.” That’s what I thought when I was an intern. Then I’d get simple UI tickets that I couldn’t complete. I remember thinking, “just give me some back-end code and you’ll see I can code, UI is not my strong suit.”

I failed to realize that any good mobile programmer has UI coding down pat. It may not be our favorite, but you need to master the small things so you can leave time to tackle the big fun logical stuff. So no, UI is not beneath you, and sometimes it can actually be tricky for someone with experience.

Don’t underestimate your knowledge

When I started programming, I assumed everyone knew better than me. All the programmers I worked with were veterans, so I need to be a sponge, ready soak up everything and anything that was thrown at me.

That logic still holds, but that does not discredit your own thoughts. Remember your own logic has value, even if sometimes it’s not as great.

If code looks weird, there’s usually a reason for it

Yes, you are smart, but your lack of experience or ignorance of the framework may prevent you from seeing things that a Senior Developer sees.

So, I’ll say it again: just ask! When I’m forced to code something in a way that’s not ideal, I leave comments explaining why I had to do it that way. But from what I’ve seen, you will sometimes come across code that gives you a “WTF” moment. Soon to be followed (after examining other files in the code more thoroughly or by actually speaking to the original dev or team) by an “ohhhhh, now I see.”

Any code that comes your way is your code now

I learned this the hard way when I was handed the codebase of one of our biggest projects. I had to refactor a huge chunk of it, and I had no clue what half of the code did (It was my 3rd month as a programmer).

So, if the code didn’t harm anything, I left it alone. A week later I had the opportunity to work with the original programmer who wrote most of that project. He was helping me debug something when we came across a block of code. He asked, “Why do you have this here?” “What does this do?”

“Ummm you wrote that,” I answered. “I don’t really know.” Then I realized that the code was my code now, and I had to know what it did or didn’t do. Just because a block of code is already there doesn’t mean it’s a permanent fixture.

Projects outgrow previous constraints

Don’t be scared to veer away from the code’s original set up. Brilliant pieces of code written by talented developers may not be needed anymore.

I can’t tell you how many times I’ve tried to adopt new features or rules within the existing code of experienced developers. I thought, “they’re pretty smart, so I need to work within their bounds.” I can’t tell you how untrue that is.

When that dev coded the project, they had a different set of constraints and rules to follow. If you find yourself struggling to adopt new features into existing code, it’s time to regroup and re-write. Don’t confine yourself if you’re hitting a point where the existing code is making it impractical to adopt new rules.

Learn how to use the terminal

This one I’m still working on. But the terminal is practically magic. ✨ ✨ ✨

Always test your code

As a mobile developer, I primarily test on devices by trying out all the possible scenarios that a user can do. And I always do it before delivering my stories.

By testing, you will uncover new scenarios that may need to be baked into the logic that can refine the tickets you receive (or call attention to a feature or rule that needs to be addressed). This way, you’re not scrambling in the last sprint to fix things that should’ve been done earlier.