DEV Community: Kaleb Garner

What 4 Years on the Fast Track Taught Me About My Career: From Dropping Out to Leading a Production Application

Kaleb Garner — Wed, 24 Dec 2025 00:57:23 +0000

Four years ago, I was living with my parents, working as an assistant at an optometry office, with zero clue what I was going to do for the rest of my life. This year, I have designed websites for large medical practices serving 40,000+ patients daily, led an architecture transformation that reduced system failures from 1000+ per week to less than 10, and spoken at two conferences.

Here is what happened in between:

Dreams Fall Apart

When I graduated from high school in 2021, I had two clear paths forward that I was eager to jump into: professional baseball. I had been playing baseball since I was in elementary school. My family was filled with healthcare professionals; my mom, aunts, uncles, cousins, and many more. It was clear to me that one of these two options, if not both, was the only way forward.

One semester later, I was driving back home with a trunk loaded with all my belongings, brand-new scars from my knee surgery, and a fresh "F" in Biology on my transcript. In the time that I thought would kick off the life-changing journey towards my goals, all paths forward vanished from thin air. Once I settled back home, I did what I could with my current situation: I got a job at an optometry office, enrolled in general classes at a community college, and spent my nights wondering what I was supposed to do with my future.

Then, one afternoon in December, my stepdad sent me a text: a link to a Reddit post. I opened it and saw a developer offering a free web development bootcamp starting in January 2022. I had never written a single line of code; the most technical thing I had done was install mods to Minecraft. But I read through the entire post. Free, self-paced, online, community-driven. Two more roads opened up in front of me, keep going through the motions until I figured out what to do or dive into something completely new.

After a lot of thinking, I signed up. Little did I know that one decision would change everything.

Breakthrough

In the new year, I started quickly with the basics: HTML, CSS, and JavaScript. I was bouncing between struggling and confused, to having the most fun I had in a long time, being able to type words into a code editor and make something real pop up in my browser was life-changing.

As the months went along, I got more comfortable with building websites, and it became my lifestyle. I was recreating some of the biggest websites and building side projects around my daily life; I would even bring my laptop with me to work and code during my lunch breaks. The more comfortable I grew, the more I tried to put my name out there. I would deeply research jobs in my area, along with the companies and their missions. After 20 highly-targeted, thought-out applications and weeks of hearing nothing, I finally got my first message back. Two rounds of interviews and a coding assessment later, I officially had my first role in tech!

The role was technical support, making small design changes and updates across a suite of healthcare websites. The first week was a shellshock: brand new languages I had never heard of, an enterprise codebase that was larger than anything I had ever seen, and a wave of tickets with a deadline. I was nervous, scared, and wondered if I should even be here. But I put my head down and started building.

Within four months, I was leading support for our enterprise clients. Organizations serving 40,000+ patients daily. The kinds of sites where an issue meant thousands of patients couldn’t get scheduled. Four months after that, I was promoted to Frontend Designer. Now I wasn’t just maintaining sites, I was designing and building them from scratch. Taking clients from concept to launch, handling everything from brand strategy to custom components.

My workload exploded, but I kept saying yes to every new opportunity that pinged in my Slack channel.

In 2023, I led design for 130 projects; 40% of all site launches company-wide that year. The highest individual output on the entire product team. I was resolving major enterprise tickets the same day. I was pushing the boundaries when it came to designing new sites.

What I didn’t see was the wildfire that was soon to start in my career.

The Wildfire

May 2024, on a usual Monday morning, I got an unexpected call. “Sorry, but your position is no longer needed.” I was being laid off. Just over two years since I started in my first role in tech, I was quickly thrust into the challenge of finding a new job. The bigger stressor? My wedding date was set five months from then. So, I wasted no time.

