Andy's Laws of AI in Software Engineering

(Note: this is a live document that could undergo revisions in the future)

I came up with a list of laws in relation to doing general Software Engineering work with reliance on AI, from my experience as a Master Software Engineer experimenting with AI and from observing other Software Developers who experiment with or use AI. 

Law #1: "The more Software Developers use AI, the more valuable Software Engineers who do not use AI become."

Software Engineers who are masters at delivering Software without using AI will actually have increased job security the more Software Developers in the worldwide Software Development community rely on AI to deliver Software without having true mastery over Software Engineering.

As more Software Developers become fully dependent on AI to build Software without truly understanding how AI gets work done, Software Engineers who do understand what is going on under the hood will dwindle and become more valuable than ever. In other words, they will have a competitive advantage over Software Developers who can only deliver Software features with AI as well as Software Developers who have not mastered Software Engineering.

Also, there will always be a need for Software Engineers who can maintain the Software of AI itself.

Law #2: "Software Developers benefit from AI in direct proportion to how weak they are in Software Engineering"

The weaker Software Developers are at Software Engineering the more they benefit from AI. After all, AI learns from Master Software Engineers and then applies its learnings in code generation done for lower-level Software Developers who lack mastery in Software Engineering. So, users of AI simply place themselves lower in the expertise hierarchy to be on the receiving end of what Master Software Engineers feed AI with their code. This explains why many experts like Linus Torvalds do not find AI very useful while devs who have zero degrees and qualifications feel like they get a lot from AI.

A beneficial thing to learn from this law is that it is more valuable for a Software Developer to hone in their Software Engineering skills (including the completion of university degrees) than to hone in their AI usage skills because if they achieve mastery over Software Engineering, they would cease to need AI to do their job well for customers. In other words, if a Software Developer feels like they benefit from AI even a little bit, then that means they have some unhandled weakness and are lacking some skills in Software Engineering they could be improving instead. Using AI after all takes away from the recommended 10,000 hours of Software Engineering practice to achieve mastery.

Law #3: "AI's speed is negated when it produces Software features faster than customers can test and learn."

Code generation is not the bottleneck when customers still have to test every Software feature at a human pace to provide real human feedback before iterating further for future improvement. So, given that customers still need to provide human feedback with non-AI testing, that negates the need for Software Engineers to produce code faster, rendering AI's speed benefits moot. Producing code with Lean Software Processes is fast enough for that need. 

Furthermore, Software has a limit to acceptable complexity by customers in relation to how many features it contains. So, if customers get too many features, they get overwhelmed, and that also invalidates the benefits of AI's speed. In other words, customers prefer quality over quantity. 

Interviewing Ruby Software Engineers Is Easier Than Ever in 2025!

(This article, which was posted at the end of 2025, doubles as a guide on "How To Be a Top-Level Ruby Software Engineer in 2026")

My team's approach to interviewing Ruby Software Engineers involves giving a candidate a small-size Rails web app project to complete over a week (some finish it in much less time), reviewing the solution to check if it follows good Software Engineering principles and practices, and conducting a follow-up interview meeting to ensure that the candidate did solve the project themselves and can answer follow-up questions that test their general Software Engineering skills and specific Ruby on Rails skills.

Regarding the follow-up interview, new developments in recent years and not so recent years have made it super-easy to interview Ruby Software Engineers and tell the good ones from the bad ones in 2025:

1. GitHub: With GitHub becoming so proliferate in the Software Engineering community, there is no excuse for any Software Engineer not to have a GitHub account with GitHub open-source repositories showcasing their code anymore. If a hiring candidate doesn't include a GitHub account on their resume with at least one open-source project (could be an experimental or purely learning project), then they won't make a good member in a modern Software Engineering team that sometimes contributes fixes to existing open-source libraries or extracts new open-source Ruby gems from existing work for the benefit of the Ruby community at large. Also, having open-source projects on GitHub demonstrates initiative and passion whereas not having any demonstrates laziness and lack of true passion. Many talk the talk of passion in Software Development, but few walk the walk by demonstrating passion with actions (e.g. open-source projects), not just words alone.
2. Microservices: Just ask a Ruby dev about their opinion of the Microservices architecture. If they claim it is necessary since day 1, you can safely deny the hiring candidate from further steps in your hiring process. If they completely dismiss Microservices and claim that everything can be solved by a Monolith, you can safely reject the candidate as well. The right answer would be a pragmatic "it depends on customer needs", and would describe adopting Microservices incrementally if needed only, while describing the pros, cons, and trade-offs for using different approaches, such as a Monolith, Rails Engines, and Microservices, clarifying that it is OK to adopt a hybrid approach instead of a black and white approach. Bonus points if the candidate recognizes that  "Microservice" is just a silly buzzword for what is more properly called "Web Service", which has been around since the early 2000s. 
3. New Programming Languages: Just ask the Ruby dev what they think of new programming languages like Elixir, Rust, Golang, TypeScript, Scala, and Clojure. If they respond with anything other than noting that the benefits of immutable FP are overhyped by people who have skill issues with OOP and aren't truly useful/necessary in a practical sense given that OOP, the more modern paradigm (FP is 70's style programming), operates just like how we naturally and intuitively think of the real world without having to go through a translation layer that maps everything into "functions", which loses half the battle, then you have a dud on your hand, and you can easily reject that candidate in your interviewing process. They still need to know what FP is useful for, numerical computing, like any sort of mathematical algorithms that truly represent functions in real life mathematics. Also, any sort of iteration over collections, which Ruby supports with its hybrid OOP/FP approach (e.g. using `reduce` or `map`, etc...). That said, also, if they respond with anything other than noting that in about 90% of Business App Development, dynamic typing enables better focus on business domain concerns (kinda like what Matz called driving auto in a recent RubyConf keynote speech) while static typing provides the illusion of better Software Development while actually making you work harder, take longer to finish features, and write more code overall while being distracted by types instead of focusing on business concerns, then you have a dud on your hand. Of course, they should still note where static typing is useful (kinda like what Matz called driving a stickshift at a recent RubyConf keynote). That's in optimizing algorithm performance when needed. Also, the candidate should demonstrate an open mind about being able to follow a polyglot's hybrid approach that relies on a dynamically typed OOP language for most basic features while calling out to a statically typed language for algorithms that need extra optimizations. That's kinda like how Ruby relies on C extensions or JRuby relies on Java. Candidates that fall easily for the hype of new programming languages without having the skills to discern what the pros, cons, and trade-offs are in each can be skipped in the hiring process.
4. React: Just ask a Ruby dev point blank what they think of React.js (and related technologies like Inertia.js). If their reaction is anything but disgust and absolute dismay, you're interviewing a dud that can be rejected safely in the hiring process. That means they don't really understand Ruby well enough to notice all the ways React.js contradicts the Ruby way and destroys Rails productivity, and they don't really know Software Engineering principles and best practices enough to notice where React breaks them, which makes maintainability very complicated and expensive and lowers productivity as a result. Another question that immediately reveals frauds with this regards is "How would you feel if someone invents a better Frontend technology than React that doubles productivity, improves readability, and halves code?" If you notice complete lack of interest or excitement in the candidate, you know you have a dud as well, someone who is attached to technologies for purely emotional non-rational reasons instead of rationally choosing technologies to serve customers in the best way possible.
5. Glimmer DSL for Web (2025 Fukuoka Award Winning Ruby Frontend Framework for Rails): Just describe Glimmer DSL for Web to a hiring candidate and explain how it completely eliminates the need for all JS Frontend Frameworks by enabling Software Engineers to leverage the same great benefits of Ruby that they always loved, but in the Frontend, doubling productivity, improving readability/maintainability significantly, halving Frontend code, halving the workforce (Backend devs can now do Frontend development), and halving Frontend Development costs. If the Ruby dev doesn't jump up and down with excitement or doesn't at least show some curiosity to learn more about the library's possibilities for the customers' benefit, then you know you have a dud on your hand that can be safely dismissed in the hiring process.
6. AI: (Update: In 2026, I want to note that Claude Opus, which I use at work, is less fuzzy and thus more reliable than previous iterations of AI from previous years, but the other points shared here still stand; I would not rule out candidates for using AI, but I could consider ruling them out if they thought AI is everything without being aware of all the variables at play in Software Engineering, as mentioned by this bullet point). Just ask a Ruby dev to tell you what they think of the Gen AI movement (e.g. Chat GPT) and its effects on Software Engineering. If they respond with anything other than stating facts like solving the right customer problems has a lot more effect on productivity than generating code, human interactions are more important for producing the best work possible than actually increasing machine interaction by replacing humans, or generating code isn't the bottleneck, yet maintaining it for years to come, then you have a dud on your hand, and you can safely eliminate that candidate from your hiring pool. In other words, even if AI was perfect, it's still better to have more human interaction as it brings new fresh ideas due and connects devs with their humanity, which yields a better understanding of customer needs and more creative solutions for their problems. Additionally, a smart candidate would recognize that using AI can be a bug in the requirements because Gen AI is fuzzy by nature (Update: In 2026, Claude AI has become generally stable and reliable, so this point can be disregarded now) while Software Engineers seek sure answers, so attempting to use a Gen AI can be the wrong strategy from the get go if it doesn't satisfy the requirements not to be fuzzy, regardless of what sort of technical proficiency it has (Update: In 2026, this seems to not be an issue anymore). AI can be great for gaming or art with its fuzzy nature, but terrible if a sure correct answer is needed (Update: In 2026, this seems to not be an issue for code generation anymore). Furthermore, good candidates would recognize that AI is only as good as its input, so it often learns the answers that the average masses come up with, and even if it learns to provide good answers one day, after it ingests some more bad input for a while, it would unlearn what it learned and yield bad output (Update: In 2026, this does not seem to happen as much as it did in previous years). AI only provides the most common average solutions, but excellent Software Engineers come up with top-level solutions that are better than what's common, so again, AI limits top-level Software Engineers with that regard (Update: In 2026, Claude AI seems to be reflecting solutions from top-level Software Engineers as well now, so this does not seem as big an issue as it was before when GitHub Copilot's suggestions only impressed average/beginner/mid-level devs, but almost always failed the quality standards of top-level/master-level Software Engineers; albeit top-level Software Engineers can still come up with better solutions than AI from time to time, so this is something to keep in mind). I have observed that top-level engineers in the Software Engineering industry like Linus Torvalds, the creator of Linux, don't really care for AI. Only average devs care for AI. Many devs don't get this, making it easy to rule them out to find out the Software Engineers who are truly the best. (Update: In 2026, this point has become moot due to the increased utility of AI even to top-level Software Engineers). By the way, it is OK for devs to use AI if they want to, but only as long as they responsibly do so while being fully aware of all the inherent issues explained above. We don't micromanage devs to either use or avoid AI (companies that micromanage their employees are awful and not maximally effective), but we do expect them to do correct Software Engineering reasoning about AI.

The good news is that those same recent developments also help truly skilled Ruby Software Engineers maintain job security very easily. It's ironic that AI didn't actually decrease job security, yet increased it for proper Software Engineers who are the real deal in their profession. Rejoice in these times! Our jobs have gotten much easier while the market got worse as a whole. 

One last note is hire devs with the backbone to say no when the masses are heading in the wrong direction. If a dev who might have noticed that a technology like React was bad at first later on changed their mind and approved of it just because the majority started using that technology, then they are exactly the wrong kind of dev to hire. Never hire spineless pushovers. Even if they come up with very smart solutions sometimes, the quality of their work can always be compromised by their lack of spine to push back against popular yet bad solutions.

I'm happy one of my team's recent hires volunteered to help me with Glimmer DSL for Web open-source work, and another actually complimented me on winning an award for that project and expressed great excitement about joining my team because of that accomplishment and our use of a Ruby Frontend library in our Rails web app.

Unlimited Tech Debt Work

I love that at my job, our managers are 100% on board with doing as much tech debt work as needed. That's what enables my team to stay productive month in month out. It's very sad when company politics prevent tech debt work from happening and employees end up getting forced to accept the unproductive status quo because "that's the way it is". That's why good work relationships are of paramount importance. They enable us to bypass politics entirely to focus on getting work done in the most effective way possible for customers.

Under-applying YAGNI Results in Terrible Codebases and Not Taking Good Advantage of OOP

It's amazing how few devs understand the YAGNI Software Engineering principle (Ya Ain't Gonna Need It!). This is as true in the Ruby community as it is in other Software Engineering communities. Devs either over-engineer everything with very complicated "Services" or under-engineer everything by using a Functional Programming language or style of development, resulting in a very terrible expensive-and-difficult-to-maintain codebase. Very few Software Engineers are adept at applying YAGNI, understand how to balance division of responsibilities between objects in Object Oriented Programming, and understand that every approach in Software Engineering is valid depending on the problem at hand.

Writing everything in a single script is sometimes good enough. Otherwise, dividing the script into a few Models might be the next good enough approach. If the Models grow too large, then perhaps extracting a Service or few is the next good enough approach, but that doesn't mean devs should be applying that approach everywhere all the time. That's where most devs fail as they try to generalize whatever approach they think is "best" everywhere all the time, and end up resulting in a terrible codebase to work with.

