10 things every new engineer should know
By: Enoch Robinson
Tags: Programming, Software Development

I still remember my first year as an engineer. I’ll never forget the sense of pride when I first solved the impossible. It was also a year full of lessons learned. The first (and last) time I wiped out a critical table or realizing the waste of time coding because you didn’t ask to fully understand a story. I’ve made plenty of mistakes. Here are 10 things I learned that first year.

1. Plan your code

I cannot stress enough how important it is to have a semblance of a plan before you write your first line of code. I’ve noticed a correlation in which engineers who plan their code, will write less and cleaner code. It’s not uncommon you’ll jump in and start writing code. Especially the first year. Start by breaking down the story into logical chunks. Flow chart it if it helps. You can then pseudo code it to outline your structure of logic. Some engineers write a bunch of comments first, then write in the code. Figure out your planning style to help you break down your work.

2. Don’t Assume Your Solution

In school, I was given the following puzzle:

“Write a snippet of code that will always produce an even random number between 0 & 50”

At first glance, this puzzle seems to make people think they need division to solve it.

My first attempt to solve the puzzle.

After a few seconds of thinking it through, you’ll realize a check is needed to ensure a return of an even number. Using the Modulus Operator, we can verify the result.

Dealing with odd numbers.

While the above works, following the division path led to an inefficiency. You may already see another solution, without any checks.

A much more efficient solution.

In my first year, I would hear a problem and immediately start solving it in my head. I would plan out my code using that first solution. I learned to take my time, think it through, and ask questions. Your code may work, but make sure it accounts for most/all scenarios and its efficiently written.

3. Asking Questions

Being a new engineer, I had all sorts of questions. I’m not afraid to ask questions, but I quickly learned that I was bothering senior members when they too had work to complete.

When you are new, your peers are more lenient about how often you can interrupt and ask questions. Take advantage of this during your first two weeks on the job. Ask to your hearts content, being mindful of the time you are taking away from others. After a few weeks, ask during noted down times. For example, just before meetings start and right after they end, you’ll find a few minutes to sneak in a question. If you hear a senior or lead engineer offer their time, use it.

As you gain experience, you won’t have less questions, but you’ll learn where to find the answers. Start with the official documentation (ie Javadocs, .NET documentation) to learn the original intent of the technology stacks and frameworks. Google, StackOverflow, and Reddit Programming are good options as well. For me, it lead to a different problem: not asking enough questions.

I started spending too much time researching. After a certain point, researching won’t help you. You’ll need figure out that cut off point, but generally it will be a couple of hours at least. I found most of my answers (during my first year), on average, within three hours. If I didn’t have an answer, I’d take a break, then try for another hour. If still no answer, then I’d ask. By this point, I thoroughly researched my topic and my questions were better defined. My peers appreciated this and were more willing to answer my questions when they saw me raise my hand. Over time, my research times dropped as my knowledge increased.

4. Code Bloat

In my first year, I rarely wrote perfect code on my first attempt. Typically, after planning, I would write a section of code, then realize I needed to make some adjustments. This would repeat a few times before I completed the section. Next, I would branch out to other sections, building off what I originally created. After a few iterations, my code looked different than originally intended. But code compiled without errors and I could turned it in.

My code was not clean. Over time, my code would slow down productivity. It made debugging harder and adding new code like navigating a land mine. Here are some guidelines to help you be aware of what to avoid:

· Redundant variables

· Unused logic in code

· Irrelevant logic in code

· Inefficient logic

· An object that knows to much (AKA God Object)

· Code is hard to read

If you see any of these, or you aren’t sure if the code is bloated, always ask a Senior or Lead Engineer on your team for direction. Over time, code grows and eventually you have unnecessarily long, slow or wasteful logic. It is almost impossible for a new engineer to discern the impact of refactoring. Review this JavaScript sample of code I found online:

Bloated JavaScript Code

Here it is simplified:

Simplified JavaScript Code

Not only is the simplified version shorter, but it’s easier to read. Try to write clean code. Your best indicator of clean code is you won’t get questions on what your code does. There are good resources out there on how to write clean code, read or watch them.

5. Magic Numbers

I often encountered a loop that needed a specific number of iterations before it exited. Knowing that number, I added the value directly in the code. No variable, no comment, just a number.

Why seven?

