We’re living through a fascinating time in software development. AI coding assistants like Claude Code, Codex CLI, and GitHub Copilot have become powerful tools that can generate code, explain complex algorithms, and even debug issues.
I’ve watched developers embrace these tools with varying degrees of success, and there’s a clear pattern emerging: the developers who truly benefit from AI are the ones who already know how to code well.
There’s a dangerous narrative floating around that we’re approaching the end of programming as we know it.
Look, I’ve built on a few different blockchains over the years, and I’ll be straight with you: most of them are a pain in the backside. Gas fees that’ll bankrupt you, smart contracts that feel like you’re programming with your hands tied behind your back, and consensus mechanisms that move slower than bureaucracy. But then there’s Hive, and it’s a completely different beast.
Hive is hands down the easiest blockchain to build applications on. Not because it holds your hand or abstracts away complexity, but because it gets out of your way and lets you actually build things. Here’s why it’s become my go-to platform for blockchain development.
Neural DSP is a company that produces guitar and bass plugins, mostly known for their Archetype plugins such as Archetype: Gojira or Archetype: Nolly. They also have the Quad Cortex amp modeller hardware device.
Recently, the thought of an NDSP preset file viewer entered my mind. Instead of opening up the xml preset files in plugins, being able to read the settings in a separate standalone app of some kind.
It’s been well over a decade since I started my journey as a front-end developer. I’ve worked on numerous projects, built and maintained websites, and developed applications. I have numerous open-source projects and am on the Aurelia Javascript framework core team. Over the years, I’ve gained experience and learned a lot of things, but there are still times when I feel like I don’t know what I’m doing.
I know I’m not alone in this. As developers, we face a lot of challenges, big and small. From dealing with complex algorithms to fixing simple bugs, obstacles always exist. But despite my experience, I still get caught up in stupid bugs, struggle to install and configure packages and spend hours stuck on things that ultimately have simple solutions.
There are more methodologies than you can shake a stick at. All promise to streamline your workflow and deliver quality software, many of which leverage the same old approach to work: estimation and timelines.
I am not saying that timelines need to be replaced entirely. Because they are a necessary evil. However, in my experience, most companies putting deadlines on features and projects use arbitrary figures, not for a valid reason.
I am an avid reader of Medium, and it’s no secret that the quality of Medium articles has gone downhill over the last couple of years. Clickbait articles are intentionally titled and written to garner a response but lack substance. Amongst the shining gems, is a pile of faeces.
One recently caught my eye. An article titled. It’s 2022, Please Don’t Just Use “console.log” Anymore.
You are probably already rolling your eyes at the title without even reading the article.
In recent years, there has been an explosion of front-end development frameworks and libraries. While this has made development more manageable and efficient, it has also led developers to become increasingly reliant on these tools. As a result, when something goes wrong with the library or framework, it can be difficult to determine the source of the problem and fix it.
You can cross your fingers and hope someone in a comment on a GitHub issue has a workaround or there is a pull request with a fix. But, I’ve seen how fragile the front-end ecosystem can be when a single library lags behind the updates of other packages it depends on and things can quickly fall apart.
When I started as a developer, the term front-end developer was almost nonexistent. Let me pull up my old man socks while I regale you with stories of a simple time in web development when Node.js wasn’t even in the womb yet, and Microsoft was not the open-source friendly company they are today.
It used to be a badge of honour to have a W3C validation badge on your website. Developers used to spend ridiculous amounts of time getting their sites compliant with XHTML/HTML as per the spec. I am talking about alt tags, proper semantic use of HTML elements, putting widths on images, everything.
I love GitHub Actions. They are so simple and powerful, allowing you to have your code deployment and source code in one location.
I manage and deploy all of my sites using SSH (because it’s more secure), and over the years, I’ve adopted numerous deployment strategies. I adopted a Git strategy not too long ago where my server would pull down changes from Git, but it’s a flawed approach.
Here is an actual GitHub Actions build file I use for a project. It’s a mixture of Node.js and WordPress. If your needs are not as complicated, your file will resemble a fraction of this.
A large majority of developers love dark mode. And for years, GitHub (the developer platform of choice for source control) has noticeably been devoid of dark mode. Which is kind of ironic, considering it’s the popular choice.
There are third party scripts and ways of making GitHub dark, but a native dark mode is always best. Admittedly, I’m not motivated enough to go installing some third party creation (especially if the slightest change can break it).