Balance between different approaches is key and being comfortable with imperfection is perhaps the most underrated skill in Software Engineering as it is the skill that ensures properly applying the YAGNI principle whenever needed. Under-applying YAGNI results in terrible codebases and not taking good advantage of OOP when helpful.

One of the most common anti-patterns caused by lack of application of YAGNI is a developer complaining about different parts of a technology and throwing the baby with the bathwater by never using a technology again because it did not solve everything all the time. 

Usually, when I hear a Software Engineer talk with such generalizations, I recognize right away I am talking to an amateur not a real expert in Software Engineering. Software Engineering amateurs usually are always bouncing from one approach to another while seeking the golden hammer that would solve all their problems all the time. One day that is GraphQL, the next day, it is Server Side Rendering, and after that, perhaps Rust, and on and on and on. They never learn to write good code with any approach because they are always seeking a silver bullet while complaining about different parts of a technology because of expecting them to solve everything all the time. 

Like, they might complain about Rails for being "too simplistic with its MVC pattern". So, then they jump on Elixir or Rust and expect it to solve all the problems of the world by throwing the Rails baby with the bathwater. Hello!!! You were never supposed to only apply MVC in Rails, yet just use it as a starting point while augmenting it with proper Object Oriented Design, including application of Design Patterns and Domain Driven Design! 

Those same devs end up eventually ditching Elixir or Rust, and then jumping on the next hype bandwagon, like Next.js or Clojure, etc... Every codebase they build ends up being a complete piece of unmaintainable garbage, and they use that as an excuse to jump unto the next piece of hype. 

Beware of such devs as all they do is scam customers with the illusion of skill while they lack the true deep Software Engineering skills of applying YAGNI and knowing how to use the right tool for the job.

How To Compliment an Open-Source Software Project

The best compliment of an open-source project is using it, even if only in a proof of concept or a toy project.

When I started the first desktop version of the Glimmer project back in 2006, I had multiple coworkers support me by not only trying the project out, but also making contributions to the project via pair-programming.

If somebody ever compliments your open-source project without using it, it means they didn't compliment it at all, yet just lied. 

Beware of fake "open-source supporters". They actually weigh you down by pretending to support you with words alone without actually supporting you with actions. Meaning, they're all talk and no walk. I try to intentionally alienate such people from my open-source projects all the time. They're total trash!!! Not real supporters of open-source software. 

If someone compliments one of your open-source projects, put them on the spot by asking them if they used it. If they didn't, it means they only offered a cheap compliment, so tell them not to compliment your project until they've used it, or else they would be lying because if they didn't even try the project out for themselves, the compliment isn't sincere.

Montreal.rb April 2025 Domain Driven Design in Ruby on Rails

The video, slides, and repo for the Montreal.rb April 2025 talk "Domain Driven Design in Ruby on Rails" have been published!

YouTube Video:

https://www.youtube.com/watch?v=JlJLz2dJlhQ&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=17 

Presentation Slides: 

https://docs.google.com/presentation/d/e/2PACX-1vT91M7Aw715dVfewkEn_kcDBjDIBJPN7eB6PH0lEkH41EUFGiL5GANj2rFxIGPU68s4Lm-O8Ch5WHZv/pub?start=false&loop=false&delayms=60000&slide=id.p1

GitHub Repo:

https://docs.google.com/presentation/d/e/2PACX-1vT91M7Aw715dVfewkEn_kcDBjDIBJPN7eB6PH0lEkH41EUFGiL5GANj2rFxIGPU68s4Lm-O8Ch5WHZv/pub?start=false&loop=false&delayms=60000&slide=id.p1

Talk Description:

Software development is not just about translating business requirements into a static software design. It is about ensuring that in the long run, the system can evolve with the business needs and facilitate communication between business people and developers around the business domain in order to quickly and accurately add or modify features. This requires superb knowledge crunching and domain modeling skills.

Domain Driven Design is an approach that Eric Evans popularized in the mid 2000s to address these concerns. It is a process that centers design of software around the business domain.

This presentation will cover several of the topics and ideas in the Domain Driven Design approach (but not all topics of the book):

• Domain Modeling
• The Ubiquitous Language
• Model Driven Design

Additionally, there will be a few code examples to illustrate some of the Domain Driven Design ideas as applied in a Ruby on Rails application.

Entitled/Incompetent/Mean Members of Ruby/Rails Subreddits

This is how conversations metaphorically go with typical members of the Ruby/Rails subreddits nowadays who act as if they're gods in Software Development:

• > Have you ever presented at RubyConf, or multiple RubyConfs?
• Them: No
• > Have you ever presented at RailsConf, or multiple RailsConfs?
• Them: No
• > Did you ever win a Fukuoka Ruby Award, or multiple Fukuoka Awards?
• Them: No
• > Do you maintain any Open-Source Software Projects, or award-winning Open-Source Software Projects?
• Them: No
• > Do you have a Master's Degree in Software Engineering, or a Bachelor in any computing related field?
• Them: No
• > Do you have 10 years of experience in Software Engineering at least?
• Them: No
• > But, you think you're a god in Software Development?
• Them: Yes

Obviously delusional, and a very embarrassing entitled attitude! 

I mean, my answer to all those questions (except the last one) is Yes, and yet I don't consider myself a god at all, nor act as one! That's because as a Software Engineering professional, I must avoid all "pride" to be able to always stay unbiased and open-minded about better ways of Software Development instead of getting attached to what I know while unintelligently pretending that makes a god. The moment someone thinks they are a god (or even a god to their former selves) is the moment they stop improving and stop performing as well as they could be.

The Ruby/Rails subreddits are currently the biggest embarrassments of the Ruby community as they often contain people who are very unhumble and unnice despite lacking experience and skills, violating the Ruby principle of MINASWAN (Matz Is Nice And So We Are Nice) as they don't give Software Engineers with interesting creative outside the box ideas the benefit of the doubt or any much-needed support, thus embarrassing themselves when such Software Engineers end up winning awards for their ideas by Matz, the creator of Ruby himself (like Glimmer DSL for Web winning at the Fukuoka Prefecture Future IT Initiative 2025 competition). Such subreddits are so badly managed that mean/unhumble developers are excused/enabled while nice/hard-working developers are usually allowed to get mistreated and piled upon there. Ruby & Rails subreddit members literally downvoted my posts about Covert Discrimination to zero, not realizing unintelligently that this ended up offering a 100% irrefutable proof of how discriminatory and hateful they are as anyone who doesn't discriminate would have immediately offered support and concern without double-standards if discrimination is pointed out, saying something like "discrimination is wrong no matter what kind it is!" without actually discriminating live against the individual raising the issue with discrimination as to prove it. 

