Week 11. Post 3.

 After this experience, are you considering a career in this specialty area? Why or why not?

This summer I have been working in a software engineering team that was developing a scientific search engine for NCAR. My team's organization felt like a real industry environment as we were using the Agile Scrum framework and many other things that people in the industry use. We worked on both the front-end and back-end of the web application and were deploying our work to "production". It was nice to see how everything works "behind the scenes", how to manipulate database queries, how to work with Java-based frameworks etc.  Thus, I had a nice exposure to what it is like being in a software engineering team. 

Before coming to this internship, I was not quite sure if I would like to go with the software engineering path or if I would choose something else. I thought that software engineering is very challenging and only genius people can do it.  However, I discovered that as long as you put effort to learn - it is not as hard as it can seem. I realized that I would love to continue in this direction - I feel that I enjoy seeing the results of my work on real-world applications and that it is bringing impact. I do not see myself in the research aspect of the CS because I do not think that I have the patience for research that take years. Plus, I saw other research-based projects at NCAR and I realized that I definitely would not enjoy doing something similar to this. 

The lesson I learned is not to put limitations and restrictions in your head. The CS field is very vast and there are many different roles out there and it should not intimidate you. On contrary, it should motivate you to keep exploring yourself and trying new things. 

Week 11. Post 2.

What could be the implications of what you learned from this experience for your future work career?

One of the biggest implications of this internship experience for me has been becoming certain about my decision of having a software engineering career after graduation. Before the internship, I did not feel confident in my skills and sometimes doubted whether I wanted to work in the industry. This industry always felt intimidating and it seemed like only super smart people will be able to get in there. However, in this internship I learned that as long as you have eagerness to learn - you are good. 

Moreover, because I got a better understanding of the industry through my internship, I feel a lot more prepared to transition to a full-time job. The fact that I know what life as a full-time engineer is going to be like from first-hand experience gives me peace of mind.

In addition to this, another thing that I learned in this internship is that getting a master's or a PhD degree is actually beneficial in your career. One might think that you do not need grad school for CS, however, I realized it is not true. Grad school in CS opens more opportunities in the future and leads to a potential increase in the salary and career. 

Lastly, I learned that software engineering is not the only career I can pursue in the tech industry. I can always switch to other roles and a master’s degree is especially going to be useful in these cases as well.

Week 11. Post 1.

 What past experiences have contributed to your understanding of leadership? How do these past understandings about leadership influence your behavior or decisions regarding your challenges presented by this internship?

One of the first times that I was given the opportunity to practice true leadership and learn about leadership was at Berea College, especially in the computer science department. One thing that I love about the CS department is that they care about students’ voices and opinions. For every major decision that is going to affect the whole department, including students, we are asked for our input. In addition, in our labor positions as teaching assistants, we are trusted and expected to think critically and make informed decisions. I believe that both of these values are essential in leadership positions: to not be afraid of asking for others' opinions and trust your coworkers.

As a teaching assistant, the above-mentioned values really helped me gain confidence in myself, and become confident enough to speak up and share my views. Moreover, the CS department, specifically my position as a teaching assistant, helped me develop my own leadership skills by giving me the opportunity to introduce new ideas, lead discussions, and bring in new proposals.

In terms of the challenges presented in my internship, I will utilize these learnings to ask my team members for constant feedback. Moreover, because I practiced leadership at Berea College, I am not afraid of taking the lead and proposing new ideas or projects to the team. 

Week 10. Post 3.

 

How have your interactions with colleagues from varying backgrounds holding differing perspectives developed your perspectives?

My interactions with my colleagues and the conversations I have had with them has really broadened my perspective about what I can do with my computer science degree. Working in a software engineering team in a non-software engineering tech company really helps you grasp all different intersections of CS with some other field. At my internship place, most of the people come form natural science backgrounds such as physics, chemistry, biology etc. 

