Software Engineering Soft Skills: How To Receive Feedback

When a good Software Developer is called out on an actual mistake or subpar performance, they immediately say "Thank you for your feedback!", they own up to their error by apologizing, they do some introspection to understand how they failed and empathetically become aware of the impact their mistake/subpar-performance had on their customers and team, they genuinely ask for help if needed to understand how they could do better, and they resolve to improve.

When a bad Software Developer is called out on an actual mistake or subpar performance, they immediately get angry and defensive while seeing feedback providers as the "enemy", they avoid owning up to their error by making lame excuses and lying about the situation, they express apathy towards understanding how they failed, selfish lack of empathy, and lack of interest in becoming aware of the impact of their mistake/subpar-performance on their customers and team, they think they are above the need for help, and they do not put any effort into improving.

Remember that giving people honest unfiltered feedback after they made a mistake is the nicest most loving thing one could do for them as it helps them become aware of whether they need to improve or they are on the right track. Feedback has the positive intention of helping someone improve regardless of whether it is negative or not. When people discourage honest feedback or want filtering of it (like adding an emotionally insincere "positive" tone), they end up stagnating in mediocrity and never improving because they never get the full impact of their mistakes on their customers and team. 

I never trust anyone who doesn't immediately say the equivalent of "thank you" and shows genuine concern when receiving feedback, whether harsh or not. In fact, that is the biggest difference maker between top performers and average performers is that top performers will accept any sincere feedback no matter how harsh it might be, so they end up improving many times over average performers. That is also the difference between how mature adults and children handle feedback. Children cannot accept any feedback, which is why parents 'baby-talk' them. On the other hand, mature adults can accept the truth in any way, shape, or tone. If someone needs 'baby-talk' privilege, they are not qualified adult hires in the first place.

In summary, everyone makes mistakes; nobody is perfect. And, the nicest most loving thing to do when people make mistakes is to provide them with honest unfiltered feedback to help them improve. But, the difference between good Software Developers and bad Software Developers is that good ones own up to their errors and correct them whereas bad ones do not own up to their errors and never correct them.

Video for RubyConf 2024 Workshop "How To Build Basic Desktop Applications in Ruby"

The video for my RubyConf 2024 Workshop "How To Build Basic Desktop Applications in Ruby" has been released:

https://www.youtube.com/watch?v=TTSqRdTVtDY

This video is not only useful to Ruby Developers who want to learn how to build basic desktop applications in Ruby with the Fukuoka Ruby 2022 Award Winning Glimmer DSL for LibUI (Prerequisite-Free Ruby Desktop Development Cross-Platform Native GUI Library), but also to Rails Developers who want to build Rails productivity tools as Ruby gems (e.g. the rails-gui gem offers a user-friendly fast GUI for rails routes), leverage all the awesomeness of Glimmer in the Frontend of Rails applications 🤯 (in the workshop, I mention a new Glimmer DSL for Web that has all the features of Glimmer desktop gems tailored for Rails Frontend Development), and improve their skills in Object Oriented Programming, Software Architecture, and Software Design in general, like how to apply MVC (Model-View-Controller) & MVP (Model-View-Presenter) correctly to improve productivity and maintainability, instead of doing things the Rails MVC way, which is not completely correct. 

Happy learning!

Here is the GitHub repository with the workshop code exercises and test solutions:

https://github.com/AndyObtiva/how-to-build-desktop-applications-in-ruby/tree/rubyconf2024

Here are the workshop presentation slides:

https://docs.google.com/presentation/d/e/2PACX-1vSAaFLYeyolSy2Qe2tW0djv78tA-m120i4DJyaJ4qAHoWpv5Xppn_-yIpg4_IAGntetZkRDkkuT2zXN/pub?start=false&loop=false&delayms=60000&slide=id.g140fe579a5a_0_0

The DCR Kids Programming Language Supports Live GUI Updates

