Do Good Work for Selfish Reasons … Sort Of

By | September 14, 2023

OK, so that post title is a bit click-bait-ey, but it’s a really relevant title so I’m going with it. Hopefully you will see why in a couple minutes.

The Job Market Sucks Right Now

Pretty much that. In software and tech, the job market is tougher now than it has been in recent memory. There are a lot of reasons why, mainly:

  • High Interest Rates which:
  • Reduced Tech Investment contributing to:
  • Large Tech Company Layoffs and overall:
  • General Economic Unease

There are more reasons of course, but those are the main reasons that I’ve seen in my reading and research.

I’m not saying tech jobs are impossible to find right now, but certainly, it’s harder, and for someone like me who only works remote jobs it’s a bad market at the moment. So what does any of this have to do with doing Good Work?

Your Reputation Matters, Like a Lot

I was part of a large reduction in force at Avant earlier this summer. It was the third significant layoff they had during my 15 month tenure there. I really loved Avant the company, the mission we had, and the people. I intended to retire there – but sometimes life happens and you have adjust.

That happened to me, and so I move on. Fortunately, in my career, I’ve always worked hard and tried my best to produce great work.

Customer Service Matters – Your Employer is Your Customer

I started in food service, so I know how important pleasing the customer is. It was drilled into me in my work at the small chain Tom Wahls where I started and worked throughout college. (If you are ever in western NY state, look them up the food is amazing!).

(Tom Wahls is most famous for its burgers, fries, homemade root bear, and of course soft serve ice cream!)

In my 4 years of college I worked there near or full time and worked my way up into store management. I learned a great deal from that experience about what it takes to please customers and management.

Anyway, the point here is – I learned early how important the customer is. If the customer is not happy, you will never be happy working there. If you’re manager isn’t happy you won’t be either.

If you are employed guess what your manager and employer are your customers. Make sure they are happy. That’s your most important job.

Good Work Pays Dividends

Since most of my career I’ve been a consultant – I’ve taken that learning and applied it to my work in technology. I ALWAYS strive to produce great work, on time, on specification and within budget.

I’ve got a track record now of over 25 years of doing great work when it comes to building software. That track record has served my customers very well and it has paid off handsomely for me and my family as well.

Through my reputation and good timing with past client needs – I’ve quickly picked up contract work in a really tough job market. It might have required a year or more of looking to find a good role.

But a few days after I was laid off from Avant, I was working and have maintained steady work since. I had almost no income loss from the layoff. That’s huge as we all know.

But, it would not have been possible had I not done great work in the past. Be memorable for your good work! You will never need to look long for work. Sure, that is a bit of a selfish benefits, but I think its fair trade for doing really good work for your customers!

AI’s Amazing New Toy – Create any Image using Text to Image

By | August 23, 2023

I have always been a tinkerer and technologist. I just grew up tinkering with computers instead of woodworking like I probably would have had I grown up in the 50’s instead of the 80s and 90s.

The latest toy I’ve been playing with are AI Text to Image bots. Surely you know by now that AI stands for Artificial Intelligence. I wouldn’t quite say that the tools that generate these images hold intelligence per say, but the certainly can create some interesting scenes with simple text prompts.

See the image up there at the top of this post? Yep, created by AI via a simple text prompt. I told the AI to “create a painting of dogs running on a beach scene” and bam, 5 seconds later I had 4 unique pieces of digital art to enjoy!

I’ve really been excited by the recent renaissance we’re undergoing in the area of AI, and this is just one of the great tools that is out there.

What is this Good For?

Well, creating fun imager is one use. But, on a more practical level, if you need a certain graphic for a presentation, a paper, a blog post or whatever – you can literally now ask for it, and get it. No need to find a designer or create yourself, the AI does it for you. This is definitely a tool you should consider using if you ever need art for your work.

Want to Play?

Here are some free, capable, and interesting AI Text to Image services, check them out and see what you can create! If nothing else, you get a good laugh when the AI creates something whacky. Enjoy!

AI Image Examples

Here are a few of the better images I have generated, and the prompts that created them. Some are great, some are OK, some are just odd, you never quite know what you will get. But the AI tools generally generate at least 2 images so you can choose the best one. Here goes:

Man with Head in Hands

Cats, a Dog and a Raccoon Playing Poker

A Female Superhero on a Beach with a Storm in the Background

Yes, this was a whacky prompt with a whacky result!

