Hello World!

The Rhythm of a Team

Leadership is an intricate dance, where every decision shapes the rhythm of the team. Whether by changing policies, updating procedures, or applying the right amount of pressure, finding the best cadence to keep a team in flow is the art of effective leadership.

Through the application of philosophy and psychology, I have earned a reputation for orchestrating high-performing, highly-engaged teams characterized by remarkable cohesion and minimal turnover. I have honed the following leadership lessons through my real-world experience. They reflect a journey marked by successes, setbacks turned into opportunities, and a perpetual cycle of improvement.

Hire Well

Hiring is the most critical task a leader undertakes. I've come to view the bond between team members as a sacred, delicate thing, and any change to the group's makeup can have a profound impact on this synergy, for better or worse.

The pressure to quickly fill a vacancy can clash with the imperative to select the right candidate, but it's worth taking one's time.

It's not about simply finding someone with the right buzzwords on their resume. While skills hold their merit, the right new hire can gain them over time. Character, on the other hand, directly impacts an individual’s ability to integrate with the rest of the team. I have come to value collaboration and cooperation over independent contributions.

Influencing personal growth is much more difficult than teaching an employee a technical skill.

Promote Work-Life Balance Through Flexibility

In the contemporary workplace, the traditional notion of basing an employee's value on their attendance is no longer reasonable. It is essential to prioritize execution over mere presence, particularly when dealing with a remote workforce.

Recognizing that employees juggle personal and professional commitments, a leader should shift their focus from tracking hours to assessing contributions, granting team members the autonomy to manage their schedules according to their unique needs and work styles.

Embracing a philosophy of balance and flexibility reflects the realization that productivity is not confined to a rigid schedule.

However, with this flexibility comes responsibility. While team members are encouraged to manage their time as they see fit, a leader must remain vigilant for potential abuses of this policy or breaches of contract. Striking the right balance requires a blend of trust and accountability.

The Application of Authority

The authority granted to a leader is a powerful instrument, and how it is wielded shapes the team dynamics and, consequently, its success.

Leadership demands a nuanced approach—the direct exercise of authority should be a measured action, akin to a scalpel in the hands of a skilled surgeon. Wielding power like a cudgel, constantly demanding compliance through brute force, is a surefire way to diminish employee engagement, resulting in an environment where collaboration falters and innovation stagnates.

Instead, guiding the team with respect and understanding better fosters an atmosphere where individuals are empowered to contribute their best. This approach requires an investment of time and energy, as it involves assessing each team member's unique strengths and challenges. It is a commitment to mentorship and guidance, allowing the team to flourish, rather than diminish under an authoritarian figure.

Leaders also have a pivotal role in managing the stress level within the team. Striking the right balance is essential; too little pressure results in complacency and a lack of progress, while excessive tension leads to burnout and high turnover. Effective leaders understand the importance of finding a level of stress that motivates without being overwhelming. Once found, this baseline, background pressure keeps the team moving forward.

Keep Raising the Bar

Leaders can be a transformative influence on their teams.

From the realm of psychology, the Pygmalion Effect reveals a profound truth about leadership dynamics. It describes a phenomenon where individuals, when presented with elevated expectations by their leaders, exhibit a remarkable propensity to ascend and meet those expectations.

When harnessed effectively, the Pygmalion Effect becomes a self-perpetuating cycle of growth. As the team accomplishes their aspirational milestones, their confidence grows, setting them up for continuous success. The victories become more than just achievements; they affirm the team's capabilities, fostering a culture where the next set of challenges is embraced rather than feared.

It is the alchemy of leadership—a continuous process of transformation where the team, under the influence of positive feedback, not only meets but exceeds their original expectations.

Value Progress Over Statistics

The influx of agile methodologies and associated tools has ushered in an era of data-driven management. Charts, graphs, and metrics paint a vivid picture of a team's activities—burndown charts tracking task completion, velocity charts gauging productivity, lead time charts outlining workflow efficiency, and various other visualizations aimed at providing a comprehensive overview.

