As part of the SEED project, I recently talked with Brian Blose, a Software Developer at Giant Eagle. In this interview, Brian shared with me that software engineers need to be adept at gathering the requirements of the systems that they will implement. Brian also stressed that it is important for software engineers to seek out and learn from mentors. Read Brian's responses to the three SEED questions to learn more about his unique perspective on the engineering of software.
While most wouldn't expect it of a regional grocery chain, Giant Eagle is one of the larger information technology employers in Pittsburgh. This is mostly due to the company philosophy of building software in house instead of buying commercial-off-the-shelf products. Giant Eagle's pharmacy pushes approximately a third of prescriptions chain-wide to a central processing facility where robotic systems dispense pills into bottles, then drop it to an assembly line for workers to package and ship to individual pharmacies. I have the fortune — and occasionally the dismay — of building and maintaining interfaces between the software of this facility and our store systems.
Requirements gathering is consistently the most challenging aspect in software development for me. Some of this can be offloaded onto a business analyst if you're fortunate to have one on your project, but often you need to sit down with the people who will use your software — not their boss or the director of their department — and learn how they do their job in order to shake out the important details. The alternative is hacking together a series of emergency fixes to account for the incomplete specs.
No one expects the new developer to be an immediate star in the corporate world. Obtaining your degree in Computer Science is a huge accomplishment, but there is so much more to learn — some of which will be unique to the organization that employs you. If you are not formally provided a mentor, then identify someone knowledgeable and personable enough on your team to answer questions and provide advice.
Do you have any questions about this interview? Or, do you have a response to Brian's ideas? If you do, then I hope that you will contact me to share some of your thoughts. Or, do you want to be updated when I publish new interviews in this series? If you do, then please subscribe to my mailing list.
Enjoy this post? If so, please read, Using real faults to evaluate test suite prioritization techniques, my most recent article.