I originally thought that to work in the tech industry one would need to come from a computer science background. However, as I talked to my colleagues I realized that people who work in the tech industry come from a lot more diverse and sometimes unexpected backgrounds than I thought previously. I learned that because tech industry is constantly growing there is always need for new perspectives and skills and any of the previously mentioned concentrations can somehow translate to an area of need in the industry. In addition, it is not hard to learn software engineering skills later in one’s career and convert to being a software engineer.

In contrast, I have other colleagues who first majored in computer science, worked as a software engineer, but then realized that might not be the job for them and decided to change their career. Yet, they did not completely went off from the CS field - they just shifted to some other jobs such as product marketing/management etc. 

At later stages of my life I will try to explore as many different fields of the CS as I can, not trying to limit myself just to software engineering. 

Week 10. Post 2.

 What is one of the most important things you learned at your internship?

Today I learned that to be a great software engineer, I need to be a great storyteller. As Albert Einstein rightfully and gracefully said, ‘If you can’t explain it simply, you don’t understand it enough’. The same applies to every day of my internship as a software engineer. I have to work with a multitude of stakeholders within an enormous variety of domains, and simply sharing code upon their request isn’t what my job is supposed to be. As a beginner software engineering intern, this is the number one mistake I’ve been committing: simply sharing the code that non-technical audience can’t really interpret or any audience can be overwhelmed with. Code has an important story to tell, and as a software engineer, I am relied upon to give this code a clear and convincing voice. So, now I am working on improving my code storytelling skills. I now know that code storytelling/explanation isn’t just trying to explain the technical aspect of it. Rather, I try to focus on developing in all three important areas of coding storytelling: technologies, visuals, and narrative, that all comprise a structured approach to communicating task insights. When I craft a deliverable to a stakeholder, I now try to make sure my narrative is coupled with code so that it helps explain what’s happening in the code and why a particular insight is important — and here I try to insert as much context as possible. Visuals can enlighten the audience with insights they might not otherwise see. When visuals and narrative is paired, it helps me make sure the audience is engaged with the story. Lastly, when all three components are combined, it helps me make sure that the code story influences or drives change.

Week 10. Post 1.

 What recommendations would you give to other students doing an internship?

I would one of the most important skills that I have learned in my internship are not even technical. Technical too, but mostly I would say it is soft skills such as communication. I worked in a relatively small team and 70-80% of my work heavily relied on communication. 

Before coming to this internship,  I have been always underestimating the power of communications. I always felt that as long as I have good technical skills - I am good to go. However, I realized that even for software engineers, communication in the team is a key. For example, if you working on devleoping a certain feature and your mentors gives you some instructions on how to implement it, in your head you might have a completely different vision and understanding. Thus, it is highly important to keep always communication your process of developing and how you are feeling about it. After I came to this internship, I was fascinated by how my mentors interact with each other - how clear their thoughts are always are, how concise and comprehensive their speech is etc. I realized that having good communication skills are not less important than your technical skills. 

Thus, I would highly recommend working on your communication skills, how to express your thoughts well, how to address your technical questions better, how to convert your technical mindset to non-technical when talking to managers etc. On my next internship, I will try to work on my communication skills harder by practicing some of the advice for good communication practices. 

Week 9. Post 3.

 What have you done that you didn’t ever think you would be able to do?

My internship is two weeks from coming to an end and I am fascinated by the amount of work that I and my co-worker have done. During this internship, we were able to implement a whole lot of new features into our search and harvester applications. One of the biggest improvements that we have made is that we have developed a validation feature that would allow displaying only valid scientific data into our search application; in addition to that, we have developed a faceting feature that would allow us to filter scientific data based on its resource type; in addition to this, we have implemented sitemap so that our metadata would be indexable by Google Scholars and many other features. 

Before coming to this internship without much prior experience in web application development, I always thought that it will be enormously hard and impossible for me to develop big features. I always felt the imposter syndrome and that I won't be able to contribute anyhow to the development of the search application. I always felt that I lack the knowledge and expertise to do even minor changes in the source code. Especially I never learned Java and I thought I won't be able to code much. 

