Forem: Chris Bertrand

Don't believe the hype.

Chris Bertrand — Wed, 08 Jul 2020 22:49:53 +0000

I've been in this industry for over a decade now, and the one thing I've learnt is that you should never believe the hype.

Technologies come and go, things get superceded, things improve. You just need to look at the technologies or frameworks that are no longer with us, such as Flash and those that are now barely used including the myriad of JS solutions we've used. Sure, sometimes you might want to ride the wave, it'll be fun, but you might not be left with much afterwards.

Using what is cemented into the ecosystem and battle tested will mean you don't come across any horrible surprises. You have a myriad of documentation and stack overflow questions answered on the most superfluous of issues. Getting things done is easy, if not always elegant.

Selling you the dream.

Twitter, blog posts and conferences will sell you a reality that in most cases doesn't exist in the corporate world. That's the purpose of those mediums, they are trying to build and audience, create a market, get you interested in what is new. It's basic marketing.

Mircroservices, Macrofrontends, Unit tests, Static code analysis, Best practices, Containers, K8s, Serverless, Cloud, ai, big data, react, go, nosql, sass, PWAs, design systems, automation, agile.

All these things are useful and important in the right circumstances, however if you think your company should be following all of these methodologies then you're being naive. Businesses have objectives and stakeholders to appease. They're not here for us to create the mecca of the technology world. Sure, some big businesses can afford to live the dream, but those are far and few between.

K.I.S.S.

There is nothing wrong with a well organised and structured monolith. In fact for most of us, that's still the best way to go.

All these things have been heralded as the holy grail and yet most businesses are using at most a couple of these idioms.

Our new devs are lambasted with complicated tech stacks, overpriced hosting solutions and preachy beliefs that make all but the most simple hello world application a difficult and unsatisfying proposition.

The Fundamental Fallacy

Rather than looking at problems, we memorize frameworks, syntax and convoluted ways to complete simple tasks.

I'm sick of telling people that you can achieve things in a few lines of JavaScript. There is no need for a complex SPA application written in React/Angular/Vue installing 37 dependencies to make an http request, or fill a simple form.

I'm tired of reading countless blog posts on how to use Gatsby and React to create the most perfect blog site that you can host on Netlify or GitHub pages. If you want to blog, create some content, don't spend 3 months creating a damn blog framework, there are hundreds out there already! Just use one!

The internet and technology has been around for a long time, and people are always pining for what's new. It's understandable, it's new, it's shiny, it's cool. But it's not always necessary. Actually it's very rarely necessary.

Sometimes a few lines of JQuery can do everything you need. Sometimes you don't need 100% code coverage across your codebase. Sometimes you just use WordPress to deploy your blog, and focus on the content you are trying to share.

Sometimes you shouldn't believe the hype.

The Best Way to Improve & Automate your Code Quality!

Chris Bertrand — Tue, 17 Mar 2020 18:22:02 +0000

I was recently on the Front End Podcast (Listen to it here) with Rob Kendall. We discussed something I'm quite passionate about. Making code better! This means how to follow best practices and coding standards we have assigned and how we can do all this quickly, easily and (most importantly) automatically. So what's the secret I hear you ask! What is this magic silver bullet!

The Secret? Use a Linter!

This Static Code Analysis tool is a powerful way to keep your code in line with the latest standards and to keep a shared codebase following a set of chosen principles. We'll run through the what, how and why's explaining how you should go about implementing this solution in your code today.

The term "lint" is derived from the name of the undesirable bits of fibre and fluff found in sheep's wool.

What is it?

Linting is the name for the process of checking your code against a set of pre-determined rules. Whether those are language dependant or specific to your project. Linting will run a program or tool that will analyse the code for potential errors. It will make those warnings or errors clear to you and give you the option to fix them.

Linting tools are especially useful for interpreted languages like JavaScript and Python. These languages lack a compiling phase that would usually throw errors prior to execution, and you can feel a big benefit when using it in these instances.

The Linting Tools Available to use.

So now we know what it is? How can we use it in our project? Surely we need a linter specific to each language! Well, you're right! But luckily, every major language already has linters available for them, and some are even language agnostic.

You can find a detailed list here: https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

A nice curated list from the above would comprise EsLint this is a popular Linter for JavaScript which you may have heard of, or may already be using. SonarQube is a popular language-agnostic option that works from Java to PHP to Python. C# and .Net in general has StyleCop and FxCop which are often used together.

