In my recent post, What is Tech Debt? I try to break down what "Tech Debt" means in modern software development. To me, tech debt is simply any work that seeks to benefit the long-term health of your software product but has been deferred until a later date.
Tech debt is a word that gets thrown around a lot in modern software development. If you're a software engineer, you might have a pretty good idea already about what tech debt really means. If you're not an engineer, you might just think it's a word that we tend to use when we want to be really convincing that a set of tasks should get done.
I’ve recently come to the realization that I can’t work towards all my goals and achieve the progress that I need. When you’re actively trying to make progress on too many goals, it makes it harder to get to your milestones. You’re spread too thin. When you can’t complete milestones, you quickly lose the drive to work on anything. Before long, you’ll give up. But it doesn’t have to be that way.
Software Development can be hard on its own, but when your own development environment doesn’t work for you it makes it even harder.
I’ve been writing Python for some time now, and when I reflect on some of the older code I’ve written… I sometimes cringe. For example, when I was just starting out, I wrote this Sudoku game in python (available on GitHub here). I thought that this was one of my better pieces of work at the time. It turns out I can’t even clone and run this because I didn’t add a setup.py or requirements.txt file, a mistake I would never make today!
Today I was doing some programming, trying to finish up an old project that was 80% done, but I never finished. The project is an API for sharing beer ingredient data, being the avid homebrewer that I am. I was in the middle of writing some pretty simple authentication logic, when I found a weird bug in my code. The code, featured below, was pretty straightforward, or so I thought.
Unless your web application is 100% client-side code, you should split it into a backend API and a frontend client. Too often people fall into the trap of believing that because they need a “quick” turnaround they shouldn’t spend the time developing a separate API and client-side app, or they believe that their application is small enough that they can get by without doing this.
