kmoon47 - Tumblr blog

kmoon47 · 2 years ago

Text

Reflection Computer Science experience at Dickinson

As a computer science major at Dickinson College, I have been fortunate to experience an interdisciplinary education that has allowed me to combine my interests in both the arts and sciences. The mission of a Dickinson education is to produce critical thinkers who are able to solve complex problems and analyze situations before making decisions. As a computer science major, I have been able to apply this philosophy to my coursework, and I have made progress on some of the goals of the computer science major and the mission of a Dickinson College education.

One of the key components of a Dickinson College liberal arts education is an interdisciplinary approach to learning. Through my coursework in philosophy, physics/astronomy, music, computer science, and, I have gained a better understanding of how different fields of study can be used to approach problems in unique ways. In particular, I have been able to use the knowledge of logic and electronics from my philosophy class (PHIL 103) and physics (PHYS 131) to analyze logical circuit combinations in my computing abstraction class (COMP 256).

My years of music-making experience from private lessons and ensemble participation have also sharpened my attention to detail, a quality I have been employing to perform many programming tasks such as error detection and debugging. In my numerical method class (COMP 245), I found it quite helpful to re-use my matrix/vector math skill from multivariable calculus (M171) to analyze much more complex rounding errors in computers.

Furthermore, racial issues involved in tech have been brought to light and discussed in our classes. As a computer science major, it is important to be aware of the gender divide in tech roles as well as be skeptical of the technologies we often relied on. One issue we learned about was female open-source developers claiming male identities on GitHub to get their pull requests merged. Another issue involved biases in AI chatbots and airport scanning technology that sparked serious racial discrimination. These discussions have allowed me to become a better critical thinker and have given me the tools I need to approach ethical dilemmas in tech from a more nuanced perspective.

In addition to being a critical thinker, being a good writer is also an important aspect of a Dickinson College education. Through my coursework, I have had the opportunity to write for both history/humanities papers and math/computer science classes. For example, I was required to write multiple mathematical proofs in my discrete math class and several blog posts in the senior seminar where I combined my own critical opinions with evaluations of online resources. Most importantly, the valuable feedback from my professors, particularly those relating to grammar and styles during the First-year seminar, European history class (HIST 106), computing abstraction (COMP 256), and the fall senior seminar, has helped me make tremendous progress on structuring unorganized opinions in my writing. These writing skills have been invaluable in my computer science courses, where clear and concise communication is essential.

As a computer science major, I have also made progress on the goals of the computer science major. One of the primary goals is to develop real-life problem-solving skills. In my data structures and algorithms courses (COMP 232 and COMP 332), I was able to apply multiple techniques and strategies to solve one problem effectively and efficiently while understanding the trade-offs in terms of time and space complexity.

Additionally, courses like COMP 232, COMP 332, and COMP 314 have helped me develop a thorough understanding of the core concepts of computer science, and the knowledge I gained has been invaluable in my internships and personal projects. Additionally, COMP 256 allowed me to connect my current learning of high-level programming languages to the beginning of the very first computers that were made of transistors, circuits, operating systems, and the assembly language.

Another important goal of the computer science major is to develop basic programming skills. The intro to computer science class (COMP 132) provided me with a solid foundation in Java programming, while the database management system (COMP 378) advanced my Java and SQL learning. With an excellent emphasis on teaching students object-oriented design and code readability, I strongly felt that most computer science classes here provided me with solid foundations that allow me to effectively pick up new languages and technologies.

Being able to work and collaborate in teams is a critical skill in the computer science field. The Computer Science department provided me with numerous opportunities to work in teams, including lab teams for core computer science courses (COMP 132, COMP 256) and open-source project experience. In my senior seminar, I also had the opportunity to learn and experiment with real-life methodologies that enable efficient software development collaboration both on a team and company level. These include the Agile methodology, SCRUM, waterfall, and so on. These experiences have allowed me to understand the pros and cons of existing methodologies and how we can choose the most efficient and practical strategy for specific scenarios.

One significant goal that I was able to achieve was contributing to an open-source project as part of the senior seminar. On the non-technical front, I have learned the importance of troubleshooting issues beyond just coding, and I have developed the ability to interact politely and inclusively with the open-source community. As I have explored multiple projects, I learned to pay closer attention to the Code of Conduct, which has helped me become more familiar with the expectations and values of the broader computing community. On the technical side, I have become proficient in making pull requests, commits, and using git version control, as well as seeking out resources and using the command line and text editor. Through these experiences, I have developed a deeper understanding of how to contribute to open-source projects in a meaningful way and gained valuable technical skills that are great assets to my future job application.