While these tools offer valuable insights, leaders must see beyond statistics alone. Immersing themselves too deeply in the world of charts, leaders can create a culture that values the perception of success over meaningful progress. For example, a relentless focus on burndown charts can lead to the stagnation of development resources near the end of a sprint as they wait for their stories to be marked complete by Quality Assurance or User Acceptance Testers rather than take on new work.

Authentic leadership goes beyond the confines of statistical analysis. Attending scrum and agile ceremonies is not just a formality but the best means to measure the team's pulse. It sheds light on the challenges faced by individual team members, presenting truths that charts cannot capture.

Leaders must foster a culture that celebrates tangible progress rather than reduce achievements to mere data points.

Keep Sprints Negotiable

Sprints are simply time boxes, and should not be treated as rigid constraints. Priorities can shift unexpectedly, so a responsive and customer-centric team must embrace a culture of flexibility.

During emergencies, strict adherence to a preexisting plan can become a source of friction. During urgent scenarios, clients are not amenable to hearing that the team can only address their pressing concerns during the next sprint (or, worse, during the next program increment).

Remaining open to change does not imply a lack of structure; it underscores a commitment to adaptability. In this spirit, accommodating late-breaking requirements introduced mid-sprint recognizes the need for agility in response to evolving client demands. However, this flexibility may require postponing an equal amount of previously planned work.

It requires a balance between being responsive and maintaining a realistic workload; a leader must ensure that the team can effectively manage unexpected shifts without compromising the overall project timeline.

Remove Impediments Early

In an agile working environment, the regular sprint-by-sprint cadence moves teams forward at a steady, sustainable pace. This narrow focus on sprints can consume the team's attention, but effective leadership requires a dual perspective—a simultaneous gaze at the present and a thoughtful look to the future.

Impediments such as the breakdown of a developer's machine or an unexpected absence may be forever unavoidable, but astute leaders can anticipate potential obstacles before they impact the team. For instance, if another team's collaboration is crucial for an upcoming sprint, discussions and coordination should commence weeks or even months in advance. If a firewall change is needed, a little foresight prompts the submission of the proper paperwork well before the relevant sprint begins.

In essence, a leader's role is to manage the team's current workload and prepare for the future. A leader adept at looking to the horizon instills a forward-thinking culture within the team. This culture doesn't just react to impediments; it anticipates and mitigates them, ensuring that the team continually operates with agility and resilience. In the best-case scenario, the entire team becomes forward-focused, with each member collectively contributing to the sustained success.

Don't be Interesting

Every team desires a good reputation. Teams want to be entrusted with more responsibility, granted more autonomy, and gain renown for getting things done. Unfortunately, in most organizations, it's easier to fall into disfavor with leadership than to earn respect.

Reputational risks are inherent in deadlines, whether they are hard or soft. While the team may embrace agility, the broader business environment may be less flexible. These deadlines always receive significant attention when they appear, but there are other, less obvious time limits such as those tied to corporate training, surveys, expense reports, and timesheets, which all demand equal attention. Ensuring the punctual fulfillment of these commitments—big and small—is crucial to avoid the appearance of insubordination.

The release of defects carries obvious reputational consequences, as bad news spreads faster—and higher—than good news. If leadership cringes every time the team deploys, it's a clear signal of underlying issues. Ideally, deployments should be frequent, smooth, fast, and stable—so routine that they no longer garner attention and just become a routine part of doing business.

Usually, a team's reputation is built upon a foundation of consistent, reliable delivery. A track record of quietly and dependably meeting all commitments is the key to fostering a positive perception within an organization.

Wait Before Implementing Change

Leaders are frequently exposed to upcoming plans earlier than individual contributors. Upper management often introduces ideas that may not come to fruition, and when they do, the outcome may differ from the initial proposal.

In the face of these fluctuations, influential leaders understand the delicate balance between transparency and stability. Change, while inevitable, can be a disruptive force if not managed with care. It is a distraction that can divert the team's focus from their core objectives.

