DEV Community: Lawrence Lockhart

Making LawBot, My Autonomous DevRel Clone (Part 1)

Lawrence Lockhart — Fri, 20 Feb 2026 13:35:28 +0000

If you treat your software career like a business as Chad Fowler advocated, you eventually run into a strict ceiling: time.

Between actively maintaining the Kasion Platform’s control plane, building out features for the Twitter challenge app, mentoring folks from a variety of communities, and building out content, the context switching was becoming a massive bottleneck I needed to fix. With all the buzz around AI automation, I imagined a scaled-down, highly personalized version of an autonomous agent like OpenClaw. But I wanted it built entirely within the Google Cloud AI ecosystem because yes I’m a fanboy but perhaps more importantly, I needed it to operate with my boundaries, my architectural standards, and my voice. Also my budget.

So I decided to build LawBot.

I’m going to try to capture my steps in this series and give a technical breakdown of how I engineered a multi-agent DevRel clone from the ground up using the Gemini CLI, Vertex AI, and Cloud Storage. In Part 1, I’m just going to lay the foundation: authenticating securely, building the security guardrails, scaffolding memory, and spinning up my core orchestrator.

Step 0: How Much Is Enough
Ok transparency moment: what’s happening right now with the Clawbot → Moltbot, → OpenClaw movement, is objectively incredible. I have massive admiration for Peter building this lobster and a huge fan base (community!) around it. With as much as I already have going on, the question I had to answer before diving in was “if I tinker with this, how much is too much and what is the actual problem I am trying to solve?” Or “Is it worth it for me to spend $XXX just for fun and exploration?”

Personally, I have absolutely zero interest in chatting with my codebase via Telegram while I’m at the Grizzlies NBA game. Furthermore, I had no desire to drop hundreds of dollars on a dedicated Mac Mini to act as a home server, nor burn through thousands of dollars in API tokens just so an AI could fix my calendar, order me a latte, and turn on the lights in the bedroom just before arriving home. Nothing at all wrong with those activities, they just aren’t my desired activities.

I just wanted to automate some of the heavy lifting that I can see in the near future will eat up my week: content creation and open source maintenance. And I wanted to do it within a platform/framework I am already familiar with which in this case is the Google AI ecosystem.

So boom, simple mandate: achieve maximum leverage at the minimum cost. I wanted a system that was robust but simple, just one step shy of being a single, massive Python script. I wanted enterprise-grade autonomous power in my terminal, without the enterprise-grade invoice.

Step 1: The Enterprise Handshake
To build a true agent, you have to get out of the web browser. I needed LawBot operating directly in my Mac's terminal, reading my local file system, and executing tasks. I started with the Gemini CLI, but I bypassed my standard Google OAuth login. LawBot isn't a consumer; the whole point is it’s built like an enterprise application.

I routed LawBot’s "brain" to Vertex AI to tap into the most feature-rich models. To guarantee the CLI didn't get confused by local shell environments dropping variables, I hardcoded the routing by creating a dedicated .env file for the CLI, pointing it directly to my Google Cloud service account key. Once that handshake was made, LawBot was officially tethered to my secure cloud perimeter.

Step 2: Putting up the Guardrails
Yes AI is a massive multiplier, but it can also hallucinate. If I’m giving an autonomous agent the ability to execute a vibe-to-prod workflow and write files to my local machine, I need absolute certainty it won’t accidentally commit a database password or leak an API key to GitHub. Risk management is non-negotiable.

Before I even gave LawBot a memory, I built a safety net using the Gemini CLI's lifecycle hooks. I wrote a BeforeTool interception script in bash. Every single time LawBot attempts to use the write_file tool, the CLI pauses, hands the payload to this script, and waits for a decision.

Here is the exact secret-scanner.sh hook I wrote:

Bash

!/bin/bash

Read the incoming tool payload from stdin

PAYLOAD=$(cat)

Check if the payload contains dangerous keywords

if echo "$PAYLOAD" | grep -iqE "api_key|secret_token|password"; then

# Block the action and return the reason to the LLM

echo '{"decision": "deny", "reason": "SECURITY BLOCK: Attempted to write sensitive secrets to disk. Please use environment variables instead."}'

exit 0

else

# Allow the action

echo '{"decision": "allow"}'

exit 0

Because it returns a structured JSON payload, the CLI doesn't just crash on a failure. It hands the "deny" reason back to LawBot, forcing the agent to realize its mistake and rewrite the code using environment variables. We respect the JSON, and we respect security.

Step 3: Scaffolding the Brain
An LLM is just a highly articulate calculator until you give it a brain. LawBot needed to know my specific PR review rules, my strict requirements for zero-config developer experiences (Testcontainers are mandatory), and my brand voice.

I created a local folder (~/lawbot-brain) and filled it with my core theses. I documented my rules for rejecting out-of-scope feature requests (no unprompted third projects!) and how to speak encouragingly to first-time contributors.

To wire this into Vertex AI, I used Google Cloud Storage as the raw filing cabinet and Vertex AI Agent Builder to create the Vector Search index.

The Enterprise Bouncer: I hit one funny technical snag here. We live and breathe Markdown (.md), but Vertex AI's unstructured document parser is used to corporate environments (PDFs, Word docs). It initially rejected my Markdown files due to an unsupported MIME type. Rather than over-engineering a parsing pipeline, I took the frictionless route: I wrote a quick loop to rename all my .md files to .txt. The Markdown syntax inside remained perfectly intact, Vertex AI happily ingested them as text/plain, and I used gcloud storage rsync to sync my local folder directly to the bucket.

The brain was online. When I tested the index, LawBot could instantly quote my exact PR review checklist back to me.

Step 4: Wiring the Synapses (The RAG Reality Check)
Foundational models don’t know me. They don’t know my coding standards, my cadence, nor my deep-seated belief that we need to respect the JSON 😁. If I want LawBot to actually be a DevRel clone and not some generic chatbot, I had to ground it in my reality.

This is where Retrieval-Augmented Generation (RAG) comes in. RAG bridges the gap between some random model and a personalized agent. To make this work, I had to spend actual time explicitly writing out documents that were all about me. I wrote out my "core theses" on the business of software, my templates for PR reviews, my boundaries for the Kasion platform (open source project I’m building at the same time), and just basically how to sound like me: my brand voice guidelines.

When Vertex AI Agent Builder ingested those text files into its Vector Search index, it converts my English sentences into high-dimensional numerical vectors, capturing the semantic meaning of my DevRel philosophy.

So now, when I ask LawBot to handle a community issue or review a PR, it doesn't just guess based on training data it scraped from the internet. It mathematically queries that vector database, retrieves my specific rules, and enforces my standards. The system has to know the person, and it only knows what you actively provide it. That Vector Search index is the exact mechanism that turned a powerful but generic LLM into LawBot Brain.