A Baseball Player Hitting a Home Run, in the Style of a 1950’s Comic Book

Weird, but it made something kind of neat.

Amazon Forces RTO, Cites Increased Nearby Restaurant Sales Increases as Reasoning

By | August 25, 2023

What is serendipity and how does it connect to software or the production of software? Beats me! But apparently Amazon is using an executive’s personal serendipity to “know” that forcing remote workers back to office is better. Yes, really, this isn’t a joke.

As you may know already Amazon forced most of their remote staff to return to office earlier this year. At the very least they returned hybrid but I’ve read stories indicating that they were forced full time back in the office. (Yuck!) This happened even if the employee was hired 100% remotely and never worked in an office. It also happened if employees lived NOWHERE near the office in question.

“Hey, I know you live in Salt Lake City out in Utah, but I need you in the office in Chicago on Monday. Mmmm, kay?”

Yeah, I imagine it went down like that. Office Space style. Or similarly I’m sure. With a similar total lack logical reasoning or any regard for the employees personal life or well being.

They Had Good Reasons though Right??

No internal or productivity data was provided providing reasoning behind the demand to have employees in office. What they did provide was the following data that was sure to excite employees:

In Seattle, Amazon’s return to its South Lake Union campus has led to an 82% increase in foot traffic between May and July and an 86% increase in credit card transactions at restaurants in the neighborhood, according to data shared from Amazon.

– From Amazon Directly

No, you read that right. Amazon is quoting restaurant sales increases near their offices as a key positive outcome of return to office. Yeah, amazing isn’t it. That is the best they have to share from forcing RTO on people for no logical reason.

Unhappy Workers == Less Productive Workers

You would think if productivity, collaboration or work output had increased or improved they would have shared that right? I think we know why they didn’t. I’m sure that a large majority of remote folks are not happy being forced to commute and work in a fishbowl open office. I’m also sure a significant number of these folks personal lives were deeply impacted by these forced, and arbitrary changes.

Let’s put it in simple terms. Remote employees would not be and are not happy about these forced arbitrary changes. I’m sure over the aggregate, Amazon has seen work quality and quantity drop. In my experience folks who are unhappy at their jobs simply don’t produce as well as those who are. I’m sure Amazon is learning that lesson now.

This study reported by ADP claims that unhappy employees cost employers up to $300 Billion a year through lost productivity, turnover and other measurable losses. Oh and that was in 2014, so here 9 years later that number is likely higher.

I hope Amazon relents and reverts back to the policies that drove them to record profits during the Coronavirus forced work from home from 2020 – 2022. I’m not a shareholder, but if I was, this is one of the things I’d be wondering about.


I know this is the third article about return to office I’ve written recently – and probably the last for a while.

Remote work is a subject I’m passionate about because I know how well it works both for employers and employees. It is something I’ve done now for most of the last two decades.

I hope that companies continue to embrace remote work for employees who can be productive anywhere. It will be a competitive advantage for hiring for sure – and it will produce happier more productive, and more loyal employees!

The Importance of Simplicity in Software Architecture: A Guide for Success

By | August 19, 2023

Free Coding Cliparts, Download Free Coding Cliparts png ...

In the fast-paced world of software development, simplicity in design and system architecture is VERY often overlooked as a critical component of a successful project. While there is a tendency to focus on performance, scalability, and other technical aspects, the truth is that simple architectures are more efficient and ultimately more successful in the long run. Why? In this discussion, we will explore the benefits of architectural simplicity, the reasons for complexity, and provide recommendations for driving simplicity in software architecture.

Benefits of Architectural Simplicity

Simple architectures offer several key benefits that contribute to the overall success of a software system.

Ease Cognitive Load

A simple architecture is easier to communicate and comprehend. Architects and development leads often do not consider the cognitive load required by developers to understand a system enough to effectively work on it without breaking everything they touch.

Just imagine if you took an auto mechanic from 1970 and asked him to understand and fix a modern EV like a Tesla or a complex gas-electric hybrid like a Prius? He (or she) would be utterly lost and would have to spend a ton of time just trying to figure out how the car works, before even trying to fix anything.

That’s what a lot of companies do today with really complex micro service collections, code as service and other widely diverse architectures. Before developers can even begin to work on such a system they have to understand a ton of complex concepts: languages, frameworks, containers, container orchestration, networking, scaling, cloud infrastructures API interfaces, message busses, and so on. Then they have to understand all the particular ways your architecture uses those tools. It is a huge learning curve, and slows developer productivity.

