Browsed by
Author: Kevin

Errors and Punishment – The Art of Debugging

Errors and Punishment – The Art of Debugging

So recently I have been blessed enough to talk to several people, who are new to the software development field, and been able to do some mentoring. And firstly, I’m the one that’s lucky for this, as there are few things better than meeting with people who are new to this industry and getting to engage with their ideas. If it isn’t something you do regularly, you should start.

But one of the things that has become very much apparent to me, just how little time is spent actually teaching how to debug. I know I saw this when I was teaching, but there’s this tendency by many in academy to show students how to code, and when they run into errors show them how to fix them. Which at it’s core sounds like “Yes, Kevin that’s what teachers do…” but I would actually argue it is a fundamentally flawed principle. The reason being that error messages and fixing things that are broken is a pretty large part of being a developer, and by giving junior developers the answer, we are doing the preverbal “giving them a fish, rather than teaching them to fish.”

To that end, I wanted to at least start the conversation on the a mindset for debugging, and how to figure out what to do when you encounter an error. Now obviously I can’t cover everything, but I wanted to give some key tips to how to approach debugging when you have an error message.

Honestly, debugging is a lot like a police procedural, and it’s a good way to remember the steps, so hang with me through the metaphor.

Tip #1 – Start at the Scene of the Crime – The Error Message

Let’s be honest

Now I know this sounds basic, but you would be surprised how often even senior devs make this mistake. Take the time to stop, and really read the error message and what I mean by that is do the following:]

  • What does the error message tell you?
  • Can you find where the error is occurring?
  • Is there a StackTrace?
  • What component or microservice is throwing the error?
  • What is the error type?

Looking at an error message is not just reading the words of the error, but there are usually other clues that can help you solve the mystery. Things such as the exception type, or a stack trace where you can find the exact line of the code is going to be critical.

Honestly, most people just read the words and then start making assumptions about where an error occurred. And this can be dangerous right out of the gate.

Tip #2 – Look for Witnesses – Digging through logs

Now, in my experience an error message is only 1 piece of the puzzle / mystery, the next step is to really look for more information. If you think about a police procedural on TV, they start at crime scene, but what do they do next…talk to witnesses!

Now, in terms of debugging we have the added benefit of being able to refer to logs. Most applications have some form of logging, even if it’s just outputting messages to a console window, and that information can be very valuable in determining an error message’s meaning.

Start looking for logs that were captured around the same time, specially looking for:

  • What was occurring right before the error?
  • What data was being moved through the solution?
  • What was the request volume that the system was handling?
  • Were there any other errors around the same time?

Any information you can find in the logs is critical to identifying and fixing the issue.

Tip #3 – Deal only in facts

Now this next on, is absolutely critical, and all to commonly overlooked. Many developers will start making assumptions as this point, and start immediately announcing, I know what it is and start changing things. Resist this urge, no matter what.

Now, I’m not going to lie, some errors are easy and with a little bit of searching it becomes really easy to see the cause and address it, and if you are 100% sure, that should be the case. But I would argue in the TV procedural perspective, this is the different between the rookie and the veteran. If you are new to this field, resist the urge to jump to an answer and only deal in facts.

What I mean by this is to not start letting your jumping to conclusions cloud the story you are building of what occurred and why.

Tip #4 – Keep a running log of findings and things you tried

This is something I do, that I started and it pays dividends. Just like the cops in a police procedural, they make a case file as soon as they capture their original findings, and you should to. Keep a running document, either in word, or for me I use OneNote. I will copy into that document all the findings.

  • Error Messages
  • Relevant Logs
  • Configuration Information
  • Dates / times of the errors occurring
  • Links to documentation

Anything I find and I will keep appending new information to the document as I find it.

Tip #5 – Look for changes

The other key piece of evidence most people overlook is the obvious question of “What changed?” Code is static, and does not degrade at the code level overtime. If it was working before and isn’t anymore, something changed. Look for what might have changed in the solution:

  • Was code updated?
  • Were packages or libraries updated?
  • Was a dependency updated?
  • Was their a hardware change?