Rather than gossip about rumored changes, a leader should embody a steady hand on the rudder, maintaining composure and refraining from premature discussions until the decisions are finalized and the path forward is clear.

Silence during these periods isn't an evasion of responsibility but a strategic choice. It allows the team to concentrate on their work without unnecessary distractions. Constancy in leadership acts as a stabilizing force.

Confidentiality is Key

Trustworthiness stands as a cornerstone of effective leadership. Leaders often find themselves privy to sensitive information, with staff and upper management confiding in them about personal problems, financial matters, or simply venting frustrations about other employees. In these instances, the leader's role transforms into that of an active, respectful listener.

Ethics demands that the leader refrain from discussing these matters with anyone else, ensuring the utmost discretion, unless the situation necessitates intervention by Human Resources.

Confidentiality is the bedrock of trust, and psychological safety in the workplace is essential for cultivating a high-performing team.

Explode Up, Not Out

A team is composed of individuals, each with their own emotions, challenges, and daily frustrations. It's only human for these pressures to occasionally boil over, potentially causing harm to the team's collective reputation.

I consistently advocate for a specific channel to vent such frustrations—directly to me. I emphasize the importance of not conveying hostility towards colleagues, external teams, or clients. Customer service must come first; political capital is often easier to burn than to gain.

As a leader, I patiently listen to these frustrations and then transform them into actionable initiatives. These could manifest through policy changes, strategic plan adjustments, or, when necessary, appropriate escalations to address underlying issues.

By providing a safe and confidential space for the team to express their concerns, a leader protects the team's reputation and turns moments of frustration into opportunities for positive change and growth.

Weeding the Garden: Knowing When to Let Go

The culture of a team is a direct reflection of its leadership.

In an ideal scenario, team members trust one another, take pride in their contributions, and derive genuine enjoyment from their work. Unfortunately, this is not always the case, and there are times when a leader must intervene to address personnel issues. While I acknowledge that everyone may have an occasional bad day, an individual's persistent contribution to a toxic work environment requires decisive action. In such cases, a leader must implement corrective measures and, if necessary, proactively remove an offending individual for the collective well-being of the team.

Redirect Praise, Accept Blame

When a team succeeds in their goals, it's not uncommon for a leader to receive praise from above. However, integrity demands the recognition that success is the product of collective effort, and it is only fitting to redirect that praise to the entire team.

Conversely, when faced with setbacks or failures, a leader's role is to shield the team from external hostility. Instead of pointing fingers at individual team members, the leader must take any blame upon themselves. Adverse situations should trigger a process of introspection and improvement, with leaders channeling their focus towards policy changes and enhancements to the workflow to ensure a better outcome in the future.

Fostering a Culture of Success

Leadership involves managing the work and the intentional creation of an environment where individuals can flourish, innovate, and exceed their own expectations.

Employee satisfaction is at the heart of a thriving workplace, and leadership is about laying the foundation for a culture where every team member feels valued, supported, and inspired. The art of leadership lies in fostering a culture where every individual thrives, and success is simply a way of being.

A Missing Role

A Software Architect is responsible for overseeing a system's overall structure and design, ensuring that it aligns with business goals and remains adaptable to evolving requirements. Unfortunately, in most organizations, this role is not formally defined.

Other technical leadership roles may exist, but they don't have the same focus. Enterprise Architects evaluate third-party technologies and mandate their use, while Solution Architects focus on course-grained, high-level, system-to-system integrations. Management is often too busy—or simply not technical enough—to provide much architectural guidance.

Instead, software architecture is, by necessity, left up to the Software Engineers. While this de facto approach sounds reasonable—the engineers have to work with the system, after all—there are problems with leaving the architecture undefined.

The first problem is that developers may become overly focused on delivering individual stories, overlooking the importance of viewing the system as a whole. This myopic approach can result in a heterogeneous architecture, where different parts of the application diverge due to variations in the developers' backgrounds. Left unchecked, some modules may become so cryptic that only the original developer can maintain the code.

