This is a quick list, a "cheat sheet" if you will, which I will expand on down below.

• DO log your program output to stderr. This is meant for both errors and diagnostics, logs are classified as "diagnostic messages of a program".

• DO ensure the only place you're logging your program output to is stderr, not a file, a DB, or a third-party service.

• DO adhere to structured logs. JSON is the go-to format for a majority, but if you're working with simple logs, logfmt works fine too.

• DO play around with log levels. The default level should be set to INFO in production and DEBUG in development.

• DO NOT log sensitive details such as PII data - stick to using IDs (e.g. user ID).

• DO NOT log and handle an error simultaneously.

The Deep Dive

Logging to stderr

No matter the log level, it should be streamed to stderr. From the docs on stderr it reads like this:

Under normal circumstances every UNIX program has three streams opened for it when it starts up, one for input, one for output, and one for printing diagnostic or error messages.

Logs are diagnostics and are not necessarily meant to be consumed by the end user of the program.

Keep in mind that many production systems do not adhere to this original POSIX standard though, and it's fine as long as the output stream is consistent.

Log to stderr and nowhere else

It's not the job of your program to log to a file, to a database, or to a 3rd party service. You will be making your program more complex if you do.

Of course, there are exceptions, when for example logging to the standard streams is not possible.

In all other cases, let other tools handle that for you, such as a log scraper that will send the logs to a Grafana, Loki, Datadog, etc.

Adhere to structured logging

Structured logs are way easier to process by other machines than by humans, and this is the point exactly.

You don't need to drill down into every log line separately, but to have an aggregate overview of the logs that your program is emitting based on which you can make meaningful decisions.

Use JSON because it is widely used. I haven't encountered a log management service that doesn't support JSON, but if you like other formats, like XML or logfmt, then use those as long as you are consistent. Pick one format and adhere to it.

Log levels

This is a tricky one. Every developer has an opinion on which log levels should be used.

I personally found that most programs do not need more than three levels which are INFO, ERROR, and DEBUG. Not even DEBUG is necessary in most cases.

So let me explain these levels:

• DEBUG: This should be default in development, this level is only enabled in production as a last resort, if everything else fails, which is also a good opportunity to improve on log messages. Usually, metrics and development events are logged on this level.

• INFO: Represents normal operation with sufficient metadata like, "user_id added record into DB", but not as exhaustive as DEBUG. Anything that helps you pinpoint the execution flow of your program.

• ERROR: Usually, indicates an error that cannot be recovered from, e.g. "cannot insert data into the db", and with enough metadata that you can reconstruct the error when debugging.

You don't need these log levels:

• WARNING: these are basically INFO logs with a label attached to it. They are definitely not ERROR logs, but it's something that you should keep an eye on, e.g. "database query took 3 seconds", above the threshold considered normal. It could signal a lot of things out of the ordinary.

• NOTICE, FATAL, ALERT, CRITICAL, etc.: are all just semantics of either INFO or ERROR where a label would suffice, e.g. "INFO alert message alert=true".

Do not log sensitive data

I can't state the obvious. Not one system is 100% hackproof.

Logging sensitive data such as names and OMG, passwords is creating yet another attack vector.

The best way to filter out sensitive data is to have an ETL (Extract-Transform-Load) function execute on the log messages before it is written to the destination stream.

Do not handle errors and log them too

Logging an error means you handled it. You either handle the error or log it if it's an unrecoverable error.

For example, if a database insert fails, the code could retry the query like two more times, that's handling it. If the insert fails every time, the code should log that so somebody can inspect it later on.

If you handle the error (e.g. retry the insert query) and log it too, that log line will be meaningless to whoever is analyzing the logs, because ultimately it wasn't an error that the program couldn't recover from.

The art of writing good logs

Answering a few questions each time you wish to write a log line in your code is a good way to think about whether it's worth writing that log or not.

1. Can the event be reproduced from the logs? If the event, be it a warning or an error, cannot be reproduced just from the logs it's not worth logging. For example, "cannot update table". Which table? Where in the code? What data was used?

2. Are the logs rich with enough metadata to understand what happened? This is why structured logging is so important, that you can attach metadata to each log. Example of a bad log: "fetching data from URL failed", but doesn't include which URL, nor what request variables were sent.

3. Can multiple log lines be correlated? This is most prevalent in Web API services where multiple requests could be happening at the same time, making the log lines intertwined with each other. It is a good practice to attach a so-called "request_id" to individual logs so that you can track down and correlate these logs later on.

4. Is the error clear just by reading the error logs? The example above, "cannot update table", while it is a simple message, it's not clear. It does not help in any way, it can even be considered noise. A better message would be "cannot update table user_photos: user does not have access to group" with metadata such as group_id: 123 and user_id: 456.

5. Is it clear from the log when and where the event occurred? A program execution can take many code paths that could result in the same error. For example, multiple functions can update the same database table. Do you know which code section resulted in an error and do you know when the error occurred? Save a timestamp and the "file:line" location with every log, like: "cannot update table user_photos" metadata t=1697880685 and user_group_photos.php:38 or separate it like filename=user_group_photos.php, line=38.

Individual log lines vs wide events

There has always been a debate on whether log lines or wide events are a better choice.

Every function follows an execution path. The question is do you emit multiple logs along this path or one big one at the end of the execution?

In my experience, generally, individual log lines find their utility in CLI applications, where the execution path is small and clear enough, while web projects or request/response-based applications prefer wide events, enriched with metadata added throughout the execution path resulting in a single log line emitted at the end of the execution path.

Takeaway

It's not just about jotting down what your program is up to but analyzing it so you can make clear decisions about what to improve in your code.

After all, what is a log good for if nobody reads it?

Photo credits: Niklas Jeromin

The three main "themes" of bad specs I saw over the years, that come up repeatedly are the following.

Simplifying specs too much

This is more of the failure to address corner cases and potential pitfalls. The issue is mainly about glossing over complex scenarios or failing to consider the full scope of the feature or the project itself.

For example, specs that state "set up the database engine" without detailing the specific requirements, configs, or integrations needed can result in an implementation that doesn't meet the project's goals.

More often than not a problem solution is indeed simple, but sometimes complex problems require complex solutions and careful scoping.

It's just CRUD

No, it's NOT just CRUD. Stating this is diminishing the problem solution and oversimplifying the complexities involved in creating software. While CRUD operations are fundamental, they often require careful consideration of various factors such as data validation, security, concurrency, and performance.

There is always more to the problem than just simply stating that "It's just CRUD".

The rest are details

Focusing on the main solution is always the right thing to do but glossing over important details because it's not part of the main solution is a huge mistake. Even if those details are not part of the original problem, they need to be explored before scoping out the solution that the problem requires.

Software projects deal with a high level of complexity and unpredictability. Every module almost always depends on other modules and each of these modules is inherently more abstract than we think it is.

Building software is hard.

Cover photo by Mrillustration

My very first interaction with programming was when I opened a random exe file, saw a bunch of weird characters in the editor, and started editing it. To my surprise, the file didn't run anymore, so I edited more and more characters until, at one point, when I executed the file in the CLI, it turned the prompt green.

That was the magic moment for me. After that point, I wanted nothing more than to sit in front of that IBM 80286 all day long and figure out what made that prompt switch to green; and then I discovered DOS BASIC.

Fast forward to the early 2000s, I discovered web development with HTML4, CSS, JavaScript, and PHP v3. This journey continued until around 2010 when Node.js was released. In 2007 I founded my software development company, and then around 2015-ish, I had a client project requirement to be done in ReactJS on the front-end and Go on the back-end; and the rest is history.

Along the way, I used almost all major programming languages in some form or another, either professionally or just as a hobby, ranging from C and Pascal in high school to Ruby, ASP, C#, modern PHP, Java, and the list could go on.

My point is that in all these years, the technologies have changed radically, but more importantly, what remained constant were the general programming principles I learned on my journey.

I wasn't using the same technologies in the 2010s as I was in the 2000s, and I'm not using the same tech now as I was a decade ago. If I had focused only on the technology, I would probably still be stuck in BASIC.

I tell every developer I work with, to learn the general programming principles and they will be fine for the rest of their life.

If you learn technologies instead of programming, you will become obsolete when (and not IF) that technology falls out of trend or is replaced by some AI automation.

A decade ago my tech stack looked totally different than today and in the next ten years it will look radically different I'm 100% sure of it.

Cover photo by seowoo_lee

The problem with these statements is that they are living on the "extremes"; and extremes in programming are the real anti-pattern.

When senior developers talk about utils being bad they refer to util packages that are global to the project. Code that is accessible from everywhere in the code base, can lead to code organizational issues, maintaining or refactoring this code is hard.

Project-level util packages resolve concepts that are too broad for the project. What code do you put inside these packages? String manipulation functions? File handling helpers? Parsing request variables? The list could go on.

Package-level utils, on the other hand, are perfectly fine to write, for example, having some entities/models/structs that describe a product and the util functions that parse or manipulate the name of the product.

Ideally, these utils shouldn't be used outside the package where they were defined, but other internal packages could use these to parse a product's name.

So yes, utility functions are useful if their scope is well defined.

Cover photo by PIRO4D

These opinions formed along the way in my career that I wouldn't always agree with in the past, but that is called learning.

So here's my list in no particular order:

• Have an open mind but also strong opinions: People gather into tribes/camps on everything, like tabs vs. spaces, JS vs. TS, etc. Having an open mind to new things is essential, but also strong opinions on things you know it's working, otherwise you will just drift with the flow.