So, you might have heard of some of these already, but what are the benefits of using this, why should you invest your time to add these tools to your solutions?

Some of you may be thinking... what about Prettier? Prettier is not really a linter, as it doesn't check code per se. Prettier is an opinionated code formatter. It saves you time and energy and stops arguments about line length, bracket placement and most importantly, "Tabs vs Spaces".

The best thing is you can tailor it to your needs. It can be run during development or added as a step when committing to your source code repository. It's flexible enough to work around your situation.

Why should I use it?

Everybody wants to write clean code, they want to follow best practices, they want to keep up to date with the latest and greatest ways to create code.

Linting is important to reduce errors and improve the overall quality of your code. It also helps to make your code consistent over time, and across teams and individuals. It's great at catching problematic bits of code early on, and in most cases, lets you know how to fix them! Let's look at the pros and cons.

Linting Strengths.

Linting will flag up any unused variables in your code. Any potentially unreachable bits of code! (Did you test an if statement by changing the logic to a 1 == 1 comparison?) It can also help to find issues with indexing beyond array lengths.

It will catch errors early, we all know the best time to find a bug is during development. The longer a bug is left undetected and unresolved, the costlier it is to fix.

Linting Weaknesses.

Linting can produce a lot of errors and warnings. Sometimes as many as there are lines of source code. This can lead to a lot of false positives and may deter you from fixing what is really important. That's why setting up the rules, to begin with, is crucial.

Linting will identify violations of best practices. It won't teach you those best practices. Developers can use linting to improve their code, but they might not replicate the standards that are advised.

Linting is inexpensive in actual time and cost, but it can decrease developer productivity, as they fix or alter the code to conform to these rules.

How to enforce it?

So this is the tricky bit. As we can see, there are pros and cons to the notion of linting. Do you want to get your product shipped quickly or conforming with best practices that may speed up future work? There is always a trade-off, and this is something to remember.

Do you expect your team to fix all the issues every time they change something? Should they just have to keep what they have changed tidy? Maybe you just want to inform them, hoping they make any relevant changes?

The Happy Medium

What I've found is that some level of linting is useful, especially in unison with a code review process. Having basic things fixed before they go for code review means generic checks are no longer made by the human eye. It also allows us to focus on the important aspects,rather than the subjective.

We should check if we can refactor the code? Whether it would benefit from being split up, either into different files or functions? Is there sufficient documentation? Do we have tests covering important functionality? Is it scalable and secure?

I like to think that we should all follow The Boy Scout Rule - making sure to leave any code we touch code better than we found it, this means we will gradually remove any technical debt without having to do it all at once, or as specific tasks.

Leave your code better than you found it.
The boy scout rule

My JavaScript Setup - The Trifecta

As I mentioned above, JavaScript benefits greatly from the introduction of linting, but as the language is so open, putting in some guidelines is a necessity. Here is the configuration I add to my solution to enforce linting during the development process.

I use 3 external libraries to aid me in my endeavours.

Husky is the easy way to configure Git hooks. For those that do this manually, having it all set in the top-level config, standardises and simplifies the process massively.

The next is Lint Staged. As mentioned before, you want your developers to have a happy medium of what to fix. If they are working on a file, I think we should all follow the Boy Scout Rule, meaning we clean up the code before resubmitting.

Last, but not least. Pretty Quick will run your Prettier settings on all staged files. It's similar to Lint Staged but taking care of the formatting instead.

Install and Configure Packages

So anyway, once you've installed the three packages, you can add the following lines to your package.json. This will lint all your JavaScript and TypeScript files if you're using any, and format your staged files before committing. If the linters throw any errors, we display them to the user and block them from proceeding!

The Configuration - Package.json

The sections above add the tools installed into the Git pipelines. Husky is our middle-man and you can see that in its hooks section the pre-commit hook is configured to run PrettyQuick on our staged files and also the Lint-Staged section afterwards. This runs eslint and tslint on the globs specified, which in this case are all staged .ts and .js files it finds.

Lastly, we must set up the rules, we want to use during this process.

TsLint Config

The important things here are the rule sets we are extending. tslint:latest and tslint-angular are taking care of the fundamentals. We can overwrite any of these base rules below, and I would recommend finding that happy medium for yourself. I have left a couple of rules that make sense for me.