All of this is valuable evidence to helping to find your reason.

Tip #6 – Check documentation

A good next step is to check any documentation, and what I mean by this is look to any reference material that could explain to you how the code is supposed to work. This can include the following:

  • Documentation on libraries and packages
  • ReadMe / GitHub issues / System Docs
  • Code Comments

Anything can help you better understand how the code is supposed to work and identify the actual way the code is supposed to behave.

Tip #7 – Trust Nothing – Especially your own code

At this stage, again people like to make assumptions, and I can’t tell you the number of times I have done this personally, but you stare at code and say it doesn’t make sense. I know X, and Y, and Z are correct, so why is it failing? Only to find out one of your assumptions about X, Y, or Z was false. You need to throw all assumptions out the window and if necessary go and manually verify everything you can. This will help you identify the underlying problem in the end.

Also at this stage I see the other common mistake. Keep your ego out of debugging. Many developers will look at the code they’ve built and they trust it because they built it. But this bias is usually the most damaging to your investigation.

Similar to the running joke of “The husband always did it…” I recommend adopting the philosophy of “Guilty until proven innocent” when it comes to any code you write. Assume that something in your code is broken, and until you can prove it, don’t start looking elsewhere. This will help in the long run.

Let me give an example, let’s say I am building code that hits an API, and I write my code and it looks good to me, and I go to run it and I get back a 404 error saying not found. I’ve all too often seen devs that would then ping the API team to see if their service is down, or networking to see if something is blocking the traffic, all before even looking to see “Did I get the endpoint right?”

Doing this makes you look foolish, and wastes people’s time. It’s better to verify that your code is working properly, and then that will empower you to have that conversation with networking as:

You: “I think it’s a networking issue.”

Network Engineer: “Why do you think that?”

You: “I’ve done the following to rule out anything else…so I think it could be ________________”

Tip #8 – Try to reproduce in isolation / Don’t Make it a hatchet job!

If you get stuck at this point, a good trick I find is to try and reproduce the error in isolation, especially when you are looking at a microservice architecture, there can be a lot of moving parts. But it can be helpful to try and recreate an error away from the existing code base by isolating components. This can make things easier to give evidence, and not unlike a police procedural where they try to reproduce the events of a theory, it can be a great way to isolate a problem.

The one thing to try really hard to avoid, is taking a hatchet to code, all too many times I’ve seen people start doing this pattern to solve a problem:

  • I’m going to try this…
  • Run Code
  • Still Broken…
  • Change this…
  • Run Code
  • Still Broken…

You are actually making your life harder by not being methodical, now I’m not saying don’t try things, but try to be more deliberate and make sure you take time to log your thoughts and attempts if your running log. This can be critical to keeping things logical and methodical and not spinning your wheels.

Tip #9 – When you find the answer right it down.

When you finally find the answer, there is this tendency to celebrate, and push that commit, cut that PR and be done. But really your not doing yourself any favors if you stop there. I find it helpful to make sure you take the time to answer the following:

  • Do I fully understand why this occurred?
  • Can I document and explain this?
  • Am I convinced this is the best fix for this problem?

Really you want to make sure you have a full understanding and complete your running log by documenting the findings so that you can refer to them in the future.

Tip #10 – Make it easier and test in the future

The other thing that is largely overlooked and skipped due to the “Fix Celebration” is the debrief on the issue. All to often we stop and assume that we are done because we made the fix. But really we should be looking at the following:

  • Is there an automated way I can test for this bug?
  • How will I monitor to make sure my fix worked?
  • Does this hot fix require further work down the line?
  • Does this fix introduce any technical debt?
  • What can I do to make this type of error easier to debug in the future?
  • What parts of the debug and testing cycle made it hard to identify this error?
  • What could I have done differently to make this go faster?
  • What does this experience teach me?

