mthuasect - Tumblr blog

mthuasect · 2 years ago

Text

My College Life Memoir: A Journey Through Computer Science

From 2019 to 2023, I’m finally going to graduate from the Dickinson Computer Science Bachelor's course, which took 4 years. This essay may be somewhat lengthy, but I describe the process of the past four years in the hope that it will be helpful to those who are struggling with similar concerns in similar situations to my past.

First, I will introduce the general review of the department, and then I will introduce the review of each course.

Today, as computer science has become one of the most popular departments, 'pseudo computer science' or IT convergence departments that attach computer science are appearing in rapid succession. However, to me, the computer science department fitted more than these places. There are many experiences that I have been held back by learning only the coding necessary for the field without learning the operating system or network. I didn't know anything about Linux or http, but I first learned about it through classes, and it was very helpful. Of course, these contents will come out if you search Google, but the depth is different between copying and pasting the code and learning the general computing and its meaning.

What I realized while being here is that the Department of Computer Science is not a department to learn coding, nor a department to create S/W. In terms of practice, the goal would eventually be to produce programmers, but given the nature of college as research institutes, the Department of Computer Science is an approach to the nature of computers themselves. “How can we use automatable machines to calculate calculation problems that people struggle to solve?” Taking courses such as Computing abstraction or programming language structure will made me think about computers before programming was available.

I saw on Facebook the other day a computer science student asking why he need to learn calculus, but in fact, if you understand the nature of CS, you'll see that it's the opposite. Computers were invented to solve calculus that humans could not solve, and computers were made to be automated by reconstructing them into digital electronic circuits. Then, the role of the computer scientist that follows is how to make this computer calculate calculus. That's why programming languages and software came out. During my time at Dickinson, I took fewer computer-related subjects and more math. It's very unfortunate that I couldn't listen to other cs electives because I couldn't afford it because of my double major and my interest toward philosophy.

If you are reading this article and are thinking about whether or not to go to the Department of Computer Science, you should know the direction of this department. I've heard from one of my seniors who took a COMP130 Python class, that there was nothing left for one do with Python programming. But I learned a lot from COMP130 python course. At least to me, I thought I could find and learn coding in internet, but having no background knowledge for application was a problem. Among Dickinsonian friends, the reviews of those who regret or drop the computer science department are cases in which they wanted to learn coding and build some career in the field, but the direction or expectations of the computer science department did not match. In my case, I was more interested in mathematics or philosophy, so there is a bit of a difference in perspective.

There are many friends who say that graduating is difficult in CS, but to be honest, graduating is not a difficult on this department. Compared to natural science departments, the burden of assignments is much less. Colleges usually have a lot of requirements for graduation, and the tests and assignments are thorough, but maybe the only reason why it is difficult to graduate from the Department of Computer Science compared to other departments is that you have to take a senior seminar for a year, so you can't take two other classes. It's just that. Since it is one of the most crowded departments, it seems that there are many reviews saying that graduation is difficult. It's not that it's difficult to graduate from the Department of Computer Science, it's just that it's difficult to graduate. HAHA

Now, I will introduce the process, changes, and personal impressions/reviews of each course over the past four years. As I said before, this is a very subjective opinion. And as I once had a very clear goal of going to graduate school in mathematics, so my likes and dislikes can only be based on that standard.

First of all, I decided to take data structure/algorithm, and placed the subjects I needed out of the rest. I thought the network was essential because I didn't have too much basic knowledge, and I placed subjects with a high proportion of math as first.

In the case of statistics, I did not learn to go to economics/management/social statistics or biological/bio statistics, but I liked probability and combinatorics a lot so I thought it would be fun.

< Linear Algebra > People who hate math but come to school just to code (my friends who say why do I need math?) are very freaked out. To be honest, Dickinson linear algebra is lacking in quantity. However, I was personally very satisfied with the quality. Professor Dick Forrester, who is mainly in charge of mathematics subjects, was the one who I felt was really good at teaching among all the professors I had seen in numerous lectures so far.

< Probability and statistics 1 & 2 > When you do statistics, you basically learn computational tools for statistical calculation, and Dickinson teaches R, a statistical programming language, as a base. So, practically speaking, it is a subject that needs to be taken. Because of R programming, I think it is a class that both computer majors and other majors can take. My favorite part was probability theory. This course deals with probability theory, which is the most basic background mathematics that dominates statistics. Generally, concepts and theorems related to probability are introduced in the first half, and conditional probability and Bayesian probability are also briefly mentioned. And the middle section introduces representative PDF (Probability Distribution/Mass Function) models. These are the content that comes out of subjects like , so if you only want to know the concepts and not details such as proofs and theorems, you may want to go over it. However, If you learn statistics without understanding probability, you end up memorizing most formulas and substituting them. The second half of the lecture introduces ANOVA and Time series analysis, which are helpful if you know them. Because it's Professor Jeff Forrester's lecture, there are times when it fits in your ears.