tslint-config-prettier is required so tslint does not format our code, that is Prettiers job and where the prettier config comes into play.

Prettier Config

The best place to put your prettier config is a .pretterrc file. I have shown a simple set of rules to get you started. The Prettier Documentation of Configuration is the best place to look for tailoring the setup to your needs.

The outcome?

Here it is in action. You can see a git commit kicking off husky which in turn runs our tools! First Prettier fixes up any formatting, before eslint changes the let to const as it's never reassigned, and moves our class level declarations to the top of the file! Pretty neat right!

So in conclusion, hopefully, you've understood what linting is, why to use it, and how to adapt it to your coding environment!

I would love to hear of any other setup that works for you! There is always room for improvement. Please share your thoughts below!

Sources and Further Reading

3 Reasons to use a Clipboard Manager

Chris Bertrand — Mon, 25 Nov 2019 22:15:27 +0000

I bet you're reading this because you don't use a clipboard manager.

Some of you may not even know what a clipboard manager is.

In a nutshell, a clipboard manager is a computer program that adds functionality to an operating system's clipboard. Many clipboards provide only one buffer for the "copy and paste" function, and it is overwritten by each new "copy" operation.

Well, a clipboard manager extends this limit, making your items searchable and quicker to retrieve.

Here are the 3 reasons you should use one today.

You copied some data to the clipboard and then accidentally overwrote it. That's no longer a problem, it's still there!
You need to copy a few bits of info from one app to another. Rather than hopping between them, copy them all first then paste them in the order required. Easy.
Do you use several usernames and passwords? You no longer need to keep a spreadsheet with the info to delve into. It's all in your handy clipboard. Now really you should use a password manager, but if they aren't sensitive logins, this works just as well too.

See I told you a clipboard manager is awesome!

There are tonnes of other uses, but I bet you already know what reason you'd use one for, so what are you waiting for, download one today! Most are free so it won't do any harm trying one. They even have mobile versions too. Here are a few I'd recommend.

The one I use on a regular basis and my personal favourite starts us off before I run through Mac, Android and IOS alternatives.

What are your thoughts on clipboard managers? Do you use one already? If you have a personal favourite I'd love to hear it!

Are you using Void correctly?

Chris Bertrand — Tue, 05 Nov 2019 14:51:39 +0000

Vb.Net got something right. Its separation of the trusty function and the subroutine makes perfect sense. Unfortunately, that transition has not made its way to any other recent language. Delphi and Pascal also use this idiom, labelling them Procedures and Functions respectively.

All other languages that omit a value from a method call, return a void type. By default, you will create your function and then decide whether to return something.

Let's look at the purpose of a void function or as I like to refer to them, a subroutine and try to comprehend the utter confusion it can bring.

Is there a correct usage of Void?

Isn't the purpose of a function to return something?

9 times out of 10 a function will return something. Otherwise, it will do something. These two acts should be tangibly different, yet we group them together. This leads to horrific methods that are not pure, do multiple things and mutate global state, all under the watchful eye of Master Void.

Programming has come a long way, yet we stick to this archaic practice that confounds me to this day. Now I'm not against the notion of functions doing something; This is what we want; The issue is the misuse of the void mechanism specifically.

When saving or deleting a record, is it better to return nothing, or should we return the object, boolean or an identifier of the record changed? Is explicitly checking for some value better than wrapping all that code in a try-catch block.

One valid use case is Logging; where information is captured about the application. Another is an entry point like the main function or task runner whose only job is to run a set of functions synchronously.

Why are you using Void?

Let's start with global properties. My ultimate bugbear with void functions is changing global state. It happens far too often. Don't do it!

The key design decision should be whether the function returns something? When creating a function ask yourself:

Does it throw an exception if there is an error?
Does it alter an object or some properties?
Should we wrap code in a try-catch block?
What happens when the function succeeds?

Do we care? Is more information better or worse?

That's down to you, I guess what I'm trying to say is that using void functions can cause confusion. It requires the developer to dig deeper into code because externally the function doesn't disclose any information about its effects.

I believe the only valid use case of a void function is a fire and forget call. So long as it didn't error, you don't care what it did.
Me, hater of the misused void.

A void call shouldn't stop the rest of the code running successfully. It's not required for the rest of the function to do its job.

Are you sure it doesn't do something you want to know about?

This is the first question I as myself when looking at a void function.

It should be yours too!

