DEV Community: Michael Landry

A Tier List for Company AI Strategies.

Michael Landry — Mon, 12 Jan 2026 00:36:24 +0000

Often these days, conversations inevitably turn to the topic of AI. While we should expect this as it has and will continue to transform our world, I can't help but note the rather disparate takes, understandings and discourse on the matter, even amongst IT professionals. While most of us don't possess deep academic training on the subject, myself being more of a hobbyist for most of my engineering career, and have spent most of our existence in a world where AI was just a curiosity, I always observe a certain juvenile quality to these conversations, as if the masses were thrust into carrying on an informed conversation on a matter that takes years and years to master.

And so I offer to the reader this tier list of organization AI strategies. These conversations help me realize that the majority of companies are still adjusting to this new world, with most making sincere efforts to appear informed yet still searching for the path to post scarcity AI nirvana.

Aside from drawing parallels between colleagues and companies, it frames the topic of AI in terms of a natural progression from the nature of the change, to level of impact it can have, and what to expect from the next level of transformation, and what will be needed to reach the next level.

I offer these 5 tiers, with a fun culinary spice to them. Tier I contains more points than any of the other tiers. Seeing how all organizations start their journey here, and that most companies are at this level, this is to be expected.

I: Sprinkle

Light opportunistic exploitation of AI solutions

Characterized by 'sprinkling' AI on existing solutions and processes.
Often, these 'AI' strategies are just application of traditional IT/computer solutions mislabeled as AI.
Tier I strategies also claim AI utilization through curation of AI-labeled vendors, tooling, basic plugins, and integrations.
Tier I strategies are often broad yet shallow, and lack measurement or KPIs.
No formal strategy, training, or organizational mandates provisioned nor imposed.
Tier I strategies are spearheaded by leaders with very little AI fluency or perhaps technology in general, who rely on an assumed instinctual understanding of AI and its value proposition (as an example, contrasting different AI methodologies such as deep learning, neural network, generative AI, LLM, etc, and how these techniques differ in suitability to solving different problems).

II: Stir

Deliberate integration of AI into specific workflows and tools.

Strategists have at least a basic understanding of AI as a field.
Vendors and tooling undergo informed analysis before adoption; such integrations feature custom integrations and configurations.
Organizational adoption features basic guidelines and training.
Focus on boosts and efficiency is targeted.
Changes are still additive rather than transformative.

III: Simmer

Deep embedding of AI across multiple functions, with custom solutions and data feedback loops.

Organizational leaders either possess AI fluency or consult and delegate AI adoption and operations to informed strategists.
Fine-tuned models, internal AI platforms, agentic workflows (AI agents that plan and execute multi-step tasks), and RAG systems.
Cross-functional governance, data infrastructure investments, and measurable ROI tracking.
AI influences decisions, optimizes operations, and starts reshaping how work is done.
Core contributors (engineers, dbas, managers, etc) must up-skill in the AI domain. Legacy roles and titles are augmented and replaced by AI oriented skillsets.
The organization recognizes the criticality of quality data, and begins investment and enhancement of data architecture and data sourcing.
The organization is "letting AI simmer" — changes are gradual but pervasive.

IV: Bake

AI is baked into core business processes and products; the company redesigns operations around AI capabilities.

Enterprise-wide platforms, autonomous agents/swarm systems, predictive analytics at scale, and AI-driven automation of complex workflows.
Significant talent hiring, ethical frameworks, and cultural shift toward AI fluency.
New revenue streams or cost structures emerge from AI (e.g., AI-powered products or services).
AI is no longer a layer — it's fundamental to how value is created.

V: Feast

AI-native transformation: the entire organization is built or rebuilt around AI as the primary driver.

The organization is now an industry leader thanks to an exponential advantaged realized through AI.
Continuous AI-human collaboration and evolution of proprietary AI models.

Quick hits

My new phrase-of-the-week goes to artisan code. It will be difficult to talk about code as just code anymore. Instead, we will have to qualify it somewhere on the artisan code <--> AI slop spectrum. I can imagine myself in the not-too-distant feature telling people about how companies used to source all of their software directly from wetware, but that such a thing is a luxury for deep-pocketed patrons skulking in Parisian botiques yearning for the beautiful, clean code of halcyon days.

Constraint-based Design

Michael Landry — Fri, 23 Feb 2024 21:03:29 +0000

Image courtesy of https://www.vectorstock.com/

This article seeks to establish the concept of Constraint-based Design (CBD), especially as it pertains to code design, system architecture, and the Software Development Lifecycle (SDLC). There are similar articles and scholarship on this eponymous term, however, I am to establish CBD as critical to all participants of software projects.
Constraint-based Design is the idea that the capabilities of a system or solution are best understood not only by its features and capacities, but also, if not more so, by its limitations and constraints. CBD is a very effective paradigm to adopt during the design and architecture phases of SDLC. It, paradoxically, makes for simpler and easier designs and problem-solving sessions by limiting the decision points and options to well-understood and predictable patterns. It also makes for better developer experience as engineers come to rely on, familiarize, and continually enhance known patterns and solutions. Stakeholders, Project Managers, and Product Owners are also able to make much more informed decisions when considering customized solutions for specific problems solved by CBD systems. Lastly, project costs are ultimately reduced as CBD forces implementations into highly reusable components that are very well understood and robust.

A real world example