Another key goal of the computer science major is the ability to present technical and non-technical information effectively, both orally and in written form. I have had the opportunity to work on peer reviews for the comp 256 analogy project, which has helped me to develop my skills in providing constructive feedback on technical details. I have also been able to deliver multiple technical presentations during the senior seminar where I learned to speak clearly and excite the audience. Additionally, I have enjoyed exploring controversial legal and ethical issues related to computing through writing public blog posts, such as the topic of Microsoft GitHub Copilot, during senior seminar classes.

Finally, I have gained a broad range of perspectives on the ethical and legal issues raised by computing. For example, in my senior seminar classes, we discussed the issue of bias in AI and the digital divide. We also used ethical principles to evaluate situations and examined the formation of SWE organizations in tech and how they differ from traditional industries like white-collar jobs or banking. Moreover, I came to understand the value of computing and its role in understanding the physical world and generating commercial value. Through readings and discussions in courses such as COMP 491, I have gained a better understanding of the organizational structures between big tech versus smaller tech firms, and have learned what to look for in a company in terms of values and culture. This has been an important part of my education, as it has helped me to contextualize my technical skills within a broader social and economic context.

Overall, my experience as a computer science major at Dickinson College has been incredibly rewarding, and I am confident that the skills and knowledge I have gained will serve me well in my future endeavors in the software engineering field.

0 notes

kmoon47 · 2 years ago

Text

How Big Tech's successful management practices could mean differently to developers

Google, Microsoft, Meta, Apple, and etc, collectively known as Big Tech, could be among an engineer’s dream workplaces for their offer of great culture, well-established engineering process, and anything in between. Their success often boils down to how well projects are managed across teams and adaptation to changes, yet they are not the sole reasons. In fact, what constitutes most of Big Tech’s success lies in its unique organizational structure, the people, the autonomy and skills of those people, the competition, and the work culture.

Big Tech pride itself in having flexible team management approaches, as opposed to traditional companies, and a pool of high-caliber talents, which often results in groups of exceptionally competent and highly motivated engineers bonded by deeply shared goals. However, evidence suggested that these characteristics may impact employees in different ways.

Following the science behind their success, I want to further answer how these distinct management practices could have cultural impacts on individual developers as they look to fit in the company’s business goals.

The way Big Tech run projects is different

As far as I’m aware, some of the methodologies and frameworks with which companies have successfully run their projects were test-driven process, Agile, Kanban, or Scrum according to Software Process Models. Under these approaches, software engineering teams often have a dedicated project manager, or product owner, and follow one specific, heavyweight process involving sprint planning, daily standups, iteration, and unit testing. These methods somewhat addressed most of the key factors in defining successful project management such as pace, ownership, and awareness of teammate’s work as defined in the SWE Process.

It was a surprise for me to discover that no “formal” methodologies were found in Big Tech even though they still incorporate similar ideas from the Agile method, such as the focus on customer collaboration and developer’s freedom and ownership. How did they ensure the developer’s productivity and that everyone is on the same page?

One article found that Big Tech engineers have the freedom to organize how they work and a tech lead instead of a project manager. Specifically, teams can freely choose their project management styles which result in various processes between different teams in the same organization. The tech lead is an engineer who oversees the project planning but not owns the project management.

Another underlying factor that contributed to their success is having highly skilled, cross-functional engineers. This led to teams full of empowered and autonomous people who hold each other accountable and have a clear picture of their teammate’s best interests. These manifestations are very much close to the idea of the Agile method, where the team’s competence is leveraged through prioritizing individuals over processes and tools.

What does this mean for developers?

Now that we have a sense of how Big Tech’s unique infrastructure set it up for success, I want to see how all of this would lead to any particular cultural challenges for an engineer.

An article suggested that software engineers tend to be associated with being “smart”, which could be amplified at well-known large tech companies. This may prompt developers to experience impostor syndrome, which is said to be exhibited by 58% of employees in tech companies. Together with the fact that processes vary among different teams, an engineer may be more concerned with culture fit rather than technical interest when considering switching teams. This could prevent potential engineers from growing to their fullest capabilities. However, I believe this issue could be resolved with enhanced technology and tools for customized team matching.

With practices such as daily stand-ups and sprint planning, any individual would probably need to be more open about sharing and asking for help, even if you consider yourself an introvert or someone who does not want to risk looking “dumb” in front of your teammates.

In addition, could you expect that your busy tech lead, also a full-time engineer, to address all of your technical and non-technical problems? According to this article, a dedicated project manager may have a broader understanding of various teams and departments, hence better assistance with your personal goal and needs.

