Before starting my first enterprise web development job, I was accustomed to code-alongs on Udemy and ample opportunities to fix my mistakes.

I also enjoyed browsing Tex-Mex cooking blogs for hours at a leisurely pace when I need a break from coding.

In other words? I had my own pace and workflow. It was awesome!

So it was a bit of a culture shock my very first week on the job as a web developer.

Of course, you never know exactly what to expect when you start a new job. But I really could have used a few secret dev fairies to clue me in on what it was going to be like.

Here are 5 things I wish they told me before I started my first web development job.

5. We speak JavaScript here. Literally.

Most of my early coding journey was completed non-verbally. Sure, I went to Meetups and other social events for devs – but I was too scared to talk to anybody because I was a newbie.

And the times I did interact verbally? It involved asking for help using mostly non-technical terms. Thus when I started my enterprise dev job and got stuck, I had to use my big words with my co-workers.

This is a lot more difficult than I thought it would be!

At first I was so nervous because I was scared I would say the wrong term (like parameter instead of argument) and they’d fire me. It sounds silly but I had heard horror stories.

Fortunately, I got more confident with my technical communication and eventually interacted with my fellow co-workers as if these concepts and terms were just an extension of English.

4. We do version control. Know it, love it.

I didn’t realize what a massive and integral role version control plays in an enterprise environment. The thing is, it’s hard to practice all those robust Git commands when it’s just you. I contributed minimally to open-source software projects as a newbie so only had experience with the basics like commit, push, pull, etc.

The first week on the job was like a hands-on Git crash course. There were some new and mildly crazy commands I’d never heard of and had to quickly become fluent with like rebase, bisect and cherry-pick.

I learned not only the science of version control, but the art of version control down to the art of a quality commit message.

3. oH ThE aNiMaL isN’T B0TH3RInG yOu Is hE?

I don’t mind well-behaved animals in the workplace. The keyphrase here is well-behaved. Unfortunately, my workplace was overly dog-friendly – so friendly in fact that there were two very unruly dogs that barked at everything. They also loved to play and fetch and run up and sniff places that shouldn’t be sniffed in mixed company. I mean…These dogs were bad.

I guess the other employees were used to their behavior or just cranked up their headphones.

One day I actually captured them on video going ape:

It was really, really difficult doing SQL queries with the dogs around.

2. You’re going to gain 20 lbs.

You’ve probably seen at least one Day in the Life of a Software Engineer video on YouTube where seemingly endless buffets are served all morning and afternoon. While my first dev job wasn’t blessed with a vegan taco bar or humming cappuccino machine area, my co-workers usually invited me out for lunch on the daily.

It was always fast food since it was the only thing we had time for.

It.

Added.

Up.

Because not only was I sitting on my butt for 8-12 hours a day, I also was so tired after work that I lost the initiative to go exercise. I gained about 20 pounds and was very non-plussed. I eventually started bringing in my own healthy lunches. But even so, the effects lingered for quite some time. In fact I’m still trying to bike some of that weight off!

1. There are deadlines. There is the right way to do things. Choose one.

This was a tough one for me. I was used to methodically solving problems, refactoring my code and doing everything with the utmost efficiency when it came to my freelance and personal projects.

But in enterprise development, there are tight deadlines.

More often than not, developers aren’t given enough time to create software that really shines. We cut corners. We write bad code because it’s faster. We don’t fix mistakes when we see them and convince ourselves we’ll come back and fix it later…Which we never do.

Unfortunately, enterprise code bases are often filled with poor code and a lot of times it’s not entirely the developers’ fault. Quite the opposite. It’s the tempo of the company forcing devs to make tough choices.

As a result, our future tasks (and future devs’ tasks) are made so much more difficult because at a certain point the code stops working. Then management gets ticked off. Then you have to explain things. And then…And then…yeah, it’s a dirty cycle.

These are the biggest things I wish the dev fairies had told me.

But there were so many other things that were thrown at me I never expected. For example, needing to hone in on my interpersonal communication skills since upper management didn’t know much about software – but me needing to explain the whats and whys of the applications I was building in the most specific way possible.

Or the expectation of being flexible enough to dive into a legacy code base for the first time to add features or fix age-old problems.
Or juggling dev responsibilities with client phone calls, spouses and friends dropping in, random people mistaking our office for the dentist downstairs, FedEx deliveries and other external distractions.

While I indeed fulfilled my goal of getting enterprise experience and being a valuable asset, I often look back and think about how crazy those first few months were.

P.S. Follow me on YouTube where I talk a lot about cool web dev stuff.