Think back to the last time you looked at an unfamiliar block of code. Did you immediately understand what it was doing? If not, you’re not alone – many software developers, including myself, find it challenging to grasp unfamiliar code quickly…
Many years ago, I took part in the development of a taxi-hailing mobile app that is still widely used today. I don’t know what kind of code they’re running now, but in those early days, the driver assignment code –if I remember it correctly– was similar in spirit to the grossly simplified example that follows. There are five levels of nested if statements in less than 30 lines of code. It doesn’t look so bad, some might say, but it’s not difficult to imagine how complicated this code can become with just a few more checks…
When writing code, you can call any function as long as it’s public, and similarly, you can access any object’s public properties or methods. Usually, access to code is all or none – a piece of code can be either public or private. Lately, I’ve been thinking about ways to implement more fine-grained access controls and have looked to the networking world for inspiration…
I started programming in GW-BASIC on an IBM PC clone running MS-DOS. Back then, many so-called home and business computers came bundled with a BASIC interpreter, mostly made by or licensed from Microsoft. They all looked similar. You were greeted by a screen with a READY or OK prompt and a blinking cursor waiting for your input. The “screen editor” and interpreter were all in one in the true sense of the word – they weren’t bolted together like the separate text editors and interpreters/compilers we use these days…
Recently, I had a conversation with a junior developer on my team. Let’s call him Alan. We were talking about a new notification feature that was going to be used to send reminder e-mails to potentially thousands of people if they had forgotten to enter certain data in the last month or so. Alan was confident that the code he’d written was correct. “I’ve tested it well.”, he said…
Linux comes with all the basic tools necessary to deploy an application to development and production environments, and to roll back to any past version if something goes wrong. It takes just a few commands to set everything up…
In the beginning, there was only HTML. The first official HTML specification focused on semantic markup. There were minimal styling tags and attributes. It was up to the web browser how to render the markup in an HTML document. The whole specification was refreshingly simple. You could easily read it in one sitting…
In a relational database, foreign keys are normally used to associate records stored in different tables, but wouldn’t it be nice to define relationships dynamically without having to add extra columns or tables? And while we’re at it, how about having sparse relationships by associating a record directly with any other record like “post X was last edited by user #123” or “post X was flagged for review by user #456” (who happens to be a moderator)?
The great majority of the software architectures currently in use are variations of the layered architecture, and what really sets them apart is the implementation details. Some might find this statement controversial, but in my experience, most software applications rely on code organized in layers to manage complexity. Some of the layers may utilize message queues or microservices, but that doesn’t necessarily make the architecture event or microservices based…
Over the past two decades, I’ve worked as a software developer, tech lead, and CTO at various startups, including my own. I’ve accumulated a number of principles I use to make major technical decisions. Most of the principles outlined here were learned the hard way. You might not fully agree with all of the principles, but I hope at least some of them could help those who struggle with tough technical decisions…
