DEV Community: Taylor R Price

Git Stash - A Quick Primer

Taylor R Price — Thu, 20 Apr 2023 17:08:31 +0000

This was originally posted on my blog and is being re-posted here for reach. Please share it and let me know if you liked it or have any questions!

Interruptions are fairly common when working on a large project. Heck they’re even common for me when I’m working by myself. For me these interruptions often come in the form of: Please switch to working on this other thing. What happens when this comes at a point that I'm not ready to commit? git stash to the rescue! Just as the name indicates git stash allows changes to be stashed away for later use. Once the changes have been saved the source tree is returned to the state of the latest commit. At this point I can work on the other set of necessary changes. When I'm ready to come back to the changes I stashed I can simply pull them out of the stash using git stash pop and continue my work.

TL;DR - What are the commands I need to know for git stash?

git stash - This will store your current changes and clean your working directory. This is the same as git stash push
git stash -m <message> - Same as above but attach the message to the stash instead of the commit ID
git stash list - Show the list of stashes for this repository
git stash apply <stash id> - Apply the changes from the stash and leave the stash in the list of stashes.
git stash pop <stash id> - Same as apply but remove the stash from the list
git stash drop <stash id> - Delete the stash from the list

While there are more options available for git stash this list contains the majority of what is needed for normal usage. The documentation shows the full list of options for git stash.

Let's see some examples

I've created a simple repository with a single file to show some examples of how to use git stash. Here I've got a change to the file ready to be staged or stashed.

The next screen shot shows using git stash without any arguments. You'll see that the default comment will be a portion of the commit id and the commit message.

This is the output of git stash list showing a single stash with its stash id and the default comment.

If only the previous commit message is present it doesn't reflect the actual changes that were made and stashed. It would be better to have a message that reflects the changes made and the reason for stashing them. Here we can see an example of stashing a change with a message.

Now we can see there is a second commit and that it has been pushed on to the top of the list. Notice that our initial commit that was originally stash@{0} is now stash@{1}. The change we just stashed has taken its place in position 0.

If you were to run git stash pop you would get the changes that we just committed. What if, however you'd like to start working on a set of changes that aren't at the top of the list? That's as simple as calling git stash pop <id>. In this case I've provided 1 as the ID. You can see at the bottom of the git output that it says it has dropped the ref to stash@{1}.

Running git stash list we can see that there is only one change remaining in the list. The initial change that we stashed has been removed from the list since we popped the first change.

Here we use the push option along with a message. The listing shows both changes are stored again.

Now we'll use the apply option to show that we can apply a stash without deleting it from the list of stashes.

To wrap things up let's show what happens when we want to delete a specific stash.

Conclusion

git stash is a handy way to save a set of changes you're working on. There are, of course, other ways to handle saving your changes (i.e. branching). My usual use case for git stash is when I need to merge a set of changes from another branch and am not ready to commit what I'm currently working on.

Let me know if this post was helpful and/or if you have questions on this topic. For more reading on git check out my post on git merge strategies.

How To Connect A Nintendo Switch To A Private Minecraft Server

Taylor R Price — Thu, 23 Mar 2023 03:57:27 +0000

This was originally posted on my blog and is being re-posted here for reach. Please share it and let me know if you liked it or have any questions!

Mojang, when releasing Minecraft Bedrock Edition for consoles such as the Nintendo Switch, wisely decided to allow only certain public servers to be available to connect to. This is great for protecting children when they're playing online. This is not great, however, when someone wants to play on a server with friends that isn’t one of these allowlisted servers (see more reasons why here). So how do we get the Switch to allow us to play on another server?

TL;DR - Steps To Connect To A Private Server

Go to the Switch Home Screen by clicking on the home button
Click on Settings
Choose Internet
Choose Internet Settings
Select your WiFi network from the list
Select “Change Settings”
From the list of network settings touch DNS settings and choose “Manual”
Set the primary DNS server to 104.238.130.180. This server will trap Minecraft server connections and allow you to connect to private servers.
Set the secondary DNS server to 8.8.8.8. This is one of Google’s DNS servers and will allow normal internet usage.
Save the settings and connect to the network
Open Minecraft, click Play, and click on Servers
Select any of the servers and join the server
You’ll be presented with a dialog to enter and join your private server’s address.

What Is Actually Happening?

But, First, What Is DNS?

DNS is short for "Domain Name System". The best analogy for the DNS is that it is the yellow pages for website names; it contains a list of webpage names (like google.com) and their addresses. Here is a primer on DNS from CloudFlare if you're interested to learn more.

So What Are We Actually Doing Here?

The address we had you enter as the primary DNS server (104.238.130.180) is the address of a server running a Minecraft world. This world has been specifically designed to allow you to keep track of other Minecraft servers and hand you off to that server when you ask to connect to it. This is a way of sidestepping what Mojang and Nintendo had in mind when they limited Minecraft to only connect to certain servers on the Switch.

Side Note: This also works for Minecraft on the Microsoft Xbox. The same limiting of servers happens there for the same reasons.

Conclusion

Given that we're sidestepping what the designers of the Switch and XBox consoles had in mind for Minecraft please use this knowledge at your own risk.

That being said this process does allow you to play with your friends on a world that stays on all the time. This is one of the reasons why you would want a private Minecraft server. If you're interested in starting up such a server, please reach out to us here and we'll get you going with one of your own today! You can also fill out this contact form to get in touch with us and we'll get back to you with pricing. Since you're reading this you're likely to be running Minecraft on the Nintendo Switch and should pick "Bedrock Server" below.

Git Merge: To Squash Or Fast-Forward?

Taylor R Price — Thu, 23 Mar 2023 00:56:24 +0000

This was originally posted on my blog and is being re-posted here for reach. Please share it and let me know if you liked it or have any questions!

There comes a point when developing a new software feature or fixing a bug where everything has been coded, tested, and reviewed. If git is being used with feature/bug fix branches the next step is the daunting challenge of merging the newly written code with the branch we diverged from. There are several common strategies for handling a merge in git. The ones of interest in this post are fast forward, three way, and squash. What you end up having to ask yourself is:

The merging strategy that you'll choose actually comes down to this question: Do you want to retain commit history or make it easy to rollback this merge? In any software organization the answer to this question will depend on where you are in your branch structure and what it is that you're merging. To understand what the differences in these strategies are we should first start with describing what needs to happen when we merge. From there we can discuss how these strategies work. With that understanding we'll then handle answering this question.

What Does Git Need To Do When Merging Branches?

Let us imagine a developer creates a new branch (feature/test) from another branch (develop) to work on. They make a a change that they commit to their branch to implement their bug fix or feature. When they're done they need to merge back into the branch they diverged from. If other changes were made to the original branch in the mean time the result may look something like this:

If we’re seeking to merge the changes from the feature branch into the develop branch git will need to make sure that each commit from both branches is present on the develop branch after the merge. Git has several merge strategies it can use to make sure that all of the commits end up present, fast forward, three way, and squash included.

How Does Git Handle Diverged Branches? A Merge Commit / Three Way Merge