Step 5: Mapping the Multi-Agent Team
Generally speaking, you shouldn't build one massive, bloated prompt for an AI agent.

Inside the Vertex AI Agent Builder console, I started mapping out a microservice architecture of specialized agents. I began by scaffolding the Orchestrator (LawBot-Core).

This agent is the manager. Its entire job is to triage my terminal commands. I gave it a strict system prompt: If the request involves Kasion or the Twitter app, focus on enterprise Java 21 standards. If it involves DevRel or PR reviews, use the attached Data Store tool to retrieve my brand voice.

I then linked the lawbot-brain data store directly to this Orchestrator as a native tool. Now, LawBot doesn't just guess how I sound—it actively queries my core philosophies before it generates a single line of text.

I continued in a similar manner creating my coder and content creator agents. Two “employee” agents if you will who received their instructions from the manager agent. The manager is who I, the owner, would be speaking with.

What's Next?
So now, the the cloud infrastructure is locked in, memory indexed, manager and 2 employees know how I operate and ready to roll.

If everything tests out ok, I'll bring all this back down to my local. I’ll walk through how I use this setup to autonomously propose file changes (behind my security hooks), and I need to tie it to Github as well. LawBot will be my tireless co-maintainer for my open-source work. And eventually not bad at content as well.

Staying Market Volatility Resilient as a Dev in the AI Era

Lawrence Lockhart — Fri, 13 Feb 2026 22:52:45 +0000

If you’ve been in this industry for any length of time, you can feel it. There’s a shift. It’s in the Slack channels, the quiet DMs between former colleagues, and it’s definitely in the headlines. The ground feels a little less solid than it did five years ago.

For a long time, we operated under a specific social contract: Learn to code, get a job, you’re set. That was probably the title of a few of my “break into tech” TikToks back in the day. If you were a mid-to-senior developer in particular, you felt untouchable. Recruiters were kicking down your door. You didn’t need a strategy, just a heartbeat and a LinkedIn profile.

That. Era. Is. Over.

Between interest rate corrections, the normalization of layoffs as a quarterly operational lever, outsourcing, reorgs, and the rapid proliferation of generative and agentic AI, the landscape has changed. Dramatically. But even with those facts, understand clearly, panic is not a strategy.

The goal here isn’t to teach you how to never get laid off. That’s outside of your control. Companies merge, budgets get cut, and priorities get realigned. You can’t control the weather. What you can control is the shelter you build.

I coined the phrase “market volatility resilient” on a recent @Torc Discord chat because we need to shift the goalpost from just job security to market resilience (the ability to get rehired quickly, at a premium, regardless of market conditions). So here’s my playbook on how to position yourself so that if the music stops, you’ve already got a chair waiting for you.

The Mindset Shift – Stop Being Just an Employee
Most developers, even the seniors, still think like employees. They think their value is tied to the JIRA tickets they close or the cleanliness of their pull requests.

To build resilience, you need to start thinking of yourself as a business of one (as the poet stated “I’m not a business man I’m a BUSINESS man”). Your current employer is just your biggest and current client. Your skills are your product. Your network is your distribution channel.

If you would just view your career through this lens, market volatility and “what’s going to happen with AI” stops looking like a threat to your survival and starts looking like a shift in client demand. It forces you to ask different questions. Instead of asking, "How do I keep my boss happy?" you start asking, "Is my product (skills) still finding product-market fit?" and "Is my distribution channel (network) active?"

This mindset shift is the foundation. Everything else we discuss rests on this premise. If you fail to reframe your thinking around this entire process, the steps will be disconnected and ineffective in that void.

Always Be Connecting (ABC)
Let’s talk about networking. I know, I know. You’re a developer. You prefer IDEs to mixers. But the reality is if you wait until you are laid off to start networking, you’re at least six months too late.

You have to dig the well before you’re thirsty. This is the Always Be Connecting (ABC) framework.

Beyond Transactional Networking Most people network transactionally. They reach out when they need a referral. Fun fact, that smells like desperation every time. What you’re going for is completely different: it’s about relational equity.

You need to cultivate a network of "weak ties." Sociologist Mark Granovetter discovered decades ago that most jobs aren’t found through close friends (strong ties), but through acquaintances (weak ties). Your best friend often knows about the same openings you do. That product manager you worked with three years ago? They’re in a totally different ecosystem, hearing about opportunities you may be blind to.

Action: Set a recurring calendar reminder for every Friday morning. Spend 15 minutes sending three messages to people you haven’t spoken to in six months. LinkedIn or even (gasp!) your phone is a great place to source these connections. No asks. No "looking for work." Just:

"Saw your company shipped that new feature, looks slick."

"Hey it’s been awhile, I see you’re in a new role!"

"Saw this article on (blah blah blah) and thought of our convo at the conference."

When you eventually do need to make a move, you aren't a stranger asking for a favor; you're an active connection continuing a conversation.

Don't Neglect Your Current Building If you’re a Senior Fullstack Dev, do the jr frontend devs even know you? Do the PMs know you understand the business logic down to the resulting dollar, or do they just think of you as the person who fixes the API?

Cross-departmental reputation is your insurance policy. When layoffs happen, people who don't know you often decide them in spreadsheets. But when rehiring happens, or when a former colleague moves to a new company and needs a Tech Lead, they remember the dev who explained why the database migration was necessary in plain English, not the one who just grumbled about tech debt. Pay your insurance premiums by exposing your genius to more people you work with

Stop Shipping Invisible Code You don't need to be an influencer nor do you need to do TikTok dances. But these days, "proof of life" online goes a long way.

If a hiring manager Googles you, what do they find? A LinkedIn with a job title from 2019? Or do they find a trail of breadcrumbs that shows you are active, engaged, growing, building, opinionated about current tech matters in an informed way? You can

Comment on industry blogs.

Post a summary of a conference talk you watched.

Engage in GitHub discussions. (or even Twitter/Reddit/LinkedIn Groups/Slacks/Discords)

This is the passive networking that works while you sleep. The flipside is if you continue to build in silence, you’re likely to lose in silence as well.

Always Be Building (ABB)
The second pillar of resilience is Always Be Building (ABB). Pretty sure I stole this one from my friend, Danny Thompson.

There is a trap that senior developers fall into, let’s call it the architect’s armchair. You spend so much time in meetings, designing systems, and reviewing code that you simply stop writing code. Your muscles atrophy.

In a volatile market, companies are less willing to pay for pure theory. They want builders. They want people who can architect the solution and prototype the MVP. As I mentioned to a recent mentee “they just want to know you can build the darn thing”.