The silence of the Ruby community about this incriminates everyone who is silent about this no matter who they are. I don't care if it's DHH, the creators of Puma, maintainers of Ruby/Rails, Ruby podcast/newsletter content authors, or whoever else. they're all guilty of being enemies of the Ruby community if they remain silent about this problem or even encourage it to happen because this problem kills good ideas, degrading the Ruby community as a whole. This forces the Ruby community to regress to least common denominator weak ideas that "the majority approves of". Truly good citizens of the Ruby community will follow MINASWAN and call out this anti-MINASWAN behavior in the Ruby/Rails community subreddits continuously until the situation is fixed. Beware of people who claim to believe in MINASWAN but apply it with double-standards, discriminating covertly against certain people.

This issue with lack of humility resulting in delusional incompetence is not limited to Redditors as it happens with everyone who has zero humility despite being lazy and having no degrees, no extensive work experience, no open-source contributions, no awards at any Software/Tech Competitions, no presentations at local meetups, no talks at software conferences, and no sufficient reading of Software Engineering books. It's so counter-productive and embarrassing how such devs who lack humility try to argue nonsense with Software Engineers who are very passionate about Software Engineering with actions not just words alone, are true hard workers, have a solid university degree or more, have more than 10 years of work experience, maintain many open-source projects, present frequently at their local meetups, talk at software conferences, and win awards in Software/Tech Competitions. Remember that a beginner snowboarder can't "school" Shaun White on snowboarding, but if they were humble, they could learn a lot about snowboarding from Shaun White who's won Gold Medals at the Olympics with his snowboarding skills. This problem with lack of humility might also be a form of Covert Discrimination against specific people that are not listened to no matter how experienced and accomplished they might be while listening to others with similar or even less experience/accomplishments. That's a form of discrimination, so it is still embarrassing given that discrimination is unacceptable.

Lack of humility in inexperienced devs is a recipe for disaster as such devs never improve, getting stuck in their mediocrity forever as a result. When I was a Junior-to-Mid-level Software Developer, I was extremely humble and always did my best to defer to the knowledge of more senior Software Developers while learning from them as much as I could. Ignoring the knowledge/experience/advice of more senior Software Developers is 100% the loss of the less experienced devs. By the way, I am not saying that as a Junior/Mid-level Software Developer, I didn't have some ideas that were better than the ideas of the more senior Software Developers. The more senior Software Developers always kept an open dialog with me to explore ideas that they have not thought of. That said, many of my ideas were ones that they already encountered and tested, finding out for themselves whether they are effective or not. I listened humbly to them when they pushed back on some of my ideas instead of "feeling offended" like so many selfish self-obsessed non-humble devs who don't put serving customers at the top of their priorities.

By the way, this post is assuming good ethical hard-working Senior Software Engineers who listen to less experienced Software Developers with a two-way dialog, not mediocre unethical rude ones who shut down dialog completely. I sometimes see some younger devs getting immaturely caught up with the drama of "experience wars" (having the attitude of "I told them! I made them understand I'm right despite not having as many years of experience as they did!") while completely forgetting customers and the focus on selflessly maximizing the use of past experience of all coworkers on a team with selfless teamwork to humbly learn and do the best work possible for customers.

Thankfully, devs that are not humble enough to learn and improve give the rest of us job security when they make fools of themselves! Thank you!!!

I Am Not a Fan of Ruby

I am not a fan of Ruby. I am mentioning this to dispel any misunderstandings that some devs have about my use of Ruby. I do not have any personal preference for using Ruby. I do not find Ruby's syntax beautiful. I do not think of Ruby code as art or anything like that. I do not like or love Ruby. 

In all circumstances, I only use Ruby as a Software Engineering decision to provide the best solution possible for specific customer functional requirements while weighing Ruby against alternative technology options, such as Java, Python, JavaScript, C++, C, Swift, Lisp, etc... in relation to pros, cons, trade-offs, and non-functional requirements, such as productivity, maintainability, extensibility, and flexibility.

I am a Software Engineer first and a Rubyist as a byproduct of that, always. If a better programming language than Ruby comes along, I would be the first to start using it to solve customer problems more effectively. That said, I will not jump on any newer programming languages just because of peer pressure or hype/buzz when they do not in fact perform better than Ruby in meeting my customer requirements. 

Montreal.rb February 2025 Design Patterns in Ruby

Design Patterns provide reusable solutions to common problems in Software Design and Implementation. Learn how to apply all 23 Design Patterns by the Gang of Four in Ruby by watching the Montreal.rb Ruby Meetup February 2025 Talk "Design Patterns in Ruby"!

YouTube Video:

https://www.youtube.com/watch?v=pi5RAynZWuA&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=16

Presentation Slides:

https://docs.google.com/presentation/d/e/2PACX-1vRMuWVMfMQ9q2YQ_MIFG2i0Jer0KDeGGnuRrZ4J8RQNcSd9ZTvJH-2rgq9_ed5L7WecPk3OuPHvRTtK/pub?start=false&loop=false&delayms=60000

GitHub Repo:

https://github.com/AndyObtiva/design_patterns_in_ruby

Full-Stack Development vs Split Frontend & Backend Development

I see a lot of uninformed posts online that misunderstand the benefits of Full-Stack Development vs Frontend/Backend Development. Know that only Software Engineers who have the full context of the value being delivered to customers end-to-end will be able to deliver max value to businesses while simplifying the Software Design and Code maximally across the Frontend and Backend! 

Anyone thinking "specialization" is useful in this case is like someone thinking that specialization in pressing the gas pedal vs the break pedal is important when driving a car even though that obviously over-complicates how to drive a car with multiple people unnecessarily as it overthinks the complexity of pressing a gas pedal vs a break pedal! It's true that specialization is useful sometimes, but this is certainly NOT one of those cases. One must take into account the complexity of work to decide on whether specialization is useful or not. Frontend Development in its essence isn't complicated enough to warrant specialization that is different from Backend Development. Remember that Software Engineers build Desktop Applications as having both the Frontend and Backend in the same application. Web Development isn't that different. In the end, users have to interact through a User Interface and pull data from a Database. Some people use Frontend libraries that are too over-engineered/over-complicated like React and Angular though, and then use them as an excuse for misplaced "specialization" while lazily coasting at lower productivity by unnecessarily focusing on Frontend Development alone while their fellow Backend Developers coast at lower productivity by unnecessarily focusing on Backend Development alone.