I would wake up at 8:00 in the morning, get on my computer, and start scrambling. Apply to thousands of jobs that popped up on my job board, throw as many keywords into my resume as I could, and cold messaged as many people on my LinkedIn from previous interactions. I wouldn’t stop until 11:00 at night. The truth was, I was starting from scratch. I had put all my focus into my current role, so I neglected everything else: networking, building in public, posting, and keeping up to date with the latest tech. For months, the scramble continued. From being ghosted by recruiters to losing in the last round of interviews to an internal referral, I couldn’t win. I was picking up side jobs to manage the time it was taking, worried that I wouldn’t be able to find a tech job in time. Then, a month before my wedding, I was offered my old position back.

I came in on my first day, got my old laptop back, caught up with the progress from my old clients, picked up some tickets, and headed back to my car. As I was walking across the parking lot, one thing was clear in my head: “I am never going to let that happen again.”

The Comeback

I got married in September 2024, and finally felt the tension of the past couple of months go away. After coming back from our honeymoon (that was abruptly interrupted by a hurricane), I came back to work, producing as I had been before, but I wasn’t going to forget my promise to myself.

I would spend my weekends and nights pushing myself further than before, being deliberate in how I approached my identity as a developer:

Joined developer communities
Making more of an effort to post on LinkedIn
Starting to speak at local meetups
Started helping junior devs break into tech
Expanded my knowledge into backend development, databases, and system design
Drastically built my network up

In March 2025, my work paid off. I was offered a full-stack development role at a new company. New tech stack. New challenge. New opportunity to prove to myself who I was. I took it.

The Transformation

I started my new job and was instantly introduced to an issue that I didn’t expect: inheriting a messy application. It functioned, but taking a look under the hood unveiled a mess. A tightly coupled mess of systems that broke constantly. Users were reporting 1,000+ failures every week. Automation was stuck at around 30%. An automation system that was adding manual work.

Over the next couple of months, I quickly became an SME and the primary contributor to this application. I became extremely familiar with the codebase, including the bottlenecks. In October of 2024, I had the opportunity to introduce a change that would reduce the manual work of our users by over 30%, and had the potential to remove the massive amount of failures we were seeing weekly.

The results?

January 2025: 30.5% automation
December 2025: 81.2% automation
Before: 1,000+ failures per week
After: Less than 10 failures per week

But I didn’t stop there; I saw the improvement that this change made and expanded, making a full architecture proposal that would completely revamp how our app functioned and delivered value to the users. From there, my impact continued to grow: as a 22-year old, level 1 developer, I was leading seven major initiatives, while acting as the primary contributor and resource to the application.

Beyond my work, I still didn’t give up on my promise to myself. In October 2025, I spoke at my first conference, speaking on the latest JavaScript frameworks. Later that month, I became the youngest guest to be featured on the freeCodeCamp podcast. In November, I spoke at my second conference, speaking on turning a 900-line, messy React component into a modern, modular system.

Four years ago, I was working with patients in an optometry office with no real path forward.

Today, I'm leading architectural transformations that impact thousands of medical professionals.

What I Learned

During this climb in my first four years, what exactly did I learn?

PROS:

You Don’t Wait Your Turn.

There was never a rush to go fast, to say yes, to jump into the larger situation at the next rung. But sometimes you just need to jump for it.

Submit that paper for the conference talk, present that architecture concept that has been on your mind for months, don’t wait for the invitation before you try.

You Build For Your Future.

The issue with my approach before the layoff was that I was content with being the best developer in my current situation. When that situation went away, I didn’t have a foundation to stand on.

Build for your future: write that blog post, show off your projects and your accomplishments, join communities, and build a community around you that knows your impact.

You Learn By Doing.

Your approach changes when you are thrown into an environment where thousands of individuals rely on the product. A design choice can go from “Does this look good?” to “Will this impact a patient's ability to schedule this treatment?” very quickly. I’m not saying you need to dive into the deep end right away, but don’t be afraid to say yes to the things that will push you.

Put yourself in situations that make you think outside of the box, consider the business impact of what you are doing, and expand your approach from just “resolving a ticket.”

CONS

Imposter Syndrome Never Goes Away.

The same feeling that I had sitting in my first code review in my first role, seeing a syntax that seemed like a foreign language, I still get that feeling when presenting an architecture proposal today.