• There are no terrible programming languages: They were created to solve problems, if you haven't faced that problem it doesn't automatically mean they are bad, it's just not the right one for your particular problem.

• No such thing as right or wrong software: only more or less fitting to the problem context.

• Context switching does more damage than it seems: Let developers develop. If you constantly interrupt them they will be much less performant. This includes setting up calls for every insignificant problem just to have a "face-to-face". 90% of things could be an e-mail or a Slack message.

• Clients will lose focus on the bigger picture: If the project is complex, there will come a time when those client calls are just bikeshedding that will waste everybody's time.

• Not everything is about work: even if you love what you do, you must set up a healthy work-life balance. I love what I do with a passion, but I rarely do work stuff after 5 PM.

• Technologies change: I tell every dev I work with, to learn the general programming principles and they will be fine for the rest of their life. If you learn technologies instead of programming you will become obsolete when, and not if, that technology falls out of trend. 10 years ago my tech. stack looked totally different than today and in the next 10 years, I'm sure it will look radically different.

• No FOMO: It's nice to play with new technologies, but don't base your career on FOMO, like AI is the shiny new thing now, I do use it, and I play around with it, but I'm not jumping in head-first replacing my tech stack and approach to programming.

• Cross the bridge when you get there: Don't write code toward inexistent scenarios. "What ifs" will miss the deadline every time.

• Code is the by-product of programming: Software development is so much more than writing code, learn the other aspects of it. This is why metrics like LoC are useless and an anti-pattern. In my experience, writing code is 20% of the overall work that needs to be done.

• It's human nature to be lazy: A task will always fill out the time that is assigned to it. Lazy programming and coding practices should be nipped in the bud early on with a rather firm stance.

• Becoming bored is the leading cause of leaving a company: when there's no end-sight to a task or a feature communications break down and boredom settles in. At first, devs. will go on auto-pilot and then switch jobs.

• Boring and simple is always the right answer: I would rather work with boring and simple technologies or projects than the new shiny things that don't get the job done or projects that will fade out of relevance very quickly.

• Tooling is important: Good tools that help you and other devs are important. If it's complicated to set up, nobody will use it.

• The more communication "choke points" the worse is the result: If you can talk directly to somebody then do it. The more people in the communication chain the more problems and misunderstandings. It's like the game of Telephone.

• It's a fine balance when asking for help: What I want to hear from a dev is that they exhausted every possible avenue and can't move ahead, and only then ask for help. It's a fine balance because devs could shy away very quickly from asking for help but also it's not productive to hold their hands on every minuscule thing.

• Bet on the human: Treat devs as humans and not "resources" and it will pay off in the long run.

• Technical interviews are almost useless: Nobody can assess technical skills in this industry by doing 1 - 2 rounds of interviews. You could only have "some" idea. I would rather hire the individual with a paid internship for a couple of months to see if they are a good team fit, and this is also true from the developer's perspective. If the expectations are set upfront it's a win-win for everybody and there are no hard feelings if things don't align.

• Processes are not important at the beginning: only when you grow bigger do they become essential.

• Junior devs will not be productive right away: Depending on the onboarding processes, junior devs will need a couple of weeks to a few months before they can become productive on a project or team.

• The world is built on open source: and it's hanging by a thin thread, that if breaks, will burn down this whole circus.

Back then everything had a "responsive" design even though that word was foreign to web developers. We just assumed that if people have 640px widths or 800px widths others most likely have smaller or larger resolution sizes.

Today, we somewhat come full circle with responsive design, though it's not just about pixel width, oh it's much much more. There are so many variables to take into account that I honestly lost track of it all. Display sizes come in all shapes and forms ranging from 320px width up to 5120px wide or more, not to mention pixel density multipliers, image art direction, and so on...

I see a lot of web designers adjusting their design to make it look good only on a handful of pixel widths like the most popular ones being 768px, 1024px, 1280px, ... where they should create web designs that work on all resolutions.

Progressive enhancement should be core to web design as well, targeting the smallest screen size and working your way up to larger sizes, be it using CSS media queries, containers, flexbox, or CSS grids.

Disregard popular resolutions, because I can resize my browser window to 628x1317. Does the design look good on it? The answer should always be yes.

Cover photo byPexels

So what about the rest of us? What can we do to make our code just that tiny bit better for our future selves and colleagues who will maintain it?

I have gathered a few principles, North Stars if you will, to guide me along this journey, and the first is that:

Programs must be written for people to read, and only incidentally for machines to execute. -- Hal Abelson

Even though code will ultimately be interpreted and executed by machines, the code base itself should always be written with humans first in mind.

I have never successfully got my way around in a code base that wasn't readable and the code architecture could easily be reasoned about. There's something beautiful when reading well-written code, the execution path flows in our mind like well-composed music.

A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment. -- Robert C. Martin

There are always two camps of people when we're talking about software, and the idea above is no exception. In the past developers and mentors always told new programmers to have small variable names, functions, and constants.

This, like everything else, in programming is nuanced and can be interpreted in multiple ways. Yes, when variables don't have any meaningful underlying logic behind them and are ephemeral such as a counter variable in a loop, by all means, should have short names.

Anything else should instantly let the reader know what it is about, a function called UpdateProductStatusCode is leaps and bounds better than a function called updProd or upd_prod_st .

Also, the second part of the quote A long descriptive name is better than a long descriptive comment refers to the fact that if a developer has to write a long comment to explain what a function or code block is about is usually a "code smell" to refactor the code. Explaining complex code flows is still encouraged though, I like writing long comments to explain what a function does if the execution path is complicated.

Code is read more than it is written. -- Daniel Roy Greenfeld

I've written more about this concept in this blog post here.

This quote underlines the idea that the majority of developers' time is spent understanding code and only incidentally spending time writing code. I could argue that writing code is just a side effect of thinking deeply about a solution to a very specific software problem.

Don't comment bad code, rewrite it. -- Brian Kernighan

Commenting a badly written piece of code is lazy, but not everybody has the luxury of time to refactor code often, but nonetheless, everybody should strive for it.

Production code is inherently messy and always in need of refactoring, commenting, and explaining why a poorly written function does what it does is always encouraged in my opinion when you don't have the necessary resources to improve it.

In programming, boring and simple is always better than smart and complex. -- Rob Pike

A straightforward and simple solution is always preferable because it is easier to understand, maintain, and debug. Simple code is more accessible to other developers who may need to work on it in the future, reducing the likelihood of introducing bugs or errors.

Complex solutions, while they might seem clever or efficient, can introduce unnecessary complications, making the code harder to read or build on top of. Complex code can become a maintenance burden, as it needs more time to understand.

I will always choose the simple, boring, and battle-tested tech. over the latest and newest shiny thing as I mentioned at the beginning of this article that delivered code is better than beautiful code that misses the deadline.

Cover photo by ronymichaud.

It underlines the idea that a majority of a programmer's time is spent understanding the code, instead of actually writing it. When developers write code they also update a "living documentation" of the project that other developers will have to read and understand.

In a typical project the code "read vs write" ratio is 7:1. Code is read seven times more than it is written. It's logical, if you think about it because usually a piece of code block is written once and then read much more.

Quality code is not only functional but is also easily readable. Always write easy-to-understand code even if nobody will ever read it because most likely a few months from now YOU will be the one who has to read and understand it again.

Remember:

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live. -- Code for the Maintainer

Cover photo by Rostislav Uzunov

Rolling back code in my experience is much harder to do, so why bother with it?

Do you have a bug in production? Roll out a hotfix. Having a new feature that wasn't supposed to be exposed to the users? Roll out an update that disables that feature. In other words, roll forward.

Rolling code backward is hard if you work in a team and a lot of new updates are merged into the main branch, rolling your code back would most likely create inconsistencies and conflicts. It's much easier to create the fix and move forward with updates.

There is a distinction between code under version control and code deployed in production.

Code under version control is not necessarily deployed into production but code in prod. should almost always be rolled back temporarily if you have a serious bug in the code that's blocking users from using your software.

One way of temporarily rolling back production code is to have multiple versions "readily available". In web development that means keeping the most up-to-date version and one version before it.

For smaller projects, this is achievable by not overwriting deployed code in production, but having multiple versions in separate folders and a symlink pointing to the version you want. The symlinked folder is the one that the web server has access to.

Switching versions this way is as easy as changing where the symlink points to.

In the meantime having a hotfix that's "rolled forward" in version control and deploying that when it is ready.

Cover photo by Soner Arkan

No such thing as perfect software.

Software is never truly finished. It's always in a state of constant change and evolution. From improving efficiency, security updates, and enhancing user experience, to fixing inevitable bugs, it never stops changing.

This constant change is not without its challenges though.

Picking the "right" software architecture, for example, is like picking the right battles and then managing the trade-offs. It can almost always be improved mainly because business requirements and specs change.

People always bring up examples trying to reason about software development that everybody can relate to. Examples such as, software is like building a car because everybody can understand what a car is. First, building the wheels, then the engine, and chassis, and finally putting it all together.

But software is not at all built like a car because people know exactly how a car should look and how it should work while in software development there's always a big unknown.

When thinking about a software project and developing it, there are always some elements that were never built before and it's always unique to that particular software project; I'm not talking about implementing a login screen for example but the overall project and how all the various elements should work together.

Developing a feature to work in a particular way is not a guarantee that's how users will use it or if they will use it at all. It's like building a car to be driven on the road, but users would like to fly with it.

