
Time in the day is constant, but as your career grows, so should your impact. You can scale your impact while managing your time commitment by learning how to automate your influence on and across projects.

## Testing

Nearly everyone agrees that testing your software is good, but it’s essential to see a project’s test suite in the context of the big picture.

Why do we write tests? Well, manually testing everything is tedious and time-consuming. So, we automate some of these checks in unit, integration, and end-to-end tests.

When we have a test suite, we can quickly get a quality measure on the codebase. Does this change break existing functionality? Do things look okay after updating my dependencies?

What does this have to do with your influence? As you become more senior, your responsibility for a project or team will grow. If you’re a lead, then the buck stops with you. Spending all your time manually testing the project’s quality will prevent you from contributing to other areas. Also, as the project grows more complex, you won’t have enough time in the day to check everything.

<Aside>
  [Property testing](https://en.wikipedia.org/wiki/Property_testing) is
  unfortunately underutilized in the industry. I like to think of it as
  second-level automation. It helps automate your tests, which are automating
  various checks.
</Aside>

There’s limited time in the day, so you’ll need to prioritize testing things that will have the most impact on the product, given its current state. But once you’ve invested in a sufficient testing suite, it will help you scale. It will also free up your future time to work on other initiatives.

## Static analysis

A codebase’s quality depends on more than just producing the correct outputs given specific inputs. If the code is hard to change, then its utility diminishes. As your career grows, you’ll need to concern yourself more with the code quality and its effect on the product.

Static analysis can detect quality issues with code, and depending on the tools you use, it can even automatically fix common problems.

Again, as we said above, there’s limited time in the day, and spending your time manually checking code for specific problems is not the best use of your time. Investing in a linting suite will help the team catch problems early and enforce standards.

With a linting suite, you’ll influence the codebase for much longer than the initial time investment it takes to craft the suite.

There are numerous different linters, and like tests, you’ll need to prioritize which are best for your particular project. [Type checkers are one of my favorites](/blog/mypy-tips-and-tricks), and luckily their use is growing within the industry.

But some specific lints or linters will cause more harm than good, so continually evaluate their effectiveness and don’t be afraid to iterate.

## Tooling

Tooling is a more general version of the previous sections, but it’s important to mention. Tools shape culture, and you can help shape the team’s culture by advocating for and building quality tools.

People gravitate towards the easier thing to do, so you can guide this with the tools you help craft.

Tooling is vital because tooling decisions are often sticky, and they become integral parts of our workflow. Tools even influence the way we think about problems.

Like above, there’s a balance in prioritizing what tools to invest in or what even needs tooling.

Tooling work also allows escaping from a [local maximum](https://en.wikipedia.org/wiki/Hill_climbing#Local_maxima) since tools often entrench past decisions. Iterative improvements within the current system are essential, but you risk missing the forest for the trees. The chances of arriving at a global maximum with only iterative improvements on the status quo are slim.

Part of your mandate as an organizational leader is to improve the status quo. Therefore, updates to foundational tools and processes may be important—or even required—to move the needle.

## Documentation

The [curse of knowledge](https://en.wikipedia.org/wiki/Curse_of_knowledge) is real, and documentation is a critical component in counteracting it.

When you work on a project, you’ll gain a lot of “folk” knowledge about it. This knowledge presents a risk because if it’s only in your head, then you’ll need to be present in conversations for others to learn and benefit.

Once again, there’s not enough time in the day for you to be in every conversation, so we must turn to documentation to scale your influence. Walking someone through an aspect of the project is quicker than writing a detailed document, but the document will persist. It’ll continue being a valuable reference for as long as it tracks reality.

The same applies to your product’s users, who will have even less context. Quality documentation can resolve problems before they bubble up to you, while insufficient documentation can prevent market uptake of your product. If your documentation addresses 80–90% of common issues, you can spend your time on other impactful work.

<PostImage
  src="/assets/blog/automate-your-influence/water-ripple.jpg"
  alt="Picture of a drip of water causing ripples in a larger body of water"
  aspectRatio={2.18}
  citationText="Photo by Linus Nyland"
  citationLink="https://unsplash.com/photos/Q5QspluNZmM"
/>

Testing, static analysis, tooling, and documentation are all things you can use to automate and scale your influence. They will continue to impact your projects long after the initial time investment. And if they’re of sufficient quality, you’ll have more time to pursue other initiatives and further scale your impact.



When people first hear about my double major, they are usually surprised as computer science and philosophy seem like two completely different fields. While they have many differences, they both share many similarities, and I have found that they complement each other tremendously.

First, a crucial aspect of both domains is taking a big problem or topic (like designing an application or arguing in support of utilitarianism) and breaking it down into small, manageable parts. It helps to enforce this skill by applying it to two distinct problem spaces.

For example, when you are designing an application, you can divide it into the initial design, implementing the design, testing and assessing the implementation, then finally revising your implementation. You then further divide each part, where you'll end up with manageable pieces to tackle.

If you are writing a paper in support of utilitarianism, then a possible division of parts would be introducing different ethical systems, presenting your argument in support of utilitarianism, providing thought experiences and evidence to support your argument, and finally considering and rebutting counterarguments.

This is an important skill to have for just about anything in life, and it is a great help to have experience practicing this skill on two separate problem spaces.

Second, logic is fundamental to both fields. Logic has been called the calculus of computer science since it plays the same role in CS as calculus plays in physical sciences. Having a solid grasp of the basics of logic will make your experience with CS much easier.

Arguments are central to philosophy, and understanding the basics of logic is key to understanding and assessing philosophical arguments. Furthermore, a solid grasp of logic will help you when formulating your own arguments and thought experiments.

Third, studying philosophy and more specifically ethics gives you the tools and perspective to better consider how the technology that you and others in your field will impact society. Computers are an ever increasing part of our lives, and the importance of considering the ethics and the effect of them cannot be understated.

Tech companies are starting to hire people from philosophical backgrounds to consider the risks and ethical issues that could arise from the use of their products. Studying both computer science and philosophy puts you in a unique position to not only understand the product itself but to also understand the bigger picture around the product.

In short, studying computer science and philosophy is a great combination and both complement each other well. I recommend anyone in either field to take a few classes in the other subject. It will benefit you greatly, and the demand for people with experience in both fields will only go up.



Inspired by [Wesley Aptekar-Cassels’ post](https://blog.wesleyac.com/posts/engineering-beliefs) (which was inspired by [this](https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d14e2b)), here are some of my hot takes on software engineering.

- The crux of software engineering is minimizing complexity
- Luck has a more significant role in conventional success than many of us think
- A system that depends on infallible humans is anything but
- As a whole, the industry is too tolerant of bugs and inefficiencies
- Considerably more software is mission-critical than we realize
- The industry heavily incentivizes local maxima
- We don’t expect nearly enough from our tools
- Dynamic typing hurts developer velocity on day one
- The machine learning industry’s dependence on Python holds it back and ultimately makes us less safe
- Taylor Swift is the optimal ambient music for coding



I believe there is potential in creating a central website that will showcase locally-owned cabins in the Red River Gorge area in Kentucky.

The [Red River Gorge](https://en.wikipedia.org/wiki/Red_River_Gorge) area is a fairly popular tourist destination in southeastern Kentucky. It features hiking, camping, and world-class rock climbing, bringing thousands of people into the area every year. Tourists stay in a number of cabins in the area, providing a much-needed economic boost to the struggling communities.

Unfortunately, history is repeating itself. The region's resources are not going to locals, at least not to the extent that they could be. The industry is dominated by multiple cabin rental agencies owned by people who are not from or do not live in the area. These agencies charge anywhere from 28–50% of the booking price as commission to just place the cabins on their website.

This is fine for people who are not invested in the area and just have a cabin built for a passive income. For local owners who are invested and rely on their cabin(s) for their main source of income, this is unacceptable.

50% is an enormous price to pay to just have your cabin listed on a website, especially when you are _still_ responsible for the building and maintenance of the cabin. On top of this, the cabin owners are forced to absorb nearly all the damages caused by the guests. This is because the agencies do not want to charge their customers for the damages they cause, since this increases the chances of a negative review (and it was not the agencies' property that was damaged). Also, local owners' cabins are placed at the bottom of the list, as the rental agencies will only direct people to these cabins after the agencies' cabins are booked.

I witnessed firsthand all the troubles my parents and other local owners went through while in this situation. It was not pleasant, and it isn't fair.

Websites such as [Homeaway](https://www.homeaway.com) and [Flipkey](https://www.flipkey.com) offer similar services while charging reasonable commissions. They can serve as reasonable alternatives if a cabin owner does not want their own website. Still, there is no replacement to having your own website, and many local cabin owners prefer to handle bookings through their website whenever possible.

Ideally, a central website would showcase pictures and amenities for all the locally-owned cabins in the region. It would link tourists to either the cabin owners' websites or their contact information. It would be easier to get locals to approve having their cabins on the website if the website was completely free for them. After the upfront development cost, the maintenance of this website should be able to be supported by ads.

Of course, there is no reason why this website could not be expanded to include other regions. I only suggest the Red River Gorge region as it is the region I have experience with.

This website would also provide benefits to tourists. In general, renting from cabins where the owner is actively involved and invested in the cabin will provide the tourist a cleaner cabin and a better rental experience. Tourists can also expect to pay a lower price for the quality of product they are receiving as the middleman is cut out. Furthermore, tourists will know the maximum amount of their money is staying within and helping the local economy.

During the summer after my freshman year of college, I tried to create this website. I bought the cabinsdirect.org domain name and created a website on the bootstrap framework. This website allowed you to easily add, edit, and remove cabins. It also allowed the user to filter the various cabins by what amenities they wanted.

The source code of the website is available on my [Github page](https://github.com/justinaustin/cabins-direct).

I was able to add my parents' cabins to the website, but I did not receive any responses when I first reached out to local cabin owners in the area. With my move back to Philadelphia close by, I decided not to pursue it anymore. I eventually took down the website.

I unfortunately do not have enough time as of now to pursue this project. However, I still believe it has a lot of potential. I will gladly help anyone who wants to revive this project in any way that I can.

While this is probably not the next big thing or a massive money-making venture, it will definitely provide valuable experience and has the potential to help a few struggling communities.

If you are interested or have any questions, please don't hesitate to contact me by email at <Email />.

_Disclaimer: My parents own a cabin rental business in the Red River Gorge area._



[Technology Education And Literacy in Schools](https://www.tealsk12.org/) (TEALS) is a program started by a Microsoft employee to address the lack of computer science courses in high schools. The program matches software engineers in the industry to high schools without CS courses. The engineers teach the courses (Intro to Computer Science or AP Computer Science) at first, then the local classroom teacher gradually takes over. The goal is for the school to have a self-perpetuating computer science program within two or three years.

Beattyville is a small town of around 1250 in Southeastern Kentucky. Dubbed '[America's Poorest White Town](https://www.theguardian.com/us-news/2015/nov/12/beattyville-kentucky-and-americas-poorest-towns)', Beattyville has had its fair share of economic trouble and not so fair share of resources. Lee County High School, the only one in the county, is unable to provide the same opportunities as other schools, but students and faculty make do with what they have. So, it should come as no surprise that LCHS did not offer a computer science course.

Through a stroke of luck, a Microsoft employee and volunteer within TEALS met our school board president while rock climbing in [Red River Gorge](https://en.wikipedia.org/wiki/Red_River_Gorge). TEALS was looking for a pilot school for remote teaching, and our high school was grateful for the opportunity. The next school year, my junior year, an Introduction to Computer Science course was taught at our school via Skype. Unfortunately, the dream come true had a setback, as I was unable to enroll due to scheduling conflicts with a required math course.

Within the first few weeks of school, the software engineers had flown to our school in order to meet with the students in person. They also hosted a presentation for any interested students. I was certain not to miss it. After the presentation, they stayed back to answer any lingering questions. I met with one and explained my situation and interest. He introduced me to websites with free computer science courses like [Udacity](https://www.udacity.com/) and [Coursera](https://www.coursera.org/). I had no idea these existed. Over the school year, I enrolled in and completed Udacity's Intro to Computer Science course. It was an amazing experience, and I highly recommend it to anyone interested in CS.

Around halfway through the school year, there was a rumor that they were expanding TEALS at our school to include AP Computer Science next year. My friends and I anxiously waited to learn if the rumor was true. Near the end of the school, it was confirmed. I (unsuccessfully) tried not to be too excited, as I did not want to be disappointed again with another scheduling conflict.

When I learned the schedules for my senior year, I found out that AP Calculus was at the same time as AP Computer Science. I was heartbroken. The heartbreak was short-lived though, as our upper level math teacher offered to teach me Calc during his planning period. I was (and still am) extremely grateful for this, as it allowed me to take both classes.

Our AP Computer Science course had 7 students including me. Our two teachers were software engineers based in NYC, and they taught the course via Skype everyday around 9:30 am. The course taught the [Java](<https://en.wikipedia.org/wiki/Java_(programming_language)>) programming language and included creating a calculator program, a spreadsheet program similar to [VisiCalc](https://en.wikipedia.org/wiki/VisiCalc), and modifying [GridWorld](http://apcentral.collegeboard.com/apc/public/courses/teachers_corner/151155.html).

The highlight of the course was a trip to Seattle, WA. Microsoft was gracious enough to fly our class out for 4 days. While there, we toured the city, saw the beach, and visited the offices of Facebook, Google, and (of course) Microsoft. I cannot describe how amazing this trip was. It was my first (and only) time I have been west of the Mississippi. It allowed us to see and experience the world outside of our small town. Most importantly, though, it made everything seem real and reachable. Afterwards I knew that I wanted to pursue computer science in college.

Our college choices in high school were usually limited to colleges in Kentucky. It's not that we were actively discouraged from applying to top tier schools out of state, it was just never really presented as an option. When one of our teachers found out about my college preferences, he offered to help me with my application. Having went to Cornell, he was intimately familiar with the process. His help was invaluable, as our school's experience with helping students with the Common App was severely lacking.

College admission decisions were released near the end of March. Anyone who has went through this process will know how nervous I was waiting for the results. I found out I was accepted into the Engineering School at the University of Pennsylvania, and I was ecstatic. It was the culmination of all of my hard work, and I know it would not have been possible without my teacher and TEALS.

The benefits of TEALS did not stop after my first day of college. I was learning with and competing with students who went to the top high schools around the world and had excellent resources. I definitely felt I was at a disadvantage in some of my courses. I never felt disadvantaged in my computer science courses. In fact, I had just as good if not a better background than my peers, a testament to the world class computer science education I received through TEALS.

During my sophomore year of college, I was invited to a Microsoft hosted dinner at the [Clinton Global Initiative](https://www.clintonfoundation.org/clinton-global-initiative/meetings/annual-meetings/2015/speakers) in NYC. It was another amazing experience, and I was able to share the impact the TEALS program had on me. I was also able to reconnect with my teachers and meet some amazing people.

In summary, TEALS is great. The program changed my life, and I wouldn't be where I am today without it. If anyone has the chance to participate in this program, I highly recommend it.



Immutable variables are supported by many languages, with some going even further by having immutability by default. Python is unfortunately not one of those languages. Still yet, we can leverage type hints and [mypy](http://mypy-lang.org/) to gain some of the benefits of immutability!

## Why do we even want immutability?

First off, why do we even want to have immutability? Especially in a language like Python where achieving an acceptable level of immutability is nontrivial?

Immutability makes our programs easier to reason about. It helps us reduce the realm of possibility, and it can provide some assurances to our data. Knowing that a variable is immutable gives us one less thing to worry about, and lessening our worries is always welcome!

While these benefits are particularly pronounced when dealing with multithreaded code (e.g. by helping to prevent [data races](https://en.wikipedia.org/wiki/Race_condition#Data_race)), single-threaded code can also benefit greatly. Immutability helps prevent accidental modification to our data. If we have mutable state that we accidentally modify, then at best our program will fail with a sufficiently informative error message, allowing us to quickly identify and fix the bug.

Unfortunately, another likely outcome is that our state will become silently corrupted, causing seemingly unrelated bugs in our program. These bugs are hard to identify and frustrating to deal with. They also have the potential to become catastrophic, especially if the accidental corruption causes the state to violate invariants that other parts of our code expect to be upheld.

In contrast, accidental modifications to immutable state fail with either of the following:

- A straightforward error message at runtime:

```text
$ python test.py
Traceback (most recent call last):
  File "test.py", line 9, in <module>
    state.x = 2
  File "<string>", line 4, in __setattr__
dataclasses.FrozenInstanceError: cannot assign to field 'x'
```

- Or, even better, with an error message at “compile time” from either your compiler or static analysis tool (like mypy):

```text
$ mypy test.py
test.py:9: error: Property "x" defined in "State" is read-only
Found 1 error in 1 file (checked 1 source file)
```

## Applying this to Python

While Python does not have built-in language support for general immutability, we can leverage type hints from the [`typing`](https://docs.python.org/3/library/typing.html) module to get us some of the way there.

To start, let's look at two type hints that are frequently used in Python code: [`List`](https://docs.python.org/3/library/typing.html#typing.List) and [`Dict`](https://docs.python.org/3/library/typing.html#typing.Dict). Both `List` and `Dict` declare methods that support mutation, like `append` and `__setitem__`. So, mypy reports no errors with the following:

```python
from typing import Dict, List

l: List[int] = [1, 2, 3]
d: Dict[int, str] = {1: "Hello, world!"}

l.append(4)
d[0] = "Hi!"
```

```text
$ mypy test.py
Success: no issues found in 1 source file
```

Great! This meets our expectations. We can freely mutate lists and dictionaries within Python, and the analogous type hints declare all of the appropriate methods to support this.

Now, what if we want to have an immutable list or immutable dictionary. Unfortunately, Python does not have a `frozenset` alternative for lists or [dicts](https://www.python.org/dev/peps/pep-0416/). We can instead reach into the `typing` module for "immutable" versions, namely [`Sequence`](https://docs.python.org/3/library/typing.html#typing.Sequence) and [`Mapping`](https://docs.python.org/3/library/typing.html#typing.Mapping) respectively.

Calling `Sequence` and `Mapping` “immutable” may be slightly off. They do not enforce immutability; instead, they just do not declare methods that can mutate the object.

Here's an example of what I mean:

```python
from typing import Mapping

d: Mapping[str, bool] = {"a": True, "b": False}

d["c"] = False
```

With the corresponding mypy output:

```text
$ mypy test.py
test.py:7: error: Unsupported target for indexed assignment ("Mapping[str, bool]")
Found 1 error in 1 file (checked 1 source file)
```

`Mapping` does not declare `__setitem__`, which is implicitly called with the `d["c"] = False` syntax, and this causes mypy to report an error. We've used type hints and mypy to catch unintentional mutation without having to run our code!

Looking at the Python standard library [documentation](https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes) for collections abstract base classes, we can see that `Mapping` also does not declare `__delitem__` either. We can quickly verify that `Mapping` + mypy catches when we try to delete items:

```python
from typing import Mapping

d: Mapping[str, bool] = {"a": True, "b": False}

del d["a"]
```

```text
$ mypy test.py
test.py:7: error: "Mapping[str, bool]" has no attribute "__delitem__"; maybe "__getitem__"?
Found 1 error in 1 file (checked 1 source file)
```

Yay!

`Sequence` + mypy provides us the same benefits for lists, as `Sequence` also does not declare `__setitem__` or `__delitem__`:

```python
from typing import Sequence

l: Sequence[int] = [1, 2, 3]

l[0] = -1
del l[2]
```

```text
$ mypy test.py
test.py:7: error: Unsupported target for indexed assignment ("Sequence[int]")
test.py:8: error: "Sequence[int]" has no attribute "__delitem__"; maybe "__getitem__"?
Found 2 errors in 1 file (checked 1 source file)
```

## Frozen dataclasses

I think [dataclasses](https://docs.python.org/3/library/dataclasses.html) deserve a special mention here. I _love_ dataclasses. They're one of my favorite parts of Python. They can provide so many benefits to your codebase, most of which are out of the scope of this post.

One of their benefits, though, is the fact that you can declare your dataclasses to be "frozen", like so:

```python
from dataclasses import dataclass


@dataclass(frozen=True)
class State:
    x: int
```

Modifying attributes of an instance of a frozen dataclass will fail at runtime with a `FrozenInstanceError`:

```python
state = State(1)
state.x = 2
```

```text
$ python test.py
Traceback (most recent call last):
  File "test.py", line 10, in <module>
    state.x = 2
  File "<string>", line 4, in __setattr__
dataclasses.FrozenInstanceError: cannot assign to field 'x'
```

And if that wasn't exciting enough, mypy is smart enough to understand that dataclasses can be frozen, and will report an error with the above code:

```text
$ mypy test.py
test.py:10: error: Property "x" defined in "State" is read-only
Found 1 error in 1 file (checked 1 source file)
```

`frozen=True` also gives some nice benefits beyond this, like automatically adding a `__hash__` implementation provided that `eq=True` (which is the default).

While it would have been nicer for `frozen=True` to be the default, dataclasses still provide an elegant way of grouping related data in your program, akin to structs in other languages. They save a lot of boilerplate, and they provide a nice foundation for other great libraries like [dataclasses-json](https://pypi.org/project/dataclasses-json/).

## Of course, this is still Python

Unfortunately, [you can't create truly immutable objects in Python.](https://www.python.org/dev/peps/pep-0557/#frozen-instances) The Python interpreter ignores type hints when running your code, so the following will work:

```python
from typing import Sequence

x: Sequence[int] = [1, 2]
x.append(3)
assert x == [1, 2, 3]
```

mypy will flag an error here, but Python will happily run this because as far as Python is concerned, `type(x) == <class 'list'>`. The same is true with `Mapping`:

```python
from typing import Mapping

x: Mapping[str, int] = {"a": 1}
x["b"] = 2
assert x == {"a": 1, "b": 2}
```

Even our beloved frozen dataclasses can be mutated, albeit with slightly arcane syntax:

```python
from dataclasses import dataclass


@dataclass(frozen=True)
class State:
    x: int


state = State(1)
object.__setattr__(state, "x", 2)
assert state.x == 2
```

_(Please don't do this.)_

## But let's remember our "threat model"

We're not pursuing immutability to prevent all cases of our state being modified. This is Python; if someone wants to mutate something they will succeed.

We're pursuing immutability to help reduce bugs in our code and catch developer mistakes. The risk of a developer accidentally modifying state using `object.__setattr__` is very low compared to a developer accidentally modifying state via `state.x = 2` or `foo(state.x)`.

While Python gives us some tools for this, they are not on by default. Therefore, we need to be conscious of them while developing, ideally making them a habit.

As the above illustrates, this is not as good as languages like Rust or Haskell where you need to opt-in to mutability. Another thing to watch out for is that mypy's type inference defaults to the mutable versions of types. We can see this by using the [`reveal_type()` mypy builtin:](https://mypy.readthedocs.io/en/stable/common_issues.html#reveal-type)

```python
x = [1, 2, 3]
reveal_type(x)

y = {"hi": 1}
reveal_type(y)

z = {True, False}
reveal_type(z)
```

```text
$ mypy test.py
test.py:5: note: Revealed type is 'builtins.list[builtins.int*]'
test.py:8: note: Revealed type is 'builtins.dict[builtins.str*, builtins.int*]'
test.py:11: note: Revealed type is 'builtins.set[builtins.bool*]'
```

I try and simulate immutability by default in Python by always defaulting to `Sequence` and `Mapping` in my method signatures and variables instead of `List` and `Dict`. Also, I try to always include `frozen=True` to any dataclasses I create, unless I for sure need mutability (and [`dataclasses.replace()`](https://docs.python.org/3/library/dataclasses.html#dataclasses.replace) isn't sufficient).

So, mimicking immutability in Python unfortunately has to be a sustained effort while you are developing. But I believe the long term benefits to your project outweigh this initial investment.



Here's a collection of various tips and tricks for [mypy](http://mypy-lang.org/), a static type checker for Python. Some are more opinionated than others, but they all will help you leverage mypy to its full potential.

## Use a type checker

First off, if you're using type hints in your code, I _highly_ recommend you type check them with a tool like mypy. The only thing worse than unannotated code is incorrectly annotated code.

If you're using mypy, I like the following `mypy.ini` for my config:

```ini
[mypy]
disallow_any_generics = true
disallow_incomplete_defs = true
disallow_untyped_calls = true
disallow_untyped_decorators = true
disallow_untyped_defs = true
follow_imports = normal
ignore_missing_imports = true
no_implicit_reexport = true
show_error_codes = true
show_error_context = true
strict_equality = true
strict_optional = true
warn_redundant_casts = true
warn_return_any = true
warn_unused_ignores = true
```

The rest of this post touches on most of these flags and the idea behind them.

## Enable None checking

Help mypy catch the [billion-dollar mistake](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/) and enable `None` checking with the `--strict-optional` flag. Luckily, this is the default in mypy starting from version `0.600`.

With this flag, mypy would disallow the following code:

```python
def foo(x: int) -> None:
    ...

foo(None)  # None is not of type 'int`
```

I also recommend setting the `--no-implicit-optional` flag, which disallows code like the following:

```python
# wouldn't pass with the flag
def foo(x: str = None) -> str:
    ...

# but would with an explicit Optional annotation
def foo(x: Optional[str] = None) -> str:
    ...
```

In general, being explicit is better than being implicit. This is especially true as the codebase grows older and the number of developers touching it increases&mdash;i.e., [programming in the large](https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small). The time it would take to fix any future bugs caused by an implicit optional would dwarf the few extra seconds it takes to be explicit when first writing the code.

Remember, code is read more often than it is written, and it is run more often than it is read.

## Beware of “Any” types, especially silent ones

Mypy will pass any type checks that contain an [`Any` type](https://docs.python.org/3/library/typing.html#the-any-type). `Any` is a helpful escape hatch when retrofitting type hints onto an existing codebase. Unfortunately, it can also jeopardize the type safety of your program if it appears in places you aren't aware of.

Silent `Any` types can appear when using types from your dependencies if you have not configured mypy to follow imports. For example, if you import a method from a third-party dependency, then mypy will treat values returned from that method as `Any`:

```python
from dep import foo  # dep is a third-party dependency

def bar(s: str) -> int:
    ...

x = True
y = foo(x)
bar(y)  # this passes mypy regardless of the type of y
```

Note that even if `foo` has type hints, mypy will still always pass the above line if it is not configured to follow imports. Luckily, `--follow-imports=normal` is the default for mypy, but this option is often turned off when adding mypy to an existing codebase.

Unfortunately, this behavior is not always clear, and mypy can lull you into a false sense of confidence when it passes your code while in reality, it's considering everything as `Any`. Speaking of which&nbsp;&hellip;

## Make sure your library has a py.typed file

[PEP-561](https://www.python.org/dev/peps/pep-0561/) specifies that if you want your package to export its type hints, then you must include a `py.typed` marker file in your package installation. The file is just an empty file. If you do not include it, then your package's users will not be able to leverage your type hints in their mypy runs. To them, it will be as if your package has no type hints at all.

This is a small but crucial detail that is all too easy to miss while you're learning about Python's `typing` module. As the [PEP states](https://www.python.org/dev/peps/pep-0561/#packaging-type-information), you'll also need to declare this `py.typed` file as part of your package's installation. For example, you can add it to the `package_data` section of your `setup.py` file.

To confirm this behavior, we can see how mypy infers the type of an imported constant with [`reveal_type`](https://mypy.readthedocs.io/en/stable/cheat_sheet.html?highlight=reveal_type#when-you-re-puzzled-or-when-things-are-complicated):

```python
from dep import CONSTANT  # CONSTANT = 1

reveal_type(CONSTANT)
```

```text
$ mypy foo.py
foo.py:1: error: Skipping analyzing 'dep': found module but no type hints or library stubs
foo.py:1: note: See https://mypy.readthedocs.io/en/latest/running_mypy.html#missing-imports
foo.py:3: note: Revealed type is 'Any'
```

Mypy thinks it's `Any`, even though the actual value is the integer `1`. But after we add an exported `py.typed` file to our `dep` dependency:

```text
mypy foo.py
foo.py:3: note: Revealed type is 'builtins.int'
```

Mypy correctly infers the type as an `int`.

## Consider using object instead of Any in some cases

Sometimes, you're deserializing a big JSON blob or dealing with a dictionary with multiple different, complex value types. In cases like these, it may be tempting to reach for `Any` as the type hint.

<Aside>
  The <code>object</code> type hint is similar to TypeScript's{" "}
  [`unknown`](https://www.typescriptlang.org/docs/handbook/2/functions.html#unknown) type.
</Aside>

Consider using `object` as a typesafe alternative to declaring that a value could be anything. Mypy won't allow you to do most things with `object`; you'll have to narrow the type with `isinstance` checks or similar:

```python
def foo(x: object) -> int:
    return len(x)  # mypy rejects this


def foo(x: object) -> int:
    if isinstance(x, str):
        return len(x)  # passes mypy as we've confirmed x: str
    elif isinstance(x, int):
        return x  # passes mypy as we've confirmed x: int
    raise TypeError()
```

This is the key distinction between `Any` and `object`: Use `Any` to opt-out of static type checking, and use `object` to declare that the value can be of any type.

Of course, if you're declaring that a value can be of any type, then there's not a lot of useful things you can do with that value until you introspect its type. As [this blog post](https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/) eloquently describes it, “you can't process what you don't know.”

While there is no distinction between `Any` and `object` at runtime, using `object` in your code will let mypy force you to prove that you can safely use and manipulate your value before you do. `Any` will not.

## Tell mypy to show error context

The `--show-error-context` flag directs mypy to give a couple of lines of context for every error.

Without the flag:

```text
$ mypy bar.py
bar.py:2: error: Argument 1 to "len" has incompatible type "object"; expected "Sized"
Found 1 error in 1 file (checked 1 source file)
```

With the flag:

```text
$ mypy bar.py --show-error-context
bar.py: note: In function "foo":
bar.py:2: error: Argument 1 to "len" has incompatible type "object"; expected "Sized"
Found 1 error in 1 file (checked 1 source file)
```

Not a big deal (and the added verbosity could be unwanted in CI), but it's helpful when you're not as familiar with the code.

## Enable “drift” checks

The [`--warn-redundant-casts`](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-warn-redundant-casts) and [`--warn-unused-ignores`](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-warn-unused-ignores) flags tell mypy to warn you if there's an unneeded [cast](https://docs.python.org/3/library/typing.html#typing.cast) or unused `type: ignore` comment.

Both of these usually happen over time as your code starts to drift. That is, when you first write the code, you might need the `cast(str, x)` function to direct mypy a certain way. But later on, if you update another section of the code, then you may no longer need it.

It's not always obvious when updates to one section of the codebase affect mypy's understanding of another section. These flags help prune your code over time.

Mypy continues to get smarter as new versions are released, and previous `type: ignore` comments due to mypy bugs or deficiencies can become stale over time. It is especially important to remove these when they're stale, as they can prevent mypy from notifying you of different but valid type errors on the same line of code.

## Disallow untyped definitions and method calls

If you're going to adopt mypy on your codebase, it helps to go all in and annotate all your methods. The [`--disallow-untyped-calls`](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-disallow-untyped-calls) and [`--disallow-untyped-defs`](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-disallow-untyped-defs) flags tell mypy to enforce this.

<Aside>
  Adding type hints to an existing codebase is hard. Luckily, there are some
  great tools to ease the transition, like{" "}
  [typing_copilot](https://github.com/obi1kenobi/typing-copilot).
</Aside>

Dealing with untyped methods causes mypy to treat types as `Any`, passing all subsequent checks involving them. It is better to explicitly annotate your methods with `Any` types than to leave them unannotated, as being explicit is better than being implicit. Also, this reduces the barrier to refine your type hints in the future.

These flags also prevent any new unannotated code from being added to the codebase, helping ensure your codebase doesn't regress in this respect.

## Disallow untyped decorators

Wrapping your typed method with an untyped decorator will cause your method to be untyped. Mypy understands the type hints in a regular typed function:

```python
def foo() -> int:
    return 2

reveal_type(foo)
# Revealed type is 'def () -> builtins.int'
```

If we decorate this method with an untyped decorator, mypy now infers the method as untyped:

```python
def decorate(func):
    def inner():
        return func()
    return inner

@decorate
def foo() -> int:
    return 2

reveal_type(foo)
# Revealed type is 'Any'
```

We took care to add type hints to our functions. It would be a shame if we miss out on some benefits because we happen to decorate with untyped decorators.

The `--disallow-untyped-decorators` flag directs mypy to warn whenever it encounters a typed method wrapped by an untyped decorator. This is a great way to prevent the introduction of some silent `Any` types into your code.

## No implicit re-export

Python allows you to import `foo` from file A even if file A doesn't declare `foo`, provided that file A imports `foo` from somewhere else. That is, the following situation is valid:

```python
# File A
from file_b import foo
...
```

```python
# File B
def foo():
    ...
```

```python
# File C
from file_a import foo  # Note that it's file_a, not file_b
```

Even though this works, this indirection increases the likelihood of problems in the future. If we refactor file A so that it no longer imports `foo`, then file C will also stop working.

Luckily, the `--no-implicit-reexport` flag directs mypy to warn us whenever it detects this situation.

With this flag, we can still export the imported `foo` from file A with either of the following:

```python
# File A
from file_b import foo as foo
```

```python
# File A
from file_b import foo
__all__ = ["foo"]
```

You'll receive benefits from this flag even if you rely on exporting imported values as it forces you to make them explicit.

## Disallow implicit type parameters in generics

By default, mypy allows you to use `List` and `Dict` as type hints without specifying type parameters. Mypy uses `Any` for all type parameters you don't specify, so `List` is equivalent to `List[Any]` and `Dict` is equivalent to `Dict[Any, Any]`.

<Aside>
  Starting with Python 3.9, you can specify type parameters with the built-in
  collections, like <code>list[str]</code>. See{" "}
  [PEP-585](https://www.python.org/dev/peps/pep-0585/) for more details.
</Aside>

The `--disallow-any-generics` flag directs mypy to reject any generic type hints without explicit type parameters.

You start to develop a healthy distrust of `Any` as you work more with Python type hints. `Any` has legitimate uses, but you'll correctly double-check the context when you see one. This increased caution is good since mypy will gloss over `Any` types.

Enabling this flag continues our trend of preferring explicitness. Generics without type parameters are a great place for `Any` types to hide. `Dict[Any, Any]` will catch your eye&mdash;while `Dict` may not.

## Enable a few more warnings

The [`--warn-return-any` flag](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-warn-return-any) tells mypy to produce a warning if you're returning `Any` from a method declared to return another type.

The [`--warn-unreachable` flag](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-warn-unreachable) tells mypy to produce a warning if it detects code that will never execute.

The [`--strict-equality` flag](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-strict-equality) tells mypy to flag any comparisons between non-overlapping types. These always evaluate to false at runtime.

All the conditions that trigger these warnings are often the result of buggy code or silent `Any` types. These warnings, along with the other tips discussed in this post, will help you better leverage mypy to create more robust and maintainable software.



Policy around Internet Service Providers (ISPs) has been in the public eye recently
with the recent [Internet Day of Protest](https://battleforthenet.com) in support
of [Net Neutrality](https://en.wikipedia.org/wiki/Net_neutrality). Net Neutrality is
the position that ISPs have to treat all internet traffic the same regardless of the traffic. This
is similar to how we expect the power company to treat "electrical traffic" (It
would seem outrageous if the power company charged different rates for the electricity
used by a TV opposed to electricity used by a refrigerator).

Net Neutrality is crucial to a healthy internet. It guarantees startups and smaller
businesses equal opportunity compared to larger corporations with money to spend
on "fast lanes." Net Neutrality also prevents companies like Comcast, Verizon, and
AT&T from having too much power in our lives. For example, an ISP could throttle
access to Netflix or similar service while providing a fast lane to their own Netflix
competitor, giving them an unfair advantage.

Opponents of Net Neutrality frame it as the FCC [overstepping its reach](http://thehill.com/blogs/pundits-blog/technology/332099-ajit-pais-fcc-is-right-to-roll-back-the-regulatory-overreach-of).
Ajit Pai, the chairman of the FCC, has repeatedly [stated](http://www.pbs.org/newshour/bb/fcc-chair-ajit-pai-explains-wants-scrap-net-neutrality/)
that the concerns raised by Net Neutrality supporters are "hypothetical" and nothing
more. This is blatantly wrong. This great [reddit post](https://np.reddit.com/r/NeutralPolitics/comments/6cbckk/net_neutrality_john_oliver_vs_reasoncom_whos_right/dhtdwwi/)
gives numerous examples of ISPs interfering with services to benefit their business
model.

Normally, if a company was engaging in these practices, we as consumers would be
able to switch to a competitor. The pressure from the free market serves to keep
these companies in check. However, many Americans [have no choice](https://arstechnica.com/information-technology/2016/08/us-broadband-still-no-isp-choice-for-many-especially-at-higher-speeds/)
if they want high speed internet. Some, including people from my home in Southeastern
Kentucky, have no choice.

The infrastructure required in order to be an ISP presents a massive upfront cost
to new companies. This gives ISPs "natural monopolies" in the areas they service.
ISPs in many areas therefore do not have to worry about competitor pressure. This
is dangerous, and ISPs will repeat the same behaviors they have in the past if
the FCC does not step in in order to protect consumer interests.

For many Americans, government regulation has a bad connotation to it. While there
are certainly times where regulation has impeded innovation and [led to less jobs](https://www.usnews.com/opinion/economic-intelligence/2015/09/14/regulations-kill-jobs-data-show), there are countless things that we take for granted as
citizens. Vehicles are infinitely safer due to government regulations. Air pollution
in and near major US cities has declined significantly due to regulations. Also,
we can thank regulations for power companies not being able to charge as much as
they want given their "natural monopoly."

The internet is a utility, and it needs to be regulated like one. We cannot allow
The FCC must uphold Title II with respect to the internet. We cannot allow ISPs
the power to control the content we see. They have enough power as it is. Gutting
the FCC's ability to enforce Net Neutrality under the guise of removing regulations
is wrong and not in our best interests. I encourage everyone in the US to contact
their representatives to voice your support for Title II and Net Neutrality.



Using a list of tuples instead of a tuple of lists is an easy way to help [make illegal states unrepresentable](https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/) without any custom types in your code.

We can do this in places where the multiple lists are required to be the same length, like a method taking in multiple lists or a structuring storing multiple lists. Let's take a look at an example of this:

```python
def foo(y_pred: List[float], y_true: List[float]) -> float:
    ...
```

We need to check that the two inputs are of equal length and raise an exception if not:

```python
def foo(y_pred: List[float], y_true: List[float]) -> float:
    if len(y_pred) != len(y_true):
        raise ValueError("Lists need to be of the same length")
    ...
```

While this is okay and we've handled our error case, it would be better if our function did not have to check this. Programmers are fallible, and it's all too easy to forget this check, especially if we come back to this code in the future and refactor (or if someone else comes across the code).

I argue that the following is better for many cases:

```python
def foo(y_pred_true_pairs: List[Tuple[float, float]]) -> float:
    ...
```

While we gain a longer parameter name, we also eliminate the possibility of there being a different number of `y_pred` and `y_true` elements just by using a different data structure!

Of course, if an upstream process was producing two different sized lists, then changing our function signature doesn't magically fix that problem. It does push these concerns away from our function and closer to the source of any problems, which is a positive change.

It should not be our `foo` function's concern that the lengths of the two lists could be different. Any error handling that `foo` has to implement increases its complexity. Also, any caller of the original `foo` function should be made aware that it can raise an exception on some inputs, namely inputs where the two lists are of a different length. Put another way, the original `foo` is a [partial function](https://en.wikipedia.org/wiki/Partial_function), not a total function.

The new `foo` pushes the concern upstream because of the following:

To call the `foo` function, the caller needs to convert the two lists (or whatever format the data is in) into a list of tuples. If the caller can do this successfully, then it will be able to call `foo` without having to worry about any exceptions. If the data is invalid, then the caller will not be able to convert the data.

If this is due to a bug in the caller's implementation, then great, we've exposed the bug very close to the source. If this is due to a bug upstream of the caller, then our caller has a couple of options on how to handle this:

1. If the caller is able to gracefully handle this error and still compute the result, then it can.
2. If the caller needs the result of `foo` to compute its result, then we are in the same situation as before, just one level up. We should consider having the caller take the data in the same format as `foo` in order to push this concern upwards once more.

The continual pressure that this applies is good because it pushes data-related concerns closer to the boundary of our system. By handling any invalid data at the boundary, we free up the rest of our internal code from these worries.

For more information about this, I _highly_ recommend the excellent [Parse, don't validate](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) post.

And one last thing: While our `foo` function is better, we can further improve it (provided that we don't mutate `y_pred_true_pairs`) by [mimicking immutability with our type hints](/blog/mimicking-immutability-python-type-hints). So with this change:

```python
def foo(
    y_pred_true_pairs: Sequence[Tuple[float, float]]
) -> float:
    ...
```

and a static analysis tool like [mypy](http://mypy-lang.org/), we're able to get an error if we accidentally mutate it!

All of this is part of a trend about pushing potential runtime errors to compile/static analysis time. It's much easier to catch a bug during development with a compiler or linter than it is to push out a fix to customers in production. The small amount of additional development time will pay dividends over the long run.

So, next time you are in a situation where you have multiple lists that need to be the same length, consider requiring a list of tuples instead!



Note: While the examples in this post are in Python, the information should be relevant to any languages with the `NewType` construct.

Python's [typing module](https://docs.python.org/3/library/typing.html), introduced in version 3.5, allows developers to specify type hints for their methods and variables. These type hints can then be statically checked for correctness via a program like [mypy](http://mypy-lang.org/). When used throughout your program and checked with mypy, they allow you to catch whole classes of bugs without ever running your program. They also serve as verified documentation for your methods (though they are not a complete replacement for full documentation).

_Example of function without type hints_:

```python
def copy_and_scale(features, x):
    return {name: value * x for name, value in features.items()}
```

_Example of function with type hints_:

```python
from typing import Dict


def copy_and_scale(
    features: Dict[str, int], x: int
) -> Dict[str, int]:
    return {name: value * x for name, value in features.items()}
```

One aspect of `typing` that doesn't get enough use in my experience is the [`NewType`](https://docs.python.org/3/library/typing.html#newtype) helper. `NewType`s are often lumped together with type aliases, with the latter being used in cases where the former is more appropriate.

The [`typing` docs](https://docs.python.org/3/library/typing.html#newtype) provide a nice summary of when you would want to use a `NewType` vs a type alias:

> Recall that the use of a type alias declares two types to be equivalent to one another. Doing `Alias = Original` will make the static type checker treat `Alias` as being exactly equivalent to `Original` in all cases. This is useful when you want to simplify complex type signatures.
>
> In contrast, `NewType` declares one type to be a subtype of another. Doing `Derived = NewType('Derived', Original)` will make the static type checker treat `Derived` as a subclass of `Original`, which means a value of type `Original` cannot be used in places where a value of type `Derived` is expected. This is useful when you want to prevent logic errors with minimal runtime cost.

Let's look at a simple pair of concrete examples to see the difference:

_Type alias_:

```python
Uid = str


def process_uid(uid: Uid) -> None:
    ...


process_uid("foo")
```

_mypy output_:

```txt
Success: no issues found in 1 source file
```

_NewType_:

```python
Uid = NewType("Uid", str)


def process_uid(uid: Uid) -> None:
    ...


process_uid("foo")
```

_mypy output_:

```txt
error: Argument 1 to "process_uid" has incompatible type "str"; expected "Uid"
Found 1 error in 1 file (checked 1 source file)
```

In order to resolve the error, you need the below cast:

```python
Uid = NewType("Uid", str)


def process_uid(uid: Uid) -> None:
    ...


process_uid(Uid("foo"))
```

## So, what's the point?

From these examples, we can hopefully see why mypy succeeds/fails, but it probably looks like `NewType`s add boilerplate without much benefit. The point of `NewType`s is to help prevent logic bugs, so how does casting our string via `Uid("foo")` help achieve this?

For that, let's look at another example:

```python
Age = NewType("Age", int)


def query_for_options_with_ages(
    url: str,
) -> Dict[str, List[Age]]:
    ...


def calculate_cost(options: int, age: Age) -> int:
    ...


options_age_info = query_for_options_with_ages(
    "https://example.com/"
)

for options, ages in options_age_info.items():
    age_option_len_pairs = [(age, len(options)) for age in ages]
    costs = [
        calculate_cost(option_len, age)
        for option_len, age in age_option_len_pairs
    ]

    logger.log(
        "options: %s | estimated total cost: %d",
        options,
        sum(costs),
    )
```

Do you see the bug in our code? Luckily, mypy does:

```txt
error: Argument 2 to "calculate_cost" has incompatible type "int"; expected "Age"
```

Why is our `age` variable of type `int` instead of `Age`? Because we swapped our tuple unpacking! Instead of `for option_len, age` it should be `for age, option_len`.

So yes, the above-contrived example shows a case where mypy catches a bug that would not have been caught if we used a `Age = int` type alias. Of course, if we were more careful while writing the code, we would have spotted this obvious blunder and wouldn't need to rely on mypy (or the `NewType` boilerplate). We even named our variable `age_option_len_pairs` with the correct order!

While this is true, the crux of the issue is the following: humans make mistakes. Even the best programmers make silly mistakes.

To borrow an excellent phrase from [an excellent blog post](https://fasterthanli.me/articles/aiming-for-correctness-with-types):

> Engineering is not about "not doing mistakes". Engineering is about designing systems that ensure fewer mistakes occur.

Luckily, we have tools that we can leverage to catch some of these mistakes before they are deployed out in the wild. Type systems are one of our better safeguards for this, and the `typing` module along with mypy is the closest thing we have to this in `Python` right now.

Alas, type systems are not a [silver bullet](https://en.wikipedia.org/wiki/Silver_bullet), and it's important to understand their limitations. But these limitations shouldn't stop us from leveraging them whenever we can. We can't let perfection be the enemy of good.

## How to know when to use a NewType?

Next time you are coding Python and write out a type alias, ask yourself if the name you are aliasing is the _exact same thing_ as the type you are aliasing it to. Or is it actually a subtype and therefore would be better as a `NewType`? In our first examples, all `Uid`s were `str`s, but not all `str`s are `Uid`s. Likewise, all `Age`s are `int`s, but not all `int`s are `Age`s.

Unfortunately, there's no magic formula for when something should be a `NewType` vs a simple type alias. Let's look at a simple example where a type alias probably makes more sense:

```python
def get_features() -> Dict[str, Union[int, float, str]]:
    ...


def copy_and_scale(
    features: Dict[str, Union[int, float, str]], x: int
) -> Dict[str, Union[int, float, str]]:
    ...


def log_features(
    features: Dict[str, Union[int, float, str]]
) -> None:
    ...
```

In this code, we see that the `Dict[str, Union[int, float, str]]` type appears in multiple places. Introducing a type alias removes this duplication from our code and arguably makes it more readable:

```python
Features = Dict[str, Union[int, float, str]]


def get_features() -> Features:
    ...


def copy_and_scale(features: Features, x: int) -> Features:
    ...


def log_features(features: Features) -> None:
    ...
```

What about a `NewType`? Wouldn't that help mypy catch bugs when we input a dictionary of something other than features instead of an actual `Features` dictionary?

Well, we could make a new type, but then we would need to support all of the operations we want to do. For example, we want to be able to add new features to our dictionary, and we may also want to update or delete existing features. We might want to easily combine two dictionaries of features into one.

A heuristic I use for determining if something should be a `NewType` vs a type alias is how simple the actual type is. By actual type, I mean the type on the right-hand side of the assignment. For example, if we have `Features = Dict[str, Union[int, float, str, bool]]`, then the actual type is fairly complex. Whereas if we have `Uid = str`, then the actual type is simple.

In my experience, if the actual type is simple, then you probably want a `NewType`. Why? A type alias for a simple type probably isn't to reduce redundancy. It almost certainly isn't to save keystrokes.

It's usually to signify that we have a special case of the actual type, or that we want to better "document" our data. If we care enough to alias our `float`, `str`, `bool`, etc. to a different name, then our different name is probably a different _thing_ than the simple type.

Using `NewType`s is not guaranteed to prevent logic bugs in your code. They only represent a small but important piece of the tools available to help catch bugs during static analysis instead of at runtime. Judicious use of these tools makes our code more robust and easier to maintain. They help create a system where it's harder to make a mistake.

So, next time you are creating a type alias, ask yourself if you'd be better served by using a `NewType` instead.



[Technology Education And Literacy in Schools](https://www.microsoft.com/en-us/teals) (TEALS) is a Microsoft program that builds sustainable computer science programs in high schools. The program is sustainable in that volunteers train an on-site teacher who will eventually take over the class.

I have [a personal connection](/blog/microsoft-teals-personal-experience-lasting-impact) with TEALS, having been an AP CS student with the program my senior year of high school. I know firsthand how impactful the program can be&mdash;and I know that I wouldn't be where I am today without it.

So, while I was working from home due to the pandemic, I thought it would be a good time to volunteer. I didn't realize when I signed up to volunteer that my high school's CS teacher had left for another job, leaving the school without a CS class. After learning, I requested to switch, and the TEALS staff were able to make it happen.

I had the opportunity to co-teach the course I took at my high school seven years ago.

## It was a rewarding experience

While it was challenging, it was a very rewarding experience. Teaching is not something I'm particularly good at, so this was an excellent opportunity to improve my skills. It forced me out of my comfort zone, but it wasn't too bad.

Luckily, TEALS provides a structured [curriculum](https://tealsk12.github.io/apcsa-public/) with plenty of teaching resources to volunteers. Slides and worksheets are almost always available for each topic, along with a sheet of key points and suggestions for the teacher.

It was nice to give back to my school and the program. I hope that I've made a positive impact on the students.

## Be aware of the curse of knowledge

A common cognitive bias when teaching is the [curse of knowledge](https://en.wikipedia.org/wiki/Curse_of_knowledge), where people with knowledge about a particular topic assume that others share that knowledge. I deal with code nearly every day, and there's a lot of foundational knowledge I take for granted. A student most likely will not have that knowledge, and it can be easy for a teacher to gloss over some of the finer details.

Even though I tried to keep this top of mind, there were still cases where I caught myself assuming knowledge. I'm sure there were cases where I didn't catch myself.

I found that the provided lecture notes were a great help since they highlighted key points and anticipated areas where students might need more time to properly digest the material.

## Keeping students engaged

It's hard to keep students interested and motivated, especially remotely. A lot is going on in the world, and the students were trying to learn in extraordinary circumstances.

Understandably, most students are more interested in concepts that help with their immediate problems, like arrays. It's harder to motivate concepts like encapsulation, where the benefit is more pronounced while [programming in the large.](https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small)

<Aside>
  I've experienced this in my professional job as well. It's tough to adequately
  prioritize code health and maintenance when it doesn't meet the project's
  immediate needs.
</Aside>

These more "professional" concepts unfortunately seem best learned in hindsight after bad experiences with poorly maintained code. Perhaps we can learn from analogous situations in other fields, like [flossing.](https://hillelwayne.com/post/flossing/)

On the other hand, programming is fairly unique within high school subjects in that it's easier to verify your problem sets. If you're working on a problem to print a pattern of asterisks with for loops, you can always run your program and see! It's not as easy to verify your math or English homework.

I think we can leverage this feedback loop to increase engagement. More frequent feedback also helps to localize cause and effect. If you see the output of your program, change the code, then run again, you can connect the change in output to the change in your code.

## Developer tools are invaluable when learning

The AP Computer Science curriculum uses the [Java programming language](<https://en.wikipedia.org/wiki/Java_(programming_language)>) as the medium to learn concepts. While revolutionary when it was released, Java has many idiosyncrasies that can get in the way of learning more fundamental concepts.

It can be frustrating to deal with syntax errors while you're learning things like inheritance or sorting algorithms. `int[] foo` vs `int foo[]` shouldn't matter when learning the differences between an array and `ArrayList`, but you can only run your code with the former. Furthermore, the reasons behind certain syntactical decisions are often [unsatisfactory.](https://en.wikipedia.org/wiki/Java_syntax)

Luckily, we have access to some amazing developer tools. [Integrated development environments](https://en.wikipedia.org/wiki/Integrated_development_environment) (IDEs) are applications that provide many tools and utilities to help programmers write software.

Closing the feedback loop is one of the best features of most IDEs. Much like how word processors can underline a misspelled word, IDEs can underline anywhere in your code with syntax errors. Some can even suggest and implement fixes to common issues. This is invaluable when you're learning, as it provides constant feedback and suggestions while programming.

Contrast this with a workflow where you edit a source file and need to move to another program to compile the file. After compiling, you'll need to move back to the window with your source file and correct any mistakes. This introduces a lot of inefficiencies, and the experience is not as fluid as with IDEs.

A compiler catching these types of errors is a perfect place to inject context-aware feedback to a user. The [Rust](https://www.rust-lang.org) compiler is an exemplar of helpful error messages that I have a lot of experience with. [Elm](https://elm-lang.org) also has a similarly helpful compiler, though I have less experience with it.

Regardless, while Rust and Elm may not be the best initial languages for a student to learn, having an empathetic compiler in their style to help guide students would be amazing.

I'm not aware of any student-focused compilers that place a priority on UX and teaching rather than optimizations and completeness. One for a traditional initial language would be an interesting project that has a lot of potential to positively impact the learning experiences of students. Though honestly, people of all experience levels benefit from good UX and error messages, so it may not make sense to separate these priorities from the standard compilers for languages.

<Aside>
  Of course, machine learning is really about automating the biases of the past.
  If you're pessimistic, then you could consider Copilot as automating the buggy
  code of the past.
</Aside>

Tools like the newly announced [GitHub Copilot](https://copilot.github.com) make me hopeful for the future. If Copilot and future similar tools can help automate the boilerplate and suggest good context-aware code, then they can help remove the barrier to programming. These tools have the potential to introduce a new abstraction layer. Now, most programmers do not have to worry about assembly and low-level programming. In the future, maybe most programmers will not have to worry about a lot of the boilerplate and rigid syntax of our current languages.

## Should object-oriented programming be taught so early?

There's no escaping object-oriented programming in Java, a language where nearly everything is an object. Java is the language of the AP exam, so there's not much TEALS can do about that.

Object-oriented programming is extremely common in the industry, and some subscribe to it wholeheartedly. It has many benefits including being fairly intuitive for students.

However, it has some drawbacks, especially as projects become older and larger. It's all too easy for object-oriented code to become tightly coupled and complex.

The two things I worry most about are the following: forcing an object-oriented design onto a problem where it doesn't fit, and having to unlearn many of the habits when working with other paradigms, like functional programming.

Objects map nicely to many of the manufactured problems you have in class. In the industry, though, the only constant is change. Your wonderfully designed object hierarchy might cleanly solve the first version of the requirements, but it can easily become a liability while solving the second.

Just for the record, I think object-oriented programming should still be taught. I'm just not sure if other paradigms should be excluded. Arguably, procedural programming is taught at the beginning of class while introducing fundamental concepts like variables and control flow. This isn't usually made explicit, and it's certainly not discussed as an alternative to object-oriented.

## The pandemic exacerbated the digital gap

When I took AP CS through TEALS by senior year of high school, it was taught remote, as the volunteers were based in NYC. However, we still had an on-site teacher every day of the class, and we had reliable access to the internet at our school.

But when I took AP CS, there was not an ongoing pandemic forcing students to stay home. In a more just society, homebound students would still have access to learning materials and teachers via the internet. Unfortunately, reliable high-speed internet access is still not available for much of my hometown.

Some students in the class were not able to join the Zoom sessions during the scheduled time. For other students, they were able to join, but sharing their screen and video was unreliable. We were able to record the lectures and share with students unable to join live, but this, unfortunately, does not provide the same impact as attending live.

## Representation is important

Our high school does an amazing thing for the AP CS students: they fly the students to Seattle for a tour of different tech companies.

There are a ton of Appalachian stereotypes, particularly around intelligence. You can't help but internalize some of them while growing up in the area. For me, the AP CS course and trip played a critical role in instilling confidence in my ability.

This trip was a highlight of the class for me. Not only was it my first time on the West Coast, but it also made tech careers seem obtainable. They were no longer foreign. These were real people, and I could see my future self in their shoes.

It worked out, and I'm fortunate that I can serve as an example of a TEALS alumni who found success.

## Looking to the future

I hope the AP CS course at my high school is sustainable. I also hope to encourage more people to volunteer with the program&mdash;because it truly is life-changing.

Computers are one of our greatest inventions, and they give their creators a ton of power. As software becomes more foundational to our society, we need to ensure that all members of our society are equally represented in tech. TEALS is a great opportunity to empower underrepresented groups, and I'm excited to see its future.

If you have any questions or comments about volunteering or the program, please reach out to me at <Email/>. I'd love to help.



I recently finished [CIS 198](https://cis198-2016f.github.io/), a minicourse at Penn on the [Rust programming language](https://www.rust-lang.org). Rust is a language that "runs blazingly fast, prevents segfaults, and guarantees thread safety." It provides functional programming features while also giving you low-level control when needed. The feature that initially caught my interest is that Rust is memory safe without the need of a garbage collector. I never knew how much I would appreciate memory safety until I spent many late nights tracking down memory bugs in our operating systems project written in C. Rust achieves memory safety through [its ownership model](https://doc.rust-lang.org/book/ownership.html). When you first start with Rust, this will probably be something you hate. I definitely did. However, I now view it as one of the best features of Rust. It forces you to know how the variables and structures are used throughout your program and thus leads to better code. Code that results in nasty, hard-to-find bugs in other languages results in a compiler error (usually with a helpful message) in Rust.

<PostImage
  src="/assets/blog/ruci-and-my-first-experiences-with-rust/rust-error-message.png"
  alt="Rust error message example"
  aspectRatio={2.94}
/>

_Example error message in Rust_

Everyone knows the best way to learn any new programming language is by building something in that language. My final project was [ruci](https://github.com/justinaustin/ruci), a UCI chess engine. Ruci was not only my first major project with Rust, it was also my first experience with artificial intelligence. So, it introduced me to concepts such as [Alpha-Beta Search](https://www.chessprogramming.org/Alpha-Beta) and [Quiescence Search](https://www.chessprogramming.org/Quiescence_Search) while also giving me valuable experience with Rust. The thing that most surprised me while working on ruci was how little I had to fight with the borrow checker (since I fought with it so much on previous assignments). I believe it was a combination of having more experience with Rust and designing and writing a program from scratch, therefore having a better understanding of the data structures and how they're used. The engine still needs a lot of work as it is extremely slow, but I look forward to working on it whenever I have free time during the upcoming semester.

Rust is a language that I am really excited about. I can definitely see it as the future, and I hope to see more and more people give it a chance. It has a steeper learning curve than a lot of languages, and you will probably become extremely frustrated with the borrow checker when you first start out. Stick with it. It will be extremely rewarding, and you'll avoid so many bugs in your future projects! If you run into problems, please take advantage of [Rust's amazing community](https://www.rust-lang.org/en-US/community.html) on [/r/rust](https://www.reddit.com/r/rust/), [#rust-beginners](https://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust-beginners), and [Stack Overflow](https://stackoverflow.com/questions/tagged/rust). We are more than willing to help :).



I found some trouble getting my spotify client to scale correctly to my HiDPI screen after installing it. Hopefully this tutorial will help someone having the same problem.

1. Install spotify via [flatpak](http://flatpak.org/) using the instructions on [flathub](https://flathub.org/apps/details/com.spotify.Client).
2. You can force spotify to scale to your display using the `--force-device-scale-factor=X` command line option. I find `X=1.6` works the best for me, but this will change depending on your setup. So, full command to do this in your terminal emulator is `flatpak run com.spotify.Client --force-device-scale-factor=1.6`.
3. In order to make this change permanent, you can modify the desktop file to send this command line option whenever Spotify is launched via the icon. cd /var/lib/flatpak/exports/share/applications/ and edit the com.spotify.Client.desktop file as root with your favorite text editor. Change the `Exec` variable to include the above command line option. Note that these changes will be overridden if Spotify updates. You can instead copy the desktop file to `~/.local/share/applications/` and make your changes there. It should look similar to this:

<PostImage
  src="/assets/blog/spotify-flatpak-hidpi-scaling/spotify-desktop-screenshot.png"
  alt="Spotify desktop screenshot"
  aspectRatio={2.08}
/>

4. ~~Restart your computer and Spotify should correctly scale the next time you launch it!~~ Update: `sudo update-desktop-database` and then launch Spotify from your application launcher.

_Thanks to [Daniel Aleksandersen](https://www.daniel.priv.no/) for catching a few mistakes with this tutorial!_



[Bear Track Lake Adventures](https://beartracklake.com), the website I made for my parents' cabin rental business, recently turned ten years old.
With that, I'd love to take this opportunity to both look at the history of the website and also introduce the new redesign.

For context, Bear Track Lake Adventures is a cabin rental business in the [Red River Gorge](https://en.wikipedia.org/wiki/Red_River_Gorge)
area in Kentucky. There are three cabins for rent: Bear Lair, A Sleepy Bear's Dream, and A Sneaky Bear's Hideaway.
They are all located next to a six-acre lake on a beautiful piece of property that I'm lucky to have grown up on.

While there are three cabins now, the business actually didn't start with cabin rentals.
When we started, we only had fishing and camping in tents and caves. And of course, we needed a
website to promote the new business.

I unfortunately don't have screenshots of the initial website, which was a WordPress site created by a local developer.
Being a sophomore in high school who was interested in computers, I tried to make a website including our new cabin that we liked better.
I don't remember the exact software I used, but it was a basic WYSIWYG editor included in our hosting package.

## Initial design

Here's a screenshot of the cabin page on that site courtesy of the [Wayback Machine](http://web.archive.org):

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/first_design_0.jpg"
  alt="Screenshot of first website design"
  aspectRatio={1.24}
/>

Quickly after launching this version, there was some design iteration, like making the navigation buttons bigger and the image carousel smaller.
Here's the same page after this:

<Aside>
  The left to right green and brown gradient was also swapped to a top to bottom
  one. ¯\_(ツ)_/¯
</Aside>

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/second_design_0.jpg"
  alt="Screenshot of second iteration of first website design"
  aspectRatio={1.24}
/>

And the homepage:

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/second_design_1.jpg"
  alt="Screenshot of second iteration of first website design bottom half"
  aspectRatio={1.28}
/>

While this does look dated now, it was a success, drawing plenty of new visitors to the business. The design was something we were proud of,
and it confirmed for my parents to trust a critical part of their business to their high schooler.

Other pages followed the same basic layout, with the gradient as a background, centered text throughout the page,
and a few pictures scattered around.

## Second design

Of course, this design did not last forever. The second cabin was ready to rent, and this was a great excuse to
redesign the website, using the newly updated website builder.

This redesign captured a major change for the business. We were now solely focused on cabin rentals, as they proved
more lucrative than camping. I swapped “Adventures” in the website title with “Cabins” to help signify this,
while also hoping that it would also help with [SEO](https://en.wikipedia.org/wiki/Search_engine_optimization).

For better or worse, the background gradient was gone, replaced with a subtly dotted background that was the
default of the theme I was using.

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/third_design_0.jpg"
  alt="Screenshot of third website design"
  aspectRatio={1.07}
/>

The individual cabin pages kept the same general structure, with a description on top, an image carousel in the middle, and amenities and booking information below.

<Aside>
  Unfortunately, the Wayback Machine did not capture the picture in this
  screenshot, but it was the same.
</Aside>

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/third_design_1.jpg"
  alt="Screenshot of third website design"
  aspectRatio={1.16}
/>

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/third_design_2.jpg"
  alt="Screenshot of third website design"
  aspectRatio={1.31}
/>

This design was also the first to feature an embedded booking calendar from the vacation rental management software we used,
allowing guests to book a reservation right on the page.

## Third design

While this version served us well for a few years, the third cabin's completion presented a problem.
The website builder I was using was free for six pages, but we wanted to add a seventh &hellip;

Ever the frugal one, I took this as an opportunity to try web development without a website builder. Fresh off my first year of undergrad,
I spent the summer learning [Bootstrap](https://getbootstrap.com/) and creating a new website.

I found a default carousel theme that seemed like a good start, and without really knowing what I was doing, I started editing
the HTML and CSS to get a workable homepage.

This was the eventual outcome:

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/fourth_design_0.jpg"
  alt="Screenshot of fourth website design top half"
  aspectRatio={1.31}
/>

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/fourth_design_01.jpg"
  alt="Screenshot of fourth website design bottom half"
  aspectRatio={1.78}
/>

With confidence from this, I started working on the individual cabin pages, ending up with the following:

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/fourth_design_1.jpg"
  alt="Screenshot of fourth website design"
  aspectRatio={1.3}
/>

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/fourth_design_2.jpg"
  alt="Screenshot of fourth website design"
  aspectRatio={1.22}
/>

And that was it. This design and version persisted. It needed only minimal changes over the six-year lifespan.
While it was far from perfect, it worked. It drew compliments from customers and helped support the
business's growth.

But it was time for a redesign.

## New design

The old website, unfortunately, had quite a bit of technical debt, and it was way harder than it should be to
make changes. With the new website, after the initial setup, I wanted to minimize the amount of time I'd need
to spend on it to make any necessary changes.

<Aside>
  In fact, Zola builds the new website from scratch in under two seconds.
</Aside>

The new website is built using the excellent [Zola static site engine](https://getzola.org/), which builds the output
HTML files from a series of Markdown files and [Tera templates](https://tera.netlify.app/). This helps reduce the
duplication in the project by allowing each component of the website, like the footer or menu bar, to be declared in
one place. This is already a vast improvement over the previous website, which was created by manually editing HTML
files from a Bootstrap template.

Here's the new landing page:

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/new_design_0.jpg"
  alt="Screenshot of fourth website design"
  aspectRatio={1.825}
/>

And here's an individual cabin page:

<PostImage
  src="/assets/blog/ten-years-of-cabin-rental-website-design/new_design_1.jpg"
  alt="Screenshot of fourth website design"
  aspectRatio={1.825}
/>

I'm far from a good designer, but I'm proud of how the [new website](https://beartracklake.com) turned out.
I'm excited to monitor the analytics over the next year, and I'm excited to be able to make changes with
minimal effort going forward.

It's an interesting experience looking back at the history of a project that I've maintained for 40% of my life.
This website has had a huge impact on both my professional trajectory and my parents' business, and I'm grateful.



My journey with Linux began around my freshman year of high school. I managed to stumble into some pretty bad malware, which left my (Windows Vista) laptop unusable. After desperately trying to fix it (to no avail), I finally went to my parents defeated. We ended up going to Best Buy to see what they could do. After a quick glance, they decided the only way to fix it would be to reinstall Windows, and this would cost us ~$200. This seemed outrageous to me. My parents refused, and I went back to trying to fix it myself.

I ended up finding out about other operating systems under the Linux umbrella. I do not remember exactly where I first heard about them, but I quickly found plenty of resources. I was reading about how these operating systems were free, secure, and extremely customizable. I eventually decided to install [Ubuntu](https://www.ubuntu.com/) as it was supposedly the most user friendly out of the box. I downloaded it, installed it, and fell in love. I eventually learned how to navigate around in the terminal and read [GNU](https://www.gnu.org/) and open source [philosophy](https://www.gnu.org/philosophy/philosophy.html).

Ubuntu was my main operating system until my freshman year of college. There was nothing _wrong_ with Ubuntu, but I just wanted to try something new. I decided on [OpenSUSE](https://www.opensuse.org/), mostly because it had the reputation as the best KDE distribution. There were not any _big_ problems, but KDE would crash at least a few times everyday along with other minor annoyances. I sticked with it though until this past summer when I bought a ThinkPad.

I decided to try [Fedora](https://getfedora.org/) and fell in love. Below are the reasons that I feel set Fedora apart:

- Unmatched GNOME experience
- Perfect combination of stable and bleeding edge software
- Excellent hardware support
- `dnf` is faster (in my experience) than `apt` and `zypper`
- Only '[Free as in Freedom](https://en.wikipedia.org/wiki/Gratis_versus_libre)' software in official repos
- Feels like a complete product, rather than a hodgepodge of parts
- Fedora community is second to none

Fedora's community is an amazing resource. There have been numerous times when I was stuck, and I was able to get help quickly from both [IRC](https://fedoraproject.org/wiki/IRC) and [Reddit](https://reddit.com/r/fedora). If you are thinking of hopping distros or trying Linux for the first time, I highly recommend Fedora. We will be happy to help if you run into any difficulties.


Justin Austin