One of the requests I received at #RubyConf2024 for Glimmer DSL for LibUI (and other Glimmer desktop gems) is providing an editor that can update the GUI live as the programmer types code into it.

I have built something like that before for a programming language for kids called DCR actually. 

Check out DCR (Draw Color Repeat), which is built in Ruby using Glimmer DSL for SWT:

https://github.com/AndyObtiva/dcr

When I was working with Noel Rappin (author of the latest edition of the Programming Ruby book) at a Chicago-based company many years ago, he gave an internal presentation at our company about the fact that small productivity features like keyboard shortcuts and IDEs don't accelerate Software Development as much as following good Software Processes, having good Software Architecture & Design skills, and avoiding Over-Engineering. For example, DHH used TextMate for many years for Ruby on Rails development, and that didn't slow him down despite not being a super-advanced editor. Many Rubyists use VIM, Emacs (like Matz, the creator of Ruby), and Sublime Text with no issues in productivity. The point I am trying to make is I thought about implementing live GUI updates as an editor feature, but then decided against investing in it as it does not provide the benefit that people think it offers. If it did, I probably would have built it already as I care a lot about productivity in Software Engineering. That said, live GUI updating was a useful feature for kids to avoid overwhelming them with having to know about the command line. They could type the program, and they didn't even have to click a button to say Run. The app updated the graphics automatically through advanced data-binding features. But, adult professional Software Engineers already know how to use the command line very well, so running a desktop app with a few keystrokes is fast enough for their productivity. I have built many desktop apps that way, some in under 10 minutes for the first MVP (Most Valuable Product), like my Glimmer Metronome, and that proves that this feature isn't as important as people think. You would get much more benefits from developing your Object Oriented Programming skills, Software Architecture & Design skills, and learning to apply YAGNI to avoid Over-Engineering. Tiny productivity features save you seconds every day whereas Software Engineering skills save you hours, days, weeks, or even months. Also, many React.js devs use tools like that, and React.js productivity is honestly not that good compared to productivity in Ruby on Rails without React.js and without such productivity features as live reloading. 

This is in fact what separates average developers from top-level developers, is knowing how to judge things that are just "cool" without being that useful from things that could save customers days and weeks of time and paid work without seeming that cool.

I am not saying I won't consider supporting GUI live updating in the future. But, honestly, my time is divided between many open-source projects, and currently taken up by higher priorities. It is more important to finish implementing advanced features in Glimmer DSL for Web, which I can benefit from at my job immediately for my clients, and to finish version 1.0 of Glimmer DSL for WX (the newest GUI kid on the block with native widget support that is more complete than LibUI's). 

Last but not least, Glimmer gems are an open-source effort. Anyone can build an open-source editor with them and play around with implementing live GUI reloading upon updating code in the editor. Knock yourselves out and help the open-source community with your effort. It's important to be good citizens of the open-source world and to give back, not just take without giving back.

In any case, you are welcome to share DCR (Draw Color Repeat) with your children or young relatives to have them experience the delight of being able to draw graphics on a computer screen by typing simple commands on a keyboard! DCR was meant to be a simpler version of the historic programming language, Logo. It cut down its features to the absolute simplest minimum to avoid overwhelming younger kids.

Happy kids programming!

Montreal.rb Hack Night Solutions for Hunt The Wampus

In November and December of 2024, Montreal.rb hosted 2 Ruby Hack Night meetups about building the historic computer game, Hunt The Wampus, which was a text-based adventure game developed by Gregory Yob in 1973.

The Hack Night details are at this GitHub repository (you can look at Git branches for solutions):

https://github.com/AndyObtiva/hunt_the_wampus

I heard great feedback about the event from attendees of the Ruby meetup:

- "This was very interesting!'

- "It is great to change things up with a Hack Night instead of just having talks at every Ruby meetup!"

