Lies We Often Tell Ourselves: Simplicity, Microservices, and More

Software development has a way of humbling you. Early in my career, I was certain about a lot of things—best practices, the “right” way to code, and how teams should work. Over time, I realized that many of those “truths” weren’t universal. Some were outright wrong. And some—well, present-me now finds hilarious. The more code I write—and the more late-night debugging sessions I survive—the more I see how few absolutes exist in this field. Chris Kiehl recently wrote a fantastic blog post reflecting on 10 years in software development, sharing lessons that resonated deeply with me. After 25+ years of hands-on coding, I can say that these lessons become even more true over time. Consider this article my chance to highlight the big mindset shifts that creep in after decades in the trenches—plus a few comedic jabs I wish someone had told me earlier. Check Chris’ article here: https://chriskiehl.com/article/thoughts-after-10-years 1. Simplicity is a full-time job. Everyone agrees that “good code is simple.” Turns out, that keeping it simple takes constant effort. Leave code alone for a month, and it starts sprouting complexities like weeds. If your code is an over-engineered labyrinth, get the lawnmower and trim it down, do it weekly. 2. Complexity isn’t a flex. There was a time when I took pride in deciphering arcane systems. Now, I take pride in making them disappear. If your codebase requires a 12-hour onboarding session complete with flowcharts that look like cryptic treasure maps, you haven’t built something genius; you’ve built something that keeps new hires up at night. 3. Typed languages aren’t a luxury—they’re essential. Once, I thought dynamic typing was freedom: no constraints, just vibes. Then came 3 AM bug hunts caused by a single mistyped variable that turned everything into confetti. Types aren’t a cage; they’re the guardrails that keep a drowsy driver from veering off a cliff. Especially on teams with varying skill levels, type systems are a lifeline. Spend time up front clarifying function inputs and outputs, and you’ll avoid rummaging through logs at ungodly hours. Especially when you keep hearing from all sides the ever-green: “Our customer does not allow us extra time for unit tests…” 4. Java is actually great… because it’s boring. Any language that just works, has stable tooling, and doesn’t feel compelled to reinvent itself every six months is an asset, not a relic. Give me “boring and reliable” over “exciting and unpredictable” if we’re running a business. Java, C#, Go—even PHP—prove that reliability can generate real value. Not everything has to be the new shiny toy. In production environments, stability > hype every time. 5. Most programming happens before you write a single line of code. Real engineering happens before you crack open your IDE: Understanding the actual problem Scoping the requirements and data models. Designing a clean, maintainable solution Analyzing how new changes impact 3rd party integrations Listing out all the edge cases, etc. Drafting a minimal PRD that later will evolve into actual documentation Sitting down to code is the last step. Junior devs often jump straight into coding, only to discover midway that they misunderstood the spec. If you plan like a pro, you can code like one, too. One of my team’s favorite proverbs used to be “One week of coding can save you 2 hours of planning,“ 6. Frontend development is a Kafkaesque nightmare. I used to love frontend. Over the years, it became more like stepping into a haunted mansion where the floor plan changes daily. New frameworks, shifting best practices, impossible state management battles—some folks thrive on that adrenaline. I realized I liked my sanity intact. If you’re a front-end whiz, hats off to you, but keep an eye on that floor. It might vanish tomorrow. 7. ORMs are not the magic solution. Just write the SQL. (But also… use the right tool.) ORMs seem like a time-saver—until they produce a query so monstrous it stops your database in its tracks. Yes, SQL is an old language, but it’s powerful for a reason. Learn it, use it, and you’ll avoid half the performance nightmares that come with one-size-fits-all abstractions. Still, it’s not a black-and-white debate: Small-to-mid projects? ActiveRecord-style ORMs are fine. Large-scale apps? Query builders & raw SQL are your friends. Reporting or analytics? ORMs usually create queries that could put your DB on life support. The key is knowing the right tool for each scenario. 8. Good management is invaluable. Bad management is far too common in this industry. But a truly good manager? That can mean the difference between a thriving team and an early burnout. A great manager removes roadblocks, fights off scope creep, and helps you grow instead of piling on tasks with no guidance. It’s not just about being technically sharp; it’s about emotional intelligence and shielding your team from chaos. The main responsibility of a tech manager is to keep everyone, especially top management, grounded in reality. 9. The query planner is a cruel mistress. You may think you know how your database works—until you look at an execution plan that betrays all your assumptions. Indexes are fantastic until they aren’t. Queries are blazing fast until they’re not. Database tuning is an art form, best approached with patience, a willingness to read logs, and possibly a stiff drink. Or three. 10. Code quality matters more than speed. (Not always.) Early in my career, I obsessed over writing “beautiful” code. But in a real-world environment, deadlines, business demands, and trade-offs run the show. Sometimes, shipping on time is more important than achieving conceptual purity. There’s no point polishing code that never makes it into production. The trick is knowing when to make compromises and how to keep track of the debt you’ll inevitably have to pay back. 11. Green tests don’t mean working software 100% test coverage can be a false sense of security. I’ve seen entire test suites pass while the real application burned quietly in the corner. Tests are only as good as the scenarios you write. A passing test suite that never checks critical business logic is a glorified thumbs-up. Always aim for the right tests, not just a high coverage number. At a minimum, test the real integration points—especially with third-party systems. 12. Git history should be useful, not perfect When I started, I wanted a Git history that looked like a curated museum exhibit. Then, reality (and a few weekend crunch sessions) happened. The truth is, clarity beats aesthetics. Over-rebasing can wipe out the breadcrumb trail that helps you debug. A perfectly linear commit tree won’t matter if it takes you hours to figure out where a breaking change originated. Keep it readable, keep it useful—leave the perfectionism at the door. GitFlow is great, but make sure you’re team is big enough to actually need it. Smaller teams usually need a dedicated “mini-gitflow” version of the process. 13. “Best practices” are usually just “best practices for someone else.” Younger devs sometimes assume that best practices are holy commandments. Those with a few more battles under their belts know that “best” depends on your team’s skill set, your business constraints, and your performance or scaling needs. In other words, Google’s best practice might not help your three-person startup. Context rules everything. 14. Scaling is a problem you wish you had. I used to over-engineer everything, anxiously anticipating the moment a thousand new users would crash my app. Turns out, most projects never see that kind of user load. If you don’t have an actual scaling challenge yet, don’t spend your life building a fancy architecture for a party that might never happen. Get customers first, and then scale when you actually need to. Otherwise, you’re just building a castle in the sky. 15. “Rewrite it from scratch” is almost always a bad idea. Sure, rewriting your entire codebase sounds refreshing. But the reality is you’ll reintroduce old bugs, lose hidden fixes, and burn countless hours rewriting what already (sort of) works. Meanwhile, your boss wonders why features aren’t being delivered. Refactor where you can, rewrite only if you must. “Burn it all down” often looks good on paper, but it’s typically a development time sinkhole. P.S. This does not apply to abandoned legacy codebases, typically built on prehistoric dependencies, libraries, and frameworks—or the complete lack thereof. 16. Microservices aren’t the answer. Ah, microservices: the darling of modern architecture. Also, the cause of many a meltdown when you realize how much overhead they introduce. If you’re not operating at Google scale, you probably don’t need a microservices labyrinth. A monolith is almost always cheaper, simpler, and easier to maintain. Don’t adopt microservices just because it’s the trendy thing to do. Build a monolith first, then start modularizing it a year after the first production deployment. 17. You don’t need the “latest and greatest” tools. Chasing trends can be like sprinting on a hamster wheel. React or Vue? Doesn’t matter if your product is still stuck in planning. Rust or Go? Doesn’t matter if you can’t hire or train developers for them or if your boss/customer doesn’t provide you with a higher budget for this kind of position. Kubernetes? You do not need that complexity unless you’re orchestrating dozens of services. Pick tools that help you ship now and that your team can realistically manage. The goal is to solve problems, not to collect badges. 18. You don’t need a CS degree to be a great developer. A CS degree is helpful, sure. But it’s not a prerequisite for excellence. Many fantastic devs have non-traditional backgrounds, taught themselves online, or switched careers from something completely different. That said, you should still learn fundamental algorithms, data structures, and system design. If you skip formal education, make sure you fill in those gaps. 19. Writing good documentation is a superpower. Poor documentation can make even the best code borderline useless. The ability to write clear, helpful docs sets you apart—seriously. When new developers (or future-you) come on board, well-structured docs can save them days of frustration. If you want job security, become the one who writes (and updates) docs that people can actually follow. 20. Most dev jobs are about glue code, not groundbreaking innovation. We all dream of building the next big thing, but most dev gigs involve hooking up APIs, gluing together libraries, or debugging library conflicts. That’s not a bad thing—it’s just reality. A lot of software engineering is about problem-solving within constraints, not rewriting the rules of computing. Embrace the “glue code” aspect, because it’s what keeps the wheels turning. 21. Your biggest productivity boost isn’t a new framework—it’s focus. You can pick React, Vue, Svelte, or a random library you found on Reddit. If you’re getting pinged by Slack messages every five minutes, your productivity is still going down the drain. Focus is the true superpower. Deep work, minimizing interruptions, small hacks like noise-canceling headphones, and focusing on real output over busywork will improve your dev speed more than any fancy new tech. 22. You will never fully catch up with everything. And that’s okay. It’s tempting to try to know every new JavaScript framework or every new Docker-like tool. But there’s simply too much out there. Once you accept that, you can focus on learning the fundamentals and the big-picture concepts that apply across technologies. Being able to adapt quickly to new tools and understanding the fundamentals is far more valuable than memorizing every corner of the ecosystem. 23. Seniority isn’t about knowing more—it’s about making better trade-offs. A senior developer isn’t someone who can recite every array method in 15 languages; it’s the person who knows which problems are worth solving. Senior devs say no to unnecessary features, push back on unrealistic deadlines, and avoid over-engineering. They’re the ones who understand the cost of adding complexity—and they’re comfortable advocating simpler solutions. It’s about making the right trade-offs and knowing which problems are worth solving. 24. Debugging is a skill. Logging is an art. Yes, debugging means hunting down the cause of a bug. But experienced devs know that proper logging can prevent a hunt in the first place. A single well-placed log statement can save you hours of guesswork. Log the right things (not just everything). Use structured logs, not random print statements. Make logs actionable—timestamps, correlation IDs, and useful context. Learn to use tools that process and search through logs fast. If your log files read like a jumbled mess, you’re making life harder for yourself (and your teammates). Logging is an area that is most often completely overlooked by developers and considered the least important, rather than being treated as one of the key elements in improving software quality. 25. Senior devs make the team better, not just themselves. Early in your career, you might think a “senior” is the one who solo-crushes every difficult task. But real seniority is about enabling the entire team to thrive. Your job is to unblock others, not just yourself. Hoarding knowledge makes you a bottleneck, not a genius. Mentorship is crucial—if your team isn’t growing, you’re failing. A senior dev who invests in mentorship, documentation, and automation elevates the whole group. And in 10 years? I’ll probably look back at this post and laugh at today-me, too. That’s the job—constant change, constant growth, and a dash of self-deprecation. What’s your biggest dev mindset shift? Let me know below. I’d love to see how your perspective has evolved over time. Software development has a way of humbling you. Early in my career, I was certain about a lot of things—best practices, the “right” way to code, and how teams should work. Over time, I realized that many of those “truths” weren’t universal. Some were outright wrong. And some—well, present-me now finds hilarious. The more code I write—and the more late-night debugging sessions I survive—the more I see how few absolutes exist in this field. certain should Chris Kiehl recently wrote a fantastic blog post reflecting on 10 years in software development , sharing lessons that resonated deeply with me. After 25+ years of hands-on coding, I can say that these lessons become even more true over time. Consider this article my chance to highlight the big mindset shifts that creep in after decades in the trenches—plus a few comedic jabs I wish someone had told me earlier. 10 years in software development 25+ years even more true Check Chris’ article here: https://chriskiehl.com/article/thoughts-after-10-years https://chriskiehl.com/article/thoughts-after-10-years 1. Simplicity is a full-time job. 1. Simplicity is a full-time job. Everyone agrees that “good code is simple.” Turns out, that keeping it simple takes constant effort . Leave code alone for a month, and it starts sprouting complexities like weeds. If your code is an over-engineered labyrinth, get the lawnmower and trim it down, do it weekly. keeping constant effort 2. Complexity isn’t a flex. 2. Complexity isn’t a flex. There was a time when I took pride in deciphering arcane systems. Now, I take pride in making them disappear . If your codebase requires a 12-hour onboarding session complete with flowcharts that look like cryptic treasure maps, you haven’t built something genius; you’ve built something that keeps new hires up at night. disappear 3. Typed languages aren’t a luxury—they’re essential. 3. Typed languages aren’t a luxury—they’re essential. Once, I thought dynamic typing was freedom: no constraints, just vibes. Then came 3 AM bug hunts caused by a single mistyped variable that turned everything into confetti. Types aren’t a cage; they’re the guardrails that keep a drowsy driver from veering off a cliff. Especially on teams with varying skill levels, type systems are a lifeline. Spend time up front clarifying function inputs and outputs, and you’ll avoid rummaging through logs at ungodly hours. Especially when you keep hearing from all sides the ever-green: “Our customer does not allow us extra time for unit tests…” 4. Java is actually great… because it’s boring. 4. Java is actually great… because it’s boring. Any language that just works , has stable tooling, and doesn’t feel compelled to reinvent itself every six months is an asset, not a relic. just works Give me “boring and reliable” over “exciting and unpredictable” if we’re running a business. Java, C#, Go—even PHP—prove that reliability can generate real value. Not everything has to be the new shiny toy. In production environments, stability > hype every time. stability > hype 5. Most programming happens before you write a single line of code. 5. Most programming happens before you write a single line of code. Real engineering happens before you crack open your IDE: before Understanding the actual problem Scoping the requirements and data models. Designing a clean, maintainable solution Analyzing how new changes impact 3rd party integrations Listing out all the edge cases, etc. Drafting a minimal PRD that later will evolve into actual documentation Understanding the actual problem Scoping the requirements and data models. Designing a clean, maintainable solution Analyzing how new changes impact 3rd party integrations Listing out all the edge cases, etc. Drafting a minimal PRD that later will evolve into actual documentation Sitting down to code is the last step. Junior devs often jump straight into coding, only to discover midway that they misunderstood the spec. If you plan like a pro, you can code like one, too. One of my team’s favorite proverbs used to be “ One week of coding can save you 2 hours of planning, “ One week of coding can save you 2 hours of planning, 6. Frontend development is a Kafkaesque nightmare. 6. Frontend development is a Kafkaesque nightmare. I used to love frontend. Over the years, it became more like stepping into a haunted mansion where the floor plan changes daily. New frameworks, shifting best practices, impossible state management battles—some folks thrive on that adrenaline. I realized I liked my sanity intact. If you’re a front-end whiz, hats off to you, but keep an eye on that floor. It might vanish tomorrow. 7. ORMs are not the magic solution. Just write the SQL. (But also… use the right tool.) 7. ORMs are not the magic solution. Just write the SQL. (But also… use the right tool.) ORMs seem like a time-saver—until they produce a query so monstrous it stops your database in its tracks. Yes, SQL is an old language, but it’s powerful for a reason. Learn it, use it, and you’ll avoid half the performance nightmares that come with one-size-fits-all abstractions. Still, it’s not a black-and-white debate: Small-to-mid projects? ActiveRecord-style ORMs are fine. Large-scale apps? Query builders & raw SQL are your friends. Reporting or analytics? ORMs usually create queries that could put your DB on life support. Small-to-mid projects? ActiveRecord-style ORMs are fine. ActiveRecord-style ORMs Large-scale apps? Query builders & raw SQL are your friends. Query builders & raw SQL Reporting or analytics? ORMs usually create queries that could put your DB on life support. The key is knowing the right tool for each scenario. 8. Good management is invaluable. 8. Good management is invaluable. Bad management is far too common in this industry. But a truly good manager? That can mean the difference between a thriving team and an early burnout. A great manager removes roadblocks, fights off scope creep, and helps you grow instead of piling on tasks with no guidance. It’s not just about being technically sharp; it’s about emotional intelligence and shielding your team from chaos. The main responsibility of a tech manager is to keep everyone, especially top management, grounded in reality. The main responsibility of a tech manager is to keep everyone, especially top management, grounded in reality. 9. The query planner is a cruel mistress. 9. The query planner is a cruel mistress. You may think you know how your database works—until you look at an execution plan that betrays all your assumptions. Indexes are fantastic until they aren’t. Queries are blazing fast until they’re not. Database tuning is an art form, best approached with patience, a willingness to read logs, and possibly a stiff drink. Or three. 10. Code quality matters more than speed. (Not always.) 10. Code quality matters more than speed. (Not always.) Early in my career, I obsessed over writing “beautiful” code. But in a real-world environment, deadlines, business demands, and trade-offs run the show. Sometimes, shipping on time is more important than achieving conceptual purity. There’s no point polishing code that never makes it into production. The trick is knowing when to make compromises and how to keep track of the debt you’ll inevitably have to pay back. when how 11. Green tests don’t mean working software 11. Green tests don’t mean working software 100% test coverage can be a false sense of security. I’ve seen entire test suites pass while the real application burned quietly in the corner. Tests are only as good as the scenarios you write. A passing test suite that never checks critical business logic is a glorified thumbs-up. Always aim for the right tests, not just a high coverage number. At a minimum, test the real integration points—especially with third-party systems. At a minimum, test the real integration points—especially with third-party systems. 12. Git history should be useful, not perfect 12. Git history should be useful, not perfect When I started, I wanted a Git history that looked like a curated museum exhibit. Then, reality (and a few weekend crunch sessions) happened. The truth is, clarity beats aesthetics. Over-rebasing can wipe out the breadcrumb trail that helps you debug. A perfectly linear commit tree won’t matter if it takes you hours to figure out where a breaking change originated. Keep it readable, keep it useful—leave the perfectionism at the door. GitFlow is great, but make sure you’re team is big enough to actually need it. Smaller teams usually need a dedicated “mini-gitflow” version of the process. 13. “Best practices” are usually just “best practices for someone else.” 13. “Best practices” are usually just “best practices for someone else.” Younger devs sometimes assume that best practices are holy commandments. Those with a few more battles under their belts know that “best” depends on your team’s skill set, your business constraints, and your performance or scaling needs. In other words, Google’s best practice might not help your three-person startup. Context rules everything. Context rules everything. 14. Scaling is a problem you wish you had. 14. Scaling is a problem you wish you had. I used to over-engineer everything, anxiously anticipating the moment a thousand new users would crash my app. Turns out, most projects never see that kind of user load. If you don’t have an actual scaling challenge yet, don’t spend your life building a fancy architecture for a party that might never happen. Get customers first, and then scale when you actually need to. Otherwise, you’re just building a castle in the sky. 15. “Rewrite it from scratch” is almost always a bad idea. 15. “Rewrite it from scratch” is almost always a bad idea. Sure, rewriting your entire codebase sounds refreshing. But the reality is you’ll reintroduce old bugs, lose hidden fixes, and burn countless hours rewriting what already (sort of) works. Meanwhile, your boss wonders why features aren’t being delivered. Refactor where you can, rewrite only if you must. “Burn it all down” often looks good on paper, but it’s typically a development time sinkhole. P.S. This does not apply to abandoned legacy codebases, typically built on prehistoric dependencies, libraries, and frameworks—or the complete lack thereof. 16. Microservices aren’t the answer. 16. Microservices aren’t the answer. Ah, microservices: the darling of modern architecture. Also, the cause of many a meltdown when you realize how much overhead they introduce. If you’re not operating at Google scale, you probably don’t need a microservices labyrinth. A monolith is almost always cheaper, simpler, and easier to maintain. Don’t adopt microservices just because it’s the trendy thing to do. Build a monolith first, then start modularizing it a year after the first production deployment. Build a monolith first, then start modularizing it a year after the first production deployment. 17. You don’t need the “latest and greatest” tools. 17. You don’t need the “latest and greatest” tools. Chasing trends can be like sprinting on a hamster wheel. React or Vue? Doesn’t matter if your product is still stuck in planning. React or Vue? Doesn’t matter if your product is still stuck in planning. Rust or Go? Doesn’t matter if you can’t hire or train developers for them or if your boss/customer doesn’t provide you with a higher budget for this kind of position. Rust or Go? Doesn’t matter if you can’t hire or train developers for them or if your boss/customer doesn’t provide you with a higher budget for this kind of position. Kubernetes? You do not need that complexity unless you’re orchestrating dozens of services. Kubernetes? You do not need that complexity unless you’re orchestrating dozens of services. Pick tools that help you ship now and that your team can realistically manage. The goal is to solve problems, not to collect badges. 18. You don’t need a CS degree to be a great developer. 18. You don’t need a CS degree to be a great developer. A CS degree is helpful, sure. But it’s not a prerequisite for excellence. Many fantastic devs have non-traditional backgrounds, taught themselves online, or switched careers from something completely different. That said, you should still learn fundamental algorithms, data structures, and system design. If you skip formal education, make sure you fill in those gaps. 19. Writing good documentation is a superpower. 19. Writing good documentation is a superpower. Poor documentation can make even the best code borderline useless. The ability to write clear, helpful docs sets you apart—seriously. When new developers (or future-you) come on board, well-structured docs can save them days of frustration. If you want job security, become the one who writes (and updates) docs that people can actually follow. 20. Most dev jobs are about glue code, not groundbreaking innovation. 20. Most dev jobs are about glue code, not groundbreaking innovation. We all dream of building the next big thing, but most dev gigs involve hooking up APIs, gluing together libraries, or debugging library conflicts. That’s not a bad thing—it’s just reality. A lot of software engineering is about problem-solving within constraints, not rewriting the rules of computing. Embrace the “glue code” aspect, because it’s what keeps the wheels turning. 21. Your biggest productivity boost isn’t a new framework—it’s focus. 21. Your biggest productivity boost isn’t a new framework—it’s focus. You can pick React, Vue, Svelte, or a random library you found on Reddit. If you’re getting pinged by Slack messages every five minutes, your productivity is still going down the drain. Focus is the true superpower. Deep work, minimizing interruptions, small hacks like noise-canceling headphones, and focusing on real output over busywork will improve your dev speed more than any fancy new tech. focusing on real output over busywork 22. You will never fully catch up with everything. And that’s okay. 22. You will never fully catch up with everything. And that’s okay. It’s tempting to try to know every new JavaScript framework or every new Docker-like tool. But there’s simply too much out there. Once you accept that, you can focus on learning the fundamentals and the big-picture concepts that apply across technologies. Being able to adapt quickly to new tools and understanding the fundamentals is far more valuable than memorizing every corner of the ecosystem. 23. Seniority isn’t about knowing more—it’s about making better trade-offs. 23. Seniority isn’t about knowing more—it’s about making better trade-offs. A senior developer isn’t someone who can recite every array method in 15 languages; it’s the person who knows which problems are worth solving. Senior devs say no to unnecessary features, push back on unrealistic deadlines, and avoid over-engineering. They’re the ones who understand the cost of adding complexity—and they’re comfortable advocating simpler solutions. It’s about making the right trade-offs and knowing which problems are worth solving. making the right trade-offs which problems are worth solving. 24. Debugging is a skill. Logging is an art. 24. Debugging is a skill. Logging is an art. Yes, debugging means hunting down the cause of a bug. But experienced devs know that proper logging can prevent a hunt in the first place. A single well-placed log statement can save you hours of guesswork. Log the right things (not just everything). Use structured logs, not random print statements. Make logs actionable—timestamps, correlation IDs, and useful context. Learn to use tools that process and search through logs fast. A single well-placed log statement can save you hours of guesswork. Log the right things (not just everything). the right things Use structured logs , not random print statements. structured logs Make logs actionable —timestamps, correlation IDs, and useful context. actionable Learn to use tools that process and search through logs fast. If your log files read like a jumbled mess, you’re making life harder for yourself (and your teammates). Logging is an area that is most often completely overlooked by developers and considered the least important, rather than being treated as one of the key elements in improving software quality. 25. Senior devs make the team better, not just themselves. 25. Senior devs make the team better, not just themselves. Early in your career, you might think a “senior” is the one who solo-crushes every difficult task. But real seniority is about enabling the entire team to thrive. Your job is to unblock others, not just yourself. Hoarding knowledge makes you a bottleneck, not a genius. Mentorship is crucial—if your team isn’t growing, you’re failing. Your job is to unblock others, not just yourself. Hoarding knowledge makes you a bottleneck, not a genius. Mentorship is crucial—if your team isn’t growing, you’re failing. A senior dev who invests in mentorship, documentation, and automation elevates the whole group. And in 10 years? I’ll probably look back at this post and laugh at today-me, too. That’s the job—constant change, constant growth, and a dash of self-deprecation. What’s your biggest dev mindset shift? Let me know below. I’d love to see how your perspective has evolved over time. What’s your biggest dev mindset shift?