Updates

mock-db.json

@@ -5,6 +5,18 @@
       "subtitle": "My first blog post!",
       "html": "<div><p>Hello!</p><p>Welcome to my website. As my first blog post, I'd like to take some time to introduce myself and explain what my intentions for this website are.</p><p></p><h5>A little about myself</h5><p>When I was a senior in high school, I was torn between majoring in music and computer science. I'd been playing piano since I was about 3 years old and I had never programmed before. However, as much as I liked piano, I had doubts about a career in piano performance. Playing complex classical pieces in front of a large audience is stressful! Plus, while classical music is cool, it's not really the kind of music I like to listen to (although I do enjoy a good&nbsp;<a href=\"https://www.youtube.com/watch?v=NzCL9uLkQSI\" title=\"winter in F minor\">Winter in F minor</a>&nbsp;on the occasion). So I decided to declare myself a major in computer science with a minor in music.</p><p>I dropped the music minor after my first semester, figuring that I can learn at my own pace by myself instead of having to worry about being graded for it, and swapped it for a math minor.</p><p>Programming was awkward at first. I had a lot of questions like: why is there more than one language and why don't my programs have user interfaces. Since then, my knowledge has matured so that I now ask questions like: how do I pick a language and why don't my programs have good user interfaces.</p><p></p><h5>My goal for this website</h5><p>As you may or may not have guessed, I am not the most experienced software developer. But that's okay! At the time of writing this blog post, I've been working full-time for a year and, although the novelty has worn off a little, my curiosity towards about my field is only growing more intense. I plan for my blog posts to<em> mostly</em>&nbsp;be about things I've learned or things I'm currently learning about computer science and software development. When I explain a concept, I want to explain it in the most understandable way as possible, that way my friends and family that aren't familiar with programming can follow along, and for me to practice communicating complicated concepts in a straightforward manner. I also want to start doing solo projects and post them here as/once I build them.</p><p></p><p>That's all! Nothing too lengthy this time, but I can't promise that for later posts...</p></div>",
       "date": "Mon Jun 12 2023"