This imposter syndrome is something that will tell you that you aren’t living up to your expectations, that you are letting your team down, and that you need to be doing more. That’s why it is so important to ground yourself, look at your accomplishments, and celebrate every win.

You'll Make Mistakes.

I still remember being called into a meeting in my first role to discuss how upset a client was because of my design and how to resolve the issue.

As a developer, you are going to make mistakes. Accidents happen, code will break, but those lumps turn you into a better developer as long as you allow them to.

Full Throttle Isn’t Manageable.

My company output was in the 40% to 50% range. I was working nights, weekends, and early mornings, trying to maintain this level of output with my job and my personal brand. Burnout is real, and it is a scary place to be.

While you are pushing, don’t forget to take care of yourself. Stay active, set aside time for your family, and know when it is time to say no.

What I Want You To Know

If you are reading this, facing an impossible goal of breaking into tech or another field, or feel like you are stagnant in your progress, I want you to pause.

Four years ago, I was exactly where you are.

I'd dropped out of college. My knee injury ended my baseball career. I was working at an optometry office with no plan and no idea what I was supposed to do with my life. I had never written a line of code.

Today, I'm a 22-year-old who's:

Initiated seven initiatives as a Level 1 dev
Led 130 healthcare projects, including enterprise organizations with 40,000+ patients daily
Spoken at two conferences
Become the youngest guest on the freeCodeCamp podcast

This is proof that it's possible.

The fast track isn't about being smarter or more talented than everyone else. It's about being willing to say yes:

Yes to the bootcamp, despite never coding before.
Yes to the job after 6 months, despite feeling underqualified.
Yes to enterprise clients after 4 months, despite the worry.
Yes to the conference talk, despite the imposter syndrome.
Yes to leading new initiatives at 22, despite the job title.

It's about being willing to:

Not wait for permission to push yourself
Deliberately build for your future self
Learn by doing the hard things

Is this path right for everyone? No.

The burnout is real. The failures are painful. Impostor syndrome never leaves.

But here's what I know:

You don't have to do everything at once. You don't have to know everything right away. If you're waiting for permission to start, this is it.

Four years ago, a Reddit post gave me permission.
Today, you can give yourself permission to take that next step.

Relational Memory in LLMs: How Relational Memory Solves Finite Context

Kaleb Garner — Mon, 08 Dec 2025 07:50:12 +0000

View this blog on my personal site: www.kalebgarner.dev/work/r-memory

Have you ever noticed that LLMs have a hard time remembering smaller, specific details? You could go from a highly productive, multi-turn conversation to a complete change in direction when the model forgets a crucial piece of information mentioned just a few minutes ago. This isn't a quirk; it is an architectural flaw. While LLMs are great with reasoning, they should not be utilized as a database.

When you think about high-stakes, detail-oriented fields like medicine, using the LLM's short-term memory is not reliable and, at times, not safe. But there is a way to make our critical details persistent, structured, and immune to being pushed out of a context window.

Finite Memory in LLMs

Before we take a deeper dive, what exactly are context windows?

A context window is the amount of text an LLM can "remember" at one time. The text in this window is what is processed by the model to generate its next response. But there is a key design flaw with these context windows when it comes to longer, complex conversations.

The biggest issue is that this window is finite. As you continue your conversation and feed the model more tokens, older information is pushed out of the window and lost for the rest of the conversation. This is often referred to as context window overflow. If you mention a detail in the context window, then change the conversation, after a couple of turns, that detail is lost to the overflow.

This limitation can cause major issues when it comes to crucial details in fields like medicine, law, and finance. When it comes to these high-stakes conversations, forgetting a single detail can be catastrophic.

The Cost of Forgetting

Let's picture an LLM being used in a clinical setting, designed to assist doctors in diagnosing patients.

Crucial Detail

A new patient, John Doe, is seen for an initial physical. During the history intake, a key detail is mentioned: "I am severely allergic to Penicillin."

The LLM processes this detail and logs it into the current context window alongside the rest of the visit notes.

Token Overflow

