Cloud Management

TODO: Get job as Dev

This is an article for those of you who are self-taught or coming out of an accelerator/bootcamp program for software development, who are wondering what’s left to do before you land that first software development job.

This is based on my experience of hiring people in this situation for several companies.

First things first; yep, you’re at a slight disadvantage vs. “classically trained” software developers or engineers from University programs.

No, that disadvantage is not insurmountable. If you combine your dev education with other attributes (like your great non-software experience), and apply it in the right role selection, you’re golden. It’s a great time to be getting into software.

Full-Stack Roles

Unlike the specialized roles that sometimes require Master’s level education in specific areas, full-stack roles are constantly available.

The reason being: small software teams need excited generalists, who can demonstrate competency throughout the tech spectrum (from updating WordPress websites to building out new infrastructure in the cloud).

You’ll find many unfilled full-stack roles in the IT / tech organizations of non-technology organizations (ex. mortgage providers, agrifood manufactures, automotive parts suppliers).

Google, Facebook, Amazon, Shopify, Square etc. are key destinations for excellent talent, and pay appropriately. Non-SaaS organizations that are doing meaningful technology work struggle in that hiring landscape and are willing to hire from bootcamp programs and develop non-degree talent in house.


Front-end refers to the part of the software that users can interact with. While it includes mobile apps and web sites, it also includes documentation, email, and social systems that accompany software solutions.

From a new-grad, employers expect:

  • Demonstrable skills in one or two modern UI technologies. In 2022 that means React + Redux, Swift, Dart/Flutter, Kotlin, etc.
    • Focusing on JavaScript + HTML + CSS + jQuery + PHP is considered an anti-pattern, despite the fact that’s required for developing and improving older websites. Not great, agreed!
  • Object-oriented design principles and design patterns: Factories, Singletons, Decorators, Observers are common-place.
    • Understanding views, models, controllers, and related patterns (MVVM and MVC).
  • Concern for user experience and design. You should have an opinion if the interface is mixing serif and non-serif fonts, image alignment is inconsistent, or the affordance of a key action is low.
  • Constructive relationships with people testing, critiquing, or evaluating your work. Testers, QA, managers, stakeholders, and clients need to have positive, creative relationships with you.
  • Examples of accurate, and well-edited technical written communication.
    • Hate to say it, but knowing how to administer a WordPress instance is a friendly docs bonus.


Most students of software start their journey on writing back-end code. Back end code is rewarding to author, testable, structured, and ripe with technology options. It’s the good stuff other devs like to look at and discuss.

Though unless your job specifically concerns DX, it tends to be far from the value your team creates. So the key skill is knowing enough to know what’s fit for purpose.

New grads are assumed to have:

  • Working knowledge of RESTful API design and protocols of the web request/response pattern (ex. Content-Type, CORS, headers, cookies) .. as REST and HTTP are the protocols of choice for modern tech.
  • Though, the future of APIs is event-driven. Academic understanding of events, buses, cloud functions is helpful.
  • Comprehensive understanding of relational databases; how to query with SQL, table design, relationships between models.
    • The technology of the DB rarely matters (Postgres, Microsoft, Oracle, MySQL, etc.) as the principles are universal.
  • Understanding how documentation stores (ex. NoSQL) and key-value caches (ex. Redis) differ from relational databases, and when to use which, is important when developing new features or products.
  • Performance monitoring and profiling in general, using tools like Firebase, Crashlytics, Microsoft Insights, Papertrail, etc. is key for keeping back-end services up and running. Practical experience in keeping your work up and running under load is great.


While often part of the “back-end”, infra is becoming a field on its own, as it can be represented as code and configuration.

This is where self-taught and bootcamp developers often have an advantage over University programs — few degree programs have infra in the curriculum.