+    },
+    {
+      "title": "How to Develop Opinions as a Software Engineer",
+      "subtitle": "My thoughts after a year of full-time programming",
+      "html": "<div><p>Having been full time at my job for a little over a year now, I feel like I have a fairly good grasp of what I am doing and how that relates to the work of the programmers around me. However, something I feel I am still getting a handle on is developing my own well thought out opinions towards the tools that I am using and the courses of action I am taking to solve the problems I face. The people I work with are very smart and talented  and being opinionated comes as a part of that. When it comes to programming, not having an opinion can get you stuck when choosing from the many different languages, frameworks, and libraries  that can all solve the same problem. I also think that having an opinion gives people confidence that you can carry out the task at hand. No opinion should be held so tightly that all other perspectives become unworthy of hearing, but, overall, it is better to have an opinion than just float aimlessly in the sea of endless programming tools that all promise to take away your programming woes.</p><p>In light of this, the question that naturally arises is: how do I develop these opinions? I am not someone that would be considered a naturally opinionated person, so I've have to put some thought into this. Below are some considerations that I've thought up to help me develop my own perspectives, hopefully you will find them interesting and/or useful.</p><p></p><h5>Consider the user</h5><p>Software exists to serve the user. It only makes sense then that the user be taken into consideration when writing it. It would be easy to leave this point as \"make the program as easy for the user as possible\" and call it a day. But I think there is more nuance than that.</p><p>As I grow in experience, I am beginning to sense a trade off that can pop up when writing programs. The simpler a software is for the user, the more complex it is to write, and the more complex it is for the user, the easier it is to write. Programs serve as a medium that allow users to harness the full power of modern day computing. If a program is simple, that implies that a lot of decisions are made behind the scenes by the programmer that the user doesn't have to think about. The decisions rest on the programmer, who has to take the time to consider what the user probably<em> </em>wants, thereby making the writing process more complex. Alternatively, if the user is given more decision making power, that lets the programmer handle less of the technicalities.</p><p>Pretend we're writing a program that bakes cakes (don't ask questions). The program is given a recipe as input, takes the ingredients available in the kitchen, and outputs a cake. One problem I see us running into when writing this is: If the recipe calls for dark chocolate, but only milk chocolate is available, do you ask the user what do to, just use the milk chocolate, or throw an error and refuse to bake the cake? If we ask the user what to do, then they can't complain if the end result doesn't taste exactly like what they wanted. Otherwise, it's on us to handle this problem. If don't handle it correctly, then people won't like our program, and that will make us sad. Nobody likes to be sad.</p><p>Answering the question of whether or not to put a burden of technical knowledge of how our program works on the user is based on whether or not we've set out to write a technical program, or a user-friendly one. This presupposition should guide our opinions on how to develop the program going forward. Particularly in what decisions we make behind the scenes.</p><h5>Consider the time</h5><h5>Consider the need</h5><h5>Consider the future</h5><p></p></div>",
+      "date": "Sat Aug 05 2023"
+    },
+    {
+      "title": "UX Considerations",
+      "subtitle": "One rule of thumb for creating applications that provide a postive user experience.",
+      "html": "<div><p>When I was in college, programming assignments were usually \"here's a complicated problem, go try to solve it and let us know how it goes\". I really liked these kinds of problems. However, now that I've been in an actual software developer position for a while, with most of my time spent working on interactive web applications, I've learned that good software development isn't typically centered around \"write a super cool, super fast algorithm that can run on a coffee maker and also solves world hunger\", but is actually centered around providing the best user experience possible for the user. (Yes, I am aware that in hindsight this is kind of obvious).</p><p></p><h5>How is a good user experience crafted?</h5><p>To illustrate the thought process behind UX development, I'd like to provide a recent example from my job. We are currently in the process of implementing search functionality for our custom content management system. Since most of my experience is related to front end development, I was participating in a meeting related to designing the search bar.</p><p>One of the problems we have to solve is: when a user searches for content, how and when do we provide results that we don't already have cached in the web page? We don't want to query the server each time the user types, since that would unnecessarily bog down the server with requests. We decided that while the user is still typing we'll limit the search results to be the top level data we already have on the client.</p><p>Now the question becomes: when do we send the query to the server to get all of the detailed results? Should we debounce the search bar (i.e. wait until the user has stopped typing for a second or two and then automatically query the server)? Or should we only send the query after the user takes a specific action (i.e. presses the <code>Enter</code> key in the search bar)? I was initially in favor of debouncing the search bar over waiting for an <code>Enter</code> key press since I didn't see how we could rely on the user knowing to press the <code>Enter</code> key after they've already been provided with the limited set of results. What if they assumed that the limited results set was actually the full result set? Our project lead made a subsequent comment that I think illustrates an experienced UX oriented though process. He said that they probably wouldn't automatically know to press the <code>Enter</code>&nbsp;key to get full search results, but if we provide a button along side the search bar that is colored to draw in the user's attention (a <code>\"btn btn-primary\"</code>&nbsp;for those familiar with Bootstrap) then that visually indicates that there is some extra action to be taken when searching. The button can even be so obvious as to have the text \"Full Results\" or something similar.</p><p></p><h5>Takeaways</h5><p>I think the  lesson learned from this experience is this: Generally speaking, every action that a user can take in a user interface should reveal itself visually. An action may be hidden behind a dropdown, popup, or until after some parent action is taken, but they should be visually discoverable by the user. Adding a button that performs some action feels like a small thing to do, but it is often the case that buttons used in well thought out applications have been, in fact, well thought out. Having been working in software for over a year now, I have created and destroyed countless buttons from the web pages I have worked on. Moving forward, as I continue to created and destroy more buttons, I want to be sure to be intentional in considering the utility behind choosing whether or not to add one. Humans' sense of sight is naturally the one they lean on the most to navigate the world, so it makes sense that they should be able to do so with our applications as well.</p></div>",
+      "date": "Fri Nov 17 2023"
     }
   ],
   "projects": [

rss.xml

@@ -4,7 +4,7 @@
         <title>David Garcia</title>
         <link>https://joegar000.github.io/davidgarcia/</link>
         <description>The personal blog of David Garcia</description>
-        <lastBuildDate>Sun, 25 Jun 2023 22:43:31 GMT</lastBuildDate>
+        <lastBuildDate>Fri, 17 Nov 2023 23:33:31 GMT</lastBuildDate>
         <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
         <generator>https://github.com/jpmonette/feed</generator>
         <copyright>David Garcia</copyright>
@@ -15,5 +15,19 @@
             <pubDate>Mon, 12 Jun 2023 05:00:00 GMT</pubDate>
             <description><![CDATA[My first blog post!]]></description>
         </item>
+        <item>
+            <title><![CDATA[How to Develop Opinions as a Software Engineer]]></title>
+            <link>https://joegar000.github.io/davidgarcia/#/blog/2</link>
+            <guid>https://joegar000.github.io/davidgarcia/#/blog/2</guid>
+            <pubDate>Sat, 05 Aug 2023 05:00:00 GMT</pubDate>
+            <description><![CDATA[My thoughts after a year of full-time programming]]></description>
+        </item>
+        <item>
+            <title><![CDATA[UX Considerations]]></title>
+            <link>https://joegar000.github.io/davidgarcia/#/blog/3</link>
+            <guid>https://joegar000.github.io/davidgarcia/#/blog/3</guid>
+            <pubDate>Fri, 17 Nov 2023 06:00:00 GMT</pubDate>
+            <description><![CDATA[One rule of thumb for creating applications that provide a postive user experience.]]></description>
+        </item>
     </channel>
 </rss>