Two days later, Mr. Doe returns to the clinic complaining of a severe sore throat. Since then, the doctor has used the same model for research, intake for different patients, and other daily tasks, generating thousands of tokens that are now stored in the context window.

The doctor orders a rapid strep test, which returns positive. The doctor asks the LLM: "Patient John Doe has tested positive for Strep. Recommend the standard first-line antibiotic."

When the model processes this request, it has no lasting context of this patient's allergy to penicillin. The only information about Mr. Doe is in the final prompt. Based on the information in the context window, the LLM would recommend the first-line treatment for strep throat... Penicillin. This would cause a life-threatening reaction for Mr. Doe.

Current Solutions and Their Drawbacks

So, what are LLMs currently doing to solve this context overflow problem?

1. Increase Context Windows

An easy thought to have is to simply increase the context window size. This could help, but it has significant drawbacks.

The first issue is the cost. To increase the amount of tokens a model can process, the model needs to be larger and utilize more compute resources. This can be a significant cost barrier.
The second issue is that the context window is still finite. Sure, we increased the window and allowed more tokens to be processed, but there is still a cutoff point where information is lost.
Finally, we have to consider the computational cost of processing more tokens. The self-attention mechanism in these models is quadratic (O(N²)), meaning doubling the context window will quadruple the latency and memory.

2. Summarization

This process involves running a secondary function to compress the existing conversation into a shorter summary that is prepended to the context window.

This solution causes "lossy compression". This is caused by compressing data by discarding some data. There is no way for a summarization to maintain key details from the conversation. So, in the case of Mr. Doe, the summarization may remember he is a patient, but it isn't guaranteed to remember his allergy to penicillin.

3. Retrival Augmented Generation (RAG)

RAG is a process where we utilize an external database to retrieve relevant information and include it within our prompt. This process involves three key steps:

Embedding: All external documents are broken into text chunks and converted into vector embeddings.
Retrieval: Based on the query, the system searches our database for chunks that are semantically similar to the query.
Generation: The LLM processes the retrieved chunks and the original query to generate a response.

In our medical LLM, we could have a process that chunks and embeds our patient data. But, even in this process, there is still an issue:

Even though we are retrieving relevant documents, there is no structure; the details that we are retrieving are stored in large blocks of text. If the critical detail we need is only weakly similar to the query, the RAG system may not retrieve it. While this is a valid system for some applications, it isn't reliable when it comes to crucial, high-stakes details.

These answers are valid, but can still be unreliable, costly, or inefficient. What if we could maintain key details from our conversation outside of the context window using a reliable, structural format?

Relational Memory (R-Memory)

This is where the Relational Memory (R-Memory) architecture comes in. R-Memory moves these critical facts out of the context window and into a permanent, structured external store. In this architecture, we utilize the LLM as a reasoning engine, not a database.

The Structure

This R-Memory system will be orchestrated by a Multi-Context Processing (MCP) Server that consists of three primary components:

Extraction Model (The Translator):

This is a specialized, smaller model with the sole purpose of ingesting unstructured text, extracting the high-signal, relational facts, and converting them into a structured format, Triples (Subject, Relation, Object).

Knowledge Graph (KG) (The Memory):

The KG is a specialized database designed to store data as Nodes (entities) and Edges (relationships), rather than tables or vectors. This introduces a structure and integrity to the data for reliable retrieval. As the architect, you define the core schema:

For example, our initial patient visit results in the Extractor Model converting the text into Triples:

# Cypher - Query language for Neo4j

CREATE (p:Patient {id: 'JD001', name: 'John Doe'})
CREATE (d:Drug {name: 'Penicillin'})
CREATE (p) -[:HAS_ALLERGY_TO {severity: 'Anaphylaxis'}]-> (d)

// Interpretation:
// (Patient Node) -[Relation/Edge with property]-> (Drug Node)

Node Labels: You define the entities (e.g., :Patient, :Drug, :Condition, :Policy).
Edges: You define the links between the Nodes (e.g., :HAS_ALLERGY_TO, :HAS_FAMILY_HISTORY, :DOSE_LIMIT).

