Ironically, we commonly think of computer scientists or engineers as hermits. They are stereotypically tech dorks — who could be geniuses — but are unable to communicate with anyone. I believe that this stereotype is detrimental to one’s personal perspective on their role as a software engineer. I’ve decided to write a blog post discussing why it’s beneficial to diversify your knowledge and explore various avenues of life.

My argument today is that communication is the primary metric for a good engineer, with engineering skills as a secondary metric. I am not suggesting that technical skills are obsolete; instead, I would prefer an engineer with weaker technical skills and greater communication abilities than vice versa.

Motivation

I’ve started to find a bit less interest in software engineering as of late, and have turned toward other new hobbies and interests. I still find software enjoyable and exhilarating. Instead, I’ve been focusing on engineering through the communication and interpersonal side. I’ve noticed two major things that shifted my mindset.

The first of which is that recruiters stop caring about technical skills at a certain point, more for seniors than juniors. What really makes people stand out, after a certain technical skill level, is the ability to mesh well with the rest of the company. Recruiters genuinely care about the people they hire. False positives from personality are more tiresome than false positives from a skill difference; the latter can be trained.

Secondly, you can learn a lot more about software engineering by exploring other ways of thinking. I consider engineering to be more than just the solving of technical problems, but the mindsets we use to navigate them. This includes the understanding of social context, communication, and independence. We can improve these contextual skills through the exploration of anything. I mean anything. Here is an example. Dance lessons have taught me about the importance of being more assertive. As a leader, I was called a “gentle soul” since I gave weak pushes and pulls to my followers. This is dangerous as it is harder to tell where my intentions lie, and could result in a misstep and injury. Being assertive — not forceful — is an important aspect of life.

The Origin of Lack of Socialization

The problem is that people generally place less emphasis on the collaborative side of programming. It has become about technical skills. I will be using one of the most social majors as a comparison throughout the article: business students.

One example that illustrates the contrast between software and business majors, besides the fact that we are constantly staring at a screen, is that business students typically have a hobby section in their resumes. However, as software engineers, we would have a skills list in place of that.

Our disregard for social skills did not come out of nowhere but was socially built over time. One such explanation for this is that much of our schooling for software engineering is very individualistic. University classes predominantly focus on individual projects. This makes sense for many classes and class structures. If we are trying to teach complex ideas — such as databases, networks, and security — it would be most effective to have individuals work by themselves. However, the consequences are that we have far fewer opportunities to interact with peers, which is a mismatch with what the industry expects. This is not the fault of the school entirely, whose goal is to teach concepts to its students, and not necessarily prepare them for the real world.

Then, there is a cultural misunderstanding of what a computer scientist is and what a software engineer is. Many computer science students transition to software engineering roles. This is quite odd because computer science is about math, logic, and the theory of computing. There are usually very few classes that teach skills that are used in industry, even on the programming side. Forgetting about the technical side, there are typically no classes dedicated to working in teams, social environments, or anything in the industry. Again, this is not the fault of the schools; they are teaching the subject — computer science — as they should. But this simply results in a world where we have normalized people having the wrong set of skills for a job, then being shoehorned in later. Or this requires individuals to develop the required skills outside of their education and studies.

Outside of school, commonly, we work on software projects. Again, this is done on an individual level. It is very rare for both seniors and juniors to be collaborating with others on a software project. We push code alone; we read code alone and never document anything. Even if you did document code, it is hard to reach the same level of collaboration, as it’s not the real thing. In fact, it’s very hard to get the real thing: communication in a business setting. I think the best we can do, as developers, is to contribute to open-source software. But, even then, it is very difficult to do for many, and it can be more well-defined.

All of this is enhanced by the cultural aspect of software geeks. We are traditionally represented as very socially awkward, isolated people; the list goes on. This would naturally delve into our own subconscious; we begin to associate our traits with our character. Naturally, one could follow the line of conformism. We think that as software geeks, it’s fine not talk to people. We could also use it as an excuse to avoid uncomfortable situations, to justify not getting out of our comfort zones.

I think we should start rethinking the detrimental harm that this is causing us. Then, start understanding why it’s so important for us to explore ourselves and the social world.

The Need for Human Skills

So, why do I care so much about these communication skills anyhow? This is where the bulk of the article is heading.

Unlike what we are taught in school, ambiguity exists, and it requires communication to solve. We are constantly given specific problems to solve within our academic career. Especially us computer scientists; we solve discrete and well-defined problems. That is hardly ever the case in the real world.

Every single technical problem we solve requires some level of collaboration. Here is one basic example. If we are committing to the codebase, we need to do pull requests. There are times when people can give off the wrong impression in code reviews. They could come off as a narcissist, unhelpful, or just a brat. It’s a simple example, I know, but if you don’t address these problems, some people would be indirectly labeled as bad code reviewers — then eventually completely ignored. Every stage of problem-solving — in a team — requires team communication. You need to check what other people are thinking. You need to be assertive, like in partner dancing, to prevent dangerous injuries in the future. Communication does not only involve meetings, but there is also writing code that follows the conventions of others and understanding other people’s priorities. There is also the collaboration with the business itself. The needs of the business are changing and context-dependent. In a startup culture, people care more about going fast and breaking things. Before doing any programming, you should understand the business impact and purpose of the things you do. You could think to yourself: “How will what I do help the team and the company?” This line of questioning is not a technical skill; this requires empathy — a social skill.

Let’s say you were working alone — no team at all! Okay, there must be no need for social skills anymore, right? Well, I disagree. I think that ambiguity in business will always exist. Therefore, business objectives are never defined precisely. Allow me to elaborate. Let’s say you were working for the CEO, and he wanted a certain set of features for the latest web app: the ability to edit the user’s birthday on the profile page. Okay, that sounds simple. What kinds of ambiguities could possibly exist? Well, do you want verification with a government body to ensure that the birthday is valid? Do you want to send a confirmation email with the change? Do you want this to be a change that can only be done once or repeatedly? There can be infinitely more questions; it is a matter of imagination. Because businesses can never be defined to the smallest details, there will always exist these ambiguities. Some of these questions are valid; some of these could be a waste of time. How can we differentiate between them? Well, there comes the aspect of empathy and communication. We need to align the company goals with the business. This is even more so the case if you were a startup founder, where you also need to take on the role of the CEO. To develop a meaningful product, you require the ability to communicate with the higher business managers or customers. As stated before, this is to empathize with the business.

Let’s say that you were working a role where tasks with specialized and specific conditions were handed to you. I know people who work — predominantly in the low-level programming field — where the tasks they are given are very well-defined. An example would be to optimize a matrix multiplication algorithm. In this case, I want to argue that autonomy is cooperative. If we are truly autonomous, it means that the work has been done for us before by a higher level of business. This higher level discussed the business goals, how to achieve them, and assigned tasks to the lower level. It has been distributed and then well-defined. It typically requires that the person distributing the tasks is an engineer themselves. Otherwise, ambiguity would exist again. Then, you are handed these requirements and then must implement them — this role can be called a code monkey. It can be the case that some companies would prefer this structure. But there are two arguments to make against this. These code-monkey roles are the most replaceable by the looming threat of AI, since it is simply cheaper. Therefore, we could start considering code-monkey roles no longer viable for the future of engineering. Another is that, typically, juniors would face a more automated workload, but the goal is to wean them into a more leadership role. After understanding all the technical intricacies, you would be expected to hold more social responsibility. Unless you want to remain in the same spot in your career forever, you need to take on social responsibility.

In the end, it is vital that you have great social skills. Engineering — misunderstood to be an isolated role — is one that demands constant communication with others. To succeed and level up in any organization, you must focus and hone your communication skills.

Call to Action

How do we improve our social skills, from communication to empathy?

I think there are two simple things to try:

1) Getting involved in media. 2) Trying out new things.

Media shows us different worlds. It offers us a unique perspective on our worldviews. Films, books, and music are powerful because they show conventions of what the world is like, but also offer different ideas of what it could be. They allow us to change our ways of thinking. When watching films, we can see various conflicts arise and gain emotional intelligence as we follow the characters’ struggles. Better yet, try writing. Try writing blogs, diary entries, or even poetry. I find it a brilliant and introspective process that helps me understand both myself and the world better.

Then, try out new things. This is usually best in a group setting. If you are in university, please go and try out new clubs. It is a very exciting feeling to learn new things with others. It allows you to see their perspectives on the world and how they can integrate with your own. One example is trying out the improv club. I can tell you that the people there have a very bold and unique process for problem-solving. They are on the spot and dynamically change ideas on the fly. It is an amazing process to see different worlds and apply it to myself. There is also the social aspect of getting used to just talking to people. By joining clubs, you get used to having to talk with people often. It builds social skills.

Conclusion

Well, I hope you understand the importance of honing your communication abilities — and I’ve convinced you to start trying out some new hobbies. It took me a while to realize, but life is so much more than just programming. You never know how much joy you can find by putting yourself out there.

Thanks for reading and have a wonderful day!

I know my loyal fans are questioning why I have not written a blog post in such a long time. But I have finally returned with wisdom after a busy semester of school. To those who are new to my content, I hope you enjoy this read!

Recently, I’ve been working on a side project called https://computerscienceresources.com. I’ve noticed that there is no centralized location for the diverse range of computer science resources. I see a multitude of ways to break into various software fields, but these resources are scattered all over the place and sometimes generally hidden. Furthermore, I sometimes hear a lot about some resources, like Brilliant, from all these YouTubers. And, as a skeptic, I want to know how good or bad the resource is: the teaching quality and engagement. Then, there is another issue of people asking me what resources I should recommend for getting into software.

These three issues:

• Wanting to find more ways to learn software
• Determining the quality of a resource, like a bootcamp
• Sharing learning methods with others

And the lack of a centralized website has led me to develop https://computerscienceresources.com.

But today is not about promoting my site. I have been developing this site for well over a year now. I’ve made numerous mistakes since the beginning. I think that some lessons can only be learned from developing a long-term project, as this was my first project that was not just a throwaway toy project.

Enough chit chat. I’ll start with the lessons.

Understanding the Consequences of Your Tech Stack

After reviewing various options for my tech stack, I chose Laravel because it places a strong emphasis on developer friendliness, boasts a robust ecosystem, and is a mature MVC framework.

I did investigate other options like Supabase, Phoenix with Elixir, Node.js, and the .NET framework. However, Laravel’s ecosystem seemed much stronger for the kind of work that I wanted to get done.

However, you must also understand that some frameworks are less “sexy” than others. When you limit yourself to a tech stack like Laravel, where the language is PHP, you may get fewer job opportunities than with a more popular one. Even if you end up creating a less robust application, recruiters like seeing popular frameworks like Node.js on your resume. I’ve had several interviewers question why I am using PHP in 2025. No doubt that if I chose a web framework like Spring Boot, Django, or ASP.NET Core, which uses more popular languages, interviewers would be more impressed.