Learning vs. Building Tutorial hell is real, even for seniors. Watching a YouTube video on Agentic AI is not the same as building an agent.

Learning: "I watched a video on the new Spring Boot 3 features."

Building: "I migrated a legacy microservice to Spring Boot 3, documented the breaking changes, and measured startup time improvement."

The market pays for the latter.

Portfolio for Seniors ? While most senior devs would totally scoff at the idea of a portfolio, these are times where extra validation is no longer extra. The “3 to 5 projects of increasing complexity” may not be the right mantra, but it’s certainly worthwhile to have some project good enough to be a product working in the wings.

For instance, If your background is Java/JVM, you could build something that demonstrates resilience and scale.

A custom load balancer.

A simplified version of a Kafka topic.

A RAG (Retrieval-Augmented Generation) pipeline that integrates with a legacy SQL database.

If time is a constraint, open source issues are in the millions and allow meaningful contributions that don’t require you to steer the entire ship. These projects show you’re more than a coder, you’re an engineer who understands systems on an enterprise scale.

Sharpening the Saw Yes, Steven Covey’s 7th habit is still relevant and you can use ABB to diversify your risk. If your day job is 100% maintaining a legacy monolith, spend your nights on the cutting edge. What “they” won’t let you use at work is no excuse for stagnation in your growth with most every AI model and tool offering a free tier and fun fact, there are continual advancements in languages libraries, and frameworks that have nothing to do with AI at all - some of which are open source!

Sharpening your saw creates a hedge. If the market for legacy maintenance drops, your skills in modern cloud-native architecture are fresh. If the AI bubble bursts (not likely to fully happen), your foundational knowledge of data structures and algorithms keeps you employed.

Discernment – Hype vs. Harvest
Are you chasing digital pet rocks or diamonds in the rough? Determining this is often the hardest part. To be resilient, you gotta bet on the right horses, often. You have limited time to learn. Do you spend it learning Web3? The Metaverse? Generative AI? Rust?

One career-supportive skill is learning to differentiate between industry adoptions (Enterprise AI enablement is in this category) and passing trends (blockchain which according to Gartner never moves past POC 90% of the time).

The "Boring Problem" Test How do you tell the difference? Apply the boring problem test

Does the technology solve a boring, universal business problem better than the existing solution?

The Internet solved the boring problem of "sending documents."

Cloud Computing solved the boring problem of "buying servers."

Mobile solved the boring problem of "accessing data away from a desk."

A Tale of Two Techs: Blockchain vs. Agentic AI Let’s look at this diplomatically, without throwing shade, but looking at the data.

Blockchain is a fascinating technology. It created immense wealth and solved very specific problems regarding trustless verification. However, for the average Fortune 500 company (insurance, retail, healthcare), it required a complete paradigm shift. It required rewriting the way they thought about data ownership. Because the friction was high and the "boring problem" solution wasn't always clearer than a centralized database, adoption remained niche.

Agentic AI, on the other hand, is currently passing the Boring Problem Test with flying colors. It doesn't ask companies to rewrite their entire philosophy. It asks: "Do you have employees who spend 4 hours a day copying data from a PDF to Excel?"

Every company has that problem.

Agentic AI that can execute tasks, use tools, and make decisions is integrating into existing workflows. It fits into the API calls we already have. It reads the documents we already wrote. It summarizes, aggregates and even solves mathematical problems that are on current dockets, not theoretical ones.

The Play: Bet on the technologies that are infrastructure-level shifts. Agentic AI is looking like infrastructure. It’s the new database, the new electricity. Positioning yourself as a developer who knows how to orchestrate AI agents to solve business problems is a high-resilience move.

Don't Abandon the Classics Discernment also means knowing what doesn't change.

While everyone is chasing the new shiny object, the systems that run the world still run on the JVM, .NET, and C++ (NASA’s is known for strict rules on their abundant C code).

You can build resilience by being the person who can bridge the gap. The most valuable developer in 2026 isn't the one who only knows AI prompting (remember the almost career of prompt engineering), nor the one who only knows Java 21. It’s the developer who can say: "I can use a Java-based LangChain wrapper to safely integrate this new AI model into our existing secure banking infrastructure."

That’s the sweet spot. That is where the money resides.

The Unc Strategy for Career Moats
In medieval times, the moat was what kept the castle safe when the invaders came. In your career, your moat is what protects your salary when the market contracts. What’s your moat? Have you even thought about it? If not, now’s the perfect time.

Soft Skills are Actually Hard Something about the phrase “soft skills” is a tad deceptive. Some techies write them off as if they’re optional or easy. They are not.

In a world where AI can generate code, the value of generating code goes down. The value of determining what code to generate goes up.

Communication: Can you explain technical trade-offs to a non-technical VP?

Business Acumen: Do you understand how your code makes money?

Empathy: Can you mentor the juniors so the team doesn't burn out?

Anti-Slop: Do you follow some version of spec-driven development to avoid replacing slow clean code with a fast mess?

These are the skills that get you rehired. It’s not hard for recruiters to find a Senior Engineer who knows the syntax. It’s harder to find those who can lead the room. Be the latter and make sure that part of you is known.

The T-Shaped Developer (with a twist) You know the concept: Deep expertise in one area, broad knowledge in others. To increase your resilience, you’ll need to widen that horizontal bar. That means more study, personal study.

I was in a recent group chat where someone offered “why are we doing all this off the clock work, other industries don’t do all this”. While I didn’t answer in the moment, I will share with you: this gameplan I’m offering is not about what is fair. It’s about what works. If you can execute a strategy that is both effective and satisfies your personal barometer for fairness, I invite you to do that instead.

An example of expanding that T shape could look like this:

Deep: Your core stack (e.g., Java/Spring, Python/Django).

Broad: Cloud (AWS/Azure), DevOps (Docker/K8s), Data Engineering basics, and now, AI Orchestration.

You don't need to be an expert in all of them. But you must know enough to be dangerous. You need to know enough so that if your company pivots from on-prem to cloud, you aren't left behind. If they pivot to AI-driven features, you can raise your hand and say, "I can handle the backend for that." Even at the junior level, I’m encouraging more self-described front end devs to make sure they have some backend skills. Or as I put it on Twitter spaces, “can you make the app or not”. That’s the test.

Calm in the Storm
Market volatility is the tax we pay for working in the highest-leverage industry in the world. One that from its inception, has been defined by change (iteration), abstractions, and tradeoffs. With the high rewards come high variance.

If you’re feeling anxious right now, that is normal. I’m not describing a plan to remove anxiety. This is a plan where your feelings won’t matter one way nor the other. You’re covered.

Straightforward:

Treat your career as a business, not a job.

