Category Archives: software

Week 14 – Token #2 – CS-343

For this blog, I specifically wanted to look into how this class relates to the preferred field I want to go into, which is Game Design. I wanted to see what kind of languages would be used, what kind of design elements are implemented, and even in the case of frontend vs. backend, how online games employ servers.

However, it seems like I had a misunderstanding that these two positions were similar omewere, as I find many sources that say software design vs. game design are a completely different beast, which only made me more interested. I did some more research, and this lead me to end up reading this article below:

Software Engineer vs Game Developer – Which one is for you?

Specifically I noticed that software development has more rigidity when it comes to designing and delivering a product. Software engineers are usually employed to design a software to meet consumers demands, which usually entails specific features and options they’d want in the software you’re developing. Whereas with game design, you have a much more flexible development cycle, as theres a lot more creativity involved. You’re less focused on making sure specific features are available and more focused on delivering a product that is unique and interesting for consumers, and keeps them engaged.

Game developers also rarely work with programming languages when it comes to development of products. Game developers mainly use engines, which are interfaces that employ programming languages to create building blocks to build off of to create a video game. Software engineers mainly work with the code directly at almost all times, making sre each line is properly written. That’s not to say some game devs don’t work with code directly, some do, and many Triple A companies actually write their own engines using their own code, like in the case of Epic Games’ Unreal Engine, which is used to power their famous game Fortnite.

Something this article notes is that software developers may not need to worry about performance compared to game developers, and I can understand why they might say that. Games rel on having a fluid and enjoyable experience, and that is dependant on the performance of a game, making sure theres no glitches, bugs, or lag. However, I would argue that performance is still a factor within software design too, because what if a simple calculation process in a program takes multiple minutes? Consumers will still have an issue with that. While I do think it’s definitely a lot more important in game development, that’s not to say it’s not unimportant in software design.

And that’s all my blogs for this semester! I’ll be taking another of Professor Wursts classes next semester, so I’ll likely be writing again then. See all you readers come January!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint Retrospective 6

Sams ShipsHey guys, it’s a weird feeling to be wrapping up my last semester in my undergraduate career in computer science (and sociology). For this final installment of my AMPATH sprint series, I will just go over the general overview of what went on for my team.

Most of our updates went onto our PowerPoint presentation, which is going to be presented on May 15th, 2019. My team and I are looking forward to presenting the overall process of our group’s learning and working process, the many lessons we learned, our advice for future students, the work we tried to implement, and various other technical aspects of our project.

We decided that on top of the search bar work, it is also a priority to organize the git repository so it can be better organized and an open work environment for other classes. I think this is important especially when new people come in and cannot efficiently locate and access the files they need. As someone who was once new to an organization that had a lot of different projects and files to sort through, I believe that this is very considerate of the team to go with this.

With some limitations my team had to face, we worked around it to determine how we should move forward. The end result is pretty much a search bar that is attached to the toolbar. It cannot currently be live tested due to there being no backend but it can definitely be done in the future under certain circumstances.

It was interesting being able to observe how much planning you can start with but still end up having to take detours, starting new paths completely, or sometimes even needing to take U-turns.

I thought it would be important to pull some of the advice for future students from our PowerPoint and include them in this wrap-up:

  • Point out and address problems with technology right away because others around you might have the same problem(s) so you can solve them collectively
  • Do all team implementations in a separate component based on what you will be working on
  • Merge your work constantly to the master branch so each team can have the updated changes

A pattern I am noticing in a lot of teams or group projects is that not everything is going to work out in ways that you expected or were hoping for but you learn to move as a shifting team to make progress and continue growth.

Overall, I’d say I learned an important life lesson from this: if I am to contribute extra time on top of my technology career in the future to work on side projects, it will be a challenge to allocate time if it is a group initiative. I also learned that even when we try to communicate everything there is still more room for miscommunication, so there may be no such thing as over-communicating. I am happy to say that we always tried our best to move forward in all ways!

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Find Mentors || S.S. 10

Sams Ships (13)In this final installment of my individual apprenticeship patterns, I think an important one to write about would be Find Mentors. To summarize the main point of this one, I would say that it encourages people to observe their role and their surroundings to see where they can find the most value from learning or use their resources. It encourages you to look at things from one level back instead of blindly jumping into something right away.