If you needed to fly somewhere. You would task engineers to build a plane. A plane is very good at flying; that is its singular purpose and responsibility. In some circumstances however, it turns out that it may be useful to have a vehicle that can both fly and float. Thus, the plane is redesigned for seaworthiness and liquid propellers. This is where care needs to be taken. This is not a case against amphibious planes, that seems cool and situationally useful, but it illustrates the problem when there is a lack of CBD. What if this vehicle needs a torpedo bay ? How would a torpedo bay effect its flying ability? Would adding a bomb door cause the vehicle to sink? The analogy tells us that adding features, even a singular feature, can complicate or adversely impact the other features offered by a solution. The analogy is also that of the need to beg an important question, does this vehicle even need to be amphibious? CBD is essential in driving better design conversations. Perhaps some situations merit the amphibious vehicle, but a team that embraces CBD must first ask themselves, are there alternatives that satisfactorily solve the need at hand? With the constraint in place that the solution must be an airborne vehicle, then the design team is forced to consider more practical solutions to whatever the need is, and also consider the cost and benefit of any such design. The truth is that every system has constraints and limitations. Building systems without adopting CBD doesn't result in boundless, omnipotent solutions, only solutions where its shortcomings are poorly understood.

CBD is a mindset

CBD is ultimately a mindset; a paradigm we should all advocate and adopt. With it, stakeholders better understand the limitations and capacities and strengths of their solution. Product Owners should realize better returns on resource investment by solving variations on recurring problems by acknowledging the constraints of a system and leveraging the existing features and capacities. Architects will build frameworks designed to solve anticipated problems; these frameworks are the primary source of constraints, and by creating such constraints, they can also make empowering assumptions about the system and system state which can be exploited to provide predictable, regular, and well understood solutions to known typical problems. Solution designers use existing patterns precedent to compose solutions to new problems. Engineers work within the confines of tools and states where certain assumptions can be guaranteed and exploited.

Conclusion

It is usually more beneficial, and informative, to view systems and their constraints, rather than their features. Understanding and embracing system constraints protects stakeholders from mal-investments in dysfunctional and confusing solutions, leads to better and simpler designs and yields higher quality and more robust implementations.

New Job? New Project? Existing Project needing some tweaks? Go through this checklist ☑️

Michael Landry — Wed, 02 Aug 2023 22:55:06 +0000

I hope this article finds you well! I've compiled this checklist for the benefit of anyone reading this, be they an engineer or manager, experienced or junior, starting on a new project or trying to tweak an existing one for better results. Starting a new software project can be both exciting and overwhelming. Whether you are an experienced developer or a newcomer to the world of software development, having a well-defined checklist can significantly improve the chances of success for the project and your time with it.

1. Identify the Product Owner

This is the most important box to check. Your PO determines the success or failure of the project. This person is responsible for understanding the problem, visualizing the solution, and translating it into requirements that can be feasibly implemented by the team and their technology and capacity. The biggest painpoints all orbit around this individual, such as "timelines," "estimates", "scope", and goals, and for anyone with a decent amount of experience in the game knows these lyrics show up in every chorus.

If you have a rockstar PO who's killing it, then great! Your project is on a great start! For those projects where this isn't the case, I'd offer the following points:

Official Scrum guides specify that the PO should be a single person, and with good cause. If your project is going to deviate from this decision, there should be a well-understood reason as to why.
There is probably no such person who completely will understand both the business side and the technical side of a project. For that reason, it should be understood that the PO will ineviatbly have to delegate some responsibility to appropriate collaborators, and that's okay. With that said, it should go without saying that the team should do everything to support the PO and help them achieve their goal, including regular communication and advisement.

2. Knowledge is flowing

Everyone should feel like they have all the nessessary information to be successful. This should all be very transparent and accessable. Good signs are tickets that have great descriptions, and more importantly layout steps that can be followed in order to test that the work is complete, and that the scope is well defined. If it seems that the work is not clear for the contributors that are doing the work, then consider the following tips:

Ask for people to ask questions and get feedback. Ensure that everyone feels comfortable asking for help.
Meetings are the primary way to communicate, but try to steer away from meetings that are too long or too frequent. I always find better results creating shorter meetings, with only the nesssarry participants, and whenever possible I like to brand them more as 'workshops' than meetings.
Really focus, as a team, on creating good tickets. Working from a perspective of what should it do, to how to test it, and then finally how to implement it will be key. Test Driven Development!

3. The developer loop

The developer loop should be as quick as possible. This means that the time between making a change and seeing the results of that change should be as short as possible. This is a key factor in developer happiness, and it's also a key factor in the quality of the code. It's not feasable to meet work commitments if the developer loop is too long. If it takes too long to see the results of a change, loop into better tooling that allows more immediate feedback, such as hot reloading, or embrace a test driven development approach where business requirements can be declared and confirmed using a test harness that should in most circumstances provide faster feedback than normal approaches.

4. Following good SDLC practices and doing them correctly

It should go without saying, but following good SDLC practices is key to success. This means that the team should be following a well defined process that is understood by all. This process should be well documented, and should be followed by all. If there are any deviations from the process, they should be well understood and documented. It's very easy to skip things that don't seem to matter, like retrospectives, especially when project hardships are being felt. However, following processes matter the most when things become difficult. If it feels like SDLC processes are being skipped, then have conversations about why with your colleagues, and you may find that you may not be alone in your feelings, which can be empowering to bring the team back torwards success

5. The Backlog is in good shape

While it ultimately falls on the Product Owner to manage the backlog, it should be in everyone's interest to ensure that the backlog is in good shape. Consider the following tips to ensure this:

Is there a regular cadence where teammates review and refine the items?
Does the system in place fit the team and the project? Perhaps creating more structure around tickets could help foster a better approach to creating tickets, such as designating custom fields that allow ticket creators to define steps to test, scope, and other important information.
Does everyone have a similar understanding of the relationships between tickets? It can and should vary by team and project, but within a team, there should be a common understanding of how tickets and their heiherarchies are organized.

6. Foster the culture of testability and observability

Testing and observability should be at the forefront when planning new project challenges. This means that the team should be thinking about how to test and observe the work that they are doing. As alluded to earlier, encouragement and guard rails, such as ticket templates that ask for such information, can help foster this culture. When planning for a project, consider allowing the testers and quality assurance team to take an active, rather than reactive, role to the design and implementation of the solution.

7. Position for success, never failure

Ultimately, everyone on a team should feel like they are in a position to be successful. Success should be the default. If delays and failures are the norm, then the team will have to make significant (and ideally blameless) changes to the project approach. Consider the following tips to ensure that the team is positioned for success:

No existing process or tooling should be considered sacred. If something isn't working, then it should be changed.
Is the work too difficult or structured in a way that makes it difficult to complete? Consider breaking the work down into smaller chunks, or reorganizing the work into a different structure.
Are contributors empowered to reach out, and communicate, and collaborate? Often times, the challenges of a project are not nessesserily hard, but that people don't have what they need to succeed, and they will need to get it from someone else who has what they need.

Conclusion

By following this comprehensive checklist, you can lay a strong foundation for your new project and increase the chances of its success. Remember that flexibility and adaptability are crucial in the dynamic world of software development, so be prepared to iterate and refine your approach as the project progresses. Good luck with your project!

Improving Human-Computer Interfaces

Michael Landry — Fri, 24 Feb 2023 20:15:57 +0000

Cover art copyrighted by Fantasy Flight Games

Ideally, as professionals who interact with computers to complete their work, minimizing the friction between our thoughts and querying the appropriate data or updating the appropriate records or accessing the necessary system should be a paramount goal. The more imaginative minds might arrive at the following mental image, clamoring that useful convenient virtual reality can't come soon enough.

Image by Urku 3DArt

This is a great idea, but, being realistic, this is a ways off, and there is plenty of friction I see at play that can be removed with well-focused effort. Consider the following exhibit:

This is a common sight I witness on a daily basis, and occasionally it elicits a comment in jest, but for me, I'd stress at the thought of my virtual work area, where I spend the majority of my time contributing to building a better place, as being disheveled like this.

In the worst case scenario, if we cannot see the tabs and have no recollection of where the desired tab would be, the worst case outcome would be to have to check every single tab. Multiply this by the number of times changing interfaces is needed in order to complete a typical task, we are looking at a lot of lost time here. (For you time complexity junkies, the worst case time cost here is xy, where x is the number of tabs typically open and y is the number of times the user has to access an interface, 2 typically large numbers, costing a polynomial amount of time when it should be a constant operation)

As a software engineer, I want to spend my time building and delivering software, not wrestling with my tooling.

How did this happen?

Turing back the clock, I have a distinct memory of the Opera Web browser being the first major browser to introduce tabbed browsing. I can't claim that that information is accurate, but historically speaking, shortly after tabbed browsing debuted, every browser had it, and people came to use it, because it was an improvement over the existing design. Unfortunately, the typical user of today can expect to require touching multiple web interfaces, numbering in the dozens for a single task, and the tabbed browsing approach is no longer sustainable. Noble efforts are being made, in form of 'grouped tabs' and other gimmicks, but ultimately, a paradigm shift is needed to tackle the issue properly. Let's se if we can do better!

Thinking beyond

As per the title, I didn't want to make this a blog specifically to be a diatribe on the shortcomings of browsers, but the problem in general. "How do we remove as much friction between the brain and the computer system?" Thinking deeper about a computer, its primary purpose in interacting with humans is to show requested interfaces to the human. What I really want to focus on is improving the journey from the inception of the thought in the brain to the interface on the screen. Most minds usually conclude that a specific task needs to happen, and a specific tool(interface) will complete the task. Using the following mental conversation as an example:

"I need to look at production logs"

The only mental effort here should be to parse that idea into an input of sorts that could then be used to fetch the appropriate interface. Perhaps something like

" logs > production"

With further possibilities to disambiguate the parts of production as needed.

This simplicity certainly outshines the current status quo which is usually something along the lines of

"I need to look at production logs.
Is that an application installed on my computer, or a webapp?
Its a web app... Okay, now I need to find the (right) browser (if its already open, or I need to open a new on?)
Browser already open here, and I have 40 tabs open. Gotta search through these tabs... Actually, I'll just open a new tab.
What is the URL for production logging? I've stashed it into my bookmarks somewhere... Looking at the bookmark library now, how is this sorted? Okay, I know, navigating through the tree of directories to get to the desired bookmark.
new tab opened, now I have to navigate this site in order to get to the correct interface to solve my problem..."
And on and on...

Optimizing the OS UI-UX.

What I am aiming to establish is that operating systems were designed first and foremost to mediate between computer software and the underlying metal, and secondly as a suite of user interfaces intended to be as generic as possible, IE, NOT optimized for efficiently executing common workflows flows of a particular user. With its rich and storied journey of going from punch cards to assembled native applications to "byte code" apps that run in virtual boxes, to browser apps and every branch, side road, and failure along the way, computers are always evolving according to the "laws of the jungle" rather than whatever was necessarily the best user experience. What I also want to suggest is that any interface and interaction can, and should be investigated for improvement. As a developer, I spend a lot of time in a terminal, and not necessarily by choice, and I really like to think in terms of 'build the thing' instead of ./gradlew -A -s -xsns 2048 10240 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | egrep --line-buffered "^........(GET |HTTP\/|POST |HEAD )