I have worked at several Software Development companies that employed Full-Stack Development as a unique approach that gave them a unique business competitive advantage as Developers like me and others were able to do the work of clients at much higher productivity and with much better realization of customer requirements because we had a Full-Stack perspective. And, we were as SKILLED at Frontend Development as we were SKILLED at Backend Development; in fact, more skilled than our consulting clients' Frontend Developers and Backend Developers despite them being specialized and us being Full-Stack Developers! 

From different jobs I held throughout the years, I have experience in both the Full-Stack Development approach and the split Frontend Development and Backend Development approach (on both sides of it). In 100% of my experiences with companies that split Frontend Development from Backend Development, Frontend Developers ended up overthinking and over-engineering the Frontend while Backend Developers ended up overthinking and over-engineering the Backend, so we ended up with about double the workload that would have been needed had development been done by Full-Stack Software Engineers for both the Frontend and Backend. That's why we end up with crazy-complicated React.js and TypeScript codebases that contradict and break all Ruby/Rails principles! So, never accept BS excuses for "specialization" between Frontend and Backend! They're all misguided and come from laziness and acceptance of terrible over-engineered/over-complicated technologies like React and TypeScript.

Software Developers who cannot put a stake in the ground regarding Full-Stack Development vs Frontend/Backend Development just to be "nice" to some devs they know while being unnice to their paying customers are exactly the kind of spineless pushovers that allow ridiculously over-engineered and over-bloated codebases to happen! They're the kind of Software Developers that must be fired first and NEVER hired in the first place!

In summary, always do Full-Stack Development to avoid overthinking/over-engineering your codebases and to ensure delivering the best business value to customers end-to-end!

Montreal.rb January 2025 Ruby OOP Done Right with Responsibility Driven Design

Learn the basics of Object Oriented Design and how to do Object Oriented Programming the right way in Ruby by watching the Montreal.rb Ruby Meetup January 2025 Talk "Ruby OOP Done Right with Responsibility Driven Design"!

YouTube Video: 

https://www.youtube.com/watch?v=-KTUZDpMVKU&list=PLRAf4zt5oEjc2mqmEN9m_O0JovQCXxvxt&index=15

Presentation Slides: 

https://docs.google.com/presentation/d/e/2PACX-1vQ_ZD9J-X2tvIRX0oN-ueA8Og7n06Ddn5w_QDCyZBhp-iDrWI5KCzaTQC1ulTUoFybpj4SxkjTLxo2A/pub?start=false&loop=false&delayms=60000

GitHub Repo: 

https://github.com/AndyObtiva/responsibility_driven_design_in_ruby

Ruby Programmer Happiness Explained!

'Ruby Programmer Happiness' means 'happiness for having the ability to deliver useful business value to customers as productively and as simply as possible with the ability to maintain the code with very little effort for years to come'.

Some devs misunderstand 'Ruby Programmer Happiness' as a Technology that makes them happy only when in fact, the term assumes Ethical Software Engineers, meaning Programmers who derive their happiness from serving customers (who pay them) in the best way possible.

That is something to think about! 

Remember that all Software Engineers are paid to make Customers happy, so if they were to use a Technology that made the Programmers happy only, then they would fail at their job. 

Besides, I am sure there are many things that would provide much more happiness to Programmers than Ruby in general like playing video games, playing board games, playing sports, attending sports events, watching movies, bing-watching TV series, connecting with loved ones, etc...

But, Ruby is literally much more productive than other programming languages like JavaScript, Python, and Java at delivering business value to customers (assuming there are no special performance-optimization requirements), so using technologies other than Ruby causes frustration and unhappiness in Ethical Software Engineers. On the other hand, unethical programmers stubbornly stick to ineffective programming languages while writing 2x or 4x the code needed in Ruby in a more cryptic "clever" manner just because the other programming languages "make them happy" for personal reasons (like "feeling clever" or "belonging to a cool community") without any regard for how happy their customers who pay them are as a result of their work as compared to how they would be when using better technologies like Ruby. 

This disproves that happiness of the programmer using Ruby is what makes Ruby so great and proves that it is programmer happiness as a result of customer happiness in Ethical Software Engineers that is the real reason for 'Ruby Programmer Happiness'.

In conclusion, we do not use Ruby just to make programmers happy. We use Ruby to make customers happy, and being Ethical Software Engineers, we become happiest as we deliver the best work possible to customers (who pay us) with Ruby.

Imposter Syndrome vs True Imposters

I see too many posts on imposter syndrome and not enough posts on the other side of the spectrum, true imposters. You can’t trust an argument if it doesn’t cover both sides as otherwise it might be a covert scheme to get more unqualified imposters into the field of software engineering to steal the work and pay of truly qualified software engineers. Imposters often write shit code that hurts companies the most after the imposters have quit them to greener pastures, which is a common theme with them. They’re often unloyal and unreliable as they don’t stay in one place for long. Beware of imposters! They’re people who don’t have a 4-year degree in any field that relates to computers, engineering, or science, and who often don’t think for themselves, yet just mindlessly repeat what blog posters and open source project owners who work at large rich companies say on the Internet without questioning them with any proper pros/cons/tradeoffs analyses for their specific customer situations. 

To cover both sides of the argument as any proper argument should, imposter syndrome is different from being a true imposter because it happens in software engineers who are 100% qualified by having a 4-year university degree that related to computing, but are new to the software development market as professional workers, or are new to a position they have recently gained like engineering manager or CTO. Those software engineers are only suffering from lack of confidence in applying themselves to the field of software engineering as they feel out of place due to being new to their position. Once they have improved their practical skills enough (like by reading practical work software engineering books and building toy or open source projects), have accomplished enough successes at their job, and have humbly accepted coaching by more senior software engineers, they get over imposter syndrome and start feeling like they belong 100% to the field of software engineering. 

Be a Good Steward of Open-Source Software!

I had to ban a troll from my GitHub projects who never behaved like a good member of the open-source software community as he always just talked and talked without ever taking any useful actions, like reading documentation, following instructions, creating examples, writing documentation, contributing pull requests, or sharing code examples in issue reports, forgetting that open source projects are 100% free community contribution efforts and aren't paid closed-source software that entitles the user to anything.

Reminder of how good members of the open-source software community behave:

• They make an effort to read an open-source project's docs and try it out on their computer to answer their own questions before asking questions about an open source project.
• They build and share real examples of using an open-source project when reporting issues instead of just writing down very abstract words that might not relate to reality and might miss the fact that the project does provide solutions for the reported issues.
• They give back by writing documentation they feel is missing from an open source project and use that as an opportunity to become open source contributors to the open-source project.
• They give back by contributing simple issue fixes as pull requests to an open-source project, using that as an opportunity to become open source contributors to the open-source project.
• They interact with open-source project maintainers with an attitude of humility and respect of their effort and time.

