Modern AI assistants face the same limitations. They become significantly less effective when a codebase grows too large to fit into a context window. This forces a reliance on powerful remote servers or complex tooling just to reason about the logic, often missing crucial details in the process.

What if you could just ask your codebase what you’re looking for?

Introducing CodeIntensor

CodeIntensor is a local, semantic code search tool that understands what your code does, not just what it’s called. It builds a vector index of your entire codebase—including your dependencies—and lets you search using natural language.

The best part? Everything runs locally. No code leaves your machine, no API keys required.

Get Started in 60 Seconds

pip3 install git+https://github.com/em-wilson/codeintensor.git

# Initialize in your project
cd your-project
codeintensor init

# Build the index
codeintensor index

That’s it. CodeIntensor will chunk your code semantically (detecting functions, classes, and logical blocks), generate embeddings, and store everything in a local SQLite database.

Search Like You Think

Now the fun part. Instead of guessing keywords, just describe what you’re looking for:

$ codeintensor search "handle failed payment retry logic"

[1] src/billing/payments.py (lines 145-189)
    Score: 0.8432
    function: process_payment_with_retry
    Language: python
    Source: user

[2] src/billing/webhooks.py (lines 67-94)
    Score: 0.7651
    function: handle_payment_failure
    Language: python
    Source: user

[3] node_modules/stripe/lib/retry.js (lines 12-58)
    Score: 0.5765
    function: retryRequest
    Language: javascript
    Source: vendor (stripe)

Notice that third result? CodeIntensor indexes your dependencies too, with source type tagging. Your code scores higher by default, but you can see how libraries solve similar problems—incredibly useful when debugging integrations or learning new packages.

Filter When You Need To

Sometimes you want precision:

# Just your code
codeintensor search "database connection" --source user

# How does SQLAlchemy handle it?
codeintensor search "connection pooling" --source vendor --package sqlalchemy

# Only Python files
codeintensor search "async handler" --language python

Built for AI Workflows

CodeIntensor shines when paired with AI coding assistants. Add an agent integration with one command:

codeintensor agents add claude

This creates a CLAUDE.md file that instructs Claude to search your codebase before suggesting changes. No more hallucinated function names or missed existing implementations.

Why Local Matters

Cloud-based code search tools are powerful, but they require uploading your code to external servers. For proprietary codebases, side projects you’re not ready to share, or just simple privacy preference—local-first is the answer.

CodeIntensor uses sentence-transformers for embeddings, runs entirely offline after initial model download, and stores everything in a .codeintensor folder you can gitignore or delete anytime.

What’s Next?

Give it a try:

pip3 install git+https://github.com/em-wilson/codeintensor.git
cd your-favorite-project
codeintensor init && codeintensor index
codeintensor search "the thing that's been bugging you"

You might be surprised what you find—or rediscover—in your own code.

CodeIntensor is open source and available on GitHub. Contributions welcome!

The Early Trenches: Code, Boundaries, and the Lone Wolf Mentality

My earliest posts from 2008 and 2009 show a developer focused on personal output and survival. This focus led to a fierce protectiveness of personal time, a natural reaction to the often-unending demands of project work. That relentless pace stemmed from working at smaller companies in a fast-moving industry, compounded by my personal drive to prove myself.

In 2008, I wrote about managing scope creep. The core message was simple: don’t let work consume you. This post came from a genuine desire to establish boundaries against the relentless push for “one more feature.” My work relationship at that stage felt largely defensive. It was about my time, my efforts, and avoiding exploitation. Personal well-being was vital, but it also highlighted an individualistic approach to navigating the professional world. The team seemed an amorphous entity imposing demands. The client was a force to be managed.

Shortly after, “Get Your Boss to Do What You Want” explored workplace dynamics, but still from a deeply individual perspective. The advice to “plant the seed” wasn’t about open collaboration or shared vision. Instead, it described a subtle, indirect tactic to exert influence upwards. The goal: getting my ideas adopted without direct confrontation. This showed an awareness of hierarchy and power structures. Still, the aim remained individual success or validation. The team, if it existed beyond my immediate manager, was not the central actor. I was the protagonist, trying to bend the system to my will, or at least to my good ideas.