The most important property of a program is whether it accomplishes the intention of its user -- Charles Antony Richard Hoare

There's a saying among software developers that in the first iteration of developing a feature you learn about the problem, then in the second iteration you implement the solution, and in the third iteration you improve its performance.

This is why sometimes you "win" by implementing a particular feature and that feature is well aligned with user requirements, and sometimes that feature implementation turns out to be a "trade-off" between expectation and reality that eventually must be aligned to move forward.

For more than a decade now, my approach toward new technology has been to ask this question. Do I have use for it or it's just FOMO?

In most cases, the "tried and tested" tech. stack is just fine, also has the upside that I don't have to learn, or find out the quirks and best practices of this new technology, be it a JavaScript framework, a different database, or even a new programming language, especially if I don't need it.

This, of course, doesn't mean that I don't learn about new technologies. I do, all the time, but first I just wait.

Wait for the community's feedback on it, wait to see if it will squeeze itself into my timeline again and again because if that tech is that groundbreaking and important I will hear about it eventually.

I also like to play with new tech. like Zig or Bun. But it stops right there, on the playground. Maybe, if I can devote enough time, I'll implement a small project with new technologies just to see how it plays with my current understanding of things and what new concepts could I learn by using it.

It's fine to use the tried and tested, in my experience, 99.9% of the projects I came across don't need complex distributed microservices for example, or 30-step CI pipelines.

It's fine because it's reliable, it's battle-tested, and exhaustively scrutinized by others. The lack of scrutinization is one of the major problems with current software development IMO.

Furthermore, established technologies usually have a larger community supporting them, which means a larger resource pool of problem-solving guidelines, tutorials, and solutions.

But here's the kicker: it's not really about the tech., it's about the project. It's easy to get caught up in the flash and excitement of what's new and shiny. But remember tech. is a tool. It’s there to get the job done. Often, the 'old reliables' can do that job just as well, if not better.

Without being afraid to be ridiculed for using the "old and boring", choose the boring but stable instead of the new that doesn't pay the bills.

Cover photo by SatyaPrem

The curse of knowledge is a cognitive bias that occurs when an individual, who is communicating with others, assumes that others have information that is only available to themselves, assuming they all share a background and understanding.

To be more specific, the "curse of knowledge" in software development manifests in teams where team members assume that others have the same background, context, or understanding of software coding problems as they do.

It also manifests in senior software developers when they fail to remember what it was like to be a beginner learning the basics and often forget to convey the problem solution in a more approachable and simple way.

Software developers' knowledge and experience can sometimes act as a curse, leading to a disconnect between them and less experienced programmers.

For instance, while designing a user interface, a developer might assume that users will know how to use it because the developer is already familiar with the UI disregarding the learning curve that it would take for somebody who is a first-time user.

Similarly, during the development of a new feature, there can be miscommunications because of an assumed understanding of how the feature should work.

Overcoming this "curse" requires conscious effort and an awareness of this cognitive bias.

The senior members of the team need to be mindful of the varying skill levels and experiences within the team. It's essential to cultivate a culture of open communication where team members feel comfortable expressing when they don't understand something and asking for clarifications without the fear of being judged as inadequate or inferior.

For example, pairing senior developers with less experienced ones encourages continuous learning and helps onboarding new developers much more easily into a complex project.

In this environment, junior developers can gain insights from their more experienced colleagues' practical applications and consequently avoid potential misunderstandings. It's about creating an atmosphere where everyone acknowledges that everyone else might not be on the same page, fostering patience, and understanding to bridge the knowledge gap.

Don't be afraid to ask for help and never say no to people asking for help.

Cover image by diggeo

JavaScript, The Programming Language

To start the article let me give you a very brief history lesson on JavaScript to understand why modern front-end development looks the way it does.

Netscape Communications Corporation, initially known as Mosaic Communications Corporation, was a pioneering American technology company that developed the first widely-used web browser, Netscape Navigator.

In 1995, Netscape hired Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.

However, within just 10 days of his hiring, Eich had allegedly created a new programming language, initially named Mocha, later renamed LiveScript, and finally called JavaScript.

Contrary to what the name suggests, JavaScript has little to do with the Java programming language. The naming decision was more of a marketing strategy since Java was gaining popularity at that time. In the late 1990s, Netscape attempted to standardize JavaScript through Ecma International, leading to the creation of the ECMAScript standard.

Despite the ups and downs in JavaScript's history, including its battle with Microsoft during the browser wars, more on that below, it has stood the test of time and is now one of the most popular programming languages in the world.

Meanwhile, Netscape was acquired by AOL in 1999 and that was that, the product was discontinued in 2008.

The Great Browser Wars

To understand what mess created that we tried to fix with more mess that we call modern front-end development we have to revert time all the way back to the mid-90s/early 2000s.

You see, back in the early 2000s there wasn't much choice regarding browser flavors. You either used Netscape / Firefox or Microsoft Internet Explorer (IE), the former having the majority of market share in the high 90%.

Safari and macOS (originally called Mac OS X) were just a blip on the radar no developer was taking seriously. I don't remember Safari having more than 0.5% market share in the early 2000s.

Microsoft in the Gates & Ballmer era, but especially in the Gates era, was "very competitive" to say the least, and by "very competitive" I mean they simply annihilated any and all competition.

The Web wasn't any different in Microsoft's eyes. Browsers weren't different from other commercial products, users had to buy these applications and install them on their PC.

Microsoft wanted ALL the market share, so what they did was simply ship their browser, IE, with Windows as the default browser, so when users "opened the Internet" it was IE shining back in their faces.

As a response, Netscape tried to bundle their browser with other software that mainly ISPs provided to their customers, but Microsoft, being a behemoth, pulled the rug under their feet by requiring all 3rd party applications to be bundled with IE instead, making it a "required component for network access on Windows".

Then they did whatever they were feeling like with the scripting languages in IE disregarding any standards other vendors were trying to come up with. It was either Microsoft's way or the highway, they simply did not care about web standards.

If it were for Microsoft, we would all be using IE and VBScript today (even if I consider VBscript to be a more capable scripting language than JS back in the day).

Oh, and they also reverse-engineered Netscape Navigator's scripting language that was JavaScript and called it JScript.

In the end, Microsoft was found guilty of monopolizing the Web browser market and the verdict was that OS and browser must be two separate things and end users must be given the choice of using whatever browser they wanted.

Between VBScript, JScript, and JavaScript, the latter won out simply because developers could use a single scripting language to develop for multiple browsers, but there was a time when a web page would use half-baked JavaScript and VBScript code intermingled in a large HTML mess.

Note: There were also many other scripting languages like PerlScript or ASP. Much like what WebAssembly is trying to solve today so developers can use any programming language on the client side and still be performant and cross-browser compatible.

jQuery Was Born

In the early 2000s, the Web was truly a wild-wild west place. There were many competing standards, and vendors still discovering how to "program" for the Web.

If today's front-end development can be described as complex, back in the day it was chaotic and there weren't many online tutorials to turn to for help.

Because of this, jQuery was created. Its original purpose was to expose a unified, cross-browser compatible API to the developers. You see, before jQuery if, for example, you wanted to listen to JS events you had to program it for at least two different "standards", if not more, to be cross-browser compatible.

The code below is a tiny glimpse into the nightmare called web development circa 2005.

function myEvent() {
  alert('click event');
}

if (elem.addEventlistener) {
  elem.addEventListener("click", myEvent, false);
} else if (elem.attachEvent) {
  elem.attachEvent("onclick", myEvent);
}

jQuery's execution was really good. Having a solid and simple API ironing out cross-browser compatibility issues so the developers don't have to, furthermore pioneering targeting browser features instead of browser user agents was a game changer.

I remember first reading about jQuery on QuirksMode and was completely amazed at how simple was to work with. I only needed a single script tag and boom, there it was, all my problems fixed, with a single line.

It was an instant hit with web developers gaining mass adoption and driving a lot of modern web standards we love and use today. Let's not forget that jQuery still can be considered the most widely used JavaScript framework today even though some say it's mostly thanks to WordPress.

After "fixing" browser JS compatibilities the next step in jQuery's evolution was its plugin system. For the core to remain small, jQuery implemented a plugin system so developers could ship other library code and still use the goodies from jQuery; and what developers mainly created were reusable UI widgets like the famous jQuery Datepicker.

Backbone.js & AngularJS Entered the Chat

Backbone.js, released in 2010, was among the pioneers in bringing structure to client-side web applications and taking baby steps towards single-page applications (SPA).

Some developers would argue that Backbone's more important role was kickstarting the philosophical shift towards front-end development.

Not to take away the fame from the YUI Library which dabbled with the notion already.

Before Backbone.js websites were delivered by a server-side application pushing HTML and CSS to the client-side browser and "progressively" enhancing the UX with JavaScript, hence the term "progressive enhancement".

As websites became more interactive, this necessitated keeping a client-side data model in sync with the server-side model and the DOM. Backbone.js addressed this need with a design built around an MVC-like (Model View Controller) architecture, thus marking a significant milestone in component-based web development.

AngularJS, on the other hand, is the brainchild of Google, first released in 2010, and subsequently, Angular 2+ from 2016 forward (collectively referred to as Angular), is not a library, unlike Backbone.js.

Angular is a full-fledged, "feature-rich" JavaScript framework. It introduced the concept of “directives” (later implemented by Vue), which provided an elegant mechanism to extend the HTML syntax, thus allowing developers to create their custom HTML elements and an important concept in component-based development.

