DEV Community: N E I L O H E N E

How Not to Think

N E I L O H E N E — Sat, 18 Oct 2025 22:05:01 +0000

When my dad tried to teach me to drive a manual car, I quickly realized I was out of my depth. I'd been cruising in an automatic for years. Suddenly, I was stalling the engine left and right. At one point, I nearly drove into a gutter while trying to downshift on a turn. My dad kept repeating, "Feel the car, feel the biting point, let it breathe, be part of the car." Be part of the car? I barely felt like part of myself. But the way he said it… you could tell he loved it as much as I love computers. I thought it would be simple. It was anything but. I almost quit.

Meanwhile, my friend Elorm seemed to take to it naturally. I shared my ordeal with him and he kept on saying the same thing, "Feel the breaking point. That resistance, and slowly release the pressure". He was laughing through every mistake I shared with him. I started thinking about why I struggled so much. The automatic had done all the work for me for so long that I had never learned what it actually takes to drive. The timing, the feel, the control. Automatic gets you where you're going, but manual teaches you how the machine actually works.

That's what I see with engineers and AI. Many hit a problem, immediately ask ChatGPT for the answer, copy the solution, and move on. No thinking. No experimenting. No growth. It's like learning to drive but leaving the cruise control on the whole time. You reach the destination, but you never really drive. And there's research to back this up. An MIT study found that people who rely on AI for complex tasks like writing essays actually show weaker brain connectivity. Strategic thinking, memory, creativity, they all take a hit. The researchers call it "cognitive debt." You borrow mental effort from AI, but the interest stacks up fast.