Candidate Solutions

We will all have different tastes, and I wanted to establish a springboard of sorts for thinking about the nature of this problem, and ways to improve. I'll share some of the following techniques I've come across which you are welcome to use or as inspiration for your own taste and situation.
I've found the Keyboard Maestro application to be the most powerful weapon in my arsenal on a Mac for improving my day to day toil in building the interfaces I want. It's an app that I use to convert my computer into a friction-free tool that solves the problems I face day to day.

Requesting the desired interface

The majority of the value Keyboard Maestro delivers is in the form of loading the right interface I need. After several iterations, I've arrived at the following solution. After pressing a specified key (I chose F1), the user is shown a list of options to select. Once presented the user may click (or, more often) type the target choice (once enough letters are submitted to unambiguously identify the target, the option fires).

That's it.

Every interface I might need is stored in a tree of words. I just have to know the name I assigned it (with the option of adding redundant options to reach the same interface), type it, and I am already where I want to be.

Massaging the approach

Well almost. There is the option, and the temptation, to group different interfaces into collections, then bind that collection to various keystrokes or triggers, but I found that lumping everything together into a single group cut down on the extra overhead of trying to remember or assign specific interfaces to specific groups and the resulting and tedious internal philosophical discussions of deciding how to group items, why group them that way, and what to do when something breaks the convention ... With the exception that I've bound IDE-projects interfaces to F5 and repository viewers (aka Github deeplinks to corresponding projects) to F8, and interfacing with project management software (aka Jira) with F2 due to the frequency of these invocations.

Story time! An example

My personal experience as a software engineer leads me to conclude that I probably spend more time going back and forth with colleagues about story requirements, details, and updates than I do actually implementing them. As such, I've put some thought and effort into removing the friction of dealing with Jira stories. Consequently, it makes for a fine example of what is possible using an approach like mine. Keyboard Maestro comes with easily programmable GUI interfaces, which I exploit in order to facilitate receiving prompts for only what the computer needs, and letting the scripting deal with the toil. I have such a GUI interface I use for All Things Jira, which becomes the target interface I invoke when that becomes my task. As mentioned previously, I could press F1, then type 's'-'t'... or just hit F2 as it's common enough to merit an even faster shortcut.

pressing F2, as you see here brings up a default value of 12345. That is my 'current story number'. I could overwrite it with a different number, at which point the new number becomes the 'current story number'. That value will also populate in other interfaces across macros.

"open in chrome" will open the webpage for the ticket in question. It is a blue button meaning that its the default choice if 'enter' is pressed, so F2-enter brings up the details of my current story. Super convenient!

"paste story url" puts the url of the current story on my clipboard. This is a huge time saver when I need my colleagues to take a look at said story.

"set current story" binds the current story number with a 'description', and remembers it forever in a dictionary built into Keyboard maestro. Binding a 'description' to a story number is also immensely convenient, as more often than not, there is a great deal of ceremony and ritual around branch names, commit messages, pr descriptions and juggling tickets. and the description really comes in handy for tying all that together. Its an example of set-it-then-forget-it way of describing tickets and never having to worry or fret about branches, tickets, pr descriptions, and commits getting out of sync.

Alternative Tools

For further considerations, I'd recommend auto hot key for windows, toby extension manager, and the time proving practice of writing shell scripts is always available.

Conclusion

Imaginative sci-fi authors have provided fantastical concepts for empowering us bags of meat to access cyberspace. The current reality is still quite far removed, with many still caged up in cubicles pecking away at plastic keys. All the same, some effort and imagination can cut the friction and toil that inserts itself between us and our craft, and hopefully some of those ideas will spill over into how mainstream user interfaces are designed and delivered to the masses.

Standing on the Shoulders of Giants: the Articles and Resources that have Shaped my Career.

Michael Landry — Sat, 26 Nov 2022 02:46:54 +0000

I am sharing this list of articles, videos and books as the topics covered are critical to any developer. These are the articles I found looking for answers when I needed them; there may different or better works covering the same ideas that we all find on our journey, but these were what I found when I needed them, and they have molded my ideas on software engineering. As a writer and one who wants to give back to the community, I also found that creating this post solves two problems: it helps me consolidate all of the critical but not obvious knowledge about the profession, and it helps me identify the major gaps of knowledge that needs to be penned to paper, and while I can certainly provide my take on all of these critical issues, I don't think that I can do it better than what has already been authored, and I really want to focus my efforts on high impact topics with little exposure. I'll probably periodically update it as they come to me.

With that intro out of the way, here is the list, and my thoughts on their importance.

Software Development Lifecycle

http://agilemanifesto.org/

No excuse not to read it if you have not done so yet. It's only 413 characters and it can fit in 2 tweets. It really helps to frame what Scrum tries to do, and understanding the Agile Manifesto makes seeing Scrum for what it is, a logical yet somewhat simple tool for reliably building software

The Mythical Man Month

The original Encypcopedia of SDLC antipatterns. What is striking is that these antipatterns are really not obviously antipatterns, illustrated by the fact that these practices continue to scourge software projects still today. A reading of this book brings with it an understanding that the hectic, panicked, and chaotic ambience of the project is a pretty typical experience. The reader would also possess the ability to pinpoint the particular practices that enivitably bring about the failures.

https://blog.codinghorror.com/we-hire-the-best-just-like-everyone-else/