Secondly, under constant schedule pressure, developers might prioritize quick solutions over thoughtful architectural considerations, leading to the accumulation of technical debt. Unfortunately, refactoring, essential for maintaining a healthy codebase, often takes a back seat to more immediate business needs, so any technical debt may reside in the backlog for a considerable time before being addressed.

Finally, the team may not have experience in, or even knowledge of, agile development practices. Without a designated Software Architect, teams inevitably fall back to a design-by-committee approach, where decisions are influenced by the loudest voice rather than a strategic architectural vision.

Having a dedicated Software Architect, whether formal or informal, is pivotal. This individual should be well-versed in agile software development practices and be able to guide the team towards a cohesive and adaptable architectural design.

What does Agile Software look like?

In the pursuit of innovation, many organizations adopt the agile methodology. Once implemented, their product teams engage in time-boxed sprints, conduct daily scrum meetings, and actively manage a backlog of work. Successful implementation results in the release of working software into production early and often, defining a Software Development Lifecycle (SDLC) more responsive to changing consumer demands than traditional Waterfall approaches.

While agile adoption nurtures a culture that embraces change, it doesn't automatically guarantee that the resulting product shares the same flexibility. Surprisingly, agile teams can inadvertently craft software that is just as rigid as those built under traditional project management approaches. A telling example is when adding a new feature requires many small changes across multiple classes—a situation aptly coined "Shotgun Surgery." It signals that the application is rigid, contradicting the essence of agility.

Truly agile software transcends the methodology itself. It is characterized by clarity, flexibility, and maintainability. Refactorings are infrequent, signifying a system that readily adapts to change.

Agile Software sounds excellent, but how do we get there?

There are no shortcuts. No language—old or new—magically ensures good software architecture. With a bit of foresight and discipline, though, any product can be agile-first.

These software development concepts are not new or original to me, but I've found that they aren't broadly applied. The beauty of these concepts lies in their accessibility—they cost nearly nothing to implement but have the potential to save a substantial amount of money, frustration, and embarrassment in the long run.

While the principles outlined below are well-documented elsewhere, they remain underutilized. I provide only a brief introduction here, but I encourage readers to explore these concepts on their own.

SOLID Principles

First collected and presented by Robert C. Martin in 2000, SOLID is an acronym for five software development principles that focus on the design of classes. While initially intended for Object-Oriented Programming (OOP) languages, these principles have proven their versatility, and can be more broadly applied.

Single Responsibility Principle

The Single Responsibility Principle (SRP) advocates that each class has only one job, and therefore, a sole reason to change.

While most engineers understand the importance of ensuring individual functions have a single responsibility, its application to classes is less intuitive, especially when OOP educational materials often illustrate how one can add complex methods to data classes.

SRP guides developers towards a refined architecture by urging the separation of the data model from functionality. As an illustration, instead of appending a .Save() method to a class named Foo, adhering to SRP guides us to create a dedicated FooPersister class equipped with a .Save(foo) method.

Open-Closed Principle

The Open-Closed Principle (OCP) posits that each software entity should be open for extension but closed for modification. At first glance, this principle might appear self-contradictory, but it promotes the use of inheritance through subclassing or interfaces.

OCP seeks to minimize the impact of new code on a system by favoring the extension of existing classes (or new implementations of interfaces) over altering proven, working code. However, it's essential to avoid taking this to an extreme; doing so can lead to the Onion anti-pattern, perpetually adding layers of code without modernizing the older portions. Striking the right balance is essential to maintaining an extensible and comprehensible codebase.

Liskov Substitution Principle

The Liskov Substitution Principle (LSP) asserts that subtypes must be substitutable for their base types.

Since most programming languages support polymorphism, allowing a subclass to be used wherever a base class is expected, the initial impression might be that LSP is redundant. However, LSP delves into the runtime behavior of the class, emphasizing that the subclass must be able to substitute for the base class without unintentionally altering the behavior of the program. (LSP obviously does not apply to classes that inherit from abstract base classes.)

