DEV Community: Connor Gladwin

Programmatic Problem Solving

Connor Gladwin — Thu, 11 Mar 2021 21:00:12 +0000

The art of solving problems using code, at its core, isn't about the code. A popular quote states that programming is "90% problem solving and 10% writing code".

Though most of us, especially when starting to learn how to code, don't really think of the problem solving aspect of it. I'll admit that for the longest time I too would just jump into a new project, with no pre-planning and the mindset of "we'll figure it out along the way." This, I believe, is born from excitement, the rush of starting something new, it's the fun bit.

I still do this from time to time, either when I'm really excited about a project, or when I'm writing something just to keep my basic knowledge sharp. The latter being the one that needs the pre-planning the most.

But when you take a step back, we are solving problems, no matter what you're making. You are both making the puzzle and solving it.

A concept that I've come to know and understand as a fundamental part of my process is the preplanning. However you may do it, it will make whatever you're doing far easier, whether it be scribbling down a drawing of your website layout before you begin creating the webpage or drawing up a complex flowchart detailing how each component of your app will interact with each other, it will give you some direction and allow you to account for future components that will be added. Now I'm not saying detail your entire solution here, though it's always good to keep a few ideas noted as inspiration.

How I go about this is, I have a notion.so document that contains everything my app will need to do. from here, whenever I create a new file, I will add all the components and functions needed for that file, like so:

// fetch user input from form and store in session

I use these like headers. Taking the examples above, creating a function that will add the user input information into session storage will go beneath that comment. It allows me to separate the code and focus on that one thing, its also handy for finding that piece of code when you need to fix it. You can also pseudocode here for added planning, its something that most of us have learned when we started out but rarely use. Next I determine what are my inputs, outputs and variables, as this lays down what I'll be working with. Then I hop in and start writing.

You're going to be problem solving whether you like it or not, if it's for a client, your job or just for yourself. So give yourself the best advantage: clear direction and a better understanding of where you're going with the code and what it needs to accomplish.

Unfortunately, in the real world, the problems you'll be tasked with solving won't be clearly laid out, so I hope what you've read here helps with the problem you're trying to solve.

Thanks for reading!

If you'd like to read more of my writing, you can check out some of my other articles on dev.to, if you'd like to read more of my ramblings and thoughts or just stay up to date you can follow me on twitter @khasmodan, I also stream myself solving different coding tasks over on twitch - here - every Tuesday and Thursday at 7pm (SAST).

The Immediacy of Web Development - Hot Reloading

Connor Gladwin — Fri, 05 Mar 2021 07:04:08 +0000

When I had moved over to web development after finishing my bootcamp in software development (Python & Java), I was amazed that you could get immediate feedback on what you had just done. No need to wait for your app to compile and run, and in a few cases, you could intentionally break your website if needed. Along with this you're also given a whole host of developer tools right out of the box.

After a short while I found this immediacy a boon for my development, with very little thought you were able to see the result of your work. Though this wasn't enough for me, I didn't want to click outside of my editor to see the changes happen.

After a bit of research I came across a buzzword from many of the podcasts I have listened to: hot reloading. Now this just sounds cool. It conjures the image of your lightning fast key strokes flying straight to your browser, still glowing red hot when it gets there.

That analogy aside, hot reloading is an awesome tool. This works well with single page apps, and it definitely helps when you're learning website design or single page static websites, though you may run into some issues if you're building a bigger, more complex app.

In the past, grunt and gulp were the go to tools for this, but I haven't used them because I was introduced to Parcel.js first, and that's what I've used ever since.

How to make it happen:

First off you'll need to download and install Node.js, as this is a node package.

Secondly you will have to create a folder which is going to house your project. (You can do all of this in your file explorer)