If you don't know who Jeff Atwood is, you should. His articles are a treasure trove of software-people intersections. We who also practice Clipboard-Driven-Development (CDD) also owe him a debt of gratitute for https://stackoverflow.com/. 😉

The Temple of Busy

Cynical yes, but quite on point.

Programming

Object-Oriented Programming is Bad

Provocative but well thought out. It is also a reminder to listen to that alarm going off in your head when you find yourself disagreeing with the sacred idols of the industry.

The Kingdom of Nouns

Key ideas when comparing Java to other languages. The article has aged well having watched all of the new versions of Java doing everything in their power to ship out functional features without having to conjure up some intermediary class to house it.

KISS and YAGNI

May want to toss in Principle of Least Suprise as well

NeetCode

Data structure and Algorithm training. Aside from the obvious Crack the Coding Interview , Neetcode has provided the absolute best resource for it,

Functional programming

Versioning and build pipelines

Gitflow

I don't actually condone the suggestions in this article, nor does the author anymore for that matter, but the majority of the software industry still reveres these concepts, thus making it extremely important reference material

95% of your Project Hardships are Caused by this One Thing, a Failure to Communicate.

Michael Landry — Sun, 06 Nov 2022 00:03:25 +0000

"Good communication is the bridge between confusion and clarity" according to Nat Turner. If confusion grips your project on a daily and weekly basis, as I often find for many projects, then it befits the entire team to recognize, accept, and address the root cause: we are not doing a very good job communicating our ideas.

Good communication is the bridge between confusion and clarity

I would even make the case that the majority of the more recognizable smells, anti-patterns, and mistakes are just specific instances of failures to communicate: incomplete requirements, wrong abstractions, ticket deadlocks, and failing processes to name a few.

Defining Communication

The concept of communication is deep, and should rightly be considered a critical skill needed for success in any endeavor, and one that has to actively be honed. With that being said, the fundamental fact of communication is that the ability to express oneself pales in importance to the ability to listen. Being mindful of this listening component is important when understanding how it impacts a software project.

I also highlight an ofter overlooked fact, source code is a form of communication. It is probably the most complex way that people communicate in a regular basis. When writing source code, the author is writing for at least two audiences, humans who will read it to derive specifications and to maintain it, and for compilers that will execute its instructions in the most strict of adherence to grammar and syntax. When evaluating the competency of a prospective software engineer, their ability to speak, write, read, listen, and communicate is going to be a much better predictor of their capacity to read and write source code than something more relatively banal such as calculating time and space complexities of a given algorithm. This is why I repeatedly endorse the merits of linguistic skills over all others, and that the right way of judging code is by clarity, lucidity, and understandability, and not complexity, sophistication, or even elegance. Experienced engineers write code that is easy to understand, not code that is so complex that only experienced engineers could comprehend it.

Outside of code, consider all of the following things and how they are manifestations of communication: unit tests, designs and diagrams, READMEs, meeting notes, agendas, emails, Slack threads, discussions, tickets, comments, code reviews, and on and on... All of these activities are chances to contribute to the success of the team, or to miscommunicate.

Examples of miscommunication and examples

Miscommunication	Example
Ambiguity	A colleague raises a discussion about a bug, but assumes that everyone knows which bug they are talking about, when in fact there are many bugs
Wrong Audience	A colleague authors a guide, but its voice drifts from deeply technical to more of a sales pitch, and entirely without a target audience in mind
Wrong Information	the wrong date for a deadline is set
Concealed Information	A colleague with critical project or corporate knowledge and information fails to disclose or document the knowledge.
wrong context	A discussion of pros and cons fail to take into account whether it is in regards to meeting an immediate need, or for long term planning
absence of communication	A technical ticket is written with no description, a README or document doesn't exist.
unresponsiveness	A colleague 'ghosts' requests, creating a bottleneck for some result
assumptions about the audience	A speaker assumes that the audience is highly technical, or knows obscure acronyms.
failure to listen	Every effort is made to inform colleagues about a concern, but no action is taken.
failure to discuss	Unforeseen challenges arise, instead of raising these new issues and alerting that deadlines may have to be pushed back, nothing is said, and the work silently fails

With so many ways to fail to communicate, one should never underestimate how much these failures can harm a project.

A Thought Experiment

To further cement this idea, just think back to the last hardship or failure on your current project. Was it caused by bad communication, or could have it been prevented with better conversation? I thought so 😀.

Recommendations

For you and your Career

My first recommendation is to understand the true gravity that miscommunication has on a project. Additionally to this, and my objective of the article, is that I want you, as civilly as possible, to call out miscommunications loudly and often as they create hardships on the project.

Secondly, I highly recommend improving your own communication skills. This topic is beyond the scope of a single blog post, but aside from the obvious recommendations, which one would immediately find after a few minutes of googling such as reading, using a thesaurus, and brushing up on grammar, I would attribute a large amount of failure to a not-so-obvious source: coloring and obstructing information through the prism of one's ego. While it might feel dropping an endorsement of a self-help book in a communication blog, reading The Power of Now has been very instrumental for me to pick up on these errors and how they happen.
In addition, I think that staying up-to-date on the latest industry trends through constantly reading articles like these are a great way to hone this skill, but taking on a writing hobby does wonders as well. I personally think that engineers should hone their writing skills just as much as one's coding skills.

What your Team can do

Research

There are plenty of resources on the internet that can help your team communicate better. It would not be a waste of time to implement some of the suggestions offered by more authoritative foundations, such as Atlassian.

Define Ubiquitous Language