Looking back, a lone wolf mentality defined this era, or maybe it was a highly effective individual contributor mindset. Solving the code itself was the primary problem. Managing my personal workload and navigating the immediate hierarchy came next. Human interaction served as a means to an end, not the core challenge. Today, I’d approach similar situations with open dialogue and transparent collaboration, focusing on shared goals rather than individual influence.

The Slow Thaw: Understanding the Other Side

As the years progressed, a subtle but significant shift emerged in my perspective. Less about individual friction with organizational processes, my thinking moved towards understanding the broader professional environment. This change became evident in my reflections on “The Interview Process”. I still gave advice, but it stemmed from observing both sides of the table. I understood interviews were a two-way street; the company also tried to win over candidates. The emphasis on authenticity and passion hinted at a growing appreciation for personality and fit, not just technical prowess. This was a crucial step: thinking about team building and the human elements that create a cohesive group, rather than just individual performance. It recognized that talent involved not just knowledge, but also who someone was and how they might integrate.

This period was a slow thaw, an increasing realization that software isn’t built in a vacuum. It’s built by people, for people. And to build good software, you need good people, working well together. The questions I was asking myself were no longer just “How do I do this better?” but “How do we do this better? And who are the right we?”

The Agile Awakening: People-First and the End of the “Agency Agile” Joke

My thinking about team dynamics clicked around the time I wrote about “12 Months of Agile” in 2019. By then, I had witnessed enough “Agency Agile”—a superficial process implemented without understanding its spirit—and grew disillusioned. My earlier jokes about it lost their humor; ignoring the human element had painful consequences. My understanding evolved past methodology, becoming a philosophy and marking a conscious, deliberate shift. The statement, “my job is less about writing code and mostly about figuring out what problems people are having,” was a revelation. This fundamentally changed how I viewed my role. I realized bottlenecks, miscommunications, and frustrations usually weren’t technical; they were human.

Embracing the Agile Manifesto’s core tenets—especially “Individuals and interactions over processes and tools”—transformed my understanding. I saw that creating a strong vision then getting out of their way defined effective leadership and team empowerment. This shifted my focus from subtle influence to active facilitation, clear communication, and trust. The team was no longer an obstacle or distant entity; it became the engine. Understanding its mechanics, its people, and its interactions became paramount. I viewed my role as an enabler, a problem-solver for people, not just for code.

Navigating the Future: AI as Collaborator, Communication as Superpower

Fast forward to 2025. My recent experience marks a mental shift in my people-first perspective, particularly as technology dramatically changes. I initially viewed AI as an “existential threat” to my career, a fear of being left behind, a sentiment I explored in my reflections on surrendering to AI masters. Yet, after a year of reflection and constant trial and error, it clicked: AI is a powerful tool. I’ve evolved from seeing it as merely an extension of my IDE into something I can run multiple instances of, performing many tasks simultaneously. This extends my evolved thinking about teams. Collaboration is no longer just human-to-human; it now encompasses human-tool interaction. I realized AI demands precise communication, structured intent, and clear articulation of underlying “values”—a powerful metaphor for managing human teams. If I cannot clearly articulate expectations to an LLM, how can I expect a human team member to intuitively understand them? AI has become a tool forcing me to be a better communicator, a better leader of thought, even if the “team member” is a silicon brain. This shift also heavily influenced my observations about the tech job market today.

The job market for software engineers reflects an industry in flux. The solutions presented aren’t just technical skills; they demand architects, decision-makers, mentors for other developers, and those who bridge technical and business requirements. These are deeply human, collaborative, and leadership-oriented skills. The market now rewards strategic thinking, the ability to orchestrate efforts, and the capacity to solve problems AI cannot yet solve—problems often residing in the messy, nuanced realm of human needs, business context, and complex team dynamics.

The Unfolding Path: Always Getting Better Together

My career trajectory, viewed through this blog, marks a journey from individual focus to collective impact. It shifted from asking “How can I protect myself from the demands of work?” to “How can we—a cohesive unit of humans—best navigate challenges, create value, and continuously improve?”

The core philosophy of this blog remained constant. Its application broadened exponentially. I moved beyond just improving my code. Now, it’s about improving communication, team processes, leadership, and the collective intelligence of the systems and people I interact with.

