This is part one of an eight part series where I dive deeper into the concept of building passion with the intention of becoming a better software engineer.

Passion is a fundamental starting point for motivation. With all things being equal amongst eight traits for success, start with passion. The best software engineers generally love what they do. Software engineers pull from a variety of scientific disciplines and principles to design and build software. The more difficult the design constraints or the more difficult the problem, the more creative the engineer has to be to find a solution.

Finding passion to be able to love what you do as a software engineer can be very challenging. For me, I drew inspiration from Steve Wozniak while reading his book iWoz: Computer Geek to Cult Icon: How I Invented the Personal Computer, Co-Founded Apple, and Had Fun Doing It. He was the type of engineer who loved improving upon existing things and I found that quality within myself as well. Everytime I successfully improved existing software I get a really unique satisfaction that can't be replicated elsewhere in life. Everyone is very different so it is a good idea to explore many paths or try out different things until you find your calling as a software engineer.

Some really good advice that I believe in when it comes to building passion is to "follow your heart, not your wallet" and "do it for love, money comes anyways." When a person looks at the monetary value of a particular path, it's common to try to fit oneself into that path whether it be natural or unnatural. Monetary value is good when evaluating what to explore, but most of the time it's not a good idea to force it when it is clearly not meant to be.

I came across this TED talk presented by Richard St. John almost fourteen years ago and thought it was interesting. A fairly thorough guide on becoming successful and famous. I did not have the desire to become super famous or rich and thought the concepts he presented would only be applicable towards that end so I did not think to implement his advise. Fourteen years later, some years working as a software engineer, a question pops up in my mind. That question was "what do I work on if I want to become the best software engineer that I can be?" That seems straight forward at first because you can google search the latest tech trends/tricks and pluck any one out of a hat and do some tutorial course or toy project with it. Does that really make someone a better engineer though? If you take some very good engineers in the past like Kent Beck or Steve Wozniak for example, is that what characterized them? I don't think so.

From that point on I was fascinated with the internal qualities of what it means to be the best you can be. I researched and looked into many self help resources that are currently popular. I was not happy with their quality of content (or lack thereof). Then I remembered that Richard St. John gave a pretty good talk and I could not find any holes or issues with what he was recommending. I bought his book, read through it, and now I aim to present some good advice tailored specifically for software engineers and how I personally am applying them.

I will be doing an 8 part series going into each trait development more in depth.

Here is an amazon affiliate link to his book for anyone interested in reading the material. Any purchase made through that link supports this blog.

I was browsing YouTube and this video popped up as trending

I found it really cool and wish I had seen this when I was in college. The basic idea of working for 40-60 minutes and then taking a 20 minute break to watch a relaxing anime (or show) is way more appealing than the Pomodoro technique that I have been exposed to in the past. I have already implemented this productivity style for many weeks and added one modification to suit my life style. That modification was to add working out during those 20 minutes while an anime or show is playing. This is an example of my best and most productive 8 hour workday day:

1. Completed current sprint's tasks 2 days ahead of schedule
2. 100 pushups
3. 100 squats
4. 30 vertical rows
5. Full Pilates routine
6. One chapter of "Effective Engineer"

I not only was able to take care of my work, I was able to take care of my physical and health goals as well which I too often neglected in favor of saving time.

There is another idea proposed in the video, which was a concept called rough drafting. To me, that means to incrementally improve on your work, not necessarily rush to get it done. I really enjoyed applying that concept and it has allowed work and coding to not feel as stressful. I feel the best work usually comes out at the most unexpected time of inspiration and trying to force that actually leads to the opposite result.

Finally, the last concept I want to talk about, is doing at most a chapter a day in any individual educational or self-improvement book. I have so many books to read in my personal library that it becomes daunting to read all them all. I experimented with just stopping after reading a chapter in any particular book before switching to another and I ended up reading a lot more than I ever had since college. If you are interested in reading more, I recommend to give that a try.