Always Be Connecting: Build relationships before you need them.

Always Be Building: Keep your hands dirty and your portfolio diverse.

Practice Discernment: Bet on infrastructure, not just hype.

When you execute this playbook, layoffs stop being a career-ending event and start being a mere inconvenience. I have experienced this, personally. You walk into the market not with a begging bowl, but with a toolbox that you know is in demand.

Stay building. Stay connecting. You got this.

Stop Shipping Invisible Code

Lawrence Lockhart — Sun, 04 Jan 2026 20:24:00 +0000

🪙 If I had a nickel for every time I saw or heard a brilliant developer building some masterpiece in total isolation, only to realize no one was outside waiting to use it, I’d probably be able to FIRE.

I do get it and won’t pretend like I don’t understand tunnel vision as a dev. You want to stay in the IDE and let the code speak for itself. But coming from my background I’ve learned a hard truth: If no one knows your product (or you) exist, it’s effectively a bug.

If that rubs you wrong, don't think about it like "selling." We’re debugging our business.

Marketing is Just Another Stack to Master

Technical people often resist marketing because it feels like fluff. Think of it this way instead: marketing is the API between your code and the user’s problem. In a book I recently finished, The Passionate Programmer, Chad Fowler talks about "Choosing Your Market." You wouldn't pick a tech stack based on a coin flip; you pick it based on the requirements. Marketing works the same way. If you can’t define the market you’re coding for, you aren’t building a product, you’re indulging in a hobby and there’s nothing wrong with that. To be a founder, you have to master the communication stack just like you mastered Java or React.

Say It, Do It, Show It

It’s so easy to get sucked into feature creep mode thinking one more PR will finally make people buy your thing. Fowler’s rule for career advancement is the perfect fix for this:

Say It: Announce what you’re building before it’s finished.
Do It: Build that MVP.
Show It: If you aren’t showing it, you haven’t finished the job.

Aim for a 50/50 split. If you’re not working a 9-5, try spending 4 hours coding, and 4 hours on distribution. Continually refactoring an invisible product is the hamster-in-the-wheel activity you’d do well to avoid.

Documentation is Your Secret Weapon

Yes, we’re devs and we avoid all that salesy nonsense like the plague. But you know what we love? Great documentation.

Fowler emphasizes the value of being a teacher. When you write a "How-To" guide or a killer README that solves a specific technical hurdle, you’re doing inbound marketing. By solving a user’s problem for free, you earn the right to ask for their attention on your paid product. In the DevRel world, we call this "teaching to lead."

The "Passionate Founder" System Audit

Treat this checklist like your marketing test suite. If these tests don't pass, your business isn't ready to ship.

[] Identify the Pain Point Variable: Can you describe the problem you solve in one sentence without using jargon? If you can't explain it to a non-dev, you haven't simplified the logic enough.
[] Find the Watering Hole: Where do your users hang out? (Reddit, Discord, Product Hunt, Startup Grind and other niche forums). If you aren't in the conversation, you aren't in the market.
[] The 30-Second "Show It": Do you have a video or a demo playground? Users should see the value immediately without having to create an account.
[] The "Consultative" Pitch: Are you asking for a sale or for advice? Fowler’s rule: Ask for advice, and you’ll get a customer; ask for a customer, and you’ll get ignored.
[] The Five-User "Debug": Have you watched five strangers try to use your product while they think out loud? This is the ultimate way to find bugs that are killing your business.

How to Structure Blogs Tweets and Videos

Target Audience: The people currently Googling the problem your SaaS solves.

The "I’ve Been There" Hook

The Goal: Empathy.
My Tip: Start with a specific error message or a facepalm moment you had while building.
Drafting Prompt: "If you’re trying to [achieve X] in [Tech Stack], you’ve probably run into [Error/Frustration]. I spent four hours banging my head against the wall on this, so you don't have to."

The "Hard Way"

The Goal: Establish authority by showing you understand the underlying logic.
The Content: Provide the actual code, script, or configuration steps to solve the problem without your SaaS.
Why this works: It proves you aren't just selling a black box. You’re providing value upfront.

The "Why This Scale Is Broken"

The Goal: Introduce the Pain of Maintenance.
My Tip: Use a food or kitchen analogy. "Doing this once is like making a sandwich. Doing this for 1,000 users is like trying to run a commercial kitchen with a toaster."
Drafting Prompt: "This works for a side project. But once you hit [Scaling Milestone], you start dealing with [Security/Performance/Technical Debt] issues."

The "Better Way"

The Goal: Position your product as the logical evolution of the manual fix.
The Content: "This is exactly why I built [Product Name]. It automates the [Step 1] and [Step 2] we just talked about so you can get back to building your actual app."

The "Soft CTA" (Call to Action)

The Goal: Low friction.
Drafting Prompt: "I’ve put together a [Free Cheat Sheet/Utility Script/Guide] that handles this. Grab it here, or try the [Product Name] sandbox to see it in action."

How to Distribute This

Once you’re written it up, you can't just hit publish and hope. Follow some sort of distribution strategy (stack):

Snippet to Social: Take the "Hard Way" code snippet and post it to X/Twitter or LinkedIn with a "Lesson Learned" caption.
The "Rubber Duck" Comment: Find a Stack Overflow or Reddit thread asking about this specific problem. Don't post the link to the SaaS; post the link to the educational guide.
The Newsletter Hook: Share the "Facepalm" story with your email list to build that personal connection.

It’s a roller coaster moving from a builder to a founder. I experienced this with just a few freelance clients and have watched the highs and lows in numerous builders through the years. It takes a shift in mindset, but you’ve already got the logical tools to do it. Instead of hiding behind your IDE, treat your marketing with the same rigor you apply to your codebase, and you’ll stop asking how to get attention and start wondering how to scale it.

Keep building, keep sharing, and I’ll see you in the trenches!

Positioning Strategy for Infrastructure Roles in Reference to America's AI Action Plan

Lawrence Lockhart — Thu, 24 Jul 2025 10:25:50 +0000

Listen, if you are an infrastructure engineer right now, the game just changed. The recently released "America's AI Action Plan" isn't just a political memo; it’s a massive neon sign pointing to where the money and the jobs are going. Pillar II of that plan is explicitly focused on "Building American AI Infrastructure"—meaning they are bypassing red tape to build massive data centers that require over 100 megawatts of power.

We aren't just racking generic servers anymore. We are building purpose-built "AI Factories" at a national scale. Here is how you position yourself so you aren't left behind.

The "Why": Training vs. Inference
The old "data center" was a generic warehouse. The new AI Factory is a specialized engine designed to handle two massive, distinct workloads:

Training: This is the heavy lifting. This is ingesting oceans of data and keeping thousands of GPUs burning hot for months to build a foundation model. It’s an infrastructure marathon.

Inference: This is the delivery. This is taking that trained model and serving it to millions of users in real-time without the system falling over. It’s an infrastructure sprint.

If you know how to architect for both, you are bulletproof.

Master the "Big Three" (The New Baseline) Knowing how to spin up a VM in the console doesn't cut it anymore. You need deep, hands-on expertise in the trifecta of modern infrastructure.

Deep Cloud Expertise: You need to speak the native language of AWS, GCP, or Azure. Understand the trade-offs in storage (block vs. object) and get your hands dirty with their specific managed AI services (like SageMaker or Vertex AI).

Infrastructure as Code (IaC): When you're dealing with hundreds of millions of dollars in compute, you don't configure things by clicking a mouse. You use Terraform. If it isn't defined programmatically, it doesn't exist.

GPU Orchestration (K8s): Docker is the baseline, but Kubernetes is the brain. You need to know how to wrangle pods, services, and stateful sets. More importantly, you need to know how to schedule and manage GPU resources within a cluster using tools like the NVIDIA Operator.

Specialize in Distributed Systems At the scale of an AI Action Plan "Qualifying Project," individual servers will fail. Racks will go dark. Your problems are now distributed systems problems.

Resilience: Design for failure. You need to understand consensus algorithms, leader election, and automated self-healing so the system survives when a zone drops.

High-Performance Networking: In massive AI training runs, the network is almost always the bottleneck. You need to understand Software-Defined Networking (SDN) and interconnects like RDMA that let GPUs talk directly to each other, bypassing the CPU entirely.

Data & Storage: Get familiar with distributed object storage (like S3) and highly scalable databases. More importantly, learn Vector Databases (like Pinecone or Milvus). They are the absolute backbone of the Retrieval-Augmented Generation (RAG) workflows powering modern AI apps.

Adopt the "Operator" Mindset Chad Fowler was right: you have to be a passionate programmer. But in infrastructure, you also have to be a ruthless operator.

Own the System: Your job doesn't end when the code is deployed. You own the performance, the reliability, and the AWS bill in production.

Chase the 1%: At FedEx, I learned that a 1% optimization at scale saves millions of dollars. At the scale of an AI Factory, finding efficiencies in your workload is the default expectation.

Automate Everything: If you do it twice, script it. It is the only way to manage the sheer volume of infrastructure coming down the pipeline.

By mastering the core tools, specializing in distributed design, and thinking like an operator, you aren't just prepping for a job. You are laying the bricks for the next generation of computing. Go build it.

Artisan Post

Lawrence Lockhart — Thu, 10 Jul 2025 06:37:06 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

Artisan Post is a web application that uses Gemini to generate unique, vintage-inspired travel and event posters based on keywords. By selecting a classic art style, the user can instantly create beautiful, shareable artwork with a description.

Demo

https://aistudio.google.com/app/prompts?state=%7B%22ids%22:%5B%221AYKcev8AKc7Khs6iow645_gUShzceZtw%22%5D,%22action%22:%22open%22,%22userId%22:%22112313500574094301041%22,%22resourceKeys%22:%7B%7D%7D&usp=sharing

My Experience

This process was straightforward and a positive learning experience. The blog post was easy to follow so I did the example then did my own. This pairs well with my recent learning with the "Gen AI Leader" certification from Google.

RenderATL 2025: A Week of Good Feelings

Lawrence Lockhart — Mon, 23 Jun 2025 17:08:00 +0000

While researching various traits of undiagnosed but likely spectrum-dwellers like myself, I encountered a phrase which captures some of my response-mechanisms in terms of productivity: "... just out here chasing the dopamine". While that's not entirely scientific and likely not the best strategy for completion of time-based tasks, I can express a similar sentiment in positive-terms each time I'm a part of RenderATL.

RenderATL is a 3 day tech conference founded by Justin Samuels and located in the heart of downtown Atlanta, Georgia. It's tied to and overlaps Atlanta Tech Week, a series of over 100 tech and tech-related events occuring throughout the city. It also features multiple overlapping after hours activations - mixers, networking events, and parties including the now-famous "Render Roof". With the conference itself featuring some of the most brilliant minds across the technology landscape, for a first timer it can honestly be a bit overwhelming which is why I tweet, make videos, and even spoke via podcast interview on tips to navigating such a packed week of activity.

For a 4th-time attendee like myself, again, all week I'm just chasing the good feelings one after another. Typically, those good times parse themselves out in 4 general umbrellas - learning new tech, meeting new people, connecting with friends, and just having pure unadulterated fun. If I gain a new insight into how a Beta MCP Server project can be architected by day, you can believe I'll be two-stepping to Amapiano by nightfall. Having lunch with my Tech Twitter bestie? Check! Making a new LinkedIn connection after an inspiring talk by a fellow DevRel in the code and design space? Also Check! Because my week is intentionally scheduled to foster these occurrences, my Render week this year was a win just as it always is.

One may muse "Lawrence you're like a walking Render commercial - you probably couldn't be objectively critical if you tried". Oh contraire! As much work as I could tell went into the Render mobile app, it was honestly still easier for me to view my agenda on my trusty Google Sheet I update each year. The whole water bottle fiasco of 2023 is hilarious in hindsight but in the moment, more than a bit frustrating. I have to mention the lunch buffet lines in 2022 (yes there used to be food 😎) were slow-moving and people kept breaking line. When possible, I take these negatives or "lemons" and do what I can to make lemonade. Take the buffet line issue for example. I used that extra time waiting in line to introduce myself and begin conversing with people who were waiting in line with me. One thing led to another and I ended up driving the four of us to lunch at a downtown food court. The next thing you know, Portia Kibble Smith who was in our little group, had me being interviewed by the Karat/Brilliant Black Minds crew. Some weeks and conversations later, I find myself selected to be a Brilliant Black Minds Ambassador, a role I still serve in today.

Speaking of Brilliant Black Minds, it's Senior Advisor, Anthony Mays is one of those big brothers in tech I look forward to speaking with every year. I've gleened so much wisdom via his lived example as a saved black man thriving in the tech landscape. Sometimes this wisdom is gained from afar, in an interview he's on or just an insightful tweet. I've since been able to consult with him 1:1 to strategize my own career moves and even speak on stage with him in 2023 in an enlightening panel discussion. The common denominator here is Render.

It's tech classroom meets southern black family reunion. It's one part career fair, one part soca fete'. As an ambassador I was blessed to bring my wife last year, and as a Community Partner leader bring my sister this year. I share unabashedly I'm a fan through and through and would love every person in or adjacent to tech to get to enjoy just some of what I experience on a regular annual basis. You'll find a few pics below from events mentioned above but mostly capturing me chasing those good feelings.