However, after starting to get used to the source code, designing, and problem-solving, I was finally able to work on some bigger problems and start implementing these relatively hard features. I realized that you should never be underestimating your abilities and just always trying to push yourself out of your boundaries. It is good to know your weaknesses, but never let your imposter syndrome block you from learning and putting yourself out there. At the end, I felt really nice and accomplished that I did not just give up but tried to solve it even if it was hard and continue learning. 

Next time, whenever I feel like I cannot accomplish something because of my current skill set, I will just try to break the problem down into smaller chunks and see if I can achieve at least them and what should I do for that. Instead of just giving up and getting overwhelmed with the thoughts of "I can't", I will try to ask myself: "What can I do to accomplish this task? Will I have to watch some tutorials? Will I have to ask mentors for more technical explanation" etc. 

Week 9. Post 2.

 Client's requirements VS your vision. 

This week we have been working on developing a faceting feature for our search application. There were no clear criteria in the beginning so I started implementing it in the way I vision it - filtering the resource types of our publications in the search in the format of checkboxes. So, whenever I check the box with a particular resource type of our data files and hit the submit button, it will only show this type of particular resource. However, after spending two days trying to get it done, I realized that this is not the kind of UI and architect design that the client wanted.

After I showed my work to my mentor, he said that it is not the way the manager would like to see it. My first reaction to this was not positive since I spent hours working on something that I would have to revert. This was the time when I kind of disagreed with the client's vision because the way he envisioned it was being able to filter only by one field. However, my code was allowed to facet by multiple fields. I felt stuck and disappointed that I had to revert and start all over again. For the first time, I felt like my work was just wasted. 

After this situation, I realized that my software developer vision might not always match the client's vision. Thus, it is highly important to really understand the acceptance criteria for the task before you start coding. I also learned how to be more flexible and not get stubborn about my vision. I learned that it is important to communicate better and ask clarifying questions instead of jumping straight into coding without any feedback. 

Next time, whenever I am given a task, I will make sure I understand every single piece of the implementation vision before starting to code. I will also try to make sure I will communicate more and ask for constant feedback throughout the development process so that I can stay on track as much as possible. 

Week 9. Post 1.

 What ethical, leadership or other challenges or constraints did your team face? What did you do to solve them? 

Two weeks ago it happened to be like that the code we wrote for completing the tasks did not quite match with each other and one of us had to revert the changes. However, the previous week we worked on separate tickets so we did not have to work together on the same task; which indeed produced good results. 

Usually, I am positive about working together on the same tasks but I noticed that it creates sort of a competitive environment where each tries to get the things done first and correct. I think that it would be much better to work on separate tickets and ask each other for help when needed. Pair programming gets hard when it comes to modifying a lot of files/classes/methods and code gets complicated. It saves more time and I felt it to be more effective. 

My first reaction to reverting my code was not super positive and quite dramatic. I felt like the work I have put in was just wasted; however, I tried to calm myself down and really understand that this kind of thing happens quite often to developers. Their code might not always be ideal and ready to commit. So, I realized that I should learn to objectively evaluate my code and accept critique. My code is not always going to be perfect and it will have a lot of coupling and other issues; thus, it is highly important to listen to the mentor's feedback about reverting the changes and if necessary then do it. 

Next time, whenever someone tells me to revert my changes I will try to react less dramatically and think carefully about WHY they told me to do so. Instead of being disappointed, mad, and dramatic I will think and analyze my code and accept the critique. 

Week 8. Post 3.

 How often do you ask your supervisors about their feedback towards your work?

Two weeks my mentors mentioned several comments regarding my skills of presenting during the demo presentations. They said that I should talk slower, and explain things on a less high level so it is understandable to our client since he does not have much of technical background. He also gave me feedback that I should give more of a background context and point out things more clearly. Last week I have been trying to work on those skills, and before the demo, I did a practice demo with my mentor trying to get more feedback before the actual presentation. This week I finally did a much more successful demo, where I was talking slow enough, giving good context/background, and pointing out features more clearly. I got positive feedback from my manager saying that my presenting skills improved. I was very happy to see that I am making progress in my presenting skills. 

