DEV Community: George

Technologies Change

George — Sun, 23 Jun 2024 11:00:05 +0000

I still remember dabbling with my father's first computer in the mid-90s when I was around 7 or 8 years old. Back then, the computer "unit" took up the space of a small desk, and the big CRT monitor was placed on top of the unit.

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

Opinions After 20 Years of Software Development

George — Wed, 12 Jun 2024 10:43:14 +0000

Inspired by other articles I've read about various developers' opinions on software.

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.

On Writing Good Code

George — Sat, 01 Jun 2024 12:39:21 +0000

Over the years I have realized that delivered code is light-years better than beautiful but useless code. This of course is not to belittle the "code artists" I look up to who have the mental capability to deliver "JIT code" that is also clean, beautiful, and reads like a good novel.

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.

A Brief History of JavaScript Frameworks

George — Fri, 29 Dec 2023 10:37:47 +0000

This article is inspired by Fireship's short video on web development.

youtube.com

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 of Node.js was its 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.

About Logging

George — Sat, 21 Oct 2023 15:51:11 +0000

This blog post will be about the DOs and DON'Ts of code logging I picked up along the way in my coding career.

I don't have to emphasize the importance of logging, if you think that logging is not important at all, you should stop reading now. 😀

First off, the DOs and DON'Ts

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.

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.

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?
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.
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.
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.
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.

Conclusion

There you have it. My thoughts on the "art and science" of logging.

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?

Software Outsourcing Part 2: Myths and Truths

George — Fri, 04 Aug 2023 06:52:06 +0000

This article was originally published on https://primalskill.blog/software-outsourcing-part-2-myths-and-truths

For Part 1 see: https://primalskill.blog/software-outsourcing-part-1-types-pros-and-cons

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.

The Black Box of Software Development

George — Sun, 18 Sep 2022 10:29:26 +0000

Think of software development as a box.

Now, this box is transparent at the start, but as you develop the application this box will get darker and darker.

Initially, you can see inside the transparent box, you can see all the code bits and pieces that keep the box together.

A new task was assigned to a developer who starts working on it right away putting the implemented code in the box. The box gets darker. Then another bit of code by another developer is put inside the box and the box, yet again, gets darker.

Every new code from tasks, iterations, phases, or sprints, however you want to call it, will make this box ever so slightly darker up to the point when this box is completely black.

Developers can't see the contents of the black box, they don't know what's going on inside anymore. They have no idea what's keeping the box together.

A team's job is not to let the box become completely black.

What prevents the box to be completely black?

It's well-defined specifications. It's good tests, be it unit tests, integration, or end-to-end. It's also sane task deadlines, and a well-spent time in and around development reviews. It's refactoring stale code.

Finally, it's team energy of overcoming the hurdles of a complex project and creating a solid architectural base for this imaginary box.

Remember, good code is just a side-effect of all of the above.

Image credit: Thorn Yang on Pexels.

Stay tuned and if you liked this post, please share it and comment on it below.

I Challenged Myself to Create an App in Less Than 24 Hours

George — Fri, 22 Apr 2022 07:29:44 +0000

So I challenged myself to see if I can create an app from idea all the way to production in less than 24 hours.

Here it is! https://breathe.so

I had the idea of this app in mind for quite some time now. I implemented it in ~16,5 hours, from typing the first letter of the source code to desinging, deploying it to production, configuring the server and redirecting the domain.

About the app

The app is about mental health and breathing. Mental health is important, I do breathing exercises almost daily and this app will help me, and hopefully others, to work on it even more.

Currently there are two exercises called "Calm Down" and "Focus".

Calm Down - it's a box type breathing exercise with 4 sec of breath in -> 4 sec hold -> 4 sec breathe out -> 4 sec hold.
Focus - it's a in/out type of exercise with 6 sec breathe in -> 6 sec breathe out.

I'm planning on adding more features if interest is high enough.