All of that is a far cry from the simplicity of a classic Ruby on Rails monolith, for example. In an architecture that’s a monolith, there are far fewer moving pieces, and you don’t have to understand containers, orchestration, deal with inter-micro service orchestration or any of the other problems created by more complex architectures.

I’m not making a stand on micro services vs monoliths here. Rather, simply stating that often times a simpler architecture will offer significant benefits over something overly complex that you probably don’t really need. At least not yet. Don’t build complexity until you really need it.

By working to define and implement a simple architecture with a smaller model and fewer drawings, developers and stakeholders can quickly grasp the architecture, leading to better alignment across teams and efficient implementation. It saves time, money and frustration to keep it simple!

Ease of Implementation

Simple architectures are often far easier to implement and manage in a production environment . They have fewer moving parts, interactions, and potential points of failure. Compare a monolith with an application server, a database and a caching layer like Redis or memcached. In this architecture, 3, maybe 4 key tools power the whole thing. It is super easy to understand how it works, and therefore how to run and maintain it.

While it may take more time to identify a truly simple design through trial and error, the overall implementation process is streamlined. It is worth the effort.

Simplified Deployment and Operations

Simple architectures are easier to deploy and operate. With fewer moving parts, the deployment process becomes very straightforward. Once in production, simple architectures can be easily scaled and monitored, leading to fewer operational challenges.

There are a ton of great tools to manage deployments using continuous integration and continuous deployment (CI/CD). Even something as simple as Jenkins works great – unless your architecture is super or overly complex. Overly complex architectures make deployments and coordinating the deployments of tightly coupled components time consuming and error prone. (Tightly coupled / poorly abstracted micro services are abominations and I’ll definitely have things to say about that in the future. )

Focus on keeping your build and deployment architecture as simple as possible. This combined with a straightforward system architecture can greatly simplify and streamline your CI/CD pipelines maintaining maximum efficiency.

Flexibility for Modification and Evolution

Simple architectures are easier to modify and evolve. By adhering to the principles of Agile practices and specifically LEAN – development teams can be more productive with fewer complexities to manage and fewer points of impact when making changes. This makes the process of change overtime much, much easier.

Never heard of LEAN – learn more here?

I’ll summarize LEAN – it is all about eliminating waste. Even if nothing else in the LEAN world appeals to you or suits your team, you should always be looking to eliminate wasteful work in your projects. I’ll be sure to write a LOT more about that in the future because in my experience companies and project teams waste a lot of effort on meaningless busy work. But I digress…

Understanding Architectural Simplicity

Defining simplicity in software architecture can be challenging as it encompasses various concepts and practices. Here are some key considerations to drive architectural simplicity:

Strive for the Simplest Option

When designing a software system, strive for the simplest option that meets the functional and non-functional requirements. This approach, often referred to as Occam’s Razor, emphasizes choosing the most simples solution among multiple possibilities.

Apply YAGNI (You Ain’t Gonna Need It)

Avoid designing for future requirements that may never materialize. Instead, focus on building what is needed at present and only that. By avoiding over-engineering, you can reduce complexity and unnecessary development efforts. The vast majority of the time you won’t need to do more.

The most common way this manifests is “building for scale”. For example, you are building an internal time keeping app for a large company of approximately 5000 employees. Spending a lot of time to implement clustering, sharing, auto-scaling and other large to huge scale focused capabilities is almost certainly a waste of time. Time keeping happens once a day x 5000 employees. One server should be plenty to handle that level of load. Maybe two.

If your company grows exponentially, or decides to sell the time keeping software – now you might have to consider scaling. But how likely is that? And how fast will that happen? You won’t simply wake up tomorrow and have 5 million users keeping time on that system. Nope. It will take months to years – you’ll have time to make changes for scaling.

Key takeaway: Do it when you need it – don’t anticipate a need u will never have!

Avoid Premature Optimization

Another aspect of YNGNI is over optimizing. Avoid over-optimizing the design at the initial stages. Start with concrete implementations and refactor into interfaces as needed. This iterative approach allows for better interface definition and function names, resulting in a more suitable level of complexity for the system.

Embrace Simplicity, Not Familiarity

Simplicity is not equivalent to familiarity. Embrace simplicity even if it requires using unfamiliar technologies or techniques. The focus should be on finding the simplest solution that solves the problem at hand, rather than relying on familiar approaches that may not be the most efficient.