These kinds of questions are critical to ongoing success in your software development career and the health of your project longer term.

I hope you found these 10 tips helpful!

How to leverage a private modules in your YAML Pipelines

How to leverage a private modules in your YAML Pipelines

I’ve made no secret about my love of DevOps, and to be honest, over the past few months it’s been more apparent to me than ever before that these practices are what makes developers more productive. And taking the time to setup these processes correctly are extremely valuable and will pay significant dividends over the life of the project.

Now that being said, I’ve also been doing a lot of work with Python, and honestly I’m really enjoying it. It’s one of those languages that is fairly easy to pickup but the options and opportunities based on it’s flexibility take longer to master. But one of the things I’m thankful we started doing was leveraging python modules to empower our code re-use.

The ability to leverage pip to install modules into containers creates this amazing ability to separate the business logic from the compute implementation.

To that end, there’s a pretty common problem, that I’m surprised is not more documented. And that’s if you’ve built python modules, and deployed them to a private artifact feed, how can you pull those same modules into a docker container to be used.

Step 1 – Create a Personal Access Token

The first part of this is creating a personal access token in ADO, which you can find instructions for here. The key to this though is the PAT must have access to the packages section, and I recommend read access.

Step 2 – Update DockerFile to accept an argument

Next we need to update our Dockerfile to be able to accept an argument so that we can pass that url. You’ll need to build out the url your going to use by doing the following:

https://{PAT}{organization}/{project id}/_packaging/{feed name}/pypi/simple/

Step 3 – Update YAML file to pass argument

This is done by adding the following to your docker file:

ARG feed_url=""
RUN pip install --upgrade pip
RUN pip install -r requirements.txt --index-url="${feed_url}"

The above will provide the ability to pass the url required for accessing the private feed into the process of building a docker image. This can be done in the YAML file by using the following:

- task: Bash@3
    targetType: 'inline'
    script: 'docker build -t="$(container_registry_name)/$(image_name):latest" -f="./DockerFile" . --build-arg feed_url="$(feed_url)"'
    workingDirectory: '$(Agent.BuildDirectory)'
  displayName: "Build Docker Image"

At this point, you can create your requirements file with all the appropriate packages and it will build when you run your automated build for your container image.

How to leverage templates in YAML Pipelines

How to leverage templates in YAML Pipelines

So now secret that I really am a big fan of leveraging DevOps to extend your productivity. I’ve had the privilege of working on smaller teams that have accomplished far more than anyone could have predicted. And honestly the key principle that is always at the center of those efforts is treat everything as a repeatable activity.

Now, if you look at the idea of a micro service application, at it’s core its several different services that are independently deployable, and at it’s core that statement can cause a lot of excessive technical debt from a DevOps perspective.

For example, if I encapsulate all logic into separate python modules, I need a pipeline for each module, and those pipelines look almost identical.

Or if I’m deploying docker containers, my pipelines for each service likely look almost identical. See the pattern here?

Now imagine, you do this and build a robust application with 20-30 services running in containers. In the above, that means if I have to change their deployment pipeline, by adding say a new environment, I have to update between 20 – 30 pipelines, with the same changes.

Thankfully, ADO has an answer to this, in the use of templates. The idea here is we create a repo within ADO for our deployment templates, which contain the majority of the logic to deploy our services and then call those templates in each service.

For this example, I’ve built a template that I use to deploy a docker container and push it to a container registry, which is a pretty common practice.

The logic to implement it is fairly simple and looks like the following:

    - repository: templates
      type: git
      name: "TestProject/templates"

Using the above code will enable your pipeline to pull from a separate git repo, and then you can use the following to code to create a sample template:

  - name: imageName
    type: string
  - name: containerRegistryName
    type: string

  - name: repositoryName
    type: string

  - name: containerRegistryConnection
    type: string

  - name: tag
    type: string