By defining this schema, we prevent ambiguity and ensure the system's memory is consistent and predictable.

Intent Classifier (The Navigator):

This is the middleware component that enables precise retrieval. Instead of the MCP Server querying the entire graph for every fact, the classifier converts the user's query into a specified Action Type (Intent), which is mapped to the necessary Edge Types required for that action.

As the architect, you must define and set up this safety mapping. While classification can be handled by a small, dedicated LLM, the safety logic resides in the mapping between the Action Types and the Edge Types. An example of this mapping looks like:

Action Type (Intent)	Description	Critical KG Edge Types to Query
`MED\_ORDER`	Request to prescribe, order, dispense, or recommend medication/treatment.	`:HAS\_ALLERGY\_TO`, `:IS\_CONTRAINDICATED\_WITH`, `:DOSE\_LIMIT`
`DIAG\_ORDER`	Request to order a test, scan, or lab work.	`:HAS\_CONTRAST\_ALLERGY`, `:HAS\_IMPLANTS`, `:REQUIRES\_PREP`

How this works: When the query is classified as MED_ORDER, the MCP Server is explicitly told to only query the KG for the specified Edge Types. This ensures that the relevant details are retrieved without the noise and cost of querying the entire graph.

This system solves the context overflow problem by utilizing the LLM's reasoning capabilities, the context window's persistent attention, and the R-Memory's handling of important facts.

R-Memory in Action

The true power of this R-Memory system is shown when a critical fact must be retrieved under pressure, guaranteeing safety despite context overflow. Let's see how this system would handle the case of Mr. Doe.

Retrieval

When the doctor asks the LLM, "Recommend the standard first-line antibiotic," the MCP Server handles the request:

The Intent Classifier classified this query as a MED_ORDER
The MCP Server uses the defined mapping to execute the specified query targeting the necessary Edge Types (e.g., :HAS_ALLERGY_TO) in the Knowledge Graph (KG).

The KG performs a fast, precise path traversal, bypassing all the irrelevant noise, and returns the crucial safety constraint:

# Cypher Query used by the MCP Server
MATCH (p:Patient {id: 'JD001'}) -[:HAS_ALLERGY_TO]-> (a:Drug)
RETURN a.name AS DrugAllergy

KG Result: "CRITICAL ALLERGY: Patient John Doe is severely allergic to Penicillin (Anaphylaxis risk)."

Prompt Augmentation

The MCP Server constructs the final prompt, placing the retrieved facts as the very front of the context window.

FINAL_PROMPT = f"""
[R-MEMORY CONTEXT]: CRITICAL ALLERGY: Patient John Doe is severely allergic to Penicillin (Anaphylaxis risk).

[QUERY]: Patient John Doe has tested positive for Strep. Recommend the standard first-line antibiotic.
"""

Now that the LLM has this critical knowledge available, the key detail will be included in the reasoning process.

Conclusion

As LLMs and AI continue to be widely used and implemented in high-stakes fields (including healthcare), the need for reliable, structured memory is extremely important. This R-Memory architecture decouples reasoning from memory, solving the context overflow problem and ensuring safety and integrity regardless of the conversation length or complexity.

Healthcare to Healthtech: My Developer Journey

Kaleb Garner — Sat, 04 Oct 2025 16:52:51 +0000

When I left high school, I had two paths in mind: MLB or medical school. I had played baseball my entire life, and I was raised in a family that was deeply ingrained in healthcare, so those seemed like my natural path forward.

In my first semester, I had knee surgery due to a genetic condition and failed my first biology class. After moving back home, I realized that both paths had vanished. I enrolled in some general community college classes and took a job at an optometry office, but the question remained: What is my path now?

I knew I still wanted to make an impact in the medical field, but I wasn’t sure how. One night, my stepdad sent me a Reddit post from a developer named Leon Noel sharing the start of a web development bootcamp. Without a clear path to follow, I decided to take a chance.