Recently, I got a copy of the book "8 To Be Great" written by Richard St. John. I plan to read through and adapt the 8 successful traits into engineering as a guide to give inspiration to fellow engineers who are brainstorming ways to become the best engineers they can be.

I recently started reading a book written by one of my college professors back at University at Buffalo called Blockchain in Actions. It's a really well-written book. A surprising takeaway that I have so far is how she proposes her blockchain solution to her sample problem. I've decided to adapt some key concepts and fit them into my way of doing it including using a table to help make viewing easier.

Background definitions(in paragraph form):
Use case with problem statement:
Issues with how problem is currently tackled | Implications
Previous or existing attempts at solution | Pros | Cons
Proposed new solution
Benefits | Consumer | Business | Overall Community

Here is an updated version of my previous mock solutions pitch for Open Fitness Culture.

Open Fitness Culture:

The fitness industry contains a lot of products or programs that are fads or have paid promoters making exaggerated claims that over promise and under deliver in results. Old trends get recycled as new and beautiful models are used to misrepresent results to consumers. A fitness culture that is open and honest should allow people to see and verify start to end fitness journeys that would more closely match their own. Aspiring fitness enthusiasts should be able to market and monetize their own start to end fitness programs with reproducible results for people to see.

Benefits:

What I like about this modification is that it makes all the relevant information very compact and easy to navigate and it formulates upfront all the presentation information you would want if making it into a slideshow or doodle presentation.

Context: Postman is a widely used tool that is useful for API development. A Postman collection is a defined collection that allows for documenting, sharing, automated monitoring, and express complex workflows for API's and their success/failure. Postman collections are expressive enough that I believe API workflows as libraries can be encapsulated within them and be executed by an interpreter (my other project) in any environment or program.

Challenge: The way that Postman currently imports and exports collections is entirely through JSON. This is a problem because when trying to collaborate in a version controlled environment (such as git), the line diffs and changes that are being made will result in merge conflicts or garbage diffs that are hard to collaborators to review and merge together.

Current Solutions(implications):

• Upgrade to the enterprise tier of Postman product to allow separate accounts to make changes and modification of collections and be able to revert any change using Postman's history feature (does not allow a truly separate workflow for separate changes and merging of everyone's work, changes can happen without a review process)

Possible Solutions(pros/cons):

• A program that can take in Postman collection JSON and convert that into a folder directory structure with information regarding the collection. The directory structure can also hold additional metadata to allow conversion back into Postman collection JSON to be loaded into the application or be run by Newman.
  • Pros:
    • Allows easier version control diffing and team review process
    • Allows collections to be easily shared and contributed to by users who don't have an enterprise Postman account
    • Offloads Postman application's necessity to hold all the information
  • Cons:
    • A lot of work to write a program that can handle that kind of conversion process
    • If Postman ever decides to change its JSON schema regarding collections, will have to also be updated to accomodate

Solution in Progress: A Rust program that can take in Postman collection JSON and output a directory of folders and YAML files that correspond to the requests in the Postman collection. On the flip side, the program should also be able to take in a metadata file of said output directory and be able to construct an identical Postman collection JSON that can be fed back into Postman.

Business Impact:

• Consumer win:
  • Consumers would be able to maintain all the power and expressiveness that Postman encapsulates but also be able to version control the changes to collections
  • More simultaneous collaboration changes to a Postman collection can happen
• Open Source Contributor win:
  • Be able to demonstrate skill with Rust programming language
  • Potentially be involved in growing trend of unification and simplication of API usage in tech
• Everyone win:
  • Enhanced collaboration and easier documentation with API development

If you have ever ran into a code base or find yourself involved in a workflow that has a lot of code that looks like this

var result1 = Action1();
if (!result1.Success) {
  return new Error1();
}

<Action>

var result2 = Action2(result1.value);
if (!result2.Success) {
  return new Error2();
}

Then you may benefit a lot from using the concept of monads to replace that logic in your code. If you don't know what monads are, I recommend checking out this Youtube video:

What potential issues can come from the code snippet above and how can monads help? Other than being verbose, the biggest potential issue comes from reliance on runtime error checking. There is no compiler error that would pop up if a person decides to not check if either result1 or result2 were successful. Type systems in programming languages that support them are very powerful. If you are able to delegate more errors into compiler time type checks, your code can have more guarantees and highlights in places that have the potential to go wrong.

Does there exist a type system that can express code that can encounter an error and force the person using the code to catch all errors in order to pass compiler check? In most functional programming languages and in Rust, there are such type systems, and these type systems implement the concept of monads.

When you have a workflow or process comprising of multiple methods, if even one method in the process can fail, that means the overall workflow can fail.

var workflowResult = Workflow();
Console.WriteLine(workflowResult * workflowResult);

public int Workflow() {
  var something1 = DoSomethingThatAlwaysSucceeds1();
  var something2 = DoSomethingThatRandomlyFails2(something1);
  
  if (something2 == null) {
    return null;
  }
  
  var something3 = DoSomethingThatRandomlyFails3(something2);
  
  if (something3 == null) {
    return null;
  }
  return something1 + something2 + something3;
}

Without monad types existing, there is no compiler error to let the user of Workflow() method know that it can possibly fail. In this instance, the failure is represented as a null return value but there is nothing in the interface of the definition that would give hint that it can return null (documentation might be what the user has to rely on) and be vulnerable to a runtime NullException.

What would the above example look like if C# had monads like Rust? It would look like this

var workflowResult = Workflow();
match (workflowResult) {
  Succ(val) => Console.WriteLine(workflowResult * workflowResult),
  Err(e) => Console.WriteLine(e)
}

public Result<int, string> Workflow() {
  var something1 = DoSomethingThatAlwaysSucceeds1();
  return DoSomethingThatRandomlyFails2(something1).
         .AndThen(something2 => DoSomethingThatRandomlyFails3(something2))
}

public Result<int, string> DoSomethingThatRandomlyFails2(int s) {
  if (DateTime.Now.Second == s) {
    return new Err("method 2 failed");
  }
  
  return new Succ(5);
}

public Result<int, string> DoSomethingThatRandomlyFails3(int s) {
  if (DateTime.Now.Second == s) {
    return new Err("method 2 failed");
  }
  
  return new Succ(10);
}

In the above code snippet, it is abundantly clear that Workflow() method returns something that can either be the result, or the error response and the intention is that if either is not handled, the code will not compile. Looking at the signature of the two methods that randomly fail, it is clear what happens when they succeed, and what to expect when they fail.

Interestingly, a feature similar to this does exist in a dotnet nuget package in in the form of Either monad. The syntax of it however, did not seem very clear and that's why I want to create a dotnet monad library that follows more along the lines with what Haskell or Rust has.

Context: A lot of advancements have been made in terms of web API development and SDK generation for consumer to use. Documenting and sharing API using OpenAPI (OAI) and creating/generating SDK's using OAI specs has allowed a big step forward for API design and usage. Good API design and documentation is crucial for adaptation.

Challenge: Despite there existing more readable options for documenting and sharing API that have OAI specs, demonstrating how an end to end workflow using multiple API calls is still a challenge. Things get even more complicated if one is trying to document or demonstrate a workflow that involve multiple API's.

Current Solutions:

• Rely on written documentation to communicate what E2E workflows are supposed to look like to a consumer (can be a challenge to write good documentation that doesn't leave the consumer still asking questions in addition to keeping them up to date)

Possible Solutions(pros/cons):

• Use a popular framework/ecosystem for designing and testing API and write an API workflow that can include calls to multiple different API's in its workflow and write an interpreter in Rust that can utilize that representation of a workflow and be the SDK for consumer use. WebAssembly can be used to export that interpreter to various other programming languages.
  • Pros:
    • Great flexibility
    • Great performance by utilizing Rust
    • Design API workflow once, export it everywhere
  • Cons:
    • A lot of work to write an interpreter that can handle the vast scope of possible workflows and scenarios of web API's
    • Would be tied to an ecosystem that can change
• (Didn't identify alternative competing solutions from Google research)

Solution in Progress: A Rust interpreter that can take in an exported JSON representation of a Postman collection and be able to perform the actions encapsulated in that collection. Using WebAssembly System Interface, this interpreter can be utilized by various other programming languages while only maintaining one codebase.

Business Impact:

• Consumer win:
  • Would only have to maintain one source of truth Postman collection when supporting various language's SDKs
  • Less coding errors, more time spent on intuitive user interface
• Open Source Contributor win:
  • Be able to demonstrate skill with Rust programming language
  • Potentially be involved in growing trend of unification and simplication of API usage in tech
• Everyone win:
  • Greater clarity in API documentation
  • Enhanced ability to tie different API's together for better designation of responsibilities

Found this nice presentation on the problems that Rust solves as a programming language. Check it out.

Context: Modern technology has revolutionized productivity for a lot of industries. Healthcare, particularly in the physical therapy realm, still has a lot of improvements needed to empower the professional and not let paperwork and administrative work take time away from doing what's important.

Challenge: As a physical therapist, certain workflows and processes that can be automated are very tedious manual work that exponentially increases with the number of patients or the complexity of surrounding circumstance with a patient (insurance disparity, lack of documentation, etc).

Current solutions (implications):

• Work long hours outside of patient interaction schedule windows (may lead to burnout)
• Schedule tedious administrative work to be done within patient interaction schedule or business hours (less chance of burnout, opportunity cost)

Possible solutions (pros/cons):

• All encompassing PT software suite solution built from ground up
  • Pro:
    • Most customizable and streamline options can be tailor made
  • Con:
    • Expensive, time consuming to make, not generic enough to help all health professionals
    • Hard to get approval from upper management on big software shift
• Individual programs for incrementally improving each step of a physical therapist's workflow
  • Pro:
    • Easier to develop
    • More chance of individual solutions for a smaller workflow being applicable to more physical therapists
    • Requires less leap of faith
  • Con:
    • Not a one stop shop solution from the ground up

Solution chosen (why)

• Individual programs for incrementally improving each step of a physical therapist's workflow (it is the fastest way to get quick workflow enhancement out with maximum impact)

Business impact

• Consumer win:
  • Less time and work requirement for PT to see increasing number of patients
  • Reduce possibility of PT burnout
• Business win:
  • Able to implement complete end to end workflow of creating technological solution from inception, design, to implementation and support
  • Add to portfolio for resume
  • Enhance skills in using new and latest technology stack
• Everyone win:
  • Enhance and bring light to possibilities on productivity enhancing technologies for healthcare workers
  • More efficient processes for patients

What does it mean to be an engineer? What does it mean to be a craftsman?

Engineering to me is the ability to come up with solutions to problems using a combination of technology, science, math, and many other disciplines. A stronger engineer can come up with a good solution where a lesser engineer couldn't. Craftsmanship to me is the mindset to think long term in terms of a product or craft and always trying to get better and better outcome of a product's life. A stronger craftsman will create products that are way more usable, stable, and effective than products created by a lesser craftsman. The phrase "the desire to do a job well for its own sake" is a good way to describe it.

I think it's healthy for a software developer to try to improve and embody what it means to be an engineer and a craftsman in their career. Take a proactive approach. As an engineer try to push the boundaries on what's possible and coming up with solutions to problems yet dreamed of. Maybe set aside time, or whenever you find yourself having downtime, to just brainstorm and dream with your users on what's possible and how you can push the boundaries on existing solutions. As a software craftsman try to refine what you have done in the past and see what can be improved upon for the sake of exploring how to make something more usable, stable, and effective. Have the desire to do a job better or increase your ability to do so for its own sake. Don't just be reactive as an engineer, take proactive steps to bring something new to the table.

These important attributes are huge reasons why I don't think companies should overburden their employees with things like performance metrics or time tracking to squeeze every drop of productivity out of their engineers. When an employee experiences those kind of confines, you lose a mindset of creativity and excellence that is probably the most valuable asset in the tech industry. No one ever said "Apple squeezed so much labor efficiently out of their engineers so that's why their phones don't seem to crash" or "Windows phone failed because they missed out on productivity from their engineers."

Have you ever wanted to improve on something or strive to better yourself but you're not sure in what aspect or way and you search up what other people are doing to get inspiration? Have you ever been curious as to the learning path some people took to get at the skill level or expertise that they currently are at? I've definitely had a lot of moments like these and I'm sure I'm not the only one.

I was designing a custom solution to conveniently track and record my progress in different goals (I wrote more about my recommended progress philosophy here). It was going to be a personal app that would allow me to add weekly focus/tasks under different categories of goals to work on and as the weeks go by that history will be logged for the purpose of giving someone else a path to follow. I then started to wonder "what if you can see your friends doing the same thing?" I felt like that can be very inspiring.

Imagine a group of friends who are getting into running. If any one of them is curious as to the weekly progress everyone made or what they are up to, or what specific routines they are doing to get better, it can somewhat be a hassle. You might have to do a weekly check up, maybe through texting or some kind of messenger app but it would be nice to just have a clear view of what everyone felt like sharing each week on what they did to progress their goals.

Strava is an app that I've used before where cyclists and runners can highlight routes on a map for others to see and challenge each other. A user can get a birds eye view to see who has ridden which segments on the map, recorded time, fastest speeds, etc. A user is also able to track and record all of the segments they rode and their times for others to view as well. It is a great example of what I'm thinking of except that the social media platform I want to establish isn't solely focused on outdoor running/cycling but can be used to make progress for any goal.

Why can't any of the currently existing social media platforms such as Facebook, Twitter, Instagram, etc, fulfill my requirements? They simply show too much, do too much, and try to engage too much. I don't want a nonstop feed of random information, no matter how well the algorithm predicted that I would like it. I just want laid out information on how my friends shared their progress on improving themselves. I want to see how renowned experts advanced their knowledge in some way or what specific concepts my jiu-jitsu friends are focusing on. Most social media platforms are designed to waste time but this one that I have in mind is designed to make people get off it once they get on, because they see all the people making progress on their goals and not wasting time on social media.

This is just the rough draft on the idea I would like to make happen. I will formulate it as an engineering proposal in my next post.

One of the most valuable learning experiences I ever had in my life was during my Gracie ICP certification training. I learned that how you frame a question for a lesson made a huge impact on whether your students would ever absorb the material. It made so much sense that I could not help but to adopt it for software engineering and communicating problems and solutions. I would like to share a useful format that I've started to refine since going through the Gracie ICP in the hopes that other engineers can find it useful.

Context:
Challenge:
Current workflow (implication):
Possible solutions (pros/cons):
Solution created:
Business impact:

This is actually a format that I use when I'm thinking of or presenting a hackathon project or proposing a creative solution to a current problem. A key presentation detail that isn't very obvious is that the language and terminology used to outline everything should be understandable by the lowest common denominator of your audience, which can possibly include the lay person outside of tech. This is to minimize the barrier to entry for the audience to understanding what you are trying to communicate. Here is a fleshed out example.

Open Fitness Culture

Context: The fitness industry contains a lot of products that are fads or have paid promoters making exaggerated claims that over promise and under deliver in results. Old trends get recycled as new and beautiful models are used to misrepresent results to the population.

Challenge: As a consumer, it is exceedingly difficult to determine how effective an exercise program would be for you since you are unable to determine if the testimonials are real. This can be a problem because not only do you not know if the testimonials you see are real, but you may have the wrong impression about what your progress would look like compared to what they actually would be in reality. These issues often times cause people to quit out of frustration and not having the right expectations.

Current solutions(implications):

• Just tell people to suck it up and believe and achieve (if people quit it's their fault).

Possible solutions (pros/cons):

• Make real people video vlog their everyday journey with the program
  • Pro:
    • adds relatibility
    • good story
    • definitive proof
  • Con:
    • hard to get people to do
    • hard to consume
• Gather up written testimonials with before and after pics
  • Pro:
    • easy to do
    • easy to read if you can trust the testimonial
  • Con:
    • issue of paid testimonial
    • no substantial material on expected progress
• Make a video live streaming service that is specifically intended to live stream workout programs and people's everyday participation in them. Use those live stream and recordings to be proof of the workouts, before and after transformation between dates to be the expected results, and the workout participant to be the example for other people like him/her.
  • Pro:
    • Allows optimal relatability as consumer can look at live or recorded live journey of someone with similar attributes as him/her.
    • Definitive proof due to the live streaming nature of the workouts and gives a reproducible schedule.
    • Allows the best set up of expectation of progress since someone with matching attributes is used as an example benchmark for your current rate of progress.
    • Allows new comers to create workout programs that can be repeated and reproduced with results of various people to either validate or discredit a workout program.
  • Con:
    • Requires significant infrastructure and engineering work.
    • Might be hard to get people to do

Solution created: Live streaming platform specifically intended for working out with features of monetizing workout programs through advertisement and paid sponsorships. Features quick filtering by results, timeframe, level of fitness, and body weight/height.

Business impact:

• Consumer win:
  • Get a potentially infinite number of workout programs with results viewable by people just like them who have tried the programs before them.
  • New trainers who want to make a niche or who have unique programs to offer have a platform to show the proof as to their effectiveness.
  • Maximize the benefits of being held accountable for working out and being examples for future workout people
• Business win:
  • Carve out niche market in the health tech industry by being a pioneer
  • Great platform for sponsorship and advertisement
  • Ability to branch out to other fields/discipline where consistent practice and reproducible programs would be valuable
• Everyone win:
  • Expanding what's possible with new emerging ways to use technology
  • Good platform for people to make friends and share ideas with each other

From this example you can see, that I used very little tech terminology, not only because it wasn't necessary to imagine what was possible, but because it is not relevant to the people I would be pitching this tech solution to. In fact, I would venture a guess that a lot of your interactions as an engineer could go even better if you refrain from relying on tech specific terminology.

When I started to train Gracie Jiu-Jitsu and Judo, and after I learned the fundamentals and started to execute them proficiently, I thought the biggest impact I could make to my martial arts career was to dive deeper and deeper into more advanced and situational techniques so that way I can display my prowess and my experience. What I realize now is that it's my communication skills that would make the biggest impact on my martial arts career. Software engineering is not that different. It can be super tempting to only want to dive deeper and deeper in tech, to show off, but sometimes it's good to keep in mind that no one cares about you. They care what you can do for them and your communication skills are your most valuable asset when you want to show what you can do for people.

I like paradigms or helpful simple guidelines that can be applied to many things in life. The more things a simple guideline can be applicable to, the closer it is to being a unifying theory. Simple guidelines and advice are easier to remember and way easier to teach the next generation. Here is probably my most meaningful and simple advice that I could ever give to my future generations.

"Make a meaningful advancement in your self development every week" - Hank Lin

There are so many things in life that a person can work on. Some people would like to conquer their fears, others want to learn a new skill, however way a person can define his/her goal I highly recommend trying to make progress on that self improvement goal every week.

Why do I say every week? Why not say every day, or month, or year? I say every week because that's what has been universally applicable to me personally in so many endeavors in life. I noticed that trying to rush to improve literally everyday gets boring and repetitive, and making progress once a month is just not satisfying. I utilized this principle for many different categories of skills that I acquired. Body weight training, Gracie Jiu-Jitsu, cooking, using vim, and software engineering.

Here is a way to learn that I and many people find to be very natural in terms of expanding your skillset or broadening your horizon. I call this the flashcard method. You create a bunch of flashcards for something new you want to try in a particular skillset, and you focus on that new thing for a week. You apply that new skill, technique, or concept whenever you get the chance. The body and mind takes time to improve and adapt/adjust and similar to how most people will not see improvement from their workout until the week after recovery, you might find yourself taking a week to improve on that flashcard you were focusing on. After you spend that week working on that flashcard you shuffle that flashcard into the pile of flashcards you've already worked on and you take another from the new deck. Periodically you should revisit the old pile of previously worked on flashcards and maybe focus on one of the old ones for a week or just quickly review each in rapid fire depending on how comfortable you are with what's in the old pile.

Take something that is not an abstract skillset, maybe something involving emotional maturity such as communication skills or relationship health. This flashcard method, once a week progress goal worked tremendously well for me in that regard too and I see myself doing the same for when I have a kid in the future.

To some people, improving once a week doesn't sound impressive but I want to help you think through how impressive it actually is. Imagine if a person learning Gracie Jiu-Jitsu, going 2X a week, and making significant improvement after each week no matter what the topic of the week was, that person would be a monster after a year. If a person focused a week using 'hjkl' keys in vim instead of the arrow keys, and then next week focused on utilizing q macros, they would be already ahead of 90% of the population in terms of effective use. If you have a parent who has anger issues and that parent spent a week focused on not being bothered by 1 particular thing, then another week on taming the anger on another thing, etc. After a year that parent will have 52 anger pain points that they made progress on, or 1 primary anger issue reduced by a small amount 52 times.

Consistency will always win over monumental effort in the long run

Following this guide to get a handle on Rust and how it looks to create WebAssembly that can work on the browser. First thing that went wrong was needing to upgrade NodeJS because npm apparently required a newer version of NodeJS on my Windows machine all of a sudden. So after upgrading to Node v12, I then found out that git wasn't recognized in powershell so the command to clone a git repo to initialize an npm project with the command npm init wasm-app www wasn't working. I wish Windows would have the foresight to install git on machines, it's just extra hassle and work that makes me feel Windows development environment isn't aligned with what normal developers would work with.

Going through the tutorial to make Conway's game of life was really awesome. There does not exist a ton of stuff to make it look great yet but it was just so cool seeing how it all worked together and seeing live changes happen from manipulating Rust code to convert to WebAssembly. I might go through different projects that I've completed before in other frameworks/languages and use this Rust/WebAssembly setup and try it out. I eventually want to move onto the Gameboy emulator that was written in Rust/WebAssembly.

The first 5 exercises focus on command line input and output. I most likely will add more exercises under the category for input and output in the future. This was to get me familiar with coding in Rust.

I found it interesting that it is so hard to move away from Visual Studio in Windows. Even when I am not programming in .Net and programming in Rust I have to download Visual Studio Build Tools. I received this error when trying to compile my saying_hello.rs program without it installed.

error: linker `link.exe` not found
  |
  = note: The system cannot find the file specified. (os error 2)

note: the msvc targets depend on the msvc linker but `link.exe` was not found

note: please ensure that VS 2013, VS 2015, VS 2017 or VS 2019 was installed with the Visual C++ option

Luckily somebody else has encountered the same issue as me before. Just had to follow the instructions to download the C++ build tools through the Visual Studio Installer. Setting up the environment for Rust development was way way faster in Ubuntu than Windows so far from what I'm seeing.

I also decided to use IntelliJ as my IDE. I used to be more of a TMUX/NEOVIM guy but since I have to work on multiple machines and OS's it's easier to have the same IDE with the right configuration up. IdeaVim plugin along with Relative Line Number plugins have been working well enough for me. Definitely had to disable IntelliJ's version control setup though as I still prefer to work with Git through git bash.

As far as coding, it was fairly straightforward definitely a good intro set of problems for someone trying out a new language. Next up is learning to use the language for doing calculations.