Software Outsourcing: Types, Pros and Cons

George — Mon, 17 Jan 2022 09:02:10 +0000

This article was originally published on https://primalskill.blog/software-outsourcing-part-1-types-pros-and-cons

In 2004 I started working as a freelance software developer doing mostly outsourcing work for foreign clients. More than 17 years later I'm the founder of a software development company called Primal Skill with my partner having a dedicated team doing software outsourcing.

Only now I just realized that I haven't addressed software outsourcing in a blog post, specifically what blockers our clients had when we first started working together.

In this article, I will talk about what software outsourcing means, what types of outsourcing strategies are most common and what are the pros and cons of each.

In part 2, I will dispel some of the myths and shed light on some of the truths of software development outsourcing I learned along the way.

First, let's define what is software development outsourcing and let's look at the various forms of it.

What Is Software Outsourcing?

Simply put, software development outsourcing means the client delegates some or all software development processes to an outside party instead of keeping it in-house.

It's up to the business to decide how much to keep in-house and how much, if not all, to outsource to various parties. A business can choose to outsource software development only, keeping design, maintenance, and system administration in-house.

The primary purpose of outsourcing for most businesses is cutting down costs, which is somewhat a myth and we will see why is that later in part 2 of the article.

Other reasons a business can choose to outsource are getting access to a larger and diversified pool of talent, scaling up the business, and/or covering other geographical locations.

There are differences between outsourcing strategies mainly considering the outsourced work's location:

Off-shore outsourcing means that the outsourced work is being executed in a different country, in a different time zone. For example, a US business outsources to a European company.
Near-shore outsourcing means that outsourcing happens usually in a neighboring or close proximity country where the timezone is the same or a couple of hours different and the spoken language is usually the same. For example, a US business outsources work to Canada.
On-shore outsourcing is when the outsourced work remains within the borders of the country, timezone and language are the same as the clients. For example, a US business with HQ in Los Angeles outsources work to San Francisco or New York.

Red: On-shore, yellow: near-shore, blue: off-shore

Types of Software Outsourcing

There are countless ways of dissecting an outsourcing process by either the business or the development agency that does the outsourcing for the business.

The most common are as follows.

Outsourcing to Freelancers

A business decides to outsource software development to one or more freelancers located in other countries and timezones. A freelancer is a sole developer who doesn't work for an agency nor has a team of experts.

This approach is the most cost-effective and easy to set up as there is a lot of supply of freelancers across the Globe.

This strategy is beneficial if the client only wants part of his business outsourced, for example having one or more freelancers for developing the software and a couple of freelancers for maintaining the server architecture where the codebase will be hosted.

A business can also employ a freelancer for highly specific work that needs to be developed and there are no in-house experts to tackle the problem.

The downside of this strategy is that the client will have to manage the individual freelancers and play the part of the project manager or even an engineering lead which can be time-consuming.

Many freelancers work with an hourly rate pricing model, and they are usually working on many different projects.

If the outsourced work is not continuous hiring a freelancer can be the most optimal way of doing work, with a minimum dedicated hours agreement with the freelancer which the client can either fulfill or not.

This pricing model is beneficial for both parties because the freelancer will have a continuous stream of revenue even if work is not filled out for that week or month, and also beneficial for the business that they can retain the same freelancer on a week-to-week or month-to-month basis.

Working With a Software Development Company

This is the most popular form of doing software outsourcing and it is not limited to development. In this strategy the client contracts a software development agency, usually found in another part of the World, for developing and maintaining the software.

How work is executed, is usually, dictated by the outsourcing company, which can decide to employ freelancers, set up a specific team of engineers, or even outsource the whole work to another company.

What the outsourcing company can and can't do is stipulated in the contract and in non-disclosure agreements (NDAs) as well as national and international laws such as GDPR in Europe.

Depending on how the work is set up, the outsourcing company can still decide to rotate individual team members in-house to better optimize their costs and the workflow without input from the client.