Bad members of the open-source software community behave this way:

• They act entitled like they are more important than the creators of open-source projects (as opposed to equal to them) and think they are owed the privilege of paid service on 100% free and open source software projects, expecting 100% hand holding on everything, instead of being expected to be responsible strong software engineers who can figure things out for themselves by reading open-source code and minimalistic documentation. Also, they don't realize that they are being evaluated by open-source project creators on whether they are competent Software Engineers and respectable members of the open-source software community instead of being entitled devs that lose merit if they ask questions without putting in any of their own effort or demonstrating understanding of solid Software Engineering and open-source software principles.
• They do not spend at least 10-30 minutes reading documentation or trying out an open-source project before asking very trivial questions they could have answered for themselves with very little effort.
• They complain about missing documention instead of realizing this is 100% free open-source software, not paid closed-source software, and using missing documentation as an opportunity to gain the honor of becoming contributors to an open-source project.
• They report issues without writing any code examples and they ask questions with a very haughty rude entitled attitude as if they are more important than the open-source project creators when in fact, their entitled attitude loses them merit and drops their importance way below that of the maintainers who at least spent time and effort to contribute something to the worldwide open-source software community for free.
• They do not contribute pull requests for very trivial issues that they could have contributted fixs for themselves to intelligently gain the honor of becoming contributors for an open-source project.
• They do not contribute time beta-testing or using an open-source project in low-risk situations to help contribute feedback to very novel and innovative open-source ideas to show good faith in wanting to support innovation/excellence and help open-source software.

Good stewards of open-source software are the kind of Software Engineers that is considered the top of the line when hiring at Software Businsses. Be a good member of the open-source software community to help it come up with better ways of serving customers with open-source software while improving your resume and your hirability and job retention!

How To Spot Covert Discrimination in the Ruby Community

Covert discrimination is often hard to spot because it happens as personal microdiscrimination against one person or few people only without them belonging to a common minority group. As such, the people discriminated against are not protected by any minority group anti-discrimination measures, and are often abused without the abuse being detectable by outsiders because the abusing discriminators treat outsiders without discrimination, so they become none the wiser about the microdiscrimination happening against the one individual or few that are discriminated against.

That is why I wrote a guide on how to spot covert discrimination in the Ruby Community and beyond. It will be a live document that is always updated whenever new forms of covert discrimination are discovered. It is written from my experience working at both Canadian and US Software Development companies.

Forms of Covert Discrimination:

1. Treating The Majority Well: in order for covert discrimination to remain covert, it has to seem like the discriminators are very good well adjusted people who treat "everyone" with love and non-discrimination. So sometimes, discriminators will treat everyone very well except one or a few individuals in their team, company, or community, which are subtly treated in a very unloving, mean, and non-equality-conscious way. How easy is it to spot discrimination when 99%+ of people are not discriminated against? Not easy at all. In fact, this is a scheme that some discriminators at unethical companies use to basically milk one person out like the Golden Goose for the benefit of everyone else without returning the favor back to them, and every time that person is replaced, a new person plays the role of the "Golden Goose". 

2. Culture Fit: some companies do not see all people as equal human beings that could only be distinguished based on their merit (i.e. work performance and ethics). So, if they hire someone that they later find out they do not like by their non-equality-minded discriminatory biased inner standards, they chalk it up to a "bad culture fit" and fire that person, citing "culture fit" being the issue despite the fired person being very friendly, pleasant, and team-oriented while performing impeccably. Do not fall for this trap of covert discrimination. Companies have no right discriminating against anyone, and they could only fire someone if they did not perform well at their job or interacted in a bad way with others. If they fire someone for "culture fit" reasons despite the fired person not having done anything wrong, that is 100% covert discrimination masked as "culture fit". The only culture fit that matters is if the hired person has the right qualifications for the job or not, including how ethical and team oriented they are. Anything is else, like "not liking someone" for non-professional reasons despite them not having done anything wrong, is a lazy lame excuse to justify discrimination. Such companies sometimes practice this sort of discrimination because they were offering preferential treatment to employees that were not as qualified as the person who recently joined the company, and that person unintentionally made them look bad just by performing very well, so instead of requiring humility from the other employees in order for them to stop being envious and learn from the new hire, they end up punishing the new hire unfairly to go back into masking their preferential treatment for the older unqualified employees that the company discriminators grew to "like" for unprofessional reasons. 

3. Hidden Prejudice: some discriminators will discriminate against someone because they have hidden prejudices against them that they sometimes are unaware of. They see someone, and based on their look, that someone does not look like "an important person" to them. Even after they get to know that person and their job qualifications and past accomplishments, they still do not change their mind about seeing that person as "unimportant". That is because they do not treat everyone as equal and some people are just "unimportant" no matter what, due to internalized discrimination against their type of person. To them, it does not matter if that person has very good university degrees, has 10+ years of experience, has presented at important software conferences, has created and maintained very sophisticated open-source projects, etc... That person will forever be "unimportant" to the discriminators who have hidden prejudices against certain people just based on their looks or other petty reasons. This is a very bad form of covert discrimination because it is so covert sometimes even the discriminators are unaware of it. 

4. Emotional Dishonesty: some discriminators like to keep a "positive" facade at all times because they think it sells better to their clients instead of sharing the actual truth, so they train everyone at their company to be emotionally dishonest. To them, the impression of "positivity" that you put on your face is more important than how good your work is truthfully. The problem at such environments is when anything negative happens, it becomes a big elephant in the room that nobody could talk about, and remains there for months or years without ever getting handled. So, when a new hire joins such a company and discovers an extreme waste in productivity caused by one or several of those "big elephants" for so many years that everyone got used to them, as soon as they mention the negative truth, they are seen as "the enemy" and fired. Again, that is a form of covert discrimination because those new hires did not do anything wrong. They only pointed out what is wrong. They just pointed out the truth. And, yet they got punished for it. Another form of emotional dishonesty is combined with hidden prejudice. For example, a new hire joins a company because they met the company job qualifications, but afterwards, discriminators at the company realize they hate that person, and yet they "smile" every time they see them and they act as if "they're doing great". If that person does a bad job by mistake (everyone makes mistakes), the discriminators continue "smiling" and pretending "everything is fine", which puts the new hires at ease for artificial reasons instead of actually receiving normal work feedback that helps them improve their work performance. One day, the discriminators use that lack of improvement in new hires as justification to fire them, but only because they hated them since day one and were not willing to offer them the same feedback they offered other hires that they "liked" for emotional bias reasons unrelated to work. Again, that is a form of covert discrimination.