Employers love to see:

  • Experience with a few “clouds”: Azure, AWS, or Google Cloud being the most important.
  • Understanding of the role Docker + containerization play in software deployment. Kubernetes configuration is a next-level skill, and likely not worth the attention it gets in the computing community.
  • Experience working in a work management tool (Jira, Azure DevOps, Trello etc.) with a pipeline that does integration and deployment.
  • Once again, cloud functions and storage buckets are more often the right ways to build back-end services.


Sometimes people feel that their experience in Bootcamp was great, but not enough to land them software development work. A couple of practical next-steps:

  • If you have a Bachelor’s degree in another field, and a bootcamp credential, you may qualify for a post-grad program in software development at your community college. These programs are often awesome: an intense year of programming up-skilling, sometimes coupled with a co-op program. In Kitchener-Waterloo, Conestoga College offers a program like this that I’ve hired out of several times.
  • There are many Business Analyst roles at technology companies that require expert understanding of a field, coupled with project management and technical software skills. BA roles often have career paths into QA and Solutions Engineering, and they are sometimes attached to a software team. The role may seem junior, but it puts you at the intersection of valuable business work and technology. BA also has career paths into management, sales, and other orgs. It’s a very flexible role in technology companies.
  • Software companies need application support, and support engineers who learn the deep technical aspects how software works for clients. Application Support Engineer is a fast growing field, replacing the old “customer support” + “Tier 3 developer” model into a shared role. The role generally has a well-defined career path into software development for those who stand out.

Hope you find this helpful, and good luck getting into the field!


New Collectors Guide to NBA TopShot

Welcome to NBA TopShot! Here’s a quick writeup to help you get started, as collecting moments can be intimidating and expensive. I started collecting NBA TopShot moments in October 2021. Big thanks to those who shared the advice with me in my early days (especially @pirate_arr_kay)

I’m @dgx on the Marketplace if you’d like to send a thank you card.

Packs and Drops

Buying Packs during drops has been the safest way to participate with TopShot. You (likely) won’t lose money, may score valuable cards, and “ripping packs / pax” is legitimately fun.

Without exaggerating, I recommend buying as many $9 – $14 packs during drops that you’re comfortable spending on.

Don’t get discouraged if some packs are just Base moments (generally worth $2 -4 each); occasionally you’ll score a nice Limited Edition card. I pulled one Three-Star Rookie after ~20 packs, which alone covered the cost of all the packs I had purchased to date.

If you’ve been collecting long enough / have a high Collector Score to qualify for Rare and Legendary pack drops, those are profitable (yes, even at $89 – $999). Competition is fierce; you likely won’t get a pack as the counts are quite low.