< Discrete Mathematics > My highly recommended lecture by Professor David Richeson. It was much better than I thought. You will learn several number theory-based theories that are usually the basis of digital theory. It was more extensive than I thought. But tests and assignments were very light.

< Algorithm > It is one of the compulsory computer science courses and is a paired course with. One of the indicators that can often be used to evaluate whether one have received education in one’s major is how well you have learned algorithms and how well you implement them in code. Since algorithms are dependent on data structures when implemented, data structures are always included as prerequisites, and it is common to learn some of the algorithms in data structures in advance. Most of the coding tests, which are the biggest gateway to getting a job these days, are conducted in a way that immediately implements the contents learned in data structures and algorithms. The lecture itself does not directly involve coding practice, but it is a subject that must be studied hard because all the concerns that are essential before coding are learned here. Professor Dick Forrester is in charge, and his teaching skills are superb. This class cover a fairly large range, while other subjects in Dickinson often have a reduced range.

< Computing abstractions > It is also a compulsory subject in computer science. As the only subject in charge of hardware, learning commands and CPU structures and principles occupied a significant amount, and a lot of time was allocated to learning the structures and principles of the rest of the peripheral devices. This subject can be seen as the least directly related to programming skills, but it is good to understand the structure of CPU. And if you're not sure where the things you learned in Digital Logic Circuits can be useful for, this is where they will shine. And if you do embedded or assembly programming, there is no corresponding subject in Dickinson, but you must know the computer command structure in that field. The lecture is taught by Professor Grant Braught. This was the first time I've heard of his lecture, the lecture itself was not bad, and it was important to listen to the lecture in addition to the textbook because there are many things to see. However, following in the previous semester, he gave an insane amount of assignments.

< Computation and Complexity + Programming Language Structure > The extremely difficult automata theory, where the hell is this going to be used? It is used for language structure. When a person enters a command code into a computer, an electronic device composed of electronic circuits, programming is to analyze it and perform electronic calculations. Then, how does the computer interpret the command code and convert it into a signal that controls electronic parts? In a way, it can be said that these courses as a set is the exact opposite of above. The principle of compilation, which is the process of converting a programming language, which is the core of software, into a hardware control signal after a computer interprets it, is covered. It is the lowest level of software. The process of interpreting a string entered by a person as a programming language, understanding the flow of an algorithm, and converting it into machine language is a formal language and automata, a unique mathematical system that I have never been encountered before. It was difficult because I wasn't used to this kind of expression. If you want to create a new programming language yourself, then you need to develop a compiler for that language in another language, and it will be useful in that case. The course consists of lexical analysis, syntax analysis, and semantic analysis of C, C++, Prolog, and Scheme. Professor John MacCormick lectures, and his unique, tidy but kind and detailed lecture skills are a subject that shines. Personally, it was the most difficult subject among computer science subjects, but it would have been more difficult if someone else had taught it. It is highly dependent on understanding through pictures, so it is better to see the professor commenting through PPT rather than just reading the book.

< Python Comp130 > Professor Lev Fructcher is in charge of the crazy enthusiasm (Professor Lev is kind and passionate enough to give feedback even on holidays), and we try the syntax of the Python language and simple exercises. It is the most obscure subject. It is a very good subject to learn the language called Python. Not only programming, but also simple data analysis methods, data structures, and optimization were implicitly included in the language learning process. In the class, the professor does not explain the code description of the PPT, but opens the program and explains it while coding on the spot. (What I really liked about this is that all compilation errors come out and you can see the process of taking action. Students will also go through this process.) Probably most people who take this course are the first to code, and I know that there have been many revisions and reorganizations since I took it.

0 notes

mthuasect · 3 years ago

Text

A03b - Blog Post #2

This blog post discusses the definition of "working software" in the Agile Manifesto and the importance of unit testing and structure in the development process.

The methodology called Agile started from the Agile Manifesto, and the Agile Manifesto contains this item.

“Working software over comprehensive documentation”

This definition of “working software” here may vary slightly from developer to developer. Some developers may think literally, as the code that just runs. Some other may think that the design should be clean and complete, including unit tests. But in fact, most beginners tend to choose the former because they get caught up in the concept of "agile = need to move quickly."

However, code written only to work, that is, code written without a proper design, abstraction, or pattern, may be easy to write for now, but it will cause problems every time a new feature is added. Recall the emotions you felt when you encountered messy legacy code. Because it's hard to understand the code, you don't know where and how it will be broken if you modify it incorrectly, thus you’re scared to touch it. You’ll be reassured only if you test the full functionality every time you make a small change. Moreover, if tests were not automated, you have to test it by hand. Note that this case also falls under the category of former “working software.” Let's imagine that we need to add a new function to this legacy code or improve an existing one. Will we be able to move as agilely as we intended when we first introduced Agile? I don't think so.