Currently, LSP lacks compiler enforcement and relies on code reviews for adherence.

Interface Segregation Principle

The Interface Segregation Principle (ISP) promotes the creation of atomic, tightly-focused interfaces. A key advantage is that dependent classes can selectively request only absolutely necessary methods.

By encouraging the development of compact and purpose-driven interfaces, ISP aligns with the broader principles of modularity and simplicity in agile software design.

One of the significant benefits of ISP is its role in preventing SRP violations. Where SRP emphasizes that a class should have only one reason to change, ISP ensures that an interface, as a contract, remains cohesive and does not bloat with unrelated methods.

Dependency Inversion Principle

The Dependency Inversion Principle (DIP), often referred to as Inversion of Control (IoC), stands out as one of the most pivotal principles among the SOLID set. DIP fundamentally transforms how software components interact by shifting the traditional control flow.

DIP advocates that classes should declare their dependencies and receive them through external means, rather than being responsible for the instantiation of foreign classes. This leads to more flexible, modular, and easily maintainable systems.

Consider a scenario involving a FooManager class dependent on a class implementing the IFooPersister interface. Instead of internally instantiating the dependency, DIP mandates passing the dependency from external sources. During runtime, the FooManager could receive a FooDatabasePersister, a FooFileSystemPersister, or a MockFooPersister. This level of flexibility empowers developers to adapt the system to changing requirements without needing to modify the core logic of the components.

The recommended approach for handling dependencies is through constructor injection, passing dependencies in at the time of instantiation. This method enhances clarity, as dependencies are explicitly declared, making it easier to understand and enforce. Property injection is an alternative, where dependencies are passed through properties, but constructor injection is generally favored for its transparency and effectiveness.

Five Principles, One Unified Approach

While the SOLID principles—Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—are often discussed individually, their true strength lies in their collective synergy. Each principle is not an isolated guideline but a crucial piece in a unified approach to robust and maintainable software design. For instance, Interface Segregation helps enable Dependency Inversion, which is best implemented when classes and interfaces have a Single Responsibility.

Essentially, the SOLID principles form a holistic framework where each principle complements and reinforces the others. They are interconnected threads in the fabric of software design, weaving a tapestry of code that is not only modular and flexible but also resilient to the evolving needs of a dynamic development environment.

Aspect-Oriented Programming

When common concerns, such as logging, monitoring, caching, and security need to be addressed, these concerns can wind up repeated across multiple methods or modules. Aspect-Oriented Programming, or AOP, is a powerful approach to elegantly handle these cross-cutting concerns.

AOP operates by segregating cross-cutting code into entities known as "aspects." These aspects encapsulate functionality that needs to be applied uniformly across various parts of the codebase. This approach brings modularity and abstraction, preventing the scattering of concern-specific code throughout the application.

The implementation of AOP may vary across programming languages, but a common pattern involves proxies that are generated at compile time. These proxies act as wrappers around the methods of target classes, intercepting calls and executing the aspect logic before and after the original implementation. This interception mechanism ensures that the cross-cutting concerns are seamlessly woven into the application without cluttering the core business logic.

Most popular Inversion of Control (IoC) containers, such as Unity and Spring, come equipped with built-in AOP functionality. However, the full potential of AOP is often underutilized, possibly due to a lack of awareness.

By embracing AOP, developers can significantly enhance code maintainability and reduce redundancy. It provides a centralized and modularized approach to handling concerns that span multiple parts of the codebase, promoting cleaner, more readable, and more maintainable software architectures.

Test-Driven Development

While good development teams write unit tests to test their code, the best development teams practice Test-Driven Development (TDD).

TDD takes an idiosyncratic approach, transforming requirements into tests before the development commences. These tests are expected to fail initially; the development cycle involves refining the code until the tests pass. This pattern results in a growing suite of tests that act as a safety net, ensuring the application functions as intended despite any ongoing modifications.

