3 Lessons I Learned About Software Engineering During My Internship at Siemens

Ashton's Blog

2025-08-09

The main glass doors of the Siemens State College office.
This summer I interned as a Lifecycle Visualization Intern at the Siemens DISW State College, PA office. Alongside the 2D/3D Visualization team, I worked to implement features in new performance modes to improve UX. The experience was incredibly transformative, both personally and in my understanding of how software is really developed. The goal of this post is to share the important lessons I've learned for those yet to get their big break.
Teamcenter PLM's Active Workspace, where users can view, manipulate, and analyze product models.
The first lesson I learned is that effective communication is a hidden strength. I had previous experience with stand-up meetings during my IT job, but in a software environment I did things a bit different. Every day before our stand-up – sometimes even the day before if I wanted to retain focus – I would write down the day of the week, what I did, what I needed to do, and what was blocking me from moving forward. While this may sound trivial, this log served as a personal guardrail; it kept me on task, and it also helped me to quickly switch gears whenever I needed to.
The daily logs didn't just serve me, though. They also served those around me. Anyone could approach me at any moment, and I was ready to answer – even if I was completely lost or out of gas. More importantly, they served my mentor and manager. It informed them of the pace I was able to keep up, juggling different tasks and getting them done quickly and effectively.
I would also recommend writing other things down, not just your daily log. So often I found myself flipping back through pages for something I knew I wrote down ages ago – like what command I had to run here. I saved myself from asking dumb questions many times. One highly respected engineer in the neighboring cubicle – who had the ability to make anybody laugh – jokingly remarked, "I like you because I only have to tell you something once." I didn’t feel less intelligent taking notes, because who could really remember everything in their first few weeks in a new role? If anything, note-taking shows you respect others' time and that you want to learn.
The second lesson I learned is that asking the right question, not every question, can be surprisingly difficult. When I ran into a problem, I wrote the question I had in my notebook. However, the contacts I had were periodically tied up with other things, so I would be forced into answering the question myself. Surprisingly, I was usually able to get the answer on my own. All I needed was to push myself just a bit further.
Through my internship I had access to LinkedIn Learning, and through a problem-solving course I took, I learned of a technique called "The 5 Whys." Essentially, as you observe a symptom of a problem, you ask why it’s occurring, which reveals a new symptom each time until you find the root cause (hopefully 5 whys is enough). This technique saved me on numerous occasions from asking an unnecessary question, and it also helped me to not give up on myself.
One example involves a rotation feature defect where a standard view would not always return to the same place. I noticed that the reorientation worked in our testing environment but not in the full build, why? After playing around I noticed that if I rotated the model in the full build, it perfectly lined up with the desired orientation. The difference was that the rotation setting in the full build was different from the test environment. Once I identified the root cause, all I had to do was specify the setting with one line of code to fix it. Something that seemed difficult to fix because I couldn't reproduce it in the tests was not so difficult after all.
The third lesson I learned is that it is okay to fail forward. So many times I felt like I didn't have the information to move forward, but almost every time I was just missing one minor detail. I often find myself getting into this fear-paralysis, where I don't understand the totality of the problem and its solution, so I am apprehensive to try. This behavior comes from my ingrained fear of failure, but looking back I realize that failure isn't the right word for it.
My last project at the internship was at the junior engineer level of difficulty, and it felt like a big test. Initially, it felt like nothing made sense, like I had pieces to different puzzles. I made it my goal to simply hack something together, anything that would work, and then I could expand on that. It was a good approach because it was noncommittal to bad ideas; once I found something that stuck, I ran with it. While it was ugly, nothing was in the right place, and it wasn't well documented, it was enough for me to plant my feet and get started.
I’ve sold myself short before out of fear or doubt – but those boundaries were artificial, and I’m not going back.
I want to express my immense gratitude to the incredibly talented engineers and leaders at the Siemens State College office. From start to finish, they all showed kindness, patience, and willingness to help me at any moment – no matter what I was stuck on. While my internship is now finished, this is only the beginning for me, and I’m excited to see where life takes me.

My other posts