- task: Bash@3
    targetType: 'inline'
    script: 'docker build -t="${{ parameters.containerRegistryName }}/${{ parameters.imageName }}:${{ parameters.tag }}" -t="${{ parameters.containerRegistryName }}/${{ parameters.imageName }}:latest" -f="./Dockerfile" .'
    workingDirectory: '$(Agent.BuildDirectory)/container'
  displayName: "Building docker container"

- task: Docker@2
    containerRegistry: '${{ parameters.containerRegistryConnection }}'
    repository: '${{ parameters.imageName }}'
    command: 'push'
    tags: |
  displayName: "Pushing container to registry"

Finally, you can go to any yaml pipeline in your project and use the following to reference the template:

- template: /containers/container.yml@templates
    imageName: $(imageName)
    containerRegistryName: $(containerRegistry)
    repositoryName: $(repositoryName)
    containerRegistryConnection: 'AG-ASCII-GSMP-boxaimarketopsacr'
    tag: $(tag)
Poly-Repo vs Mono-Repo

Poly-Repo vs Mono-Repo

So I’ve been doing a lot of DevOps work recently, and one of the bigger topic of discussions I’ve been a part of recently is this idea of Mono-Repo vs Poly-Repo. And I thought I would way in with some of my thoughts on this.

So first and foremost, let’s talk about what the difference is. Mono-Repo vs Poly-Repo, actually refers to how you store your source control. Now I don’t care if you are using Azure Dev Ops, GitHub, BitBucket, or any other solution. The idea here is whether you put the entirety of your source code in a single repo, or if you split it up into multiple repositories.

Now this doesn’t sound like a big deal, or might not make sense depending on the type of development code, but this also ties into the idea of Microservices. If you think about a micro-services, and the nature of them, then the debate about repos becomes apparent.

This can be a hot-debated statement, but most modern application development involves distributed solutions and architectures with Micro-services, whether you are deploying to a server-less environment, or even to Kubernetes, most modern applications involve a lot of completely separate micro-services that provide the total functionality.

And this is where the debate comes into play, the idea that let’s say your application is actually made of a series of smaller micro service containers that are being used to completely overall functionality. Then how do you store them in source control. Does each service get it’s own repository or do you have one repository with all your services in folders.

When we look at Mono-Repo, it’s not without benefits:

  • Easier to interact with
  • Easier to handle changes that cut across multiple services
  • Pull Requests are all localized

But it isn’t without it’s downsides:

  • Harder to control from a security perspective
  • Makes it easier to inject bad practices
  • Can make versioning much more difficult

And really in a lot of ways Poly-Repo can really read like the opposite of what’s above.

For me, I prefer poly-repo, and I’ll tell you why. Ultimately it can create some more overhead, but I find it leads to better isolation and enforcement of good development practices. But making each repo responsible for containing a single service and all of it’s components it makes for a much cleaner development experience and makes it much easier to maintain that isolation and avoid letting bad practices slip in.

Now I do believe is making repos for single purposes, and that includes things like a templates repo for deployment components and GitOps pieces. But I like the idea that to make a change to a service the workflow is:

  • Clone the Services Repo
  • Make changes
  • Test changes
  • PR changes
  • PR kicks off automated deployment

It helps to keep each of these services as independently deplorable in this model which is ultimately where you want to be as opposed to building multiple services at once.

How to start a New Job in a Pandemic

How to start a New Job in a Pandemic

So if you find me on LinkedIn, you know that I recently changed job at my current company. And changing roles is something that many of us have had to deal with several times in our careers. Even if you’ve been able to work at the same place for most of your career, it’s more than likely that you’ve had to change roles, or even teams at one point.

Now this time was a little different, mainly because it was in a pandemic. In previous roles, I would say I was a “mobile worker” and then a mix of “remote and mobile” (probably a blog post on the differences coming). But in all cases, I would go to an office for the initial transition, and at least meet people face to face. But thanks to COVID-19, that became impossible.