5. Double Standards: having double standards is common in non-covert forms of discrimination too, but it is a lot more subtle in covert discrimination. It can also be a form of indirect discrimination via preferential treatment for some people over others. For example, some employees are allowed to be loud and inappropriate at meetings and be late at delivering their work even though it is a general standard that all employees must be respectful at meetings and must deliver their work on time. For example, a company would allow someone to be mean to and unsupportive of their colleagues, but if any of the colleagues tried to defend themselves against that mean behavior, they are labelled as "the enemy of teamwork" while all the wrongdoings of the initial perpetrators who started the real wrongdoing against their teammates are ignored. Another example of this is a company that claims to have policies against discrimination, but they practice Ageism openly in their hiring practices without ever treating it as a form of discrimination. In fact, many companies (but not all) that claim to be "against discrimination" often do so with double-standards that mask covert discrimination. After all, if a company advertises itself as "against discrimination" that would make everyone believe at face value that there is no discrimination going on there when in fact there might be some very bad forms of covert discrimination going on at such companies (though not all of them).

6. Fake Love: in order to keep a facade of love for everyone, including people that are discriminated against, discriminators would provide the people discriminated against with a false exaggerated form of "love" that belittles them with baby-talk as if they are helpless little children that could not succeed with anything on their own. I am not talking about offering sincere help to someone who asked for it. I am talking about forcing "help" just to make someone look bad no matter how many times that person proved themselves with past good performance and how many times they tried to say they 'don't need any help' because they did not truly need it. And, that is while discriminators treating everyone else normally as mature empowered adults who do not need their help unless it is asked for. This is another form of covert discrimination.

7. Unavailability & Lack of Interaction: some discriminators will make themselves available to most everyone except one person or a few people in their team, company, or community, with which they will feign lack of availability or will be extra lazy towards respectfully providing them with availability, often as a result of personal prejudices and biases against the people discriminated against. If the problem is brought up to the discriminators, they will avoid discussing the problem and pretend "everything is fine" and they are just "busy as usual". Again, that is a form of covert discrimination as those discriminators do not treat everyone that way.

8. Lack of Sympathy: some discriminators will treat some people as if they do not have human feelings like all other human beings. They will be very cold and distant towards them while putting on a pleasant face to everyone else. The people discriminated against never did anything wrong, so this is a form of covert discrimination against them.

9. Not Owning Up To Error: discriminators will often continue their discrimination even after it is pointed out to them because they do not like owning up to their error like mature adults, yet instead, they like to offer lame excuses like children. Obviously, no good work ever got done with lame excuses, but still they insist on offering lame excuses instead of addressing covert discrimination.

Now, let us wrap up by providing a legend of terms used in this article.

• Covert Discrimination: discrimination that is done covertly to escape detection
• Microdiscrimination: discrimination that is done to one person or a few people only, often not sharing any commonality in a minority group that could offer them protection
• Personal Discrimination: discrimination that is done to one person only. This is often the most difficult kind of discrimination to detect because there are no other people that could report the same experience as the one person being treated with discrimination.

As mentioned before, this is a live document, so it will be updated whenever new information about the topic is uncovered.

Expect covert discrimination numbers 7, 8, and 9 to be practiced by discriminators who read this article. 

Please share this document with everyone to spread awareness of the problem of covert discrimination, especially if you have experienced any form of covert discrimination yourself. 

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.

Lack of Support in the Software Engineering Community Violates The Software Engineering Code of Ethics

Some Software Engineers mention "not being interested" as an excuse not to help someone with something that could benefit customers or the Software Engineering community at large when the real reason is in fact covert discrimination against that person and lack of effort to treat them as an equal and equally respected member of their community. Know that Software Engineers have to abide by the Software Engineering Code of Ethics: 

https://www.computer.org/education/code-of-ethics

And, it includes the statements: 

• "Software engineers shall act consistently with the public interest."
• "Software engineers shall be fair to and supportive of their colleagues."

So, if someone gives you an excuse of "not being interested" to avoid helping you out with a public interest matter out of discrimination against you, know that they have conducted themselves in an unethical manner, and remind them of what they signed up for when they became Software Engineers, whether implicitly or explicitly.

This even extends to matters like Software Engineers not wanting to check out certain technologies/libraries that could greatly help the public interest just out of discrimination against the technology/library creators. It also covers matters of Software Engineers not wanting to learn and improve certain skills through frequent attendance of local user groups that can improve the practice of their profession.

After all, that is covered by the statement: 

"Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession."

I am including the short version of the Software Engineering Code of Ethics below for your convenience:

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Ethical Disagreement Demands Sharing Reasons and Allowing Debate

When ethical Software Engineers disagree about something, they always share with others their reasons for disagreement because they care about others' well-being and want to provide them feedback to help them course-correct when they are wrong for the benefit of the community at large. Also, ethical Software Engineers always humbly open themselves up to debate to acknowledge the possibility of being wrong and to benefit from correction if needed. By sharing their reasons for disagreement and allowing others the room to debate, they objectively explore the topics of disagreement until they arrive at a mutual understanding with others whereby both parties either correct themselves gradually or reveal points that the other party was not aware of until they resolve all of the disagreement successfully.

As such, telling others the reasons for disagreement and staying humbly open for debate are two very important characteristics in ethical Software Engineers that are required for effective team work. 

Software Engineers who try to avoid providing their reasons for disagreement not only show a lack of care about improving the knowledge of the other party and community at large to improve collective work quality long term, but they are sometimes masking hidden discrimination against the person they are disagreeing with. Sometimes, they do not want to accept a correct version of the truth from someone else just because they do not personally like that person or actually hate that person, and do not want to treat them with equality or as equals to all members of society, yet want to maintain a higher ground above them. Silencing debates becomes then a tool for masking discrimination because if no debate takes place, the disagreeing Software Engineer who does so purely out of discriminatory reasons could never be found out. In other cases, getting unreasonably angry and silencing debates happens simply to avoid revealing lies that the Software Engineer believes and lives at the expense of everybody else, which they want to maintain to keep a lazy or incompetent work ethic while customers and other Software Engineers are paying for their laziness and incompetence. It is like someone who wants to continue to believe in Santa Claus at the expense of everyone else instead of hearing and accepting the truth, by requiring everyone else to work hard at maintaining the lie that Santa Claus exists in all their interactions even if that lie is basically hindering work quality significantly for customers. 

In summary, ethical Software Engineers always provide reasons for their disagreement while humbly opening themselves up for debate. Not providing an explanation for the reasons of disagreement and silencing debates are often immediate tell-tale signs of a non-equality-minded discriminator. If someone avoids telling you what they disagree about and do not want you to debate the disagreement any further, know that it is a red herring as they are not treating you with equality and objectivity, or are masking a lie that they want to live at the expense of others.