With "directives", Angular enabled the creation of reusable components, a feature that would significantly enhance code maintainability and readability. So said the "marketing brochure".

Ultimately, both Backbone.js and Angular started important conversations in the web development community about creating more efficient, maintainable, and scalable client-side applications, and starting the component-based web development "madness".

Transpiling With CoffeeScript

CoffeeScript's role in the evolution of JS frameworks is mainly attributed to the concept of "transpiling", in other words, the concept of source-to-source compilation; and it was created by the same person who created Backbone.js.

CoffeeScript's answer to developers who hated working with JS at this point and managing all the quirks and intricacies of the language is to create a new language altogether and then transform that language into JavaScript to be able to be used in browsers.

Beyond easier syntax, the advanced features of CoffeeScript, such as destructuring assignments, classes, and array comprehension, have significantly simplified the process of building web components and ultimately these features found their way back into modern JavaScript.

Node.js, JS Goes in the Upside Down

I think that Node.js was the fuel on the slow-burning fire that started the fast-paced development of client-side technologies and the adoption of the many modern JavaScript standards that we have today.

Prior to Node.js, JavaScript was essentially a client-side language used for adding interactivity to web pages. Web developers had little to work with in terms of tooling for JS development, mostly relying on web browsers for runtime execution, and often resorting to manual code minification and concatenation by using other server-side technologies.

The advent of Node.js brought JavaScript to the server-side, enabling developers to execute JavaScript outside the context of a browser.

Even though the original premise (and proof) of Node.js is that JavaScript can be used anywhere, promising a more streamlined web development workflow, optimize code, catch errors, and automate repetitive tasks by using the same programming language on both server- and client-side, in fact, it kickstarted the exact opposite trend. After all, it's not Node's fault how people are using the technology.

Node.js provided a platform for developing such tools, resulting in a rich ecosystem of packages like Grunt, Gulp, Webpack, Babel, and others.

Arguably the second biggest innovation coming out from Node.js was their adopted package manager, NPM, which drastically simplified the installation and distribution of JavaScript libraries and tools.

React & the Descent Into Tooling Madness

Now, we have arrived in full SPA, interactive, rich-web, enhanced to the gills mode web app territory and I believe React needs no introduction.

React, even though it didn't pioneer the complicated ecosystem we have around front-end development today, it sure influenced how we do things the React way™.

With the ever-more need to create highly interactive and performant web applications more and more tooling was created around module-based JavaScript code and the FOMO of tech engineering leads somewhat resulted in what we have today.

My first introduction to React was in 2014-2015 when my team was outsourcing for a Silicon Valley client where the tech leads were fully sold on the early React Flux Architecture.

I remember being adamantly against JSX echoing the larger web development community's voice: "How could any sane developer embed HTML into JavaScript?!".

But there it was, HTML in JS, then CSS in JS, and then as with many things in web development you have to learn to love it. Managing the application state in the browser and then reacting to it is all the rage now.

React started and Vue continued the shift towards JavaScript-centric development by encouraging developers to write everything in JavaScript, including markup language and styles advocating "create once, use it anywhere" components, or at least that was the promise. React took it even further with React Native, the ambitious promise of using everything everywhere, including mobile, and writing it only once.

React also fueled the trend of this front-end feedback loop where more and more tooling and JS modules are created every day to further improve or fix the downsides of major JS frameworks that everybody decided to use not questioning whether it made sense to use the way it was intended to be used.

Note: If you have an hour, go watch the React.js Documentary. Yes, it's good filming and production.

TypeScript & The Botched Type Surgery

Just like CoffeeScript, TypeScript is a source-to-source programming language and not a JS framework, but plays a pivotal role in the evolution of these frameworks.

At least that's what Microsoft and many thousands of developers are advocating.

Don't get me wrong, type safety in a programming language is paramount, but I'm not fully onboard with bolting types on top of a language where dynamic types are intended to be a feature and not a bug.

In this regard, I agree with DHH on the false promises of TypeScript and why it makes sense not to use it in their products.

Before TypeScript came into play, JavaScript was known for its difficulty to manage in large-scale projects, and not just mainly because of the lack of static types. However, the lack of static typing doesn't make the language better and it made debugging and maintaining code increasingly complex as a project grew in size.

TypeScript also offers powerful features like interfaces, enum types, and optional parameters that are absent in JavaScript but can be important to "taming the beast" in more complex JS projects.

Also, TypeScript provides developer tooling that enables more accurate autocompletion, refactoring capabilities, and more (also, autocompletion and lint rules can be set up and just use JSDoc).

But TypeScript is essentially an additional layer on top of JavaScript, introducing a level of complexity and overhead that may not be required or suitable for every project or development team.

Although TypeScript provides a wide range of enhancements, it comes at the cost of needing to learn an entirely new language with its syntax, rules, and best practices. Not to mention figuring out type rules that other JS frameworks have implemented. For smaller projects or teams, this may prove to be a significant deterrence.

TypeScript requires developers to annotate their variables, function returns, and arguments with their types. While this can make code easier to read and debug in large projects, it can slow down development. In other words, the very feature that makes TypeScript awesome in large-scale projects can turn into a horrible nightmare for smaller ones oftentimes reverting back to JavaScript is more productive.

At the end of the day what TypeScript did is to start the conversation of having opt-in static types in JS maturing the language, which is awesome.

Sunshine and Rainbows With Svelte

By now every front-end developer has had it with the JS ecosystem. This is where Svelte enters the picture.

One of the primary problems SvelteJS is trying to solve is the unnecessary bloating that results from the usage of "traditional" frameworks, because by now React, Angular, and even Vue are considered "traditional" and conventional.

Another area that Svelte is trying to amend is the steep learning curve presented by other frameworks and libraries. While frameworks such as React or Angular offer great power and flexibility, they can be overwhelming for beginners due to their complexity. Svelte, in contrast, is developed to be much more intuitive and easy to grasp. With its simpler syntax and less boilerplate code, developers with only a basic understanding of HTML, CSS, and JavaScript can become proficient in using Svelte in a relatively short time.

Svelte can also be considered to be a programming language that compiles HTML-, CSS-, and JS-like code instead of a parser that parses regular HTML/CSS/JS.

If we think about Svelte as a programming language then the code we write is a separate language that happens to look like HTML, CSS, and JS, but it's not. This is why Svelte goes into devDependencies because we don't need any of Svelte's code in production in contrast with React and others.

Typically, with traditional JavaScript frameworks, the client's browser must load the entire JavaScript bundle, parse, compile, and execute it before the user can interact with the application. This process can be slow and negatively impact the user experience, particularly on mobile or slow networks. SvelteJS solves this problem by doing the heavy lifting during the build process.

Svelte, unlike React, is much more opinionated on how to do things which is not necessarily a bad thing. This is most notably can be seen in SvelteKit.

Also, Svelte is one of the major frameworks that started talking about the place of MPAs (multi-page applications) in client-side development. Before that MPAs were considered this antiquated development method that no developer would use, ever (wink, wink).

Still, Svelte tries to shine a beacon of hope in the muddy waters of broken front-end development.

Htmx Deployed to the Front

Okay, we are slowly coming full circle.

If you never heard of htmx I don't blame you. It's a relatively new JS framework (at least its modern iteration), more like a paradigm shift from modern front-end development.

While CoffeeScript, TypeScript, and Svelte all try to fix JavaScript by using something similar to JS, but only the good parts™ then converting the whole thing into JS, the creator of htmx wants to start from scratch by not using JS altogether.

Alright, the above paragraph is not a fact, but it's funny nonetheless.

Htmx essentially lets web developers access AJAX, CSS Transitions, WebSockets, JS Events, and SSEs (server-sent events) directly in HTML without needing to write JavaScript (okay, some JS). It introduces a new approach (okay, it's not entirely new) to enhancing web apps by seamlessly transforming static HTML into dynamic content.

Unlike other heavy JavaScript frameworks, htmx aims to shift the balance of responsibilities, taking a simpler approach to web development. By allowing developers to execute common dynamic UI interactions directly in HTML with its extensive attributes, or some would say directives, it significantly reduces the dependency on JavaScript.

This reaffirms the principle of progressive enhancement in web development, where HTML and CSS handle the foundation and layout, while JavaScript is kept lightweight and used for added interactivity when needed.

What's worse is that htmx is annoyingly simple. It's worse that we had to descend into slow madness to see the light at the end of the front-end development tunnel when there wasn't any tunnel nor pitch-black darkness because the techniques used by htmx were always there, invented by others decades ago.

Through the use of backend languages, developers are allowed to build and modify their applications and keep data and state on the backend where it should be, whilst keeping the UI dynamic and responsive on the frontend where it should be.

Ultimately this is a good thing because young developers will discover the true joys of front-end web development by not using modern JS frameworks at all, and this is not to say that React, Vue, Svelte, and Angular will vanish into thin air anytime soon. Baby steps.

Full-stack devs are back baybieeee...

Notable Exceptions

I know I skipped many notable web technologies such as Alpine, Astro, Babel, Bun, Dojo, EmberJS, Esbuild, ES6, ExtJS, Express, Gatsby, GraphQL, Jamstack, KnockoutJS, Lit, MeteorJS, MERN, MooTools, Next, Nuxt, Parcel, Polymer, Preact, PWAs, Remix, REST, RollupJS, Rome, Ruby on Rails, RxJS, SproutCore, Sass, Skypack, Snowpack, SolidJS, Stencil, Stylex, Vite, Vue, Zig, and others... that all contributed to modern front-end development in some shape or form.

The main reasons are that 1) I can't cover everything, 2) a lot of technologies have overlapping ideas, and finally 3) I'm not that familiar with a lot of these technologies to have a sensible opinion about them.