So this was the first time I’ve had to transition jobs in a completely remote position. And more than that I’ve noticed I’m not alone, having friends who are going through the exact same thing. Now through this experience, there were somethings I was able to do to help myself, and other things I learned for next time. And in this post I hope to capture both. So here are some tips and tricks to starting a new job in a 100% remote capacity.

Tip #1 – Make sure you fully transitioned

This is the first thing I will point out, and may not apply to everyone. If you are changing roles at your current company though, this can definitely be important. As you gear up to transition from one role to another, it’s especially important that you make sure you are able to close out your current responsibilities to prepare for your new roles responsibilities. This sounds like common sense, but I have seen in the past how this can go horribly wrong.

Because you are a remote worker, its easy for some manager or team mates to think that because you aren’t physically moving, or are still working for the same organization that you can be available after your start date at your new position. This is a slippery slope in my experience that should be avoided. The simple fact is this, its not fair to you, your previous team, or your new team for your attention to be divided. Now I’m not saying you should be a jerk about this, and it’s a scorched earth policy when you leave your old team. But I am seeing be cautious about taking on responsibilities after you start your new position.

Like it’s one thing, for some one your old team to reach out with questions or asking you for context on something. It’s another entirely for you to be working on key deliverables or attending meetings for your old team after you start date at the new position. Remember to be respectful of all sides, and I will say that for this to work, you need to respect this tip as well.

More than likely you gave a certain amount of notice, and I’ve seen way too many people take those 2 weeks as a “I’m just going to coast out and then pick up my new position.” This is absolutely the wrong behavior. You have a responsibility to your old team to do as much as you can in the two weeks to set them up for success in the transition. For example, doing the following actions:

  • Document everything you can about your current projects, things like:
    • State they are in
    • Why certain decisions were made
    • Key team members who were part of the conversations
    • where to find certain things
    • key concepts and processes
  • Setup meetings with your backfills early, and make sure they have time to consume everything and understand what is going on.
  • Communicate with team members and others as much as you can to make sure nothing gets dropped.
  • Document any processes you do to help them pick them up.

Tip #2 – Make sure you have a meeting with your new manager day 1

This one feels kind of obvious, but again, some people miss it. You really need to make sure you have a meeting with your new manager as soon as possible. This is going to be to set the foundation of your relationship with them.

You need to make sure you have this meeting as this is the time to make sure you focus on the following key areas:

  • Expectations on communication
  • Expectations on delivery and focus
  • Key objectives and things you can help with
  • How to engage with the team
  • What is their preference means of communication?
  • What are their working hours?
  • What is a reasonable response time?
  • What kind of regular cadence should you set up? And who defines the agenda?

Tip #3 – Make sure you talk about team culture

The above meeting with your manager is a great time to have this conversation. And this is one of those things everyone over looks, but is probably the most important. In a pre-COVID world, you would discover the nature of the team naturally. You would talk to your team mates, and find out how they work. And let’s be honest, some of these things could be taken for granted. But with the advent of remote work, all of the old assumptions are out of the window. So you need to take the time to figure out what the culture of Thea team is, and by that I. Mean things like this:

  • Are there regular cadence calls?
  • Do people prefer phone or face to face?
  • Is there a preference for camera use?

Tip #4 – Ask for an “onboarding buddy”

This is extremely important, Onboarding in a vacuum is completely impossible. And even the best manager in the world isn’t going to be able to talk about everything. And to be honest, even if they want to, team dynamics are always going to be different.

Let’s face it, people behave differently for their managers than they do for their other team members. Plus, most managers I’ve known are very busy people, and the demands of onboarding someone can be problematic.

So a good solution is to ask your manager for an “onboarding buddy,” and the idea is this is someone who you can check in with on a daily basis. The goal being that you can check in with on a daily basis to make sure things are going well and that you are aligning properly.

Tip #5 – Make sure you have explicit direction