The client, in many cases, only communicates with a member from the outsourcing company, who in most cases is a project manager or an engineering team lead and is usually responsible for multiple projects that the outsourcing agency does.

Depending on the outsourcing company services the processes a client can outsource can vary. Some outsourcing companies offer full-service solutions from project alignment to server maintenance while others only a limited but well-defined solutions.

In some cases, the client hires managers who are more aligned with the business and report directly to the client and outsource the rest.

Software development companies have flexible pricing models, ranging from hourly rates to fixed prices models.

For smaller projects, a fixed price model is more beneficial as it can optimize the costs upfront for the entire project or forecast the costs for a project phase.

For larger projects, an hourly rate pricing model is better because it's harder to estimate the whole project scope upfront therefore the client pays for the work that's finished.

Outsourcing to an Agency With a Dedicated Team

This approach is similar to outsourcing to a development company, the only difference is that the client is guaranteed a dedicated team assembled for the duration of the project.

This team is solely responsible for developing the client's project and their time is carved out and locked down for that single project.

The outsourcing agency, in this case too, can decide to rotate team members in-house, or have a contractual agreement that locks down the individual team members for the project.

The client can directly communicate with individual team members, or have a dedicated project manager and/or engineering team lead.

Depending on which parts of the project the client is outsourcing, this strategy usually offers a turnkey solution for the software project, including development, maintenance, platform administration, and on-call support team. It makes sense to the business to outsource all of it.

The pricing model is similar to other strategies, having an hourly rate for the scoped out project phases, both parties can optimize work being done on their ends.

The time-to-market with a dedicated team is also logically faster since the project phases are decided upon by the team and team members are not pulled away on other projects.

Outsourcing Team for Hire

This method got more popular in recent years, where a client outsources the bulk of the development to a dedicated outsourcing team but hires the managers and tech lead (C-level managers) directly and keeps these people in-house.

The client has a contract with the outsourcing company but retains and works with the team directly through the in-house managers. The development company essentially leases out the team or a couple of engineers to the client.

In this scenario, the managers hired by the client and the outsourcing engineers form the project team. The engineers report to the managers and the managers to the client and the development company handles the rest such as offering a space for the engineers, handling administrative costs, and so on. The engineers are still employed by the development company.

This strategy is beneficial for the client because the development team can handle the administrative costs, local taxes, and engineer salaries, while the development company has a constant revenue stream without the headache of managing the team.

It makes sense for large projects to use this method where the client wants to get a closer grip on the outsourced development process.

The pricing model can vary, the parties can set up an hourly rate paid directly to the development company, a fixed rate for a specific project phase, or a hybrid model for various outsourced departments, e.g. development having hourly rate, devops team having fixed price.

Having One or More Outsourced Teams Directly Hired by the Client

This approach entails that the client directly hires a team in a different country to cut down on costs, have a larger pool of talent with experts who are not available in the clients' country.

This team is not employed by an outsourcing company, but by the client directly.

This is the most expensive solution out of all the outsourcing strategies above because the client needs to factor in administrative costs, local taxes as well as team costs, but this solution offers the greatest control and flexibility to the software project that's being outsourced.

The dedicated team can also be located in different countries, in different time zones, and speaking different languages which makes the logistics of this strategy more complex.

This strategy is usually chosen by a business that either wants to offer their software to a specific market at a specific geographic location and has a dedicated team at that location to offer support for the software or wants to scale up the business more rapidly by having access to a greater pool of engineers.

The approach is optimized for large, complex projects with a development run-down measured in years, where continuous development is being done and released to the public.

Decentralized Teams Hired by the Client

This strategy is similar to hiring teams directly by the client one exception being that these teams are spread across the Globe while a single dedicated team (like the previous strategy above) is present in a single location be it off-shore or near-shore.

These teams can be composed of a variety of people freelance designers, devops engineers, managers, etc.