Here's a question that can easily occupy most of your software team’s next brainstorming session. This phenomenon may be entirely foreign to some or deeply familiar to others – this is called "bikeshedding".

One thing I can almost guarantee you, once you learn what bikeshedding means you will see it everywhere.

Bikeshedding definition

In 1957, C. Northcote Parkinson observed an ironic twist in administrative decision-making that arguably trivial matters often receive disproportionately high levels of attention and debate. In his example, a nuclear plant budget was approved without much ado while choosing materials for assembling an elementary bicycle shed incited extensive discussions.

Borrowing its roots from there, the term "bikeshedding", also called Parkinson's Law of Triviality, pervades modern software teams like wildfire. It refers to unwarranted fascination in discussing minor bugs or deciding on details like color palettes but disregarding other critical aspects such as application design and data architecture.

Basically, a lot of software engineers are concerned about how their project's directory structure looks or whether to use one IDE over the other rather than whether their application solves the actual problem it was created for in the first place.

Why do we fall into this "trap"?

The reason is quite simple and relatable. It happens because it's human nature to gravitate towards simpler problems, where discussions are easy and everyone can have an opinion.

Picking a color scheme or logo design simply seems less daunting than solving complex algorithmic challenges or designing the structural architecture of a software product.

But the trap is that minor details become major distractions, stealing away our focus from critical problem-solving tasks that demand in-depth understanding and expertise. It ignites an avoidant culture pushing us to seek comfort in comprehensible topics rather than diving into intensive, high-impact issues requiring more effort and knowledge.

Pitfalls and possible solutions

When too much time and energy is spent on less important issues, bigger tasks can often get overlooked. This can lead to problems for the software project in various ways:

1. Delivery timelines - spending countless hours debating trivialities have projects scrambling against shrinking deadlines.

2. Technical debt - ignoring more important problems in the project will amount to bigger backlogs and later cause slower systems and buggy solutions.

3. Talent churn rate - struggling sprints to fulfill meaningless targets will disappoint top-level engineers who will most likely move to workplaces where skills matter more than mindless discussions on trivial things.

This is not to say that details don't matter, they do, a lot, but creating balance where a team isn't side-tracked by minor issues becomes crucial.

Defining the main goal, the overall "big picture" of the project, and making sure every team member understands it and does not lose sight of it will optimize the critical development path of the project.

Managers should always set the environment for the team, encouraging open-mindedness, and being willing to engage in subjects beyond one's comfort zones.

Finally, timeboxing should be important when discussing the details of a project. Setting finite time limits on topics will help curb spiraling discussions veering off-topic not just with team members but with the project clients too.

Other fun reads that inspired this article:

1. Poul-Henning Kamp's FreeBSD thread on "bikeshedding", who popularized the term.

2. Parkinson's Law by C. Northcote Parkinson

Acknowledgments

• Article Cover photo by Alex Fu on Pexels.

As a self-titled "senior" software developer, I have found an unexpected source of inspiration and skill development in photography. In this quick blog post, I will share how exploring the art of photography enhanced my abilities and contributed to my growth as a software engineer.

The intersection of my two passions, photography and software engineering, has granted me unique insights into both fields. As a hobby photographer, my creative drive blends seamlessly with the problem-solving nature of software engineering.

Attention to Detail

One of the first notable advantages photography brought into my professional life is my enhanced attention to detail. As a photographer, every photograph requires careful examination of various elements, such as composition, lighting, and subject alignment. Similarly, in software development, paying attention to minute details is crucial to produce code that is efficient, scalable, and bug-free. The meticulousness gained through photography has allowed me to spot errors or potential issues much better in my code.

This meticulousness has facilitated efficient collaboration within development teams as I can swiftly identify and rectify issues. By consistently honing my attention to detail, I have reduced the chances of bugs slipping through the cracks, leading to a more robust and reliable codebase but that also slowed my development down quite a bit.

Stimulating Creativity

Photography is an art that encourages creativity and out-of-the-box thinking. In the pursuit of capturing visually appealing and emotionally engaging photographs, I have honed my imagination and embraced unconventional approaches. This has translated directly into my software development work, enabling me to come up with innovative solutions and generate fresh ideas to tackle complex problems. The composition principles employed in photography, such as the rule of thirds or leading lines, have even influenced my front-end design choices.

By incorporating these visual concepts, I have been able to create user interfaces that not only function well but also captivate users with their aesthetics.

Improving Problem-Solving Skills

Photography often presents unexpected challenges that require quick decision-making and problem-solving skills. For instance, shooting in difficult lighting conditions or capturing fast-moving subjects can be quite demanding. Similarly, in software engineering, projects often encounter unexpected obstacles that need to be overcome promptly.

Thanks to my experience in photography, I am now more adept at rapidly assessing the situation, identifying potential solutions, and adapting my approach accordingly. This skill has proven to be invaluable when faced with urgent bug fixes or resolving critical issues during tight project deadlines.

The constant advancements in technology make adaptability a vital trait for any software engineer. Thanks to photography I can better adapt to various environments and quickly adjust my techniques based on changing conditions. Whether it is adapting to different lighting scenarios or experimenting with new equipment, I have learned to embrace change and apply similar adaptability to software development.

This flexibility allows me to adapt to evolving project requirements, scalability challenges, and changing technologies. It also encourages me to explore new programming languages, frameworks, and methodologies, ensuring I remain up-to-date and versatile in an ever-evolving industry.

I am much more flexible in changing my mind about various programming techniques or feedback from my team and much less set on rigid things because "it was always done that way".

Simplicity & Deconstructing Elements

Programming, much like photography, requires a keen eye for simplicity. Over the years, I have learned that simpler code is often superior to clever code that may seem intricate or convoluted. Just as convoluted compositions fail to convey a clear message in photography, overly complex code decreases readability, maintainability, and team collaboration.

When capturing moments through the lens, the most impactful images often consist of a straightforward composition that leaves no ambiguity in the message being conveyed. Similarly, employing simpler code structures ensures easier debugging, efficient code reviews, and seamless knowledge transfer among team members. Emphasizing a straightforward approach enhances maintainability and reduces the likelihood of introducing bugs.

Enhancing Communication

Photography, at its core, is a visual language that speaks to emotions and conveys messages without the need for words.

In photography, being able to convey a story or emotion through an image requires an understanding of visual language. Similarly, as a software engineer, being able to communicate complex technical concepts to colleagues or stakeholders is vital for successful project execution.

Through photography, I learned how to communicate visually, using images to evoke specific emotions or convey a specific message. I have applied this skill to software development by creating visual diagrams and flowcharts when explaining complicated algorithms or system architectures. This visual approach has significantly improved my ability to engage others and ensure shared understanding, resulting in better collaboration within cross-functional teams.

Conclusion

In my journey of becoming a software engineer, I have discovered that photography goes beyond being just a hobby or a creative outlet. Photography has enriched my professional life by sharpening my attention to detail, stimulating my creativity, enhancing problem-solving skills, improving communication, and fostering adaptability.

Keep experimenting with stuff as you don't know where inspiration might come from.

As a bonus, here are a few photographs that I made.

Corvin's Castle in Transylvania, Romania.

Men fishing in a river.

Men at work.

Studio work with a model.

Studio work with a model.

Studio work with a model.

My team's annual Christmas postcard session.

Many C-level managers tasked with finding cost optimizations within their organization have a fear of outsourcing companies because of their lack of knowledge about outsourcing and hearing many "horror" stories about various companies.

In this article, I will shed light on some of the myths and truths about software outsourcing. Let's start with the myths first as these are the most compelling ones and the biggest blockers for any prospective client to jump on board.

Myth: The software product will be of lower quality

Software outsourcing companies ARE software development companies and the quality of code they produce can vary greatly. A US-based development team, which is usually not outsourcing, can produce code just as badly as a team from Bangladesh.

There's absolutely no basis for this claim, which is more likely an unfounded fear from managers looking into outsourcing.

Myth: You can't get to market quickly by outsourcing the product

It's true that managing a remote team of any kind is more complex than an on-site dedicated one, but getting to market is not dependent on the outsourcing nature or the location of the team.

A well-built team comprised of expert developers can just as easily get a product to market as any other team, the key is to manage expectations correctly.

The perception that outsourcing cannot deliver a fast go-to-market process is a myth that stems from inadequate planning and communication, rather than the intrinsic nature of the outsourcing model.

Through the use of offshore development centers, outsourcing can provide round-the-clock development support, thereby shortening the development cycle, improving product quality, and accelerating time to market.

Myth: Developers will steal your code and idea

The right to the codebase, just as any other asset of a company is dictated by the terms of NDA contracts and intellectual property rights.

Most outsourcing companies, just like any other company, have robust legal frameworks in place, and they respect the intellectual property rights of their clients.

Due diligence needs to be carried out though, background checks of the company, what kind of legal framework the country has for outsourcing where the company is registered.

BUT to build trust and establish a long-term partnership, a professional and well-reputed outsourcing provider relies heavily on its reputation, which means it will keep its clients' code and ideas completely confidential.

Myth: Language barrier of outsourcing teams

It is a common myth that outsourcing software development to a team in another country will result in a significant language barrier.

Many outsourcing companies, including my company, employ English as their primary business language and require their employees to be proficient in it.