I'll let Martin Fowler layout the case for it. Practically speaking, if your project doesn't have some sort of pattern for documenting the specific words that you use throughout the project, an easy win is to write it up and share it with the team.

Introspection and action

recognize the dynamics of your projects 'office', being especially cognizant of any hybrid or remote colleagues on the team.

Improve your code review process

This topic is getting a lot more attention lately, and deservedly so. This particular article by Erik Dietrich really distills the vitriol of the practice into words

Improve your meetings

A lot of communication anti-patterns are on full display at a typical project meeting. Fixing these meetings are a good starting point. Elon Musk has a lot of thoughts on the topic as well that resonate with my experience.

Conclusion

Software engineering is a discipline of communication, and software is built as a team. Great communication skills will serve you greatly as an engineer, and is paramount to becoming a leader in the field. You owe it to you and your team to make sure that the ideas that we share and receive are done correctly.

Dynamos vs Planners, an Important Profile Spectrum for Engineers

Michael Landry — Wed, 26 Oct 2022 20:18:41 +0000

This spectrum plays a very important role on how your job and career plays out, it's worthwhile to be aware of it.

I am writing this article as an informative piece, and so that we can put our hands on its link so as to give it a concrete name and description. It is not new information by any means; anyone who has slogged through one of those long annoying strongly disagree...strongly agree surveys to determine if you would be a "good fit" culturally will find this information familiar. Without further ado...

The Profiles

The Dynamo is your bootstrapper person. Most would describe this person as a "self starter", "showing initiative", "getting stuff done", "getting hands dirty", "working face first", and on and on. The Planner, by contrast, is going to be your individual that is detail-oriented and plans out the solution end-to-end. While I present these profiles here as being on a spectrum, if asked, I would refuse to identify with one or the other as both profiles have desirable features that are not mutually exclusive. However, it would not be entirely honest to claim that one could manifest as a perfect version of both profiles simultaneously. Now that terminology has been established, let's look at the implications, for both the project they serve, and how it shapes we engineers.

The Pros and the Cons

The Dynamo

Pros

Gets stuff moving and gets it done
Bypasses bottlenecks and deadlocks
Good at identifying and delivering meaningful and impactful results
Highly valued by managerial and business leadership
Tend to become highly visible individuals both within and outside the team
Often given ample credit, sometimes praised as project saviors

Cons

Susceptible of introducing technical debt of all varieties, especially that of wrong abstractions
Often makes unilateral design decisions without gathering or waiting for consensus from colleagues.
Requires good experience, knowledge, great effort, and boldness to actually be successful in rushing out changes against legacy code bases to deliver value
Dynamos can expect to rework a lot of implementations. For that same reason, Dynamos are inclined to provide little to non-existent high-quality unit tests or documentation.
Other critical facets of software development, including testability, developer experience, automation, maintainability, and documentation may be neglected by Dynamos.
Dynamos assume much riskier behavior, leading to volatile outcomes swinging from success and praise to termination and project failure.

The Planner

Pros

Planners view tasks through a large variety of lenses, considering many topics such as feasibility, optimal solutions, extensibility, reusability, testability, maintainability, good design, and plausible risk.
Planners are detail-oriented
Planners are more willing to build consensus amongst colleagues for solutions
Planners are more inclined to ship testing and documentation along with their tasks, often building out these entities before doing the implementation so as to having a gauge to judge for correctness.
Planners are very good at preventing a variety of classes of problems from ever harming the project by virtue of thorough research and planning beforehand.

Cons

Planners are susceptible to blame for, or causing, project delays and deadlocks.
Planners are prone to being bogged down by bureaucratic processes, and culpable of introducing and enacting new processes that do more harm than good.
It is difficult to identify, and much less quantify, the positive impact a planner can have on a project by virtue of preventing problems from ever arising, and will not likely receive credit for it.
Planners don't garner the same attention as a Dynamo might, especially amongst managerial and leadership colleagues.
Through more thorough conversation and documentation, Planners are less likely to retain unique knowledge crucial to the success of the project, thus making Planners more expendable.

Conclusion

I hope you find this topic exploration informative. My goal, having been a good Dynamo, a bad Dynamo, a good Planner, and a bad Planner at various times in my career, was to portray the profiles not as one being better than the other, but more in their realistic flattering and not-so-flattering light. The important takeaway I have is to identify this behavior, and that all projects throughout all moments of their lifetime need one profile over the another, and that we can and should adapt. Perhaps you recognize these themes in your own project, and see the effect that they can have. Perhaps you identify with one or the other, and find the conclusions similar to your own experiences. If not, leave a comment below! Thank you for reading!

Software Stories should be organized as Call Stacks, not Queues.

Michael Landry — Thu, 12 Aug 2021 02:30:56 +0000

Stories and Epics and Subtasks, ohh my!!
Dorothy the Product Owner

It seems no matter who I ask, I can never get a straight definition of what an “epic is.” I find this fact alarming. Agile teams all over the planet, replete with very intelligent people, opt to organize their work load in terms of concepts with nebulous definitions. That software projects both large and small, public and private, often come in over budget and late should come as no surprise given this fact, and I feel that a certain company, in prime position as the go-to choice for off-the-shelf project management software work and tracking, exacerbate the problem by providing solutions that force end users to classify and structure work into specific configurations, use specific terminology, and enforce hierarchal groupings, because let’s face it, corporations would fall apart without bucketing everything into one class or another. In my own struggles, I just go with a simple definition, epics are a collection of user stories (or tickets, or however you want to refer to your baseline block of work.) The point is, is that, while fixing all the Scrum confusion for every business is beyond the abilities anything or anyone currently possess, it would be nice to chip away at the problem.