The software engineering field is, at its heart, a problem-solving endeavor. I’ve learned that the most interesting, challenging, and rewarding problems don’t reside solely in elegant algorithms or robust architectures. They exist in the intricate, unpredictable, endlessly fascinating world of human beings working together. In 2025, with AI woven into our work’s fabric, leading, collaborating, and communicating effectively has never been more critical. It is also more personally fulfilling to continually refine. It seems the journey to “Always Get Better” always led me to understand that the greatest accomplishment lies in building not just great software, but great teams.

I was caught up in the layoffs that hit the industry in early 2024 and it took almost 3 months to find a new role. I’ve been a software engineer for more decades than I care to admit and I have never experienced such a tough search - interviewing was a full time job and hundreds of applications went totally ignored. It was a scary lesson that things have changed, not for the better, maybe permanently.

What’s actually happening out there? I spent some time digging through the data and talking to people across the industry to figure out the real story.

The Numbers Don’t Lie (But They’re Complicated)

Let’s start with what we know for sure: job postings for software developers have hit a five-year low, down more than 33% from 2020 levels. That sounds terrible until you remember that 2020-2022 was an absolutely bonkers hiring spree unlike anything the tech industry had ever seen.

Everyone seems to forget the period from 2020-2022 was one of the hottest tech jobs market in history. Companies were throwing money around like it was Monopoly cash, hiring anyone with a pulse who could spell “JavaScript”. During COVID, it was super cheap to borrow money, so investors had tons of cash to throw around, and everyone was building for a post-pandemic digital future that seemed to have unlimited upside.

Then reality hit. Interest rates went up to levels we hadn’t seen in 20 years. The money spigot turned off. Companies looked around and realized they’d hired way more people than they actually needed.

So yes, layoffs happened. About 95,000 workers at U.S. tech companies were cut in 2024. What the headlines don’t tell you: most of those cuts weren’t engineers. They were HR, communications, middle management, and other non-technical roles.

Meanwhile, software development roles are still projected to grow 17% from 2023 to 2033 – one of the fastest growth rates across all occupations. The Bureau of Labor Statistics isn’t exactly known for wild optimism.

Why Companies Are Getting Pickier

What we’re seeing isn’t the death of software engineering jobs. It’s the emergence of a skill premium.

Companies got burned by hiring too fast during the pandemic boom. Now they’re being much more selective. The days of getting hired based on a weekend coding bootcamp and a strong handshake are over. The market has fundamentally shifted from quantity to quality hiring.

Candidates are going through increasingly rigorous technical screens, multiple rounds of interviews, and lengthy decision processes. What used to take two weeks now takes two months – if you’re lucky.

But what we are seeing is the role of a software engineer is evolving. AI tools like GitHub Copilot can now write simple code, fix basic bugs, and create standard templates - stuff that used to take engineers hours. This means companies need fewer people to write code, but they desperately need more people who can architect systems, make technical decisions, and guide AI tools toward the right solutions.

This has created a weird paradox: job seekers are finding it harder to get responses (as I lived firsthand), while hiring managers find it takes longer to fill positions than ever before. Companies would rather leave seats empty than hire someone who can only execute tasks without understanding the bigger picture.

Successs doesn’t necessarily mean “the engineers who can code the fastest”. They’re the ones who can plan projects, direct technical efforts, and solve problems that AI can’t handle yet – understanding business requirements, making architectural decisions, and mentoring other developers. If you’re purely focused on implementation, you’re competing with increasingly capable AI tools. If you can think strategically about technical problems, you’re more valuable than ever.

What It Means at Every Level

Junior Engineers: Welcome to Hard Mode

If you got in before the COVID rush ended, good for you! If you’re a new grad today, I feel for you and worry about what the tight market for new grads will mean for the industry as a whole as people move up and out of the roles they’re not training juniors to replace.

If you’re trying to break into this field right now, it’s tough. Really tough.

The entry-level market is the most challenging it’s been in years. Companies that used to hire bootcamp grads by the dozen are now primarily recruiting from top computer science programs where students have already completed multiple internships. The competition is fierce, and the bar has been raised significantly.

