The importance of processes

What’s the first step taken to any project, whether at home or at work? Is it an idea? A problem that requires a solution? A request from an associate? How is it that this project takes the next step and eventually comes to a conclusion? What is the next step?

Something comes next, or nothing gets done

In all likely-hood the process that must be taken to get to the first or next step is a know process by those asked to do it. Be it a discovery process, a design process, a development process or an organizational one. Something comes next, or nothing gets done. Processes, or the steps taken to do work, can be improved from the logical outcome of thinking and planning. Anything that has effort can be done more consistently and efficiently with a well thought out process.

How is a planned process recorded? Is it written down? Is it a set of checkboxes that are checked off as work has been completed? Can it be verbal, or simply remembered or a visual cue? Regardless of how a process is communicated, the level of communication can and will determine the impact and integrity. Without a somewhat rigid procedure, getting work done can have unpredictable outcomes with unknown efficiency. So a well thought out and practiced process tends to solidify what can be done, and when and how work will happen at what expected efficiency.

A recorded process is sometimes referred to as ‘the standard’. There may be a notation on a procedure to take in any given situation. This becomes know as the SOP, standard operating procedure. Many times the SOP is considered a learned process that is known by all workers inherently. When approaching a stop sign while driving a vehicle, for instance, the SOP is to stop and look before entering the intersection. Then a learned process is taught to all drivers on what procedure to take when there are other cars. In my experience it is almost ubiquitously known that getting a ‘wave’ from another driver means you can go, even though this is never a taught thing. This is an example of a process that occurs, but is never taught.

It is important to a team of workers to have a process that is not simply known, but one that is taught, documented and improved with regularity. The leaders of the team cannot have ‘waves’ in the process that everyone is expected to understand. New team members especially will be confused and fill fail to do their work. A good leader knows when to ‘wave’ and when to document a rule.

A team will stalemate when too many rules are applied. This can be observed within most bureaucracies. The rules are extremely organized and well documented, but so may procedures are observed in the processes that not one person can be able to understand, let alone follow them. This leads to specialists within the team; which leads to scaling issues. In fact, more procedures and processes will cause the team to lose control of what they are attempting to build. Once this happens, the work that team does will be reliant on another party in a way that impedes the team.

There is not a fine line that determines a trim from an overbearing process. There is, ironically, a process to determine if the larger set of steps within the work being done needs trimmed or grown. This is typically referred to as a retrospective. Time taken with regularity by a team to change and control a process will determine the success or failure of the team.

As a takeaway consider the team processes you’re a part of. Are they well communicated and followed up on with regularity? Can your personal processes be improved with a little bit more focus from these same tools of thought?

Quick tip with Typescript, Use moduleResolution

https://www.typescriptlang.org/docs/handbook/module-resolution.html

One of the first items to not miss or be confused about when starting a typescript project is to set up the tsconfig.json to contain how to resolve the paths for inclusion in the app being built.

In my case, being reminded to use the node resolution strategy for importing from the node_modules folder was a requirement.

1
2
3
4
5
6
7
8
{
"compilerOptions": {
"target": "es2017",
"module": "es2015",
"sourceMap": true,
"moduleResolution": "node"
}
}

Also see some further examples here.
https://github.com/chanon/typescript_module_example

Using AutoHotkey with Surface Pen

https://autohotkey.com/

This is a scripting language designed for Windows to automate some usage. A lot can be accomplished by re-mapping the inputs.
While Windows 10 does allow apps to be loaded by the surface pen, however, these can be messed up and are very limited. What if the pen’s single click was “Copy” and the double-click was “Paste”? Something like this is easily achieved with AutoHotkey.

1
2
; remap surface pen button to copy to clip-board
#F20::^z

Simple mappings can be achieved with short-syntax, however the surface pen tends to have some problems with this when turing off the hotkeys. More success can be had by using the full syntax and applying the down and off state.

1
2
3
#F20::Run Onenote ; Single click, Open OneNote
#F19::Send, {Shift down}{LWin down}s{Shift up}{LWin up} ; Double click, Take a screenshot into onenote (hotkey created by onenote)
#F18::Send, {Control down}{Shift down}{Alt down}x{Control up}{Shift up}{Alt up} ; Hold button to trigger snippet tool (hotkey created within Windows)

This is the beginning of using AutoHotkey. It’s been around for many years and has thousands of options that can be scripted including mouse moving and deep Windows interactions. Check out https://github.com/dantheuber/WinTop-AutoHotKey for one of my favorite ways to keep a window on top with a transparency.