While feature development may seem agile at first, accumulating technical debt will eventually make it less agile. Besides, being agile in Agile doesn't mean finishing development quickly. It refers to the ability to respond flexibly to frequently changing requirements.

I think that professional software creators should pursue sophisticated and skillfully crafted software, not software that simply works. Sophisticated and skillfully crafted software means a design that is clear and simple enough for a new developer to understand immediately even if the code was written a long time ago, and that adding and modifying new features can be completed with a development effort similar to that of the first development that is, predictable and maintainable software.

Few of the articles I read suggests unit testing, pair programming, and continuous integration as concepts necessary to write such software. However, even if you do not execute all the methods suggested, in fact, if the code review is successful, the worst case in which the code of the application going to the total catastrophe can be protected to some extent.

One more thing I reflected on myself is that I thought of writing unit tests and writing business logic as completely separate tasks. I thought it was more important to finish development of the business than unit tests. And this seems right at first, when it's okay to test by hand, but later, as the application grows larger, the time required for this test increases as well, so unit testing becomes crucial.

Many of the bugs that occur suddenly in a production environment and are difficult to identify easily can be caught during development simply by writing unit tests. A lot of developers agree on that unit testing can reduce wasteful and repetitive work, which leads to increased productivity.

If you’re a beginner, you may be asking yourself a question here.

If you write unit tests, the absolute amount of code you have to write will increase, and you will spend more time thinking about this because you have to define clear functions. So, in the end, won’t the development period be longer?

This is true. It will definitely take longer than just weaving the code out. So, in the first place, we need to include in a schedule to write tests. Writing business logic and tests is not a separate task, but just one part of the process of developing a feature.

Lastly, we have writing unstructured code. In other words, “doing this first and fixing it later.” To be honest, I've done this a lot. I think not only myself but also other developers have experienced cases where when you think is unlikely that a bug will occur, you write the code that has poor readability or unclear structure.

However, doing this is worthy of criticism, saying that the developer is putting poor quality code into the application without any guilt.

0 notes

mthuasect · 3 years ago

Text

A03a Blog post #1 - Ideal team structure and collaboration for software development

In this article, I would like to talk about the ideal team structure and collaboration plan of members directly involved in development in software development projects. However, I will focus on only the three roles mentioned in this article: product manager, product designer, and developer.

What is the required direction for each of the three positions?

Of the many activities in software development, writing source code is the most expensive. It’s expensive in a way that it takes longer to complete, and is the hardest to fix. It is more expensive than product designers creating prototypes, and product managers detailing user stories. This task requires the most labor, but it is often too much for developers to do alone. Therefore, the help of product designers and managers is absolutely necessary. But they don't work on writing source code. So how can they help developers?

Product designers and managers should do their best to collect and refine requirements, create prototypes and validate them to actual users before developers enter the implementation. For example, let's say that a product manager describes the features that he or she thinks the user will need. This function may be completely useless to the user. Let's say that the developer realized that it was useless after implementing it. The cost of user stories, screen designs, and implemented software for this function is wasted. It must be very exhausting for the parties who did this work. What a bolt out of the blue that a product made by hard work turns out to be useless. It also has a significant impact on lowering the team's morale.

If a list of functions is prepared after many thoughts, a manager should think about which of them is the most necessary function for the user. And when screening is done, create a prototype with the product designer. This prototype is not the task of developing software by writing source code. It can be a picture drawn on paper, or a PPT. It should be sufficient to verify the need for functionality while using minimal cost. Once the prototype has been completed, it should meet the users. It is the responsibility of the product designer to choose interviewees and listen to them through open questions. By showing the prototype, a designer should gain confidence in the users’ interest and ease of use. If a designer meets multiple users and analyzes patterns, it is able to verify whether the feature is really useful. Then the manager writes down a user story(detailed requirements) to deliver this validated prototype to the developer. When the implementation is complete, a manager should write down the acceptance test conditions to allow the developer to verify that it really been appropriately implemented. This acceptance test condition will provide a good test case for developers and will be a milestone for developers to develop as originally intended.

These activities eventually reduce the frequency of rework by developers and minimize waste. In other words, it will be able to provide users with the solutions they really need in a timely manner. And this is much more efficient from the perspective of the entire team. By reworking or doing useless work, the stress or degradation of morale that a team receives can also be minimized. Software development is ultimately done by 'people', so this should be considered important. If such a well-balanced team transparently exchanges opinions and delivers to users a software development that operates at short intervals, wouldn't it be possible to develop software with pleasure?

0 notes