Since Big Tech moves fast and responds to uncertainty quickly, developers may barely find slack time to be creative. Could this prompt developers to feel less motivated about their work? In a different context, this could mean having to exhibit a certain level of engagement. A blog post shows that in a busy, fast-paced work environment where everyone values open communication, a quieter developer, despite her enthusiasm, could be misunderstood as disengaged.

Since not every developer would experience these issues, it is worth noting that a lot of Big Tech management practices still contributed to developers’ positive experiences, including setting them up for rewarding challenges and career growth. I’m intrigued to see what future practices and training these tech companies would continue developing to help ease the cultural transition for their employees.

0 notes

kmoon47 · 2 years ago

Text

Does Copilot operate on stolen creativity? If so, does it replace our creativity?

Microsoft Github’s Copilot, a code autocompletion tool backed by OpenAI’s codex, has been around for more than a year. Considered as a new automated StackOverflow, this product has gained both increasing appeal and controversies over licensing issues. Some argued that Copilot fundamentally changed the way we code for the better. Others were heavily concerned about the sources from which the code was generated, claiming that Copilot infringed the copyright of others.

The more I read about this product, the more I realized that Copilot was imperfect and unrepresentative of a novel idea or algorithm, making it less of a threat to copyright. I want to explore the question of whether Copilot’s AI-generated code is unusual enough to be considered stolen and completely replace our creativity.

The legal issue of Copilot

First, let’s try to examine why Copilot has sparked such controversies. This involves understanding the concept of copyleft licenses in the open source community. You are likely already aware that there exist multiple software licenses that regulate the usage, modifications, and distribution of open-source projects. Hence, I will not dig into the definitions of each license, as they can be further explored through this well-explained article on Popular Open Source Licenses. We are mainly interested in a strong copyleft license, which outlines that one must apply the same license to the distribution of open-source software if the modified code in the program is based on the original code.

“Why is this important?”, you may ask. From reading about liability issues around Copilot, I was intrigued to see that Copilot itself was trained on public code written by others from public GitHub repositories licensed under GPL, a strong copyleft license, yet Microsoft claimed to have no licensing obligations for the output of the product. Apparently, according to the strong copyleft license definition, Copilot should be accused of not licensing itself under GPL even though its AI models and training set relied heavily on the original public codebases.

The issue continues to expand as Github Copilot also read the code we write to collect information about which suggestions users accept or reject, then use this data to improve its AI models according to Copilot Pros and Cons. Consequently, I agree that users should be concerned about liability issues when using Copilot, particularly employees who do not want to risk having code shared outside their organizations or become subject to a different license as part of the GPL enforcement.

Though I do not specifically know what kind of code Copilot developers are interested in fetching their AI models with, I question their uniqueness and quality. If Copilot only renders trivial code blocks that anyone can come up with from commonly written code samples, is it considered copyright infringement? The answer may lie in determining which problems Copilot actually solve and whether it has the capability to replace our entire thought process and creative minds.

Copilot generates averagely-written and ineffective code

It is worth noting that Copilot helps create software with fairly small, boilerplate chunks of code that may not make sense when brought together without manual inspection, let alone representing one thorough solution to the problem. The product's goal is to perform common tasks, including taking demo code from public documentation, which implies that these codes could be easily used and found by any individuals with basic programming knowledge.

Moreover, evidence shows that Copilot could potentially introduce bugs, bad practices, and deprecated code if used without manual verification. The article Copilot Pros and Cons suggests that Copilot does not necessarily provide well-tested and “correct” code that will run as given due to the AI model’s 29% correct response rate. The autocomplete snippets are said to be more representative of how average programmers write code. Another article pointed out that Copilot can only solve 20% of the problems and typically fail in performing data science tasks due to the lack of niche domain coverage.

What Copilot has to offer is revolutionary, yet I believe that Copilot is not an ultimate and perfect tool that helps us “invent” new solutions because they do not represent unusual or consistently functional code.

Copilot makes room for more creativity

Now that I have laid out the technical shortcomings of Copilot it is clear that we still need to rely on our coding ability and creative minds to find the most elegant solutions. Overall, Copilot is just a prediction, it does not directly align with our best intentions while developing software. What Copilot has done particularly well is reducing tedious work, allowing the user to spend more time brainstorming the structure of the code, minimizing context switches, and coding more efficiently. This in fact creates space for us as developers to think of the code from a higher level and tackle more complex problems without the help of autosuggestions. Solving these problems requires tremendous creativity, so Copilot is certainly not taking away our growth opportunities.

The line where averagely-written code is differentiated from unique and unusual code can be further investigated to truly determine Copilot’s implications on our creativity and problem-solving skills in the long run. However, one can take advantage of this powerful tool to gain a basic programming mindset while being actively aware of its legal implications.

0 notes