The brutal reality: the bottleneck has moved entirely to that first job. Breaking in is harder than it’s ever been. Many new grads are facing months or even a year or more of job searching. The the counterintuitive part is once you do land that first role and prove you can deliver, the career progression opportunities are actually quite strong. The job market now works like this: getting your first job is nearly impossible, but once you’re in, moving up is much easier.

This creates a concerning dynamic: companies are being so selective with junior hires that they’re creating their own talent shortage at higher levels. The few juniors who do get hired often advance quickly because there’s less competition in the 2-5 year experience range.

Think of the job market like a funnel. The opening at the top (entry-level jobs) got much smaller, but once you squeeze through, there’s more room to move around inside.

The junior engineers who are succeeding right now aren’t just learning to code. They’re building real projects, contributing to open source, and demonstrating they can solve actual problems. They’re treating their job search like a full-time job itself.

Mid-Level Engineers: The Sweet Spot

If you have 3-7 years of experience, you’re in the driver’s seat. Companies desperately want engineers who can contribute immediately without months of hand-holding. You’re experienced enough to be productive from day one, but not so senior that you’re prohibitively expensive.

This is where the “skills shortage” everyone talks about is most acute. There’s massive demand for engineers who understand modern development practices, can work with AI tools effectively, and have experience building scalable systems.

Senior Engineers: More Critical Than Ever

The market for truly senior engineers – people with 8+ years of real experience – has never been better. Companies are realizing that a handful of excellent senior engineers can accomplish more than a small army of junior developers.

But being “senior” isn’t just about years of experience anymore. The demand is for people who can architect complex systems, mentor other developers, and bridge the gap between technical and business requirements. They’re the ones who can look at a business problem and figure out the right technical solution, not just implement what someone else designed.

Staff+ Engineers: Navigating Uncertainty

The market for engineering leaders is more volatile. While individual contributor roles are growing, many companies have been cutting back on engineering management positions. Amazon has been particularly aggressive about reducing engineering managers, and most of Big Tech is reducing Director+ roles.

For senior technical leaders who can wear multiple hats – architecture, mentoring, technical strategy – there are incredible opportunities. The key is being flexible about titles and focusing on impact over hierarchy. And patience, so much patience.

The AI Factor

Everyone wants to talk about whether AI is going to replace software engineers. I don’t see that happening, at least in the way investors want us to think it’s going to happen.

I’ve been experimenting with AI tools for months now, and they’ve made me more productive than I’ve ever been. Not because they write perfect code (they don’t), but because they handle the tedious stuff so I can focus on the problems that actually matter.

Adapting well means treating AI as a powerful tool, not a threat. Using it to prototype faster, explore different approaches, and handle routine tasks. I worry people are going to struggle if they are either ignoring AI entirely or expecting it to do all their thinking for them.

During my own job search, I noticed that the most performant companies increasingly expect candidates to be familiar with AI tools. It wasn’t enough to just know how to code – they wanted to see how you could leverage these new capabilities to be more productive, and they are willing to pay more for these skills.

The Real Story

The software engineering job market in 2025 isn’t broken. It’s maturing.

Gone are the days when any warm body who could write a for loop could expect multiple job offers and unlimited career growth. The market is more competitive, more demanding, and less forgiving of mediocrity.

For engineers who are genuinely good at this work – who can solve real problems, work effectively with teams, and adapt to new tools and technologies – this challenging market represents an amazing opportunity to differentiate yourself. While companies aren’t hiring in volume, this is exactly when you can build the skills, portfolio, and expertise that will set you apart when hiring does return. The engineers who use this downturn to level up will be in an incredibly strong position when the market turns (and I’m old enough at this point to tell you the pendulum always swings back eventually). Companies are willing to pay top dollar for people who can actually move the needle.

The key is being honest about where you stand. Are you coasting on skills you learned five years ago? Are you ignoring new developments because change is hard? Are you more focused on job titles than on the actual value you create?

The market has no patience for any of that anymore. My own experience taught me that even though decades of experience can open doors and get you conversations, they don’t guarantee anything if you can’t demonstrate current relevance and adaptability. But if you’re willing to stay sharp, keep learning, and focus on solving real problems, there’s never been a better time to be a software engineer.

What This Means for You

If you’re thinking about getting into this field: Do it, but go in with your eyes open. It’s not an easy path anymore, but it’s still one of the best careers you can build if you’re willing to put in the work.