I find too often, and I’m including myself in this, I am afraid to step back and say, I’m not entirely clear on what you are looking for. You don’t want to find yourself in a situation where you don’t have an understanding of your direction and next steps. Make sure you get explicit instructions from your new manager on what you’re priorities should be and what you are going to be working on.

Tip #6 – Make sure you are able to contribute early

Look for ways to dive in, I hate to say this, but most onboarding is fairly generic, and the best way to get to know the team is to roll up your sleeves and get to work. Find ways that you can help them with what they are working on right now.

Don’t be pushy about it but just ask “How can I help?” Or look for things you feel comfortable taking on early. The best way to get to know a team is by getting in a foxhole with them and showing value.

Tip #7 – Start in listening mode

One of the biggest mistakes, I see over and over again is that people show up to a team and start saying “we should do this differently?” It is pretty presumptuous to walk in to a team that has been working together and start with a “You’re doing it wrong.” It also causes you to miss out on a lot of learning and would recommend you take the time to really make sure you understand how the team works, and the “Why?” before you start throwing out ideas for changes.

So there are some of my initial thoughts on how to join a team remotely.

Passing Values to a Orchestrator function in durable functions

Passing Values to a Orchestrator function in durable functions

So I wanted to get a short post out here on a handy little trick that I actually had a pretty hard time finding the answer to. So I’ve been doing work with Durable functions lately in Python, and really enjoy the possible options this opens up for longer running or complex server-less operations.

That being said, I did run into a headache early on in the form of how do I pass values from the initial request to the other parts of the function. So here’s a short post on how to do that so that hopefully the next person doesn’t have as hard of a time finding the answer.

So when you have a durable function, you essentially get 3+ pieces, but at the minimum its 3 pieces.

  • HttpStart: This is the code that receives all Http requests for durable functions and then acts as a router, to push them to the correct Orchestrator.
  • Orchestrator: This is the function that will be longer running and used to manage state ongoing.
  • Activity: These are the smaller functions that are called upon by the orchestrator to do the work being asked for.

Now the problem is that normally I would pull from an http request in a function in the following way:

async def main(req: func.HttpRequest, starter: str) -> func.HttpResponse:
    payload = json.loads(req.get_body().decode())"Trigger payload = {payload}")

See though the problem with this is that the actual request that kicked off the function is only accessible to the HttpStart. So now, you need to figure out a way to pass this to the orchestrator, and if I’m being honest, the best way to do that isn’t clear.

Part of the reason it isn’t clear, is that Durable functions do a lot of work to encapsulate the inner workings of how they manage state. Which I’m thankful for, but it made this harder.

But after much head-scratching, if I figured it out, and here it is:

async def main(req: func.HttpRequest, starter: str) -> func.HttpResponse:
    client = df.DurableOrchestrationClient(starter)

    function_name = req.route_params["functionName"]
    requestBody = json.loads(req.get_body().decode())
    instance_id = await client.start_new(function_name, client_input=requestBody)

Now when you use core tools, all the wiring is pre-built for you. Strongly recommend that. But if you leverage the “client_input” parameter off the DurableOrchestrationClient, you can pass a json serialized paylod over to the orchestrator.

From the orchestrator’s side, the code looks like the following:

requestBody : str = context.get_input()

Now one of the limitations I found was that you could only pass one parameter this way, so the easy workaround was to implement a complex object that I would then serialize containing all relevant data.

Building modules in Python

Building modules in Python

So recently I’ve been involved in a lot more development work as a result of changing direction in my career. And honestly it’s been really interesting. Most recently I’ve been doing a lot of work with Python, which up until now was a language that I was familiar with but hadn’t done much with.

And I have to tell you, I’ve really been enjoying it. Python really is a powerful language in it’s flexibility, and I’ve been doing a lot of work with building out scripts to do a variety of tasks.

As mentioned in previous blog posts, I’m a big fan of DevOps and one of the things I try to embrace quickly is the idea of packaging code to maximize re-use. And to that end, I recently took a step back and went through how to build python modules, and how to package them up for using a pip install.