Quick, easy and done. The next engineer will understand that this will loop seven times, but they will not know why its looping seven times. If months or years pass before another review, it may need to be run several times to understand why it loops seven times. Or you’ll need to ask the original coder, why seven? Coding shouldn’t be a philosophizing endeavor. At the very least, you comment the code why the magic number is used. When possible, avoid them.

6. Shotgun Surgery

If you ever hear another engineer during a planning session mention that the same logic will be needed in multiple places, immediately identify why. If you discover the need to use the same code in multiple places, do not cut and paste the code, talk to your team.

It seems much quicker to copy code in multiple places versus thinking through and properly abstracting your code. However, you’ll spend far more time tracking all your copied code to make a change, rather than updating one place.

On a side note, some people struggle growing their careers by spending too much time maintaining various aspects of lower tier work. This keeps them from developing the necessary skills to get promoted. And it doesn’t help that your peers will struggle trying to fix your code and may provide negative reviews.

7. Hard Coding

In my first coding job, I was tasked to create a web interface for an old flat file database. They didn’t need an elaborate solution, something quick they could use for those rare cases that came up for review.

The file wasn’t large, loading it into memory was reasonable. I worked with our network guys to ensure the file was hosted in a shared directory with the required permissions. Then, coded the path directly into my logic.

Hard coding prevents us from obtaining data from an external source. As you may have already surmised, the path was changed and my code broke. Thankfully, I gracefully handled the error with “Network guys moved the file so don’t blame me” and it was easy to track the new path.

While easy to fix, it took longer than necessary. I had to recompile my code and run it through our deployment process. Had I placed it in the web config file, a quick update would have solved my problem much faster. This issue is exasperated with large code bases that take a long time to compile. If external data is required, work with your senior or lead engineer to learn where you can keep it to avoid a full recompile. This problem is made worse during a critical hot fix that impacts customer ability to use the product.

8. Speed vs Quality

Is it better to create code quickly or create quality code? Most engineer will answer quality code is best. Yet, when faced directly with this challenge, we tend to pick speed. Business always want to go fast. New engineers have the added pressure of watching their peers complete their work faster than they can. Who gets the good work? The fast ones! Or so it seems.

As a new engineer, writing code quickly is what led to most of the lessons I learned. If you write quality code, you will naturally be fast. Completing your task quickly won’t matter if code reviews or QA is often returning your work. Focus on quality, always. As Robert Martin says, “You’ll only go fast if you go well.”

9. Excessive Abstraction

After a few months on my first coding job, I often needed to make database call to obtain the same information. At this point, I had several internal web pages all dealing with Employee data. Since I was given each page to work on individually, I never thought to abstract my database calls into its own class that could be shared across the pages.

Once it hit me, I quickly made a new class and moved all my database calls into it. As I was moving my database calls, I noticed something. I always had to connect to the same database, always pulled three pieces of data, and always had to close the connection. I abstracted these pieces into their own methods.

I further realized; my queries could be programmatically built. I abstracted my query string builder so I could build any query by only sending the fields and tables to a method that would generate the query. I further abstracted my table selector string so I could send a name or number to add to my query string builder to get the table or tables I needed.

When I was done, it was a mess. It was difficult to debug whenever a query was malformed, and worse, performance optimization was nearly impossible since it only built to use one type of join. Sure, I could have handled that, but it wasn’t worth it. Opening and closing my database connections was all the abstraction I needed. It helped simplify maintaining my connection strings. By keeping everything else where I used it, I could easily optimize the query for its specific purpose.

There are all sorts of opinions on how much is too much or too little abstraction. With experience, you’ll learn to balance your abstractions. Work with your leads or senior engineers, they have the experience and will guide you properly. I thankfully do not have this sample of code to share.

10. Performance Costs

Learn the costs of whatever pattern, structure, or database calls you use. While memory is cheap now, time isn’t. Poor performing code can lead to longer load, processing and/or debugging times. Generally, this isn’t an issue until you work with large datasets or code bases.

Most engineers code with a small or limited data sets on hand. While the logic may be sound, performance may not. Keep in mind to test your code with larger datasets for performance. Queries are notoriously inefficient when not properly optimized. Performance, like QA, starts with the engineer.

Conclusion

Hopefully you found this helpful, especially if you’re new to engineering. Keep trying, don’t be afraid to fail and you’ll make it!