Skip to main content

· 5 min read
Marcel Scherzer

Why do we have pull requests?

As software developers, we enjoy that feeling of being immersed in the flow, that wonderful state of being where hours whizz by in an instant, and our mental model stands clear; where we can be hyper-productive as long as we can keep the outside world at bay and remain in blissful uninterrupted solitude.

However, building modern software is also a complex team sport where collaboration and continuous feedback loops with fellow developers are key to personal development and high-quality code.

Code reviews are the most obvious contact point with other developers and a foundational process in working towards becoming a part of, remaining in or working towards building a high-performing team that creates code that is stable and fun to work with.

While one on one code reviews likely offer the most value in terms of learning from each other and making available stable applications to our end users it is unfortunately not always practical to meet face to face. We are frequently working on different schedules in distributed teams or require input from multiple people to weigh in on a design decision all reasons making it unpractical to talk one on one about our code.

Fortunately, the development community has been steadily iterating on the process of reviewing code contributions from developers distributed around the globe. Through many iterations and trial and error of sharing patches via email, IRC, forums, and various other communication channels we are currently positioned to take advantage of the “Pull Request” concept for conducting code reviews.

The concept of a pull request as a mechanism for conducting code reviews is built into all popular modern code management platforms like GitHub, GitLab, Bitbucket and others.

In simple terms, a pull request is simply a request to get input from fellow developers on some code that you would like to contribute back to a project. Depending on the platform in use there are various features for working with pull requests but usually, there is a forum-style feature set used to discuss and reason about source code changes.

What is a pull request?

Ok, so let’s take a stab at a definition of a pull request.

“A pull request is a form of code review that is facilitated by a code management application that provides communication mechanisms specifically designed for talking about specific source code changes. In other words, it is a technical solution for conducting asynchronous code reviews, typically before accepting code into the code base.”

Before digging a little deeper into the pull request, I want to take a quick detour and encourage you to think about what type of developer you are striving to be and to think about your work in the context of your team. Ideally, you are reading this with the motivation of striving to be the best developer you can be and that includes thinking beyond the code. Hold that thought in the back of your mind as we move on.

Alrighty, so back to pull requests. Recalling that pull requests are a mechanism for discussing code it then follows that a pull request is an opportunity for learning and expanding one’s development skills. The net result is an improvement in the ability to craft quality code.

Things to consider

I want to now list a train of thought that you may consider following as a starting point for developing your own thinking about pull requests.

So, let’s start with the following: I want to ensure my code is of high quality and I want to try and discover something I did not previously know. I’m therefore seeking to take advantage of collective knowledge embedded in my peers and in those that may be more experienced with the code, language, design patterns, algorithms and so on.

Furthermore, I can empathise with what it feels like to be interrupted and how little time we have for the fun part of our job, that is, the actual problem-solving and writing of coding.

Therefore, I need to ensure that my pull request is easy for others to reason about and work with.

Finally, I want to use this opportunity to ask any specific questions to learn and make it simple to iterate over suggested code changes.

Pull request checklist

What follows is a mental checklist of points to consider before submitting your next pull request.

  • The pull request description provides enough context to what the code is supposed to do through the lens of the end-user.
  • I have asked specific questions on areas of uncertainty.
  • Where I use a non-obvious approach, I have explained why I avoided the obvious approach.
  • I have considered splitting up this pull request if I have more than 250 lines of functional code. Ignoring boilerplate/comments/styling.
  • The commits in the PR have been squashed to related code changes.
  • The code is technically related (cohesive) and focused on a specific feature.

Following, the above will put you well on the way to getting the most out of your pull request and hopefully make you rethink the notion that a pull request is simply a hurdle to getting code into a project.

In a follow-up article, I want to take a dive into GIT and share some techniques for using GIT to craft pull requests that will delight your teammates.

🍺 Happy Coding! 🤘

· 3 min read
Marcel Scherzer

Before you write GIT on your CV for your next job interview, make sure you know how to use GIT professionally; read on.

If you are here you know that GIT is likely the most popular version control system used in the known universe. If you are a developer looking to get paid GIT is one of your most important tools for doing a professional job.

