My favorite code editors over the years

I am excited to finally share my first blog post this year! This one tells my journey of programming through the lens of the various code editors that I have used. I always find it quite interesting to learn about how other people work and if I can learn something from them to improve how I work. Since everyone’s preferences are quite subjective, the answer to the question “What is the best code editor?” is also very subjective. Regardless, I would like to share the various code editors that I have used over the years and the reasons why I liked them at the time. If you happen to be looking to try a new code editor, I hope that maybe my thoughts and experiences can help shape your decision. But more than anything, I think this will be a fun trip down memory lane, and maybe you can also relate to my journey too!

Microsoft Notepad

While I started my programming journey using a drag and drop interface to program my Lego robot, my first time writing lines of code was when I was in middle school. I was taking a computer class at school, and our final project was to make a website. It was a simple static HTML website, and I wrote it using Microsoft Notepad. For my experience level, it offered something familiar and easy to use with zero bells and whistles. I wrote this at the end of 2010 and being a San Francisco Giants fan, I was excited to make the content of my website about the Giants winning the World Series.

Spyder

Fast forward to high school in 2015, I was taking a Python programming class. Looking at the Python release dates, I think I was using Python 3.4. This was my first time writing any Python code, and I wrote my code in Spyder. I did not use many of its features aside from the integrated “run” button to test my code. My programs were simple and contained in one file as I was just learning basic control flow. For my final project, I wrote this tic-tac-toe game with Turtle graphics. As I was taking a screenshot for this blog post, it was fun to discover that my program still works well – just like when I wrote it!

IntelliJ IDEA

The next year, I went to college to study computer science. My first class was object-oriented programming in Java, and I used IntelliJ IDEA to write my code. I really enjoyed using IntelliJ IDEA as it had a lot of features that made it easy for a beginner to write Java code. My favorite features included autocompletion, squiggly lines if you wrote something wrong, suggestions for following best practices, the ability to click on objects to see where they were defined, the code refactor tool that automatically renamed all instances of an object across multiple files, and a handful of keyboard shortcuts. My favorite keyboard shortcut was sout which was converted to System.out.println(“”).

Adobe Brackets

Additionally, when I was in college, I started attending hackathons. It felt cool to go to these events to try to learn something new, build a cool application, and demo it to the various judges. And it was always exciting to get a bunch of free stuff too! In my first hackathons, I mostly focused on front-end web development. With no prior web development experience, I started using Adobe Brackets since I liked using other Adobe applications. My favorite feature in Adobe Brackets was its live preview button which allowed you to see changes on your website as you made them without reloading the page.

Vim

In my second semester of college, I took a class for programming in C. Unlike Java which was easy to install on my personal computer to do the school assignments, my programming in C course was set up to use the lab computers. The lab computers ran a custom version of Linux, and we were able to SSH into the lab machines from our own computer if we needed to work away from the lab. Since I was working over SSH, I used Vim to write my code. Even though Vim did not have all the cool features of a full featured IDE, I was still able to do my work well enough. And since everyone else in the class worked on their code in a similar manner, I did not experiment with other ways of working. While I do not use Vim for working on large projects anymore, I am glad that I was introduced to it as I still use it often to quickly modify configuration files.

PyCharm

Eventually I started writing more Python for my own projects, hackathons, and then my summer job. Since I had really enjoyed using IntelliJ IDEA for Java, I started using Jetbrains’ Python IDE, PyCharm. As I started using PyCharm, I realized that it had all the same features I liked in IntelliJ for Java, so I was happy with my choice. Thus, I did not bother to compare it to Spyder which I had used before.

Atom

Also, I started using Atom over Adobe Brackets for a general-purpose editor since it had the ability to render Markdown, it had a user-friendly interface where you could drag and drop to easily rearrange the tabs, and I felt like it had nicer code highlighting too. Since Atom was being advertised by GitHub as part of the student developer pack, it seemed like there was a bigger community using Atom compared to using Brackets. Aside from providing a good code editing experience, my favorite feature of Atom was its built-in dark color theme. And while I do not use Atom anymore, I still liked the Atom’s dark color theme so much that I still install it in all my code editors now.

VS Code

After college, I wanted to do more web development projects on my own including making this website, and I felt like the language support for JavaScript in Atom was not as good as the support for Java or Python in the respective JetBrains’ products. While I could have switched to another JetBrains’ product, I thought I should use a free tool before paying for something since I did not think I was very good at JavaScript anyway. With these points in mind, I decided to try using VS Code. Similar to Atom, I liked the endless customizability of VS Code including the ability to easily modify the settings or keymaps in JSON. And since the community was larger, I could install extensions for just about anything. Lastly, I felt happy with the long-term prospects of using this editor because Microsoft was the publisher of both the editor and the JavaScript language plugin.

In my first job after college, it was the first time that I had to contribute to and continually maintain a shared codebase. Up until this point, I had just relied on my code editor to give me suggestions for coding best practices I should follow; however, I quickly learned that not everyone used the same code editor or even bothered following the suggestions. This experience was frustrating and made enforcing any code standards hard. Soon, I learned about various open-source tools to run code formatting checks in the CI which we could require the contributor to pass before you could merge your pull request. While I still liked using the Jetbrains’ IDEs for the host of other features, it at least opened me to the possibility of trying a different code editor since I did not need to rely on my IDE for what code suggestions I should make.

In 2021, docker based development environments were becoming popular. I really enjoyed using Gitpod because I could define exactly how the development environment could be set up with all the dependencies for a project pre-installed. Unlike many web-based editors of the past, Gitpod basically ran a full featured version of VS Code. Because of this, I started using VS Code with Gitpod as a general code editor for my personal projects especially when I did not feel like setting up a local environment for it. And if I only worked on a project periodically, it was easy to forget how to set it up. Thus, the VS Code settings and Gitpod config allowed me to automate the process of setting up a project. Overall, I found that this helped reduce friction, and I was more likely to work on a personal project if I did not have to remember how to set up a project again. Additionally, the dev container specification (which was well integrated with VS Code) was great if you wanted a locally built docker based development environment.

Around the same time, the popularity of Rust programming language was growing, and a lot of people started writing developer tools with it. I was very excited because there was this new Python linter and formatter called Ruff which was written in Rust. It was 10 to 100 times faster than the equivalent tools it replaced including Black, Flake8, isort, and more. Since it was so fast, it made it easy to continually have well formatted and linted code using the Ruff VS Code extension. Thus, my feedback loop was quicker because I did not have to wait until I was ready to make a commit to have pre-commit run the formatting and linting checks. While I had previously preferred using PyCharm to do more serious work since I felt its autocompletion was better, always having well formatted code in VS Code was worth the switch.

AI Coding Tools

Today, the popularity of AI coding tools using large language models is quite mainstream with tools like OpenAI Codex, GitHub Copilot, and Claude Code. It is exciting to see these changes and how it is changing the way many developers are writing code. Currently, I have been using the GitHub Copilot as an extension in both VS Code and the Jetbrains’ IDEs, and it offers nice code predictions outside of the typical language support of the code editor. But aside from just code predictions, many AI coding tools can write code to complete a task described in natural language. For example, I can now assign GitHub Copilot (just like assigning any other engineer) to work on a GitHub issue, and it will work on its own and open a pull request with its changes when it is ready for review.

Overall, it looks like the future is bright for the evolution of code editors or whatever other tool we might use to contribute code changes. And whatever it is, I’ll be looking forward to seeing how future tools help developers work faster and more efficiently!