Personally, I have been in a role where I had to figure out a lot of things that could have just been taught to me. I quickly learned that I would be able to ask other junior developers how they managed to learn things on their own and it helped me a lot. If other junior developers were not available, then I would work my way up to people who had the most recent on-boarding experience and hope that they could recall the process I was currently going through. For the most part, that worked out well!

Thanks to this pattern, I thought it was useful to think about and remind ourselves that even though our mentors will know a lot more about us, they still do not know everything. They are still continuing to learn as much as we are in their own careers.

I thought I should update this blog to throw in a little hidden announcement if anyone actually reads these that I will be learning at a company with about 100 peers going through the same thing. This makes me feel a lot more confident knowing that I will have a designated support system around me and have mentors around.

Overall, I agreed with the pattern. This is because I can testify with my personal experiences how useful it was to be able to utilize my resources including being able to ask mentors questions or just find my own. A common question I had for my interviewers was, “Will I have a mentor or support system along the way throughout my career progression?” Personally, it is important for me to have a designated place to go for support because it just takes one more worry away about having to ask somebody a question.

It is now time to conclude my individual apprenticeship pattern series! I hope you have at least learned one thing from it because I have learned so many things.

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 5 Retrospective

Sams Ships (14)Over the past two weeks, my team continued to discuss what we are working on as usual. We have come to the conclusion that we will add our Search Bar component once there are updates and more of a base to work off of. This was concluded after we realized that the process would be much more efficient. The parameters and details on the search bar would be harder to figure out without making up a base anyways.

Some advice for others who may be working on the same thing would be to try and collaborate or discuss potential orders between groups if one thing may depend on another. That would make it much simpler from the start if possible so there aren’t any clashes or time wasted on doing extra work that could have just been done by one group or team.

In the meantime, I did a little more research on the AMPATH system out of curiosity since we are going to be building onto their work. I found out that there are 500+ care sites in Kenya! It is interesting to think about the potential impact our work may make on how AMPATH carries out their process. Their initiative reminds me of what Enactus at Worcester State strives for when they work on projects to help people or organizations in the community “sustain their own success, connect them with universal health insurance, train next generation medical professionals, and research new breakthroughs and best practices.” Being able to help a healthcare organization is pretty meaningful, especially as a project through my capstone.

A way to tie our 348 course (Software Process Management) with our 448 (Capstone) course would be through now being able to use Travis CI and Heroku. It was interesting being able to experience using these in class and help our peers use it and now be able to use them in our capstone. I think the practice we got was nice because I found that my peers and I were more comfortable with following steps that were written out and explained to us instead of just “going for it.” I have also noticed that our 348 course helped us pay more attention to how we interact with others, which is very useful for the future when we will be working in teams of developers to create or update new technologies. One more thing which I found useful was seeing Travis CI load, and the race against time when it came to classmates pushing code at the same time; it made me push myself to be a little faster while at the same time not be sloppy about what I was putting into my code.

Overall, we discussed what we will do in these coming weeks as the semester comes to a close. The project we are planning on presenting will feature a search bar which we plan to implement by then. I am excited to see what we end up with in terms of helping AMPATH and their healthcare system!

 

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 3 Retrospective

Sams Ships (11)Hey guys! This sprint retrospective will cover what the WSU Coders Without Borders team has done from the week before spring break and up until this week.

As the project is propelling forward even more than before–due to us having more concrete plans to begin working on the project, it has been an exciting transition. We saw our options from Greg’s wireframes and explanations through his YouTube videos. From there, we created Zeplin accounts so we could visually understand and remember certain parts of the app in progress.

Since it was my first time using Zeplin, I wanted to add a little review of it. As someone who loves to organize things, I found that it is a great tool to have for sorting projects and handing off designs and style-guides to other users. It seems like an effective way to share ideas directly with people.

The overall WSU team now has a GitHub section for dividing up the components and issues we will be working on. So far, my team is going to tackle the search bar and everything else it would entail to create. It was nice being able to collaborate amongst one another to find a component that we agreed to work on (and the fact that a few other components had already been assigned to some teams helped our decision be made faster).

From there, we were figuring out what we need to do and how we can get things done. We discussed some potential ideas with Professor Wurst and from there continued to brainstorm for the search bar. There is nothing that comes to my mind that I would have chose to proceeded differently with if I could go back.

