Road Trip

Man Plans, G-d Laughs

I began my road trip today – a drive across half the country, from Arkansas to New York City.

I don’t have to tell ya’ – Flatbush ain’t Conway.

This is the third – or perhaps the fourth? – time, that my family and I have loaded a truck, and criss-crossed hundreds of miles to a new home, a new job, and a new set of friends.

You know – it isn’t for the faint of heart. It’s challenging. It’s scary. It’s – literally – life changing.

Five years ago, I didn’t envision being a CIO at a top liberal arts college. Last year, I wasn’t thinking about being the Director of IT at a large independent school in the middle of Flatbush, Brooklyn.

Where will you and I be five years from now? Who’s to say? Man Plans, and G-d Laughs.

I’m very grateful that my new colleagues have been welcoming, generous, and kind.

And, happily, the only faux pas that I’ve been directly challenged on were (1) ordering sweet tea, and (2) misspelling the name of my new employer. Oy.

How far, and how fast, will the remainder of the journey be? I’m ready to find out.

Open the door. Step on the road. Embrace the journey.

Go, and be you.

Scarce Commodities – Google Android, Memory, and Bitmaps

This week has thrown a severe monkey wrench into my daily schedule.

Sometimes, life just happens.

But to make it up to you, O Gentle Reader, I share with you one of my most trafficked posts, from Logorrhea.

Enjoy.

Logorrhea

Working on mobile devices forces one to make conscious decisions regarding coding choices, if for no other reason that resources are scarce (memory, screen size, bandwidth). Taking the easy route and ignoring wise mobile programming practices can take what could be a promising application and make it a disappointing user experience.

If you’ve spent any time with the Google Android SDK, and have tried to read a JPEG into a Bitmap using Media.getBitmap, you’ve almost certainly run into this little gem of an error message:

bitmap size exceeds VM budget

Unfortunately, since Android caps all applications’ VMs at 16MB in size, it only takes one or two big image reads to get you into trouble, regardless of all the garbage collection and Bitmap recycles you may try (see code snippet at the end of this post for more on that).

So, what’s a programmer to do?

Well, the…

View original post 331 more words

Decisions, Decisions

Decision making is the key trait, by which your leadership and management style will be judged.

Are you consistent in your decision making approach? Are you thoughtful and considerate? Are you rash? Do you put off decisions, until the matter is settled for you, by outside forces?

Vital to being a good decision maker, regardless of your style of deliberation, is your ability to process data and information from many disparate sources, some contradicting each other entirely, and coming to a timely, best possible decision that you can make; or, at least, the best possible decision that you can make for the moment.

By making decisions, you are declaring your thoughts and decisions for all to see.

But more importantly: Decisions are the key metric by which your job performance will ultimately be judged.

Inaction until a decision is made for you is sometimes a powerful and extremely powerful tactic; however, it is a poor default decision making mode, because it makes one look ineffectual and out of control, rather than decisive.

A wrong decision made with clear decisiveness can be used to good effect; first, as a way to show that it is OK to make mistakes and attempt something untried, and second, to demonstrate leadership as a learning and growth exercise.

I can’t stress enough that decision making is the very DNA of your leadership style and character. And, like all great attributes of leadership, you learn by doing.

Decide to be great.

Go, and be you.

Unreliable Narrators

I have long claimed that one truly is well on their way to becoming a mature professional, when they can readily spot unreliable narrators.

An unreliable narrator is usually someone in literature, film, or theatre whose credibility – or at even, perceptions and perspective – is compromised. In actual real life, we’re all unreliable narrators; our attitudes and perspectives are constricted to our limited – and biased – personal experience.

Unreliable narrators are generally not deceitful or deceptive. But, their opinions and internal dialogs are informed by incomplete information, past experience extrapolated inappropriately, and, sometimes – by pure naiveté.

And, because someone is an unreliable narrator in one regard, doesn’t mean that they aren’t reliable sources in every other area.

So – how do you know when you’re dealing with an unreliable narrator?