If there are changes on the develop branch after the feature/test branch diverged it is necessary to create a separate merge commit when merging. It does this to mark that a merge had to happen (whether or not there were any merge conflicts). If there are any conflicts between the code that was added on the two branches, such as changes to the same lines in the same file, git will save a version of the file with some added text to mark the change. The developer will need to resolve the changes and then commit the changes as a merge commit. If there wasn't a conflict git will simply create a merge commit. This ends up looking like the following:

What Is A Git Fast Forward Merge?

Now that we know what is supposed to happen during a merge when the branches have diverged, let’s talk about the fast forward merge strategy. The strategy name is pretty descriptive in this case. The fast forward strategy attempts to apply each commit from the feature branch onto the develop branch. When there are no commits on the develop branch after the branches diverged it can do this by simply updating the head pointer of the develop branch to the latest commit that's on the new branch and call it a day. The benefit of a fast forward merge is that it maintains the commit history on the branch without adding any extra commits. It looks something like this:

What Is A Squash Merge?

A squash commit is also aptly named once you know what it does. It takes all of the commits that have happened on a branch and squashes them down into a single commit. Let's say we start with a bunch of commits on the feature/test2 branch as follows:

The squash merge is technically two actions: squash and merge. From the command line these would both be handled in the single command git merge --squash feature/test2. GitKraken, however, highlights that these are separate actions. Here you can see that I've squashed all of the commits from above into a single commit on feature/test2.

Because there weren't any other commits on develop since the two branches diverged git can fast forward develop to the current commit on feature/test2.

When Would We Want To Use These Different Merge Strategies?

Now that we've seen these merging strategies in action we can talk about when and why you'd want to use each. As usual, it depends. Each of the strategies is useful in different situations. The short version is that a fast forward or three way merge is useful on a branch where you want to keep the history of commits and squash where you don’t. Further discussion from here presumes that there is a develop branch that is current with what the developers are working on and some hierarchy of branches above develop representing the current state of environments that are released to (QA, UAT, Production, etc).

The likely candidate for a squash merge is when a developer is merging code they've been working on in a feature or bugfix branch diverged from the develop branch back into develop. The feature/bugfix branch is likely to have lots of commits on it that represent the daily work of the developer. This commit history isn't necessarily important at a higher level view of the project and, as such, it doesn't matter for the higher level branches either. To the contrary, the feature itself as a whole is what is important. Given that a squash merge will condense the entire feature down to a single commit not only removes the commit history that might be considered noise but allows for easy roll back of the feature by reverting a single commit.

If features are squash merged into the develop branch we'll end up with a series of commits that represent the addition of entire features or bug fixes. This is commit history that matters to the high level view of the project. This makes using fast forward merges when merging from develop up to QA/UAT/Prod branches make lots of sense. If we can fast forward without introducing merge commits on these branches even better.

Conclusion - Squash Feature Commits and Fast Forward After That

There is a time and a place for every kind of commit. The only additional piece of advice that I would add to this is: Merge develop into your feature branch before you squash merge. By doing this your squash merge into develop can be fast forwarded and avoid having an additional merge commit. Once on develop you can move your features up through your environment easily.

For another interesting read check out my post on how I approach writing software. If you're interested in more git topics read my primer on git stash.

How Do I Get CMake To Find Boost When Using Conan?

Taylor R Price — Mon, 20 Jul 2020 05:08:57 +0000

This was originally posted on my blog and is being re-posted here for reach. Please share it and let me know if you liked it or have any questions!

Recently I was watching Jason Turner’s series on creating an RPG game with C++20. In this he mentions the use of a C++ starter project that uses CMake and Conan to setup good practices from the start of the project (here’s the video walking through the creation of the project). I recently started a project using CMake to create the build files on different OS’s and had some trouble with it. Given that I thought I’d update my CMake setup for the project to the starter project that Jason used. While doing that, however, I ran into trouble getting CMake to find the version of Boost that Conan installed. Here’s what I did to resolve that.

TL;DR — Read the manual, of course. Also use cmake_findboost_modular to pull just sub-modules of Boost.

What is Conan?

And why am I giving a summary of what it is when this is a post about a solution to a specific problem? Because defining what Conan is and what it does will help clarify the problem. It did for me. I’d just jumped into using Jason’s starting project as a template without fully understanding the tools in use and I had to learn about them to find the solution.

So Conan: The … Package Manager?

Conan is a package manager that allows for the installation and management of C and C++ dependencies. It is a stand-alone app that can be run by itself. It also happens to have great integration with CMake. This integration with CMake is what the starter project makes use of and, thus, what I am making use of.

Goal: Get a Specific Library Within Boost

When I created the EveSDEImporter project and determined that I wanted to handle command line arguments I decided to use Boost’s Program Options library. There are many ways & libraries for handling command line parameters but, given that I hadn’t played with Boost at all and it is a large and popular set of C++ functionality, I thought I’d go with program options to get some experience with Boost. That being said, it took me more time than I would’ve liked to download the Boost source, build it, and figure out how to get the program options library linked into the EveSDEImporter executable with CMake. Given that Conan is a package manager it was my hope to use it to get Boost and make it easy to include in the project.

How do you tell Conan to download Boost?

The Conan.cmake file that is part of the C++ starter project creates a macro that does the Conan setup. My Conan.cmake is almost identical to the starter projects’ with the exception that I replaced docopt with Boost. Note that this isn’t a judgement on docopt. I’d just been using Boost so I decided to continue with it.