That key distinction of TDD—creating tests before undertaking development—ensures that the tests are intrinsic to the requirements, and not contingent on the specific implementation details. In contrast, writing tests post-implementation—say against the individual methods of FooManager—can lead to a more rigid system. Changes to the implementation may necessitate extensive rewrites of the tests, making the system resistant to refinement or refactoring. This resistance goes against our goal of agile software.

Instead, TDD promotes the creation of tests at the outermost layer of the program, free from dependencies on internal implementation details. For instance, when developing a microservice, the tests should simulate actual requests, routing them through the request handler and asserting that the responses align with the expectations. Placing tests at the system boundaries facilitates unencumbered refactoring while affirming that the architectural changes haven't introduced flaws.

External dependencies should also be circumvented. Instead of testing against live data sources or APIs, mocks should be employed to create static conditions to test against. By decoupling tests from downstream system uptime and insulating them from data volatility, the stability of the test suite is preserved.

As an additional layer of quality assurance, the Continuous Integration/Continuous Deployment (CI/CD) pipeline acts as a gatekeeper. Any test failures should trigger a halt in the build process, preventing the deployment of the product until detected flaws are addressed. This stringent adherence to testing practices in TDD not only fosters a robust codebase but also instills confidence in the development and deployment process.

Are Agile Development Practices Still Relevant?

The world has changed dramatically since these practices were first introduced. Today, dealing with cloud-native applications and scalable microservices, leads some to question whether agile development approaches are still relevant. I argue that these practices remain indispensable.

Deployment strategies, such as Horizontal Pod Autoscaling (HPA) or Vertical Scaling, cannot replace solid software architecture. While these strategies address immediate scalability concerns—effectively, throwing more hardware at the problem—they are not substitutes for the foundational principles described above.

With their emphasis on creating efficient, lean, and flexible software, SOLID principles provide a timeless framework that aligns seamlessly with cloud-native architectures.

In modern systems that deal with millions of requests daily, the significance of monitoring and security cannot be overstated. Aspect-Oriented Programming emerges as a powerful tool to systematically address cross-cutting concerns, ensuring critical aspects like authorization are embedded throughout the application.

In environments characterized by continuous delivery, Test-Driven Development remains a linchpin for ensuring product quality. TDD enables development teams to react swiftly to evolving requirements; the confidence instilled by a robust suite of tests ensures that each deployment is a controlled and low-risk operation.

Navigating the Future

There is no substitute for good software architecture; the cloud is not a panacea. Crashlooping, memory leaks, and processor spikes all indicate that an application needs architectural revisions.

While the technological landscape has undergone significant transformations since these practices were first introduced, they continue to provide a resilient foundation that thrives in the face of contemporary challenges.

Retrospective

I began working in the technology field in 1998—a bygone era in the ever-evolving Internet landscape. Over the years, I've witnessed the remarkable evolution of the industry and accumulated a wealth of experience and expertise, navigating through transformative waves of technological advancements.

Below, I've grouped my resume into different parts to make it easier to read through, with the most recent—and most relevant—experience first. Naturally, the further back one looks, the less applicable the technologies are. Allaire ColdFusion, anyone? Today, I look back on these early forays into programming with nostalgia and amusement.

Throughout the years, I've embraced the dynamic nature of the tech industry, consistently rising to meet the moment and adapting to the ever-changing needs of the business.

Part I: The Healthcare Years

For the past 12 years—nearly half of my career— I've been a part of the healthcare industry. During this time, I've switched from C# to Java, and then to Go, leading my team through the same transitions.

Part II: The Small-Business Years

Between 2001 and 2012, I worked primarily for small companies in the Buffalo area, including my own: BinarySwitch. During this period, I worked in various sensitive industries, including advertising, real estate, education, healthcare, and more.

Part III: Getting Started

From 1998 to 2001, I transformed myself, ascending out of my first job in the technology industry—building PCs—into a role as a software engineer.

The Early Years

I can’t remember a time when I wasn’t attracted to technology.

As a child growing up in Buffalo, one of my favorite places to visit was the Ontario Science Centre across the border in Toronto. Pressing the buttons on the exhibits to activate the animatronic displays was something I couldn’t get enough of.