Before coming to this internship, I always felt like I can progress without having any feedback. I looked at feedback as something not really important as I felt like at the end of the day nobody pays much attention to feedback and they just continue doing whatever they were doing. However, during this internship, I realized how valuable feedback is, especially if it is coming from someone who is much more experienced than you in the field. They give you a whole new perspective on what you are doing - things that you never thought of and the things that you thought are good. Before my mentors' feedback, I would always be thinking my presenting skills are good; however, after their feedback, I was like: "Oh, that is right. I should really work on these aspects of my presentation". 

Next time, whenever I am preparing for a presentation, I will always try to practice in front of someone and won't be afraid to ask for feedback. I will stop underestimating the value of feedback and really listen carefully to what people think about my presentation. I will try to at least practice in front of myself and try to give myself honest feedback about my performance as it can drastically improve the overall presentation. 

Week 8. Post 2.

What is your extent of interaction with colleagues? Is it formal or informal or both? Does your interaction with colleagues involved topics beyond the task at hand?

Last week my mentors invited us, interns, for a lunch together outside of the office after our Friday demo presentation. We went out to eat at a very authentic restaurant in Boulder that my mentors used to go to a lot before the pandemic. 

When they invited us for this lunch, I was very surprised and excited. I was shocked because I would never expect mentors to initiate such informal settings as I thought they would only always set formal settings. Usually, our conversations are both formal and informal - it depends on the task we are working on but generally, our mentors are very nice and do not put so much formality on us. My mentors joke a lot, tell us personal stories and talk with us about things outside of work too.

Before coming to this internship, I always thought that the working environment is always super formal and mentors are never reachable. I always thought that there is going to be a strict hierarchy at work that would make me feel like I can never talk to my mentors on topics outside of work. However, we had lunch without mentors and managers and it was a very nice and informal setting for conversation - I got to know my team much closer and it even made it easier for me to work with them later. I realized that having such informal settings is highly important for team building and my stereotypes about mentors were crushed. I found out that they can be informal too and there is not much formal hierarchy that they put on you during work; on the contrary, they talk to you kind of o the same level. 

Next time, before having certain stereotypes in my head about certain people, I will try to objectively evaluate them and ask myself self-guiding questions such as "Where is this stereotype coming from to my mind? Is it a fair judgment to have about a certain group of people?" etc. 

Week 8. Post 1.

 How would you describe your work style based on your behavior at this internship?

Couple of past weeks I have been actively working on developing new features and fixing previous bugs with my teammates. We have made a lot of progress in our work and we could see our code doing the real-life functionality on a real application. Thus, I have noticed some insights about my work style during the internship.

Before coming to this internship, I always thought that I am an introvert and I always used to prefer to work alone. During the school assignments, I would always prefer to do the labs by myself if I had the choice. I always felt that working alone is much easier, faster, and more efficient. I always thought that working alone is much more productive and I do not need anyone else's input. I also always thought that pair-programming is something complicated and not efficient. 

However, after coming to this internship, I realized that I enjoy working in a team. I have noticed that working with people and implementing best practices of pair-programming is one of the styles of my work. When working in a team, I realized that I brainstorm better and come up with solutions faster; I also noticed that working with someone makes me feel less stressed and the work becomes more joyful and interesting. I noticed that I get more energy to do more work when doing something with the team rather than alone. I wish I have tried it better at school before jumping to conclusions and stereotypes about myself. 

Next time, before making any assumptions about my work style, I will try to make sure that I am implementing the best practices of a certain style of working. I will also make sure that I have tried it several times enough before making conclusions. I will also try to make sure that I am trying one particular style of working in different environments and settings. 

Week 7. Post 3.

 Have you seen ways in which your experience with the internship deepen your understanding of information technology or the connection of computing to other disciplines? 