- "It is very useful that this Hack Night gives people the option to build an app as a CLI, TUI, GUI, Web Backend, or Web Frontend. Even if people made one of those choices during the Hack Night, they can later build other versions of the app after the Ruby meetup."

Here are demos of a couple of Ruby implementations of the game that were done in under 2 hours.

Ruby GUI desktop app built using Glimmer DSL for LibUI:

https://github.com/AndyObtiva/hunt_the_wampus/tree/solution-gui-glimmer-dsl-libui-text

Ruby on Rails Web Frontend SPA built with Glimmer DSL for Web and Opal:

https://github.com/AndyObtiva/hunt_the_wampus/tree/solution-web-frontend-rails-opal-glimmer-dsl-web

Building a lo-fi prototype is a common Game Development practice. That's why the GUI version of Hunt the Wampus intentionally did not render graphics, yet text only, for representing the various objects and senses of the game. It can certainly be upgraded in the future with graphics if desired (Glimmer DSL for LibUI supports canvas graphics with the area control).

It was pretty amazing to be able to take the Model layer Ruby code that worked in CRuby and reuse it successfully in Opal Ruby (Ruby 3.1 to JavaScript transpiler). That clearly demonstrated the superiority of the Frontend Ruby approach in Rails applications over JavaScript libraries like React or Vue because JavaScript does not support being able to reuse Ruby code directly in the Frontend when needed. Only Frontend Ruby (e.g. Opal or WASM) supports that, which saved a lot of development time for building Hunt The Wampus as a Web Frontend in a Rails web app given that the Model layer was already complete from a previous Hack Night event.

Feel free to do the Hack Night exercises yourself by going through parts 1 and 2:

- Part 1 (The Model): https://github.com/AndyObtiva/hunt_the_wampus/tree/hack-night-part1-model

- Part 2 (The View): https://github.com/AndyObtiva/hunt_the_wampus/tree/hack-night-part2-view

Happy learning!

The Rails subreddit is an embarrassment to the Ruby community

The Rails subreddit is such an embarrassment to the Ruby community. I get anti-Ruby sentiments from people there more than anywhere else. People there are very hateful of any Ruby innovations that are outside the box, like using Ruby in the Frontend of Rails apps. It is shameful the group does not make people with highly innovative ideas feel safe. Everyone there must comply with the few things the top players in the Rails community say or else they are downvoted to kingdom come while receiving many mean hateful comments without being given a chance to explore new divergent ideas safely, meaning the group is unsupportive of innovation and diversity, as they discriminate against people who have diverse ideas by being very nasty towards them. Ironically, such people act like how many devs acted towards Rails in the mid-2000s when Rails was still very new and young. This goes against the Ruby motto MINASWAN (Matz Is Nice And So We Are Nice). I personally prefer the acronym WAN (We Are Nice) or WANNJBMIN (We Are Nice Not Just Because Matz Is Nice), but either way, the Rails subreddit fails all niceness acronyms. When I pointed that out to someone on the Rails subreddit, their response was literally "lol", meaning lots of laughter as in they don't care, thus confirming my point 100%.

 
With the negative things happening at the Rails subreddit, it is no wonder the Rails community is questioned daily on whether Rails is dead. The community is not healthy at all in 2024 and is not what it used to be 10 years ago when everyone was open-minded about any brand-new out-of-the-box ideas that are not necessarily coming from the creators of Rails themselves. I joined the Rails community in 2007 initially because of how open-minded, creative, and intelligent it was, but today it is extremely closed-minded outside of what the Rails top players do. The community has become elitist, meaning only people who are part of the elite contributors to Rails or who are compliant with the elitists' thoughts and ideas are included in respectful treatment by others, but everyone else who is not part of the elite core or the people who worship them and their ideas are excluded from any respectful treatment or are ignored without providing any community support. Again, this goes counter to MINISWAN. 

