|
|||
|
[Home]
[About]
[Projects]
[Blog]
[Photos]
|
|||
|
Why I Built This Site 2026-03-29 I would imagine most people start a website because they feel they have something important to share with the world. I'm not totally sure if I have anything important to share, maybe just critical thoughts about other engineers. I certainly have a lot of hobbies that I feel are fun, so I assume someone else out there probably may find enjoyment in seeing what I'm up to, but I'm not an artist, I'm an engineer. So naturally the main reason I built this website centers around why I designed it to look this way. Engineering and maybe society in general have gotten it all wrong, it's unimpressive (to me) to build the most complex system you can build. Anyone can design something that includes 10,000 components, has 100,000 functionalities and doesn't really make much sense to anyone unless you spend hours 'learning it'. We hear that phrase constantly in the workforce or in our day to day lives, everyone is always 'learning' a new software or system. The fact that this is acceptable lets engineers off the hook too easily. It should not be acceptable that the way in which we interface with the world requires immense amount of education on any single way of evaluating it. Websites shouldn't take long periods of time to render, shouldn't collect thousands of data points off of you and spam you with advertisements to the point that the site barely functions. Applications shouldn't require you to explore and 'find' new features all of the time, things should just work. While it's easier said than done and it goes without saying that the functionality my website requires is incredibly simple, I built my website to really satisfy this belief I have that quality engineering is centered in simplicity. Simplicity isn't just how quality engineering has historically been practiced, it's the definition of it. When we think about some of the most important and complex engineering solutions ever, we see a long track record of intentional, thoughtful and clever engineering. In the American context, one of the greatest engineering feats is landing on the moon, specifically the spaceship known as Apollo 11. Apollo 11's central computer was called the Apollo Guidance Computer (AGC), if you were to attempt to run a website on this computer, you would've thought this thing was a hunk of junk. The AGC had 32 kilobytes (KB) of random access memory (abbreviated to RAM, which measures a computers ability to remember things on it that happened recently), and the internal processor ran at 2.048 megahertz (abbreviated to MHz, which measures essentially how fast a processor is)[1]. If none of that means anything to you in itself that's fine, but lets compare it to that of the iPhone 17, the iPhone 17 has 8 gigabytes (GB) of RAM and the processor runs at 4260 Megahertz (MHz)[2], the modern iPhone has roughly 24,999,900% more RAM and 207,900% faster clock speed than the central computer of the spaceship that landed on the moon. You might argue that the iPhone just does more than the spaceship did, the spaceship had a specific purpose, the iPhone needs to do several things. Let's look at what the AGC actually did, the most important action, and computationally complex requirement the AGC needed to get right was actually calculate the trajectory to the moon. The astronauts on board certainly did a lot, but it in fact was the AGC that calculated how to get there. On top of that, the AGC needed to interact with over 100 devices and sensors that were onboard the spaceship. The AGC also was able to monitor and assist with solving for hardware failures across the entirety of the ship. The AGC was able to do this with the amount of compute that probably can't run a modern website. Engineers have been arguing this for decades, one of the most famous examples of this is the Unix Philosophy. Unix, for those who may not know, is the precursor to the modern Operating System (abbreviated as OS, the software that computers use to function), though it predates many modern OSes, its influence is everywhere - Linux, MacOS, Android all trace their roots to it. Unix Philosophy was derived by the developers of Unix during their time developing the OS. In 1994, the Unix Philosophy was distilled to three core tenets: 1. Programs should do one thing, and do it well 2. Write programs to work together 3. Programs should handle text streams, because this is the universal interface[3] These tenets defined how software should be built in their minds. The common theme across these three tenets are the ideas of simple and intentional design choices in software. We see intentionality in the third tenet, they were thinking seriously about how their application will be used by the world around it. At that time, the main interface across all applications was text streams, so they believed that their software should be able to integrate with its environment. The developers of Unix believed that they should be producing thoughtful software, that was designed for the world around it, not assume the world will make itself work for their software. We see simplicity being valued in the first two tenets. In short, each component of your application should do one thing, do it well, and should be able to work with other programs. What we see a lot in the engineering world is people attempting to solve all problems or build something that is beyond robust that can support any and all use cases. This pattern amongst engineers is what leads to systems that require months of training just to be able to administer them. Unix is a perfect counter example to this, there are people who continue to build upon Unix, but you don't have people who build upon Unix at every company. If you think of applications like Salesforce, ServiceNow, or SAP, these are monolithic, highly configurable and complicated products, every company who uses these products has a team or teams administering them. Applications such as these violate these two tenets by not being purpose built (they ask of you that you build them for your purpose) and they often require you to structure your processes around them, in other words, they don't work well with other programs. These applications are incredibly complicated, not intentionally built and due to this, require significant resources from their consumers simply to use the product. So here's why you are looking at monochromatic website interface from 1996... Every decision on this site was made with the same question in mind, what is the least I can do to give someone exactly what they came for? This website has five pages, of the five pages, only three really have any functionality to speak of, filters so content can be curated for a specific interest. Each of the filters work the exact same way, they are basically in the exact same spot on each page, and they are bare bones HTML dropdowns with JavaScript doing the 'heavy lifting' of updating the webpage's content. My reasoning here is that if someone happens to stumble upon this page, I shouldn't be so presumptuous to assume that they will spend more than a moment or two on this website. Therefore, the truly elegant way of engineering this website is to make it as simple as possible so that a user can glean as much content in as minimalist a way as possible. To me, thinking this way is what makes truly interesting solutions to engineering problems. I easily could've built something that demonstrated how capable I am as an engineer. Instead I built something that demonstrates what I actually believe good engineering is. The difference is the whole point. [1] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer [2] https://en.wikipedia.org/wiki/Apple_A19 [3] Salus, Peter H. A Quarter Century of Unix. Addison-Wesley, 1994. << Back to all posts |
|||
|
© 2026 Emanuel Eagle — All opinions are my own and do not represent my employer. |
|||