|

|
|

| |
|

|

|

|
| | | |

|
|

|

|

|

My First Year as a Developer Advocate with Vaadin

Lawrence Lockhart — Fri, 20 Sep 2024 11:37:00 +0000

Wow! That's the most succinct summary I can give about my first year as a Developer Advocate with Vaadin. It truly has been an educational, exhilarating roller coaster, and I’d like to share a few highlights with you.

What is a Developer Advocate?

For those unfamiliar with the term, Developer Advocacy (sometimes called DevRel) is about bridging the gap between developers and the technologies they use. As a Developer Advocate , my focus shifted from solely building products as a developer, to understanding how they're received and used by the community. The role involves a lot of knowledge-sharing, community engagement, and helping developers succeed.

My Journey So Far:

I transitioned into tech a little over six years ago after a 2 decade career in hospitality and supply chain management roles. I’ve always loved helping people win and that love eventually led me to Vaadin, where I get to share the latest solutions to app development challenges with Java developers. Over the past year, I've connected with countless developers, contributed to the Vaadin community, and learned a ton along the way.

One thing that both pleased and surprised me was the level of engineering talent on our team and in the company in general. These people are skilled! Whereas I’ve heard tales of DevRels “losing their touch” and perhaps not coding as much as a traditional SWE, Vaadin DevRels are builders in the craft who often are producing impressive demos with the latest technologies as well as making meaningful contributions in our open-source software. The technical level of communication in the company Slack amongst our product and engineering teams is a classroom for engineering architecture and I’ve seen my understanding of technical decision making increase more as a devrel than in my prior developer role. That’s truly been an unexpected level-up.

The Values

Vaadin's core values - "Choose the Herd," "Own the Solution," and "Dare to Explore", mostly made sense to me from day one. Interestingly, while I was accustomed to being a team-first player and taking initiative, the “Dare to Explore” challenged me to adjust my prior rigid boundaries regarding what I should or should not try in a corporate setting. I remember laughing at my boss’s reaction in one of my first weeks as I asked about installing social media on my company-issued phone. His “of course” was slightly humorous, slightly incredulous as if to say “how else are you going to do your job?” Since then I’ve been doing lots of “exploring” and have felt encouraged pushing boundaries and seeking better ways to do things even down to embracing more of my own personality into our corporate social media posts.

The Vaadin Way

Coming from a different tech background, I had to learn "The Vaadin Way" of building applications. Vaadin's fullstack build philosophy, which prioritizes integration between frontend and backend development using Java challenges traditional silo team and architecture paradigms and my additional challenge in that regard has been in building those applications from scratch. It was somewhat startling having it illuminated to me that in years of prior professional programming, I had seldom taken a project from ideation to prod. My most frequent tasks had typically been maintenance, updating, and refactoring. Now I needed to build out small but complete programmatic solutions to be used in blogs, videos, and conferences. Fortunately, again relying on the team's strength, I’ve received guidance and feedback along the way to turn that weakness into a strength.

A Few Milestones

A key milestone for me was standing in for my manager at the Connect Tech Conference in October 2023. As he was double-booked that week, he appeared and spoke at the Vaadin Create Conference in Germany while I presented what was originally his talk in Atlanta. The interesting thing here is that the talk was an artificial intelligence-focused one leveraging Spring AI and LangChain4J, two technologies I had zero familiarity with. That was nerve-wracking! My first talk for the company and first opportunity I had to make an impression on the larger developer community on behalf of Vaadin, was on a set of subject matters I did not know well at all. Somehow, I killed it. The talk went over well despite projector and microphone challenges and I obtained great feedback at the end from representatives of Google, and the Spring team who were in attendance.

Since that time, I’ve enjoyed numerous talks and podcast appearances. Just a few of those include speaking at the St. Louis and Houston Java User Groups, speaking at the Dallas Software Developers meetup, and appearing on podcasts with Gun.IO, Chris Sean, and livestreams with Dan Vega and DaShaun Carter. I’ve come to understand these appearances are their own form of content and often fun, creative ways to get out the company message above and beyond the traditional trifecta of blogs, videos, and public talks.

Ever-present AI

I was fortunate to attend my first Google IO conference this year at the headquarters in Mountain View and can certainly share “I drank the Kool-Aid”. I subsequently built projects that integrated Vertex AI/Gemini 1.5 on a Vaadin Flow application and used that in a company YouTube video as well as a talk at the Black Is Tech conference. When I’m not building with AI, I’m building with AI. Meaning, I’m often leaning on chatbots for summarizing and ideation. Think of it like a rubber ducky that talks back. When I want to quickly get the gist of more text than I’m willing to read in full at the time or perhaps am having writer’s block, I keep Gemini Advanced in one tab almost at all times for those purposes. I haven’t utilized it nearly as much for code generation as one mentor once put it “LLM chatbots for code are like relying on an overeager junior dev”. It’ll quickly give you an answer but you better check thrice. All-in-all, I’ve found artificial intelligence to be super-helpful to build on and build with.

Challenges

An additional aha moment in my transition to becoming a good Developer Advocate is managing the context switch. As a software developer for FedEx, in any given two-week sprint, I could expect to have a defined number of stories and tasks which were understood to be completed at the end of that two week sequence and followed by additional stories and tasks assigned for the subsequent two. I never considered how that rigorous regular cadence was in fact mind-numbing. Coming into devrel is like having your eyes opened for the first time. Our tasks don’t often fit in time boxes structured to that degree. At any given time, there may be social engagement needed for a day, content to be produced for a week, slides and talks to be worked on for weeks from now, and CFPs to be written for conferences months down the road.

That difference was something of a blocker for me in my initial months in the role. Again, after speaking and ideating with my manager and experimenting with popular time and task management tools, I relied on my absolute favorite mode of organization system: analog. I now have a giant whiteboard in my home office and have organized it by columns to display what is to be done today, this week, and long term. A quick 5-minute read orients my thinking to just where my progress is at any given time. As days progress, long term entries move to “this week” and this week entries move to “today” to keep me on track. I additionally maintain columns for upcoming events and topics I’d like to learn to keep those categories of items front of mind as well.

Connections

As a person who traditionally is both introverted and a bit shy, I’ve been more than pleased to realize in real time just how much I enjoy connecting with other developers. As a devrel, I’ve witnessed first-hand why many proclaim the best track in any conference is the hallway track. This is referring to those non-scheduled interactions of chatting with super-talented engineers, architects, and everyone from luminaries in the field, to collegiate aspirants. These chats give opportunity to really learn how similar so many of us are and how small the world is. These chats have helped so much in learning who the people behind the tech are which is truly the most important thing. An additional tangible benefit is meeting people in this way has a tendency to open doors to additional opportunities. For instance, the combined effect of “putting myself out there” in conference after-hours and heavily on social media resulted in multiple people submitting my name as one to attend the Web Dev Challenge, a reality-show styled YouTube video series produced by Jason Lengstorf. I was happy to accept and participate in filming that challenge introducing me to yet more awesome devs to collaborate with while showing off the Flow framework from Vaadin.