How to structure your Python Modules?

The first thing I’ve learned about Python is that it very much focused on the idea of convention. And what I mean by that is that Python focuses on the idea of using convention to define how things are done over have a rigid structure that requires configuration. And putting together these kinds of modules is no different.

So when you go through the setting up of the configuration, you would use the following structure:

  • {Project Folder}
    • {Module Folder}
    • {Module Code}
  • requirements.txt

From there the next important part of the setup is to create a As you start to flush this out, you are going to be identifying all the details of your package here along with dependencies that you want pip to resolve. A great post on project structure is here.

import setuptools 
with open("", "r") as fh: 
    long_description = 
    python_requires = '>=3.7',
    packages = setuptools.find_packages(),

And next is the requirement for a, which will outline the specifics of your package. This where you are going to put the documentation.

Next the important part is how to implement the, this is important and is basically a manifest for the namespace of the library. Below is the sample.

from .{python code file} import {class}

From there you can actually use a utility called twine to bundle the package, and information on twine can be found here. Below is the command to create the bundle. There is a great post on that found here.

Threading in Python

Threading in Python

Just another quick tip and trick for Python, and that is how you implement threading. This is surprisingly simple in Python, but basically it involves installing the threading library using pip

pip install threading

From there the process is the following:

numThreads = 10
threadList = []

def RunTest(self, name):
	print(f"Hello {name}")

for x in range(numThreads):
	t = threading.Thread(target=RunTest, args=(x))

This will then kick off each thread and let them run in the background, now the next logical question being how do I wait for a thread to complete, and that would be the following:

for t in threadList:

That’s really it, overall pretty easy.

Quickly Deserializing in Python

Quickly Deserializing in Python

Just a quick “Tip and Trick” post right now, but I’ve been doing a lot of work with python lately. And I have to tell you, I’m really enjoying it. Python provides a lot of easy ways to do the kind of work that we have to do so often. The “Free form” nature of python gives the ability to build a lot of things very quickly, and one of the common problems I wanted to solve is pulling in configuration information into your python scripts.

One of the habits I’ve built over my time as a developer is that I HATE to build magic strings, and prefer to build configuration settings as I build my code. And rely upon this configuration almost immediately. And as I’ve been working with python, I found an easy way to handle this type of pattern.

The first benefit, is how Python handles json, when Python reads in a json script, it will treat it as a type “dict” which is great because it makes it really easy to read as a key / value pair. So for example, the following code works:

Below is the test.json:

	"value1":"value 2",
	"object1": {

The following python script can read that:

filePath = "./test.json"
f = open(filePath)
config = json.load(f)

value1 = config["value1"]

Honestly pretty easy, but one of the fun tricks of python I recently discovered is how to map those values to a class. Take the following file for “test.json”

	"value1":"value 2",
	"object1": {

And if I create the following class:

class Object1(object):
	def __init__(self, objectvalue1, objectvalue2):
		self.objectvalue1 = objectvalue1
		self.objectvalue2 = objectvalue2

I can load that class with the following:

filePath = "./test.json"
f = open(filePath)
config = json.load(f)

object1 = Object1(**config["object1"])

That one line at the end will take the json object from the “object1” property and will match it to the constructor to load the object, and do it based on name mapping, so as long as the constructor parameters match the names of the json file it will take care of the mapping.

So just a fun little trick for python for anyone who’s new to python.

Being your own enemy….Perfectionism

Being your own enemy….Perfectionism

So this is something I’ve been thinking a lot about lately, and I figured it might be worth doing a blog post about, and that’s the topic of Perfectionism, and the idea of being your own worst enemy.

In my new role, I’m doing a lot more coding, and software development and I find myself in a position that I’ve been in before, where I have sort of a “blank slate” to build out something and have a degree of latitude to figure out the “how” I want to do things. And it can be great, but also stressful.

We’ve all heard the stories of Steve Jobs, Elon Musk, Thomas Edison, and others. Who demanded nothing less than perfection from themselves and those who they worked with. And we’ve all had that manager who’s standards were too high, or even been that person who tries to make every detail of your work perfect.

I have lots of times where I catch myself doing the later, and being the one who holds myself to a higher standard, and there can be a lot of reasons for that. Some of those reasons include:

  • Perfectionism
  • Ego
  • Fear of Failure
  • Imposter Syndrome
  • Lack of self confidence

In my experience, due to the positive nature of the word “Perfectionist” because of people like Elon Musk, or Steve Jobs, there is now this “convention” where people say “I’m just a perfectionist” to really help mask one of the other truths above.

And at the end of the day that’s telling yourself a lie, which can create this vicious circle. For example, it took me a long time to realize that my perfectionist tendencies were really imposter syndrome.

And this ultimately created a vicious cycle, as follows:

  • I would be over critical of my work, and put in more hours thinking that it “Needs to be better” or people are going to “realize I not as good at this as I think I should be.”
  • When people would identify the extra hours and work, I would hide it by saying “I’m a perfectionist, and just need to really deliver the best work possible.”
  • I would then feel increased pressure to deliver perfect every time, and repeat the cycle with more intensity.

And it should surprise no one, that the above cycle is about the furthest thing from sustainable that you can get to, and because I would take on too much and put too much pressure on myself, I would then set myself up for failure, which made my imposter syndrome a self-fulfilling prophecy.

Now after talking to friends and colleagues, I find that this type of issue is pretty common, subtle differences might be involved (Remove imposter syndrome, and replace with “Fear of Failure”). And the first thing to know, is you are not alone, there are a ton of people now starting to talk more about this. Personally I like Scott Hanselman’s discussion on this topic, found here.

But here are some tricks I’ve found to help myself avoid this, and increase the amount of work I deliver and getting to a quality I am satisfied with, and avoid the downward spiral.

Tip 1 – Keep objectives Small

This is the biggest thing I find that helps me, so let’s do it first. And I did this recently with a coding project that I needed to work on. I take every coding project and break it into small tasks, things that can be done in like 20-30 minutes. And then I break that list into two categories Essential and Nice to have.

The idea here being that I am forcing myself to take 2 minutes and define what is absolutely essential and what would be nice to have. And then as I work on this I will focus on the Essentials, while roping in as many nice to haves as I can.

Now what I did find is that this alone is not enough, as you will find ways to push to make sure both groups get done, but Tip #2, helps with that.

Tip 2 – TimeBox

The next part is that I will timebox everything I do, maybe not with tight like “I have 30 minutes to do this.” But more of a “I’m going to get X done before lunch.” And I find that by doing so, I ensure that I don’t lose focus on the larger picture.

This forces me to keep the essential at the front of my mind, and only let’s me go so far down the “rabbit hole” that is the “Nice to have” list.

At the end of the timebox, I then adopt the Scrum mentality and either add the “Nice to have” items to the backlog, or throw them out all together. This helps me feel like I’m being productive and delivering on what I need to, and can lead to a confidence boost, when I see how many “Nice to haves” I knocked out.

Tip 3 – Be clear about the desired outcome

This is the other critical one, I’m clear for myself and when I communicate with team members about this. Avoid words like “need to…” and be clear about “trying things”.

For example, I had a scenario where I wanted to implement threading in python to resolve an issue and making something more performant. At the time I hadn’t even researched threading, so I was very clear with my team members that I was going to “try” and make this work, and made sure that I went into it with the expectation of trying, not that I 100% committed which reminded myself that getting this working was not essentially.

Now as it turns out threading in python is really easy, and was pretty thrilled with the results (2 hour process down to 17 minutes). But it helps to understand that you need to make sure that you are clear about what you are “trying to do” or “experimenting with” and what the expected outcome is.