Teams also often have a dedicated project manager or team leader who acts as a liaison with the client and ensures effective communication cutting down the unnecessary "communication barriers" between many people.

Myth: Outsourcing will cut down costs

A huge misunderstanding most of our clients make is to think that outsourcing development is dirt cheap and soon realize that development is indeed like any other service, you get what you paid for.

Yes, outsourcing usually will cut down costs, but a key difference between a good outsourcing company and a bad one is that outsourcing to the good one won't cut down costs that much.

20 to 30 percent cost reduction is a fair and also optimistic price point every manager should look for and it could be enough for an organization to jump on the boat.

Truth: Cultural differences in outsourcing

Cultural differences are an undeniable reality. Differences in work ethics, communication styles, and business practices can sometimes lead to misunderstandings and conflicts in the collaboration process.

It's no secret that when outsourcing software development to another country, there will likely be some cultural differences to navigate.

For example, a culture that values direct communication may clash with a more indirect communication style that prioritizes avoiding confrontation.

Truth: Timezone differences of various teams

As most people in the industry know, software outsourcing often involves timezone differences between client companies and their outsourcing partners, as well as other teams involved.

These differences can sometimes make communication and coordination more complicated, as team members may be working during different hours of the day.

Despite these differences, many outsourcing companies are able to accommodate clients by adjusting work hours or scheduling meetings at mutually convenient times.

Also, asynchronous communication tools and project management software can facilitate easy sharing of updates and progress.

Planning is harder, this is true, but there are a boatload of tools to help overcome the differences and successful collaboration can be achieved.

Truth: The talent pool is much larger

One of the most significant advantages of software outsourcing is that it allows clients to tap into a talent pool much more extensive than what they could find locally.

This fact came to light with the early 2023 tech. layoffs. Most companies who laid off tech people did so to optimize their talent pool and most of them re-hired part of them in other locations.

Moreover, outsourcing companies often have highly specialized developers, whose skill sets might be hard to find locally. This opens up opportunities for clients to work with top-tier developers who can deliver high-quality work.

Also, this provides a competitive advantage as it allows businesses to scale their operations quickly and efficiently with access to a sizable pool of talent.

Truth: Skills and costs are more optimized

Deploying an external software development team can be an excellent way to optimize costs and resource management. These expert teams have the capacity to identify opportunities for cost reduction specific to their field and offer tailored solutions to meet the client's needs.

Outsourcing brings a wealth of experience with them when tackling diverse projects. This experience provides adaptability to unique project types and unexpected situations, something an in-house team might not be equipped to handle.

Team scalability is another advantage offered by outsourcing partners that businesses can use to their advantage. Quick resource scaling or reduction depending on project demands makes project management more agile and flexible.

Besides providing technical expertise, external teams commonly offer a vast range of other services that companies can benefit from, including project management, quality assurance, and efficient documentation processes. These can frequently contribute to reduced project times and increased quality, allowing businesses to maximize their returns.

For less money.

Turnkey solutions without micromanaging

Turnkey solutions are excellent options for businesses that prefer to deploy an external team to manage their technology needs without micromanaging. With turnkey solutions, businesses receive an all-encompassing solution, encompassing different technological areas that offer the convenience of having all technological matters centralized and managed by a single partner. With the caveat that businesses need to actively look for this because the sad reality is that most outsourcing companies are "coding sweatshops".

In the context of software outsourcing, businesses need to communicate the broader project goals and ensure that developers are aware of the strategic direction as well as the product needs and limitations. By involving developers in problem-solving discussions, businesses can benefit from the developer's skills while raising their understanding of the strategic needs of a project, which a "turnkey" solution could offer to the client.

Freelances vs Outsourcing Companies

In software outsourcing, businesses have the option to outsource to freelancers or development agencies. While freelancers may lead to reduced costs, the main disadvantage is that clients may be directly responsible for managing the project and its various stages. In contrast, outsourcing to a development agency means that the client has a team to manage the project holistically and the agency is responsible for ensuring quality outcomes.

Outsourcing companies that offer a full package from design to development, production deployment and maintenance are advantageous as they offer a seamless system from beginning to end, ensuring that each stage of the process works together harmoniously.

Working with multiple outsourcing companies, however, can lead to communication challenges as each company may have different practices and methods. This can lead to defects, delays and a lower quality of work.

Breaking up the project by teams working in isolation can cause communication challenges between teams, which ultimately leads to delays and lower project quality. It's crucial for businesses to consider these issues when outsourcing.

In comparison, working with a company that can offer a full range of services from design to deployment and maintenance simplifies the process. By working with a single company, clients can reduce the challenges of fragmented communication and disjointed methods. A one-stop-shop solution provides accountability throughout the project's lifecycle, leading to timely completion, higher-quality outcome, and more predictable costs.

Additionally, post-deployment maintenance and support are more robust as the company has intellectual property rights and proprietary knowledge of the project, meaning any issues that arise after deployment can be handled efficiently.

Estimating the cost, timeline, and resources required for software projects is a crucial aspect of project management. However, it is also one of the most challenging tasks.

Estimating a software project is like predicting the future; it is fraught with uncertainties, unknown variables, and shifting priorities. As a result, it can be challenging to provide accurate software project estimations and we don't bother trying to be 100% accurate. Being in the ballpark is always better than shooting it way off the field by trying to pinpoint the deadlines.

So how do we do it?

One possible solution to these challenges is the PERT algorithm, which stands for Program Evaluation and Review Technique. This algorithm enables project managers to create a range of possible outcomes by analyzing the critical path and calculating optimistic, pessimistic, and most likely estimates for each task. By weighing these estimates, project managers can arrive at a more accurate estimation.

Standard deviation is another formula that we use that measures the variability of a set of data points and shows the amount of deviation from the mean. In the context of software project estimation, the standard deviation provides a way to understand the possible range of outcomes and assess the level of risk involved.

The Monte Carlo simulation uses statistical modeling and simulation to generate a range of possible outcomes. This method involves running multiple simulations of a project using different inputs and parameters to determine the likelihood of various outcomes. The Monte Carlo simulation helps us identify that our assumptions are in the correct and acceptable range.

While the PERT algorithm, standard deviation, and Monte Carlo simulation are valuable tools for software project estimation, they do have limitations. These methods rely on historical data and assumptions, and they cannot account for unforeseeable events that may impact the project. This is why I suggest using it only for simpler project estimations.

Essentially, we estimate the effort it takes for a task to be implemented by using story points and estimating effort instead of duration. After that summing up the totals, calculating PERT and the standard deviation to give us the "estimative" story points for the project.

Finally, converting the story points to development hours, by knowing how much similar projects take on average, then running everything through 5000 Monte Carlo simulations to give us a ballpark estimate with 68-95-99.7 rule-based confidence levels.

It sounds harder than it is. In the link below you'll find the Excel file that takes care of all of this, you just have to estimate the tasks using the story points. Have fun!

The template Excel file: Primal Skill Project Estimate Template

Make sure you download the file and open it in Microsoft Excel for the formulas to function correctly.

We were trying to figure out what technologies or services to use so we are not reinventing the wheel, and while Google gives us specific results one has to know what to query for.

So... we thought to ask the "AI". Here's the conversation with it sprinkled in our thought process too.

Prompt: What would be the architecture for a real-time comment system?

A real-time comment system can be built using several architectures, but the most popular ones are:

1. Client-side rendering architecture: In this architecture, the front-end application is responsible for rendering the comments in real-time. Whenever a new comment is added, the front-end application sends a request to the server to retrieve the new comment, and then the comment is rendered on the web page. This architecture requires the use of technologies like WebSockets, AJAX, and JavaScript frameworks like React, Angular, or Vue.

2. Server-side rendering architecture: In this architecture, the server is responsible for rendering the comments in real-time. Whenever a new comment is added, the server sends the updated HTML to the client, which is then displayed on the web page. This architecture requires the use of technologies like Node.js, Socket.io, and server-side templating engines like Pug or Handlebars.

3. Hybrid architecture: This architecture is a combination of client-side and server-side rendering. In this architecture, the server is responsible for rendering the comments initially, and then the client takes over the rendering process. Whenever a new comment is added, the server sends the updated HTML to the client, and then the client uses JavaScript to update the DOM in real-time. This architecture requires

This wasn't a very helpful response but it gave ChatGPT a context of what we're looking for.

Prompt: Get me a list of backend tech that's used for building realtime comment system.

There are several backend technologies that can be used to build a real-time comment system. Here are some of the most popular ones:

1. Node.js: Node.js is a popular choice for building real-time web applications because of its event-driven architecture and support for WebSockets. It also has a large and active community that provides numerous libraries and frameworks for building real-time applications.

2. Ruby on Rails: Ruby on Rails is a popular web application framework that provides built-in support for WebSockets through the Action Cable library. It's easy to use and has a large and supportive community.

3. Django: Django is a popular Python web application framework that provides support for WebSockets through the Django Channels library. It's a mature and stable framework that's easy to learn and use.

4. Laravel: Laravel is a popular PHP web application framework that provides support for WebSockets through the Laravel Echo library. It's a modern and elegant framework that's easy to learn and use.

5. Firebase: Firebase is a backend-as-a-service platform that provides real-time data synchronization and messaging services. It's easy to use and provides a complete set of tools for building real-time applications.

6. Pusher: Pusher is a hosted service that provides real-time messaging.

This response was more helpful, at least we have a list to choose from, but it's a mixed list like programming languages and messaging services thrown in the same place. So we singled out the "Pusher" service from the list as we felt this was the most relevant from the response.

