(This is the third and final post in a series by Joe Bustamante, a Hope senior who spent the summer as an application development intern at Open Systems Technologies in Grand Rapids, MI. In this series, Joe describes his internship experience and how it relates to his learning at Hope College. Our apologies for not getting this one out sooner!).
It’s odd to think that school is back in full swing and I now have homework and other responsibilities that weren’t present this summer. The first week of classes may have just finished, but my mind is still partly in a summer mindset, especially when it comes to software development. I finished up my internship at Open Systems Technologies just a few weeks ago, but I’m still thinking about the opportunities I had there and some of the things I learned in the process. As I start up another school year and attempt to put many of the skills I practiced this summer into effect here at Hope, I’ve realized I can sum up some of what I learned this summer into three big takeaways.
The first big thing I realized from my internship is that application development is a team job. For the most part, any software system with even a mediocre level of complexity or size requires a team of people to build and maintain. As I worked on some larger systems this summer (at least, larger than some of the projects that you typically get assigned in classes), I realized how necessary it is to have good communication with your team. The only way to keep so many moving parts working together is not only with good architecture and design, but also maintaining constant communication throughout the development process. Any project that involves more than a couple branches of work necessitates that those branches have both a clear vision and purpose, as well as a cohesive way to handle any conflicts that arise as those branches are continuously merged back together.
Part of this first realization was also coming to understand some of the differences between the two main fields of development work: consulting and product. In consulting, communication is crucial since working with clients and meeting customer demands on a regular basis is key. Especially in a place that develops with an agile or agile-like methodology, and where regular demos and constant gathering of requirements are important, communicating effectively with both your team and a customer is an invaluable skill. That isn’t to say that communication isn’t also an essential skill in product development, but it takes a different form. The focus tends to be less on communication with the customer and more with your team and the rest of your organization, unless customer relations is part of your role. Either way, it’s important to think about what kind of a team dynamic you want to work with when trying to find a job as a developer. For me, I think this summer has shown me that working as a consultant on a small team within an agile methodology is one kind of dynamic I’m comfortable in. However, that might not be true for other people, and thus it’s important to try and get a feel for that dynamic at a potential workplace.
The second important realization I had this summer, and one which I’ve talked about a lot in previous posts, is the importance of continuous learning and question asking. There’s always someone who knows more than you or is more experienced than you. Seeking those people out to grow your own understanding is a valuable part of the of software development. Besides the actual programming and designing I did this summer, one of the main ways I learned and grew was from looking at the code that other people on my team had written, especially the more senior developers. Seeing the ways that other people solve similar problems is a great method to grow your own understanding. Code reviews work in tandem to this. Having other people look at your code and ask you why you did things the way you did is good practice for making you think about your decisions. Additionally, it lets others show you any of the potential errors or bugs you may have missed.
That said, it’s also important to have confidence in your ability and voice any questions you may have about the work of others, even if they may have more experience than you. At the very least, asking about things that don’t make sense to you will help you understand better, and it might even possibly uncover a bug or mistake in your team’s code that others didn’t realize. Imposter syndrome is a very real thing in the development field, and something that doesn’t always go away, even as you gain more experience. As most people who have ever been in the position of being the “expert” on something know, the pressure you feel when everyone looks to you for answers is often times even greater than what you feel when you just start out learning something. All that to say, never be afraid to ask questions and be confident in your own understanding of programming and the disciplines that surround it, and seek out the knowledge and advice of others whenever you can.
This doesn’t mean that you need to have a formal degree in computer science, of course; plenty of developers are self-taught or never went to college. However, the fundamental theories behind programming and computing that are taught in a computer science curriculum are invaluable to creating good software and making smart design decisions. Even if you don’t directly use some of the knowledge you gain in more specialized systems, the process of learning those things itself provides a huge benefit when it comes to learning new technology. And you never know – you may just have to work with some framework or technology that uses some of what you learned under the hood. That was also the case for me this summer. As my team was developing the Alexa skill and our cloud backend, we were using a lot of promises and asynchronous frameworks. Though my experience with asynchronous programming was minimal, and I had never used these frameworks before, the learning I did in my advanced algorithms class helped me understand what was going on in the background and fix some bugs when they came up. Even though I didn’t have to actually implement any parallel or asynchronous functionality besides what the frameworks provided, knowing how those concepts worked allowed me to find bugs and use those frameworks more effectively.
It was an incredible opportunity to be able to work at OST. It’s hard to sum up everything I learned into a single blog post, but I think these three things encapsulate the summer well. Spending a summer working on a team and developing an actual product has helped me realize that software development, and especially consulting, is something that I would love to do as a career. Being able to gain hands-on experience through an internship was a valuable way for me to come to that realization about software development, and definitely something I would recommend to anyone else interested in the field.