This approach makes sense if the client has an ongoing, long-term project built directly for the end-users or there are multiple variations of the software (e.g. different versions for different locations) or support is necessary on location across the World.

Managers can be located on-shore (e.g. C-level managers), while other teams in mixed off-shore, near-shore or on-shore locations.

The various teams can and should communicate directly with other teams to streamline the whole development workflow.

Some of the teams can even be a 3rd party outsourcing company offering development support or dedicated freelancers hired to do a specific task that needs comprehensive expertise in that field (e.g. AI experts or data scientists).

Which Outsourcing Strategy Is More Optimal for Your Project?

To find out which outsourcing strategy is most beneficial for your project or if outsourcing is good for the project at all, first, you need to create a profile on the project.

1. Are You Technologically Proficient?

A software project is wildly different from other non-technical projects. You need to understand the various parts and phases of a software project.

We had clients who were great business strategists and project managers but lacked technological literacy. They tried to develop their project with freelancers at first but failed then approached a software development company (Us), understood the different strategies employed in a software project, and could create a better strategy for their business.

If you have a software project but lack a deep insight into the development process it's better to outsource the whole project to a development company that will also manage the project for you.

2. Size of the Project

If you have a small project and can't guarantee continuous work for a team, then your best bet will be freelancers.

If the project size will increase over time, it can be passed to a team at a development company that offers proper management for the project offloading this work from your shoulders.

Having an already developed project it will be harder to pass the whole project to a development team. In this case, the best strategy is to either hire freelancers to expand the development team or hire a dedicated team that can be onboarded to the project by your tech leads.

3. Supported Costs

Failing to optimize costs can make or break a software project. Not realizing the true cost of development can result in chaos making a project deadline unmanageable.

Having a good team who can break down the project phases and estimate them with somewhat good accuracy is essential. Remember an estimate is not a guarantee, therefore supporting overrun project costs needs to also be factored in.

Having a dedicated team employed by you comes with additional administrative costs and/or local taxes (e.g. opening a company in the country, hiring company administrators, hiring accountants, etc).

To quickly scale up your business the best strategy is to either hire freelancers in the short- to mid-term or outsource directly to a development company that has the necessary capacity to do this.

4. Team Availability

The nature of the software project will dictate the urgency of development for it. A project where a future event needs to be met such as a web app created for an online conference going live on a fixed date is different from a project that implements new features without a strictly fixed deadline.

Outsourcing teams can run behind a client's time by hours, availability is also determined if a team is dedicated to a project or not. If a team works on multiple outsourcing projects they need to factor in development time for your project's tasks.

These tasks are not implemented immediately, but days or weeks after scoping it out.

If emergency work has to be done on the project, like a serious bug fix or responding to market demand quickly, a freelancer or even an outsourcing team is not usually available at the exact moment.

5. Support and Maintenance

Every software project will need support and maintenance at some point, the question is at which stage of the project's life cycle.

These tasks can be outsourced further to a separate dedicated team that can offer support for customers either on-site or through a support call center.

Development maintenance is usually done by the team who develops the project, but the on-call support and disaster recovery can be outsourced to a separate team that can guarantee 24/7 availability.

All these variables need to be factored in before you decide to outsource the software project.

Hope you liked part 1 of this article. In part 2 I will tackle the myths and truths of software outsourcing.

Stay tuned and if you liked this post, please share it and comment on it below.

Do you read the license of an open-source package you're using?

George — Wed, 12 Jan 2022 11:41:25 +0000

Open-source doesn't necessarily mean it's free to use in all cases. Do you read licenses?

3 Tales of Tricky Statistics

George — Tue, 01 Jun 2021 14:05:35 +0000

Statistics can often be misleading, here's an example. Take the number of billionaires in ten countries:

💰 United States - 585
💰 China - 476
💰 India - 131
💰 Germany - 114
💰 Russia - 98
💰 Hong Kong - 67
💰 Canada - 64
💰 United Kingdom - 54
💰 Brazil - 43
💰 Italy - 42

From this list, we can safely say that the US is clearly leading here, or can we? This number is not showing reality because the underlying comparison, billionaires to nr. of people is different in each country.

Normalizing the basis to compare to, let's say, per million people would be a much better metric because every country on the list above has at least a million citizens.

The list below shows this:

👉 Hong Kong ~8.93
👉 Canada ~1.70
👉 US ~1.6
👉 Germany ~1.37
👉 United Kingdom ~0.81
👉 Italy ~0.69
👉 Russia ~0.67
👉 China ~0.3
👉 Brazil ~0.19
👉 India ~0.09

This list shows a totally different picture. We compared two dimensions normalizing one to the other and calculated the average.

Another case where averaging can be misleading is employee salaries and the national or company-wide average, which is not a very accurate metric simply because if we take five employees in a company with the following salaries:

👶 Employee 1 - 5,000.00 USD / month
👶 Employee 2 - 5,500.00 USD / month
👶 Employee 3 - 6,000.00 USD / month
👶 Employee 4 - 12,000.00 USD / month
👶 Employee 5 - 14,000.00 USD / month

On average we could say that an employee has 8,500.00 USD / month. Employee 1 wouldn't agree.

A better metric would be the median salary, which is considered a more neutral measure and it's 6,000.00 USD / month.

So, next time you interview for a job and the HR person says "Oh yeah, our employees get around X amount of USD per month" you should ask if it's on average or median? 😁

A wonderfully elegant yet horrible metric is lines of code in a codebase. It's wonderful because it's straightforward, it's a number everybody can understand, one project has 100.000 LoC another project has 20.000 LoC, therefore, the former is bigger than the latter.

Yet it's a horrible metric because managers often use it to measure developer productivity.

Why is that? Well, a program can be written in an infinite amount of ways, one developer can write a function in 5 lines another can write it in 25 lines. Which is better?

Also, the process of writing code differs from let's say writing this blog post. A developer can write 1000 lines of code, deleting 300, and modifying the rest to be under 500 LoC.

Or, one project can adhere to one type of coding style another to a different one, for example, the same exact code can be written in four different ways:

Ten lines:

console.log(1);
console.log(2);
console.log(3);
console.log(4);
console.log(5);
console.log(6);
console.log(7);
console.log(8);
console.log(9);
console.log(10);

Three lines:

for ( let i = 0; i < 10; i++ ) {
  console.log(i);
}

Four lines:

for ( let i = 0; i < 10; i++ ) 
{
  console.log(i);
}

One line:

for ( let i = 0; i < 10; i++ ) { console.log(i); }

Using lines of code as a blanket statistic to measure productivity is horrible but if a manager uses this metric, by logic, the developer who wrote it in ten lines is the most productive.

Developer productivity is a really complex metric, there's no single truth, but we can employ a variety of other strategies such as:

The number of bugs QA caught after a feature was implemented.
Effort of feature vs. time of development.
Time and effort of peer reviews.

In the end, WTF/minute is a better metric than LoC. 🙃

Cover photo by charlesdeluvio

This article was originally published on https://primalskill.blog/3-tales-of-tricky-statistics

Please comment and consider sharing this article; and if you have any questions you can contact me here in the comments or on Twitter.

How to Keep Up to Date with Web Development

George — Tue, 12 Jan 2021 10:38:21 +0000

This article was originally published on https://primalskill.blog/how-to-keep-up-to-date-with-web-development

Approaching this behemoth of an industry called web development can be overwhelming at times, everybody had that feeling of missing out on web development, especially the chaos that's happening in the front-end world...

...But just like any other problem, you break it down into smaller pieces. Think of the areas in web development you're lacking knowledge, then look for resources to fill that gap.

