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. 

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!

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!

Christmas-Themed Retrospective at Lexop

Today, Ajay Komirishetty (software engineer) complimented me by name at our Lexop team's Christmas-themed retrospective!!!