If you’re already in the field: Don’t get comfortable. The engineers who are building lasting careers are the ones who never stop learning, who embrace new tools (including AI), and who focus on creating real value for their teams and customers.

If you’re hiring: Stop complaining about the “talent shortage” and start investing in the people you have. The best engineers have options, and they’re choosing companies that treat them well and give them interesting problems to solve.

The software engineering job market isn’t what it used to be. In many ways, that’s a good thing. The gold rush days of easy money and low standards are over. What’s left could be shaping up into a profession that rewards genuine skill, continuous learning, and the ability to solve complex problems. That sounds like the kind of field I want to be part of.

Getting Out of the IDE

When I first started playing around with language models, I thought the whole point was to write code directly inside an editor the way I’ve always done. That approach was frustrating and re-enforced my belief that AI models are an interesting toy but not capable of producing serious, reliable code.

That assumption broke when I read a Hacker News thread about a developer who goes to his desktop app instead of typing in his IDE. He’d ask the AI to sketch out a function, then go back and forth and copy the final snippet into his IDE to do the final tweaks manually.

It struck me that the AI wasn’t replacing the IDE; it was becoming another helper tool. I tried the same workflow: I opened Claude desktop, gave it read access to my repository, and asked it to propose solutions to the problem I was solving. The rest—adding tests, refactoring, integrating with the other domains in the system—remained firmly in my hands.

That experience taught me two things: first, AI can generate useful code on its own, but you still need to bring it into your existing toolchain; second, the “real” power comes from using the model as a collaborator that suggests ideas, not as a replacement for your IDE. It feels less like a threat and more like an extra pair of hands.

At some point I said that AI isn’t coming for your jobs, people who use AI effectively are coming… and that feels more true than ever before.

Why Longer Prompts Matter

In my early days of experimenting with LLMs, I would just type a short command to create a small feature, then issue more short commands to tweak the feature and debug it until I was satisfied. The output was quick, but it was also generic—no error handling, no documentation, no overall purpose. I kept hammering away at the prompt until I got something that worked in my test case. It took a lot of time, used a lot of tokens, and left me frustrated with the LLM as a tool.

Then I heard about about spec‑driven development. Instead of telling the model what to do after the fact, I asked it to write a specification first, to tell me what it planned to do and why it thought that way. The model produced a concise spec, then we refined it together - adding edge cases, asking what information the model was missing to build without hallucinations, making sure the rules were internally consistent.

Once I had that detailed spec, I fed it back into the prompt as a single long request. The result was a fully‑documented application with a graphical UI, terrain generation and complex build logic, with no bugs. Not quite a playable game, but easily weeks of work compressed down into a single evening.

That shift from “do this, now do this” to “what’s the full picture?” made the AI far more helpful. It feels like I’m co‑authoring a design document before I write code, which in turn reduces surprises when I get the final result.

Unexpressed Values Show Up as Bugs

My main beef with code that Claude and Gemini and ChatGPT produced was the quality seemed akin to a junior developer just out of college. Yes it might be functionally correct, but it missed all the principals that make good software and left me spending more time debugging than if I had just written the thing myself in the first place.

I mentioned this to a CTO friend and he pointed out that most developers have personal coding philosophies - some love concise functional style, others prefer explicit OOP patterns. The LLM model is trained on massive datasets of varying quality from the Internet. If your specific beliefs aren’t communicated to the AI, it defaults to its internal biases which can clash with yours.

So every time I got an output that bothered me from the AI, I woudl evaluate what it was that bothered me about the code, and express the correct methodology in my project file. When I re-ran the prompt, the bot started producing code that was closer and closer to the level of quality I would expect from my own.

Epiphany

They may not be major insights but those insights have transformed my workflow. I’m using these tools in as many places as I can find use for them - checking my work, tweaking my communications, organizing my chaotic thoughts into managable TODO lists. I feel so much more focused in my work, almost like I have an assistant running interference for me so I can focus on the most critical tasks.

Each new prompt feels like setting up a puzzle. I outline the goal, play with different phrasings and see how closely the AI’s output lined up with my mental image. It’s a loop of question, answer, refine much like a game where you learn the rules by trial and error.