Naturally, video games had their allure as well. I can still remember reading advertisements for games that, even then, promised complete freedom and immersive experiences. Eager to dive into new worlds, I saved up the meager income from my paper route to buy a home computer.

It was the 1980s, and there was yet to be a clear winner in the home computing space. After comparing what was on the market, I purchased an affordable Commodore 64. It had a whopping 16-color 320 x 200px display, which beat the contemporary lime-green monochrome display of the Apple II or the fuchsia and teal CGA displays of IBM PCs. Needless to say, the competition quickly caught up.

Stop the Presses

Irrespective of my interest in technology, I didn’t initially pursue a career in computing. I wanted to be a writer. The prospect of being a novelist, inventing whole new realities, fascinated me.

As I grew older, I thought the job of a journalist was more practical. I began writing for my school newspaper, eventually becoming its editor. My flair for reporting led to an internship at the Niagara Gazette. I spent the summer after my sophomore year of high school writing man-on-the-street columns, human interest stories, and other fluff pieces. It wasn’t serious work, but I had a byline in a real newspaper, and that was all that mattered to me at then.

As much as I enjoyed my work as an intern, I noticed that the bullpen reporters were less satisfied with their profession. They were expected to churn out many articles a day and many of them were burned out and cynical. My exposure to these veterans of the job made me less inclined to pursue journalism as a career. Without that longstanding career path in front of me, I felt a bit aimless.

Tragedy Strikes

Midway through my junior year, my parents announced they were getting a divorce. It overshadowed the rest of the school year. In June, I moved with my father to a new house on the other side of town, starting my senior year in a new school. In October, he got remarried.

Then, in early December, my father died suddenly, tragically. The loss of a parent is hard for anyone, but the timing—midway through my senior year—couldn’t have been worse; I could have used his guidance in the years to come, and without it, I began floundering.

Exit Stage Left

In February, when I turned 18, I began living off of my inheritance. I moved out of the home I shared with my stepmother, into an apartment of my own in the city.

Deep in mourning, I became heavily involved in my high school's drama program, which offered distraction and community. Inspired, and longing to hold onto that sense of belonging, I decided to pursue a career in theater.

However, midway through my first college semester, my professor leveled with me and bluntly told me he felt I didn’t have the knack for acting. Completely discouraged, I withdrew from school; without a clear career path, pursuing an unfocused liberal arts degree felt like a waste of time.

Retreat & Survival

Still living off my inheritance, the total lack of either professional or educational commitments meant I was completely free to spend my time working on personal projects. My friends and I, all long-time gamers, began working on making a video game of our own. I would spend my time composing music and developing low-poly 3D models for the game on a 486 DX2 PC I had built for myself. It was one of the most creative times in my life.

Inevitably, though, my inheritance ran out, and reality came crashing in. The music stopped.

I had to work four retail jobs at the same time to make ends meet, but even that wasn’t enough. To avoid homelessness, I moved in with some folks I barely knew.

Eventually, I received an assistant manager position with one of the stores. It provided more stability, but I wasn’t happy with the course of my life.

A First Foothold

I was visiting a friend at his workplace, CS Business Systems, when I heard that there was an opening in their custom PC assembly shop. I was no stranger to tinkering with computers, so I jumped at the chance to build PCs for a living.

After being hired, I soon learned that our department needed an inventory management system. Our sales agents never knew which components we had in stock, and what we’d have to order in.

My friend was too busy developing the company’s core business system to help, so I invested in a few books, learned how to code, and built the intranet application myself, using a combination of MS Access, Frontpage, and Visual Basic.

Coding came naturally to me. I enjoyed the immediate feedback of the building and testing loop. I got a rush from it, and found I entered into flow just like I used to when composing music.

When the company’s service department manager learned about the system I had built, he was impressed. He began sending me out as a consultant to a local manufacturing company. Their technology stack was different—ASP 3.0 and Microsoft SQL Server—but the programming fundamentals were the same. Again, I purchased the relevant books and studied them intensely. I wanted to fight for this newfound career.

