DEV Community: Primal Skill

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

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.

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.

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.

10 Books Every Programmer Should Read

George — Fri, 08 Jan 2021 13:01:35 +0000

This article was originally published on https://primalskill.blog/10-books-every-programmer-should-read

Due to the dynamic nature of software development, we as programmers can be sometimes overwhelmed by the sheer amount of information we're being bombarded with on a daily basis.

Even though we can take programming to a multitude of avenues there still are some "general truths" in programming that every developer should learn and practice.

The following list of books covers a wide range of areas in programming (and not just) that, practiced, can be implemented in a multitude of programming languages.

0. Mythical Man-Month: Essays on Software Engineering

Author: Frederick P. Brooks Jr.

Get it here.

It is a timeless classic on the software development management process. It is a must-read, not just for programmers, but all the people working in this industry, including clients.

This book shattered the myth of putting more people on a project will be finished more quickly. It is absolutely false, you simply can't finish a project more quickly by simply using more developers, in fact, the opposite will be true.

1. The Pragmatic Programmer: Your Journey to Mastery

Authors: Andrew Hunt, David Thomas

Get it here.

This book should be on the shelf of every beginner software developer, even though most of the ideas presented in the book are sort of "common sense" for most programmers, it still helps to reiterate these ideas.

It's one of the best non-technical software development books, it presents ideas such as taking ownership of our code, fighting code rot, applying the "broken window" theory to software, and so on.

2. The Art of Computer Programming

Author: Donald Knuth

Get it here.

Another classic, and possibly the most influential book in computer science. Donald Knuth truly raises software development to an art form.

The Art of Computer Programming is a collection of books covering everything a developer should know about computer programming, starting from how math applies to computers, algorithms, floating-point calculations, data structures, and much much more.

3. Algorithms

Author: Jeff Erickson

Get it here.

Just like blood running through our veins, algorithms are the lifeblood of computer programs.

The author presents this complex topic in a clear and simple manner, it covers techniques most other books on the same topic ignore. If you want to master this field, going back to basics is sometimes necessary.

4. Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages

Author: Bruce Tate

Get it here.

The Pragmatic Programmer book above in the list recommends learning a new programming language every year, to be truly dedicated to the craft. The author of this book demonstrates as the title suggests, seven programming languages in seven weeks.

It achieves to broaden the reader's perspective of programming by striking correlations between the different programming languages, showing the reader the pros and cons of each.

The languages presented in this book are Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby.

5. Refactoring: Improving the Design of Existing Code, 2nd Edition

Author: Martin Fowler

Get it here.

Business expectations and project features sometimes change, dependencies are always being updated, and inevitably code rot happens.

Refactoring code should be part of every development process, it's inevitable after a while and that's just the reality of programming. The author shows us clear strategies we can take on our codebase, presents the principles of refactoring, how to recognize code smells, and much more.

6. Code Complete: A Practical Handbook of Software Construction, 2nd Edition

Author: Steve McConnell

Get it here.

Talking about code smells, this book takes it to another level. You can find every type of bad practice and "what not to do" in this book, and more importantly "how to do it right".

This book focuses on the process of software construction and everything relating to it like software architecture and design decisions, debugging, testing, code smells, and more.

7. Clean Code: A Handbook of Agile Software Craftsmanship

Author: Robert C. Martin

Get it here.

This book is widely popular in the software developer community, and it's for a good reason. The author, also known as Uncle Bob, shows us that the practice of writing code is a very complicated process.

Writing good code is truly an art, this book presents clear and concise strategies a programmer should take to "get to the next level", methods such as, how good OOP principles look like in action, classes are not just containers for procedural code, there's a reason behind every design pattern, and so on.

8. Domain-Driven Design: Tackling Complexity in the Heart of Software

Author: Eric Evans

Get it here.

If you want to take the practice of designing good software to a whole other level, this book is for you.

The author focuses on the topic of domain modeling, how to actually implement those models, normalizing the domain across all parts of the project, having a clear cut line between various entities, etc.

9. Why We Sleep: Unlocking the Power of Sleep and Dreams