Rare and Legendary Packs! Get `em if you can.

I’m personally not sure that $19 Archive Set pack available to new collectors is worth it, vs. just adding $19 to Dapper. Your mileage may vary.

In the future, there may be an “unripped Pack marketplace”. That may be an incentive to avoid ripping Base packs, unless you’re building your early collection.

Starting a Collection and Your Favourite Team(s)

Pack drops are infrequent, while the Marketplace will take your money at any time.

Many top players have low-cost ($2-4) 60k Base moments (Giannis, Curry, Luka, etc.) Those are great to collect, particularly to participate in Flash Challenges.

Selecting your “favourite team” and buying the 3 moments required for the Collector Store bonus is great. Beyond that, there’s limited utility in just following your team; your early dollars are often better spent developing breadth:

  • Across other NBA teams, particularly top players for each statistical category.
  • Across the Base Sets — Series 2 is inexpensive (< $6) and helpful in building a Collector Score quickly.
  • Dipping into sets like Hustle & Show or Cool Cats. They’re more expensive, but have value due to low mint counts.
  • You can build towards your first set over time … it’s another fun aspect of collecting.

A tool like OTMNFT (see end of this article) helps you track your team sets. I started finishing Base sets for my favourite teams (Raptors, Memphis, OKC) because it’s good fandom … but once again, it’s not a great use of early collecting dollars. helps you track your team sets.

Flash Challenges + Targeting Moments

Flash Challenges require you to collect 5 – 10 moments based on some criteria (most rebounds in every NBA game that night, etc.), and win a reward. Challenges are announced around 5pm EST. They’re exciting and pulse-pounding, but the wild swings in the market during and after the Challenge can be intimidating.

Challenge rewards tend to be high value ($30 – $3000).

Challenge rewards look sweet in the collection.

But as an early collector, my honest advice is to sit-out and observe the Flash Challenges, while you learn the market mechanics. Collect the top 3 – 4 players from each team that lead in assists, points, attempts, rebounds, etc. per game.

Look to purchase declining moments, after the reward is awarded (“the dip”); it’s a great opportunity to scope important players at a discount. Often the same players come back around for future Challenges.

Buying all the moments you need to complete a Challenge means you will overpay for those moments, and the reward may not cover market losses after the dip.

The advice I got was that you can buy one card if you already have the others. If you need to buy two or more, you are possibly better off selling at peak and re-buying. But gambling is fun, so you do you!

Guess when the Challenge started and when it ended?

Bottlenecks and Rookies

One can write a PhD dissertation on the impact of “bottleneck” moments and rookies on NBA TopShot and Challenges.

Bottlenecks are low-mint (< 10,000) moment for new players (sometimes rookies) that are good enough to land on a challenge. This includes players like Jonathan Kuminga, Bones Hyland, and Scottie Barnes.

Unlike their superstar peers, these players may only have one moment. If Scottie Barnes lands on a Challenge, his $350 moment becomes a $575 ripper in minutes, pricing many fans out of the Challenge.

These moments get capped in value once a second moment is available on the market (as happened with Desmond Bane in Jan ’22).

There is always the classic allure of a “rookie card”, Three Star Rookie cards. They are priced appropriately in the market. A 7-min-per-game player like Dalano Banton commands $70 (Jan ’22).

My opinion is that certain bottleneck cards are worth their value because that player will just be involved in rewards regularly. Anthony Edwards of the Timberwolves comes to mind as a lower cost / high value pick in early 2022.

Trade Tickets + Locker Packs

You can “Trade In” moments to receive a Trade Ticket. You need 4 Tickets to purchase a Base Locker Pack when they are available. On face value, it seems lossy: trading in 4 moments to get 3. In my experience, it can be worth it.

I value Base Locker Packs at $7. They are not as random as regular Base Packs — moments are generally less desirable, have higher serial numbers, etc. That being said, I’ve pulled several Series 2 moments, great players with high serial numbers, and an Archive Set card in the last few months.

If you have moments worth less than $2, trade them instead. (ex. if have have to discount a moment to $1 to sell it quickly). You might get lucky on a few Locker Packs like I have!

Try a Locker Pack if you have a few $2 moments to trade in.

Great Tools on the Internet

Beyond purchasing moments or packs, the majority of my interactions with TopShot are on 3rd party tools.


For a new collector, LiveToken is awesome. It helps you:

  • Track the changing values of your own collection, and your for-sale listings.
  • Identify lowest priced moments for specific players.
  • Spot check the price trend on a moment: is it on the way up, way down, did it spike?
  • Check out the value of other people’s collections.
  • Hunt for deals. LiveToken Deals is probably the most visited TopShot page on the internet. The competition for those deals is intense!

Watch out for false deals; I find LiveToken overvalues very low (< 500) serial numbers, and low-serial-number volume is reduced, making the moment less “liquid” at it’s fair price.

LiveToken is awesome.

Own the Moment

OTMNFT is a more advanced tool, but excellent once you start putting together sets and minding collector scores. OTM helps you:

  • Manage your Sets and team collections.
  • Identifying dropping (and rising) prices, watching trends, etc.
  • See metrics on the distribution and the market activity of each moment.
  • Excellent Collector Score calculation and targeting tooling. Critical once you want to get to 2500 points to snag Rare packs.


NBanana is a mobile and Chrome app which notifies you of a target price for a moment. This is great if you want to list a moment at a certain price, or buy once it drops. Simple tool, but I find I use it often.


Building Inclusive Teams

Making a team inclusive is not some HR challenge, but within the mandate of any people manager.  As a manager, how do you set up an inclusive team?

(Most of these hot tips are things that I’ve seen work at great Canadian organizations: D2L, Tulip).  All credit for the correct stuff goes to them.


  • Compensate people equitably and pro-actively; nothing fair can progress without that.
  • When team-building, stick to activities relevant to the teams function.
  • Be explicitly respectful of personal, cultural things
  • Focus on your people’s needs
  • Be patient with hiring to adhere to your team values.


Money is the great equalizer.  Start with your own, personal compensation review of all salaries, benefits, and bonuses paid out to your team.

If the compensation on your team isn’t equitable based on annual performance and role responsibilities, inequity and privilege are there on the ground floor of your employee-employer relationship.  These base forces are almost impossible to overcome.

Regularly review salaries + job descriptions, and make adjustments to keep things equitable.  Every 2 quarters is a realistic cadence.

Or better yet, work towards a predictable salary grid (avoiding the pitfalls of negotiating at level changes).

Hire Slowly

When hiring quickly we generally bias towards the most available, most accessible, qualified candidates. We favour the person that we connect with, or evaluate them based on personal criteria to satisfy who we need now.

Give yourself the time to assess candidates.  I know this is hard in the modern employee market, but at least take the time to identify things that truly matter to your team long term: attitude, core skills, value fit, growth goals.  Try stuff like removing names from resumes, and screening resumes independently (to avoid that initial group-think)

Let the team do most of the hiring. As the manager, be part of the process identifying bias and assumptions, and helping push the process along positively. 

Vice Squad

In the 2000’s / age of kegs at the office, some people never felt comfortable drinking or being around alcohol. 

Here’s a short list of reasons people don’t want to drink at work functions:

  • pregnant (or trying)
  • picking their kids up from daycare
  • on strong meds
  • religiously abstaining
  • wife asked to cut back

This is personal stuff that has nothing to do with the teams work;  don’t exclude people from team activities because of it This extends to other inebriates and vices as well.  ex. cannabis, gambling.

If you want to build an inclusive team, don’t team-build around exclusive activities. Wine at dinner? Great.  Meeting at a bar. Not good.

Making friends isn’t the same thing as team building.  No doubt, shared vices and debauchery make better friends; but building an inclusive team is a different activity.

Religious / Cultural Accommodation

A simple way to ruin team cohesion is to make people feel uncomfortable about their religion or lack thereof.  Theism / atheism / religion is personal and cultural, and shouldn’t really influence your work team identity.

Appropriately accommodating is not always obvious.  If something comes up, park it, and respectfully bring it up in a one-on-one as it relates to your activity  (“Anything we should avoid for weekly lunch? Need any additional time away for family holidays?”). Trying to deal with things on-the-fly tends to be embarrassing for someone.

Small example — I’ve started making Diwali a team holiday, due to the number of Hindu people on our teams and vendor networks, rather than awarding it to people who ask.

Small example — I’ve stopped asking people where they are traveling to.  Sometimes it’s a pilgrimage, or a cultural rite, and they don’t need that to be a thing at work.

What about Christmas?!  I embrace the inclusive levity and kitsch of it.  I celebrate Christmas at home Euro-traditionally, but at work an over-the-top Christmas tree with a nod to the Grinch and a Baby Jesus “it’s my birthday!” ornament is also nice 👌🏼. “Put the Christ back in Christmas” stickers are not.  The Seinfeld Festivus, Hannukah sweaters and Nutcrackers were a big thing at Tulip.

Politics, Sexual Identity, Reproductive Rights, Liberalism, Trump

See Religion above? Kinda?

Some corporations have decided that creating venues for expression of social ideas and discuss challenges in society is important. As soon as those venues (ie. Slack channels, seminars) are mismanaged at work, it is painful for participants.

As a manager, I prefer to focus energy on individual concerns and being an ally for my team members.  I celebrate the good stuff that impacts people on my team. I tend to stay out of their business unless my support / assistance is helpful.  People need room to explore this stuff without their boss reading their reaction Tweets.

Creating the air where your team feels respected for their work, and has the freedom to just be / breathe easily is purposeful; it’s the real work of building an inclusive environment.

Note: I started writing this in 2019 and now it’s 2022.  It may seem out of date or obvious, sorry!



Migrating Clouds Quickly

In August 2020, ShipperBee migrated the bulk of their business from Google Cloud Platform (GCP) to Microsoft Azure. It took us under 3 months start-to-finish, with about 4 days of panic. We managed to finish the year with a 99.5% uptime on our core services (not amazing, but really good!).

I think this was well-executed, especially for a business with a few hundred daily clients, several hundred delivery drivers, and a team of about 70 people using and operating in the platform 6 days per week.

ShipperBee’s landscape included: 2 x REST API services, 4 x web portals, an IoT/hardware support stack, Apple + Android notifications system, PostGres databases, Redis caches, and a Shopify app already running in Azure.

Here is what we did, and what I learned.

Hire + Trust the Experts

Our dev team had the will, but not quite the internal experience with Azure, to execute on a migration like this. We determined that hired-guns on a short engagement would be cheaper than hiring a full-time Azure infrastructure expert (or two) … and it definitely was.

Via our Microsoft CSP Arrow, we hired their subsidiary company, eInfoChips from India, to help with the lift. It went OK! eIC were knowledgeable about what Microsoft has to offer in Azure, about proven configurations, and which products/settings to avoid.

The most controversial example of following expert advice was using VM Scale Sets rather than Docker containers for core APIs. On the advice of their system architects, we avoided the Docker ecosystem in Microsoft since it wasn’t as well tooled for scaling, repair, price reservations, etc.

Do DevOps Yourself

I wish we had avoided leveraging our experts in setting up our DevOps / build / CI / CD pipelines. Ultimately that should be owned and managed by the people closest to the product code.

Nuances like naming convention and owners for service accounts matter in future upkeep. A contractor won’t be as concerned with those details as your team might be.

We migrated our deployment process to Azure Pipelines, rather than staying with existing Bitbucket pipelines that had been hardened over the years. There was no real need to move our deployment pipeline with our Cloud provider; it ended up being extra scope that ultimately caused a bunch of confusion and problems.

Skip the Great Inventory

Whenever you decide to move Clouds, inevitably someone will suggest you do a complete inventory of your software system, and how it interacts with every other piece (including your IT and DevOps stack).

I believed we had a thorough inventory of every GCP component that we used, and moving it would involve checking things off a list. Unless you’ve turned off the Console/Portal and everything you’ve ever put in the cloud was done explicitly via Terraform, you’ll learn more than you’ve ever wanted about vnet’s, service accounts, storage keys, and deleted users. And you’ll miss things.

Do enough of an inventory to understand the big pieces of the lift, but each instance of each service will have to be migrated independently, with care for all the small stuff around it (ex. resource groups, networking, IAM)

Aggressive Timelines are Key

Our COO decided that we had to be done the migration by September 25th for some business reason. That gave us under 3 months to complete the project. Frankly, without that arbitrary target, we’d still be “multi-cloud” and struggling to get pieces over the line many quarters later.

Having an aggressive target date helped us identify two critical “all hands on deck” weekends, which became our key milestones. One milestone involved a working Demo environment. Two weekends after that, we’d move the Production environment.

Those weekends were predictably terrible; 18 hour days, non-stop War Rooms and unexpected emergencies. Since we had the next stage scheduled for the following weekend and business resuming Monday, we just kept “failing forward” instead of responsibly reverting.

As long as things were 90% working by start of business on Monday, we explained the problems away with the COO and resolved the remaining 10% quietly during the week.

Reset your IAM and Subscriptions

My favourite part of the transition to Azure was updating our access control lists and permissions (we went to a group-based permission model after years of adding trusted dev’s as Editors or Owners to pieces), and taking advantage of the Subscription level segregation in Azure.

Subscriptions are one level higher than Projects in GCP. I created Subscriptions for Development, Production, and Integrations .. which made cost analysis for those budget items much easier. It was easy to lock down Production access since it didn’t impact the design of the Development and Integrations resources.

Hope that helps someone! I’m now a reluctant fan of Microsoft Azure. More than anything, moving clouds convinced me of the importance of good Infrastructure and DevOps talent in today’s modern software development setup.


Developers as TeamLeads

A common career path for software developers is into a “team lead” role.  On the surface it’s a very attractive role for the organization: a transition for dev’s interested in management, retaining some of that key senior-dev contribution, and avoiding a hire for a more traditional Manager role.

But its pitfalls are serious: TL’s generally struggle balancing individual contributor commitments vs. management responsibilities, and the perceived importance of each.

From personal experience, and from managing Team Leads, some tips!

Guard Your Time

Being a Team Lead requires you to be really aware of how you spend your time.  For example, time spent on lofty, heroic senior achievements can be less important than more predictable output, especially if others depend on you for their next steps.

Ask yourself these questions:

  • How much time can I set aside for individual work.  (2-4 hours per day is normal).
  • How much time can I dedicate to organizing or unblocking work, alignment, reporting, client calls, etc. (4-6 hrs/day)
  • Do I have direct reports? How much time will I dedicate to 1:1’s, mentorship, onboarding, etc. (1-2 hrs/week/person)

This split will impact team activities like pair/mob programming, whiteboarding sessions, etc. because you may not have long stretches of dedicated time available anymore.

The simplest way to visualize this challenge is to set up your calendar.

  • Block off dedicated slots for certain types of work (then guard them with your life).
  • Pro-actively book time with your team for work that you need to do together.
  • Identify things you have to do well, give yourself time to prepare (weekly demo’s to the CEO, client meetings, etc.)

.. knowing that it’ll change week-to-week, but have these rough proportions.

Most importantly, run this setup by your manager. Maybe they have a different vision about how to spend your time?

Focus on More Constructive Efforts

The “individual contributor” time Team Leads have needs to be used very constructively.

There’s a few ways to play this … some thoughts:

Taking high value, undesirable work (difficult-to-reproduce bugs, client escalations, etc.).  Those issues keep you connected with details, and identifies difficult things to mentor the team on.

Architecture and high-level software design for the team.  Something I found works well is scaffolding new capabilities, and being involved in that first week .. but letting the team fill in the blanks and iterate.

Technical documentation becomes more important as you’re more exposed to stakeholders, other teams, etc. Docs can influence more of the organization than your dev work does.

Code reviews can get overwhelming for any lead.  Good practice is to defer to the rest of the dev team, and focus your review attention on very important or risky deliverables.

Understand Perceptions of Your Contributions

Regardless of other duties, Team Leads are often perceived as “developers first”.  That can be positive or negative, depending on how you really want to contribute.

Navigating this perception of the role can be really challenging.

Personal story: I was leading a team of four on a new product.  The plan was ambitious and unlikely to succeed, so we had designed a better solution that would move the timeline, but more likely to succeed.

I went to my executive asking that we re-evaluate the promised timeline so we can deliver this better thing.  They started asking me about some current implementation detail that I wasn’t aware of. Then mentioned that I should know those details, and ignored questions about the plan.  It was frustrating; I felt under-appreciated.  Later I realised the mismatch with what the company expected from a Lead role, vs. what I was focusing my energy on day-to-day.

Building resiliency for those times, and being flexible enough to contribute on the many sides of the role, is tough .. but good for professional growth.

Hopefully you found this helpful,  and good luck with your Team Lead future.