facebook pixel

My First Programming Job: In The Trenches

First Programming Job Featured Image

This is the tale of my first programming job. Most of us have at least one thing in common in the professional world. We had to start from square one. The point in our career path where we have no professional experience in the field we’re trying to tap into, and we’re looking for someone to take a chance on us.

We’re often willing to compromise on how much we make, our paid time off, and our overall work-life balance. All so we may have a better chance at getting our foot in the door.

The beginning of my career was similar. I had little experience writing code, lacked the credentials that most of my peers had, and was willing to sacrifice whatever I needed to get my foot in the door.

Although I felt like the odds were against me, my hail mary attempt at getting my foot in the door surprisingly succeeded, and I secured a job as a Junior Developer.

Entering the Professional World

Despite that the only technical experience I had was that of a hobbyist programmer. My first job as a software developer was in industrial automation. But it wasn’t without its caveats.

First, I would only receive twelve dollars an hour (USD) for compensation. This one is on me since it was all that I asked for. Because I didn’t have any experience or even a degree in the field, asking for such little compensation felt like I was asking too much at the time.

Secondly, no medical benefits were associated with the job, and the amount of paid time off was minimal. This was a small company in a small town where most jobs in the area do not offer benefits for their employees. This seemed like the norm at the time, so I didn’t fret over it.

Finally, I had to work as a quality assurance specialist for the initial few weeks to become acquainted with the software. Additionally, this would allow me enough time to learn the technologies they used at a basic level.

Even though this may sound like a terrible deal to most people reading this, I was excited. The pay was better than most places I was working at before, and it was a real opportunity to learn some valuable skills.

I hit the books hard to prepare for moving up to a development position. After a few weeks of hard work, they tested the skills I had set out to learn and gave me a seat in the developer room.

At first, I was proud of myself for overcoming this initial obstacle. However, I soon realized that I may have bitten off more than I could chew, as I had no idea what lay ahead.

Immersed in the Codebase

With my shiny new workstation setup, I was excited to get started. My first task was getting familiar with the codebase I would be working with.

I was paired up with a Senior Developer who would assist me in getting started. Conveniently enough, the developer helping me out sat directly behind me.

He pulled up his chair, quickly commandeered my keyboard and mouse, and began to show me around. While clicking through files like a madman, he started rattling off more technical jargon than I was ready for.

I hardly understood anything he was saying to me at the speed we were moving through the codebase. After about fifteen minutes, he pushed the keyboard and mouse back in my direction and quietly rolled his chair back over to his workstation.

It was immediately apparent that I would be on my own to learn how things worked, which would be a massive undertaking. Luckily, I had spent some time on the Quality Assurance team and understood the products reasonably well.

I used this to my advantage and began diving through the source code for each product, taking general notes along the way. When I didn’t understand how some piece of code worked, I fired up the project in my IDE, set some breakpoints, and stepped through those sections. I kept repeating the process until I finally had that “aha” moment and then moved on.

After a few weeks, I was directed to the “Bugs” work queue, which would be my life for the next several months. However, I was okay with that. I would truly learn how the products and their code worked during this period.

My First Solo Project: Overcoming Challenges

I spent about six months working on fixing bugs that were reported by our Quality Assurance team or by clients. As a result, my programming skills improved significantly, and I better understood the products I was working on.

My boss and colleagues have gained more confidence in my abilities and entrusted me with my first project, localization. The problem with the software was that everything was in English; however, many of our clients spoke different languages.

We needed to allow the products to display the language our clients preferred to accommodate our clients better overseas. However, this seemingly simple project would be far more complicated than anticipated.

Challenge 1: Hard-Coding Everywhere

We had five client-facing products that our clients interacted with that needed the user interface updated to support different languages. Luckily, each product was crafted using Windows Presentation Foundation (WPF), which allowed the applications to be responsive.

Except that, instead of taking advantage of the dynamic nature of WPF, every width and height throughout the products was hard-coded. This was a major disappointment.

While exploring our products and loading different language files, I noticed that the text would sometimes get cut off. Screen elements didn’t resize properly, and the layout would break on some screens.

I realized I must make all user interface components within our products responsive—a tedious task, to say the least.

Challenge 2: Verbose languages

There are more than seven thousand languages spoken around the world. All of which come in many different shapes and sizes. What may be a concise phrase in one language may be quite lengthy in another.

While our application interfaces looked great in English. When shown using another language, they left much to be desired, if not downright unusable.

This could lead to UI element labels being truncated, textboxes needing more space, and overall misproportioned page elements. I was also going to have to account for languages that read from right to left.

My simple project was starting to balloon in complexity. However, I was up for the challenge and learned quite a bit from the experience.

Challenge 3: Poor Translations

Google Translate can sometimes have some rather humorous results. The tool can be convenient when we need to get the jist of something that isn’t in our native language. However, it isn’t trustworthy enough to use it for localizing applications.

This would be a challenge that would come post-release of the project. The company I was working for was relatively small. They decided to leverage Google Translate instead of paying a professional to do their translations to save some money.

This blunder caused us to receive some prompt feedback from our clients. For some clients, the result was even seen as humorous. But they wanted it fixed and quickly.

We quickly hired a third-party translator to review and revise our translations. Realistically, this is what should have happened from the beginning.

As a result, I had to update the projects with the new translation files and conduct a complete regression test to ensure that UI components didn’t break.

Receiving Feedback and Growing as a Programmer

When I was hired, I didn’t know what to expect. With a little research, I discovered that a mentor would likely guide my progression and learning. Someone with more experience to help me learn and grow as a developer.

Well, this notion was wrong. Everyone at the company was a seasoned developer except for me. The fact is that nobody had the time to help out the newbie in the room.

However, I could still receive feedback and continue growing as a developer. I just had to look for these opportunities in other places.

For instance, our Quality Assurance team quickly told me how many bugs my feature or hotfix produced. Fewer complaints meant fewer bugs that I was introducing into the software.

Another source was the pull request feedback. Even though our senior programmers didn’t have the time to mentor me, they were quick to comment on my code.

I used this information to identify gaps in my programming knowledge and direct myself to learn other parts of the technology stack I was working with. I identified online resources such as Pluralsight that could fill these gaps and take charge of my own growth as a developer.

Conclusion

I worked at this company for a total of three years. During that time, my skills vastly improved. I built trust between my employers and colleagues and participated in some pretty cool projects.

I leveraged many online resources to not only improve as a developer but also to advance my career. Some paid, others free. The point is I took some general feedback and turned it into something actionable to progress my career path.

While I started for only twelve dollars an hour, I received several raises. By the end of my third year, I was now making a $50k a year salary which was a huge difference from when I started.

I really enjoyed working for this company. Their products were very niche and fun to work on. However, after three years, it was time to move on, and for good reason. But that’s a topic for another post.

Cheers!

Leave a Comment

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