Siemens

They got me a job as a junior developer, which I am very grateful for. They coincidentally had just brought someone in to train the team on the software program we were using when I first got there.

Unfortunately, I didn't have a good frame of reference to understand what to ask because I had never used the software. It turned out that using the software wasn't much of a problem anyway, but I appreciated being introduced to it in that way.

To help get me up to speed, I would pair program with the worker next to me a bit each day for at least a month. We also went to an event where someone talked about the stuff they learned taking a course from the company, so they do have some resources and interest in growing the employees.

The code was mostly written in a hacky scripting language, which isn't used outside of this project. Besides making the software harder to write and therefore also harder to read, it also meant you weren't gaining experience in a particular language, which can be helpful in getting the next job.

The work involved late-stage bugs where you were digging through log files trying to figure out what happened. As it goes with late-stage bugs, the bugs were more difficult to track down.

Although I really enjoy coding, I found the experience of working there low-energy. It seemed like just another office job with no energy or excitement.

I would say the choice of technologies could have probably been better. Having an end user who is excited about the product makes development more rewarding and gives a needed perspective on what development truly matters to the customer. I would do extreme programming, where things like test-driven development, pair programming (one observing, one driving), whole team, and design improvement result in high code quality and more collaboration and knowledge sharing within the team.