You also need to practice learning to be more proficient in it. Have a really good understanding of the basic programming principles first, that drive web development.

Focus on the fundamentals if you think you're lacking knowledge in that area, then build on top of that the new techniques and strategies that interest you.

There's too much noise on the Internet as it is, especially in tech, you need to focus on extracting the signal from the noise. By focusing on the programming principles you're building on top of a solid foundation because programming principles rarely change, it gets re-invented.

OOP is not new, functional programming isn't either, MVC, DRY, KISS, SRP were all invented in the 70s and 80s.

With experience, you'll realize that a solid foundation is key, and the major difference between most web development programming languages is just the syntax only.

You’ll need to have a very narrow set of problems that only a specific programming language can solve, in other cases it truly is just a matter of preference, community adoption and the available resources you have on hand.

If you want to know more about good programming principles, check out my blog post on the 10 books every programmer should read where I cover books presenting these programming principles.

The bottom line is you need to love web development, love programming, then learning will be easy, but if you're a 9 to 5 programmer, not really interested in software, then you're going to have a hard time leveling up to be a better programmer.

This doesn’t mean that you shouldn’t have a life outside work, on the contrary, work-life balance is really important.

You need to invest time and energy every week to learn something new.

Old is New Again

There's no such thing as the wrong approach in web development, it's more like the wrong solution to that set of problems you're trying to solve, and showing off your new programming techniques is usually the wrong solution for the problem. 😃

It's perfectly okay NOT to use the latest and greatest packages, modules, or techniques in your codebase, changing it out every day because something newer and shinier was released is almost always the wrong approach.

It's a much better strategy to use tried and battle-tested code instead, especially because of the dynamic nature of software development.

It's also a fallacy that not using the newest programming language or the latest framework you'll be doing a disservice to your project. You can solve 99% of the problems with any programming language.

Cut out 90% of the news

Get off social media, stop procrastinating, and cut out any distractions while you're working. Practice async, passive information gathering, meaning, not to jump on a new video, blog, or podcast instantly, instead save it for later and keep a schedule for learning new things.

You can organize your streams and feed with a note-taking app, and keep a log of what you've learned on a weekly basis.

You can use apps like Feedly, created for this purpose, to filter the information overload you're being bombarded with daily. They even use an AI assistant that will learn from your habits and will filter out news for you.

Start your own blog

If you want to really get neck-deep in a subject you want to learn, I think, the best way to do it is to write about it. You'll be forced to research the topic in-depth filling the gaps in your knowledge in the process.

Starting a blog is not complicated anymore, with services like Hashnode or DEV it's 5 minutes to create your own blog and start writing.

The benefit of creating a blog on such services is that you will also get a huge audience from the get-go.

Other Tips

*Read source code: * most beginner developers I've met just don't read other developers source code at all. Why? Reading source code should be thought in schools 😁, it's one of the most fundamental things you should do if you're in software development.

Ask yourself this: Do you know what's inside node_modules? Do you know what code a module or package contains?

You can learn awesome techniques, simply by, reading other developer's code, and more importantly, you can vet that code for security exploits, maybe even fix it and create PRs, it's a win-win.

Share and discuss: news, tutorials, and techniques with your friends in tech or your co-workers. It's very important to get feedback on your ideas, programming techniques, and the like.

Get active on forums: it may be counterintuitive, and I personally, don't like to follow a bunch of people on social media, because it usually adds noise to my daily work, but by following a narrow set of topics on Reddit or Twitter can be okay.

Get familiar with Github: look at what's trending on the website, watch releases for repositories you're interested in, or popular repos, just to stay up to date on what direction the industry is pulling right now.

You can also follow topics which gives you an overview of repository and user activities related to that topic, such as data structures or Docker.

Resources

It's important to learn how to learn new things, but also to find the signal in the noise. Here are a couple of resources, that you could use to stay up-to-date with the new info.

Blogs

Find information hubs on the topics you're interested in. Blogs are a great resource for that, subscribe to influential authors' feed, remember RSS? Google tried to kill it, but it's coming back! 😊

Follow tech information hubs, but be vary, the content on these websites can be overwhelming and of lower quality unless it’s a curated feed.

Hashnode - is a good place to find articles organized by topics (e.g. tags), just follow a couple of tags that you're interested in.
Dev.to - same as Hashnode, subscribe to topics of interest and you'll get a timeline with posts from those topics.
Daily.dev - a website where you'll get daily curated programming news.
Hackernoon - another curated news website including everything tech and software.
DZone - a massive news website giving you the highlights and trends in tech.
LinkedIn - as surprising as it sounds, there is a lot of really good content on the website. You can join tech groups or follow hashtags. It evolved a lot in recent years.

Newsletters

Newsletters are an awesome way to get tech-related content that's curated by other developers. Getting a weekly e-mail overview on web development is almost guaranteed that it keeps you in the loop.

JavaScript Weekly - a newsletter of JavaScript articles, news and cool projects.
TLDR - byte sized news for busy techies.
Pony Foo Weekly - really good, curated, weekly news on web development.
Frontend Focus - a once-weekly roundup of the best front-end news, articles, and tutorials. HTML, CSS, WebGL, Canvas, browser tech, and more.
React Status - a weekly roundup of the latest React and React Native links and tutorials.
Changelog Weekly - an editorialized take on this week in open source and software development.

Podcasts

Podcasts are a great resource where experts give their opinion on web development, it's great if you can listen to it in the background while you're working. If you like podcasts you can subscribe to these ones:

Syntax FM - specifically created for web developers.
Stack Overflow Podcast - gives you the news in tech right now.
Changelog Podcasts - a collection of podcasts on various tech topics, such as JavaScript, Startups, AI, Go, Brain Science.
Codepen Radio - did you knew Codepen has a podcast? 😊
Full Stack Radio - a podcast for web developers interested in creating great software.
Front End Happy Hour - thoughtful discussions on front-end web development.
ShopTalk Show - web design and development-related discussions.
Devmode.fm - podcast dedicated to modern web development.

YouTube

If you want to watch videos instead of reading or listening to podcasts, check out these channels on YouTube. I like to subscribe to smaller upcoming channels, I find that they give more hands-on information than the bigger channels, can't relate to devs working at companies with thousands of co-workers, they have a very specific set of problems they're solving.

Web Dev Simplified - quality videos on web development, mostly front-end JavaScript, React, and more.
Dev Ed - fun videos on web development, design, tools, etc.
Jack Herrington - full-stack web development videos.
Fireship - coding tutorials related to web development.
Traversy Media - programming tutorial videos.
LearnCode.academy - 100% free web development tutorials, web site design tutorials and more.
RealThoughCandy - Real-world, hands-on web development tutorials, tips & tricks.
codeSTACKr - web development tutorials in HTML, CSS, JavaScript, Python, and PHP.
Computerphile - videos on all things related to computers.
Google Developers - up to date news on Chrome and software development at Google.

Educational Websites

Educational websites are also a great way to level up on web development. You can look at the trending or what's hot sections on these websites to get the best courses on the topics you're interested in.

Even though these services are not free, it's worth the investment, because you'll get a reviewed, well-thought-out video course covering the topic from A to Z.

Books

Books can offer great value if you want to either learn new web development techniques or just simply staying up to date with the industry.

Look for best sellers on Amazon or Goodreads, and check out my blog post on the 10 books every programmer should read.

Amazon Best Sellers on Web Development & Design
Amazon Best Sellers on Computer & Technology - root category for best sellers related to computer and technology in general.
Goodreads Web Development Books
Goodreads Web Development Lists - lists put together by other software engineers.

Remember, fight the urge of FOMO!

Also, please comment and consider sharing this article; and if you have any questions you can contact me here in the comments or on Twitter.