Despite my aptitude for programming, my job was still technically with the custom PC department, and my manager wanted me to return to the assembly line. I felt trapped between two worlds, and since I was more interested in development, I thought it was time to move on.

The Climb Begins

It was 1999, and the world was in the middle of the Internet boom. It was a time when anyone with any programming aptitude could easily find a job, myself included. It was only a short time before I landed my first genuine software development job with a small technology startup called Cymfony.

While not its core focus, the company acted as an Internet Service Provider and web host for several well-known local businesses, including WIVB, the region’s CBS affiliate. My role was to support, maintain, and expand these web sites.

I learned a lot over a short time, but as much as I enjoyed my job at Cymfony, I began to seek out a larger company with better benefits the following year. I found it with Computer Task Group (CTG).

I joined CTG’s mission-critical department, working to maintain several of their internal applications. It was my first opportunity to work with a group of seasoned engineers, and I tried my hand at compiled languages for the first time.

Growth and Independence

In 2002, I began working at a local company named LanTrax. They had an EMR product that was my primary focus, but I also supported their other projects, which were primarily in the advertising and real estate sectors. LanTrax is also where I met the woman who would later become my wife.

As time went on, the company began to zero in on real estate as its primary focus, and the EMR software and the advertising projects were getting sidelined. Around the same time, I was getting the urge to start my own business.

I founded BinarySwitch in 2005, and took on the work LanTrax didn’t want anymore. It was a side hustle at first, but eventually, the business grew to the point that I could make a living off it. The owner of LanTrax was happy he had someone to direct his less desirable projects to; we were never in competition with one another.

Running BinarySwitch gave me the freedom to work on my own products. I designed several applications including a desktop background creator, a website-blocking app, an RSS feed aggregator, and more. I was proud to have a company of my own.

While running BinarySwitch, I also invested in myself. I studied for months, passed several certification exams, and eventually achieved the Microsoft Certified Solution Developer (MCSD) certification, Microsoft’s top-tier certification for developers at the time.

Then, the Great Recession came, directly impacting many of my clients. Without a stable income, I began searching for a job. During these challenging times, when many folks were out of work, my lack of degree was prevented me from getting an interview, despite having my MCSD.

One of my clients, RealtyUSA, came through with a job offer, but accepting the job resulted in a massive pay cut.

I decided it was time to return to college.

Back to School

I started taking night classes at the local community college. I took multiple courses over the next several years including Pre-Calculus, English, Psychology, Chemistry, and Intro to Programming, and I carried a 4.0 GPA.

During this time, I also switched jobs again and joined Independent Health for higher pay and better benefits, learning C# along the way.

A few years later, seeking to advance my career beyond coding, I took on a Team Lead position at Fidelis Care. At Fidelis, I took charge of a handful of .NET developers and we all adapted to Java and founded the company's Enterprise Service Bus (ESB).

While I loved managing people, I found that my new job took so much of my time and energy that I couldn’t focus on my education. I struggled with Calculus, and I received my first “B” grade, dropping my 4.0 to a 3.8. Disheartened, I felt it was better to stop attending classes than to let my grades suffer.

Today

In 2018, Centene acquired Fidelis Care, and I was promoted to manager shortly afterward. The team shifted from plan-focused work to corporate-wide initiatives. We retooled again, modernizing critical business logic out of legacy EDI software and into Go microservices hosted in AWS.

In 2020, Centene shut its offices, and we became a 100% remote workforce due to the pandemic.

In the span of time between Fidelis and Centene, I have built out my team from an initial staff of two engineers to a globally diverse, cross-functional team of fourteen. I have led the team through reskilling, transitions in upper management, multiple changes in direction, and layoffs. Through it all I’ve kept the team highly engaged and highly productive, with only minimal attrition.

Though my life has taken a different path than most, I have a long track record of rising to meet the moment by adapting to the needs of the business. I am always eager to learn, ready to lead, and hungry for the next challenge.