We are continuing our meetings as they have been scheduled and are actively participating in our stand-ups. I like being able to scroll through the log of my team’s answers because it shows our progression throughout the semester as well as serving as a reminder of when we did something specifically. I am happy to say that my team does not seem to have run into any issues or potential miscommunication among one another. It really shows how we are all working to achieve something together and effectively communicate what is happening.

In this sprint retrospective I also wanted to discuss how what we learned may be applied in other situations like in the workforce. We have to make sure we are checking in with teammates to have them understand the project more and be able to express their opinions and concerns when they arise. Similar to the bystander effect in psychology, if there is no direct communication between members when it comes to getting things done, how will there be any progression versus just observing what is happening? All it takes is being comfortable to ask different individuals if they have anything to share or add to the open conversation.

Overall, I am excited to move forward and see what is in store for me and my team during these weeks up until the end of the semester!

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations || S.S. 7

Sams Ships (9)From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.

The points brought up remind me of a recent article from the New York Times titled Wealthy, Successful, and Miserable. What happens when the new-ness of what started as an exciting role to join in a company wears off and you are left off with unsettled feelings? It is up to individuals to keep going until they find what they love again or shift what they are doing a little to stimulate something new.

I like how the pattern encourages people to come up with a list of things that motivate them. It then tells them to reflect on what those things means or if there is a noticeable pattern from the things they have chosen. Having a list like this around to remind people of what they are working for is a reassuring way to keep them going. It reminds me of a post on LinkedIn I saw where someone kept a sticky note on their monitor screen that just had a number like “-$237.25” because it was to remind them of how much they had in their bank account when they started their job.

The pattern has caused me to think about the way I intend to work as someone who constantly likes to change things up or is not afraid of change. I do not disagree with anything in the patterns as it tells us to keep pushing and persevering by thinking about The Long Road, which is another apprenticeship pattern.

Overall, I think people interested in this pattern should read the NYT article I linked as well because it gives insight on the difference it makes when people do something that makes their work feel more meaningful.

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Breakable Toys || S.S. 6

Sams Ships (7)Recently, I have been seeing plenty of messages along the lines of “We learn from failure, not from success.” As someone who used to regularly watch all of Casey Neistat’s vlogs from the beginning days, it is something that has been ingrained in me to take risks and know that if I fail, then at least I did not give up and allowed myself to try.

When I saw the Breakable Toys apprenticeship pattern, I thought this would be the perfect opportunity to discuss trying things! This pattern is basically trying to explain to us that you need a safe space to learn something even if you work in an environment that may not allow for failure. It encourages us to seek our own way to sharpen our skills and take initiative, which would increase our confidence.

I found that this pattern is thought-provoking because where would you be if you did not take all the risks or new experiences beforehand to get to where you are today? I used to study biology and chemistry until I gave computer science a real chance. It was a little daunting at first to catch up but I made it (so far). If I did not take on leadership opportunities when given the chance, would I have the observation skills I have today when it comes to being involved on a team? Probably not!

If you do not allow yourself to try something out or practice something, I think you would feel a lot more pressure. It was reassuring to hear that someone like Steve Baker also experienced something like that, which makes it a lot more normalized.

As kids, we started learning how to interact with the world by playing with toys and developing our own sense of physics. Through that, we took risks like throwing things, sliding things down places, and etc., until we figured things like “oh, maybe I should not have accidentally thrown that ball too high and it went to the neighbors yard!” But at the same time, you’re a little proud that you’ve gotten better at throwing the ball harder.

That’s the same thing with developing yourself in your professional career. I will allow myself some time and space to learn something without that pressure and it may surprise me, once again, how far I may go.

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Use Your Title || S.S. 5

Sams Ships (6)Having a software-induced identity crisis? Worry no further, I guess that may be a more common thing than I would have expected! This week’s individual apprenticeship pattern will be Use Your Title.

I thought this was really interesting because there is such a high likelihood that there will come a time when you find yourself in-between positions but called something higher because there was no pre-existing label or category that would perfectly suit you. It may feel weird to have to explain yourself in your title to someone who assumes what you do based on what they see or hear. But perhaps, I wanted to add that I feel like someone could just be feeling imposter syndrome; which is something I heard is common for women in certain career fields tend to feel. What if someone does 100% fit the title they feel that they need to explain their title for but just does not see themselves the way their supervisors do.