But I don’t think that the language mattered much to me. I was more focused on getting my application published. I knew that coming in, the flashiness of the language was not important. With the scaffolding that Laravel provided, I was able to get a prototype up and running and develop my application with great speed, as Laravel provides a very nice starter kit (https://jetstream.laravel.com/introduction.html). More importantly, I think the architectural decisions and software skills I’ve learned from this project apply to software development holistically. In this case, I’ve become very proficient with the MVC pattern.

The lesson to learn here is that recruiters don’t understand that one can become proficient with a framework by only having worked with similar ones. I’m certain I could pick up Django without much difficulty now (having done Laravel) — but to a job recruiter, they don’t see that.

No matter what framework you choose, understand what you want to achieve with your project: practicality or flashiness.

Understand Your Core Features Early

If you are going to work on this project for a long time, define what the MVP would look like. It is common advice to work on an MVP for a project and to have a list of minimum features that your application would contain. I’m not going to explain all that; I know my audience is smart.

So, I created a list of top features and split them into vital features of the application and “nice-to-haves.” Of course, for a site with resources, I had posting and filtering resources as a top priority. Then, I trimmed the core features into a smaller subset of features to create the smallest possible core feature set:

• Resource
• Posting Resources
• Editing Resources
• Filtering Resources
• Upvoting Resources
• Reviews
• Comment system

What I made a mistake in was not understanding the effort that each feature was going to take. I had some features in creating a resource be very important, such as having a multistep form save to local storage. However, I focused too hard on it during the beginning, thinking it was a trivial task — originally done with jQuery. I focused so hard on this feature to even work nicely with so many different web components and inputs that I could barely even have the MVP’s core features met. What ended up happening was I spent a few months on a prototype with Laravel and Blade, with terrible code, and not even all the core features completed.

Some features were much more complex than initially expected. One of them, which I will dedicate an entire technical article to later, was creating a nested comment system like Reddit. I managed to create one in-house, but it ended up not being a core feature at all. I could’ve saved a couple of months and launched the app early. In the end, I rewrote my Laravel Blade application with Laravel Inertia with a much more advanced and wise point of view. I saw how my past setbacks had transformed into mature lessons, which resulted in scalable, maintainable, and consistent code.

The biggest lesson was not just to predict my core features better but also to realize that I could spend the first few weeks of creating an application with a prototype mindset. If I had dedicated the first phase of the application to experimenting with the features and gauging the risk and reward of certain features for myself, it would have allowed me to mess around with different major architectures without worrying about trashing the codebase, as it would get thrown out anyhow. I could’ve scheduled the delivery of my application at least twice as fast. It may seem counterintuitive to not jump straight into a project, but if I ever start a serious project again, creating a scrap prototypical project would be my go-to move.

Overengineering Is Real

This mistake is quite similar to the previous one, but the lesson is a little different, so I will keep it. One of the biggest things engineers love to do is optimize their code, whether that be beautiful, elegant, or fast code.

There were several times where I thought I had the best way to write my code, realized that I was following a bad practice, and rewrote my code into a cleaner format. One example was I rewrote all of my tests to a helper function method, mentioned here (https://medium.com/@allankong/laravel-randomized-form-testing-trick-eb88247ba1ce). Afterwards, I discovered a better way to write the form tests with a package (https://github.com/worksome/request-factories).

Another time I overengineered was writing my comment system in such a way that I could handle 2000+ comments easily and prevented any sort of N+1 query problems. However, even now, I barely have any comments on the application. Plus, I thought of more ways that I could improve the comment system. So, software is always evolving, and it is important to have your focus on the things that will have a business impact.

The lesson is to understand that you don’t need to have your codebase, features, or anything in your product fully fleshed out. No one notices cut corners. What really makes your application stand out is the core ideas and features it delivers. So, focus on delivering that and start polishing once you have users or feedback.

Sometimes, I hold weekly recaps where I recognize things that I’ve done well and processes that I spent too much time on, even though I am a solo developer. I’ve noticed I started implementing many agile practices into my passion project, such as retros, postmortems, and sprint planning for the week. In the end, use whatever system you need to get insight on whether you are engineering the right amount.

Trying Too Hard to Validate Your Ideas

There are two schools of thought when it comes to validating your idea: create it and find out, or ask people and hear feedback. I think validation of the former is just more efficient for these sorts of passion projects. I feel that I should’ve spent less time determining if it was worthwhile for me to build this project to help others. I asked my friends around, and they had positive responses. Despite that, I still felt hesitant to work on this project.

What I forgot was that I wanted to work on the project for myself. Even if no one else wanted to use the site to discover learning resources, I would still use this site. I can share quality resources that I use with the world. If I think the idea is valid for myself, then it is plenty valid for others.

It may not be the best way to handle validity, but you cannot find any sort of closure in your ideas from others unless you believe in it yourself. It’s like a marriage. It doesn’t matter if your girl is the prettiest on the block; if you don’t love her, the marriage will fail. And if you love her and no one else does, it doesn’t matter. The marriage will still succeed. I didn’t need to waste so much time contemplating if I made the right decision. Now, I just continue doing this for me.

Don’t Make It a Job

During the development of the site, I’ve faced burnout maybe 3 times. I realized that I started treating some of the side project like a job. There came a point where I had to write tests to make development faster. However, creating a large module for the codebase sometimes resulted in an entire week dedicated to writing tests for it. This was an absolute dread that killed a lot of motivation for the project. I sometimes forget that I am working on the computerscienceresources.com project for my personal enjoyment and don’t need to force myself into torment.

Realize when you are slowing down and starting to find processes mundane. I think that ThePrimeagen has great advice about burnout (https://www.youtube.com/watch?v=KEWV5yaj_2o): it’s when you start finding no joy in the work you do. To follow his advice, I’ve started balancing the work with experimental fun work alongside the mandatory tedious things.

In addition, just switching work occasionally can spark more inspiration and interest again. I don’t find unit testing, writing UI, or even debugging problems boring. But if I were to spend more than a few days on one problem, I would burn out real fast.

So, stop motivating yourself by forcing yourself to get things done. That is being motivated by fear, focusing on the negative, which results in burnout. Instead, focus on the cool things that make software engineering fun and awesome. Focus on the positive side of completion, which results in fulfilling work. Experiment and swap around what you work on; then, naturally, you would discover your speed will increase as well.

Be Proud of What You Make

The biggest problem I’ve had and am still struggling with is being boldly proud and public with what I’ve built. Engineers see the holes in their designs, the faults, and all the problems that don’t matter and are never seen by end users. But none of that matters.

All big companies have released janky products. They proudly release their project, get feedback from their first customers, and continuously iterate from there. People release garbage all the time and slowly churn it into a mature product.

I had much fear in being public with my site. I was worried about what other people would think and the criticisms I would face. However, it’s been a few months since I’ve released the application without any advertising, not even much amongst my friends. The site has driven little traffic, which is to be expected.

So, I have reached my goal: I have not received any criticisms of the site, as I have no one to receive criticisms from. But my goal is to help many people, not build this project in isolation. I’ve started the process of publicity with this article. There is a lot of good advice in this article (https://dev.to/wasp/how-i-promoted-my-open-source-repo-to-6k-stars-in-6-months-3li9) that I am going to follow, such as publishing on popular sites like Product Hunt.

People proudly release and market stupid and foul projects all the time. Some people have no shame and spam their awful project on Reddit and Discord. If I — with a potentially good project — don’t even try to promote it out of introversion, how do I even stand a chance against all the newly released applications? Promotion is not a commodity; it is necessary.

Now Go Be Awesome!

So, I hope that everyone can learn from the mistakes that I have made through the development of my site. Of course, some lessons can only be learned from doing these things yourself. But I know that if you have read through to the end of this article, then you are already a person with great wisdom.

I hope you have the best of luck with your side projects, and if you have any advice or tips for me for promoting side projects, or mistakes that you’ve made, please share them in the comments. I’d love a discussion!

You go to a new company and submit your first pull request. After an hour, you have a bunch of comments. Easy (I hope) — you resolve them and repeat this review cycle until you get approval. Amazing, so that was a successful PR!

Imagine the next week arrives and you request a review for another PR. Without comments, it gets approved an hour after the request. What does this mean? Did they actually review it? If so, how thoroughly did they even review it?

The answer: There is no way to know without having a standardized merge request system within the team. Or you could memorize how everyone you work with handles their peer reviews and base your feedback off that telekinetic connection you have with your colleagues.

I read this nice book on PRs, and I would recommend you do so too even if you have been in the industry for a while: https://github.com/scastiel/book-pr. It helped me pick up on some social expectations and psychology around PRs that I’d never noticed before. I think this is a great book, but I think it’s missing a chapter on the ambiguous nature of merge approvals.

In the industry, there is an invisible set of guidelines when it comes to PR approvals, but it’s also expected that everyone knows what they are. So today we will discuss the implications of merge approvals, how much effort a review approval typically involves, and the expectations of etiquette.

The Levels of Review

First, we will discuss some background information before we jump into what a merge request entails.

There are generally three levels of code reviews, with each level requiring more effort from the code reviewer. It is rare for people to always perform all three levels of code reviews. Furthermore, not all pull requests are equal, so some changes can be so trivial that they do not warrant much effort.

The Human Linter

This level is the most basic of them all. The reviewer does not need to even know what the code is doing. For all they care at this stage, the code could be broken, but at least it looks and sounds nice. While most companies have a CI/CD pipeline or job to help with language linting and type checking, this stage is more about the opinionated side of design.

Your codebase might have a preferred style of writing code. For instance, perhaps you are writing TypeScript, and your team decides to use arrow functions over regular functions — and to use regular functions for returning object literals. Another example is a variable that could be more descriptive: instead of writing money_for_repayment, you could do cad_dollars_for_repayment.

Another way to describe this stage is finding nitpicks with the code at a superficial level. The reviewer does not need to open a code editor and checkout your branch. This stage is predominantly done in the GitLab/GitHub merge request page.

If you don’t already know, many people will prefix comments with “nit” to indicate that they have a small nitpick with the code.

An important thing to consider about this stage is that nitpicks can be contested, obviously in a polite manner. Not every suggested edit needs to be made.

Bug Catching

In this stage, the logic of your code is questioned. There must be some understanding of the code, and even a high-level understanding of what is going on in the code. However, the full picture does not necessarily have to be in mind at this stage.

Ideally, if the merge request were complex, the reviewer would checkout the branch to better navigate the code and how it affects its surroundings.

This level would also involve looking at the appropriate tests and ensuring that the test conditions are meaningful (avoiding confirmation bias).

Architecture Designs

This level requires that the reviewer understand the intent of the code, what problem it is trying to solve, and consider how to redesign the code in a ‘cleaner’ manner, whatever that means to your team. Additional context is needed, such as reviewing the original ticket and/or some internal documentation.

The reviewer cares less about the lines of code which you have submitted in the PR, but rather the intention behind your functions, context of the codebase, and the overall designs.

This kind of review is very difficult to pull off and is mainly reserved for PRs which have major impact on customers or will be maintained for a long time. These reviews are especially difficult because reviewing systems requires a large context window and a vivid imagination. Very rarely can you, as a reviewer, try to rebuild the pull request yourself and create the designs the way you intend. I know some people have trouble imagining clean code in their mind but have no trouble writing it out. Hence, the reviewer needs to already have good context of the codebase and be able to experiment with different ideas and designs in their minds.

Level Zero Reviews

There is also a hidden level outside the typical three. In this case, the reviewer completely trusts you and doesn’t care about the other levels at all. Think of it as: “I can’t be bothered.” It is quite rare to get this kind of approval, usually reserved for version updates. It could be for people who don’t really care much about giving a review, are overwhelmed, or just trust the person completely.

The Review Complexity Matrix

The best way to know how complex your code reviews should be is to look for any documents describing how your company’s code review process works. If there is no such document, ask the engineers around and make one yourself — it will show good initiative.

But, despite the ambiguity in code reviews, there are some general implied rules for how much effort goes into the type of pull request that is made. Most teams subconsciously follow a pattern based on PR complexity and risk:

Accounting for Variable Review Speeds

The matrix above is not always accurate as companies can have variations in how they perform code reviews. Sometimes, a review that would take 30 minutes at one company would take 10 at another. However, there are some other things that can change the speed at which a person will look at your review:

PR size: A bigger file, while not necessarily more complex, will require more time to review.

Files touched: Changes to core modules get Architecture-level scrutiny.

Author experience: Junior developers typically receive more thorough Bug Catching reviews (don’t take it personally!).

Timeline pressure: Tight deadlines unfortunately often reduce review depth.

Recent production issues: Teams become more cautious after bugs slip through.

People aspect: People have different review speeds, or just forget about your PR midway through, and get back to it later.

Approvals are never consistent — don’t expect that people will review your pull request at an ideal speed.

Even though code reviews are inconsistent in speed, there does exist a boundary where the speed is considered too fast. The table for that would look something like this:

The Unspoken Reviewer Personas

Now that we have discussed the different types of speeds and the different levels of reviews, there remains the most important part of merge approvals: the person giving them. People are dynamic; each have their own biases, quirks, and patterns.

I have noticed that some people have a recognizable pattern to the way they review. Learning to identify these “reviewer personas” can help you better interpret feedback and set appropriate expectations for your PRs. These are somewhat satirical characterizations, but they reflect real tendencies you’ll encounter in most development teams.

The Nitpicker: Always performs Human Linter level, rarely goes deeper. You’ll know them by their “nit:” prefixed comments about variable naming and formatting. Sometimes can be too opinionated with their suggestions, so don’t be afraid to speak out.

The Detective: Excels at Bug Catching. They’re the ones who spot edge cases you missed and ask, “what happens if this API call fails?” Maybe questions every edge case to an unfathomable degree so you need to tell them to relax, but most of the time they bring up good points.

The Architect: Reserved for complex PRs, they question design decisions and suggest alternative approaches. They’re thinking about maintainability six months from now for a function that could just be a throwaway.

The Rubber Stamper: Gives Level 0 approvals. Either they completely trust you, or they’re overwhelmed and not actually reviewing. Both scenarios are problematic in different ways and it would be ideal to try to get a review from another person, or inform them.

Etiquette and Expectations

Finally, let’s talk expectations and etiquette. There are unwritten social contracts that govern the entire review process. These rules are unwritten but violating them can make you come off as a bad engineer or an asshole to your colleagues. Funny how important things like these are never taught at school, but thankfully you have a nice guy like me to help you out with this ;).

Before Submitting Your PR

Make sure your code actually works. The fundamental assumption is that you ran the code yourself and have verified that there are no obvious errors. Submitting broken code wastes everyone’s time and erodes trust. It is super convenient for the reviewer to see some media of the software working (images/videos) included in the PR description.

Don’t hide test deletions or failures. If you removed tests or are aware of failing ones, be transparent about it in your PR description. Include your reasoning. Sometimes it’s justified, but reviewers need context.

Use draft status appropriately. Set your PR as a draft if you’re still making major changes. Don’t assign reviewers to drafts unless you specifically want early feedback. People get pinged unnecessarily and may start reviewing incomplete work.

Wait for a clean state before requesting review. Only assign people to your PR — or any form of requesting a review — when it has no merge conflicts and you’ve finished all major changes. A passing CI/CD pipeline is ideal, though some teams are comfortable reviewing while builds are still running.

During the Review Process

Signal when you’re actively reviewing. Leave a comment like “Currently reviewing” or use an emoji reaction that your team has agreed upon. This prevents multiple people from duplicating effort and lets the author know their PR has attention.

Respect ongoing reviews. If someone else is actively reviewing (as indicated by their comment or reaction), don’t merge the PR while they’re still working through it. Give them time to finish their analysis.

After Getting Approval

Limit post-approval changes. You can make small lint fixes or address obvious typos, but avoid any functional changes without asking for re-review. When in doubt, ping the approver.

You are completely accountable. Once the code is merged into production, you are the first person accountable for any sort of breaking change related to it. Even if the breaking change is not your fault (an external service for instance), you should take ownership to fix it, either with a git revert or rollback. At some companies, the accountability may be shared with the approvers too.

The Meta-Etiquette

The most important unspoken rule is that these rules themselves are negotiable and team dependent. What matters most is that everyone on your team shares the same expectations. When in doubt, ask. Most people appreciate directness over assumptions, and clarifying expectations upfront prevents friction later.

Conclusion: Making the Implicit Explicit

Do you know your own code review process? And what are the expectations for approvals at your team? I hope I was able to bring some insights to your engineering knowledge.

The healthiest teams eventually document their review expectations.

• “All database migrations require Architecture-level review”
• “UI changes need at least one designer approval”
• “API changes must be reviewed by someone from the consuming team”
• “Hotfixes can skip style checks but need extra testing scrutiny”

I hope that you enjoyed reading this article. If you find that your team does not have review expectations, take the initiative and write a doc for it!

Allan

Introduction

While working with Laravel, I noticed that I was using an increasingly large amount of repeated form data for testing. For example, in the site that I am building now, ComputerScienceResources.com (coming soon), it’s important that I have many feature/integration tests centered around posting resources. I noticed that I was repeating form information, like this:

$formData = [
  'name' => 'JavaScript for Beginners',
  'description' => 'An introductory course covering the basics of JavaScript programming.',
  'image_url' => 'https://example.com/images/js-course.png',
  'page_url' => 'https://example.com/courses/javascript-for-beginners',
  'platforms' => ['Web', 'Mobile'],
  'difficulty' => 'Beginner',
  'pricing' => 'Free',
  'topic_tags' => ['Web Development', 'Frontend'],
  'programming_language_tags' => ['JavaScript'],
  'general_tags' => ['Interactive', 'Project-based', 'Self-paced'],
]

Then, I would use that form data in a function for testing, as follows:

$response = $this->postJson(route('resources.store'), $formData);
$response->assertRedirect(); // a redirect after successful creation

I am a strong believer in two coding philosophies: repeating code is a waste of time, and tests should not be static, but property based. Let me break down what I mean in detail.

Repeated form data could easily be resolved by having a form saved as a variable and reusing it. However, this leads to my next point: I also believe in property-based testing. This means that instead of having expected inputs and expected outputs, we create randomized inputs with expected properties as outputs. Here is an extremely simplified example: Instead of 2 + 2 = 4, we can add any random two numbers and expect the output to be their sum (that is the property).

When you deal with randomized inputs, the domain space of your tests is wider and much more assured. For example, let’s say we had tests that made a POST request with 3 different inputs. I would feel quite confident that it works. But, if we had randomized inputs that ran 30 times each test run, I would feel certain that the code works (given that we defined the output properties correctly).

So, how did I go about easily generating massive amounts of randomized form data?

Solution

I have a small trick that combines the API Resources with the factory method (https://laravel.com/docs/12.x/eloquent-factories). When I design factories for my classes, I want the inputs to be wide-ranging. For example, with my ComputerScienceResources site. I have a resource factory defined as follows:

public function definition(): array
{
  $platforms = config('computerScienceResource.platforms');
  $difficulties = config('computerScienceResource.difficulties');
  $pricings = config('computerScienceResource.pricings');
  return [
    'name' => fake()->name(),
    'description' => fake()->realText(),
    'user_id' => User::inRandomOrder()->first() ?? User::factory()->create(),
    'page_url' => fake()->url(),
    'platforms' => fake()->randomElements($platforms, rand(1, 5)),
    'difficulty' => fake()->randomElement($difficulties),
    'pricing' => fake()->randomElement($pricings),
  ];
}

This is great for creating wide amounts of diverse data. But how do I convert it to form data? This is where API Resources come in handy (https://laravel.com/docs/12.x/eloquent-resources).

I can create form data from an existing model easily like so:

class ComputerScienceResourceTestResource extends JsonResource
{
  public function toArray(Request $request): array
  {
    return [
      'name' => $this->name,
      'description' => $this->description,
      'image_url' => $this->image_url,
      'page_url' => $this->page_url,
      'platforms' => $this->platforms,
      'difficulty' => $this->difficulty,
      'pricing' => $this->pricing,
      'topic_tags' => $this->topic_tags,
      'programming_language_tags' => $this->programming_language_tags,
      'general_tags' => $this->general_tags,
    ];
  }
}

However, now we have a new problem. How can we handle the fact that we need to have an existing model for the Resource API to work? Well, we can create a static helper function in the ComputerScienceResourceTestResource class. The job of this helper is to create a model using a factory, then convert it to form data. The result looks like this:

public static function fake(array $overrides = []): array
{
  // Create the model with disabled events
  $model = Event::fakeFor(function () {
    return ComputerScienceResource::factory()->create();
  }, [TagFrequencyChanged::class]);
  // Transform it to API form
  $formData = (new self($model))->toArray(request());
  // Delete after getting the array to avoid polluting the DB
  $model->delete();
  // Merge and return
  return array_merge($formData, $overrides);
}

There are some other things you have to consider as well in the helper, such as disabling events, making sure to remove the created model from the database, and having the ability to override some of the randomized fields.

Furthermore, if you are using a package like https://spatie.be/docs/laravel-data/v4/introduction. You have even better tools to convert the model to a form, but you will still require the helper function to ensure that you create a model, convert it to a form, and delete it after.

So, I can use the helper function as follows:

$formData = ComputerScienceResourceTestResource::fake();
$response = $this->postJson(route('resources.store'), $formData);
$response->assertRedirect(); // a redirect after successful creation

This can be run as many times as I like, and it is essentially like having multiple tests in one combined.

Alternative: Worksome Request Factories

Something I just discovered recently is that you can remove the need for the helper function by using a dedicated library: https://github.com/worksome/request-factories. In this library, you don’t use a model to generate your forms, but instead you rewrite form-specific Faker data. This makes sense, as it reflects a separation of concerns between the model factories and form factories. Soon, I will be migrating my existing test code to this library.

Conclusion

I hope I was able to share information about property-based testing, as well a trick I use to achieve that effect in Laravel!

I recently watched a video by Computerphile about developers’ least favorite languages: What’s Your Least Favourite Programming Language? (2024 soundcheck question) — Computerphile

At the top of the list was JavaScript.

All the bad features of JavaScript described in the video are as follows:

• Variable Hoisting
• Lack of Structure
• Untyped Nature
• Poor Error Handling
• A Mess of libraries

I felt like there should be some leniency; there is quite a nice language underneath JavaScript’s flaws. The language has garnered a large amount of hate, and I feel that it doesn’t deserve the terrible reputation it has. We have been shoehorning JavaScript into places, there are a few bad apples in its wacky ecosystem, and it was never meant to reach the scale it has today.

Perhaps the language is hated more than it deserves, and I can convince you that it’s not actually a bad language.

So, hold on a second… why am I defending JavaScript?

Am I a mega fan of JavaScript? Not really.

The best way to describe my relationship with it is that I am forced to use it, as all software engineers are if they want to do web development.

I know people who are huge fans of JavaScript, glazing it any chance they get. There is also a huge trend of early-career developers who want to use JavaScript at every opportunity: tRPC, Node, Deno and the list goes on to infinity. There are also many people I know who despise JavaScript to the bone.

So, I took some time to really understand JavaScript through a deep dive, to consider both perspectives of hate and love. I read the book: “JavaScript: The Good Parts.” Furthermore, I went though a good chunk of Mozilla Developer Network’s docs. I can say that “JavaScript: The Good Parts” was quite a nice read. But honestly, the book should be called “JavaScript: The Good Parts and Bad Parts.” There were an equal number of good things as bad things about JavaScript in this book.

I realized that there is basically no other language in the world that is like JavaScript, which is influenced by so many languages: Scheme, Self, Java (syntax), Perl (regex). But, even after reading, I still can’t see myself thinking that the language is amazingly well designed. I wasn’t like the developers who love it madly.

But I also didn’t see myself on the other side, like people who hate every little bit of the language. My feelings are more of a balance; I quite liked the language and thought it to be quite decent.

JavaScript is Misunderstood: It does not deserve all the hate it gets

What I’m arguing is that while JavaScript is frequently criticized for its quirks and inconsistencies, much of this disdain arises from widespread misuse, poor understanding, and ecosystem challenges rather than inherent flaws in the language itself. JavaScript is powerful and dynamic language — though it contains faults — that has brought forth various innovations.

Acknowledgement of Valid Arguments

I do want to acknowledge that JavaScript is a language that was rushed. There were a lot of rough edges, especially at its release. It wasn’t until ES5 that most major browsers became supportive of JavaScript. So, I’d like to talk about some of the biggest issues with JavaScript first.

The first criticism to tackle is the lack of an integer type. In JavaScript, you can only use floats, adhering to IEEE 754. This is not really a big problem unless you work with numbers outside the range of 2⁵³ — 1 or need native precision.

There is the infamous bug:

0.1 + 0.2 === 0.3 // true

But this big has existed in almost every language, including Python, C, Java, C++, and others. That’s why there is a dedicated Decimal class in most languages. However, JavaScript lacks one, which can be troublesome. As a result, you need to install a library like mathjs to handle high precision.

This brings me to my next point, which is that JavaScript feels like it’s missing a proper standard library. Even an operation as basic as deep cloning an array is missing. Here are a bunch of major standard features that are missing: Enum support, Date formatting, assertions for testing, and range or iterable utilities.

One powerful aspect of JavaScript is coercion. Coercion is an amazing tool, but it can be a bit confusing, and its rules can be seen as inconsistent. WTFjs — which shows a ton of JS funny edge cases https://github.com/denysdovhan/wtfjs — has most of its WTF’s from coercion. Some of the oddest ones are:

[] + {} // "[object Object]"
[] == ![] // true
null == undefined // true

Another major problem of JavaScript is that `this` does not behave as one would intuitively expect (binding to the local object). Instead, it follows a different rule: In a function, `this` refers to the global object. developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this

Here is a program that uses a helper function, and would not work:

function myObject()
{
  this.value;
  this.adder;
}

let obj = new myObject();
obj.value = 2;
obj.adder = function ()
{
  function helper () {
    this.value += 2; // Problem, `this` refers to the global object, not the `obj` object
  };

  helper();
}

obj.adder();
console.log(obj.value); // still 2, and no errors thrown

This can be mitigated by calling another object method instead (since it binds `this` to the object), or to create a variable called `that` and use `that`, example:

obj.adder = function ()
{
  let that = this; // using a new variable (that) to reference `this`
  
  function helper () {
    that.value += 2;
  }
  helper();
}

The above are all valid problems with the language, and there are still more which I have not even mentioned yet: silent failures, arrays being objects, variable scope, and semi-colons being optional. Despite these flaws, the language is not terrible. A better description for the language would perhaps be unpolished. In the end, JavaScript remains incredibly versatile and widely used, and with modern tooling (like Lodash and ESlint) and best practices, many of these issues can be mitigated.

The High Number of Frameworks is not the language’s fault

Now, we can start defending the language.

At first glance, it seems like there are many JavaScript frameworks which exist solely for the sake of creating frameworks. One could ask, ‘why did we make jQuery when vanilla is good enough, or why is there Angular, React, Vue, and so on?’ Then, one could make the brash conclusion that perhaps the reason is that JavaScript is a terrible language

But I’d like to argue that the reasoning behind this large number of frameworks lies in the flaws of the original DOM API.

Early on in the web’s history, when JavaScript first came out, the DOM was a mess (https://johnresig.com/blog/the-dom-is-a-mess/). This is a great talk that you should listen to that addressed the lack of standardization in the DOM API. This was the start of a very long chain of problems that followed.

There was a lack of standardization with web browsers’ DOM APIs, and normalizing functionality between browsers was hellish. So, thanks to JavaScript being the flexible language it is, John Resig created jQuery; it reduced boilerplate and normalized browser functionality. This was a huge help for the language. JavaScript was easier to write and people generally advocated for the use of jQuery over vanilla JS. I won’t mention the less popular frameworks (such as Prototype and Coffee Script) for the sake of time. I’m also ignoring Java Applets, Adobe Flash and Web Assembly.

People used jQuery; it made JavaScript so much easier and normalized. But web development demands grew: Google wanted to develop web applications that were single page applications, and with less boilerplate. So, they invented a new JavaScript framework with modern app requirements, with a focus on declarative code: dependency injection, dynamic rendering, and two-way binding.

Did this mean that jQuery or JavaScript became bad? No, there was simply a different approach needed for larger and more complex software applications. There was also a trend throughout the 2010’s to start using less semantic HTML and rely more on JavaScript for UX/UI. For example, instead of using the standard HTML form, people would prefer to implement a dynamic Form with JavaScript to override default behavior and perform side effects. So, it was natural that some jQuery codebases became spaghettified, and a new framework would replace jQuery. Refactoring and inventing abstractions upon complex code is a natural part of software development, in this case, with Angular.

Angular 1.0 was quite amazing. But, as we created more complex JavaScript applications, there were a lot of performance problems. Some common problems were two-way binding(they used a digest cycle), weird edge cases with $scope, and a very steep learning curve. I’ve never personally used Angular 1.0, so I wouldn’t know much about it. But the fear of it still resonates with many developers online.

Naturally, a new framework to improve speed and modularity took over. Facebook made React, which used a virtual DOM, and focused more on one-way data flow and component-based architecture. Then, Evan You decided to make a simpler and more lightweight version of that, and invented Vue.js. Then, Google rewrote Angular, and it became Angular v2.

There are also a lot more frameworks to mention, such as Flutter. The framework was created after Dart as a language didn’t take off; its purpose was to replace JavaScript entirely with an object-oriented and fast compiled language like Dart.

Outside of frameworks, there was also TypeScript by Microsoft which adds type safety to JavaScript and transpiles to it. This did take off because it did not try to replace JavaScript entirely, which so many systems — like web browsers — are stuck with. Instead, JavaScript became a subset of a stronger-typed and stricter language.

We are now in modern day and have reached a point where we have all these frontend frameworks that made sense to develop at the time. Furthermore, we have been advocating for people to learn these frameworks over using vanilla JavaScript. But even though some tools — like jQuery (or Alpine JS being the modern-day equivalent) — are better than others for certain tasks, it seems that popularity has taken over practicality in practice. It is almost like the go-to framework to use for anything is React. I also want to mention HTMX (I’m a huge fan), and I think not enough people consider it. Instead of considering all tools for the job, people like to jump on the React hype-train.

Even though there are already so many existing tools, the JavaScript community is keen on creating more frameworks and libraries. There are two categories of people who are creating new frameworks: those who see a different/better way to do front end development, and those who just want to make another framework. On the former, the web is a complicated and opinionated platform, people will come up with new ways to render the DOM in ‘better’ ways, and this will continue to happen forever. About the latter, these are just people who either want to make a framework for fun or perhaps have the aspirations of going viral. We must differentiate the language itself from the fact that the DOM API must use JavaScript, which results in many different JavaScript frameworks.

In conclusion, one cannot say that JavaScript is a bad language because it has too many frameworks. The major frameworks of JavaScript were created for a good reason at the time. If web browsers standardized the DOM API a long time ago, there would be far less JavaScript frameworks. Furthermore, one cannot attribute the community’s desire to spin up more frameworks a fault of the language. The faults of the community are not the faults of the language.

The Library’s Ecosystem is the Community’s Doing

The JavaScript ecosystem is bloated. This is well-known in the community as well, with jokes along the lines of npm modules being the heaviest mass in the universe. In 2023, there were 3 million npm packages (https://blog.sandworm.dev/state-of-npm-2023-the-overview#heading-total-packages-count-3342873). That is quite the huge amount; for comparison, python’s PyPi has more than 530,000 Python packages available as of 6 May 2024. (https://en.wikipedia.org/wiki/Python_Package_Index)

The reason behind this large number of packages is a mix of many things.

JavaScript is everywhere: Node, React Native, Electron, web development, etc. It is natural that there are many packages to fill in niches.

I also mentioned earlier that JavaScript is missing a standard library, and people have taken matters in their own hands.

But the biggest reason is that the community is focused on a culture of small, composable packages. One of the UNIX philosophies is to “make each program do one thing well.” It seems that the community has taken this idea to the extreme. There are programs like is-even, left-pad, or slugify, which one could implement themselves in a time of 15 minutes maximum.

This npm explosion of micro-packages has created a bad reputation for JavaScript, with security & maintenance risks, bloated dependencies, and fragmentation of the ecosystem. JavaScript was, however, merely the tool amid all of this. JavaScript, as a language, doesn’t dictate how developers structure projects, write code, or distribute packages. It doesn’t require developers to create thousands of micro-libraries. That’s a cultural choice, largely shaped by community practices, not language features. Combine that with the “small reusable module” philosophy from Node.js, and you have a recipe for explosive growth. The language didn’t enforce this; it merely enabled it.

I think that yes, JavaScript perhaps started the explosion with its rough edges, but the community really overkilled the ecosystem.

Core Misunderstandings of the language

I think there is another big reason that people hate JavaScript: people have not been bothering to understand the language at a fundamental level.

People see some of JavaScript’s different nature — prototypical inheritance, execution model, etc. — as traits of a poorly designed language. One could argue that JavaScript is poorly designed because of the valid arguments I’ve already touched upon. But, to argue that this language has no structure is wrong.

JavaScript is fundamentally a prototypal object-oriented language. It does have a solid foundation of structure; it just isn’t very clear about it. I think this is the biggest point of misconception on the language. There is a big discrepancy between what people think JavaScript is, and how it works.

One example I want to mention is ‘classes’, introduced in the ES6 revision. ES6 was an amazing update to JavaScript; one could argue it killed CoffeeScript as the language was now matured enough. But now, there are ways to declare ‘classes’ in JavaScript.

The old — and perhaps ‘correct’ — way to create objects was with Object Constructors, which is akin to JavaScript’s true nature, binding variables to the local object.

function Car(name, year)
{
  this.name = name;
  this.year = year;

  this.print = function() 
  {
    console.log(this.name + " " + this.year);
  };
}

car = new Car('DMC DeLorean', 1955);
car.print();

However, we can also declare the same thing in the ES6 class format:

class Car {
  constructor(name, year) {
    this.name = name;
    this.year = year;
  }

  print()
  {
    console.log(this.name + " " + this.year);
  }
}

car = new Car('DMC DeLorean', 1955);
car.print();

This makes JavaScript look like a language that supports classical inheritance, such as Java, C#, Python, and C++. But the problem is that this disguises the true nature of JavaScript, which uses a prototypical-inheritance system (https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Advanced_JavaScript_objects/Object_prototypes).

If you looked at the class example above, and think that JavaScript is like Java, this code below would make no sense:

car = new Car('DMC DeLorean', 1955);

details = {
  creator: 'Emmett Brown'
};

Car.prototype.details = details;
console.log(car.details.creator);

Prototypical inheritance does not follow classical inheritance of classes, but rather the inheritance of objects. Furthermore, JavaScript has the added feature of flexibility: adding and removing prototypes at runtime.

So, I would say that a lot of people don’t bother learning JavaScript for what it is and how it works. The problem with my claim, however, is that I don’t have any empirical data to show for this. I guess the closest would be the fact that we say Vanilla JavaScript to state native JavaScript. The original term was satirically used as the name for another JavaScript framework: http://vanilla-js.com

Another example of people not really bothering to learn about JavaScript would be how many people also don’t understand the event queue, and how JavaScript in a single-threaded worker can handle multiprocessing (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model). Again, I don’t have any evidence to back me up on this, I just see a lot of confusion about the event queue on Stack Overflow.

Furthermore, since it is advocated to use a framework over vanilla JS, most people have only worked with JavaScript in a framework setting. It is easy for one to completely disregard learning the fundamentals of JavaScript as a standalone language. It is the kind of language that allows you to get away with messy code thanks to its dynamic and expressive nature. Inadvertently, this leads to a superficial understanding of the language’s core principles.

With so many people working with JavaScript in a framework setting, there can be a lot of badly written and diverse JavaScript code. There happens to be no definitive way to write JavaScript code. Unlike Golang, where codebases will look very similar, JavaScript can range from reasonable to JDSL (https://thedailywtf.com/articles/the-inner-json-effect). I think that if we look at JavaScript, from a very high-level overview — ignoring the current ecosystem — the language has quite a lot a beauty to it that we must appreciate. I think that more people should learn about this language standalone and appreciate the beauty in it.

The Beauty of the Language

I want to take a short amount of time to just talk about how nice JavaScript is, despite its rough edges.

JavaScript can be surprisingly elegant. It borrows a lot of ideas from functional programming; hence functions are treated as first-class citizens. Hence, we have access to higher order functions like mapping, filtering, forEach. In addition to that, it is very easy to create anonymous functions, with some of the shortest and cleanest syntax seen in any language:

const add = (a,b) => a + b
add(1,2) // 3

This elegance is enhanced by the notation to create an object. Objects can be easily represented, with its variables and functions like so:

const ringo = {
  name: "Ringo Starr",
  instrument: "drums",
  year: 1940,
  print: function() {
    console.log(this.name + " played the " + this.instrument + " and was born in " + this.year);
  }
};

ringo.print();

In fact, the JavaScript Object Notion is so simple and easy to view that we have adopted it as the go-to standard for formatting data: JSON.

Furthermore, people complain a lot about JavaScript’s global variables. But, since ES6, scope is no longer limited to function or global scope using let or const. This created a powerful feature: closures. It allows you to combine a function with the information of the environment where the function was declared. (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Closures). A nice example would be:

function makeAdder(x) {
  return function (y) {
    return x + y;
  };
}

const add5 = makeAdder(5);
const add10 = makeAdder(10);

console.log(add5(2)); // 7
console.log(add10(2)); // 12

The makeAdder function now has information about the lexical environment — context in which variables are defined — and can return a function with that. This is powerful since JavaScript can “remember” variables from its surrounding scope even after the outer function has finished running. This can remove the need for duplicating code or using global variables. Furthermore, since JavaScript does not have private variables, one can come up with a workaround using closures, such as in the following:

function createBankAccount(initialBalance) 
{
  let balance = initialBalance; // cannot be accessed 

  return {
    deposit(amount) 
    {
      balance += amount;
    },
    getBalance() 
    {
      return balance;
    }
  };
}

const account = createBankAccount(100);
account.deposit(50);

console.log(account.getBalance()); // 150

Now, the balance cannot be accessed directly.

I think that is enough on the beauty of the language, you can research more into the language with these recommendations:

https://github.com/getify/You-Dont-Know-JS

https://www.oreilly.com/library/view/javascript-the-good/9780596517748/

Conclusion

I hope I’ve been able to shed some light on how JavaScript can be quite a nice language at times. I think that much of the hate towards it has come from misuse and the bad reputation of its ecosystem, rather than the language itself being terrible.

JavaScript is a decent language treated worse than it deserves.

Thank you for reading!

Over the past few years, I’ve been building a mental list of small misconceptions other people in software development say that bothers me more than it really should. Typically, these examples are two things that are not the same but are used interchangeable by the masses.

So, whether it is to share information for the sake of teaching or catharsis, I will introduce the list below:

A Modem and a Router are two different things

Stop saying that your router is what connects you to the internet!

People interchange this one the most. Let me get this straight:

• The modem is what connects your network (typically your home) into the internet. Without the modem, you won’t have any internet access.
• The router is what routes the IP packets between networks. It could be to another network, your subnetworks, the internet, whatever. Basically, it handles the routing of your network.

The modem’s job is very simplistic, all it does is transmit your network data in a transmission medium that is suitable for you to reach the internet. This is not as complex as the role which the router must take on. Henceforth, people typically only have a single device in their home: a modem and router combined into one device. Since we need a name for this device, I guess it is fine to call it a router. But don’t you dare say that a router’s job is to connect you to the internet.

I hope we understand the differences. In fact, let’s get more technical.

The router uses several notable protocols for handling the routing of IP packets. These include Network Address Translation (NAT). Border Gateway Protocol (BGP) which can be split into internal (iBGP) or external (eBGP).

NAT is to convert the local IP addresses in your network to the public IP your ISP gave you. BGP is to help determine the routing of your IP packets either inside your network, or to a larger external network, like the internet.

Meanwhile, a modem uses protocols which I have never heard of in my life. One of them is Gigabit Passive Optical Network (GPON). This is used in fiber-optic networks.

Now, onwards to more rants!

People say Big O Notation in Interviews when they mean Big Theta

During technical interviews, it’s become a standard to be asked the Big O notation of your algorithm. Typically, what the interviewer is asking for is the time complexity of your algorithm since they want to gauge if you know how fast the code you wrote is. The problem is that Big O is probably not what they are asking for.

The mathematical definition of Big O is as follows:

Let f(n) and g(n) be functions that map positive integers to positive real numbers. We say that f(n) is O(g(n)) (or f(n) ∈ O(g(n))) if there exists a real constant c > 0 and there exists an integer constant n₀ ≥ 1 such that f(n) ≤ c ∗ g(n) for every integer n ≥ n₀.

This seems like a mouthful but, I can explain slowly. Let’s say f(n) and g(n) are two algorithms that you wrote. Now, let’s say that past a certain input size n₀, maybe it is n = 1000, the algorithm g(n) is now much slower than f(n). In fact, g(n) is always slower than f(n) by at least a constant, called c.

So, we can say that the algorithm f is Big O of g. So, in colloquial terms, Big O is to define the upper bounds of the algorithm.

Understood? Well, technically, by the mathematical definition, we could just answer the interview question above:

What is the Big O Notation of your algorithm?

With the same response every time: Big O(n!).

Since that is probably the slowest algorithm one could make. Obviously, you shouldn’t do this since you will fail the job interview and be ridiculed for considering that your algorithm was that slow.

But the correct term that the interviewer should be using is Big Theta (Θ).

Big Theta (Θ) is for comparing two functions (algorithms), f and g. If f∈Θ(g), then it has the same asymptotic complexity as g.

Another cool way to think of this is that if you divide f by g, and do the limit of the input n to infinity, then you will get some constant k.

So, if f ∈ Θ(Log(n)), then you know how fast your algorithm is, not the upper bound, not the lower bound, but the actual speed. But, whatever, we will keep saying Big O in the industry as if it were the same thing.

DevOps is a Cultural Practice, not a Job

Please stop saying that you are a DevOps Engineer.

DevOps was a cultural movement that started around 2007 when people realized that deployments of infrastructure and collaborations between the development team was lacking. So, there came a new ideology that was to introduce the use of automated tooling, closer collaboration, encouraging work environments that utilized the growth mindset, and better testing. This allowed the collaboration between teams to be stronger, autonomous, and transparent.

One of the poster child’s (or is it poster children?) of DevOps is Etsy. You should read more about it. I found a nice article https://www.simform.com/blog/etsy-devops-case-study/ that explains it.

So, what is the terminology misconception that bothers me? Well, people use the term DevOps Engineer as if it were a role to cover everything related to infrastructure. The right term would be infrastructure engineer or system administrator.

I think the best comparison for calling someone a DevOps Engineer is calling myself a Chinese New Year Engineer because I am good at making dumplings and fried rice.

If you are not convinced yet, take a look at this discussion here: https://www.reddit.com/r/devops/comments/1f0u1nn/why_are_there_people_in_this_sub_who_thinks/

Scrum and Agile are Different!

To summarize quickly, scrum is a subset of agile.

Agile is a broad philosophy for software development. It involves iterative development, collaboration, and adaptability. The main focuses on agile is the ability to react to change quickly. This involves getting early interaction with the customers and collaborating. The 12 principles behind Agile Manifesto can still be viewed in glorious detail: https://agilemanifesto.org/principles.html.

These ideas are a complete contract from the traditional waterfall planning model, that involved a singular long planning session, and afterwards only followed development. Agile is a beautiful idea, and those 12 principles lead the way to two specific frameworks that adopted agile:

1. Extreme Programming (XP)

I will highlight some of the important features: customer obsession, extreme teamwork, and constant feedback. On the development side, there are small releases, pair programming, and test-driven development. More details can be viewed at: http://www.extremeprogramming.org. It is quite a nice read.

2. Scrum

Now this is what we wanted to talk about. Scrum is another framework of agile, the name actually come from Rugby, where a team comes together to move the ball forward. The framework has three main pillars of focus: transparency, inspection and adaptation. But I don’t want to get into the details. If you are curious, it is here: www.scrum.org/resources/what-scrum-module

I think the ideologies behind scrum are quite nice. It is quite efficient for fast software development and growth amongst team members. Debating whether scrum is a good framework in practice is a completely different topic.

However, I want people to know, if they say they hate agile, they better know that they are referring to the broad philosophy, not scrum or XP!

Stop Calling AI and LLMs The Same

Artificial intelligence is defined from Wikipedia as:

capability of computational systems to perform tasks typically associated with human intelligence.

Just remember that LLMs are a subset of AI’s. I am a little tired of hearing the word AI tossed around so often for LLMs. There are so many other cool AI software’s out there:

- AlphaGo and AlphaZero (from DeepMind), an amazing unsupervised deep neural network.

- OpenAI Five, an AI to win Dota 2. Yes, OpenAI once did not LLM related things.

- NASA’s ST5 Antenna Design being derived from a genetic algorithm. https://www.jpl.nasa.gov/nmp/st5/TECHNOLOGY/antenna.html

- SAT Solvers, determining how to make a Boolean formula true.

There are so many cool AI techniques that predate LLMs. If you are interested in learning about Artificial Intelligence, take a look at this amazing course: https://www.edx.org/learn/artificial-intelligence/harvard-university-cs50-s-introduction-to-artificial-intelligence-with-python

Not Every HTTP API is a REST API

I think that the idea of what REST is, is quite misunderstood. Most people know that it stands for Representational State Transfer. Creating an HTTP API is not creating a REST API, get that out of your head. Stop trying to fill in buzz words with your tech stack and say that you have a REST API.

Furthermore, don’t bother with small details like which HTTP verb is more RESTful: PATCH vs UPDATE. Apparently, HTTP verbs were not mentioned in the original dissertation (https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm). REST was just a proposed architectural style that was to guide the early internet into conforming standards.

I think this blog post is the best summary to the problem: https://twobithistory.org/2020/06/28/rest.html

Furthermore, there are some criteria in the original REST specifications which some people would never do: uniform interface, and one part of that is being HATEOAS compliance. Again, most people don’t know what HATEOAS. To summarize quickly, a client could have no idea how to navigate a website beyond simple hypermedia — links for example — and navigate the site by the server response. A great article on this is by HTMX (an amazing framework): https://htmx.org/essays/hateoas/

So, we can assume that most API endpoints are not complacent with being a uniform interface. I would say that either your API is RESTlike, or it follows a specific specification like (OpenAPI): https://swagger.io/specification/

But, in the end, I think that the word RESTful is becoming just a buzz word that will keep being tossed around into complete meaningless until it becomes synonymous with HTTP API.

Monoliths are not Bad

Developers hear monolith and think evil, slow, unscalable. I think that is wrong for so many reasons.

First, I find that monoliths are perfect for 90% of jobs out there. Most software out there usually hits a maximum of 4000 monthly users. What is the source? I eyeballed it, let me know if I am wrong. Second, monoliths are simple to maintain, your codebase is in one single location, and one can hopefully easily view what part of the monolith is responsible for what part. I think that speed of development is the most important thing when it comes to software (besides software quality).

Now, one could say, “microservices are much more organized since they have a single responsibility.” That could be possible, but even if you somehow managed to organize the separation of concerns between the services perfectly, there comes the problem of handling scalability, communication, and being independent from other services. If most of your services are broken after a single service is down, it’s not a good microservice system; perhaps it shouldn’t even be called that.

One article that supports the point I am making about monoliths is from DHH (the creator of Ruby on Rails) https://signalvnoise.com/svn3/the-majestic-monolith/

So, basically, don’t overengineer your software. Bother with overengineering once you need to. Everyone wants to role play as a solutions architect at Google but focus on what is needed from your users first.

OAuth is for Authorization, not Authentication

Authorization is knowing what someone is allowed to access.

Authentication is knowing if someone really is who they are claiming they are.

OAuth was designed as an authorization framework that allowed granting a client application limited access to a user’s resources without exposing the user’s credentials. Furthermore, Authorization requires Authentication, you cannot have any sort of authorization of an individual unless you can authenticate such individual.

What you really mean when you say you are using OAuth for Authentication is probably that you are using OpenID Connect, or you are just accessing an API with an access token and want to sound fancy. To use OAuth, the application needs to be wrapped around some existing authentication layer, whether it is your own cookie implementation, or OpenID.

If you are still confused, this is an amazing article to understand more: https://oauth.net/articles/authentication/

Do not Repeat Yourself is not about Removing Duplicate Code

DRY is not about duplicate code being evil. It’s the duplication of knowledge, or redundant knowledge being evil.

Don’t be the kind of developer that sees a line of code repeated during code reviews and write “nitpick”, this code is repeated.

Here is a very extreme example to prove my point:

name: string().required("Name is required").max(100, "Max 100 chars"),
page_url: string().url("Must be a valid URL").required("URL is required"),
image_url: string().url("Must be a valid image URL"),
platforms: array()
.of(string())
.min(1, "At least one platform is required"),
description: string().required("Description is required").max(4000),
difficulty: string().required("Difficulty level is required"),
pricing: string().required("Pricing information is required")

Notice how there is a lot of repeated code here. The idea is that the knowledge is unique each time.

But another thing to mention is that it’s also okay to duplicate knowledge sometimes. It’s called being a little bit WET (we enjoy typing). It’s okay to duplicate knowledge for a bit as long as things remain readable, and maintainable. Finding the source of shared knowledge can be quite tedious since it is no longer localized.

So, basically, it’s okay to do moist coding. Don’t follow a single silver bullet. There is always a balance to software.

Conclusion

Well, I hope today was a very informative and educational April Fools day, where you will no longer annoy a percentage of software developers with these small misconceptions that don’t even matter. But you can also continue to annoy people too. If you are interested in that sort of thing, don’t let me stop you.

Thanks for listening to another of my rants!

— Allan

The contest was very well organized and filled with challenging problems. The GitHub repository can be found here: https://github.com/infosec-ucalgary/magpieCTF-2025

My team did quite well, landing in the top 10, which was quite a nice feeling.

But, in addition to the CTF challenge, there was a writeup challenge. You could submit writeups (solutions/guides to challenges), and the top three were selected. This was my first time doing a writeup and I wished that there were more examples on the internet.

So, I managed to snag first place in the writeups, and I wanted to share it below!

Magpie CTF 2025 cops-like-ciphers-and-cookies

Written By

Team: education is fun

Member: SadBread

Category

Web

Description

New email from cors@nypd.gov:

We believe that there is a vulnerability within the NYPD landing page, that has been overlooked for way to long. Not only that but it was exploited within the days following Krypto’s murder.

Check to see what the vulnerability is, and if it has anything to do with our suspects.

Edward Cors — NYPD

http://challenges.magpiectf.ca:13000/

Introduction

Only a website is provided: http://challenges.magpiectf.ca:13000/

Upon visiting the website link, we are greeted with a webpage that looks like the following:

There does not seem to be much information related to vulnerabilities on the web page provided, only a to-do list on the left and a mission briefing summary on the right.

However, one thing that is notable on the website is that there is a URL to a webpage: https://themindfool.com/consistency-is-key.

Upon clicking on the article, one can observe that it is simply a mental health blog. There is nothing to do with the CTF in the content of the blog.

Given that MagpieCTF does not own the domain `themindfool.com`, the article title — rather than the content — is likely a hint: consistency is key. Since we don’t know anything about this website, we will just keep this in the back of our mind.

Reconnaissance

Naturally, one of the first things to do when analyzing a webpage is inspecting the source of the page. The shortcut for this is typically (Control+U) on web browsers.

Or, one can curl the webpage, whilst also viewing the response headers (with `-i`) in case there is anything important in them

$ curl -i http://challenges.magpiectf.ca:13000

The results for the curl are as follows:

HTTP/1.1 200 OK
X-Powered-By: Express
Set-Cookie: eiejmfm-yfgp=iirkb; Path=/; HttpOnly; SameSite=Lax
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Sun, 23 Feb 2025 01:14:51 GMT
ETag: W/"b04–195305f0f63"
Content-Type: text/html; charset=UTF-8
Content-Length: 2820
Date: Fri, 28 Feb 2025 01:01:03 GMT
Connection: keep-alive
Keep-Alive: timeout=5
<!DOCTYPE html>
<html lang="en">
…
Rest of HTML continued here

Notable Finds

1. The Set-Cookie header creates a cookie with the key of eiejmfm-yfgp, and the value of iirkb.

Given that the title of this challenge is called: Cops Like Ciphers and Cookies, this text is not just a random bunch of letters, but a ciphertext. Furthermore, this ciphertext looks quite short and simple, making it likely to be a primitive cipher. Now, we need to figure out what cipher and key was used to decipher this.

Remember that we saw themindfool.com article before? What was the title again? consistency is key. It is likely that the key for this ciphertext is consistency. The problem now is that we don’t know what cipher it is using.

Bonus: Using a site like: https://www.boxentriq.com/code-breaking/cipher-identifier. One can detect the likely primitive ciphers that was used. Then, using a site like https://www.dcode.fr/en, one can decode the ciphertext.

2. While going through the HTML, there is a interesting string found.

There is a span that contains a class with a long string, which was hidden in the to-do list:

<span class="dot V2UgbmVlZCBzb21lb25lIHRvIGZpeCAvbG9naW4sIGl0J3MgYmVlbiBicm9rZW4gZm9yIGZhciB0b28gbG9uZy4="></span>

This string looks like an encoding format because it ends with an equal sign `=`, which is padding from base64 encoding. There is also a small chance it could be a ciphertext or such, but let’s first check if it is an encoding format since that is much easier to decode.

Bonus: If we were uncertain of the encoding format, and couldn’t recognize it was base64, we could check with a site like https://dencode.com/en/, which would provide results for a wide range of encoding algorithms.

After decoding the base64 string using the base64 program from the coreutils package:

$ echo "V2UgbmVlZCBzb21lb25lIHRvIGZpeCAvbG9naW4sIGl0J3MgYmVlbiBicm9rZW4gZm9yIGZhciB0b28gbG9uZy4=" | base64 - decode
We need someone to fix /login, it's been broken for far too long.

We can see an important hint, there is a endpoint /login that we can try to visit. This should be our next lead.

Bonus: Using a web server scanner like Nikto (https://github.com/sullo/nikto), we can quickly find site vulnerabilities and potential leads. The scanned site looks like the following:

$ nikto -h http://challenges.magpiectf.ca:13000
- Nikto v2.1.5
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+ Target IP: 3.142.244.221
+ Target Hostname: challenges.magpiectf.ca
+ Target Port: 13000
+ Start Time: 2025–02–26 09:39:52 (GMT-7)
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+ Server: No banner retrieved
+ Cookie eiejmfm-yfgp created without the httponly flag
+ Retrieved x-powered-by header: Express
+ Server leaks inodes via ETags, header found with file /, fields: 0xW/b04 0x195305f0f63
+ The anti-clickjacking X-Frame-Options header is not present.
+ Uncommon header 'x-content-type-options' found, with contents: nosniff
+ Uncommon header 'content-security-policy' found, with contents: default-src 'none'
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Allowed HTTP Methods: GET, HEAD
+ OSVDB-3092: /login/: This might be interesting…
+ 6544 items checked: 0 error(s) and 8 item(s) reported on remote host
+ End Time: 2025–02–26 09:49:37 (GMT-7) (585 seconds)
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+ 1 host(s) tested

The results from the Nikto scan show the endpoint /login.

Bonus: Furthermore, in future CTF’s, one can consider using a DNS discovery tool like gobuster(https://github.com/OJ/gobuster), combined with a wordlist from SecLists (https://github.com/danielmiessler/SecLists/tree/master/Discovery/DNS). However, in this CTF, brute forcing and discovery tools were not allowed.

Dead Ends

An important endpoint to always check on a webpage is /robots.txt. Robots.txt is the txt file that implements the robotics exclusion protocol. This means that we can see which endpoints web robotics are not allowed to visit. Commonly in CTF’s, endpoints and clues could be found here.

However, in the case of this challenge. There was no such endpoint.

$ curl -i http://challenges.magpiectf.ca:13000/robots.txt
HTTP/1.1 404 Not Found

In the webpage, there were other script files: for CSS and JavaScript. The easiest way to view all the URLs that were requested from the web browser is to view the Network tab of your web browser.

Here, we can view through the main.css, style.css, and script.js code to find notable comments, code or clues.

I will spare you from all the details. The only notable file was the script.js file, which contained a single function: takeToWebsite, which is completely unused. The belief is that this file contains no purpose but to emphasize that the website is a very important clue.

It may not have been very useful, but it’s important to check through all the files for clues.

/login Endpoint

Upon reaching http://challenges.magpiectf.ca:13000/login, we are greeted with the page:

Once again, I like to curl the webpage with the response headers:

$ curl -i http://challenges.magpiectf.ca:13000/login
HTTP/1.1 200 OK
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Sun, 23 Feb 2025 01:14:52 GMT
ETag: W/"44c-195305f149c"
Content-Type: text/html; charset=UTF-8
Content-Length: 1100
Date: Fri, 28 Feb 2025 03:05:42 GMT
Connection: keep-alive
Keep-Alive: timeout=5
<!DOCTYPE html>
…
More HTML

First Impressions

So, we can see that there is a login portal for the web page. We can’t interact with the form in the HTML since it is disabled. Furthermore, there is a note to the admin of IT that we were probably not meant to see.

We can see that the admin text in the web page is italicized. This indicates a very important clue. We now know that the admin of this application is likely the superuser.

Furthermore, there is a note that they are removing cookies from this page. So, now we know two important things:

• The superuser is called admin
• Cookies are a very important step in this CTF

Dead Ends

1. The first thing to do is to see if we can attempt a login with a POST request using a tool like curl.

$ curl -X POST http://challenges.magpiectf.ca:13000/login
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot POST /login</pre>
</body>
</html>

Unfortunately, it seems that posting is not allowed.

If posting were allowed on this endpoint, we could’ve attempted posts with encodings of application/x-www-form-urlencoded, and various usernames and passwords such as *admin*, and consistency as the key/password.

Notable Finds

Upon looking through the webpage, we will find another string of text that is similar to the base64 we found earlier. In the metadata section we can see a new encoding string

Once we decode the base64, we can see the following result:

$ echo dmlnZW5lcmU= | base64 - decode
vigenere

It just reads vigenere. So, what is vigenere? If you don’t know, google it

This is referring to the Vigenère cipher. This would answer one of the questions we had earlier: What was the cipher that was being used to encrypt the cookie? It is Vigenère. Furthermore, we knew from before that the key must be consistency. Now that we know the cipher and key that is being used, we can now see what the cookie key and value is saying.

Using a site like https://www.dcode.fr/vigenere-cipher, we can input the cipher text and the key.

We can see that the cookie key was representing current-user. This in itself is fine and not insecure. Plenty of sites happily show their cookies for their current user session, and the value that follows. The security of a session cookie usually lied in the entropy of the session token. A secure session token should be at least 16 hexadecimal characters, making it very difficult to guess an active session.

There are also other session tokens frameworks, a notable protocol that trusts the clients side is JWT. However, since they trusting what the client claims they are, the server uses advanced cryptographic functions like RSA and HMAC with SHA256 to prevent spoofing of any kind.

This applications seems to have taken more to a security by obscurity approach since they were trying to hide what the cookie was doing. Furthermore, they didn’t do a very good job of it since we now deciphered it. The cookie value indicates that the current user is a guest. Therefore, if we can edit this cookie to something else, we may be able to log in as that user instead.

The first thing to try is setting the eiejmfm-yfgp cookie to admin. This however does not do anything. Perhaps the problem is that admin needs to be in ciphertext form like the previous value: iirkb

Solution

From everything we gathered up to this point, we now have the following information:

• The administrators of this application really likes both ciphers and cookies (from the title of the challenge).
• We discovered a deprecated login page which indicated two hints:
• The Vinegere cipher is likely being used.
• The superuser of the application is likely admin.
• The homepage indicates that consistency is key.
• There exists a cookie with the key and value that was ciphered. Furthermore, we were able to decipher it to be current-user=guest.
• setting the cookie eiejmfm-yfgp=admin does nothing.

Putting this all together, we should try to encipher “admin”, and then set the cookie to that value.

So, crzav is the value to set to the cookie.

Using your web browser in developer mode, you can edit the cookie value by double-clicking the value you wish to edit.

Upon doing so, we wish to see the effects that this cookie would have on all endpoints of the site. If we happen to refresh the page with the new cookies on the homepage: http://challenges.magpiectf.ca:13000, we will notice that the cookie value will reset back to iirkb, and nothing occurs.

Now trying the /login endpoint instead with the new cookie. We will get a new page shown to us:

We now see the flag displayed on the screen, with a little story for the detective hunt. Congratulations!

magpieCTF{wh3r3_w4s_Jake}

But through a lot of continuous effort, I now read for an hour daily, finishing at least three textbooks a year and a fiction book every month.

I will have this article split into three parts to save you time:

1. Why reading matters (A LOT)!
2. Mistakes I made getting started
3. My tips to make the most of your reading!

Why Reading Matters (A Lot!)

My initial goal for reading was to improve my experience as a software engineer (or developer). Near the start of university, I learned that the only way to improve my software skills (besides just coding) was to understand the foundations of software.

I’ve had a few shares of online courses I went through in high school, the best ones being on edX. But I quickly realized books were usually jam-packed with much more information than any other resource. Text is one of the most compressed forms of knowledge for the brain to dissect, like raw information for us to consume. So, for the sake of improving my skill set, reading was a priority.

Furthermore, some companies like Amazon require a heavy amount of reading. Mentioned from the Amazon Way by John Rossman:

• “If you needed to explain a new feature or investment to the S-Team or Jeff himself, you began by writing a five-to-seven-page essay… Then, at the beginning of the meeting, you would pass out this narrative and sit quietly for ten minutes while everyone read it”

So, reading is one of the best ways to dissect information, allowing one to dive deeper into the fine-grain details, and even Jeff Bezos agrees.

The problem was, I sucked at it.

Not only did I suck at reading non-fiction, but there was also the side of fiction books. I’ve always wanted to be a sophisticated person; someone who reads classic books. I have barely read any fiction books, and I felt like a complete imbecile in culture. I couldn’t discuss any cool books like 1984, Frankenstein, etc. I thought fiction books were only for younger audiences, or suited for posh individuals, with little real practicality. I mean, why read a fiction book when I could be learning about software?

However, I’ve seen scientific proof that reading fiction books can do wonders for the mind:

• It can improve social cognition (https://pmc.ncbi.nlm.nih.gov/articles/PMC4733342/). This can be seen as vital for a job setting, where we deal with managers and coworkers.
• Reading can improve stress levels, reducing them by over 68% (Lewis, D. (2009), Galaxy Stress Research. Mindlab International, Sussex University, UK.)

Now, there are other things that I think that reading does, but I have no sources to back me on this, so pretend like it is all true. Yep:

• Improves memory
• Helps sleep
• Preventing cognitive decline
• Making you live forever

So, I hope I got you all convinced of the power of reading and the wonders it can do for you: both career and health-wise.

Mistakes I made Getting Started

I wanted to make reading a habit for learning software, so starting I tried to pick up a heavy textbook.

It was painful.

I got bored, frustrated, and tired. Most of the time, I couldn’t bother anymore. I had the same issues with fiction books too.

So, I want to share the biggest mistakes I made so you can avoid them yourself.

Starting too Big

I think the biggest mistake I made was trying to get into hard reads right off the bat. I had a few classic books lying around and wanted to get into it. I picked some of them up, like Sherlock Holmes (A Study in Scarlet). Man, it was a tough read. It makes it harder to get into a habit when reading something complicated and foreign like that.

Furthermore, on the side of non-fiction, there is a large range of difficulties in textbooks. Some texts read as if it were a fine print with the blandest possible information, while others can be descriptive yet interesting and throw in jokes here and there.

Remember that there is a range of difficulties in any book genre. Some will be a lot easier to read than other. Don’t be afraid to start too simple, it’s important that your reading journey starts with ease. This leads to my next mistake.

Reading Things that were Boring

I started off reading simply to learn. I didn’t find the process that engaging or interesting.

It was more of a chore, quite like being forced to show up to lectures at that one mandatory university class that you hate.

I was embarrassed to read stuff like Harry Potter, or Hunger Games, thinking that they were just for teenagers, and that I was past the age for stuff like that. But, once I started on those series, it led to my passion for reading in general. Sometimes you need something to get you into reading, start with something simple and interesting, and then you can naturally find yourself reading more complex works.

In addition, for textbooks, sometimes I would choose textbooks that aren’t the most concise and detailed in favor of more interesting reads. This is a bit debatable, but I enjoyed reading Beej’s Guides (For C, networks, and network programming), even though there are a few syntax errors and outdatedness in the C code. I did this since Beej’s writing style was simply more interesting to me and allowed me to dissect much more content. The errors in the textbook were minimal, and I always resolved to other resources for more details anyhow.

In addition, find yourself some other ways to enjoy reading. I’ve never done so myself, but reading with audiobooks can do wonders for others.

Forcing Myself to Understand Everything

I will start with the fiction side of things. When I started reading “100 Years of Solitude,” characters and events started leaking out of my mind. What made it even more confusing was that some characters have the same names, and there are at least 15 of them.

At first, I reread sections that I didn’t get, or if I forgot something, I would search through the book. I wanted more than just reading a book, but to dissect all its details. Soon, I realized that maybe the author intended for you to flow through the book like one does through life, forgetting the fine details but recalling vague memories. So, I stopped feeling the pressure to understand every little thing and just went with the flow of the story.

Furthermore, it’s fine to use sites like SparkNotes to help understand the plot, deeper meanings, or whatnot. There is not a single defined way to enjoy books. Do it however you like!

On the side of non-fiction books, please don’t force yourself to get a concept that is too hard or complex. When I read through textbooks and don’t understand a concept, I would typically reread a section or seek an alternative resource like Wikipedia. By then, I would understand the concept and move on. However, there were times when I reached things beyond my grasp, and I would let it be a roadblock.

Don’t.

Feel free to skip things, maybe it will make sense when you finish a later chapter and go back to it. The structure of a book is usually a great guide, but sometimes you must bushwack.

Buying Paperback Books

Books are expensive. Try to find ways to mitigate that cost, like going to the library.

The best investment I’ve made was a Kindle;, books were so much cheaper this way. Utilizing e-book subscriptions, one can save a ton of money.

Furthermore, there are sites that provide e-books for free. My goodness, shame on them. The way these sites do so is none of my business… you should not investigate this as an option yourself, especially for textbooks that cost $80 for no reason whatsoever. Don’t consider it 😏

Making the Most of your Reading!

So, at this point, I’m going to explain things I like to do as I read that make my life more fun and interesting whilst reading.

Not being Afraid to Skim Things

Sometimes chapters can be boring.

This applies to both fiction and non-fiction.

Some chapters in fiction books can just be completely removed without impact on the story. Am I suggesting to totally skip these chapters? No. I’m saying that you don’t need to read it in the finest detail as one would with the other parts of the story. Now, here is the hard part:, how do you know what part of the story to skim? Well, for me, the best metric is how fast my brain is shutting down from the text I am reading. But sometimes this can be confused as being tired in general, and in need of a break.

Some textbooks contain chapters that are copied and pasted texts from documentation, which are so detailed that if one were to dissect it all, you would waste your entire reading session on 2 pages. The best metric for determining whether you should skim a section is judging whether you will remember the details you are currently reading. Of course, this is completely dependent on the person since some details may be more interesting to you. Furthermore, sometimes there are things that one should not skim if it were essential to understanding the textbook. Skimming is less about skipping the high-level concepts of a book, but skipping the extremely low-level details, such as specifications, implementation details (at times), and history (I can’t remember the detailed history of technologies, and why should I?).

Balance Fiction and Non-Fiction

At first, I started with reading only textbooks. It worked and I got quite good at it. But I find that reading with a balance of 50% fiction and 50% non-fiction split is much better for me.

I am typically able to read much faster since I have more things to look forward to when reading (since either book could be exciting). In addition, I treat reading fiction as a break. It helps my mind relax and let concepts refresh itself in my unconscious mind.

One thing to note is that the split of 50/50 fiction and non-fiction also depends on how difficult the fiction book is. If the fiction book were an old English classic, then it would be mentally straining to read, and I would even start to view it as a bit more of a non-fiction book in a sense (because of the mental energy it takes to read). So, one could think it’s less about fiction and non-fiction, but the difficulty of the reads, and the need to balance it to ensure better rest and comprehension.

Refreshing Your Mind

I find this tip to apply more to non-fiction books: ensure that you understand what you’ve read.

After a chapter, you should be able to summarize the chapter relatively succinctly. In addition, if anyone were to ask you any questions about the book or topic it was covering, would you be able to provide a detailed enough response?

The number of details you want to consider is up to you, if you are not satisfied, either reread the section or find another resource that explains the concepts better. Of course, don’t try to get hung up on every detail.

Keeping Yourself Motivated

Whilst reading something complex or large — for me, an example was “How Linux Works 3rd Edition” — it can be daunting with how many small details there are to cover. I mentioned skimming earlier, but sometimes one must just push through and read the details.

I have two methods for detailing with motivating on a heavy read:

The first is rewarding oneself. After having completed a chapter, you can do something exciting with the information you’ve read. Talk to someone else about what you’ve read or go online to talk about it. If it is a textbook with exercises, you can also do some practice. If it is a fiction book with a movie, think about watching it after reading the novel.

The second is a “purpose refresher”. What was the purpose of reading this book? Sometimes after so many chapters of a book, especially mundane ones, one easily forgets why they were reading in the first place. Rethink why you are reading the book and think about the skills or knowledge gained from finishing it. Before I read a book, I like to look at the table of contents and think about what I will do with all the new skills I will gain; it gives me the strength to finish through some hard chapters.

But, if this does not work, it leads to my next point

Don’t be Afraid to Drop a Book!

Sometimes a read is just not interesting, too heavy, or too complicated. That’s okay. You should not feel pressured to finish a book; it’s not a blood contract. Also, maybe you can finish in the future!

Conclusion

I hope I shared with you the beauty of reading and got you all hooked. Obviously, if you made it to the end of this article, you are already a capable reader. I hope the tips were still useful regardless!

Happy reading!

But this isn’t an article about how amazing Oxford, or the UK is, it’s about Oxford Brookes University and the University of Calgary.

I’m going to compare my experiences between my host university in Canada and Oxford Brookes University in the UK.

First off, I do want to mention that I was scared of the UK at first. I did have the idea that the Brits would be talking like Paddington Bear and be incomprehensible. Perhaps people would talk to me with such an accent that it would sound like a different language entirely. But I am very thankful that it didn’t turn out as I feared at all. Yes, there was slang here and there that I had to pick up, but 95% of the time, I understood the accents of the people in Oxford.

Culture

The biggest thing that shocked me, and that I now love, is the fact that there are two casual boozers on the university campus, the Brookes Bar and the Sports Bar. The pints go for a cheap price, at only £3.00. I love the fact that a university would support the drinking life, something that could only happen in Britain of course! I made some great mates in Oxford, and we would meet up at one of the pubs and drink — and you could hang out without drinking as well. At the University of Calgary, there are two bars: The Den, and The Last Defence Lounge. They are both great locations and are part of the SU and the Grad Students Association. However, they have more of a restaurant atmosphere, so they feel less like a casual hangout space (but there are more food options).

Furthermore, I find it a lot harder to convince mates in Calgary to come over to the pub. But, at Brookes, I found that people were always down to hangout at one. This is not just a Brookes thing, I know, everyone in the UK loves drinking. I’ve met some mates who would regularly go to spoons (Wetherspoons) for some cider and such, and it is a great way to have fun. In Canada, it’s much harder to find people who want to just hang out at a casual spot.

I found the relationship between the instructors and students much more relaxed. At Brookes, students would address the instructor usually by their first name. People would walk up to their instructors in classes and just have conversations with them. I recall a time a professor “joked” about pirating our textbooks since they are so pricy (for legal reasons I will not elaborate), something that would usually only happen between mates. At times, I would see some of my instructors at “The Forum” among students. There are even academic advisors who have regular meetings with you about grades, life and such. It’s very nice to have such a personalized experience. I had an amazing academic advisor who took me and a friend out to a pub and bought us drinks. Yes, you read that right Canadians. I couldn’t have imagined a world where an academic advisor would buy students drinks!

Meanwhile in Canada, there is a very heavy distinction between a professor’s professional and personal lives. Students usually address professors by their last name, and with a title too. Of course, students can also be mates with their professors, but usually this is a lot rarer. Mainly research students get close to their professors, since not only is it hard to talk to a professor, but classrooms can be upwards of 300 people. Standing out amongst the crowd is a bit tricky there.

Comparing academic advisors, U of C does provide a lot of academic support. Students book meetings online with a select group of advisors, with the chance of speaking to a new person each time. I find that it is hard to keep track of all the services that U of C provides. Of course, academic advising is a lot more complex in Canada due to the more flexible degree programmes.

So, in terms of culture, I think hanging out at the pub makes everything more fun, and its easy to be friends with instructors and advisors.

Student Life

I think this is a very difficult section to touch because Oxford is just a beautiful and dense city, while Calgary is a bit more on the bland, suburban side. But I digress…

The Oxford Brookes Students’ Union holds a generous number of events. There was an ABBA Bingo event, Cricket at Sixes’ Cricket Club, and Darts at Flight Club. I found these events to be great and well worth the small fees of ~£5. Personally, I do wish that they held more events like these, but at least they were of very high quality.

I found the students societies (called clubs in Canada) to be a bit lackluster at Brookes. There weren’t as many societies hosting frequent events. One time, the Jazz and Christian society collaborated on a wine and cheese night. The cheese provided was quite nice. But, as I am in Computer Science, I really wished there was a computing society, and just more club events in general. At least “The Guild” had regular board game meetings that I heard were very nice. In addition, Brookes International Student Advice team had very cool events. I would buy some tickets for day trips to nearby locations, such as Stratford, Cardiff, and Cambridge. It was very kind of them to organize those trips.

In Canada, I would say that the university and students’ union do not provide many fun activities. Just looking at the website, I see a bunch of stuff regarding academic advising: https://events.ucalgary.ca. It’s just not very exciting stuff:

But, while these events are boring, we have many clubs (reminder that clubs = societies). https://suuofc.campuslabs.ca/engage/organizations. Our listing of clubs reaches 290. There are over 7 clubs related to computer science alone. Despite all these clubs, it can be hard to find events posted by the clubs since they all use their Instagram for marketing, and there is no centralised location for searching for events.

Classes

In a nutshell, Brookes focuses more on the practical hands-on aspect of software development. The classes I took were Secure Programming, Malware Analysis, Foundations of Security, and Introduction to C and C++. My favourite of them being malware and secure programming. Each class tried to focus on practical problems that occur or occurred in the real world. To reinforce our learning, there would be a practical session which went over example problems such as performing a buffer overflow attack, arc injection, or using Wireshark. These practicals would usually be led by the instructor. Whilst in Calgary, we would have Teaching Assistants (hired students) to instruct these practicals. Doing the Brookes practicals with Ian Bayley (a quiz celebrity featured on Mastermind and other British shows), was quite educational and fun. On the other hand, some of these practicals were less interesting (Brookes students can take a guess which class that was).

At University of Calgary, I feel that we touch more on the fundamentals of computing. We do subjects like Theory of Computing, Algorithms, Programming Paradigms, and such. Now, I do enjoy these classes quite a lot. But the practicality of these courses are far less obvious than something as direct as Malware Analysis. I’ve heard great things about the Networking course at Brookes, which involves physical subnets and routers. At University of Calgary, the equivalent course mainly has a textbook where we read about the underlying protocols without having touching a real network.

I find a balance between the practical and foundational knowledge of software important, and I think that the University of Calgary has a bit to learn about doing more hands-on classes. But it’s not useful to compare the two universities since they are focused on different outcomes: one to get practical experience, the other to prepare you to be a computer scientist.

I did find the workload at Brookes to be laxer. There was typically only a maximum of two assignments per course, and a final exam which was worth a good chunk of your grade, perhaps 50%. These assignments were not too tricky but usually took a good amount of time, focused on making students do a project. Compared to Calgary, we have many assignments to do, perhaps 1–3 a month per course. These assignments would range from projects to making toy programs. The latter being much more common.

But an important thing to consider is that an A+ at Brookes is 75%. Despite this, I found the coursework to be graded quite leniently, and it’s quite uncommon to fail a course from what I’ve seen. At Calgary, it is course dependent, but the minimum for an A+ is typically 95%.

My favorite part of classes at Brookes is that there are “presentations” you do to your grader. These are not real presentations in a sense, but questions to ensure that the work you did is your own and that you actually knew what you were doing. Most my classes required a meeting where I discussed my work and the thought process behind it. I see the merit behind it, to catch cheaters and such.

I think that UCalgary has a bit to learn when it comes to catching cheaters. Since our coursework is most of our grade, some students get by through cheating on assignments despite bombing tests.

At UCalgary, it felt like courses and grades were less standardised. Sometimes, I would have to contest grades. But I think it could have been that I’ve been at UCalgary for much longer than I was at Brookes.

On the side of Brookes, I do think that there is a bit too much time dedicated to assignments. There would be a week of class dedicated to the assignment, questions for the assignment, and another week with no classes to work on these assignments. But, honestly, it’s quite nice to have so much free time to do whatever I want.

Campus

The campus at Brookes is much smaller than UCalgary. But it gives off a very cozy feeling. I enjoy how there are always changes to the front desk. When I was there, there were some Lego builds of different landmarks. I found it very cute.

On the outside, I quite liked the metal structure that looked like upside-down umbrellas. At night, it would light up and look very aesthetic. Not to mention, the CO-OP store on campus is very nice. Many students would get their lunch meal deals from there. Buying a CO-OP membership is a must, since it is only £1 and you can get £1 off your shop almost weekly.

My favorite location on campus was “The Deli.” The lunches would be quite cheap: £5.50 and very filling. The meals would rotate every day. My personal favorites would be the Christmas turkey dinner with stuffing and mash. There was also a delicious Yorkshire pudding wrap, the best I’ve had in the UK.

I very much enjoy Calgary’s campus as well. There are many different services provided by the University. Since there are so many things here on campus, I will just list them:

• A campus food hub that has cheap groceries, and soups on Wednesday for $2.00.
• A food court for students called MacHall. It is filled with restaurants.
• Free tea and fruit provided by the Life Design Hub
• 13 public squash courts.
• The Den (mentioned before) has a subsided meal for only $3.

Student Accommodations

At Brookes, I was living in Clive Booth with some amazing mates. Though, I have heard some horror stories about flatmates who would never clean the kitchen 💀. First off, my favorite thing about the residence is the kettle. It boils so fast! Okay, moving on, that had nothing to do with Brookes. I found the Brookes campus services to be very swift and effective. Whenever we filed in a problem about our residence, they would come within a few days and fix it. Honestly, residence was quite standard. I think the only problem we faced was freezer space being limited since students live off frozen food. But everyone had ample storage space, with 2 cupboards per person.

In addition, sometimes there would be loud English banter outside. Whenever it was noisy past 11pm and we called campus services, they were very swift to stop the sound. It would take 10–15 minutes for them to address the sound, which is quite quick compared to CA response times at UCalgary.

Basically, I’m very thankful that Brookes has provided us a swift and efficient service. I have heard mixed experiences from other people, so it’s hard to give an objective conclusion.

City Life

As a nice bonus section, let’s turn to the city aspect. Let me quickly talk about Calgary:

• There is a nice big public library called Central Library
• A music museum called Studio Bell
• A lot of parks to walk around, the biggest being Nose Hill Park
• Nice communities with shops like Inglewood and Kensington
• Theatres and auditoriums, though usually quite expensive to attend
• Calgary Stampede (the biggest in the world!)
• A lot of big malls

Okay, now I’m going to talk about Oxford:

• Norrington room at Blackwells. Best place to read and indulge yourself!
• Oxford theatres. There are a lot of shows and musicals to watch at a low price. I loved New Oxford Theatre and Oxford Playhouse
• Completely Free Museums, my favourites being: Pitt Rivers and the Ashmolean.
• Covered Market: love all the food there
• Free and very festive Christmas markets
• Visiting the Oxford Colleges and Bodleian Library
• Westgate Mall (much smaller than Calgary malls, but it looks nice)
• Pigeons

Recap

Basically, hanging out at pubs makes life more fun, Brookes’ courses are more hands-on, and there’s more opportunities for direct and friendly interactions with instructors in the UK.

I really enjoyed my time there and will cherish it forever ❤️.

Come over to visit UCalgary too if you have the chance, it may be studious, but it is quite beautiful! And, we have quite a large campus for you to explore!

Links

If you want to see my full technical report, it is visible here: Full Technical Report

The notebook file can be seen here: Google Colab Notebook File

Introduction

In this project, I utilized a dataset from Kaggle, the Medium Articles Dataset 📝, which spans from January 2023 to March 2023, containing 2498 articles. I dissected various features of article titles and determined which feature lead to better user interest, which was measured by claps.

Title Focus and Topic

The genre of what you are talking about seems to make the largest difference in the user interest. Utlizing BERTopic, it was determined the best performing topic was those that were focused on finance, passive income, and such. Articles in that category would score with an average of 1653 claps. Some examples of those titles are as follows:

5–9 years of obsession will save you 5 decades of working a 9–5.

I quit my 6-figure job once I learned 5 unpopular things.

In addition to this, I charted words with their average clap, to find the most important words in article titles.

We can see that notable words that show up are: “$350”, “$0”, “passive”, “luxury”, “employable”, and such. This shows that the kind of articles that garner the most claps from users are those of lifestyle, personal finance, and income.

To further support this, having a “$” dollar sign in the article title shows an average difference of claps of 802.17.

So, if it is your cup of tea, try to make your articles more garnered towards finance and income, or add a dollar sign. Of course, sometimes this is not possible and could be considered a little scummy if that’s not what you want to write about. We will move on to the more pleasant features now.

Article Length

A good article length would be within a unit of standard deviation. Hence, the best character length for an article title would be between the range of 36–73 characters.

The ideal number of words in a title would be between the range of 6–12 words.

However, keep in mind that there is not a very high Pearson correlation (correlation in general) between the article claps and the length of an article title, hence it is not worth worrying about the article title length. You can still have a smash-hit article with a very short length.

Reading Ease

This feature seemed to matter an extremely large amount. Reading ease was calculated with the Flesch reading ease score, which measures the school reading level of the given text. It is calculated with the following formula:

206.835–1.015 x (total words / total sentences) — 84.6 x (total syllables / total words)

The formula aims to find how complex your words are based on the syllable usage in your sentences and words.

I graphed the correlation between reading ease and claps, which can be seen below:

Those with a lower school reading level correlated to much higher clapped articles. The correlation between reading ease and claps is linear and has the second highest Pearson correlation.

The best reading level for articles seemed to be 5th grade. So, unless your writing style is very articulate, try to avoid using too many complex words and keep things simple in your article titles.

Number of Numerals

If possible, try to use numeral forms instead of the number word, for example: “2”, instead of “two”. The number of numerals in an article title shows another strong correlation to claps.

Number of numerals has the highest Pearson correlation to claps, at 0.23. So, the number of numerals you add do represent better claps. I would suggest that you try to aim for at least 5 numbers in your title.

Parts of Speech

Article titles that contain easier to read language and morphology will perform better as Medium articles. It is seen that with an increase of nouns, there is a decrease of claps. This makes sense as too many topics in a title can be confusing and lead to a more convoluted article.

Try to keep the focus of your title clear and easy to comprehend. You can do this by not having too many verbs or nouns going on, make the focus of your article titles crystal clear.

Best Phrases

I found the most important phrases of length 2, 3 and 4 words long. There isn’t too much to say here, so I will just show the plots:

As you can see, a lot of the phrases are very specific to finance and such, in addition, it is susceptible to outliers in the dataset.

Issues

To test the correlation between features and the importance of certain features, I trained a random forest regressor model. However, it did not perform very well, with a very low R-Squared Error: -0.034. The likely reasoning for this is that there is little to no correlation between article titles and claps.

There are various external factors that influence the number of claps on an article. For example, having a publication can drastically alter the number of claps received.

Furthermore, being a famous writer on Medium will grant you a larger audience of people, and a higher chance to get claps despite how poorly written your title could be.

In addition, this database was quite small, with only 2498 rows. Perhaps with more data, we can better understand what the Medium platform’s trends are.

In essence, sometimes, the title of your Medium article doesn’t really matter all that much in the end. If you wanted to reach out to a greater audience, or get more claps, you should look into a publication or marketing.

Summary

Try to keep your articles in the range of 36–73 characters or 6–12 words. Make the article title as easy to read as possible, ideally 5th grade level (even a 5th grade student can read it). Try to use numeral numbers instead of the word form whenever possible (“1” instead of “one”). Keep the number of nouns low, so that the article title is coherent. If you can, maybe use one of the phrases from the graphs above, only if it suits your article already, however. Finally, remember that article titles don’t always mean more user retention, sometimes it’s just a game of luck and marketing.

Thanks for reading and let me know what you think in the comments below, and clap the article if it was helpful!