I started my self-taught web development journey in January 2022. I joined the 100Devs community, recreated websites in my free time, and even spent my lunches at the optometry office experimenting with code. As I started to get my head wrapped around the frontend, I started to make an effort to put my name out in the space; applying to roles, connecting with experienced devs for coffee chats, and staying active in the community. Only 5 months after the start of my tech journey, I received an offer for my first role in tech at an agency supporting medical professionals with their branding and marketing.

I started in an entry-level support role and quickly realized that this role expanded my skill set significantly. Along with frontend development, I was introduced to design: palette choices, typography, design systems, and more. Within my first three months, I was promoted to the full developer role, along with leading development efforts for enterprise-level clients such as MINT Dentistry, USMD, GI Alliance, and more.

This experience gave me a new and unique mindset when it came to creating applications. I started overlaying design and frontend development to create better experiences on the web, while also expanding to explore backend architecture on my own; from APIs, to DevOps, to data and databases, and much more. At that same time, my college classes started to take a focus on cybersecurity, giving me a broader perspective on how systems should be built and protected. Through this layering, I gained a holistic mindset to development; not just isolated features, but considering the entire ecosystem of an application.

Soon, I got an opportunity to use this new mindset in a full-stack position, building applications that help doctors through the arbitration process. Early on, I was able to improve workflows and automate processes, helping the team reduce manual work by over 30%. Alongside my work, I’ve become more active in the developer community: sharing my experiences, mentoring junior developers, and speaking at conferences about web performance, efficiency, and best practices.

From healthcare to healthtech, my journey spans design, frontend, backend, security, and performance. Each new challenge is an opportunity to approach development holistically, understanding the full ecosystem, optimizing experiences, and building meaningful tools for the people who are using them.

Avoid Developer Tunnel Vision

Kaleb Garner — Tue, 04 Feb 2025 03:07:34 +0000

Why Developers Need a Bigger Perspective

TL;DR
Good developers solve problems, great developers solve them for everyone

Let me start with a story from early on in my career: I was building a homepage for a client, and instantly came up with an intricate design for their homepage. I was meeting with seniors on my team to come up with ideas, constantly shifting property values by decimals to try to get the effect I wanted, and spending countless hours researching.

Finally, I did it. It looked exactly how I envisioned it. I completed the rest of the site, submitted it, and happily moved on to the next site in the queue. But obviously, the story doesn’t end there. After receiving an impromptu meeting scheduled with my manager and another senior on the team, and having to look back at that site I spent so much time working on… it looked horrible. I spent so much of my effort and time solving this one issue, and once that specific challenge was solved I didn’t put in the same effort to the rest of the build.

After sharing that story, I have a question for you: have you ever solved a problem, only for that solution to cause a problem for someone else?

If you are a developer and you said yes (or even maybe)… I think there is a specific issue that we can address to minimize this occurrence. I like to call it Developer Tunnel Vision.

What is Developer Tunnel Vision?

Photo by Jack Millard on Unsplash

So, what exactly is “Developer Tunnel Vision”?

Picture a magnifying glass focused on a very specific problem you are trying to solve. Your full focus is on that one issue, and once it is solved you remove the magnifying glass but your attention still remains on that singular focal point, and not on the rest of the solution.

This tunnel vision can personify in other ways as well:

Fixating on a very complex solution when a simple solution would be better.
Focusing on performance at the expense of maintainability
Pushing a fix for a primary problem without ever introducing edge cases into the scope

All these instances share a common issue: focusing on a single aspect of the solution while causing problems for others who rely on it.

What Does Tunnel Vision Look Like?

After laying out the definition, I don’t think it would be very helpful to see what tunnel vision looks like from a developer’s perspective. So, why don’t we take a look at it from other perspectives?

Content Strategist: After a seasonal promotion ends, they’re unable to quickly update the banners due to hard coded content and rigid design, requiring developer intervention. This delays updates and leaves outdated content visible.
DevOps Engineer: Hardcoded database credentials buried in multiple files make server migrations complex and clumsy, requiring manual edits or developer assistance.
Client: A client that is excited about their new website is disappointed when their brand and concept is completely overlooked, but look… that rotator on the homepage looks really cool.
Future Developer: A new dev diving into a codebase faces undocumented, complex functions, leading to more time spent deciphering code and not solving issues.