Any developer can write code. Professional developers know how to organise code changes so that they can be easily reviewed, patched and reasoned about. GIT like other version control systems is the tool that helps us to work professionally.

Unfortunately, there is a disconnect between using GIT and using GIT Professionally.

Here, then is an insight into the GIT skills I and fellow hiring engineers expect you to possess and test for when we read the words "Skills: GIT" on your CV.

GIT basics if you are getting paid.

Know how to use the GIT from the command line.

Graphical GIT tools can be great, especially for GIT beginners, but also for professionals when resolving merge conflicts. There are plenty of fantastic dedicated git tools around such "Tower", "Source Tree" and "GitKraken"; IDEs like VSCode even ship with inbuilt GIT support with a nice integrated GUI.

Despite the attractiveness of these tools, there will be a point where you will need to drop down to the raw power afforded by the GIT command line tool. Therefore, there is an expectation that a professional GIT user has the knowledge to use GIT from the command line. Anecdotally, it has been my observation that as developers develop their GIT skills they transition away from GUI tools for all GIT tasks except the resolution of "merge" conflicts.

Use the stash to your advantage

  • Named stashes
  • Pop, Clean, List

Merge vs Rebase, clean histories.

  • Know the difference between "merge" and "rebase".
  • Ours & Theirs
  • Cherry Pick, Patches, Checkouts

Re-Organise commits so your teammates love you.

  • Use GIT to organise and create nice pull requests.
  • Squash, Rewrite
  • Re-organise with hunks.

Keep the peace, and resolve merge conflicts.

  • When do merge conflicts happen? Three-way merges?
  • Have a merge/diff tool.

GIT Warrior

  • GIT autocompletion
  • GIT aliases
  • Shell Tweaks
  • VIM & GIT, the Dream Team

Git Guru & Beyond

  • Porcelain Commands.
  • GIT Hooks
  • GIT Internals.

While not necessary, you should be capable at a pinch of using GIT from the command line to find help and resolve problems. This will inevitably be required as even the best GUI GIT Clients fall far short of the capabilities afforded by the GIT CLI.

I have noticed that developers that spend a little bit of time using GIT on the command line tend to stop using a dedicated GIT GUI. Mainly because common git operations are faster to execute from a terminal inside the IDE.

· 3 min read
Marcel Scherzer

Using MFA enabled AWS accounts & CLI


Simplify your life when using MFA-enabled accounts with AWS profiles by installing this command-line tool.

Install awsmfa from npm or fork the project on GitHub.

Managing MFA credentials

Enforcing multi-factor authentication (MFA) on AWS accounts is a security best practice that can provide some usability hurdles for engineers that rely on the SDK and AWS command line tools to get work done.

The typical workflow for working with MFA-enabled accounts is to request a temporary session using the AWS STS service. The STS service will then return a session token which includes temporary credentials as well as a session token. Depending on the use case these data can then be used either in a profile definition, environment variables or as arguments to call AWS Apis that require MFA.

However, it is a complete BITCH of a process.

To strike a balance between security best practices and ease of use it is best to take advantage of some tooling.

There are various tools available to ease this process including awsmfa.

Why, build yet another tool?

Now, I know that there are several tools available in a range of languages that address the issue of working with MFA-enabled AWS accounts.

However, I specifically needed a tool that we could install using NPM. Furthermore, I wanted flexibility for automation, and my final requirement was the ability to have an interactive mode for humans.

Making up the above wishlist, was my excuse to satisfy my curiosity about the effort required to build a CLI command with Typescript, that could be installed using NPM.

Besides, I love coding and this little project was a fun Friday night accompanied by the awesome Charlotte de Witte.

What problem does it solve?

The catalyst for the project was the inability to authenticate using an MFA-enabled account when running a project inside of the "Serverless Offline" framework.

I also needed a tool that would work with multiple AWS Accounts, supported a flow reliant on Assuming Roles, that I could further control with Bash and provided the flexibility to prompt for input of an MFA Token. Good Times!

After, a night's mad coding and a morning of debugging I'm happy to share "awsmfa" with you.