The fun part? Every iteration teaches me something new about how to phrase requests or what specifications are most useful. I’m no longer just waiting for code or feedback from other developers; I’m actively shaping the conversation with the model. It’s less “I need help” and more “let’s see how close we can get.”

I’ve held a lot of jobs where clearly communicating my intent is important to keep the team aligned. Synthesizing my thoughts in a structured accessible way has always been a battle, and I finally have a tool that is challenging me to massively improve at that.

So, here I am, armed with determination, a laptop, and a questionable amount of caffeine. My journey into the digital wilderness begins. Time to buckle up, because we’re about to explore neural networks, deep learning, and maybe—just maybe—unlock the secrets of the universe. 🚀

Where to Start?

The main thing holding me back from getting into these tools was a general confusion about the various terms and buzzwords surrounding artificial intelligence. Our opinions are shaped by the “magical” things we see in the products and movies we consume, but the reality about AI is not some weird alien intelligence, it’s 1s and 0s planted firmly in the computers we already use and understand.

I thought I needed some obscure math knowledge or deep theory, and that just wasn’t the case. I assumed ML engineers had a lock on some important knowledge unavailable to me… nope. So let’s peel back some of the layers to understand what we’re working with.

Free is the Way

In 2024, you don’t have to pay for access to decent AI. You can benefit from tons of free resources that give you access to the latest commercially available models without paying. If you do want to go the paid route (e.g. ChatGPT Pro or Midjourney) your cost layout is relatively minor.

I don’t feel like I know enough about this subject yet to commit to paying for a particular implementation so I’ve been leaning toward open source projects and freely available commercial offerings. Most of the tech big players want in on this space and they make a ton of resources available to use for free.

Buzzwords vs Ideas

It’s never good when executives start talking about tech trends before you do, but that was the case for me when it came to machine learning (ML). It was some kind of miracle technology that was going to understand our customers’ sentiments and shortcut our internal processes for us. What is actually was, was a fancy way of saying big expletive Excel spreadsheet.

Essentially, this form of AI is a prediction engine that gets better with training data. Based on millions of examples, it can take input and guess what the output is. That’s it.

Combine ML with natural language processing (NLP) and you get a chatbot that appears to understand written human speech. This is what gives chatbots the uncanny valley where you might think (at first) you are talking to a real human. As we’ve all seen, these apps are easy to “fool” into giving you out of bounds responses, since they tend to have very little training outside their specialty area.

The terms neural networks and deep learning refer to flavours of the same thing, and are just ways of describing the complexity of the data beneath the ML. Deep learning in particular differentiates itself by having hundreds of millions, even trillions, of connecting nodes from which to draw inferences. This is the technology behind popular tools like ChatGPT; large language models (LLMs) are a particular type of neural network built on a transformer model that produces generative text based on queries.

Doing Things

What does it all mean? Knowing what the words are is one thing, actually doing something useful seems tricky at first.

The trick to using AI effectively is understanding what it does and doesn’t excel at.

Searching

If you ask AI to search for something you’ll get a Google-like result with a bunch of inaccuracies, so a lot of people give up at this step. Either the bot gives you a bunch of information that seems useful but you have to verify, or you are a subject matter expert and can immediately see all the problems in the results.

The reason for this is AI doesn’t actually know anything. All it can do is synthesize the data it was trained on. Any missing gaps get filled in to sound intelligent but really aren’t (this process is called hallucination).

Hallucinating sounds bad, but it’s actually an important part of how we can leverage these tools to do unique and creative things.

Writing

AI can absolutely write articles and papers for you. It’s even capable of writing in different voices and styles, and producing surprisingly unique-sounding prose. But as a finished product these works are garbage.

Although it’s good at mimicking aspects of human writing, there is a deep uncanny valley and “off” factor in articles written by machiens that don’t have actual personalities and don’t truly understand the concepts they’re writing about.

In particular, text generation is done word-for-word with no real knowledge of what came before and what will come later. Longer works especially will not flow, and the coherent text we do get fails to live up to the expectations of a native reader.

All that isn’t to be down on AI as a tool for writing. Some of this article, in fact, was written by ChatGPT. Can you tell which parts? AI is a fantastic tool to help inspire and speed up the creative process; it won’t replace a human entirely. You still have to edit the work and be prepared to describe, in great detail, what you want.