macro(run_conan)
  # Download automatically, you can also just copy the conan.cmake file
  if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
    message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
    file(DOWNLOAD "https://github.com/conan-io/cmake-conan/raw/v0.15/conan.cmake" "${CMAKE_BINARY_DIR}/conan.cmake")
  endif()
  include(${CMAKE_BINARY_DIR}/conan.cmake)
  conan_add_remote(
    NAME
    bincrafters
    URL
    https://api.bintray.com/conan/bincrafters/public-conan)
  conan_cmake_run(
    REQUIRES
    ${CONAN_EXTRA_REQUIRES}
    catch2/2.11.0
    cmake_findboost_modular/1.69.0@bincrafters/stable # MINE
    boost/1.73.0                                      # MINE
    fmt/6.2.0
    spdlog/1.5.0
    OPTIONS
    ${CONAN_EXTRA_OPTIONS}
    BASIC_SETUP
    CMAKE_TARGETS # individual targets to link to
    BUILD
    missing)
endmacro()

One of the issues I had with CMake on Windows was that CMake’s find_package() was finding an older version of Boost that I had around. As I was looking around for how to tell find_package() to get the correct version I stumbled across cmake_findboost_modular. You’ll see this in my Conan.cmake and it immediately resolved the issue with finding the correct version of Boost. I’ll note that I didn’t have this problem on OS X but I have confirmed that adding cmake_findboost_modular did not cause problems there.

How do I tell CMake to use Boost::program_options? Like normal-ish

There are several things that need to happen to get CMake to tell the build system it creates to link Boost::program_options to the executable being built. The first way thing that we need to do when we are using Conan to manage packages is to tell CMake to load the info that Conan creates that contains all of the paths to where Conan downloaded packages (among other things). In the CMakeLists.txt for the executable that needs a Boost package this can be done with the following:



# Include Conan info
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

Once we have all the information from Conan we can use it to tell CMake where to find Boost and to go actually find it:



# Dependencies -- Boost
Set(Boost_INSTALL_DIR ${CONAN_BOOST_ROOT})
find_package(Boost 1.73.0 COMPONENTS program_options REQUIRED)

After this has been included we can do the normal step of including Boost::program_options as one of the target_link_libraries:



# Main executable
add_executable(intro main.cpp)
target_link_libraries(
  intro
  PRIVATE project_options
          project_warnings
          SDEParser
          Boost::program_options
          CONAN_PKG::fmt
          CONAN_PKG::spdlog)

Once this has been entered into the CMakeLists.txt for the project that needs a Boost library CMake can be run to build the build system.

Conclusion

CMake is a complex system that has a TON of options to help you build your build system in a way that will work across operating systems and build tools. It wasn’t until I sat down and actually read the manual for Conan that I realized that:

Conan did actually make the pathing to its packages available.
How to get that pathing into CMakeLists.txt
That, past specifying where the packages are, including a package in target_link_libraries is just like doing it without Conan

I hope that this helps you if you’re struggling with how to get Conan to find Boost and use packages. And, as always, I need to remind myself of this:

Throwing C++ Polymorphic Exceptions

Taylor R Price — Thu, 09 Jul 2020 17:11:46 +0000

This was originally posted on my blog. I'm posting here to extend its reach. I would love to hear your feedback either here or on my blog

Recently a co-worker asked me a question that I didn’t have a ready answer to:

To facilitate throwing detailed exceptions, I’ve derived several exceptions from std::exception. In order to centralize logging of errors, I created a function that takes a std::exception which I re-throw after logging. Why is the throw statement throwing a std::exception instead of my sub-type? I know the suggested workaround for this is to implement and use raise(), but that seems like a workaround for why we can’t throw in a polymorphic manner.

Polymorphic Exception Example

The desire that drove this question is to have a central facility to log exceptions. Once logged the exception is re-thrown to the next place able to catch the exception appropriately. The code that my co-worker showed me looks something like this:

#include 
#include 

class MyException : public std::exception {
    public:
        virtual const char* what() const throw() {
            return "MyException what()";
        }
};

void ExceptionLogger(std::exception& e) {
    std::cout

C++ Standards Body on Throwing Polymorphically

After my co-worker asked me this I began searching for an answer and, lo and behold, IsoCPP, the website for the C++ standards body, had and answer to how to work around this in their FAQs. The recommended way to do this is to implement your own exception base class and implement a virtual function which throws the current object (typically named raise()). Here is the example given on the IsoCPP site:

class MyExceptionBase {
    public:
      virtual void raise();
};


void MyExceptionBase::raise()
{
    throw *this;
}

class MyExceptionDerived : public MyExceptionBase {
    public:
      virtual void raise();
};

void MyExceptionDerived::raise()
{
    throw *this;
}

void f(MyExceptionBase& e)
{
    // ...
    e.raise();
}

void g()
{
    MyExceptionDerived e;
    try {
      f(e);
    }

    catch (MyExceptionDerived& e) {
      // ...code to handle MyExceptionDerived...
    }

    catch (...) {
    // ...code to handle other exceptions...
    }

}

As my co-worker stated to me, using raise() feels like a jarring departure from the normal mechanics of throwing an exception. Because raise() only needs to throw *this , it’s even more frustrating because it feels like we’re just moving the same call we would’ve used into a different context than where we wanted to use it. The example, however, works to solve the problem.

Why doesn’t C++ throw polymorphically?

The short explanation given on IsoCPP’s FAQ is that "the statement throw e; throws an object with the same type as the static type of the expression e". This means that a copy of the object is thrown instead of the original object and, when it is copied, the current type is used. In the example I gave above the type is std::exception. This means that the rest of the exception that is part of the sub-class gets sliced away to use the terminology from IsoCPP.

This, however, didn't fully answer the question for me. It answers what happens not why it happens. It is hard for me to believe that this is an oversight given the lengthy history and use of C++. That left me thinking that the reason for this issue is one of two things:

It is sticking around for historical reasons and so that it doesn't break lots of existing code.
There is some performance reason for not having throw act polymorphically.

Finding the answer

I have been writing code in C for many years I have been doing so in the bubble of a single company and its way of doing things. This left me with a deficient knowledge of C++ which I'm currently working to correct. However, because I've been working to correct that gap in my knowledge, I know a few people to go ask!

In order to find out what the answer I went to the C++ Twitter community. Specifically, I reached out to Jason Turner, a host of CppCast, and Shafik Yagmour whose prolific tweet history on C++ speaks for itself. The twitter thread can be seen here.

Polymorphism is Expensive

The answer suggested by Shafik is that, simply put, polymorphism is expensive. There is a long history in the design on the C++ language of not paying for what you don't use. This is done in an effort to make the language efficient. Bjarne Stroustrup details this by page four of a 2012 keynote speech entitled "Foundations of C++". This keynote is a good read in and of itself beyond just helping to answer this question.

My Opinion

I understand the reasoning that polymorphism is expensive and, thus, there are cases where it is beneficial to disallow it. Not only is it expensive it seems to me that code that would be necessary to figure out which subclass to copy could be complicated unless the vtable tells us which specific class we have in the current context. So, not only would the code to figure this out be more expensive, it would be simpler and easier to read if we didn't do it.

That being said, the only case that I can think of where we’re holding a base class object and want to do a deep copy (that is get an object of the derived class from the base class pointer or reference) is in this kind of case where we want to re-throw an exception. My understanding of using a base class to represent a derived class is most useful where we want to do a common operation on all possible derived types. On the other hand I've found somebody asking about this topic outside the scope of exceptions on Stack Overflow. This shows that there is a use for it that I'm unfamiliar. I’m sure that this lack of imagination for a use for this comes from my experience in C where object orientation isn’t available. I'm looking forward to all of you in the C++ community teaching me where this is used.

Lastly, there is an argument to be made that throw should be allowed to throw polymorphically because we’re already in exceptional circumstances. In the normal flow of operation performance is key and polymorphic copying should be something that the programmer has to implement (as shown by raise() or clone() in the SO question) only where they really need it. But, if we’ve thrown an exception already, the likelihood is that the program is already in a state where performance is less important than easily preserving information about what happened.

Conclusion

This has been an interesting journey of learning about C++, it's features, and the reasons behind the design of one of the features. While I still think that having to implement your own raise() or clone() routine causes mental dissonance in context of throwing exceptions it's not that bad of a solution. I look forward to learning more about this topic. I would love to have you all teach me about this topic and/or show me where to read about it!

CMake and C++11 on MacOS -- Set your variables before creating your target

Taylor R Price — Thu, 02 Jul 2020 23:29:29 +0000

*Note:* This was originally posted on my blog. I'm posting it here for reach. Please let me know what you think!

I’ve been toying with using the Microsoft CPPRestSDK library to practice with REST services and see how easily they’re done in C++. Given that I’d like the project to run on more than one OS, I thought it’d be a good idea to use CMake to build it in several places. This, of course, has required me to refresh my knowledge of CMake. And, of course, I’ve run into a problem with CMake: Getting it to generate a Makefile or XCode project on MacOS that builds and links against C++11.

One big note that I’ll make here is that this post is a description of a problem that I’m having. I will post links to this post in various places where I think I might find answers other than Google, StackOverflow, and the CMake docs where I’ve already looked. If I get a good answer from somebody I will update this post to reflect the changes made.

Problem Solved!

It turns out that I had a misunderstanding of how CMake expected targets to be declared. It expects all properties related to a target before you declare that target with add_executable or add_library. I have updated the CMakeLists.txt to have the properties set before the add_executable call and, lo and behold, it works appropriately. I would like to thank the folks in the CPPLang Slack community for helping me identify that this was the problem. Please see the conclusion for more thoughts on this.

What does the CMakeLists.txt look like?

This, of course, is likely the first question that comes to mind for anybody who knows CMake well. You can find the project here and the CMakeLists.txt here. Given that my project is relatively simple (so far) I’m attracted to the idea that Craig Scott posted. That is to use the following settings:

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

As you can see in my CMakeLists.txt I’ve got these set. You’ll also notice that they’re only set for MSVC. Everybody else gets the following to set -std=c++11 directly:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_definitions(-std=c++11)

Why don’t I use CMAKE_CXX_STANDARD for MacOS?

This is setup this way because, at present, using the CMake variables did not set the command line options correctly for clang on MacOS. If I use CMAKE_CXX_STANDARD to generate Makefiles on MacOS here are the beginning of the compile time errors. These come from the CPPRestSDK headers and are only errors if you’re not compiling with C++11 or above:

[ 50%] Building CXX object CMakeFiles/EveDataRetriever.dir/EveDataRetriever.cpp.o
In file included from /Users/taylor/development/EveDataRetriever/EveDataRetriever.cpp:4:
In file included from /Users/taylor/development/EveDataRetriever/EveDataRetriever.h:6:
In file included from /usr/local/include/cpprest/http_client.h:47:
In file included from /usr/local/include/cpprest/asyncrt_utils.h:17:
In file included from /usr/local/include/pplx/pplxtasks.h:61:
In file included from /usr/local/include/pplx/pplx.h:47:
In file included from /usr/local/include/pplx/pplxlinux.h:27:
In file included from /usr/local/include/boost/thread/condition_variable.hpp:16:
In file included from /usr/local/include/boost/thread/pthread/condition_variable.hpp:9:
In file included from /usr/local/include/boost/thread/detail/platform_time.hpp:19:
In file included from /usr/local/include/boost/chrono/duration.hpp:42:
In file included from /usr/local/include/boost/type_traits/common_type.hpp:22:
In file included from /usr/local/include/boost/type_traits/detail/common_type_impl.hpp:12:
/usr/local/include/boost/type_traits/detail/common_arithmetic_type.hpp:209:75: error: expected expression
    BOOST_STATIC_CONSTANT(int, selector = sizeof(select(cond() ? T() : U())));

You can see the same error displayed in Xcode if I generate an Xcode project and build with it:

Why doesn’t CMAKE_CXX_STANDARD work for me on MacOS?

That is a very good question! I’ve done some googling for how to set the C++ standard to C++11. Most of the pages I’ve found have recommended using the CMake variables to set the standard and, if that doesn’t work, to just set the appropriate flags for the command line. You can see in the CMakeLists.txt that this is what I’ve ended up doing.

These flags are, of course, not portable. This defeats some of the purpose of using CMake. I know there will always have to be some settings that are OS specific but if there’s a way to use CMake to set something for all platforms in a generic manner I’d prefer to do that.

Conclusion

I have re-written this section now that I’ve solved this problem. The Cmake documentation surrounding variables describes that they are dynamically scoped. If add_executable reads the variables at the time it is executed and it is what generates all of the command line flags for the compiler then it makes sense that the variables must be set beforehand.

So, in short, my misunderstanding is where in the CMake process the compile time properties are set. The way it is implemented means that these properties only have to be generated once. This is more efficient than having to regenerate them whenever a variable is changed. I did not find anywhere in the CMake documentation that explicitly warns users to have variables set before creating the target. But, to be fair, I haven’t read ALL the documentation. I hope this helps you in your endeavors with CMake.

VBA How-To: If/Else and Checking For Empty Strings

Taylor R Price — Wed, 01 Jul 2020 21:28:45 +0000

*Note:* This post was originally posted on my blog. I hope posting it here will help reach those whom it will help.

Recently I have been using VBA for a project in Excel and, though I know what I want to express in VBA, I don’t always know the syntax since it isn’t my main programming language. I had to look up the syntax for the if / else conditional clause and how to check whether a string variable is empty. Given that I’m an experienced software engineer and still had to look them up I thought sharing them with you here would be helpful.

Note: Don’t just copy and paste before reading the article. Copying and pasting without understanding is unwise. You do so at your own danger.

If – Then – Else Conditional Statements In VBA

The if – else conditional statement is a staple of any programming language. In each language they have the same meaning. That is if some condition is true then take some action. Otherwise do something else or skip the action. Each language, however, has a slightly different way of saying this; that is each language has a different syntax.

In the case of VBA this is handled as follows (and as described in this guide on Microsoft’s docs website. The documentation is here):

If [condition] Then
    ' code
ElseIf [condition] Then
    ' code
Else
    ' code
End If

Checking String Variables For Emptiness

There are two common checks needed when dealing with data coming from a source outside the control of code you’re writing. These are:

Did I get data or is it empty?
Does the data conform to what I expect and can deal with?

In the case of the code I was writing I’ve got a class with member variables some of which are optional. When I am going to use them to pass the data on I need to know if there is data present to decide what to do with them. The last piece of pertinent information is that I am treating all the variables as strings because I will be sending the data over an API.

Can We Use The IsEmpty() function?

My initial search for how to check whether a string is empty led me to the IsEmpty() function. This seems like a really good fit for what I was looking for. As described in the documentation:

Returns a Boolean value indicating whether a variable has been initialized.

Given that I want to check whether a member variable of my class has been initialized to a value this looks like exactly what I want. As I was about to write this, however, I thought it would be a good idea to test this just to make sure that I am giving you correct information. As such, I wrote this small bit of code:

Sub CheckVarForEmpty()
    Dim stringVar As String
    If IsEmpty(stringVar) = True Then
        MsgBox "Variable Is Empty!"
    End If
End Sub

After writing this I ran this fully expecting to have a message box pop up saying that the variable is empty. However it did NOT pop up.

VBA Debugger To The Rescue!

However, when I debugged the code to make sure that the message box was really being skipped, I noticed that the variable showed that it had the value “”. Now, to me, this looks like an empty string but I decided to write another conditional testing the value of the string against “”:

Sub CheckVarForEmpty()
    Dim stringVar As String
    If stringVar = "" Then
        MsgBox "Varable Is = to Empty String"
    End If
End Sub

Sure enough the message box is shown. Hooray! This means that checking a string against “” successfully determines if a string variable is empty.

Why Didn’t IsEmpty() Work?

However, because I was curious I why IsEmpty() did not return true in my first attempt, I went back to the documentation and read it again. It specifically says that IsEmpty() only returns True if a variable is not initialized or explicitly set to Empty. If you notice in my first example I declare stringVar as a string because I am used to programming in strongly typed languages and it makes sense to me to mark how a variable is to be used. Given that the documentation for IsEmpty() shows examples where the variables were NOT declared with types. This made me wonder if, by declaring a variable with a type, it initializes it to a value (“” in the case of strings). This would make IsEmpty() return False. As such I wrote another test to see if this train of thought is valid:

Sub CheckVarForEmpty()
    Dim myVar
    If IsEmpty(myVar) = True Then
        MsgBox "MyVar is Empty!"
    End If
End Sub

Sure enough the message box in this test popped up as the documentation indicated it would. This, for me, confirms that declaring a variable in VBA as a particular type will initialize it in a manner appropriate for that type.

Conclusion — I always have more to learn

This exercise shows that, despite my years of experience, there are always more things to learn. I hope that this helps you in your adventures in VBA. For me, the next things I will teach myself regarding VBA is more about how classes are constructed and destructed. I hope to bring you more knowledge as I gain it for myself.

Should Remote Workers Use Cameras in Online Meetings?

Taylor R Price — Wed, 01 Jul 2020 19:52:21 +0000

Recently I wrote a post about how important it is to make “context rich” communication a priority. This is especially important for remote teams because gaining context in a discussion is doubly difficult if you’re not together in the same room. Related to this, there’s a thread on Twitter about whether remote employees should have their cameras on during meetings. Given how much context seeing someone’s face gives, I’d like to discuss the pros and cons of turning on video cameras in your remote meeting software during your meetings. My opinion is that, as always, IT DEPENDS!

Cameras Give Context

A big part of a conversation between people is unspoken. Emotion is conveyed strongly on the face of the person you’re speaking with. Having a video camera on while you’re hashing something out gives a way for your team to see your emotion and read your intent. It also lets you see how the listeners in your conversation are receiving what you’re saying. This takes the conversation a long way toward being productive because you can tailor what you’re saying to help clarify a point or defuse tension.

When you’re speaking with a group of people in person it is pretty easy to see the entire body language of all those in the room. This lets you see how people are reacting to what you say and when somebody who might be introverted wants to speak. To use a technical analogy, you have much more bandwidth coming from somebody you can see in person than you get from a small rectangle on a screen.

However when you’re on a conference call it can be hard to tell who wants to speak even when you can see their faces. The fewer people that are on the call the easier it becomes to really pay attention to the faces of those talking. As such I think that cameras really only works for online meetings with few attendees where the goal is to really hash something out. Otherwise the cameras lose their ability to give meaningful context.

People Focus In Different Ways

While it is true that seeing the face of the person you’re communicating with can provide a context rich medium of communication, not everybody communicates well face to face. Some listen better when they can fidget with something or when they can play on their phone. This can make it look like they’re not paying attention.

As such you really need to know the personality of the person you’re talking to if you expect to have a valuable conversation with them. If you aren’t expecting them to speak with you during the meeting or you’re discussing things that don’t involve them directly it may behoove you to not care if they’re paying close attention. If you are intending to have an important discussion with them be aware that they make not look you (or the camera) in the eye. Be patient with your co-workers and communicate with them in the way that works best for them.

Cameras On Only For Small Online Meetings

Having context rich communication really only helps where everybody will be participating (yes, back to this again!). As mentioned earlier, there is more bandwidth for participants of a meeting if everybody is in the same room. However, if everyone is remote there is less bandwidth available and, as such, the number of people that can engage in context rich communication will be limited. My guess is no more than four people will be able to communicate effectively in a context rich manner over a video based conference call though I don’t have the research to back this up.

Maybe Don’t Have Big Meetings?

The bigger a meeting is the more it will trend, by nature, toward information dissemination and away from conversation. There is no point to having all ten, twenty, or one hundred cameras on if the majority of those people will not be saying anything. If you’re disseminating information you don’t need context from those you’re talking to. In reality, though, that kind of meeting should probably have been an email.

Conclusion

I think video cameras are incredibly useful for conversations between a few people meeting to talk deeply about a topic. I’ll generalize that to saying that meetings are a good use of employees time if you need to dive deeply on a topic. This applies whether you’re talking in person or remotely. Meetings setup simply to disseminate information really should be consigned to email to respect the time and talents of your knowledge workers. As such have less meetings and setup the ones you do have to provide the highest level of context rich communication whether that be video cameras or meeting rooms.

Are Your Timeline Expectations Sensible for your Software Project?

Taylor R Price — Thu, 18 Jun 2020 15:04:44 +0000

This was originally posted on my blog. If you like it, please share to extend its reach.

There is a lot of stress going on in the world as I write this post. Presently we are under quarantine due to COVID-19 and lots of folks are working remotely. There are also protests happening across the US in response to the homicide of George Floyd at the hands of a police officer. Everybody is feeling the turmoil. In this stressful time it is important to maintain sensible expectations. This is true in every aspect of life. In this post, however, I want to focus on the creation, delivery, and maintenance of software systems and the timeline expectations generated as part of project management.

This is not a new issue. I even posted about it in January before COVID-19 and the protests started. However, as companies are cutting staff and the amount of work to be done increases for those remaining, it becomes easy to let the stress dictate deadlines. Taking a step back from a situation almost always shows the decisions made under stress to be marginal at best. As such, I want to take a step back and talk about a few things that help to create sensible expectations of a team that creates good software:

What does it take to deliver software changes?
Reasons to rush
How to rush

What does it take to deliver software?

Because my mind works well with lists I’m going to start this section with a list of items it takes to deliver good software in a reasonable amount of time without putting undue stress on anybody. I’ll expand on these after listing them out. They are:

Good requirements
Understanding of existing code
Reasonable testing infrastructure
An understanding of how quickly it is necessary to act
- This one gets it’s own section below

Good Requirements

My definition of “good” requirements: Good requirements are detailed enough for a developer familiar with the business to be able to start work with minimal questions. This means that the requirements need to be more than “this field on the form needs to look like this” or “what I entered on the screen wasn’t saved.” There need to be examples of data that reproduce the problem or highlight the issue to be added. A discussion of why changes are requested reduce questions and help spread the knowledge of the business logic. Such requirements will allow developers and testers to understand the scope of an issue. This understanding will lead to better time to completion estimates which, in turn, will allow for better planning. Better planning and project management, of course, creates sensible expectations (if communicated appropriately of course).

Please note that no single paragraph, no matter how well written, will cover the extent of what good requirements look like. For the sake of this discussion I believe that my description above will do. There are, however, books written on the subject that cover this topic in greater detail. Note: I haven’t read that book specifically but, as a general rule, the books that come out of Microsoft Press are pretty good. If there is a better book on the topic please let me know.

Understanding of existing code

The developers that will be making a change need to understand the code they will be changing. If they haven’t interacted with the code already they will need to spend time reading and playing with it before they can make a change. This will extend the amount of time that it will take the developer to complete their task. It is a requisite for a developer to be able to make the change effectively. That is not to say that developers should be allowed to work only on what they are already familiar with. The plan to approach a project just needs to include extra time for a developer to learn in order for the expectations laid upon them to remain sensible.

There are ways to mitigate the penalty of a developer having to learn a new area of code. Since this isn’t the main point of the post, I will keep this short: All of the ways to mitigate the learning process boil down to implementing patterns: good design patterns, common calling conventions, and frameworks that implement APIs in ways developers will recognize.

Reasonable testing infrastructure

This is yet another gigantic topic that I am going to breeze over for the sake of making the point that this infrastructure needs to be reasonable to deliver software in a reasonable timeline. The items that, at a minimum, need to be setup are:

A clear and simple release management process (that is, how a change flows from a developer through testing and on to production)
Quality assurance (QA) and user acceptance testing (UAT) teams that knows how to test quickly in both a manual and automated manner
An attitude among all the teams (Dev, QA, and UAT) that allows all of them to work together instead of being territorial about solving problems.

I’ve spent most of my career as a developer and, as such, I have not spent time gathering books and other resources for testing. Please let me know if you have resources to put here.

Acceptable reasons to rush

There are a few reasons that I can think of that are legitimate reasons to cut corners. These include:

Production environment is broken
Governmental regulations change deadline looming
Achieving first to market status

Only rush when it’s necessaryWith the exception of the production environment being broken I would argue that even these important reasons shouldn’t cause a crunch. The requirements planning phase of a project should plan for a minimally viable product (MVP) and a fully featured product. As a due date approaches requirements should be cut from the product as necessary to finish what can be finished with quality. These are all things that I have witnesses a great project manager handle.

How to rush when you need to

Here we can get to my definition of “rush”. Rushing, to me, includes cutting corners from the development process. This means skipping writing automated tests (either from dev or QA), reducing the manual testing process to the happy path, and, as a last resort, having employees work overtime.

After finishing a project it is critical to do a retrospective on the rush that covers:

Why the rush was needed
What was done to solve the problem
What parts of the normal process were skipped
What can be done to retroactively address the process parts that were skipped.

Completing this retrospective and giving time to solve technical debt accrued during a rush is, from my experience, the item that is most often skipped by companies. The reason for this is often that most projects are treated as emergencies that cannot be put off to handle tasks that aren’t part of the projects. This way of thinking snowballs into a code base that is a gigantic plate of spaghetti and a team that is paralyzed with fear at dealing with certain projects. Taking time to figure out what happened is important!

Don’t use these reasons all the time

Rushing should be like salt; used sparingly. While it feels great to get something solved and out the door quickly that feeling is addictive. If a team rushes all the time it will find itself cutting corners on the ways to deliver good software. The more the corners are cut the harder it will be to get them instituted again. It’s a vicious cycle.

Personal Responsibility

Recently a connection read and reviewed Mentoring a Software Engineering Team and gave me a great piece of feedback: I’d failed to comment on the responsibility each team member has to complete their tasks. This article on sensible timelines is a good place to address this issue.

Just as it is my job as a tech lead / senior engineer on my team to clear a path for the other engineers to get their work done it is their job to reciprocate this effort and get their work done. This includes:

Completing tasks in a timely manner
Communicating clearly when there is an issue including
- Unclear requirements
- Timelines that are too aggressive
- Environmental blockers

Please note that taking personal responsibility does not mean working excessive hours. As discussed in this post sensible expectations for when work can be delivered are critical. Part of developing sensible expectations means planning for all team members to recreate and rest. Team members reporting lots of hours for tasks on a regular basis should be a red flag to spend time re-evaluating timeline expectations.

Conclusion

Coming to the end of this post I feel like I have written a large advertisement for Rework from the folks at Basecamp. Please go read it. Rework talks about creating a business as a whole that will avoid many of the reasons to rush and, as such, it may disagree with what I’ve said here.

That being said I’ve only ever worked at companies that often worked in a panic without sensible expectations of how quickly software can be delivered. I have often had to tell the folks I work with to go home, rest, and come back to reevaluate their expectations of how long tasks should take to get done. I will repeat the same thing here to you:

*Go get out of the office, recreate, and rest. Only then will you be able to see clearly what *actually needs to be done and how to best go about it.

How To Make Remote Work Possible

Taylor R Price — Thu, 21 Nov 2019 17:50:13 +0000

This was originally posted on my blog. If you like it, please share to extend its reach.

I have worked both in the office and full time remote for the same company over the nine years that I've worked there. Given my time doing both, I'd like to share some of the insights that I found. My hope is to provide companies and teams a suggestions to make them more productive and effective with both co-located and remote employees. In short, I'd like to help you make remote work possible.

Side Note: If you're considering starting a remote team, please read Remote: Office Not Required by Jason Fried and DHH. What I'm going to say here is said more eloquently there.

Get The Right Tools

There need to be simple, clear, and obvious ways of communicating. If an employee needs specific type of information or to communicate in a specific way they should not have to guess where to go or how to do this. This means having a single tool for each kind of communication. That includes:

A text chat tool
A video/voice chat tool
A long form text tool
Bug tracking software

There are a couple caveats I’d like to include. The text chat tool needs to handle both two person chat and group/team chat. If the video/voice chat tool is rolled into the text chat app (like Microsoft Teams or Basecamp) so much the better. The long form text tool should be THE place for things like documentation, plans, etc. Lastly, the bug tracking software should be able to integrate with (or at least take links to) the long form text app so that stories can be tied to documentation.

Prioritize Asynchronous Communication

Humans, by nature, are social creatures. Some of us are introverts but, at the end of the day, we all need to socialize with our friends to some degree. Because we are at work many hours of our lives it is only natural to make friends and be social at work. Remote work certainly makes this difficult and I am aware of that. Please read what I have to say here with the understanding that I do enjoy social interaction and am not looking to discourage it. What I have to say here is for the purpose of making our work time more productive.

People need time for thought work

When I go to dig into a bug report or feature I need time to do several things:

Build context on the subject in my mind
Understand the change being requested
Plan how to make the change
Implement the change
Test the change

If I've been working in a particular area of code recently or on a project that the change is related to these steps may happen quickly. In this case I've already got much of the context of the problem and the code in my brain.

If, however, the arena of the problem is new to me this process can take a long time. Usually, I need to spend a lot of this time by myself building a mental model of the problem, our current solution, and what we want to do. Of course there will be a point in this process where I have enough context to ask good questions of others involved but, until then, that cannot happen. This is where remote work really shines.

People need lack of distraction for thought work

In order for me to truly focus on building the aforementioned context I need not only time but a lack of distraction. I need to be able to put aside my worries about all of the other tasks I am responsible for so that I can focus on *this* one.

Don’t distract the workers

This all leads to the main point of this section. I am VERY capable of distracting myself without any external help. I would go so far as to consider myself an expert at distracting myself. In order to really focus on the task in front of me I need to temporarily put aside all the things that distract me. This includes things I typically want to read, watch, or play on my phone or computer.

This includes your messages in all their forms.

Please don’t take this personally. It’s about me not you. What it does mean, however, is that I need to ignore you for a while so that I can get this task done. Believe me, I appreciate you and I WILL come back to what you’ve said and answer you. It will just be after I’ve accomplished enough on this topic that I feel comfortable taking a break.

Put ALL Of Your Meetings On The Calendar

During the period that I worked remotely full time the company had few remote employees. None of them were full time remote workers other than I. As a result many of my co-workers fell back on "out of sight, out of mind" and treated those in the office as the only ones working. They did not do this on purpose but it, nevertheless, is what happened.

When something needed to be communicated quickly impromptu meetings were often called by walking around and gathering everybody who needed to participate. This led to situations where I would report something only to be asked why I'd worked on it. It was clear from the meeting a few days ago that we weren't going to do that. Except that it was an impromptu meeting that hadn't included anybody who was remote at the time. At this point everybody would apologize and we would figure out how to move forward.

This has led me to the opinion that all meetings should be scheduled on the calendars of those who should be included. Even if it is a short meeting that you want to have quickly, it should be sent as an invite with enough time for those who are remote to find it and be able to hop on the call. This will make sure that everybody who needs to be there can truly be there. I will re-iterate that I don't think any of my co-workers did this intentionally. The issue simply presented itself as a result of everybody working in the office.

Be a Remote First Team

All of these suggestions are ways to help smooth communication with team members who are remote. The hardest shift for a company to make, however, is the mindset of the existing employees. The mindset needs to be that a team is a remote team regardless of whether parts of the team are co-located. That is, the team is a remote first team.

What does a Remote First Team look like?

This depends on the members of your team and how well each person handles working remotely. As pointed out by Rebecca Corliss in her article Why “Remote-First” is Actually a Dangerous Mindset, some folks thrive from working in person. As I've mentioned in Three Important Points of Communication, talking over voice or in person is often the most efficient way to communicate.

If your team has members who are co-located and work better face to face, I suggest that meetings be run in a hybrid manner. This means having TVs, phone systems, and cameras in conference rooms. When meetings are run, those who are co-located head to the conference room and dial into the meeting. These employees, however, need to make sure that they remember to give space for remote employees to speak. Interrupting several people talking face to face from over the phone is difficult. If your team can handle being fully remote for a meeting, this makes taking turns speaking much easier because everybody has speak up over the phone.

Conclusion

Given the correct tools and mindset working remotely with a team can be a wonderful experience. The main thought I want to leave you with is this -- if you can learn to be patient and communicate asynchronously you will get a large percentage of the way toward being and effective remote team. If it's truly urgent pick up the phone and talk to your co-workers. And don't forget to socialize with your co-workers because working with friends can be great fun.

Addressing Arguments Against Unit Testing

Taylor R Price — Tue, 19 Nov 2019 02:24:47 +0000

This was originally posted on my blog. Thanks for taking the time to read it here!

I re-read my post about convincing a team to start unit testing and realized that, when addressing developers, I really only talked about resisting the urge to go crazy when refactoring. I didn’t, however, actually address convincing them to start testing beyond the general arguments for unit testing. One place that I recommend everybody start is this course created by Angie Jones at TestAutomationU. It’s got lots of great content related directly to this conversation, it’s well done, and it’s free with the exception of your time (of course). I recommend it highly enough that you should go NOW and, at a minimum, start the course. (And no they’re not paying me to say this) Now that you’re back, let’s get on to what I originally planned to talk about. That is the arguments that the developers that I work with have against testing even though they told me that the general benefits of testing I presented make sense.

Arguments Against Testing

My project is late

As I’ve worked with my team to start testing, I’ve heard several variations of this argument which are:

I’m already over my estimated time to finish, I haven’t started writing tests, and we didn’t estimate time to write tests into my work
We’ve been working on this for a while and our clients have started asking about time to completion (or I’m worried they will start asking soon)

Both of these statements end in the developer asking how they could possibly start testing now on this specific project. The fear surrounding trying to test when it hasn’t been planned for is totally valid. And yet my response to this is usually: “when are you going to have a project that isn’t under a crazy deadline?” If the answer is that you’ll never have time you should start planning time for testing on your next project. Or, better yet, the next part of your current project that you’ll be responsible for. Testing will make things busier and, possibly, more stressful in the short term but will reduce those things greatly over the long term as the code base becomes tested and reliable. In my experience these questions come up in environments that have lots of work to do and where work is expected to be done without delay in the quickest manner possible. This is precisely the case where testing will help the most over time and is the least likely to be supported by schedule, users, clients, management, or any combination of the above.

My project is high priority

This is really a variant of “my project is late” with the exception that the project is late before you’ve started working on it. Usually because it has high visibility to somebody in the company that can throw their weight around. Ok, that’s not always the case but, as in the case of a late project and until your team has developed good testing habits, you may want to punt until the next project to test (even though this project would benefit from testing). So far my answers have been “punt until the next project.” I really do want you to start testing BUT I want you to do it in a way that stands a chance of succeeding on project after project until it becomes habit.

The code I’m working on is too complex

Now we’re past the “I don’t have time” arguments into something that can be turned into actual tests. If your code base has been around for any significant amount of time, this is the issue you’re going to present me with as soon as you actually try to start testing. By “significant amount of time” what I mean is any code that has been developed without tests (per, as always, Michael Feathers in Working Effectively with Legacy Code). I will freely admit that your code is very complex. If it has been around for any length of time (and has survived its way to production), I have no doubt as to both it’s usefulness and complexity. That being said, that is not a reason for you to skip testing. It will simply mean that it will take you a lot of effort to:

Figure out what to test
Figure out how to test what you’ve decided to test
Refactor the code so that it is testable

This will be HARD and will cause arguments about what, when, how, priority, and schedule. Hard, however, is not a reason not to test and the arguments are ok. They mean that you’re actively talking about how to make your code and team habits better; that is a GOOD thing. I promise you that the refactoring you’ll have to do will make your code better. I promise that the tests you write will become trip wires that safe guard further changes. And I promise that your code will become more understandable as you break it up and document it with your tests. I will just take time.

There is too much refactoring required

I spoke about this in my last post a fair bit so I won’t beat it to death here. Lots of refactoring means that it will take more time to get your code completely covered with tests. I understand that refactoring takes time away from fixing bugs and adding new features that are critical. I also understand that refactoring may lead to changes that are separate from the specific feature or but that you’re changing and that will cause more testing for your QA / UAT staff. Yes, this additional work is a pain RIGHT NOW but, in the long run, you’ll be rewarded for spending the time with reduced time for and more confidence in changes in the future.

Conclusion

TESTING IS HARD BUT NECESSARY. The benefits of testing apply to an existing code base but are difficult to get to. It takes persistence and the development of habits. But you’ll get there over time. I would love to hear what has worked for you or what issues have come up in your testing journey in the comments, on Twitter, or via email (taylor@taylorbuiltsolutions.com).

Yet More Reasons to Build a Remote Team

Taylor R Price — Mon, 18 Nov 2019 07:20:42 +0000

This was originally posted on my blog. I hope that it will gain more reach by posting here.

Recently I've been reading a lot about remote work and have written about it. I've also written recently about the value of context rich communication such as talking on the phone or in person. There were some points regarding the value of building a remote team that I missed in my last post and want to communicate here. These include finding talent in places you might not expect, finding talent that doesn't look like you expect, and providing a way for your creative workers to focus in a comfortable manner.

I listen regularly to the Rework Podcast (by Basecamp) and they recently produced the episode named Cult of Overwork. As I was listening I realized that a LOT of the dialog sounded very familiar. After looking at the episode page I realized that I'd read the Cult of Overwork article on Medium written by Ty Fujimura, who they were interviewing, soon after it was written last year. There's a lot in there that I agree with and, as such, there will be a lot of information written here that is very similar to what was written there. Hopefully we'll bring wider reach to the topic of remote working by having more people cover the topic. By stating the arguments in my own way I hope that it makes sense to you if it didn’t make sense when others have explained it.

Find talent in areas other than your metropolis

There are hot spots / tech hubs throughout the country. Though this isn’t a complete list but Silicon Valley, Silicon Beach (Santa Monica / Los Angeles), New York, and Austin all come to mind immediately for me. These are meccas for those who want to be in tech and want to have an interesting and well paying job. And, as such, the big companies have all opened large offices in these areas. As the cycle of people gathering and companies starting/gathering has continued the housing prices and commute times have increased commensurately. This is a negative impact on the life of everyone who lives in these areas.

What about the talent that cannot move to a tech hub?

There are an incredible wealth of talented folks who live outside of the tech hubs. Many of them do not have the option of moving to a tech hub for a variety of reasons. The most important and urgent reason to me is cost. There are folks who have taken it upon themselves to learn how to become a developer, devops engineer, security analyst, or . What happens when they cannot find a job near where they live, a remote job, or can not afford to live in a tech hub? Others would love to be able to train themselves but do not have physical coding bootcamps nearby, the knowledge of where to find training online, or the equipment to take advantage of them even if such equipment is "cheap". (Note that this is an assumption given that I haven’t posted a study to prove it. I’d like to think that it’s a good assumption because we should always be seeking ways to lift up those who aren’t as fortunate as we are. I’ll post this on that basis and continue to look for studies that prove it)

What can we do about this particular issue?

Regarding the problem of employing the currently talented folks the obvious answer is to start hiring remotely. If you give people the chance to work remotely and set aside your biases of what an employee should look like you'll be able to start finding folks to fill your needs. Yes, post your positions on the normal job boards, but also take a proactive approach and reach out to communities on social media where such folks gather.

If you are a member of a community of tech folks who live outside of a major tech hub or are otherwise under-represented in tech please comment and let hiring managers know where to find you. Please message me with contact information on any available platform (email, Twitter, Facebook, or LinkedIn) and I’ll update this post with your information. I’ll also create another post about this issue with your info to extend the reach of the information.

UPDATE -- Options suggested from the community

After posting this article on Twitter, I received lots of great suggestions that I wouldn't have thought of given my background. The first set of advice that I'd like to offer comes from Tae'lur Alexis and gives a list of online code academies that are free or low cost. This suggestion provides a way for those without a ton of resources to teach themselves. Tae'lur herself raised herself to a career this way and these schools can provide an option for you to do that as well.

The second set of options comes from Angie Jones and surrounds how hiring managers can reach out to communities that are currently underrepresented in tech. These suggestions provide opportunities for companies to find talent in places that they might not normally look.

Her first suggestion is to connect with the career centers or engineering departments at HBCUs and ask them for a list of their best students. If a company gives these students interesting projects to work on it is a win-win for both the company and the students. The students get practical hands on experience and the company gets potential future employees.

Angie's second suggestion is for companies to send representatives to the various Black tech conferences that occur every year (including NSBE, AfroTech, and BDPA). As with many conferences, lots of top talent goes to conferences every year to learn and network. This suggestion would also work for other underrepresented communities that hold conferences every year.

Lastly, Angie suggests connecting with communities on social media who are focused on curating content for people of an underrepresented group in tech. Angie's suggestions include Black Tech Pipeline, Tech Stack'd, and Women in Linux. William Hill also suggested this and suggested /dev/color, Lesbians Who Tech & Allies, Next Play Events, and DatCode.

Thank you to all of those who have given suggestions on where to look to help bring people into tech who don't look like the current norm. I will continue to take suggestions and will likely create another post with more suggestions.

Options other than hiring remotely

Other than being willing to hire remotely and/or hire somebody who doesn't look like you, how can you help this problem? That is a good question that I honestly don't have a single, complete, or "correct" answer to. If anybody who reads this has resources to help teach people, give people the opportunity to get interviews, or otherwise lift others up, PLEASE reach out. I'll be happy to update this post with resources. That being said here are some things that come to mind immediately:

Setup an internship program
Support STEAM programs in schools
Start or support coding boot camps
Start or support scholarship programs at universities or boot camps

I’ll put the same disclaimer here as above. These are just ideas that came to me as I wrote this. Please take some time to do some research into the effectiveness of these in general and, if the data is available, the effectiveness in your community. I will continue to read on this subject as well. Please leave me a message somewhere and let me know if you've worked on these things and let's get the information out on how to be effective.

Parents have skills that translate well to the workplace

Ty's article had a paragraph about parents that resonated really well with me given that I’m a parent. The summarized version is that parents are very busy taking care of their children. They have lots of things to do and have to learn to prioritize effectively. By nature this forces parents to learn how to be as productive as possible in the short amounts of time they have available. These skills are directly transferable to the workplace. Ty says this well enough in his article that I would like to quote him here:

Parents bring unique and invaluable perspective to a team. When you take care of children, you have no choice but to grow more patient and more resilient. In giving so much to a child, you sublimate your ego. You learn how to teach, to motivate, and to energize another human being. You learn how to prioritize, and get the most out of short bursts of productive time. You learn how to push yourself harder than ever before. Who doesn’t want a teammate with those skills?

You can only focus for a certain length of time

There have been studies done on the capability of humans to focus creatively. Many of the studies show that there is a fairly hard limit at four hours of work per day that requires deep thought and creativity. In addition to Ty’s article, an article by Alex Soojung-Kim Pang in The Week talks about this and makes reference to the study by K. Anders Ericsson, Ralf Th. Krampe, and Clemens Tesch-Romer regarding the practice habits of violin students. The study talks about the necessity of practicing not only deliberately but not so much in a given day that you burn out.

My anecdotal assessment from my experience as a software engineer backs up this idea. In a given day, there are only a few hours in which I can really get into the flow of programming and be productive. Once those hours are spent I find that I begin distracting myself. While I can get more work done it tends to be routine work that doesn’t require a ton of creativity. There is, of course, lots of other work to be done in the course of running a business. Requirements gathering, planning, status updates, and team communication (among other things, of course). These are often the tasks I fall back on when I’m not actively being creative.

How does this relate to remote work, you ask? Getting into this state of focus is much easier without the distractions that come in an office with all of the people and noise that are there. There are, of course, plenty of distractions at home but, if an employee can be comfortable and turn off all forms of communication for a while focusing becomes much easier and more likely.

How we communicate with each other as a team also factors into this. If an team member is visibly sitting at their desk nearby it is easy to think that they are interruptible to help us solve our problem. The more energy it takes to communicate with somebody in a context rich fashion the more likely it is that we’ll be ok communicating asynchronously. If somebody is working remotely, it becomes much easier to communicate via message and only call when it really is critical to get information communicated quickly. This is yet another way that we can help our teammates get into their zone of focus.

Conclusion

There are many reasons to work remotely or setup a remote team if your goal is to produce creative work (software, writing, art). I understand that many people value the connection, ability to communicate, and ability to make decisions quickly that comes with being together in person. That being said please consider how much of the in person communication actually has to happen in person. If you can make use of other ways to communicate richly (phone / video chat) and practice asynchronous communication you'll open a world of possible co-workers, customers, and productivity.