My aim is not to stop people from using void functions. They are an intrinsic part of how software is developed and consumed, I just urge you to use them when necessary. You wouldn't save a number into a string field.

Don't use void without first thinking about the consequences of doing so.

I'd love to hear your views on this, counter arguments are most welcome!

Coding Concepts - Smart vs Dumb Components

Chris Bertrand — Thu, 25 Jul 2019 14:24:52 +0000

With JavaScript frameworks taking over our front end world, it's important to understand a few key principles that the major three frameworks push. When building a web-based application you'll be tasked with structuring how everything communicates.

Most people will be aware that you should use different components to adhere to S.O.L.I.D principles, avoiding repetition in your application, making changes and additional features quicker and easier to integrate into the current solution. The actual creation and interaction between those components can be seperated in a number of ways but the simplest for me is considering them as Smart or Dumb.

Smart Components

Contains dependencies that are application-specific. Services are injected in the constructor of these containers.

Also known as Controller components or Container components that can:

Manipulate Data
Call out to external resources (libraries, APIs)
Manage State

In essence, these can be thought about as a container, page or section implementing a specific task of the user.

Dumb Components

Recieves data and displays the information.

Also, know as Presentation components or Pure components that can:

Allow for data to be passed in
Display that data in a specific format and style

These can be thought of as where you create the final HTML and CSS for what something will look like on the screen. This is where you style your application and interact with the user.

Interaction

A smart component will contain one or more dumb components within them. The smart components will pass the data they receive down into these presentation components which then render the data as required.

If there is any interaction required between a smart and dumb component then a event will be fired back up to the smart component to deal with.

Purpose

So why do we need to separate our application this way? Well as in any form of programming, following specific paradigms or approaches is not strictly enforced or required to allow and application to function, but will usually have a number of benefits down the line.

Reusability is always heralded as a major benefit to most programming approaches. Following the D.R.Y principle of (Do)Not Repeating Yourself means that you can add the same functionality to different areas quickly and effectively.

Refactoring a part or whole of an application only requires changes in a smaller number of places.

Readability It's easier to read component names to figure out what something does rather than having to dissect reams of HTML!

Running Tests Last but not least, testing smaller self-contained components makes creating and managing your suite of tests easier.

Separating the concerns of your application across these two types of components, in whichever way you want to describe them should make the task of creating a web app in React, Vue or Angular a much nicer and easier process for all those involved.

If you feel differently, as Dan Abramov has recently done then please feel free with sharing your opinions below.

Coding Concepts - Hoisting

Chris Bertrand — Wed, 17 Jul 2019 08:38:20 +0000

Hoisting is the behavior of moving declarations to the top of the current scope. This is the default behavior in JavaScript when using the var keyword but using the new let and const keywords means this does not occur.

Hoisting in Action.

Here we can see that the variable is declared after it's been used, so how does this still work?

How and Why?

Why does JavaScript do this? Hoisting is done during the interpreter's first run through the code. The JavaScript engine was designed in such a way that your code is run twice, the first time it runs through some syntax checking and anything that uses the global object methods. It then does some optimisation to improve performance, which is where hoisting comes in. The second pass is where your code gets run.

Hoisting will move all declarations to the top of the current scope (top of the current file or function).

Initializations are Not Hoisted.

In this example, you can see that when declaring and initialising a variable in the same line the javascript engine does not optimise this block. As such you get an undefined error when trying to access the variable.

Let and Const behave differently

When changing the first example to use the let or const keywords instead of var everything goes belly up. If you open your console window you will spot the JavaScript engine throwing exceptions (I've added images if you can't be bothered 😉 )

You can see nothing is present in the results pane, that's because these new keywords behave differently. The errors below are easy enough to understand, a const needs to be initialised when declared, whereas a let gets checked during the first cycle of the interpreter.

Put your declarations in scope.

Hoisting is pretty cool eh? It's great that JavaScript is so forgiving and allows things like this to work. Equally, it can mean that code works when you're not expecting it to. Going forward, it's probably best to keep all your declarations at the beginning of every scope though! With the introduction and mass adoption of the let and const keywords, it's important to know the differences, and know that simply changing all your vars to lets can cause problems in your application.

What about Functions

Hoisting also applies to function declarations, which is why you can define your function after you call them! However, Function expressions/Anonymous methods do not get hoisted in a similar fashion to let and const. Take a look at this last CodePen, we can see that the variable declarations get hoisted from the bottom, but the anonymous function call does not, which kills the engine throwing errors.