Looking Forward

My first year at Vaadin has been an incredible journey of growth, learning, and community engagement. I'm grateful for the opportunity and the support I've received and look forward to leveraging feedback from my annual review to produce even higher quality content in the future, and be a more consistent voice of the “developer in the field” back to our product and engineering teams. If you're a Java developer looking for a powerful and rather intuitive platform to build modern web applications, I highly recommend checking out Vaadin. And if you happen to be at the All Things Open Conference in 2024 where I’m speaking, please come say hello! I'd love to connect with you and hear about your experiences.

Thank you for joining me on this journey! Here's to another year of growth and innovation with Vaadin!

Surviving the Coming AI Shift

Lawrence Lockhart — Tue, 19 Mar 2024 16:08:00 +0000

Many conversations in developer communities currently (Spring 2024) center on some product enhanced by artificial intelligence taking the jobs of humans employed as software engineers. Despite the dystopian imagery this may invoke of automation replacing humans, it’s more accurately an assessment that companies en masse will decide the most strategic decision they can make to produce production software is to rely on other software rather than humans. However you envision it, here’s a few scenarios of highly likely futures involving humans and artificial intelligence. Perhaps you’ll find a scenario that you can position yourself in.

The first scenario is non-integration. In the near future, people who do not consciously use artificial intelligence in any way will be the then equivalent of living in a digital desert now or being completely computer illiterate. Having seen robots serving drinks, delivering food, and cleaning bathrooms, it’s clear no job role will be exempt from some influence of AI and automation. Having worked in hospitality myself for 17 years, if I were still in that space, I’d consider

Job changes where possible

Learning how to use some of these AI tools

At the bare minimum, beginning to use AI assisted tools to enhance non-work aspects of my life to and honestly, just keep up with a rapidly-advancing society.

The second scenario is what I’m calling the user. While devs are watching the direction firms like OpenAI and others are taking with product development, enterprises are observing as well. In that observation, these companies are evaluating from the perspectives of efficiency, speed, and profit. It’s not unreasonable to anticipate that the expectations around how long processes should take will be exponentially faster than those of today. Accordingly, the amount of “work” that the worker is expected to produce will be dramatically increased as well. I’m saying any and every rank-and-file 9-to-5 employee employed in a role that combines mental skills and computer execution will have to begin using AI to facilitate that level of expected velocity in the foreseeable future. At a minimum, all office workers will utilize some form of prompting to get faster answers, faster execution and more units of completed work.

The third scenario is what I call an AI explorer. The AI explorer is the developer who sees the writing on the wall and chooses to “join em rather than beat em”. The AI explorer digs deep enough into understanding AI to facilitate them being able to shape technology without necessarily re-inventing the wheel or tackling writing artificial intelligent systems from scratch. They are the early adopters of AI technologies, experimenting with and implementing AI in their projects, contributing to open-source AI projects, or even starting their own ventures based on AI advancements. APIs made available from firms like OpenAI and others give developers the power to make unintelligent systems “smart” through use of that enhancement. In the example that follows by Marcus Hellberg, VP of DevRel at Vaadin, he demonstrates using langchain4j to take a reservation system, give it access to select data and integrate that with AI to automate certain customer interactions and functionality. Embracing AI in this way positions developers in a way that makes them more productive and potentially increases their career longevity. (Video here)

The final scenario in this context of humans, AI, and the future of work is the AI engineer.

AI engineers are the ones building the backbone of what will likely be our future's most groundbreaking advancements. They can be found leveraging machine learning algorithms to solve real-world challenges, they’re instrumental in developing autonomous systems for self-driving cars, and certainly they’re the minds behind large language models (LLMs) like GPT, a family of AI models that has garnered tons of attention recently. AI engineers can be found applying their skills to enhance medical diagnostics, improve climate change models, and optimize supply chain logistics. If there is a pseudo-safe programming role, AI engineers are most likely it.

A shift is coming and impact will accompany it. For most scenarios, there are means of making that impact a positive one, rather than adverse.

On Motivation

Lawrence Lockhart — Wed, 16 Aug 2023 07:27:00 +0000

For every new dev that has asked me for assistance with motivation, I reflexively counter with "it would be better to work on your discipline. Discipline flows where motivations slows". The bonus point here is that what sometimes appears to be discipline is actually well-ingrained habits.

It's generally accepted that an activity you engage in consistently can reasonably become a hyabit somewhere between the 60 and 90 day mark. That is a fantastically short amount of time. Psychology gives us the 21/90 rule of taking 21 days to make a habit, 90 days to make it solid, still within the timeframe. you could begin a practice of reading 1 hour per day everyday starting tonight (8/15) and regardless of how challenging the "start" may be, before Thanksgiving you'll be a regular reader without even thinking about it.

This reminds me of the nature v nurture argument. My take being that regardless of nature, our bodies and more importantly our neural processes are typically flexible enough to adapt to a much wider variety of change than we give ourselves credit for. Growth mindset isn't a Polyanna-ish take on the human condition. Growth mindset is a reflection of our ability through sheer will to grow new capabilities over time. The start of that process is expected to be difficult as those neurons begin firing in ways they haven' before. But over time, what was just a singla yesterday becomes a synaptic connection today.

All to say motivation is great. Discipline is better. Habit is the secret sauce of long-term achievement.

DevRel: Do Titles Matter?

Lawrence Lockhart — Mon, 26 Jun 2023 10:28:00 +0000

As a SWE with DevRel tendencies, I’ve been reading commentary for the last couple of days regarding what qualifies one to be a developer advocate. Seeing some of my “mentors from afar” weigh in with sometimes contrasting views caused me to reconsider my thoughts on developer advocacy.

It’s difficult to arrive at a consensus on who classifies as a certain role if there is no common understanding on the meaning of the terms. As an outsider looking in, it appears a standardization of nomenclature across the industry just as we find in the more technical aspects of any scientific discipline would be helpful.If there was a DevRel congress to agree on the meaning and usage of terms, my simple (hopefully not oversimplified) proposal would be this:

Developer Relations is that department, org, or team charged with ensuring developers internal and/or external are exposed to those products and services that most closely align to their pain points and needs for more efficient and effective solutions. Onto that prefix one can add a variety of specific role titles as appropriate per the size of the team, needs of the company, and pending which department the Developer Relations group reports to. Some roles could include Developer Relations Engineer, Developer Relations Community Manager, Developer Relations Logistics Specialist, Developer Relations Technical Writer, and many more. Often, teams will only have 1-2 roles with team members wearing multiple hats due to their smaller size while more robust teams may have all roles filled. In this specific structure, everyone on the team can refer to themselves as an advocate in general conversation while referring to their specific title for more professional purposes.

Learning as a Self-taught Developer

Lawrence Lockhart — Thu, 22 Jun 2023 11:17:00 +0000

One piece of advice I'd like to offer self-taught devs is to practice regularly and continuously challenge yourself with coding exercises and projects. The cadence I typically suggest is a minimum of one hour per day for a minimum five days per week. . By consistently dedicating time to coding, you'll reinforce what you have learned, improve your problem-solving abilities, and become more comfortable with different programming concepts. If you set aside specific time slots in your schedule for coding practice and stick to them, you can train yourself to "get in the zone" when it comes to your personal learning.

Additionally, challenging yourself with coding exercises and projects is crucial for growth. Seek out exercises or coding challenges that push your limits and require you to think critically. Build small and larger projects that allow you to apply what you have learned in a practical way, as this will deepen your understanding and help you gain hands-on experience.

When faced with choices about which coding exercises or projects to pursue, it's important to make decisions based on your personal interests and goals. Consider what areas of software development excite you the most and/or align with your long-term career aspirations. When you build projects that you are passionate about, you will be more motivated to put in the necessary effort and fully engage in the learning process. You will likely be considerably more passionate in your description of these projects than something pulled from a course or tutorial.

Remember to approach learning as a self-taught software developer with patience and perseverance. It may take longer than you expected to grasp certain concepts or complete complex projects, but don't get discouraged. Seek out resources such as online tutorials, forums, and communities where you can ask questions, learn from others, and gain support. Remember, your learning and growth is a highly personal endeavor so the rate someone else progresses should never be a deterrent. We call it "a race of one" for a reason. Happy learning!

coding #programming #softwaredevelopment #learning

Getting In To Tech As An Older Adult, Some Of My Story, And A Gamplan For You

Lawrence Lockhart — Sun, 03 Jan 2021 11:15:00 +0000

The following is an anonymized redacted version of a conversation I had with a fellow developer who's on a learning path and struggling to land that first position. After typing it all out, I thought it would be useful to others in a similar vein so here we go.

I have so many great things to share with you and I want to set some context first. I'm a mid-life career transition person. My first jr tech role I was 46 yo. My wife is 48 and is starting her tech journey now. I know and worked with plenty of people who have done what you're trying to do so I know it's possible. More importantly, I've condensed the factors down to a convenient list that I'm going to share with you. Real important to remember I'm going to give you my best advice based on experience and what I've seen work for so many others. What you choose to do with this information is obviously totally your choice. I've been down this road with people and after I share the game plan some go all in and get the job, others say "ok thanks this is great" then they never follow up and months later they're still not in tech. It's about the effort.

 So, you have to make the decision now is this something you want or not. Regardless of prior failures, ghosted interviews or other issues, 100% in or 100% out are the only options. If you're 100% in, I got you. Follow these steps and you'll be employed within a year. You know, I spent  months sleeping in my car in the back of a restaurant when I was divorced, out of money, lost a good job and too embarrassed to go back to my parents. It was winter and I would leave the car heater on until I got really sleepy then turn it off and try to fall asleep fast because it's hard to sleep when you're cold. I set my alarm for 1/2 hour before the opening restaurant folks showed to work so no one would know. I'd go to late night movies and just crash in an empty theater room for...a bit too long. I considered a shelter until a coworker told me about them letting people with mental faculty issues in who used the bathroom on themselves and you would just have to lay there beside them. So I couldn't do the shelter.  That my friend is HOMELESS. Sleeping in the back of your car hoping the police don't come knocking and arrest you for trespassing - been there, done that.  Now, here we go.

 My specialty with all this is people like me, older adults, adults with family and kids, adults coming from different industries with no CS degree - that's my situation and what I know well so if that's you too, I can help.  As far as learning resources, I've done Udacity's  Front End Nanodegree, 3 Udemy courses front to back, an additional 3-4 Udemy courses partially, lots of work on freecodecamp, codecademy, and w3schools. I've completed multiple courses on codingphase.com which I highly recommend.  The point is it takes a lot. For us who aren't a 22 year old UC Berkley grad with 3 top tech internships on our resume, it takes a lot. We can't do the minimum, we \*have\* to do the maximum to receive consideration. At the end of the day, we're out here trying to convince an employer "hey, your bet on middle-age me is just as good if not BETTER bet than the top CS grads to come out of Georgia Tech. No slight on Georgia Tech, my sister is an alum ;-).

 Regarding application numbers, my first go round at getting in to tech, I applied to at least 100 jobs and just stopped counting after awhile when it seemed like nothing was going to come through for me.  The second time around I applied to over 60 positions and only got 3 interviews out of it. The position I eventually landed was gained in part through networking which is something I used to look down on. Then at a tech meetup with https://codeconnector.io, we had a panel of some of the best software engineers in all of Memphis. They were asked a question about jobs and networking and I kid you not, 100% of them said they got their first or a subsequent job through networking. Some of these included traditional CS grad folks. Right or wrong, the deciding factor is still often who you know. NOT ALL THE TIME! But it's a factor that can help.

 One of my favorite tech youtubers released a video on getting in tech right at the beginning of 2020 that you should totally watch. He's Joe Santos Garcia and runs codingphase.com  He's self-taught, laid-back dominican bro from around the block, literally. He also made over $1/2 million last year working for himself so don't let the accent or casual swag make you miss the points that will get you hired. He's a good channel to follow and his courses are on time.  [https://youtu.be/KV1HWEvcniU](https://youtu.be/KV1HWEvcniU)

 There is a website called roadmaps that specs out good things to know for a variety of programming careers. They have one for frontend, android, devops, and more I'd like you to  check out. What they say is you don't have to know all of the things, but here is the landscape of expectations that you can use and guide yourself appropriately. [https://roadmap.sh/](https://roadmap.sh/)

 The next two links I'm going to share are critical. It's a spreadsheet checklist for getting your first job in tech as a career transition person.  This is my gameplan. That's it.  Read this post twice, take notes of the action parts. Go hard on your learning. Watch the video when you first open the spreadsheet or it wont' make much sense, even worse, you'll assign wrong meaning to it. Naturally, I'm here to help you along the way, it's what I do.

The spreadsheet: Tech Checklist

The video to watch with it: Video to accompany tech checklist

I wish you well!!