I intern at NCAR (National Centre for Atmospheric Research) in one of their internship programs for various research and software development projects. NCAR is one of the sub-divisions of UCAR (University Centre for Atmospheric Research) and the way they incorporate each other is fascinating. This week we went to one Research Aviation Facility (RAF) Field trip which is one of the divisions of NCAR and is a national resource for the advancement of airborne research in the geosciences, with a focus on the safe operation of research aircraft in a wide variety of challenging sampling environments. 

When I first heard about this trip, I was very surprised that NCAR has divisions like this. When we came to RAF, I was very shocked by the fact that one organization can have so many facilities and management parts outside of the main office. When I saw all the research airplanes and all the instruments that they use for collecting and analyzing data - I was very impressed. 

Before coming to this internship, I thought that NCAR only has one lab and we will be doing software development in that lab. I would never imagine that there are so many office buildings that have planes that collect data in the sky. I always thought that a software engineering job is just always sitting in front of the PC and coding. However, this RAF trip has widened my horizons about the CS field - there are so many more things you can do out there. You can be a scientist who goes on those planes for data collection, you can be the engineer who prepares all the tools for data collection, you can be a product engineer who organizes all the scientific proposals and trips, and many more. I realized how CS is tightly connected to other fields such as physics, chemistry, and others. At NCAR, software engineers go with scientists on the plane to support some of the software that they use for collecting data and do so much more than just sitting in front of the PC and coding. This trip gave me a very big insight into the CS field in science. 

Next time, I will try to be more open-minded and think less stereotypical about certain jobs. I had this vision of software engineers as kind of a boring job as I thought they only sit and code 24/7; however, in the example of NCAR, I saw how CS can easily be applied and useful in other fields and how their job can be so interesting too. Next time I will try to objectively evaluate certain jobs and do more research about them before jumping into creating stereotypes in my head and being close-minded about it. 

Week 7. Post 2.

 

How has your perception of work changed since you started the internship?

What happened today during our normal Friday demo presentations where we present the work that we have done during the week was something that never happened to us before. Before we would create "tickets" or tasks in the Jira platform and then once these tasks are done and presented to the manager, he decides if our work meets the acceptance criteria and if we can move the task to the "Done" column. Today was the first time that one of our tasks did not get accepted by the manager because the feature that we added did not work during the demo presentation. I and my co-worker finished that validation feature on Wednesday and Thursday all day we have been just preparing for the demo presentation and cleaning up the code. However, Friday morning before the presentation we discovered some bugs that prevented us from showcasing our feature. 

I discovered that bug 10 minutes before the demo and my first reaction to this was: "How did that even happen? The validation has been properly working all this time and now just suddenly decided to throw errors?" I was surprised and panicking. I immediately went to my co-worker and ask him to present my part with the validation. However, when we went to the live demo, his validation has not been working too. I felt very disappointed and sad that we could not showcase our work to the manager and felt kind of guilty as it seemed like we just wasted the whole week on something that ended up not working. 

Before coming to this internship, my perception of work was slightly different. I thought that once you are given the task and the deadline for it, you must complete it perfectly; and if you don't - that means that you are not a good worker, you are not bringing value to the workplace and you should feel guilty about it. However, after today's demo, my perception of work has changed. Even though our ticket was not accepted by our manager and the feature was not working the way it is supposed to, our manager told us that we still accomplished a good chunk of work and should feel proud of it. His words gave me a new insight that sometimes things might not work perfectly, but the fact that you tried your best and learned a lot during the process is also an accomplishment and that you should not treat tasks as "Done" or "Not Done" but take it more as a learning process. 

Next time, I will try to make sure that I react normally when things do not work perfectly because, in the world of software development, bugs appear all the time especially when building something gets very complicated. Next time I will make sure I objectively evaluate the work I have done and do not feel guilty for not getting things to work perfectly all the time. Sometimes the process is more important than the result and I should be considering that next time.