Finally, it's good to know that functions get hoisted before variables! So when refactoring legacy code, remember to look at the scope of all your variables and think about how the interpreter will be parsing the code you are modifying.

The main reason for this is because let and const are block scoped. var on the other hand is not and therefore can be hoisted up to the global context (as long as 'use strict' is not present

James - https://dev.to/jamesthomson

Resources

When to start looking for your next role?

Chris Bertrand — Tue, 02 Jul 2019 19:27:55 +0000

When is the right time to start looking for your next job?

You’ve been at the same place for a one/five/ten years now. Have you progressed? Are you learning anything new? Do you feel undervalued by your current employer either financially or with your efforts not being recognised? What should you do?

Are there any internal vacancies you can apply for? Have you raised any concerns with your boss? Do you feel comfortable doing so?

Have you been keeping an eye out on the market? Is there anything that catches your eye? Do you have a preferred recruiter you can contact?

Are you worried about moving on? Do you like the people you work with? Is the commute decent? There are many factors for staying where you are.

Ultimately the decision is yours.

What do you think?

Code creation, try it!

Chris Bertrand — Tue, 25 Jun 2019 08:48:05 +0000

I think we should consider the option of writing code, that writes code for us! Let me explain why.

We love coding, we try to write as much code as possible. LoC is the ultimate measurement of your awesomeness. 😊 But how many of us write code that creates code for us?

We love using tools/frameworks etc to aid our writing of course, but limit ourselves to writing these tools.

I've recently been looking at Storybook to help automate the creation of a demo app for our UI library. Currently, this is a manual task creating pages and implementing the components and variations needed.

I've been told that it's not difficult and doesn't take very long. My first thought was, well why haven't we automated it then?

But I can sharpen pencils too

Automation seems to have been swallowed by testing. Developers no longer use it as a tool in their arsenal. We’ll happily scaffold using AngularCLI or the alternative! Why not create the scaffolds? Each codebase has a style, and each company does things their own way, so they should create tooling. Let’s end the notion of style guides and lengthy how to’s to follow.

A component has a template and some inputs. You could create a simple config file, be that in JSON, YAML, JavaScript, hell any language you choose that could parse those inputs and create those pages dynamically.

Why do we want to do this ourselves?

Anyone can do this!

This sort of grunt work doesn't give us any satisfaction, but writing a tool to do this for us, packaging, styling and deploying it would be awesome. Maybe it's the inherent difference between a web developer and software engineer? I don't know, I've always thought these titles are interchangeable, is this not the case? Is it that JavaScript is not thought of in this way yet?

Yes, Storybook gives us this functionality, and it seems to do a pretty good job at it too. I just worry that we expect everything built for us these days. We seem to have forgotten that we can build them ourselves, exactly as we want. Lightweight, customisable, geared specifically to our use case. Even if we do not, it's at least worth considering no?

I guess this follows on slightly from Bens Post the other week.

Invest in building custom tools

Ben Halpern ・ Jun 16 '19

#productivity

How many people do this currently? What are the main positives and negatives from this approach? Would you do it again?

The Art of Debugging

Chris Bertrand — Mon, 17 Jun 2019 20:40:24 +0000

As a developer, a major part of your day-to-day responsibilities will entail needing to deal with bugs, finding a problem, replicating it, and fixing it.

It's much easier to write code from scratch, looking through old code, understanding it and making it better is much more of a challenge.

We have tutorials that teach us language best practices, how to use design patterns, dealing with code smells, writing lean, maintainable code; However, this crucial aspect of our duties is often overlooked.

The purpose of this article is not to tell you how to fix your bugs, it's describing the process you will need to go through to find and diagnose the problem.

Filipe Fortes

@fortes

Debugging is like being the detective in a crime movie where you are also the murderer.

00:57 AM - 10 Nov 2013

It's true, occasionally you will have written the code that has caused the bug in question! Time to investigate what went wrong! Now it's simpler if you wrote the code, as you'll know where to look.

But what if you didn't?!

Tip: Your mindset needs to be that of a detective.

How to know where to start?

Yes, this is hard! Someone raises an issue or sends over a screenshot. A stack trace drops into your Inbox! What does this all mean? How can you use this information to determine where the problem originated from?

Let’s look at the steps I would take.

Step 1: Replicate the issue

The first thing you need to do is replicate the error. A LOT of errors that get logged are down to incorrect configuration, network problems or browser related, so this is an integral part of debugging.

Tip: Get all the configuration information you need before starting, and the steps to reproduce!

Trying to fix a problem without replicating the error is a task of futility. Unless you can see it not work, you will never know if the change you make will actually fix it!

Step 2: Find an entry point

With the information you have, try to find a way of using that to get into the code.

Problem: Form Error

Say you have a screenshot of a form with and an error message displayed. How can you use that to get you to where you need to be?

A generic login form error: https://dribbble.com/emmabell

When investigating a problem, there will be two avenues that you will need to inquire of. Is there a problem on the client side either in the JavaScript, CSS or HTML; or the problem is on the server side; the backend code, where your data/database and infrastructure lives.

Step 3: Rule out the possibilities

If you've ever played Guess Who you'll have a good understanding of what I mean. You have your suspects, now it's time to whittle them down!

Tip: It's all about taking a systematic approach.

Here, we'd probably want to start with the client side, as that is our entry point, and where we can inspect how the error. We'd want to verify whether the form is doing the checking within the browser or sending some information to its pals on the other side!

In comes developer tools, known to many as the magic F12 key! Here you can view and access the DOM, the underlying HTML, and JavaScript on the page.

If you've never used Developer Tools before here are two great intros into what's available. Even if you know it, I'd highly recommend this first short video that gives a quick refresher of 12 tricks you may have missed.

A short run through 12 tricks you can use in Chrome Dev Tools

A more detailed, longer run through all the features available.

Tip: Note the Id and CssClass names of the suspected tags and find the files where they are in.

Using this approach will give you an avenue to check what was happening and where to focus your attention on next. Inspecting the tags and elements, extracting the Id and CssClass names will mean that you can delve into the source code at the precise location where the problem is occurring.

Generic client side gameplan

Check the console for errors
Inspect page finding the handler associated with the issue.
Add breakpoints so you can view the parameters being passed, and view the call stack in case those values came from elsewhere
Search in source for tags or handlers to be able to change the relevant files. Add log lines in order to aid visibility.
Test your change.
Repeat until done.

Tip: If using Typescript or if your Js is bundled add a debugger; line so that your browser will automatically break at that point when your code executes, this is a great way for finding where those files have been combined to.

Step 4: Bad data in or bad data out.

Problem: Data Display Error

If your problem is with data rather than validation, you will need to figure out whether the data is being saved incorrectly or being displayed incorrectly.

If, for example, you have a label on your page which should display your name, but it’s showing your age.

You need to find out whether you are using the wrong field/value to display the label, or the value is being retrieved correctly but saved incorrectly.

A problem of this ilk can be harder to pinpoint, as you do not know where that data is coming from, similarly to our first example, find an entry point, and follow the code up to where data is being loaded. Now you can check whether this data is incorrect at the source!

Tip: This may be an application lifecycle hook such as Page Load or Init.

Backend gameplan

Find where the data is being retrieved from, which table, proc or function is being called to display that value.
Query the database using any unique identifiers to filter down the results.
Depending on the outcome, you will have two possible avenues.
- If your problem originates elsewhere; when the data is saved.
- Or when it's being displayed.
If displayed, circle back to the client side gameplan else...
Find all possible routes to inserting data into that table/store, and whittle down which one is causing the problem.

Problem: The Stack Trace

The Stack Trace

Sometimes you'll be presented with a giant wall of text also known as a Stack Trace. The stack trace looks scary, initially comparable to that of a towering wave. But don't worry as there will be lots of information about libraries and binaries you don't care about, and probably never knew existed. In 99% of cases these will not be the problem, so find the lines that equate to the code that's yours!

If you receive a stack trace, you are actually in a very strong position. It tells you that an error has occurred and exactly where it was falling over. This makes your job much easier. Look for the method names being called, the files involved, and the line numbers to find the source of the problem. Then, depending on the problem, follow the relevant game plans listed above.

Tip: Find the first time your code was called, and start from there.

Here's a great look into the intricacies of the stack trace and how to find the bits relevant to you! https://alligator.io/js/stack-trace/

Stack courtesy of: https://alligator.io/js/stack-trace/

Not getting anywhere?

I Am Devloper

@iamdevloper

Debugging is like an onion. There are multiple layers to it, and the more you peel them back, the more likely you're going to start crying at inappropriate times.

19:51 PM - 15 Feb 2019

If you've already:

Replicated the error?
Used Google to rule out any arbitrary problems?
Found the source code you "think" is causing the problem?
Added in debug points, print statements, console.log lines to confirm your assumptions?
Made some changes, and the bug still is occurring?
Smashed your head against the desk multiple times??

Ok, so it's probably time to pull someone in to help. After spending an hour or so, if you're struggling to make progress find someone to talk the problem over with, sometimes just discussing the problem will give you new leads or a new road of inquiry.

Art comes with practice

As you can see, finding the root cause of an issue is hard, there are lots of potential routes, and quite often numerous red herrings or dead ends. Finding the optimal way of tackling each issue is a valuable skill in your arsenal. Over time, you will instinctively know where to start your search and save some time. Saying that, assumptions are usually a bad thing when looking into the code, it's always best to see what is happening, rather than what you think is!

I'd love to know if you have any tips for your fellow developer?

Alternatively, what's the biggest mistake you can make when starting out looking at a problem that is raised?

Do you write unit tests to cover every bug you encounter???

Additional Reading

Any Questions?

Chris Bertrand — Tue, 19 Mar 2019 10:32:27 +0000

It's the end of a presentation and those famous words are spoken once again, having heard this numerous times, very often the speaker/you are met with silence. You've just spent a week, perhaps longer preparing a presentation, a post or a new tool for people to use, and nobody has any questions about what you've just displayed! Faces are blank, and people make a swift exit. Why is this?

It's because you're doing it wrong!

What do I mean by that? Let me explain.

When you bring people into a room and tell them something new, they may be excited and intrigued, but first they'll feel doubtful, confused and defensive. You don't want to sound silly saying something that doesn't make sense, making you look bad, so most people say nothing at all.

How can we disarm the audience?

As our instincts are always on alert for dangers or threats, we're predisposed to be wary of change. Making sure your audience is relaxed and comfortable is an important first step. Throughout your talk, you will need to coax the audience into small acts of participation. Have you ever noticed, that once someone has spoken up during a presentation, they are inclined to speak up again further down the line, this is not a coincidence, it's the participant becoming accustomed to the speaker and feeling safe and satisfied with how the last exchange went.

I've just finished reading a book that was recommended to me - How to get people to do stuff - by Susan Weinschenk. It's a great book going into the psychology of how people behave and react to your actions, words and cues.

To get people to speak up you will need to follow a set of rules to help that happen.

Susan describes the best presentation she's been to, it was actually a performance by musician Bobby McFerrin; a master of music and in particular extensive audience participation. He does this by bonding the group and taking it slow. Sitting in a room full of strangers you won't want to look silly, but Bobby starts by getting you to sing a single note, he then builds upon that one act asking for a little more each time until everyone is freely participating. I've embedded a Ted talk showing him in action below.

Now I don't expect you to go to these lengths to get the audience to participate with you, but there are some specific things that could help gain traction in future talks.

7 Things you can do to improve audience participation

Be sure to let the audience know early on that questions can be asked throughout, unless you specifically don't want them this will improve engagement throughout the talk. Anyone that speaks up during the talk, will have a much higher probability of asking one afterward too.

Questions aren't to be feared. They’re to be embraced. There’s no better way to connect with an audience than to allow them free rein to ask as many questions as they want.

Joey Asher from Talking Points

Start slow, and try and get your group feeling safe. You can use humor to make people feel relaxed, but don’t make fun of people as a form of humor or they’ll start to feel unsafe.
Keep your hands open with palms up when asking questions, this means you’re asking for something from the audience. Subconsciously the audience will recognise this and help you out.
Ask the group to do one small activity before taking on anything more complex.

There's a reason that ice breakers are so commonly used in group scenarios. When introducing a topic you could ask for a show of hands, or ask anyone if they are aware of what you will be defining. These little steps although minor will encourage people to be more vocal further down the line.

When you ask people to do stuff, use nouns rather than verbs. By invoking a sense of belonging to a group, people are much more likely to comply with your request. Gregory Walton has published a great study into this that you can read fully here.

Take this as an example.

When asking someone “How important is it to you to be a voter in tomorrow’s election?” rather than"How important is it to you to vote in tomorrow’s election?” , this simple phrase change was said to have had contributed an 11% increase into whether participants would actually vote!

So perhaps rather than asking,"Does anyone have any questions?"

Try, "Do you have a question" or "What are your thoughts"? Speaking directly to the the individuals in the group?

This still might not work, Nobody likes asking the first question, so how about asking it yourself. Prepare a question, discussing something you have may have not covered fully to engage the audience, and make them less self-conscious about asking something that may be off topic.

Smile, Breathe and Relax! The audience can read your mood, and as such will be more open to you if you are feeling confident yourself. Speak with passion and enthusiasm, and the audience will be enthused themselves.

Let us spin a positive light on this, most of us aren't well versed in speaking to large groups of people. Whilst creating an interesting and engaging presentation is hard enough already, having to think about audience participation seems like an afterthought. Next time a presentation is looming, try using some of the tips noted above when preparing for your talk and see how this changes the engagement with that final question.

I'd love to hear of any great tips you may have, or any other books you know of that go into this topic further. Here are a few great posts I've found online, whilst writing this. Remember, being witty funny and getting the audience on board will get you a long way!

Just ask Steve!

Speaking About Presenting - Question Time

University of Leicester - Delivering an effective presentation.

Medium - Best Presentation Ever Post

Why being a good programmer barely requires programming at all.

Chris Bertrand — Tue, 19 Feb 2019 09:22:06 +0000

Yes, you read that right. To be a good programmer you don’t need to be good at programming.

I hear what you’re thinking, that makes no sense! Well hold on a second, hear me out.

When you think of a good programmer you know, what’s the first trait that springs to your mind? Determined, smart, approachable? Calm, Quiet, or conscientious? Maybe it’s something else, but I can bet it wasn’t… a really good programmer. Why is that?

Programmers require lots of skills in their day to day jobs. The discipline no longer consists of sitting in a dark basement on your own thrashing out some code. In fact interpersonal skills are some of the most important a good programmer can have. Agile methodologies require lots of communication between different departments and individuals. You’ll be required to check in at least once a day, be available for planning, refinement, retros; constantly communicating about struggles, improvements and things that are going well.

The old days of getting your tasks and specifications up front, and being left to your own devices is long gone. You’ll probably be in contact with your users, asked difficult questions about your progress, and required to feed information back to your product owner/manager.

You’ll need to talk through your design with your superior and team as most likely you won’t be working on this on your own. Testers will be asking for updates, questioning whether your unit tests are credible and sufficient, your issue tracker will need to be constantly updated keeping discussions available for all to see.

You actually might be better off with a psychology degree than a computer science one to understand how to deal with all these different people.

So yeah, programming is gonna be needed at some point, but in general the stuff that 90% of us will be doing won’t require any revolutionary coding expertise.

In most cases the reason a project will fail is because requirements were not properly discussed and refined, or teams did not communicate properly about what was required from them. Rarely will it be because you weren’t a good enough coder.

Do you share the same views? Or do you think I'm talking nonsense, I'd love to hear your opinions below.

Dev.to has implemented Series! Series are cool! Coding Concepts is now a series! Cool!

Chris Bertrand — Wed, 16 Jan 2019 14:31:27 +0000

Afternoon all, I'm Chris and I started the Coding Concepts Series, writing about programming topics which I find interesting.

As Dev.to now officially support 'Series' I thought I'd celebrate with a combination post!

I've linked to each individual post, but at the top and bottom of the article you will now find cool little circles linking to each post within a series, hopefully there will be a way to style them soon!

How to create Series

If you were wondering how to create a Series, you need to add

series: [series name]

to the front-matter part of your blog post header.

See the editor guide below for more details.

Ref: Editor Guide

Series Posts

Article No Longer Available

A term called Cargo Cult Programming and it really struck a chord with me. Read more about it above.

Article No Longer Available

Cyclomatic complexity I feel is a very valuable tool in a developer's arsenal, read more about it above.

Article No Longer Available

Reflection, what is it? What does it do? How to use it? Read more about it here

Article No Longer Available

Anonymous methods (The FAT ARROW =>)

Article No Longer Available

Generics can be hard to grasp, that's why I started the series writing about what they were, read more about them above.

Thanks to everyone that's read, and commented on the series. I hope you've found it useful, I'll be looking at expanding the series with more posts this year, if there is anything you think would make a great post, let me know in the comments below.