Which brings us to…

Idea Generation

If you’re stuck, describe your problem to an AI and it will spit back a list of ideas that will kick-start your next adventure.

Not sure what to cook for dinner? Take a picture of your refridgerator’s contents and ask for 5 meal ideas based on what it sees.

Cooking for picky houseguests? Ask for a mealplan tailored to their dietary preferences and tastes.

Working on the latest spacecraft for NASA? AI can shortcut the design of totally alien structures that perform better than traditional manual processes.

Specific Software

So what does it all mean? How do you actually jump in and do something useful with all this?

I kept getting stuck on tutorials that wanted me to install a bunch of Python libraries and code my problems, but that isn’t necessary at all. Here are my three favourite pieces of software you can use right now to dive into this.

Bing Copilot

Finally, a use for Bing! Remember Bing? That’s the search engine you get when you accidentally open Edge instead of Chrome. As it turns out, it’s being used as a clever gateway into AI - accessible and totally free.

Go to https://www.bing.com/chat and start talking to the AI. Ask it to make you a meal plan. A picture of a dog balancing on a circus ball. You need a (free) Microsoft Live account to sign into this but you can begin right away and get some impressive results.

Today Copilot uses a mix of GPT 3.5 and GPT 4 for language and Dall-E 3 for image generation. It advances fast, of course, and by the time you read this they’ve no doubt moved on to something even newer and better. Microsoft is able to flex their relationship with OpenAI (they are a partner and their largest investor) and has chosen to double down on their research in its products including Bing.

LM Studio

Stable Diffusion

Just Dive In

Learning AI has been transformative so far. The software in this article are not just gateways to understanding and getting practical use out of complex algorithms; they are the keys to unlocking a future of possibilities. By downloading and engaging with these tools, you’re taking the first step towards shaping that future. Whether creating intelligent solutions that tackle real-world problems or understanding the technology that’s changing the face of every industry, don’t just witness the AI revolution—be a part of it.

AI is not coming for your job. People who effectively use AI to make their work more valuable are coming for your job.

Seize this opportunity to learn, innovate, and lead the charge into a smarter, more connected world.

P.S. If you’re wondering whether I’ve accidentally created a sentient AI during my late-night coding sessions, fear not. My chatbot still thinks “banana” is the answer to everything. 🍌

I learned two things. First, I have no talent for graphics. Second, commercial software is created with development speed in mind, not runtime speed. As a result it was trivial to create apps that ran well on my machine. When your software is lovingly crafted and every detail obsessed over, you can write a program that effectively manages memory. The CD-ROMS I would buy to put in my computer, on the other hand, would end up making me choose between rebooting and grinding to a halt over time.

A memory leak on a consumer machine running games is irritating, but a similar memory leak on a banking mainframe or a communication protocol or a traffic control system is expensive and potentially fatal. Delivering bug-free software on schedule is hard (impossible?) work, and years of mistakes have left us with a digital infrastructure so riddled with potoles in the form of security flaws and memory safety issues that doesn’t just border on national security concerns - it crosses firmly into the danger zone; so much so even the White House has taken notice.

What are the implications of the White House’s declaration that memory issues caused by languages like C++ are a national security concern?

The face of the government is (hopefully) taking it serious that there may be vulnerabilities in the code written in these languages. If exploited by malicious actors they can lead to data breaches abd other security threats. Since culture runs from the top down, setting the expectation from the very top of government that language choice and security is a priority can lead to reforms in development processes across government.

When government and regulatory bodies, and those interfacing with them, have standards in place, it sets a level playing field for everyone else. It’s much more powerful than a bunch of programmers trying to tell everyone the same thing.

Why should the average programmer care about this situation?

If you’re not working for the government this is still important because it highlights the importance of secure coding practices regardless of the language used. Memory issues lead to vulnerabilities that can be exploited by hackers, which can result in data breaches and other security threats, sometimes years after the bug was introduced. By following best practices for memory allocation and using secure coding techniques, programmers can help protect their systems and the data they contain from these types of attacks.

Even if you’re working in one of these so called “insecure” languages and not going to change it up any time soon, it’s a good reminder to review your programming practices and put measures in place to update your security regime.

What makes languages like Rust, Python and C# more desirable from a security standpoint?

