Not Everyone’s a Special Developer Snowflake

Special Snowflake

There is a prevailing mindset these days, that everyone should learn to code, or that everyone is a potential creative.


Thirty years toiling in the business of writing software, and personally doing a fair amount of copywriting and creative work for enterprise systems, small businesses, and mobile applications have convinced me of just the opposite.

By way of disclaimer, let me openly and honestly say that I am not the greatest software developer in the world, nor the world’s reigning Photoshop master. But I have worked with some of them, on occasion. I have also worked with their evil doppelgangers.

Let’s examine who is pushing this trope / tripe that “everyone is a developer”: for the most part, companies whose business it is to teach people how to code. Or, organizations looking to develop a larger base of developers in a geographical region.

Look – having educational opportunities to promote STEM, STEAM, eSTEAM education – in and of themselves – is fine, and a worthy pursuit.

HOWEVER: the stark reality is that some people are better at programming than others. Some people are more creative.

And some aren’t.

That doesn’t diminish their worth one jot; but we do them a severe disservice by not dissuading them from pursuing a career path that they may not be suited for, and for which no one benefits.

And while not everyone may not be a special programming snowflake, everyone does have something that they are spectacular at. Let’s take the time to promote the development of that, rather than show-horning everyone into a becoming mediocre technocrat.

Why not encourage people to pursue their real passions and talents, rather than have them drink the Yuccie Kool-Aid: the claim that everyone is a coder-creative?

If we really care about preparing people for the brave new world, and living up to their full potential, we need to stop perpetuating the illusion that everyone can take a six week class and be the next programming rock star.

If you’re still not convinced of my argument – take a look at a colleague’s source code. Or their portfolio.

Snowflakes don’t last very long when exposed to heat and light. Neither do frauds and phonies.

Go, and be you.


How’d You Do That?

How'd You Do That

I was having a great after dinner conversation last week with the sons of one of my colleagues. We were talking about gaming and technology, and eventually our chat moved onto mobile applications, where we discussed some of the apps that I had developed.

What languages did I know? Were they hard to learn? How long did it take you to make your first app?

One of the sons then asked: How’d you know how to solve the problem you were trying to solve?

How’d you do that?

A great question – and one that I tried to answer, I hope to his satisfaction.

I explained that it’s a lot like learning to read and write. You first learn the alphabet, the sounds that letters make in the language you speak. You then move on to simple sentences, and then grammar, and then finally you begin to write; simple sentences at first, and then more complex paragraphs. Finally, you’re able to express yourself completely.

Learn another language, and the process repeats itself.

But I could have answered the question a bit simpler than even this.

The way one learns to solve problems, is by solving problems.

Learning, by Doing.

Learning to develop in a new computer language proceeds in the same way that learning a human language proceeds. One learns the vocabulary and language elements, master the idioms, and begin by expressing simple solutions, first, before moving onto more complex expressions.

Of course, the more times you do this, the easier it becomes to recognize similar patterns in structures and syntax, and thus, easier to ease into that language.

But being able to write code, and being to write great code, are not the same thing at all.

This week, I’ll talk about the practice of software development, and the process to proficiency.

For now:

Go, and be you.


Trust Me

Like New

Trust is one of those things in life that cannot be given; only earned.

But how many times a day do you hear the words “Trust Me!” – without immediately going into facepalm mode?

Sure – we might wait and see if someone delivers on what they promise – but that doesn’t mean that we trust them. Not in the least.

Trust is built on three things: relationship, execution, and time. Remove any of the three, and what you have is acquiescence at best, and resignation at worst – but certainly not trust.

We need time to experience the values that the people we interact with have. We need to see them reliably and repeatedly perform. We need to know that they can do what they say they will do, the way it needs to be done. Prolonged contact begets History begets Relationship.

Our cheapening of the word Trust comes in no small part because of the implicit redefinition of the word Friend through our immersion in social media. Because we see the same people on line, everyday, and maybe even trade pleasantries daily, we think we’re in relationship. But this is not Relationship with a capital R. If you’d like to test this, just ask one of your social-media-only friends for a loan, a place to stay, or a ride to the airport.

Relationship. Execution. Time. Trust needs all of these in order to exist.

Trust Me.

Go, and be you.


Great Expectations

Great Expectations

A lesson I’ve learned through long – and often difficult – experience: great project management is actually great expectation management.

Over-promising and under-delivering are the ingredients for disatisfaction.

Similarly, not being transparent about the true state of work is also common among failed projects.

Setting expectations appropriately, and meeting those expectations once set, may not make every stakeholder 100% happy. But they will at least be informed, and rarely surprised.

Look – everyone knows good fences make good neighbors. Clearly spelled out project scopes are the virtual equivalents of good fences. And as I said in yesterday’s ‘cast, a solid look of success let’s everyone know what the successful conclusion of their project is, right from the start.


  • Clearly articulate what will be done on a project, by whom, and by what date,
  • Clearly specify what the successful completion of the project will look like, and
  • Set – and maintain – the appropriate expectations of what can, will, and won’t be done.

Before leaving this topic, let me just add this: until the last piece of a project is completed, the care and feeding of the expectations of your stakeholders should always be at the very top of your daily to-do lists.

Because in the absence of good information, your customers will create their own narratives, where you may not be the hero.

Control the narrative. Create Great Expectations.

Go, and be you.


The Look of Success

Look of Success

You might be surprised at the number of projects that get greenlit, without a well-defined scope of work, or anything close to a definition of what a successful completion will look like.

Or, if you’ve lived through one of these nightmares, perhaps this is no surprise at all.

Any sane project manager will insist on a clear scope of work, before signing off on spending time, resources, and capital on a project. A clear and well defined look of success isn’t just nice – it’s required, before doing anything else.

The entire value proposition of a given project is totally dependent upon its look of success; because, it should be the most desired outcome of a project, by which its ultimate success – or failure – can clearly be judged.

For, if you can’t quantitatively – and qualitatively – define when a project is successfully completed, you’ve designed a metaphorical span, that’s firmly anchored at its beginning, but untethered at its destination: effectively, it’s a bridge to nowhere.

Remember: all successful projects have a clearly defined finish, before they have a beginning at all.

Lacking a look of success does virtually guarantee one thing, though: the certainty of failure.

Go, and be you.


Analysis Paralysis

Analysis Paralysis

There’s covering all your bases. Considering all the options. Letting every voice be heard.

And then – there’s the death of a thousand cuts of having a project “glued in place” by Analysis Paralysis: over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect, paralyzing the outcome.

If you’re an “Ol’ skooler”, you may have heard the same thing described as “death by committee.”

Good, effective governance is hard. What makes it hard is that when more than a handful of voices are involved in a design of any size, timeliness and opportunity can quickly be lost, in the fight for the inconsequential.

So – how does one avoid “analysis paralysis?”

Start by having only those involved with an actual stake in the governance process. If they aren’t a stakeholder, they’re off the team.

Secondly, before planning or deliberations begin, everyone will be aware of what has to be accomplished, with a “look of success” defined for what a successful, and complete, outcome will be.

And finally, you have to involve participants in your process who are actively engaged and working in good faith to move the project forward.

Sometimes, you don’t get to choose who is on the team. Or, you have to work with members who are actively throwing roadblocks in the way of progress quite intentionally.

The only real curative is to hold those team members publicly accountable, and challenge them, directly or indirectly. Otherwise, they will leach away every bit of momentum – or worse, opportunity – you need to succeed.

Go, and be you.




If there’s any single event, that has shaped my life, it was the fire that destroyed my childhood home.

Happily, there was no loss of human life – though, we did lose a much beloved family pet.

We were left quite literally with only the clothes on our backs.

Now, at the time, I was a sophomore at Western Kentucky University, and away at school when the fire broke out. Since the fire occurred in the morning, the only one home at the time was my mother, and she was able to safely escape; terribly shaken, but physically unhurt.

My dad called me later that evening to give me the news. I cried, for my pet. And I went home the next day.

Hearing about it over the phone was terrible. Seeing it in person was devastating.

Our house was a complete loss. The fire started in the laundry room, adjacent to my bedroom, and so everything that I had owned, made, or cherished – from earliest childhood on – was simply gone. Just – gone.

We had our lives, and nothing else.

It was more than enough.

With loving help from friends and neighbors, we were able to cram five people into a two-bedroom apartment, while our house was rebuilt within the shell of the exterior that remained.