I think about it like this: I'm the craftsman, AI is the builder. I handle the reasoning, the trade-offs, the strategic thinking. AI handles the syntax, the boilerplate, the pattern matching. That's the distinction that matters. It keeps you valuable while still leveraging AI's power. When I first learned HTML and CSS, I used Notepad. Python? Just the basic IDLE. Java?? I read [Herbert Schildt's Java Reference Book](https://www.accessengineeringlibrary.com/content/book/9781260463415. No code helpers, no shortcuts, no AI. Just me and the docs, making mistake after mistake. That struggle built something in me. The neural pathways that make you actually understand what you're doing, not just copy-pasting solutions. It's like knowing why a recipe works versus just following steps. But here's the thing: in a fast-moving world, you can't learn everything the hard way. You need speed. You just can't let it replace understanding.

So where's the line? It's what I call the "biting point," same as with that manual transmission. It's that moment when you've struggled enough to understand the problem, but you're ready for AI to help you implement faster. You're not skipping the thinking. You're accelerating the doing. Like with driving manual, it takes adjusting. You mess up. You refine. Eventually, it becomes muscle memory. You know when to engage first gear, when to let the clutch out, when to give it gas. Same with coding. You struggle through a problem until you understand the principles. Then you iterate. You build those neural pathways. Eventually, you can spot similar problems instantly and know exactly how to approach them. That's how you avoid "cognitive offloading," which is what the research warns about. You're not skipping the understanding phase. You're just speeding up implementation. The system works in phases: pure struggle to learn, AI assistance while you maintain control, validation where you test everything, and finally mastery where you recognize patterns instantly. You become that manual transmission driver who can feel exactly what the car needs.

My approach is simple but takes discipline. When learning something new? No AI. Zero. You build understanding layer by layer. AI would just shortcut that process and rob you of real learning. Set your own goals. Struggle through it. Build the mental models. For implementation? That's when AI becomes useful. You already know what you want. AI writes it. You validate. You iterate. The thinking stays yours. For validation? Use AI to find how others solved similar problems. Study their patterns. Then come back and make yours better. The key is agency. AI responds to your questions. It doesn't drive. You decide when you need help.

Steve Yegge nailed it recently. What makes someone "senior" in the AI era? Two things: knowing what you want before AI writes it, and catching when AI gives you garbage. That's exactly what the research shows. When you lose the ability to validate AI output, your brain literally stops engaging. It's cognitive offloading in action.

Here's my go-to prompt when I need AI help:

Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let's do this iteratively and dig into every relevant detail. Remember, only one question at a time.

It forces me to think through each step. I maintain ownership. I develop understanding instead of just accepting whatever AI spits out. The real danger? It's not that AI will replace engineers. It's that engineers will replace themselves with AI-dependent versions that can't think independently.

Think about building intelligent systems. You can't build what you don't understand. We're creatures of reasoning. How do you build something you have no clue about? LLMs can't go beyond their training. Sure, they remix existing solutions in new ways. But critical thinking? Like the flat earth versus spherical earth debate? If LLMs existed back then, they'd only work within the flat earth paradigm. It took someone to challenge the premise. To say, "Hey, that doesn't seem right." Newton observing an apple. Euclid discovering density. That's human reasoning breaking new ground.

As 3Blue1Brown points out, LLMs are pattern matching systems. Sophisticated ones, but still just pattern matchers. They generate content based on similarity. They don't understand context. They don't actually "know" anything. They predict what comes next based on training data. When you outsource thinking to a system that doesn't think, you're not delegating work. You're letting your skills atrophy.

The solution isn't avoiding AI. That's not realistic. The solution is using it strategically while keeping your edge sharp. Build deep understanding of algorithms, data structures, system design. Get operations experience. Learn to validate AI output and catch bad guidance. Cross-validate with multiple AI systems. Use AI as your turbocharger, not your replacement. Stay the craftsman. Let AI be the builder.

Your brain is a muscle. It needs exercise. Challenges make you grow. Reasoning through problems makes you better. Don't let AI steal that from you. The projects I work on and build today are way more complex than anything I imagined years ago. But I understand them deeply. I kept my thinking sharp while using AI to move faster. That's the difference. Using AI versus being used by it.

Everyone's replaceable, believe it or not. In a world riddled by mediocrity, I'm still enthused by what the human mind can really do. I've met some really amazing people whose thinking process always marvels me. AI would always be a supportive partner, like Tony Stark and Jarvis type thing. But just as that. May we find our place as masters of these tools in the world and season we are ushering into.

The research referenced in this post comes from "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task" by Kosmyna et al. from MIT Media Lab. The study provides compelling evidence for the cognitive impacts of AI dependence.

🔑 10 Easy Tips to Make Your Code Look Pro!

N E I L O H E N E — Mon, 08 May 2023 08:20:28 +0000

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.😂
~ John Woods

As a programmer, writing clean and maintainable code is like doing laundry - it's not always fun, but it's essential. Not only does it make your job easier, but it also helps others understand your code easily. In this post, I will share ten free tips that will help you write clean and maintainable code, even if you're new to programming.

🏷 Give Your Code A Name Tag!

The point is, it helps others understand what your code does and makes it easier to read. Always use descriptive names for your classes, methods, and variables. Naming conventions do matter when writing code. Use the appropriate case style or naming conventions available when writing code. So, instead of using vague names like x and y, you could use names like numberOfStudents and totalSales. It may seem like a small thing, but it can make a big difference in the readability and maintainability of your code.

👌🏾 Keep Your Functions/Methods Short and Simple!

Functions/methods should be structured just like paragraphs in a book - concise and focused on one topic. Paragraphs that cover more than one topic are like a jumbled mess of ideas - they're difficult to comprehend. It's important to keep them short and to the point, and a good rule of thumb is to limit them to one idea or action. Think of them as building blocks of code!

✍🏾 Comment Your Code!

Comments are like little notes that help you and others understand your code. They should explain why the code exists, not what it does. They should be concise, and you should avoid commenting on obvious things. So instead of this, // set value to 5, you could use // set the initial value to 5 to avoid null values. Simple right!

🍀 Use Whitespace and Formatting

The use of whitespace and formatting can make reading your code much easier. Indentation is critical, and it's essential to be consistent with it. Use blank lines between functions and classes to make your code more readable. Choose a formatting style and stick to it throughout your codebase. Think of it like organizing your own closet!

📦 Choose Your Data Structures Carefully

Choosing the right data structures is like choosing the right tool for the job. Use the appropriate data structure for each task, and it can make your code more efficient and more readable. Think of it like choosing the right ingredient for your recipe! So, instead of using an array to store key-value pairs, you could use a dictionary or a hash table.

🔢 Avoid Magic Numbers and Strings

Avoid hard-coding values that have no explanation. Use constants or enums instead, and it will make your code more readable and maintainable. Think of it like using labels instead of numbers! So, instead of using if (status == 1) to check if a task is complete, you could use if (status == TASK_COMPLETED).

🚫🔁 Don't Repeat Yourself (DRY)

If you find yourself copying and pasting code, that's a sign that you need to refactor it and create a function instead. Think of it like reusing your favorite ingredients to make a delicious meal! So, instead of repeating the same code in multiple places, you could create a function that does the job once and call it whenever you need it.

🎯 Test Your Code

Testing is like playing hide and seek with your code. Write tests for your code, and it will help you catch bugs early on. Use test-driven development (TDD) if possible, and it will make your code more robust. Think of it like playing a game of hide and seek, but with code! So, instead of waiting for a user to report a bug, you could write tests that simulate different scenarios and catch the bugs before they reach the user.

🗺️ Make Your Error Messages as Helpful as GPS Directions

Error messages should be like GPS directions - descriptive and helpful. They should explain what went wrong and how to fix it. Avoid generic error messages that provide no information. Think of it like giving someone directions! So, instead of using Error: Invalid input, you could use Error: The input should be a positive integer.

📚 Keep Learning

Finally, keep learning and improving your skills. There is always something new to learn, and it will make you a better programmer. Attend conferences, join communities, read blogs and books, and try new things. Think of it like exploring a new world! So, instead of sticking to the same programming language and tools, you could try learning a new language or framework.

Conclusion

In conclusion, writing clean and maintainable code is essential. Use these ten tips to help you write better code, even if you're new to programming. Remember to keep learning and improving your skills, and you will become a better programmer. Happy coding devs!