10x Developer Puzzle, Solved!!!

Here is a thought! The mythical 10x Developer is simply a developer that eliminates 9/10 of unnecessary over-engineered code, and then writes the remaining 1/10 of the code needed at the productivity rate of a 1x Developer!

Such a developer might come across as a 10x Developer to others when in fact, all they are is a 1x Developer that knows how to cut the fat of over-engineering out and avoid unnecessary overhyped libraries/languages/technologies to eliminate 9/10 of development waste and only do 1/10 of the work otherwise done. 

I believe I have just solved the 10x Developer puzzle for once and for all! The 10x Developer mystery has been demystified for good!!

P.S. Of course, there is no I in a team! What was mentioned can be followed by all members of a team. In the end, it is not about any individual in a team. It is about the team delivering the best work possible for customers. 

Can You Afford To Be Too Busy for Long-Term Indirect-Value Activities in Software Engineering?

Software Engineering activities are split between ones that provide direct value to customers in the short-term and ones that indirectly benefit customers in the long-term. It is important to have a good balance of both in order to ensure the long-term viability of Software Engineering work and continuously offer maximal value to customers. The best Software Engineers out there are those who have mastered the skill of balancing short-term direct-value activities with long-term indirect-value activities.

Examples of short-term direct-value activities are gathering user requirements from customers, breaking requirements down into use-cases, writing implementation code, doing QA testing, and deploying software into the cloud. 

Examples of long-term indirect-value activities are reading tech books and blogs, learning new technologies with vastly different approaches to what is commonly followed, building toy projects that explore new ideas, and attending local tech meetups and software conferences.

Developers who engage in short-term direct-value activities without engaging in long-term indirect-value activities end up stagnating in technical skills and getting stuck in what is known as Single-Loop Learning (read about Single-Loop Learning and Double-Loop Learning here: https://en.wikipedia.org/wiki/Double-loop_learning). In other words, they get stuck inside the box without intelligent questioning of the technology approaches and libraries being used. So, they passively accept what some library creators decided (including what they decide in future library versions) without thinking for themselves, thus losing the ability to think outside the box and make exponential jumps in productivity. Instead, they might make contributions to libraries inside the box of what they already use instead of exploring much different simpler and more elegant solutions outside the box. 

Often, such developers practice an anti-pattern known as Hero Worship as they position some library creators as Heroes on top of everyone else, making themselves believe that the Heroes are way above anybody else's ability to think, and thus they shut down their mind and default to relying on the thoughts, ideas, and works of the "Heroes" without ever questioning them. That's instead of actually thinking for themselves and living by the truth that everyone makes mistakes and everyone could be wrong from time to time, including library creators. As a result, they end up adopting highly over-engineered solutions that waste a lot of productivity due the solutions being originally created for the large organizations of the "Heroes" and their specific project situations.

The single loop referred to in Single-Loop Learning is the short-term feedback loop that is relied on to improve things within the box of previously selected technologies without periodically questioning the entire box in an outer long-term feedback loop to explore brand new novel approaches that might provide exponential jumps in improvement (Double-Loop Learning). For example, developers that use Java Enterprise Edition + Spring could continuously discover weaknesses in an inner feedback loop that leads them to upgrade their Java Spring libraries repeatedly. They won't have exponential jumps in productivity unless they employ an outer feedback loop that enables them to re-evaluate all their technology choices and discover that the dynamically typed Ruby language and the Rails web framework could offer exponential improvements in productivity for many business domains that would cut 12 months of work down into 6 months or less. 

Unfortunately, developers who stick to the safe box of technologies they are accustomed to instead of practicing Double-Loop Learning end up in a rot due to the Dunner-Kruger Effect (https://nesslabs.com/dunning-kruger-effect), meaning they end up not knowing what they don't know as time goes on. So, when others discover new ways to improve Software Engineering productivity and quality in an exponential jump that renders 12 months of work doable in 6 months or less, the developers stuck inside the box end up missing out on those benefits completely. It's like Java developers that have never experienced the huge productivity benefits of Ruby on Rails. They don't know what they don't know. Eventually, their competitors end up swooping in and taking their business, which is what sometimes causes layoffs at companies. In other circumstances, such developers are fired due to not delivering work at maximum capacity when others are able to do their work in half the time or less. 

One metaphor to explain this is how shipping services advanced over time. More than a couple of centuries ago, shipping companies relied on horse carriage. Later, they relied on the train. After that, cars were invented, so shipping could be done on trucks. Finally, airplanes were invented and sped up the ability to ship packages even further. If horse carriage shipping companies kept themselves too busy with horse carriages pulling the weights of their shipments to actually learn how to utilize newer technologies of shipping, they would have allowed their competitors to beat them to learning how to use newer methods of transportation and finish work in less than half the time needed for shipping on horse carriage, thus winning their business over. 

Some developers like to tell themselves excuses, like they are too busy with customer value adding work to spend any time reading tech books or exploring new novel technologies. Unfortunately, this attitude neglects the big picture and the fact that long-term indirect-value activities do bring more value to customers even if it is not apparent as they ensure the delivery of maximum value to customers in the long-term. So, not spending time on such activities results in worse quality work for customers in the long-term. Meaning, such developers resign themselves to doing bare-minimum quality work for customers by avoiding long-term indirect-value activities instead of boldly spending out of the box time that would enable them to do maximum quality work for customers over the long haul. In turn, they end up opening the door for their competitors to eat their lunch, whether by taking their company business or taking their employment positions. 

Making excuses to avoid something is always a red flag that signals mediocrity and a mediocre work ethic. Good Software Engineers always take responsibility instead of making excuses, and they have a healthy engineering curiosity about better technology approaches. No one can be thought of as a good engineer without having curiosity and passion for learning alternative methods of engineering that could offer better benefits to customers than whatever technologies are being used. Developers who make excuses usually do so because they have gotten too attached to and too comfortable within the confines of whatever technologies they know and have gotten too lazy to learn new technology approaches that shatter the comfortable box they have been operating inside of. Additionally, some of those developers are simply selfish as they care more about earning a paycheck with familiar work than doing their absolute best work possible for customers everyday. As such, those developers cannot actually be trusted to do the best work for customers. This matter goes further than keeping one's business and job. Those who do not do the best work possible for the amount of money paid to them by customers while claiming to belong to one of the "best businesses" out there are literally lying to their customers and engaging in unethical behaviour.

In summary, Software Engineers must engage in a good balance between short-term direct-value activities and long-term indirect-value activities to ethically ensure the long-term viability of Software Engineering work and continuously offer maximal value to customers, which helps in guarding their business and job from the competition.