Languages like Rust, Python, and C# are often considered more desirable from a security standpoint because they have built-in memory management systems (I know Rust doesn’t have garbage collection but let’s be generous and count its memory ownership system) that help prevent common issues like buffer overflows and null pointer dereferences. This makes it easier for programmers to write secure code without having to manually manage memory.

Second, these languages tend to have stronger emphasis on security best practices such as input validation and error handling which can help prevent common coding errors that lead to security issues in the first place.

Finally, these languages have large and active communities of developers who are constantly working to improve the security of their language and its associated libraries and frameworks. This makes it easier for programmers to stay up-to-date on the latest security patches and best practices.

No one is suggesting C or C++ should be dropped in favour of “better” languages.

Obviously using languages like C and C++ doesn’t mean your code is automatically insecure. These languages have a long history and are widely used everywhere, and most of the time they’re not destroying the nation.

In order to improve program security, developers need to constantly update their knowledge and techniques. (Always Get Better!) Stay up to date with the latest threats and vulnerabilities, use secure coding practices such as input validation and sanitization, and incorporate security testing and analysis into the development process. By continuously improving their technique and staying vigilant about security, we can create more secure software programs that are less susceptible to attacks and breaches.

That was fine for a few years, but I’m not doing any hosting work lately, and it seemed like a wasteful expense for a blog I haven’t been updating.

I’ve been making static sites with Jekyll for years and decided to throw my blog into it and host directly from my GitHub account. The pages environment is free, fast, and lets you use your custom domains, so it doesn’t really make sense to keep paying for hosting.

As a programmer, I am getting satisfaction from seeing all my posts in a Git repository, stable and versioned. No more tweaking PHP or worrying about WordPress and plugin vulnerabilities.

Pros

• Free!
• Static sites are fast - like, crazy fast
• Cross-linking posts is way easier - searching my file system for post content is fast and straightforward
• Markdown for programming articles works so much better than editing in WordPress
• The workflow for adding new articles and pages is simple
• It’s easier to think about the files and resources I’m using in my build

Cons

• Less control. If GitHub doesn’t support it, I can’t do it
• Static, so no more comments/discussion. I haven’t seen anything other than spam in years, so I’m not feeling much pain from this.
• If GitHub decides to stop making pages free, I’ll have to move again. Whatever, I have the source code
• If Jekyll changes I won’t be able to build the site. Rebuilding to something else from source would be painful
• Doing complicated layout things is slooowww. I don’t love the templating engine

Clean Architecture by Bob Martin

Clean Code by the same

Staff Engineer: Leadership Beyond the Management Track by Will Larson

The Price of Tomorrow by Jeff Booth

The Pragmatic Programmer by David Thomas and Andrew Hunt

In case anyone wants to know what I’ve been up to, last year I left my CTO role at a startup in Vancouver, changed my base of operation to Nova Scotia and joined an non-profit. I’m working with a fantastic group of people and couldn’t be happier right now.

My public output has been pretty low for the last year or so. Looking back, I think I needed to get out of the fast lane for a bit. The last decade I moved across the continent twice, immersed in startup culture, published two books, homeschooled three kids, and generally had an iron in the fire constantly. The pace of life is much slower here and I’ve enjoyed taking some time to regroup, enjoy the kids, and heal.

Some big stuff is in the works. I’m looking forward to announce some new projects I am excited to share with the world.

Here’s to a fantastic 2021!

Our journey started with a focus on customer satisfaction through constant software delivery. We quickly learned to welcome changing requirements, seeing them as opportunities rather than roadblocks. This led directly to understanding the power of frequent delivery of working software. That’s the real measure of progress.

We then tackled the human side, realizing businesses and developers work best together. This means trusting motivated individuals and valuing rich, face-to-face conversations over endless emails. After all, working software is the primary measure of progress.

It became clear that pushing too hard leads to burnout, so we focused on sustainable development. This ties directly into technical excellence. Sloppy code slows you down. We also found power in simplicity, cutting out the fluff to deliver real value.

The journey concluded with empowering self-organizing teams and the crucial practice of reflecting and adjusting our approach. Agile isn’t a static set of rules. It’s about constant tuning, adapting, and always getting better. That’s the real lesson from a year with these principles.