Prompt: Show me more like what Pusher does.

Sure! Here are some other real-time messaging and synchronization services similar to Pusher:

1. PubNub: PubNub is a real-time messaging and synchronization platform that provides APIs and infrastructure for building real-time applications. It provides support for WebSockets, MQTT, and other communication protocols.

2. SocketCluster: SocketCluster is a scalable real-time messaging and synchronization platform that provides support for WebSockets and other communication protocols. It's built on top of Node.js and provides a flexible and customizable architecture.

3. Ably: Ably is a real-time messaging and synchronization platform that provides APIs and infrastructure for building real-time applications. It provides support for WebSockets, MQTT, and other communication protocols, and has a scalable and reliable architecture.

4. Syncano: Syncano is a backend-as-a-service platform that provides real-time data synchronization and messaging services. It provides support for WebSockets and other communication protocols, and has a flexible and customizable architecture.

5. Pushy: Pushy is a real-time messaging and synchronization platform that provides APIs and infrastructure for building real-time applications. It provides support for WebSockets and other communication protocols, and has a scalable and reliable architecture.

Now we're getting somewhere. Let's see if there are open-source techs too!

Prompt: The same list but with open-source technologies.

Sure, here are some open source real-time messaging and synchronization technologies that you can use to build a real-time comment system:

1. Apache Kafka: Apache Kafka is a distributed streaming platform that provides support for real-time messaging and synchronization. It's a scalable and fault-tolerant technology that can handle high-volume data streams.

2. Apache Pulsar: Apache Pulsar is a distributed messaging and streaming platform that provides support for real-time messaging and synchronization. It's a scalable and flexible technology that can handle both streaming and batch data.

3. Mosquitto: Mosquitto is an open source MQTT broker that provides support for real-time messaging and synchronization. It's a lightweight and easy-to-use technology that's suitable for small to medium-sized projects.

4. SignalR: SignalR is an open source library for building real-time web applications. It provides support for WebSockets and other communication protocols, and has a simple and easy-to-use API.

5. Pushpin: Pushpin is an open source reverse proxy server that provides support for real-time messaging and synchronization. It's designed to handle high-volume traffic and can be used with any backend technology.

We knew about these technologies but it's nice to see a succinct overview of them, especially an overview in the context of a "comment system" architecture.

Prompt: What's the difference between Kafka and pulsar from the previous list?

Both Apache Kafka and Apache Pulsar are distributed messaging and streaming platforms that provide support for real-time messaging and synchronization. However, there are some differences between the two:

1. Architecture: Kafka uses a broker-based architecture, where messages are sent to brokers and stored on disk, while Pulsar uses a brokerless architecture, where messages are stored in memory or offloaded to storage systems like Hadoop or S3.

2. Multi-tenancy: Pulsar provides better support for multi-tenancy, where multiple organizations or applications can share the same messaging system, while Kafka is designed to be used by a single organization or application.

3. Message retention: Pulsar provides better support for message retention, where messages can be retained for a longer period of time, while Kafka has some limitations on message retention.

4. Performance: Both Kafka and Pulsar are designed to handle high-volume, real-time data streams, but Pulsar provides better performance in some scenarios, especially when dealing with large-scale data.

5. Community: Both Kafka and Pulsar have large and active communities, but Kafka has been around longer and has a more established ecosystem of tools and integrations. Pulsar is a newer technology but is gaining popularity rapidly.

Prompt: Give me more comparisons

Sure, here are some more comparisons between Kafka and Pulsar:

1. Protocol support: Kafka supports only the Kafka protocol, while Pulsar supports multiple protocols, including Kafka, MQTT, and a custom protocol called Pulsar Native.

2. Security: Both Kafka and Pulsar provide support for security features like SSL and authentication, but Pulsar provides more fine-grained access control and authentication options.

3. Geo-replication: Pulsar provides built-in support for geo-replication, where data can be replicated across multiple data centers, while Kafka requires external tools and configurations to achieve the same.

4. Schema management: Pulsar provides built-in support for schema management, where data can be serialized and deserialized using a schema, while Kafka requires external tools for schema management.

5. Operational ease: Pulsar provides better operational ease, with features like automatic partition reassignment and easier configuration management, while Kafka requires more manual intervention for these tasks.

6. Commercial support: Both Kafka and Pulsar have commercial support offerings, but Kafka has a more established ecosystem of vendors and service providers. However, Pulsar is gaining popularity rapidly and is being adopted by several large organizations.

Now we tried to use ChatGPT as a "software technology" consultant.

Prompt: Can Pulsar be used with gRPC?

Yes, Apache Pulsar can be used with gRPC (Google Remote Procedure Call), which is a high-performance open-source RPC framework. Pulsar provides a gRPC proxy that can be used to interface with Pulsar using the gRPC protocol.

The Pulsar gRPC proxy acts as a gateway between the gRPC client and the Pulsar broker, translating gRPC requests into Pulsar requests and vice versa. This allows gRPC clients to consume and produce messages from Pulsar topics using the gRPC protocol.

Using gRPC with Pulsar has several benefits, including high performance, low latency, and support for bidirectional streaming. It also provides a type-safe API and supports automatic code generation for client and server stubs.

To use Pulsar with gRPC, you will need to configure the Pulsar gRPC proxy and generate the gRPC client and server stubs using the appropriate tooling. Once this is done, you can use the gRPC API to interact with Pulsar topics and consume or produce messages.

Prompt: What are the downsides of using Pulsar in contrast with Kafka?

While Apache Pulsar is a promising distributed messaging and streaming platform, it also has some downsides compared to Apache Kafka. Here are some of the main downsides to consider:

1. Maturity: While Pulsar has matured considerably since its first release, it is still a relatively new technology compared to Kafka. As a result, it may not have as many integrations, tools, and community support as Kafka.

2. Complexity: Pulsar's brokerless architecture and support for multiple protocols make it a more complex system to manage than Kafka, which has a simpler broker-based architecture. This can result in higher operational complexity and maintenance costs.

3. Learning Curve: Pulsar's advanced features and architecture can make it more challenging to learn and use than Kafka, which has a more straightforward design. This can make it more difficult to onboard new team members or integrate it into existing systems.

4. Performance: While Pulsar provides better performance in some scenarios, Kafka generally provides better performance overall, especially in high-throughput use cases.

5. Ecosystem: While Pulsar has a growing ecosystem of integrations and tools, it may not have as many options as Kafka, which has a large and mature ecosystem.

6. Compatibility: While Pulsar provides support for the Kafka protocol, not all Kafka clients and tools may be fully compatible with Pulsar. This can cause compatibility issues and additional development work to adapt existing Kafka-based systems to use Pulsar.

   Ultimately, the choice between Kafka and Pulsar will depend on your specific use case and requirements. While Pulsar may have some downsides compared to Kafka, it also has several unique features and advantages that may make it a better choice for certain use cases. It's important to evaluate both technologies carefully and choose the one that best meets your needs.

Prompt: Are there any Apache Pulsar Go packages?

Yes, Apache Pulsar has official Go packages that provide a client library for interacting with Pulsar. The Go client library is part of the official Pulsar client library and provides a simple and easy-to-use API for consuming and producing messages from Pulsar topics.

The Go client library supports all of the main Pulsar features, including message acknowledgments, batching, compression, and encryption. It also provides support for message filtering, which allows consumers to subscribe only to messages that match specific criteria.

The Go client library is actively maintained and has a growing community of contributors. It's also well-documented and provides comprehensive examples and tutorials to help developers get started quickly.

In addition to the official Go client library, there are also several third-party packages and tools available for working with Pulsar in Go, including libraries for working with the Pulsar proxy, CLI tools for managing Pulsar clusters, and more.

As we're mostly using Go as our backend technology, we asked it.

Prompt: Are there any real-time comment system implemented using Apache Pulsar or Apache Kafka? Show me a list.

Certainly, here are some real-time comment systems that have been implemented using Apache Pulsar or Apache Kafka:

1. Disqus: Disqus is a popular commenting system that uses Apache Kafka to power its real-time messaging and synchronization capabilities. It uses Kafka to process and deliver comment notifications to users in real-time.

2. Livefyre: Livefyre is a real-time commenting and social engagement platform that uses Apache Kafka for its real-time messaging and synchronization features. It uses Kafka to process and deliver comments, social media mentions, and other user-generated content in real-time.

3. Stream: Stream is a real-time activity feed and commenting platform that uses Apache Kafka to power its real-time messaging and synchronization capabilities. It uses Kafka to process and deliver user-generated content, including comments, likes, and shares.

4. Commento: Commento is a real-time commenting system that uses Apache Pulsar to power its real-time messaging and synchronization capabilities. It uses Pulsar to process and deliver comments in real-time and provides a simple and easy-to-use API for integrating with other systems.

5. Hyperledger Fabric: Hyperledger Fabric is an open-source blockchain platform that uses Apache Kafka for its real-time messaging and synchronization capabilities. It uses Kafka to process and deliver blockchain transaction data in real-time and provide a tamper-proof record of all transactions.

These are just a few examples of real-time comment systems that use Apache Pulsar or Apache Kafka. Both technologies are well-suited to building real-time messaging and synchronization systems and are used by many organizations for a wide range of applications.

We love the history and context that's kept throughout this conversation, it feels more like a brainstorming session than just simply entering search queries.

Prompt: What's the architecture of Disqus using Kafka?

The architecture of Disqus using Kafka is a typical event-driven architecture, where events are generated and propagated by producers and consumed by consumers. Here's an overview of the architecture:

1. Producers: Disqus uses Kafka producers to generate events related to comments, such as new comments, replies, likes, or flags. These events are sent to Kafka brokers for processing and delivery to consumers.

2. Kafka brokers: Kafka brokers are responsible for receiving and storing events produced by the producers. They also manage the distribution of events to the consumers based on their subscription preferences.

3. Consumers: Disqus uses Kafka consumers to consume events from Kafka brokers and process them in real-time. The consumers are responsible for processing the events and updating the relevant data structures, such as comment counts or user profiles.

4. Real-time notification system: Disqus uses a real-time notification system to deliver comment notifications to users in real-time. This system is powered by Kafka and is responsible for processing events related to comments and delivering them to users through various channels, such as email, push notifications, or in-app notifications.

5. Data storage: Disqus uses a combination of databases and caching systems to store comment data and user information. These systems are updated in real-time by the consumers and are used to serve comment threads and user profiles to users.

Overall, the architecture of Disqus using Kafka is designed to provide a scalable and fault-tolerant real-time commenting system that can handle high traffic and deliver notifications to users in real-time.

Prompt: What about Commento?

The architecture of Commento using Apache Pulsar is centered around the Pulsar messaging system and is designed to provide a scalable and fault-tolerant real-time commenting system. Here's an overview of the architecture:

1. Producers: Commento uses Pulsar producers to generate events related to comments, such as new comments, replies, likes, or flags. These events are sent to Pulsar brokers for processing and delivery to consumers.

2. Pulsar brokers: Pulsar brokers are responsible for receiving and storing events produced by the producers. They also manage the distribution of events to the consumers based on their subscription preferences.

3. Consumers: Commento uses Pulsar consumers to consume events from Pulsar brokers and process them in real-time. The consumers are responsible for processing the events and updating the relevant data structures, such as comment counts or user profiles.

4. Real-time notification system: Commento uses a real-time notification system to deliver comment notifications to users in real-time. This system is powered by Pulsar and is responsible for processing events related to comments and delivering them to users through various channels, such as email, push notifications, or in-app notifications.

5. Data storage: Commento uses a combination of databases and caching systems to store comment data and user information. These systems are updated in real-time by the consumers and are used to serve comment threads and user profiles to users.

The Pulsar messaging system provides several benefits for Commento, including high availability, scalability, and fault tolerance. It also provides support for multi-tenancy, which allows Commento to serve multiple clients or organizations from a single Pulsar cluster. Overall, the architecture of Commento using Pulsar is designed to provide a modern, scalable, and real-time commenting system that can handle high traffic and deliver notifications to users in real-time.

... and that's about it.

Conclusion

ChatGPT is becoming a very powerful tool, now we know why Google is shook to its core when version 3.5 was released.

We are excited about what this technology will be capable of in the near future and bare in mind that this chat was processed by v3.5 and not version 4, which was recently released.

Programming is a complex and ever-evolving field, and many assumptions and beliefs about programming can lead to errors and inaccuracies in code. Falsehoods about date and time, phone numbers, and web technologies are just a few examples of common misconceptions that can cause problems in programming. In this blog post, we will explore these and other falsehoods in programming and how to avoid them.

Falsehoods in programming are not limited to specific areas of development but can be found across various aspects of programming, from data types to security measures. These misconceptions can lead to costly mistakes and cause a detrimental impact on the functioning of programs. Therefore, it is crucial to be aware of these falsehoods and take the necessary steps to avoid them while writing code. Let's get into it.

Names are unique

One of the most common falsehoods in programming is that names are unique. This is not always true. Consider the following scenario: you are building a system that allows users to register with their email addresses. You might assume that email addresses are unique, but this is not always the case. People can have multiple email addresses or use different variations of their name. To avoid this mistake, you should use a unique identifier, such as a user ID, to identify users.

Floating-point numbers are precise

Another common falsehood in programming is that floating-point numbers are precise. In reality, floating-point numbers have limited precision and can sometimes result in rounding errors. For example, when you add 0.1 and 0.2, the result should be 0.3, but in some programming languages, the result is actually 0.30000000000000004. To avoid this, you can use decimal or fixed-point numbers which are more precise.

There is one true way to do it

Another common falsehood in programming is that there is only one true way to do things. In reality, there are often multiple ways to solve a problem, and the best solution depends on the context. For example, there are different algorithms for sorting data, and the best algorithm depends on the size and type of data. To avoid this mistake, you should consider different solutions and evaluate them based on performance, readability, and maintainability.

Null is a value

Another common falsehood in programming is that null is a value. In reality, null represents the absence of a value. This can lead to errors when you assume that null is a valid value. For example, if you try to concatenate a null value with a string, you might get a null reference error. To avoid this mistake, you should always check for null values and handle them appropriately.

Time zones are constant

Many programmers assume that time zones are constant and do not change. However, time zones can change due to various reasons such as daylight saving time, political changes, or natural disasters. For example, Samoa skipped a day in 2011 when it moved from the east side of the International Date Line to the west side, causing confusion for programmers who assumed that time zones are constant.

Leap years occur every four years

Another common falsehood about date and time is that leap years occur every four years. In reality, leap years occur every four years except for years that are divisible by 100 but not by 400. This means that the year 2000 was a leap year, but the year 1900 was not. Failing to account for this can result in errors when calculating dates or durations.

Time is always linear

Time is not always linear, especially in cases where time synchronization is required. For example, when synchronizing multiple clocks over a network, there can be delays or inconsistencies that cause time to appear non-linear. This can lead to inconsistencies in the ordering of events or incorrect calculations of durations.

Phone numbers always have a fixed length

Many programmers assume that phone numbers always have a fixed length, but this is not true. Phone numbers can have different lengths, depending on the country or region. Additionally, some countries use different formats, such as including dashes or parentheses. Failing to account for this can result in errors when validating or formatting phone numbers.

Phone numbers are unique identifiers

Another common falsehood about phone numbers is that they are unique identifiers. While phone numbers are unique to a specific device or SIM card, they are not globally unique. For example, a person can have multiple phone numbers or use a different phone number when traveling. This can lead to errors when using phone numbers as identifiers or when verifying user identity.

Phone numbers are secure

Many programmers assume that phone numbers are secure, but they can be easily intercepted or spoofed. For example, someone can use a fake caller ID or send a text message from a different number. Additionally, phone numbers can be used for social engineering attacks or phishing attempts. To avoid this, programmers should use additional verification methods, such as two-factor authentication or biometric identification.

Conclusion

Falsehoods in programming can lead to errors, security vulnerabilities, and performance issues that can have a detrimental impact on software development. From date and time to form validation, there are many misconceptions that programmers should be aware of to avoid these problems. By questioning assumptions, testing thoroughly, and staying up-to-date with best practices, programmers can write better code that is more accurate, efficient, and secure. It is essential to continually learn and improve as a programmer to avoid these common falsehoods and ensure the success of software development projects.

This blog post was written entirely by ChatGPT v3.5 Turbo and it is a proof of concept that good okayish content is not hard to generate by machine learning.

Cover photo by Mo Eid on Pexels.

So the IKEA effect is a cognitive bias where users place a disproportionately high value on stuff they fully or partially made... which makes sense, one can and should be proud of the things they made... unless it's s**.

How does this translate into software engineering?

It's simple really, software developers AND clients too, often tend to invest time, energy, and money into their projects even though there would be other much better alternatives.

There are also multiple forms of the IKEA effect which I quickly list below:

1. Individual effect: It manifests in a way where an individual will devote more resources to get that extra work out of the "experience", be it coding or other tasks.

   For example, a software developer will devote more of his energy to getting that extra work into a piece of code where a 3rd party plugin could have done the job better.

2. Group effect: This bias tends to spread among team members and companies too and it could manifest in multiple ways:

   1. A team could be biased toward creating everything in-house just to have complete control over the whole development process (which of course is a falsehood) wasting valuable resources in the process.

   2. Also, a company could charge more for its product or service to offer that "DIY experience" for its end-users. This is actually what IKEA is doing, hence the name of this bias.

We could also take a look at how this bias unfolds from a client's perspective.

1. The sunk-cost fallacy: Where a client devotes more and more financial resources into their project, where a rewrite of the code-base (which often is a smaller effort to do) would have taken a less financial burden from the start.

   This is also happening because of a flawed view that a rewrite would result in resources lost, but in fact, oftentimes the opposite is true.

   A refactor of a code base doesn't necessarily mean starting from zero, especially in regards to know-how. Given that the same team is assigned the task of a rewrite, they already know where the pain points are in the project, hence the refactor.

2. Control over the project: Where a client wants to keep control of every aspect of the project and the development process because of the false image that this creates.

   "Not invented here" (NIH)... when the client refuses to use 3rd party modules in the project out of fear of security exploits, poorly vetted code, and the lack of control over it.

How to avoid falling into this trap?

First, just acknowledge that this effect exists and it's real and it will manifest in every individual. Be aware of the IKEA effect and always ask yourself: Am I choosing this solution because I invested work in it and it's made by me or is it something else?

Work from the outside in. When you're faced with a problem, explore it, and put in the effort of finding a solution, but don't just jump in head first into solving the problem. Create prototypes of code or tests to validate your idea before actually committing to it. This is also true with teams and this is why an MVP of a project could be very valuable early on in the development phase.

Prototype, validate, measure, rinse and repeat. Always.

Cover image copyright (obviously): https://commons.wikimedia.org/wiki/File:Ikea-logo.png