The command line tool will authenticate with a profile of your choosing (defaults to "default"), prompt for your MFA token and writes the temporary session back to your "credentials" file under a name of your choosing (defaults to "mfa").

Using a "named" profile has proven to be the most reliable mechanism for authenticating where you are using multiple programming languages, containers, virtual machines and run times.

For more information and installation check awsmfa on npm.js

Happy Coding!

Marcel 😎👍

one more thing ...

Based on completing this mini project I also made available a boiler plate template that you can use to quickly boot strap a project for building your own NODE CLI command with typescript. That sounds like an Upcoming YouTube Video.

· 2 min read
Marcel Scherzer

Vim Essentials =+-

In my opinion the best way to fast tracking your VIM skill set is to understand some principle concepts.

In most cases commands can be strung together as follows:

1 - The action to perfom - (operator) command. 2 - The number of "objects" against which the action is to be applied 3 - Which "text object motion"

Essential motions:

tJust before character
wforward beginning of word
bbackward beginngin of word
eforward end of word
[[next section
$end of line
0beginning of line
^non empty space on line
wforward N words at a time
eforward to the end of the word

Essentials commands

cchange inside: ", ', {, ( [, t
ppaste after / P paste before
g~swap case
gulower case
gUupper case
.repeat command

· 6 min read
Marcel Scherzer

Watch on YouTube

Watch "Why learn GIT" on YouTube.

  • 2:04 - How to get started with VIM.
  • 2:44 - Insert Mode. (make vim act like nano)
  • 3:40 - Getting back to normal
  • 4:09 - Console Mode
  • 5:00 - Quitting VIM
  • 6:10 - Quickly change the text inside quotes
  • 7:15 - Saving your changes.


The motivation to write this article is to encourage you to add an efficiency skill to your skill set that will benefit you throughout your entire career as a developer. Let’s set a scene to get started.

Imagine a pleasant Sunday afternoon at home and you are trying to help someone in your family be more efficient by encouraging them to learn how to “copy & paste” with the keyboard.

Your protégé reciprocates with: “I don’t want to remember that “ctrl + v” pastes text, it makes no sense to press V for pasting, it’s too hard for my fingers, and why would I want to bother remembering that? Look, it’s easier to simply copy and paste from the menu with the mouse.”

Knowing what you know about working on computers; what’s going through your head as you hear that?

Right, I think the same thing when developers list their reasons for not wanting to learn VIM commands in their favourite IDE.

You can lead a horse to water, but you can’t make it drink. The phrase sits in the back of my mind when I introduce Developers to the idea of using VIM to navigate text in their favourite IDE. Why the resistance? Follow me to the water, you may want to take a drink.

Leading you to water.

If you are doing any kind of serious coding, you know you are using an Integrated Development Environment (IDE). And you know you have installed a bunch of IDE plugins to improve your workflow.

Yet there is this one plugin you’re avoiding. It exists in some form or another for all major IDEs. It has over 3.5 million installs just for VS-Code, and top ratings to boot. What’s Up? Why would you not want to learn a productivity skill that will benefit you throughout your entire career, has stood the test of time and is highly regarded by millions of software engineers? “Can’t be bothered,” you say.

Think about this. As we transition from hobbyist to professional developer, our coding tends to skew toward refactoring and debugging. That is, as professionals we tend to spend more time navigating around and editing existing source code and configuration files than we do creating new code.

Therefore, it makes sense to invest in skills that afford us the ability to remain focused when navigating and editing existing code, the cherry on top if we can do so while satisfying our inner geek.

VIM is an editor. However, VIM is also a paradigm for working with source code that you can integrate into your IDE. It is this last part that you should consider when you hear developers encourage you to learn VIM.

VIM is a beast and the possibilities for customisations to suit your specific workflow are endless.

The awesome news is that it is quick and easy to integrate some useful VIM commands into your workflow. Even if you just adopt the basics you are going to be rewarded, just as you were when you committed “copy and paste” using the keyboard to muscle memory.

Let’s quickly have a look at a proven approach to adopting the fundamentals of VIM so you can get started today.

Getting started on the road to greatness.

Typically, the biggest hurdle when adopting VIM is understanding the “MODES” paradigm.

VIM acknowledges that working on existing code and writing new code can be done more efficiently when the UI can be optimised for each of these two tasks. As such VIM offers different modes of operation suitable for the task at hand.

The two important modes are “normal” mode for moving around and making small changes and “insert” mode for writing new code and making big changes. If we relate this back to Nano or your IDE, then “insert” mode is the only mode you have.

Enabling a VIM plugin in your IDE then adds extra modes, such as “normal” mode for efficient navigation.

The other major feature to understand is Vim’s “console”. The console functions much like any command-line interface in which you can issue your commands. You use the console to load files, write files, get help, quit and many other functions.

Let’s have a quick walkthrough of the things you need to know to replace Nano with VIM so you can start developing this skill set.

Replace Nano with Vim

  • Whenever you would type “nano” to edit/create a file start typing “vim” instead.
  • Remember “nano” only has “insert” mode.
  • Vim has many modes and starts in “normal” mode.
  • To put Vim into “insert” mode press “i” (eye). In the bottom left Vim will show “insert” to show you are in “insert” mode. You can now use Vim like nano to edit text until you are ready to save or exit.
  • To exit any mode and to get back to “normal” mode press the “ESC” key.
  • To save and or quit use the vim console. To open the console dialogue press “:”.
  • There will be a prompt at the bottom of the screen for issuing commands. w (writes changes to disk), q (quits). Commands can often be combined for example typing “wq” writes changes and quits.
  • If you want help on any command or keyboard short cut type “help” followed by the key or command.

The above is all you need to know to replace “nano” with VIM. You are now ready to start learning VIM. I suggest starting with the inbuilt VIM tutorial. Instead of vim type “vimtutor” to launch the tutorial. You can follow that up with a game of “vim adventures”.

In follow up articles I will start to introduce you to the VIM basics that translate well to your IDE.

Before I leave you, below I have outlined a learning pathway to develop your VIM skills. Drink UP 🤘

VIM Learning Pathway

Instead of jumping in feet first by installing a VIM plugin into your IDE, I would suggest you follow the following progression to avoid frustration while you build up your muscle memory.

  1. The VIM editor will be your Training Ground. Stop using Nano.
  2. Learn to use VIM like a simple text editor. Load, Save, Edit, Quit.
  3. Learn basic commands.
  4. Do the vim tutorial, play vim adventures.
  5. Activate the VIM plugin in your IDE. Gradually try adding more commands to your workflow

· 2 min read
Marcel Scherzer

Friday night and after "investing" 225 hours in Valheim I have finally unlocked the "bordom" achievment. It's a lonely life being the sole viking in a hostile land.

So here I am; switching up my friday nights entertainment by setting up this Blog. An exercise which might well serve double duty as the topic for the first couple of posts.

This should be a nice place to maintain a collection of scripts, tools, videos, rants and other odss and ends.

If the site is found to be helpfull or entertaining all the better.

Alrighty, with a readership of one and the bar set low lets go!

Queue the evervescent Miss Monique and lets map out tonights adventure.

My Ideal Blog

The goal tonight is to tick of all the boxes in this "blog" wishlist and to nail the bonus challenge.

  • The ability to author docs in any tool that can process plain text.
  • A format that is easily readable in any tool that can open a text document.
  • Files I can store on my NAS, version in GIT or easily share on a USB drive.
  • Host the file content as a nice looking website. (your are on it now)
  • Not bothering with a lot of writing code, but having the option to do so.
  • Have minimal hosting costs.
  • Is not a pain in the arse to publish new content.

Bonus challenge

  • Have the ability to automatically scale to massive number of users.
  • Maintain full redundancy for the site even if an entire data center fails.
  • Secure the site with SSL
  • Use my own domain name.
  • See how cheap I can achieve the above.

The process and rational for achieving all the above will make a nice series of posts and provide a nice opportunity for reflection as well as maybe a tutorial.

It's late the site is up, Miss Monique is spinning her last track and its time to hit the sack.

Peace Out. 🤘