I like how this pattern tells us that the title is due to the organization we work for, not necessarily us whether or not it does not match us enough or over-exceeds our abilities. By removing ourself from the current situation, I like how we are encouraged to think how we would view or think about someone’s role based on what they actually did in their job. This perspective was thought-provoking to me because I had not considered

Something I tend to think about is knowing when you need to step out of your comfort zone. When should you move on from one thing to the next; how do you know to take that risk? Seeing the little feature on David Hoover’s actions after he achieved his goals, it was interesting learning how he decided to move forward by continuing to draw his own map.

Overall, the pattern has caused me to think a little more on my intended profession in terms of where I want to end up. Right now, assuming I will have a junior/associate position after I graduate and later become a ‘senior’ or ‘lead’; where would I like to go after that? What will be my ongoing goal?

 

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Concrete Skills|| S.S. 4

Sams Ships (4)On this weekly individual apprenticeship pattern post, I’m going to discuss Concrete Skills. This pattern is pretty much explained with someone wanting to be a part of a good development team but they have not yet built up their development experience. My reaction to this pattern is that this would be a comforting one for students in college or upcoming graduates (and even entry-level developers) to feel a little less pressure on bridging the gap between starting fresh and being an experienced developer.

Concrete skills are interesting to me because you can have all the knowledge and information but being able to take what you know and apply it to something is different. The main takeaway I got from this pattern is to learn things that you will be able to apply even when you are still in the on-boarding phase. This has caused my to change the way I think about my intended profession because of course I want to get started and involved in projects right away. I like the feeling of being able to help people out when I have down time at my current opportunity just because I get to sharpen up a skill in one area instead of just sitting there.

A good question proposed in the pattern stood out to me, “If we hire you today, what can you do on Monday morning that will benefit us?” It’s interesting to imagine yourself in the role of a hiring manager; they have to hope to understand you well enough so that they can trust that you will be able to do your job and have an impact on the company. This thought makes me want to continue what I’ve been doing in terms of pursuing different learning experiences that will help me become a stronger developer not only knowledge-wise but skills-wise.

I do not disagree with something in the patterns as it gave me something new to think about and look forward to using in my future. I found it useful to hear their advice on considering looking at other CVs as references of what we would like to put on our potential list of skills.

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Do You Hate Your Computer Too?

Sams Ships (3)Apparently doctors hate their computers, according to an article titled Why Doctors Hate Their Computers by Atul Gawande. Gawande started out the article by mentioning Epic, a company a lot of people know of because it is a leading provider of software for the healthcare industry. It’s funny because just the other day, a classmate who will not be named groaned when he heard Epic being mentioned by someone, as he works in a healthcare center.

I found the reading was interesting because I have no intentions of becoming a medical doctor one day but was able to hear about how it is being one while interacting with technology that exists today.

It seems like the tension of logging everything caused the system to make doctors’ lives harder instead of easier; this was noticeable when Sadoughi was talking about how she had to look over all notes from different doctors including herself per patient. Instead of being able to just see what is going on right away; it would take up time to gather all information and even then it was not always helpful because some notes were different than others and became dated. And then work-life balance had to be thrown off a little because people had to spend extra time, up to hours after-hours to catch up with the system and review things from the day.

The real customer for the system seemed to be patients because they have some benefits from using the system like logging when to take medications or see how they are doing. Doctors are also able to monitor how they are doing and communicate with them by being pinged.

The lessons from this system do not only apply to Electronic Medical Record systems; they also apply to working in life because burnout can happen to anyone in the workforce. I thought it was interesting how one of the ways doctors were trying to save time and prevent burnout from technology was by hiring in-hospital scribes or even virtual scribes when necessary.

The reading has caused me to changing the way I think I will work based on if I ever end up creating software that affects people’s healthcare by considering how much time it takes to interact with it, no matter how “cool” or “innovative” it may be. In terms of the topic itself, the reading has caused me to think more about software that has altered people’s professions as a whole; which I thought of before but never this deeply.

I do not disagree with anything in the reading for now as I do not personally know what it is like to work in a profession that is not traditionally non-technical and then gets transformed into something that relies on it.

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.