Author: Matthew Walker, PhD

Get it here.

If you want to do a favor for your personal health then read this book. It's one of the more eye-opening books you can read and it's worth every second of your time.

This book manages to change the general idea of living a healthy life. In the past, the priority was diet, exercise, and sleep. Today this order changed to diet, sleep, exercise, thanks to this book.

We, as humans, not just programmers, should put our health as the number one priority.

Bonus: The Phoenix Project

Author: Gene Kim

Get it here

An entertaining read on the concepts, the struggles, and the problems of DevOps. The characters in the book are fictionalized, but their doings are oh so real for system administrators living it on a daily basis.

How to Create Flexible JavaScript APIs with Functional Options

George — Mon, 04 Jan 2021 12:22:37 +0000

This article was originally published on https://primalskill.blog/how-to-create-flexible-javascript-apis-with-functional-options

The methods presented in this article were popularized by Dave Cheney, Rob Pike, and Márk Sági-Kazár. This article presents how to adapt these methods to JavaScript.

Functional Options is a term used in the Go developer community and was created to explicitly describe and set an API's configuration options.

Go is a statically typed programming language, while pure JavaScript is not, therefore not every functional options method can be converted to JavaScript, nonetheless, it still offers a good way of defining an application API configurations.

Traditional way of passing arguments

Let's look at the "traditional" way of setting up default configuration options for a method. Say we develop a conference meet application and we have the following function for creating a new meet.

function CreateMeet(name, startDateTime) {
   console.log(name, startDateTime)
}

We initialize the function above like so.

CreateMeet('Meeting', new Date())

From a developer perspective, it's not really obvious what arguments the function expects without looking at the function's signature. Also, this is a trivial example, but if the function has complex initialization arguments, not just JavaScript primitives, it falls short very quickly.

Not to mention that it makes our function inflexible for modification, adding a new argument would mean we need to modify all the CreateMeet() function calls in our code, or worse, we easily introduce backward-incompatible changes in our JavaScript module.

Passing an object literal

Thinking about the problem differently, we could modify the function signature and use an options object literal to pass our options to the function.

function CreateMeet(options) {
   console.log(options.name, options.startDateTime);
}

This fails horribly because if we pass an object other than what CreateMeet expects or if we’re not passing anything at all. Without proper validation, executing the function will throw an error.

One fix we could do is to define some sensible defaults and merge our options with the default options.

function CreateMeet(options) {
  const defaultOptions = {
    name: 'No Name',
    startDateTime: new Date()
  }

  options = {
    ...defaultOptions,
    ...options
  }
}

Again, without validating options we could merge a totally unrelated object literal with defaultOptions.

Nonetheless, it is a good way of making sure the passed options argument contains all the properties that the function might need and this solution is enough most of the time, but it's not the CreateMeet function's job to make sure the options are correct.

Another problem with the solution above is that it's not very reusable in a complex application, where the options are maybe defined in other parts of the code, consider how we would execute this function:

CreateMeet({
  name: 'My Meet',
  startDateTime: new Date(2021,0,6,13,15,0,0)
})

This type of configuration initialization falls short if we have many configuration options that our function does not necessarily care about, and if we want to validate for correct values too; or if we want to define required options.

Passing in variables and object literals

One could argue we could write something like this where the name is explicitly defined...

function CreateMeet(name, options) {
  ...
}

...but then we circled back to our original problem where every function argument was explicitly defined making it inflexible for future modifications.

Passing in variadic variables

An alternative solution we could implement is using variadic function arguments.

function CreateMeet(...options) {
  console.log(options)
}

With this approach, ...options becomes an array of JavaScript primitive types, but we would still need to validate each individual option item in the array to make sure the correct option is passed to our function.

Passing in variadic functions

Variadic function arguments to the rescue! In this solution we could just pass in functions for ...options and to make sure that we only accept functions as arguments.

function CreateMeet(...options) {
  options.forEach((opt) => {
    if ( typeof opt !== 'function' ) { return }
    ...
  })
}

