codingismycraft

The market is rapidly commoditizing the "wrapper layer" of developers who just chain APIs together. When the hype settles and the industry becomes a game of performance, efficiency, and margins, the real demand will be for systems architects with mechanical sympathy who actually know how to build the engine rather than just drive the car.

I spent 3 days working on a web app that AI could have "vibe coded" in minutes.

To see if it was better to use vibe coding and agentic tools, I asked the models themselves if my manual effort was a waste of time. Their answers—and the case for a Design-First approach in the age of Agentic AI—might surprise you.

https://codingismycraft.blog/index.php/2026/04/30/spent-3-da...

Postman just announced its March 2026 updates, and it’s a massive change and deviation from its original purpose as an API testing and documentation tool. I think this is a good example of Vendor lockin (for its users) and feature creep for Postman itself.

https://codingismycraft.blog/index.php/2026/02/05/postman-fr...

Some people are trying to turn Neovim into a VS Code clone with file trees, popups, and flashy icons.

To me, this defeats the whole purpose (If you need a "total package" just use an IDE)

The magic of Vim is its simplicity—it’s just you and your code

Don’t Let Your Code Fall Apart!

Rushing Into coding usually leads to Disaster.. Planning and Smart Design Can Help You Build Rock-Solid, Future-Proof Software.

I believe that features like variadic friends, advanced template metaprogramming techniques (including concepts and ranges), and even constructs like coroutines and lambdas with auto return type add layers of complexity to C++. While these modern features can be powerful, they often contribute to an increasingly steep learning curve and may sometimes obfuscate rather than clarify the code. Instead of chasing developers away with such intricate additions, the language would benefit from focusing on practical enhancements that address everyday challenges. For instance, incorporating built-in package management or native support for common data formats like XML and JSON would provide real, tangible benefits. These kinds of improvements could help modernize C++ without overwhelming developers with complexity.

Despite the benefits of Python's flexibility, the language's approach contrasts with C++ and Java’s emphasis on consistent object-oriented principles and backward compatibility. The Perl 6 saga serves as a cautionary tale of the consequences when compatibility is ignored. Striking a balance between innovation and stability is crucial for future-proof software development.

Human expertise, developed through rigorous study and practical experience, cannot be replaced by AI. While AI can serve as a valuable assistant, it should not be viewed as a substitute for deep, acquired knowledge and mastery.

Your analogy of a 'cows not producing plastic bottles of milk with neat little labels' beautifully illustrates the effort, thought, and skill that goes into programming and developing websites. Your dedication and passion for your work is genuinely commendable. Thanks for sharing this enlightening perspective!

This blog post explores the potential drawbacks of overusing SQLAlchemy, a popular SQL toolkit and Object-Relational Mapping (ORM) system amongst Python developers. It discusses how over-reliance on SQLAlchemy can lead to violations of object-oriented principles, cause potential security risks, and introduce complexities in handling object states and session management. The post urges developers to carefully consider their tool choices, factoring in aspects like performance, maintainability, and security, as this can greatly impact the success of their projects.

An attempt to simplify as much as possible the logic behind Linear regression and Least Squares applied to one dependent and one independent variable.

Mnemic is about tracing and profiling applications. The current version is focused on python but other any other language supporting asynchronous programming can be used.

Except very trivial cases, any piece of software contains bugs that need to be fixed needs to add features based on new user stories and also must to adopt to the constantly evolving hardware. Linux is a perfect example of this constantly evolving and never finished paradigm and if anything it can be used not to support but to invalidate the "finish your program" philosophy.

Great software projects are never finished; instead they always evolve and improved similarly to living organisms and unsimilar to material things.

I completely disagree with your analogy to a carpenter who builds a chair, this metaphor is wrong and responsible for a lot of misunderstandings when it comes to software development.

I agree that the classification of a new feature or anything that has to do with the presentation layer is not exclusively a developer's choice.

More than this though, assuming that the stakeholder has a clear decision about issues related to UX (as your spelling error you are referring as an example)it is up to the senior developer to decide about the deployment readiness of the platform. As an analogy you can think of the distinct responsibilities of an architect vs a civil engineer in the construction of a building.

>> I disagree with the given metaphor of TDD as scientifically falsifiable. TDD >> posits the answers first, and builds a theory around it. As new answers/unit >> tests are put into place, the theory/program becomes more complicated.

The software development process starts with the definition of the problem and its desired answer. The code is a finite state box that claims that it meets the expectation of receiving the problem and return the answer while the purpose of testing is to verify this claim.

>> To address that point more directly, "testing" is much more than TDD. I >> believe after-the-fact tests are more akin to tests for falsifiability than >> TDD is.

I agree. Still, these after-the-fact tests belong in the infinite universe of tests that they were not identified originaly and can now become part of the testing suite. What distincts a good from a bad tester, is his ability to minimize the need for these "after-the-fact tests".