Reasons for Complexity

Despite the numerous benefits of simplicity, software architectures often become complex due to various reasons. Here are some common factors contributing to complexity:

Complexity Sells

Complexity can be seen as a way to add value to a solution, showcase technical prowess, or support empire-building within an organization. However, complex designs can become difficult to build, maintain, and evolve, ultimately hindering the success of the software system.

Development is Fun

Developers often enjoy tackling complex problems and using new technologies. Developers also tend to do this to pad their resume with the latest and greatest technologies – even if they don’t fit the need of the business or a better more proven solution exists. This enthusiasm can sometimes lead to overcomplicating the architecture, as developers pursue exciting challenges and overlook the long-term implications of complexity.

Keeping Up With the Joneses

The ever-evolving technology landscape tempts developers to incorporate the latest trends and technologies into their designs. While innovation is essential, blindly adopting new technologies without considering the impact on simplicity can lead to unnecessary complexity.

Simple Is Hard

Designing simple solutions is often more challenging than designing complex ones. It requires a deep understanding of the problem space, available technologies, and prior design experiences. Maintaining simplicity over time requires continuous effort and vigilance against entropy.

Organizational Structure

The structure of an organization can influence the complexity of software architectures. Conway’s Law states that the architecture of a system often reflects the communication structures within an organization. Complex organizations tend to produce complex architectures.

Recommendations for Driving Architectural Simplicity

To achieve architectural simplicity, it is essential to adopt specific practices and techniques consistently throughout the software development process. Here are some recommendations to drive architectural simplicity effectively:

Perform Some Design Up Front

While an agile approach is valuable, some level of up-front planning and design is critical. Set an initial vision, align the delivery team and stakeholders, and continuously monitor progress to ensure alignment with the vision.

Design Throughout Delivery

Over time as you gain insight and experience, adapt the architecture in small, logical ways to ensure you can meet the business needs.

Architecture should be continuously evaluated throughout the development lifecycle. Be prepared to make course corrections based on changing requirements or new insights gained during implementation. Intentional architecture ensures that decisions are made deliberately, considering the larger vision.

Ask Questions, Often

Challenge assumptions, clarify ambiguities, and ask questions to gain a deeper understanding of the problem and requirements. Regularly question design decisions and consider alternative approaches. Communication and collaboration are vital for maintaining simplicity.

Understand Decision Tradeoffs

Recognize that all decisions involve tradeoffs. Consider multiple options for each decision and evaluate the benefits, challenges, and risks of each alternative. Understand the return on investment of specific requirements to make informed decisions.

Create Proof of Concepts

Use proof of concepts to gain confidence and verify the viability of architectural decisions. Start with minimal implementations to validate specific aspects of the architecture, and iterate as needed. Proof of concepts can help reduce complexity and uncertainty.

Communicate Effectively and Often

Clear and frequent communication is essential for successful architecture delivery. Utilize concise documentation and favor written documentation vs shared understanding. Regularly review the architecture with the delivery team to reinforce the vision and prevent misunderstandings.

Embrace Minimum Viable

Focus on delivering the minimum viable product that satisfies early customer needs. Avoid over-engineering and prioritize architectural features based on the most likely scenarios, rather than addressing all edge cases.

Make Architecture Everyone’s Responsibility

Encourage the entire delivery team to think architecturally, regardless of their seniority. Foster a culture where all team members are involved in decision-making and challenge design choices. A collaborative approach ensures that simplicity is embraced by all stakeholders.

By implementing these recommendations, software development teams can prioritize simplicity and drive architectural success.


Architectural simplicity is a critical factor in the success of software systems. Simple architectures are easier to communicate, implement, deploy, and modify. They facilitate efficient operation, scalability, and responsiveness to changing business needs. Despite the benefits, complexity can creep into architectures due to various factors.

To drive simplicity, it is essential to adopt a proactive approach that includes upfront design, continuous evaluation, effective communication, and a focus on tradeoffs. By making architectural simplicity everyone’s responsibility and embracing a mindset of continuous improvement, software development teams can build robust and successful systems.

Simplicity should be at the forefront of software architecture. Embrace simplicity, challenge complexity, and continuously strive for architectural designs that are as simple as possible to meet the goals. Remember, simplicity is the key to unlocking long-term success in software development.

The Reality of Return to Office Policies: Why They’re Failing and What Employers Need to Do

By | August 16, 2023