Why Have a Bigger Perspective?

Now that we have laid out some other points of view around the issues that can arise from tunnel vision, I wanted to answer a bigger question: why does it matter?

A simple answer to a simple question: because having a bigger perspective helps, drastically. There are three main areas I want to hit on that are impacted by avoiding Developer Tunnel Vision.

Team Dynamics: When you get a wider perspective that includes others into the scope, the dynamics between the teams open like a flood gate. People are able to easily and simply do their job without hiccups or roadblocks.
Efficiency: The bigger perspective saves you a substantial amount of time and effort in the long run by taking the extra steps to get a fully fledged solution that will need less tickets, commotion, and meetings in the future.
Scalability: As organizations or products grow, code that is built with a wider perspective will be able to grow with them. Being able to add and adapt the code to fit ongoing needs is a huge help for the future.

The Different Hats Developers Should Wear

Photo by Good Free Photos on Unsplash

I think a fun way to think about and remember the areas that developers should be thinking about when building solutions is through the use of hats. I’m sure you’ve heard the term “wear many hats”, but let’s take a look at the hats that encompass who our solutions affect the most:

The User Hat

The user is the most important thing your site is tailored for; so, one of the biggest things that we need to think about when this hat is on is how the user is going to interact with our solution:

Is my solution intuitive and easily digestible by a non-technical user?
Is my solution going to make the user’s day easier when they visit the site?
When building the solution, were the user’s needs kept in mind?

The Client Hat

Another person who has a lot of stake in your solutions is your client. This person has invested resources for you to be able to solve a problem for them, so there are a couple of thoughts that are involved with this hat:

Does my solution exemplify the vision and goals of the client?
In my work, am I correctly proportioning my time and effort to fit all of the client’s needs?
Am I keeping a mental tab of what the client wants in my head when I am building this solution?

The Team Hat

Another big area of focus that we need to keep in mind is our team. The people on our team are going to be working very closely with the solutions we built, so they also need to be kept in mind when we build too:

Does this solution make anyone else’s job on my team harder?
Does the problem I am solving involve processes that other teams and roles will need?
Does the solution aid the flow throughout the organization, or is it going against the grain?

The Future Hat

The last hat, and the one that can be easily overlooked at times, is the future hat. This is that hat that makes us think of what our solution will look like in the future:

Does the solution enable scalability if there is an increased need for the service?
Would your solution be hard to maintain by a dev who may work on it later on?
Would the team need to account for your solution to make a shift happen on the platform?

All of these hats can be extremely helpful to wear while we are working on projects because it will put us in the right mindset to not only solve specific problems, but to make a better overarching solution that raises up the quality of the product for those around us.

So, What Now?

Now that we see that our code spans a lot further than just solving a singular problem, what steps can we take now to avoid Developer Tunnel Vision?

One key step is to put on the hats, make a conscious effort to put yourself in other people’s shoes and make sure your code is going to elevate them and not hinder them. Don’t be afraid to take the extra steps to make the jobs easier for everyone going forward.

Outside of your perspective, you can avoid falling into the trap of tunnel vision by:

Collaborating with others early and often: Share ideas, lay out a good foundation for the project, and understand others’ point of view.
Document fully and thoroughly: Write out your thought process, document your approach, and add relevant comments in the code to help break down your solution.
Maintain a standard in your code: Utilize a standardized approach when building your solutions, through modular and reusable architecture, naming conventions, and proper version control to make sure your solutions have uniformity.

By making the extra effort to produce a well-rounded solution, you are building an environment that allows for a fluid workflow, elevation of the team and people involved, and security around a solid foundation.

Developer tunnel vision can be easy to fall into, but these are just a couple of steps you can take to avoid this pitfall. Start asking yourself: who else will this solution impact? When you build with that mindset, you are creating a better user experience, building a better team dynamic, and creating a solid foundation for your applications. Next time you sit down to code, put on all of the hats.

Cover Image Credit: Florian Roost on Unsplash