But after thinking about the problem, trying to frame the whole scrum-agile work structuring thing into something sensible, simple, and effective is very daunting, so much so that I believe there is ,fundamentally, something wrong with a core tenement of this problem.

I want to propose a change to the paradigm, and I ask you to consider the concept, for you see, this possible solution has been staring software engineers in the face since forever. As currently practice, software work is pushed through a queue, with little stories marching through one end of the pipeline and out the other or sometimes across a board like a game of Frogger. Unfortunately, software engineering is a nontrivial task, and for this scheme to succeed, a great deal of planning must go into sequencing the tasks in the correct order or the sprint will fail, tasks will have to be retracted, contexts have to be switched, and velocity suffers. Teams try to create frilly hierarchies and shoehorn the work into them in the hopes of making better sense of the sequencing and timelines.

None if this is necessary. Instead of spending time in meetings planning this out, let’s start doing the things, starting with the most pressing need of the stakeholders. Instead of reconstructing the need into sequences of blocks of work, simply abandon the notion of a sprint queue and put them into a stack. Yes, that stack. And once that discovery finds the next big bad blocker, that work goes on top of the stack. Now the engineer is working on a new item, and continues to work on the item until it completes or requires a new block of work to go on the stack.This continues until, inevitably, all unknowns are brought into light, the minimum scope has been defined, and suddenly, blocks of work come flying off the stack at a rapid clip, and the deliverable gets shipped. Woohoo!

I recommend trying out this paradigm if not for work related tasks, but thinking about your own big projects and using a stack to break it down and start getting things done instead of trying to map out exactly how you are going to move your mountain.

The Rule of Three, Life Hacks to make your Interviews (and just about anything else) Easier

Michael Landry — Sun, 20 Jun 2021 00:52:05 +0000

The rule

The Rule of Three is quite simple. In terms of any topic, commit to summarizing that topic in 3 points. Not two. Not four. Three.

Applying the rule: the interview process

As a novice interviewer, I found the interview process to always be overwhelming. Even the rudimentary ritual of coughing up the 'elevator' speech always felt ham-handed, incomplete, and unsatisfying. Nowadays, I can recite it pretty smoothly:

"My name is Michael Landry, I am a business owner, and software engineer, with experience in the government and financial industries"

I'll admit, it's not the greatest elevator speech ever spoken, but I am comfortable with it, as comfortable as I am with just about most things, and it is the ease of mind that is so wonderful about the Rule of Three. By applying the Rule of Three, you know when you are 'Done.' By only providing two points, it feels incomplete. By providing four points, it takes on a sense of rambling, which has always been a weakness of mine. Five is simply right out. Three is the correct amount for just about any topic, and if we need to go deeper or extend on a point, you can simply take any point you already mentioned, and recursively apply the Rule of Three on a subpoint of the topic. Easy.

Use it everywhere

I use this rule to shop for hotels, research something new, collect information, and just about anything. It's a good guide for making sure I don't waste too much time overkilling something that just needs a little attention, while supplying enough data points to establish patterns.

Image courtesy of Columbia pictures

Every Web Application is the same, the SELID Website

Michael Landry — Fri, 18 Jun 2021 01:13:03 +0000

What does google, apartments.com, and amazon.com, have in common? They are all websites, obviously, but not just that; they all follow the same pattern:

The visitor is presented with a search field
After querying for something, the visitor is then whisked away to a search results page
Upon clicking on a result, a details page is then presented, usually featuring information and buttons that run off to CRUD something in a database or call some APIs

Yup, thats it. This sums up pretty much every web application ever made, even the fancy proprietary expensive application your employer is probably building right now. I like to refer to these as SeLiD websites ( Search, List, Drill down or Details)

Now the next question. What are the acceptable and approved tools and solutions available to software engineers seeking to build a customized web application? Sure, React is pretty amazing, and everyone has heard of AWS, but if every website emerges into the same template every time, then where is the tool that maps to these problems? Businesses want solutions to business problems. Retailers want customers to search, view, and buy merchandise. Property owners want renters to search, view, and rent properties. Software engineers are tasked to build these solutions, and as software engineers, we want to:

Build a search field that combs through and returns matches from a list of records
Shove each returned record into a template, then shove those into another list
Wire up each record into a detail page that will easily interface into some sort of CRUD SDK and extendable callback middleware.
Slap some make up on it.

As far as 'customization' goes, it should be a simple matter of asking which records are being queried, how should the data be presented, what widgets are going on to the screen, what are these widgets going to do to the data, and how is this thing going to look?

Surveying the current landscape of software engineering, I don't see this tool, and I observe the following issues.

The popular 'front end libraries' only solve technical issues, such as synchronizing behavior and state for the web app, which would normally be fine, except that businesses need to have their business solutions solved and not just their technical issues
Engineers have to solve and resolve the same problems over and over again for every web application. The same problems common to every app that the usual libraries don't address. These include authentication, authorization, theming, linting, building, containerization deploying, and on and on...

There are many projects that try to be the 'batteries included' unicorn, but all come up short in some form or fashion. Either they neglect to solve a critical concern, bring too much opinion to bear, too calcified to be extensible, too complicated, too broad, too difficult, and simply not aware of the absurdly common use-cases I have outlined above.

