Refactoring JavaScript is a book by Evan Burchard, about turning bad code into good code. Since I am going to delve a little deeper into JavaScript in the upcoming months, I thought I could learn from books that actively use JavaScript examples so that I get more familiar with the language. I am about halfway through the book and would like to give some summary and thoughts before I forget them.

The first few chapters lay out the foundation that refactoring is about improving code quality while preserving existing behavior. The author empathized on the importance of testing and having tools to help verify that the code works as intended. He went on to explain some intricacies of JavaScript and the fundamentals of testing. Though the content could be common knowledge to people who aren't beginner coders, I thought that the intense focus was on point. Quite significant efforts were given to drill the following concept into a reader's mind:

Avoid refactoring without tests!

Here is a flow chart that the author used to illustrate decisions about test, refactor or implement. You can tell from this diagram that refactoring is a small part of the decision process and it relies heavily on having testing in place. coding.png

Another major discussion in the first part of the book is on understanding functions as six basic components and the author provided some general advice for each of them:

• Bulk
  • keep lines of code and complexity low in each function
• Inputs
  • could be explicit, implicit or non-local, but prefer explicit over non-local
• Outputs
  • avoid returning a null or undefined, or returning different types of values
• Side effects
  • keep to a minimal or nonexistent
• this: the implicit input to functions
  • have it well-defined when possible
• Privacy
  • it necessarily impacts access in JavaScript

---

Author: Evan Burchard Author's interesting personal site

Link: Book pdf

Goals​

Here is a mid-year update to the goals that were mentioned in my "hello world 2020" article:

• Secure one summer internship (or NUS'CVWO)

I managed to secure both NUS CVWO and an internship position at a local startup (I chose to go with the latter).

• Continue to write CS & web dev related stuff (at least on a Bi-weekly basis)

I wrote an article or two and had a few in the pipeline, but did not follow through with the promise of bi-weekly publishing. I need to reconsider this due to my other commitments.

• Be great at one module each semester (aim to TA for it)

I am fairly happy with what I learned in CS2103T Software Engineering, though I can't say I am great at it (result unknown as of now). I started to be active in the class forum right after midterm and that was fun. There were interesting discussions and I benefitted from peer learning.

• Put in efforts to develop one of my ideas to fruition

I am excited to start working on my ideas in the upcoming summer.

• Do one open-source project

Same as above, looking forward to contribute to possible open source projects under NUS in the second half of the year.

• Be wholesome and happy while doing the above:)

---

School​

Maybe it's time for me to write reviews for the modules that I have taken:

CS2100: COMPUTER ORGANISATION​

Low level stuff that computer science students might be interested to know. Lot's of 1s and 0s. Overall an interesting module that has a somewhat similar vibe with CS1231S Discrete Structures. Most content can come off as surprising and complex at first glance, but once I start to get familar with the topics, things like control, MIPs instructions and other binary stuff seemed less scary. Certainly not a module that I mastered, but I feel that the information in the module is good to know.

CS2101: EFFECTIVE COMMUNICATION FOR COMPUTING PROFESSIONALS​

A compulsory communication module paired with CS2103T Software Engineering. Focused on class interaction, group presentation and ended with essay writing. Because of my tutor's enthusiasm, it was easy to participate in class. The opportunities to practice group presentations served as great way to receive constructive feedback on individual communication shortcomings.

CS2103T: SOFTWARE ENGINEERING​

My highlight-of-the-semester module and I think it has an excellent coverage and great delivery. The course taught me things that software engineers should at least be aware of. This include UML diagrams, test case design heuristics and things like software project management. I would say it is fairly comprehensive and I picked up lot's of nuggets of wisdom that could possibly help in my future software engineering projects. Prof Damith and the teaching team were considerate and responsive.

The module also served as a playground to create and contribute to small to mid size code bases. The collaborative nature meant that one has to work with their team mates and participate in a range of team activities such as weekly meeting and peer review and discussion of issues as well as pull requests.

ST2334: PROBABILITY AND STATISTICS​

Another compulsory math module for CS students. Builds on top of JC H2 Math Statistics knowledge. Pretty much self-study.

DMY1401TT: DESIGN YOUR OWN MODULE (Machine Learning in Practice)​

Not as expected and I could have self taught the content provided. Mostly surface level stuff with some in-depth knowledge that was communicated at the surface level.-.

GER1000: QUANTITATIVE REASONING​

No intention to put any efforts into this module and going to SU.

IS1103: ETHICS IN COMPUTING​

I understand what this module is trying to do and appreciate how it at least requires minimal efforts each week. I won't explain much because of the super low workload.

While CS2103T is about technical skills and CS2101 is imbued with insights around the topics of communication, both aimed to teach me how to work with others effectively. The former opened my eyes to working in a technical environment and the latter taught me how to interact with others to strive towards excellence in that environment. My reflection will be deeply involved in how the theme of persuasive presentation connects the dots in the module CS2101.

The first part of the module introduced me to persuasion stemming from being audience-centered. Before taking this module, I have never believe in the thinking that in order to persuade someone, one has to be perform strategic needs analysis or conduct pre-presentation surveys. I valued more on being interesting and informational in a presentation or a speech. That led to a rather average performance during my OP1 presentation which I focused on squeezing in all the content about conflict management styles and disregarded the audience profile. It was not effective as I did not put a premium on connecting with the audience. I learned from this experience that persuasive presentation should start with identifying the target audience and also identifying with the target audience. It would be better if I had analyzed the audience who were my fellow computing students, and constructed my content based on their needs and the benefits that they might get out of from learning about the various management styles.

Following from keeping the target audience in mind, persuasion also requires careful consideration of the purpose that the speaker is trying to achieve. After learning about the audience's preconceived notions and their expectations, a convincing presentation should focus on aspects of the completing values framework (CVF) and employ rhetorical appeals. During OP2 product demo, I tried to strike a balance between the informational and promotional aspects of CVF. On top of presenting the features of the product, I empathized on the design considerations and how they were catered to solve problems that potential users might have. I also utilized "Pathos" by opening my presentation with a relatable story that the group of computing students who were the audience could understand. In my explanation, I also included a reference to a famous design principle named "KISS" to establish credibility in my claims. I ripped the benefits of applying what I learned in the module to organize my presentation to be context and purpose driven.

The last part of persuasion in a presentation comes from having an unified and cohesive delivery with strong teamwork. The difficulty in a team presentation context is with transitioning of ideas and the entire flow of presentation. While I understood the importance of coding styles that were taught in CS2103T to make our code appear unified in the technical context, I realized that I lacked that consideration when preparing for a team presentation. Often times the team members decide on what they want to say before a proper discussion on the flow and purpose of the presentation. This often results in minor issues such as the lack of sign posting and unnatural transition between the team members and sometimes serious drawbacks when team members repeat what was communicated earlier or angled their sharing on a separate front. In this aspect, I think while following a structure such as motivated sequence pattern (MSP) is important to achieving soundness in logic and coherence, the planning of talking points among the team members and constant review of the integration between different teammates is crucial.

In conclusion, I was able to identify and practice many of the said ideas in the opportunities provided by the module. Keeping in mind the devices that help build a persuasive presentation, there are also other important aspects of communication such as participating in audience interaction and providing constructive feedback. Communication skills require practice and I am grateful to be armed with the relevant knowledge to further practice what was taught in the module in the future.