?Image Source: Pexels

The COVID-19 pandemic has forever changed the way we work. As the world grappled with the unprecedented challenges of a global health crisis, remote work became the norm for many employees.

But now, companies are pushing hard for a return to the office and it has become clear that the traditional full time in-office model no longer makes sense for a large part of the workforce – particularly those who’ve successfully done remote work now for quite _literally_ years.

The Disconnect Between Employers and Employees

One of the main reasons why return to office policies are failing is the disconnect between employers and employees. While many CEOs and senior leaders believe that in-person work is essential for collaboration and career development, employees simply don’t see the benefit.

Collaboration happens virtually now. Zoom/Teams/WebEx/Google Meet/whatever all make it easy to have a face to face conversion anytime with anyone on your team. Plus we have text chat tools like Slack or others making quick collaboration WAY quicker than physically tracking someone down, interrupting them and doing it in person.

A study conducted by economists at the Federal Reserve Bank of New York, the University of Iowa, and Harvard University found that remote work decreases collaboration and training for junior workers. I really doubt the findings are significant, let alone accurate. These large institutions are funded buy the same large corporations that want to drag you back into the office.

Instead of forcing employees back into the office without considering their needs and preferences, employers should take a more intentional approach to training and mentoring their newest hires using the virtual tools available. Simply assuming that time spent in the office automatically confers benefits in terms of career development and collaboration is ridiculous and makes no sense. If employers want cross training and mentoring to happen, they need to create programs to do this intentionally for both in-person and remotely.

The Myth of In-Person Innovation and Mentoring

Many executives argue that innovation and mentoring are best fostered through in-person interactions. However, this assumption is simply not be supported by evidence.

Kate Lister, president of Global Workplace Analytics, challenges executives to question whether they have actually measured the impact of in-person work on innovation and mentoring. Has any company really done this analysis? Or do executives simply like seeing butts in seats? I think it’s the latter not the former. I’ve read countless articles on this subject – as it’s one I’m passionate about. I have yet to see _any_ convincing proof that forcing workers in office improves mentoring over remote in any measurable way.

Through my personal mentoring work at Springboard I know definitively that online mentoring is very effective. I mentored more than 100 software engineering students during my time at Springboard with great results. Students learned effectively, we were able to collaborate over code easily, and I could answer questions with no problem – all virtually. And I wasn’t the only one. Springboard has hundreds of mentors helping thousands of students – all online very successfully. So I know online mentoring works because I’ve done it and I see it work.

Moving Beyond the One-Size-Fits-All Approach

The approach of mandating a specific number of days in the office for all employees is foolish and costly. Each team and individual within an organization has unique business needs and personal preferences when it comes to in-person work. Fixating on the number of days employees should be in the office fails to consider the diverse nature of work and the benefits of remote work for employees productivity and personal well being.

Instead of stupid mandates, employers need empower individual teams and leaders to determine their needs for their teams. Corporate in office mandates or hybrid mandates don’t make sense at all when employees just come to the office to be on Slack and Zoom all day working with offsite clients, or staff, for example. All too often this is the story told of employees forced to RTO. They suffer all the negatives of commuting, loud open offices, coworker distractions and office nonsense – only to really work virtually anyway.

The Failure of RTO and Hybrid Work Models

The failure of return to office policies can be attributed to a lack of flexibility and adaptability. Employers need to stick with remote work when remote work is productive. Don’t cause employee upset and turnover by forcing RTO for no actual business reason.

If your business hasn’t CLEAR and PROVEN benefits to in office, or occasional in office work, then a hybrid work model may work for your team. But don’t force employees to be in office just to meet some phony “in office days metric”. Make coming to the office have a real purpose or you will cause discord in your team.

The Future of Work: Adapting to Changing Realities

The COVID-19 pandemic has accelerated the transformation of the workplace. It has highlighted the need for employers to adapt to changing realities and prioritize the well-being and productivity of their employees. Return to office policies that fail to consider the preferences and needs of employees are destined to fail. I will cheer such policies that fail because the businesses that implement them don’t care for or consider their employees well being when they implement them.

Conclusion: A New Approach to Work

The failure of return to office policies should serve as a wake-up call for employers. The traditional office model is out of date. We no longer need be tied to location for a LOT of work, and we as a society should take advantage of that. The reduction in needless commuting alone will save costs, time, and climate impacts from all of the countless vehicles NOT on the road driving to an office.