Three Tips For New Engineers

Dojo Five firmware engineer works at a computer on code

With a bachelor in Electrical Engineering and a few coding experiences, I started my job at Dojo Five. What’s waiting for me were demos and releases that surprised me with unexpected results, challenging problems that took hours to solve, and software, tools, and technologies that I never saw or heard of before. Here are some tips that shaped me into the firmware engineer I am today.

Tip #1: Expect the unexpected

After working for a couple of months, you will start to realize critical events such as product demos, internal demos, and even product releases will not always be smooth. During demos, there are times when you end up saying “It literally worked yesterday”. Testing or having a mock demo ahead of time is necessary, but the truth is you will get nervous or have your mind go blank during the demo. Therefore, a demo script with detailed steps that can be used to reproduce the demo comes in handy. What if it still doesn’t work with the steps in the demo script? You will need a plan B. The plan B can be a demo video showing the time when it worked or a good explanation of how it works.

We have been talking about demos, what about product releases? Code reviews and CI pipelines with tests reduce the risk of messing up releases but there is one thing we take for granted, the availability of the services we are using. In my case, it was the version control provider. This totally bit me once by having a 2-hour downtime in the middle of a release and now I am able to prevent this from happening again by subscribing to the status page provided by most of the version control providers. By subscribing to these pages, whenever there is scheduled maintenance or service disruption, you will be informed through the email.

Tip #2: Don’t spin your wheels

As a fresh graduate who just started the journey as an engineer, we often encounter challenging problems that will take us forever to resolve. Especially working in a services company where timing is critical, we do not want to use up the budget without finishing the promised features. When you start working on a feature, you can start by estimating the total amount of hours you might use to complete the feature. This will give you a rough idea of when you should finish the feature and start working on new features. Unfortunately, there are unexpected blockers that keep you from completing the feature. Instead of burning hours resolving the blockers, you should know the time when you need to approach someone for help. When is the best time to do so? There is no right answer. When you find yourself not making much progress after searching online or not knowing what to search for, STOP. Don’t fail silently! This is the time you should ask for help. Ask for help in an internal group chat or during co-working with others. This often gives you the answer much faster than searching online.

Tip #3: Quick learning and notes taking

University cannot teach you everything. It is normal to encounter new hardware, tools, or processes in your job. They can prevent you from completing your task. Learning new tools can be time-consuming but you do not have to spend hours learning in-depth details about them and how they run. Instead, you can take 5 to 10 minutes to focus on learning the new tool you need and at the same time taking notes for future uses. By spending some extra time now, it will save you a lot of time later. This can be applied to the issues you encounter when implementing a feature. You can keep a note of the issues and solutions found by asking for help from others or by using Google. By having the notes, when the same issue shows up again, the time can be used to implement new features instead of researching and learning.

Conclusion

Being an engineer can be challenging but solving real-world problems and pushing the edge of the technology is what engineers do. Planning ahead, asking for help when you need, and taking notes after learning will help you be a successful engineer who impacts the world.

And if you are looking for even more on embedded ops, we host a weekly Lunch and Learn on a variety of topics from embedded on cellular, deep learning with robots, and more! Check out our current list of events  and sign up for your seats – always no cost!

Discover why Dojo Five EmbedOps is the embedded enterprise choice for build tool and test management.

Sign up to receive a free account to the EmbedOps platform and start building with confidence..

  • Connect a repo
  • Use Dev Containers with your Continuous Integration (CI) provider
  • Analyze memory usage
  • Integrate and visualize static analysis results
  • Perform Hardware-in-the-Loop (HIL) tests
  • Install the Command Line Interface for a developer-friendly experience

Subscribe to our Monthly Newsletter

Subscribe to our monthly newsletter for development insights delivered straight to your inbox.

Interested in learning more?

Best-in-class embedded firmware content, resources and best practices

Using Artifactory for Efficient Artifact Storage

Using Artifactory for Efficient Artifact Storage

Introduction Managing software artifacts efficiently is a critical challenge for software development teams. Whether you are dealing with versioning issues, dependency management, or maintaining previous builds for rollback and debugging, an inefficient artifact storage solution can slow down development cycles and introduce errors. Below is a list of questions to consider artifact management in your CI/CD processes: Are the number of binaries for your projects growing and struggling with tracking and retrieving different versions of your software builds, making debugging

Read More »
Test Equipment Automation

Test Equipment Automation

Written by: Danielle Thurow, Sr. Firmware Engineer Testing embedded systems is always a difficult issue. Testing on the actual hardware is critical for seeing what the real world product will do, but a lot of times engineers will only have one or two development boards while the hardware is being developed. This makes it difficult for multiple engineers to use especially if they’re working remotely. One way of dealing with this is setting up Hardware In the Loop (HIL) setups.

Read More »

Troubleshooting: Some common, but often unchecked, assumptions to investigate

By: Bailey Steinfadt
Are you tearing your hair out trying to find the root cause of a bug? Have you been troubleshooting the same problem for days and feeling like you’re getting nowhere? Minimize your IDE, put the keyboard down, and ask yourself a simple, but hard question…What do you know for sure is true, and what are you merely assuming is true?

Read More »