The best advice that I can give is: trust your own direct experience, over the related experiences of others. That doesn’t mean you shouldn’t take advice from others – only that your direct observations and experiences should trump all else.

You should also corroborate others’ experiences and perceptions against those of the person you think may be an unreliable narrator. If their experience squares with yours, odds are you’ve got a handle on the actual facts on the ground, and can either accept – or discount – the narrative coming from an initially suspect source.

Ultimately, time and experience will allow you to hone your skills at identifying bias, and impaired opinion.

We’re all unreliable narrators – at least to someone. Be objective, transparent, and authentic in your interactions with others, to minimize your bias.

Go, and be you.

Recognizing Opportunity

Sometimes, being successful as a software developer has zero to do with having great talent.

Sometimes, being successful is simply being lucky. Being in the right place, at the right time. Having skills and talents that are needed at just that moment. Knowing the right people. Getting in early.

But most times, it involves you recognizing opportunity when it is staring you right in the face.

If I had to choose something (aside from being conventionally handsome, naturally) to have as a career skill, it would be to have an innate ability to recognize opportunity – and the courage to act upon that opportunity – at all times.

This is silly, of course – because it presupposes that recognition has no basis, other than having some sort of Eureka! moment, without having any context whatsoever.

The ability to recognize opportunity is actually possessing mastery over multiple domains; and, understanding how those domains may be applied in new, and useful, ways.

Technology innovation sometimes drives opportunity recognition. But without mastery over the problem set being solved, there is no there, there – technology innovation is mostly a necessary, but not sufficient, precondition of successfully acting upon opportunity.

Today, the technology land grab is in wearables (Apple Watch, FitBit, Pebble), Mobile, and the Internet of Things. New platforms are the seedbeds of opportunity. But, without a clear understanding of how these technologies may be successfully staged to solve a real world problem, you’re at less than zero.

And even when you have the skills, and the recognition, to act first – and act fast – success is still not guaranteed.

RadioShack was the first retailer to broadly market personal computers and cell phones. They are now bankrupt. Palm was the first – and initially most successful – maker of personal digital devices. Now dust. Microsoft marketed one of the first smartphones – currently an also-ran in the mobile space.

It’s not enough to recognize opportunity. You have to be committed to do something with that knowledge.

Go, and be you.

Not Everyone’s a Special Developer Snowflake

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

Pffffftttt.

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.

Process to Proficiency

Every developer is different.

Some sit and stare until inspiration strikes out of the blue. Some talk over problems and solutions with their colleagues. While still others put on their earbuds and proceed to get biz-zay.

What they all have in common is a process by which they approach their work. Proficiency doesn’t occur by accident; it occurs through a systematic application of your craft.

Why is process important?

Because without process, you can’t predictably project when any given engagement will complete. Without process, there is no reliable and repeatable way to communicate what you will do, how you will do it, or how others will sync up with your work.

Now, whether you call this project management, or methodology, or simply your mojo, it’s all the same – you need a consistent programming practice, a method to your madness.

Test Driven Development. Agile. SCRUM. Waterfall. ITIL. All of these methodologies are designed to wrangle order from chaos, getting teams of developers to have a common purpose and a common meta-language to coordinate their development efforts.

Minor wars have been fought over which methodology is better than all others. But this isn’t a treatise on best processes; only a declaration that process is necessary for proficiency.

What you will find, in actual practice, is that not every programming problem needs or deserves the full brunt of whatever team management process you currently subscribe to.

Sometimes a mix of methodologies is called for to get the job done.

The simple fact is this: over your professional life as a developer, you will learn – and forget – a multitude of technologies, languages, and tools. Mastering the tactical at the expense of the strategic

What will sustain – and prolong – your professional usefulness, is your ability to systematize your approach to your craft, to learn how to learn, and to embrace process.

Go, and be you.

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

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.

Wah, Wah

Blame it on the internet. Or the new job. Whatevs.

Today’s regularly scheduled 300 Words, 2 Minutes is AWOL.

Wah, Wah.

We’ll be back tomorrow. Promise.

For today, please enjoy this oldie but goodie from JT:

Man Plans, G-d Laughs

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: