Coding is fun but ... playing Programmatic Dodgeball as a way to teach technical concepts to a group of high schoolers? Well... that's way more fun. This time-lapse is from a pre-Covid event in 2019 and required more painter's tape to mark off the grid than you would think. If you've followed me for any amount of time, you'll know one of my passions has been getting kids interested in technology and in coding. I think the best approach is by stepping away the computers, the gadgets, and make it immersive , and  interactive . In the long run, while they may not all become coders they will all benefit from being skilled at Computational Thinking . Taking a  #TechlessTeaching approach lets students physically experience the problem they are trying to resolve. If and when they make a bad assumption, they'll feel the impact of it. The result of such exercises is they start to analyze and break down the problem, and look ahead to anticipate and predict the challenges the

  I see this mistake made on resumes all the time: introductions that are paragraphs with long-form sentences that look more like a  cover letter  than a  summary. Have you ever read through a very long document/article? A product review, a security assessment, a home inspection, a legal document? Hasn't it ever made you wish you could just see the conclusion first? If you know the conclusion, then you can determine whether the rest is worth reading, right?  Think of your resume summary just like that. It should be an  Executive Summary. If you're not familiar with executive summaries, imagine being an important executive who is really short on time. To spend an extra minute on the details costs more money than it's worth. Instead you rely on your team of experts to boil things down to their most important points, allowing you to make a quick decision. Given how many resumes a hiring manager has to review before selecting which candidates will be interviewed, your resume sh

Do you use different words to describe your relationship with your employer? Not to read too much into the language, but I do sense #confidence when one describes their #work experience as companies they worked with rather than the companies they've worked for. I'm curious what others think: Does one term feel more insubordinate while another feels empowered ? Does each word define a different kind of work ? Do you use one term more than others or do you use the terms interchangeably?

Before I worked at Microsoft  (the first time) , before I worked at Cognizant, before I had a wild ride with HPA and undergoing multiple acquisitions, before my first "real" job... T his was where I built my experience, this is where I started my career: All those red boxes was where I'd spend hours scour different postings and looking for anyone that even remotely looked like they could give me work - building a website, making a small app, building a flash game, even styling a MySpace. Other times, I'd make postings of my own: "Let me build you a website, I don't charge much" it would say. I met a lot of interesting folks that way. I built an ecommerce site for a small laser manufacturing company. I built a website and flash game for a Ghana ian prince. And yes, I was paid $200 to style someone's MySpace. This is where I learned to handle multiple projects and timelines, handle customers and requirements gathering, and billing. Let me be clear: The

  No matter how many times you may reassure your team that " there are no stupid questions" - you'll undoubtedly come across moments where a bad assumption was made because someone didn't ask the stupid question. Everyone has a stupid question - a basic fundamental about the job, how something is supposed to work, why something is important. Especially in organizations where tribal knowledge runs rampant, you'll find a lot of the basics are not as black and white as as they should be. Moreover when you consider that people don't fully retain the nuance of something the first time they hear it (particularly new hires who are drinking from the fire hose) a lot of important information gets missed. Bad assumptions leads to bad results. Bad assumptions leads to bad code. Bad assumptions leads to bad products. To resolve this, try regularly hosting a Stupid Questions Only  meeting. Attendees can submit (anonymously) their most stupid (but relevant) questions. Work

Too many hiring managers need to know this. When you make a "safe" hire, you'll get "safe" results. Hire juniors , they are hungry . Hire #CareerChangers , they are experienced . Hire those who lost jobs, they have something to prove. Hire those with differences (no matter what they are) - they will give your team and product a perspective you're otherwise not getting. And soon you'll come to realize all of them are just as capable as the 'safe' choice. *And for the record I have time and time again followed this advice and it's paid off in spades. If you want advice or want to brainstorm, connect with me on LinkedIn and we can chat more about it!

Last fall I introduced a coding competition called Code / Collision.  The mechanics were based off an old Flash game I'd made back in 2007 that was a play-by-play hockey game. You'd choose the angle and speed of each player and you'd click where you'd want to shoot the puck. Since the rise of smartphones and mobile games we've seen this similar mechanic in games like Soccer Stars, but what makes Code / Collision really fun is that it's not interactive. You have to code your strategies. If you've not seen Code / Collision, it's worth a look! Consider hosting a game for your next team event.

Someone once told me a lie: Engineering Leadership, Engineering Managers, UI Developers, Product Managers are "failed coders." I've also heard Managers say of Senior Coders that they couldn't "make it" as managers and should just stay engineers. These are the statements that build egos. There is no value in this hostility. Of course, I understand where it comes from: feeling like your skills to execute your role are underappreciated and undervalued. It's a defensive response that, in turn, devalues other's skills & talents. When people start underappreciating each other in this way, something is broken. It forms a toxicity that festers and permeates the team. It reminds me of a joke: 3 sailors are in a lifeboat that's sprung a leak. One sailor is rowing. After a while he says: "You guys have it easy. I'm rowing so much, my arms are burning - but if I stop, we'll never make it to shore." Another sailor is constantly scooping

I came across an old portfolio I'd made 16 years ago, shortly around the time I was graduating college and began to look for #work. Looking back on this portfolio, it breaks a lot of the guidance I give today. It was made in Flash and the design was...well...judge for yourself. My pricing for building #websites was crazy (I was hungry for experience at the time). It wasn't a bad start - but it was largely #directionless. It didn't showcase my abilities, and it didn't know it's audience. This is why I like to create content around #resumes and #portfolios. I learned the hard way (many times over!) but eventually got there and found my footing. We all start somewhere.

I first came across Microsoft Excel at a young and impressionable age. In fact, I was so impressionable that I argued with teachers that the alphabet didn't end at Z, but was followed by AA, AB, AC... (...Yes, this is a true story...)

There's an interesting parallel between Leadership and Innovation Theory. Leaders and Innovators are both visionaries - they see a sense of what is possible, of what can be. But - critically, both depend heavily on their first followers/early-adopters. These brave folks are leaders in their own right, and - as video I recently came across demonstrates so powerfully - are the ones who turn the vision into movement .  If you've not seen 'First Follower - Leadership Lessons from Dancing Guy,' it's a good watch (and quite obviously the inspiration for the slides above.) As this video so perfectly states: We over emphasize the importance of leadership as it relates back to innovation - but without those first followers, those early adopters - the leader/innovator is nothing but a crazy nut. Given this, how much this change our perspective of the first follower as leaders?