The fire changed everything for us. It changed what we valued. It changed who we were.

And its effects are still being felt today, thirty years on, as my family still lives with the consequences of everything that happened after.

Things are things. They can always be replaced.

But people, and experiences – they are the rarest of life’s treasures.

When you find yourself wanting something more, wanting something else, or simply wanting – hold tight to those you love. Tell them it will be alright. Tell them you love them.

And it will be.

Go, and be you.


Cost versus Value

Originally appeared in Logorrhea.

I love being a programmer. There’s just something about taking an idea, and pulling together a bunch of formless elements into something cogent, useful, and – hopefully – beautiful. It’s the same process of creation that attracts me to writing – though I am a far less talented writer than I am a coder.

But even as much as I love creating software, and working with people on their ideas for applications and products, there is a side to the developer life that I find tedious, and entirely off-putting: having to continually explain cost versus value; usually, winding up on the losing side of the conversation, if only because I’ve thrown up my hands in exasperation, or maybe have just rolled my eyes as far back into my head as they would go.

When we think that paying more than $0.99 for an application is too expensive, something is wrong. When we want an enterprise-grade, responsive website, with all the bells and whistles – for $500something is wrong.

As consumers, we’ve been conditioned to conflate cost with value. I blame the Internet, and the tsunami that is the consumerization of technology. “Free” applications and services have lulled us into a false sense of frictionless commerce, believing that we now live in a time of economic magic, and scale has made everything cost nothing. In fact, all scale has really done is to destroy our conception of value that we definitely should be recognizing, in exchange for making us the actual product being sold. Amazon, Facebook, and Google: I’m looking at you.

It’s not just development that has had cost versus value turned on its head: cab rides, shopping, education, and most notably music, have been and are disrupted to the point of unrecognizability.

It’s incumbent upon us, as consumers, as citizens, and as people – to recognize that the creative process has an intrinsic value; that education has an intrinsic value; that our passions have an intrinsic value – that goes beyond a race to the bottom, where the only metric that is important is a price tag.

Where we know the cost of everything.

But the value of nothing.

Go, and be you.


Know – and Care – About Your People

Care for Your People

I’m not going to ask anyone to go out and hug a tree or adopt a puppy.

But if you truly want to develop a strong and cohesive team, and have any hope of keeping that team together, it begins and ends with understanding your people, and caring about how they are developing as people and professionals.

You don’t have to create “forced fun” departmental outings. You don’t have to hold impromptu celebrations for every life event. But, you do have to care, and show you care, through authentic actions.

Know when their parents are undergoing a health crisis. Be aware that their living situation is in transition. If you understand challenges facing your talent outside of work, it should make your workplace communications more empathetic and compassionate. There. I said it. Compassionate.

Because, if you truly want your people to care about their jobs, you start by being a mensch yourself, and demonstrate care for the people you work with.

You don’t have to be creepy, you don’t have to be intrusive – and you can still remain professional.

When you’re attuned to the needs of your team, inside and outside the workplace, you can anticipate potential disruptions and interruptions, and make much better decisions with regard to assignments.

Plus, just being a better person is reward unto itself.

Go, and be you.


The 2015 Dean’s List: EdTech’s Must-Read Higher Ed IT Blogs

Dean's List

Today, I’m going to “break format” a bit, from our regularly scheduled “daily dose of awesome.”


Well, for the second year in a row, one of my blogs was named as a Top 50 “Must-Read Higher Ed IT Blog” by EdTech for Higher Education.

Last year, my personal blog, Logorrhea, made the 2014 Dean’s List.

This year, 300 Words, 2 Minutes made the 2015 cut.

I’m pleased and honored to have our little corner of the podcast-o-sphere included in this select group of education thinkers and thought leaders.

Somehow, I slipped through the cracks and made it in. So, I guess I’ll just have hold up my end of the bargain, from now on out.

Thanks to everyone who has given me kind words of support, encouragement, and helpful feedback as I have gotten 300 Words, 2 Minutes off the ground. It’s been immensely gratifying to see something take shape from nothing, and then have it take on a life of its own.

Tomorrow, we’ll return to our regularly scheduled programming…

But for now…

Go, and be you.