Next you will need to open your preferred terminal (I use Hyper terminal which can be found here: https://hyper.is/) and navigate to the folder that you've just created.

Once in the folder, use the following console command:

npm init -y

What this will do is create a package.json file in your folder.

And once that's run its course, run the following:

npm i parcel-bundler

This will install the parcel.js package to your folder.

From here you will need to open your package.json in your favorite text editor, and modify it slightly so that you can get the hot reloading rolling.

Your package.json should look something like this:

{
  "name": "Test", // the folder name
  "version": "1.0.0",
  "description": "",
  "main": "index.js", // you'll need to change this name, but well leave it as is for now 
  "scripts": {
    "build": "parcel index.html", // the command you'll need to run in your terminal
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

A few notes on the code above:

First off, the name will be the folder name that you have initialized your package.json file in.

Secondly, the main will be the JavaScript file that your npm packages are looking at, not necessarily what parcel will be watching.

And thirdly, your build command will have to have the file name that you are wanting parcel to watch, if it doesn't, none of this will work.

Once this is done, you can create your index.html. The last step is to hop back into your terminal and run the following command:

npm run build

This will run the parcel server on your localhost (most likely localhost:1234), where you will be able to view the page. The page will also update every time you save.

Another option, though I do take exception to this as it is editor specific, is LiveServer for VSCode. It works very similarly to parcel without having to go through the process of installing a package.

Thanks for reading! I hope this little guide helps!

You can follow me over on twitter at @Khasmodan to see my ramblings and stay up to date with my posts.

Dealing with Rejection as a Self-Taught Dev

Connor Gladwin — Thu, 25 Feb 2021 06:02:21 +0000

The field of software and web development is one of the few in which a person can join, and even thrive with only self-taught knowledge. There is no shortage of success stories to prove that this is true. But even though there are these success stories, the sad reality is that there are far more where failure is a constant.

When asking those that have succeeded how they did it, the most common thread is that it's a numbers game, throw enough at the wall and something is bound to stick, another is that they were able to get the ear of a dev or hiring manager at a certain company and that was their way of getting their foot in the door. I'm not trying to dismiss these, or deny that they are viable ways of getting into the industry, but they are far harder than they're made out to be.

For most who are in a position similar to mine, rejection is a common occurrence. We've played the numbers game, we've spoken to recruiters and other devs, but the prevailing answer at the end of the day is this: "You don't have the level of experience that we're looking for."

This line of reasoning becomes a vicious circle of "I don't have enough experience to get a job but I need experience to get a job but I don't have enough experience to get a job etc...". And so, the rejection continues. This rejection comes in another form, which is no answer whatsoever, you send through your CV in eloquent and well thought out email and after weeks of waiting nothing comes back. This, in my opinion, is the worst.

The rejection hurts. The resulting headspace is one of a deep demotivation and reconsideration whether all of the time and effort you've sunk into learning this new craft was worth it. If you're worth it.

I can only speak for myself here, but I have applied for, through the most popular job search platforms available to me, over 100 jobs, and I have managed to get two positive responses: a phone screen and a tech interview. Both unsuccessful because I was too too junior.

The way I personally handle these feelings, and motivate myself to keep going is this, a single sentence: "I'm better than this". In the grand scheme of things this is just a tiny blip on the timeline that is my career, and I will overcome it. I remind myself of the success stories, and of my love of creating things, because no matter what, I still sit down and write code and keep learning whenever I have the time to. And you should too.

Another way to keep yourself up is to learn something new, find a new technology that excites you and build something. You can even go as far as starting to contribute to an open source project. Even if its something that the market isn't looking for in a candidate, do it for yourself.

Never stop looking for opportunities, because you only lose if you stop playing the game.

Python and the Art of Laziness

Connor Gladwin — Mon, 15 Feb 2021 19:58:20 +0000

I'd read somewhere that developers are lazy. It's an old joke passed around, most likely stemming from a quote often miscredited to Bill Gates: "I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it."

Now this may be true for some, but when I rediscovered my love for coding I dismissed this, I wasn't going to be lazy, I was going to be a productive dev, a 10x. I'm now just over a year into my journey, having learned python through a bootcamp, and I'm currently teaching myself JavaScript. I have been on this journey for a whole year, rarely taking a day off, and all I can say is that it makes you lazy. And thus was the impetus for this piece.

The real catalyst for the subject was when I found myself opening the four apps I use most when writing code, namely VS Code, GitHub Desktop, Chrome Canary and Hyper Terminal.

Now I understand that it's just four apps, it's really not that difficult, yet I still huffed and rolled my eyes whenever I had to do it. The thought had then occurred to me: "There must be an easier way to do this", and this was the seed. It was small, I could've shrugged it off and continued the way I had for the past months, but I gave it a bit of heed and thus the result was what I've called my DevStart.

The more I thought about it, the more excited I got, I could finally put what I'd learned to good use, to build something that I could use to solve a problem I was having in my daily routine.

When starting I knew I would have to access the os using python, with import os first step was done. Next I knew that there was a way to open files using python, but I didn't know how to open a program, and after a bit of digging I found some rather verbose and overcomplicated ways of doing it, importing a whole host of modules to get this done. I did try one or two, but they never worked, throwing error after error. This lead me to what I do whenever I run into an issue with my JS, and something that I've taken to be something like a mantra... "Just go look at the docs".

After a lot of searching and punching keywords that were relevant to my goal into the search bar I came across the function os.startFile(), into which you plug the path to your apps exe. The code ended up looking like this (paths removed):

import os

os.startFile(path to VS Code)
os.startFile(path to Hyper Terminal)
os.startFile(path to GitHub Desktop)
os.startFile(path to Chrome Canary)

I typed all this out, and upon running the file it worked smoothly. Great! Job done! Not quite. I didn't want to have to open one program, only to have it open another three, my aim was to make this as easy as possible. And making it as easy as possible meant making my new little script work like an executable.

To do this I created a batch file, which looks like this:

"C:\Users\Connor\AppData\Local\Programs\Python\Python37-32\python.exe" 
"C:\Code\dev-start\dev-start.py"
pause

Creating the batch file was relatively easy, create a new file in your editor and save it as a .bat file. Now what this does is starts IDLE, which then runs the python script and presto, we have four apps open.

I do understand that I spent probably ten times the amount of time automating a process that takes me about 30 seconds, but I'm not going lie and say I wasn't impressed with myself. It was shortly after I had gotten it to work, while I was showing it off to a friend, that the quote drifted into my mind, I now understood the core of it. It's less about being lazy, and more about being efficient, finding a way to remove the small tasks that aren't helping you be productive, or minimizing unproductive behavior. I've tried to implement this into the way I work, "how do I get the job done, to the best of my ability, using minimal effort". What this has done is develop a better problem solving mindset.

I hope you enjoyed my delve into "laziness", you might even find that you're able to use my script to your own advantage.

Thanks for reading!