When a respectable Software Engineer disagrees with someone else's idea, they highlight their reservations rationally in a civil manner without downvoting a post until they have done their homework first and tried whatever open-source project is mentioned to be supportive of open-source and to ensure their opinion is an informed opinion. They would never knock something till they have tried it. Downvotes/upvotes that come from uninformed opinions have zero weight. Uninformed opinions don't say anything about the subject at hand, but they say a lot about the false prejudice of downvoters/upvoters and how incompetent and unintelligent they are for not doing their homework or having the curiosity of true Software Engineers to try the new open-source projects.

If you want a subreddit that is NOT flooded by Ruby haters who are unsupportive of new Ruby open-source project innovations and NOT flooded by people who are negative/mean/nasty/discriminatory towards anyone who has ideas that are outside the mold, check out my new Rubyists subreddit:

https://www.reddit.com/r/Rubyists/

It is a very new subreddit that aims to be an online group for hardcore Rubyists, meaning people who are experienced in Ruby and who fully understand the awesomeness and potential of Ruby while being open-minded about new Ruby innovations. It doesn't have many people in it right now, but I'd take the few that are in it over the many hateful people who are in the Rails subreddit. I would be patient with growing this group very gradually. It is worth it in the long-term to have a place for hardcore Rubyists to converse without feeling unsafe in sharing out of the ordinary open-source Ruby ideas.

Still, it is not enough to join the group. Please share as many posts there as possible too to help grow it. Please break the ice by sharing a post immediately if possible.

Also, please repost this tweet and repost the Rubyists subreddit link on all your social media accounts if possible.

Code Exercises & Slides for RubyConf 2024 Workshop: "How To Build Basic Desktop Applications in Ruby"

Below is the GitHub repo that contains the code exercises and slides of the RubyConf 2024 Workshop: "How To Build Basic Desktop Applications in Ruby". Everyone can go through them at their own time.

GitHub:

https://github.com/AndyObtiva/how-to-build-desktop-applications-in-ruby/tree/rubyconf2024

Slides (Online):

https://docs.google.com/presentation/d/e/2PACX-1vSAaFLYeyolSy2Qe2tW0djv78tA-m120i4DJyaJ4qAHoWpv5Xppn_-yIpg4_IAGntetZkRDkkuT2zXN/pub?start=false&loop=false&delayms=60000&slide=id.g140fe579a5a_0_0

Thanks to everyone who attended the RubyConf 2024 workshop and the follow-up Hack Day event.

One of the attendees, Scott Werner, built an AI joke generator desktop GUI app with Glimmer in Ruby.

And, a scaffolding of Hangman was generated at the Hack Day event too (you can star and watch the project to follow its development to completion): 

https://github.com/AndyObtiva/hangman

Glimmer on!!!

Montreal.rb May 2024 - Hotwire Turbo in Rails: Drive, Frames and Streams

The video of the Montreal.rb May 2024 talk "Hotwire Turbo in Rails: Drive, Frames and Streams" by Helmer Davila has been finally posted on YouTube:

https://www.youtube.com/watch?v=rmsBVsZUHzI&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=13

Talk Description:

In this talk, we will be exploring Hotwire Turbo in Rails, focusing specifically on Drive, Frames, and Streams. We will dive deep into how Hotwire Turbo enhances the speed and performance of Rails applications, providing users with a smoother and more interactive experience. We will also shed light on the concepts of Drive, Frames, and Streams, discussing their roles and how they contribute to the overall functionality of a Rails application. Whether you're a seasoned Rails developer or just getting started, this talk will offer valuable insights into optimizing your applications with Hotwire Turbo.

Speaker Bio:

Helmer Davila is a Senior Software Developer with over nine years of experience in Full Stack Web Development and a bachelor's degree in Computer Science. His comprehensive experience, gained from full-time and freelance roles, has equipped him with a deep understanding of various market frameworks, with Rails and Laravel being his favorites. He also co-founded a food delivery startup in Peru. His hobbies include biking, traveling, writing, and learning new languages like Italian and Portuguese.

Happy learning!