In response to this, the Rondo Platform was born. As an engineer, I have come to find certain platforms, libraries, and technologies as being very easy, robust, and extendable, and by combining these with other open source technologies and best practices, we are able to build the Rondo Platform to be as robust, and efficient, and as simple as possible. Simply put, it takes care of all the toil that goes into custom website construction, and allows the engineer to focus on what matters, solving the business need, while leaving extensibility to customize as much as required.

An Engineer’s take on “Company Culture”

Michael Landry — Fri, 11 Jun 2021 03:20:50 +0000

The "Company Culture" topic comes up quite often, and for good reason. The culture of a company is a chief driver in the success of the company. Despite of its profound impact in both the operation of a company as well as the interview process, I feel that most discussions revolving around it are often nebulous, almost always devolving to mentioning something about having a ping pong table in the break room. Having been bewildered by such discussions in the interview process, I decided I at least needed to come up with some sort of take on it of my own, or at least forming a definition that that makes sense to me:

"The company culture is the set of principles and values that drive the ideas and actions of a company. "

After spending some amount of time researching, and interviewing with a variety of companies, what turns out to be a nebulous and expansive topic actually turns out to be the same usual concepts rehashed in different forms. This topic is very important, but it need not be daunting or confusing. Whether the discussion is about the success of the company in general, seeing if a team is a good fit, or tackling the issue in an interview, maintaining a straightforward understanding of the concept is key. I myself, in subscribing to my usual Rule of Three to keep things simple yet sufficient, subscribe to the three following principles that I adhere to when I need to be productive. I find that these three principles compliment and synergize with each other, and that these principles can be easily extended to encompass all sorts of different virtues of productivity:

Be results driven

I start with this one, it's the most important. When I view a company as a whole, we can ascertain on of this principle is important or not based on one simple criterion, do the actions of the company aide in providing a better good or service to its customers, which in turn drive profits to the stakeholders of a company? It seems obvious that this is what a company should be doing, but quite often I observe companies spending a lot of effort on extra curriculars, be it maintaining its image, fudging markets, hamstringing competition, or tilting the scales of one social issue or another. Some of these things can be important, but CEOs that get caught up in everything except improving the good or service of their business will keep like-minded individuals employed underneath them. It is important for teams to be aware of objectives, that each individual has a goal, and the team has a goal, and that the company has a goal. Only when goals and results are clearly stated, understandable and communicated throughout the entire company (specifically, that means that something was written down and not just allegedly declared in a meeting you may or may not have attended) will an organization enjoy measurable success, and be able to recognize and reward good and strong effort.

Good teams:

Favor results over processes.
Clearly communicate objectives
Recognize good effort and work
Focus more on finding solutions and less on finding excuses

Bad teams:

Drown in bureaucracy and process
Lose focus
Spend a lot of effort on making (bad) policy
Love having meetings, with many people, for long periods of time, while never encouraging anyone to withdraw if they are wasting their time.

Meaningful and impactful ideas and actions

If one assumes that a company then is doing everything it can to achieve some goal, then the next sensible question is whether or not the objective is worth pursuing, or if there is something better. This principle can be expanded into many important values. A team can only know what is meaningful and impactful if they can 'see the big picture.' The big picture exists not within a single team but across an organization.

Good teams:

Are capable of prioritizing important and urgent tasks over other tasks.
Rigorously vet any new ideas and initiatives through an appropriate amount of cost/benefit analysis.
Constantly reflect on existing practices and can change, expand, or discard practices as necessary.
Can be agile and change as needed.
Can see the big picture

Bad teams:

Tend to have many people who are always 'too busy', often indicating the lack of ability to manage and prioritize.
Defend bad ideas based on custom and seniority over merit.
Adhere to ritualistic activities that do not have any meaningful value or relevance to the present situation.

Communication and collaboration

This principle is rapidly being recognized as critical to modern software engineering efforts. The days of the brooding programmer hunched over a keyboard pecking away in solitude are long over. The Software Development Lifecycle is much more well understood, and in order to execute, all team members must be in communication and work together to be successful.

Good teams:

Understand that all members will succeed, or all will fail, as a team.
Focus on the success of the team over promoting oneself
Maintain regular feedback from management to team members, including and especially good feedback.
Respect and trust all teammates
Stay openminded to new ideas and approaches
Promote the spread of ideas and knowledge throughout the team
Find time to ensure that individuals are set up for success
Recognize the value of constant improvement, and are eager to invest in, train, and support all team members.

Bad teams:

Tend to have many people who are always 'too busy', often a 'clever' tactic to appear important, disregard the team, and refuse to take any responsibility.
Conceal, hide, and mislead key information
make it very difficult to have conversations with key teammates on other teams.

A few case studies

As I mentioned previously, the best practices and values for every company are pretty much universal. Let's view a few company cultural declarations and map them back to one of these core principles.

Amazon:

Results Driven:

Deliver Results
Dive deep
etc...

Meaningful and impactful actions:

Customer obsession
Think big
etc...

Communication and Collaboration:

Have Backbone; Disagree and Commit
Earn Trust

And another to establish a trend, here is Rocket Mortgage:

Results Driven:

Ignore the noise
Numbers and money follow; they do not lead.
etc...

Meaningful and impactful actions:

Obsessed with finding a better way.
Every client. Every time. No exceptions. No excuses.

Communication and Collaboration:

It’s not about WHO is right; it’s about WHAT is right.
We are the “they.”

This is my take on company culture. While many might like to make it that their team or company is very unique in terms of their culture, I find that defining a set of values that apply universally goes a long way in simplifying the concept, and will help people understand what distinguishes the great companies from the rest. Oh yeah, and be wary of people who are busy all the time.