In the function above if the ...options item is not of type function it will continue to iterate to the next item.

Okay, but what's the purpose of this? Well, we could pass in our specific options literal to the option functions that are passed as arguments which in turn validate and modify our options literal, and removing this concern from our CreateMeet function.

Consider the following option function that would be passed to CreateMeet.

function Name(value) {
  return (options) => {
    options.name = value
  }
}

So what's happening here? The Name is an "option function" which, in turn, returns a function accepting our options literal from CreateMeet. Let's modify CreateMeet to understand it more clearly.

function CreateMeet(...options) {
  let config = {
    name: '',
    startDateTime: null
  }

  options.forEach((opt) => {
    if ( typeof opt !== 'function' ) { return }
    opt(config)   
  })

Executing CreateMeet would look like this.

CreateMeet(
  Name('My Meet')
)

Passing in Name as an argument, which, remember, returns a function, and this returned function from Name would be executed in CreateMeet with opt(config) where config is our configuration object literal that we actually care about.

Let's define a startDateTime function option to better understand this method.

function StartDateTime(year, month, date, hour, minute) {
  return (options) => {
    // We don't care about defining seconds and milliseconds so we pass 0 to new Date()
    // In JS month starts at 0, but we would like to define 1 - 12 (January through December), this is why we subtract 1.
    // Also, proper validation is in order, this is just a simple example
    month = (month - 1 <= 0) ? 0 : month - 1
    options.startDateTime = new Date(year, month, date, hour, minute, 0, 0)
  }
}

Passing in these function arguments to CreateMeet would look like this.

CreateMeet(
  Name('My Meet'),
  StartDateTime(2021, 1, 6, 13, 15)
)

This makes our function much more readable to other developers, we instantly know that CreateMeet is executed by defining a Name and StartDateTime.

Furthermore, we could extract the initialization of the options altogether from CreateMeet into a separate function such as this, which not necessarily need to be exported.

function setupConfig(...options) {
  let config = {
    name: '',
    startDateTime: null
  }

  options.forEach((opt) => {
    if ( typeof opt !== 'function' ) { return }
    opt(config)   
  })

  return config
}

Now, CreateMeet would only execute code that it cares about.

function CreateMeet(...options) {
    const config = setupConfig(...options)

    // do something with config
    console.log(config)
}

Extending CreateMeet

Extending our CreateMeet function becomes trivial with this approach.

Let's say we want to add another option to our function, but still want to ensure backward compatibility. We want to add the option of allowing only specific users, from a list, in the meet, thus executing CreateMeet will handle this scenario correctly.

Our AllowedUsers function option could look like this.

function AllowedUsers(userList) {
  return (options) => {
    options.allowedUsers = userList
  }
}

Passing in this new option function is as easy as adding a new argument to CreateMeet

CreateMeet(
  Name(‘My Meet’),
  StartDateTime(2021,1,6,13,15),
  AllowedUsers([‘john’, ‘jane’])
)

Keep in mind that the public API of our function hasn't changed, the previous examples work the same way with or without AllowedUsers being passed to CreateMeet.

We can go as far as to add different methods to manipulate the same option, in this example, AllowedUsers only accepts a user list and then overwrites the configuration with that list.

Let's say, down the road, in a future version of our application, we'll want to add a function that accepts a single user name only. In this case, we could write a new function like this.

function AllowedUser(userName) {
  return (options) => {
    options.allowedUsers.push(userName)
  }
}

Executing CreateMeet works as expected, end users can use either AllowedUsers (plural) to pass in a user list or AllowedUser (singular) to append a user name to an existing list.

Conclusion

We, as developers, should be very aware of how the public-facing API of our code is being consumed by other users.

This technique helps to keep this API flexible enough for future modifications and it's just another technique in the arsenal of a developer.

Should you use it every time? Probably not, in most cases passing a configuration object literal is enough, but if you have complex configuration setups, want greater flexibility, and also extracting the configuration setup from functions that don't care about it, then this approach is a good fit.

I hope you enjoyed this article, please comment and consider sharing it.

If you have any questions you can contact me here in the comments or on Twitter.

Below you'll find the full example presented in this article as well as a Codepen demo.

Full Example

function Name(value) {
  return (options) => {
    options.name = value
  }
}

function StartDateTime(year, month, date, hour, minute) {
  return (options) => {
    month = (month - 1 <= 0) ? 0 : month - 1
    options.startDateTime = new Date(year, month, date, hour, minute, 0, 0)
  }
}

function AllowedUsers(userList) {
  return (options) => {
    options.allowedUsers = userList
  }
}

function AllowedUser(userName) {
  return (options) => {
    options.allowedUsers.push(userName)
  }
}

function setupConfig(...options) {
  let config = {
    name: '',
    startDateTime: null,
    allowedUsers: []
  }

  options.forEach((opt) => {
    if ( typeof opt !== 'function' ) { return }
    opt(config)   
  })

  return config
}

function CreateMeet(...options) {
    const config = setupConfig(...options)

    // do something with config
    console.log(config)
}

CreateMeet(
  Name('My Meet'),
  StartDateTime(2021, 1, 6, 13, 15)
)

CreateMeet(
  Name('Private Meet'),
  StartDateTime(2020, 1, 6, 14, 0),
  AllowedUsers(['john', 'jane'])
)

CreateMeet(
  Name('One-on-one Meet'),
  StartDateTime(2021, 1, 6, 14, 30),
  AllowedUser('kevin')
)

Codepen Example

Mistakes Were Made [Part 2]

George — Sat, 02 Jan 2021 09:34:42 +0000

This article was originally published on primalskill.blog/mistakes-were-made-part-2

If you haven't read the first part of this article please open it in a new tab and read that first.

Mistakes Were Made [Part 1]

Continuing with the second part of this article series, let's look at what mistakes to avoid on the application level.

Application Level Mistakes

Not using version control

Even if you are a sole developer, you should really learn and use version control like Git or Mercurial.

To put it simply, if you're editing more than one file, you should version the code.

A decentralized version control system such as Git has the benefit of making your codebase highly available and has a clear history of file changes which you can reverse, among many many others.

The de-facto code hosting service is Github, but you can also use Gitlab or Bitbucket.

Lazy commit messages

If you work in a team and use version control (see the mistake above) it's essential to work on improving collaboration and communication at every step of the development process.

One of the mistakes I see new developers (or new to the team) make is using version control as their own personal code repo disregarding other team members that need to use the same repo and understand each other's code and especially code changes.

These are the commits I'm regularly seeing.

These kinds of commit messages don't tell other team members what has really changed. Team members need to go look at the file changes costing development time and resources, and it doesn't promote good collaboration or reviews either.

Always try to think before you commit, amend commits together if necessary and the changes are related.

Creating good code takes practice, these resources should help writing good commit messages.

Not writing tests

No time for tests, right? Putting the benefits of writing tests in another perspective is that it actually saves development time in the long term.

It may look like that writing tests would take a lot of time, which is somewhat true, but you gain that "lost" time by introducing fewer bugs that take NO time to fix.

Writing tests should definitely be factored into the project estimate and project managers should be educated on the benefits of tests.

There are different types of testing strategies, the most popular being unit testing. Other testing type include functional testing, end-to-end (E2E) testing or integration testing.

Developers often hung up on naming conventions, "what do you call it unit or integration? No! functional tests".

While every type of testing strategy has its pros and cons, my programming experience tells me, and this may be an unpopular opinion, that it really doesn't matter what you call it, unit, integration, functional, or whatever as long as you write some tests at least for the critical parts of your code.

One can write awesome integration tests and useless unit tests and vice-versa.

Not deciding on a unified coding style and standard

No, coding styles are not just about tabs vs spaces.

Working in a team comes with awesome benefits and few sacrifices too, one being a coding style that you may not like.

Using a coding style is important for code longevity and manageability, a new team member can easily be introduced to a project if there is an already well-established style of how things are done.

If you don't know where to start it's best to look at how others do it, no need to re-invent the wheel 😊

Google Style Guide - includes guides from C++ to JavaScript
AirBnB Style Guide - goes in-depth on JavaScript coding styles
Github Style Guide - from branding, design to Ruby and JavaScript guides
PHP-FIG Coding Standards - PHP-FIG has a wide range of coding style and other PHP coding standards
Coding Conventions - a wide array of styles for different programming languages

IDE tools to help you keep your promise to coding standards:

ESLint - helping fix problems in JavaScript
W3C Validator - validating HTML/CSS code
Prettier - an opinionated formatter for front-end code

Cowboy coding

Just look at the code below...

<?php
for ($i=1; $i <= $info['Docs']; $i++) {
?><img src="/prev/<?= alphaID($args['Docs']) ?>/<?= $i ?>?en"
    style="max-width: 100%; max-height: 100%"><br><?php
}

if ($this->app->client['Domain'] == 'example.com') {
    ?><script src="/js/jquery-2.2.3.min.js"></script><?php
} else {
    ?><script src="//ajax.googleapis.com/ajax/libs/jquery/2.2.2/jquery.min.js"></script><?php
}
?>
<script type="text/javascript">
$(window).on("load", function() {
    window.print();
    parent.printLoad();
});
</script>
<?php
$this->log->log([
    'Type' => 'Doc',
    'Action' => 'Print',
    'Relevant' => $info['UUID']
]);
?>

...is this how you want to be remembered? Because if another developer sees this code I'm sure they think of murdering the author.

Cowboy-coding or spaghetti code refers to the erratic nature of developers writing code, disregarding coding styles ("Let's just add this line here..."), development environments ("Let's just add this line here on PRODUCTION...").

The process of writing code is only around 10% of the process of programming the other 90% consists of thinking solutions for solving problems, scheduling tasks, architectural decisions, code review, and audits.

Every developer has to have a management framework in place in which they work and well-defined processes on what to do in different scenarios.

So why do developers do this? Mainly, because of managerial pressures, experience and yes, laziness too, plays a role.

Developers need to learn not to act on the first impulse they have for a specific programming problem but take 10 minutes to really think about the solution they came up with and how well it fits into the overall project structure.

Regarding managerial pressures, I'm sorry to say this, but it's 100% the fault of bad managers. I have yet to meet a client who wants a feature right now disregarding any project management decision that needs to come before you write a single character of code.

Not updating dependencies

Already mentioned in the "Missing maintenance" section of the article, a regular update cycle should be performed on a weekly, bi-weekly, or at least every month.

Front-end development is highly dynamic, popular JavaScript modules (but not limited to) are updated daily and often introducing breaking changes. This is why it's recommended to update the dependencies regularly.

Updating regularly also has the benefit of reducing bugs and security holes. Use the latest package versions whenever possible.

Not using defensive programming

In software development there's this term called "defensive programming" which states, according to Wikipedia:

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety, or security is needed.

It simply states that developers should always create programs that can handle unforeseen scenarios, such as 3rd party services going offline, network requests taking too long, and so on.

What if a web application relies on a 3rd party API service like Twilio which goes offline, would this web application be able to cope with that error?

What if a request takes too long for some reason, would the application just hang or handle the long-running request by implementing a request timeout and returning an error?

If the API returns an error, does the front-end code retries the request or just simply give up showing either an error or not showing anything at all?

These are easy questions with complicated answers and even more complex implementations. Regardless, software developers should always practice defensive programming whenever possible to improve their code.

Not going through a checklist before deployment

Developers often forget to check their code before deployment resulting in bugs and immediate fixes, and re-deployments. 😅

In my opinion, this task should be automated with CI/CD, but that's not always possible or makes sense for small projects so it's best to do it manually.

There are two awesome resources I always use for API and front-end code:

Conclusion

Software development is a highly dynamic field of work, constantly evolving and inventing new ways of creating software applications.

You don't have to be a super developer to be a good developer.

A good developer is consistent first and hard-working second.

These methods presented above are mainly coming from experience. I made the mistakes and wrote them down so you can learn from them and make new mistakes, but not these ones. 😁

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