Upon completing the Chicago Triathlon this year, I had some thoughts about measurable progress and mentoring which I wanted to share. I fared well among my age group, but my personal time is not the story I’m most proud of. The lesson I really want to share, is about the true value of turning other people on to your passions, and the delight in seeing them succeed.

Last summer I worked and trained hard with my now wife, Jess, so that we both would do the International Distance (1500m swim, 40k bike, 10k run) Chicago Triathlon. We biked and swam together several times a week without fail. I never felt like I was slacking when training with her, but neither was that time usually spent at racing speed. At those speeds, I was due not to match some of my previous times in the bike portion, but the value of us training together, staying mutually motivated, was worth the tradeoff. Already she and I were going to have a milestone of our first Olympic distance tri, and at any speed that’s an accomplishment to be proud of.

Other friends, who already ran in running events decided they’d try their first tri and do a Sprint distance that year. Four of us took a really memorable picture before our races, and it was so fun to have a gang together.

This year, except for Jess who was pregnant, the other friends went on to do their second Sprint Tri, and they brought a fifth person into the mix for their rookie year. It was spreading! There is no improvement more gratifying to watch than the early improvement once someone has done a Tri before. One of our crew, who last year had to stop and hang onto each lifeguard boat as she passed them, this year had the milestone of doing the swim unassisted!

There’s an old African proverb; “If you want to go fast, go alone; if you want to go far, you must go together” This is true in a broader sense than you may think. It can be bittersweet to trade off some of one’s own performance to help another. But that is what makes converts, and new happy converts can keep your own motivation high for longer than you can do it yourself. If you’re willing to see them eventually overtake you, and be truly happy for their progress, than you are truly fighting the good fight!

—

Footnote: I’m actually very glad to have these results, exiting the 35-39 age group with a time in the top 20% of my age group and top 13% overall. In many senses this is a personal best for me, even if not the fastest overall time. That’s a wonderful thing about triathlon- there are so many independent ways to improve! I almost think that improvement is automatic as a function of hours put in- “that which is measured, and focused upon- improves” So I’m glad I did not miss the chance to convert a few new folks, only to rise a few measly percent in overall standing – I’m not going pro any day, anyhow.

Once upon a time in a far-away land, a team of knights were tasked with protecting the food supply of the kingdom by using a magical fence given to them by a very old and powerful wizard.

The fence, all 4,000 magical yards of it, would be used to enclose the farmland on which the food was grown. The fence had the power to keep out invading pests as well as humans, but let water and sunlight through – it was basically the perfect crop-guarding tool. The king said:

“I need you knights to deploy this fence anywhere you want in this land in order to gain for us the largest possible food supply for the health and growth of the kingdom. As you do this, I’ll want you to keep track of the exact instructions for how you did this, so we can repeat the process in other parts of the kingdom, should more magical fence become available.”

Then he left the knights to figure out how this was to be done. As the knights studied the material and asked questions, they learned the following:

• The 10,000 inhabitants of the city required 100 square yards of food each to produce their food
• A plot of land had already been identified that was suitably large to accommodate any shape the fence would enclose
• The fence could be bent but not torn (an existing door in the fence allowed for getting men and food in and out)
• It was a rectangle 1 yard high and 4,000 yards long
• It stood vertically without any other support, as long as it was on top of a layer of lodestone at least 1 inch wide

The lead engineer, Seamus, upon understanding these constraints, and believing he understood what the king wanted said:

“I have enclosed many a field before, and have the necessary tools to do so. I believe we can simplify our task into merely laying down the lodestone in the correct shape, and once we have a repeatable procedure for that, we can unroll the fence to conform to it.”

He continued…

“It is by Providence that we have 4,000 yards of this material. Using the simple construction techniques I have used, and can easily explain, we will have 1 million square yards for food, enough to provide the 10,000 inhabitants of the city the 100 square yards each they need to eat. I need 3 able bodied men to join me tomorrow, and we can begin construction- now let’s eat drink and be merry!”

Everyone was glad that a plan existed, and they drank heartily. In the morning, Seamus unveiled his plan in full:

“From my surveying tools, I have four Squares. I also have four 1,000-yard lengths of line we can use to mark where the lodestone goes. We start all 4 of us at the center, one length of line between each neighbor, then back away from each other slowly, keeping our t-square arms pointing at one another and stopping when the line is exhausted. This construction technique will meet the requirements, and be simple enough to convey to others with minimal tooling.”

The other knights liked the simplicity of the approach, and so construction on the lodestone foundation began.

END PART 1

Where do you think this story is going ? I have a part two in mind, but I’m curious where you all are at in your heads after reading this part..

Dear ‘Uncle’ Bob Martin,

You compared TDD to hand-washing for surgeons.

But the analogy is skewed because hand-washing was not the innovation at all. The innovation was the Germ model of disease, without which hand-washing advice would have been easy to ignore amidst other claims of the day.

I would think that any claim of TDD superiority must be backed up by being able to point to a single design that could only have come from TDD. This is comparable to validating the germ model by pointing to an infection that could only have come from germs. Is there even a claim that such a design exists, only producible by TDD?

It may be anecdotally wise to TDD in many cases, but there are software success stories from the past using other mindset-driven techniques like Literate Programming. How could you compare two such approaches?

I’ve no problem analyzing tests, and testing practices. But I find the community arguing about the ‘importance’ of test-first TDD to be a real distraction from true, causal analysis of the still-unanswered question, what makes software and its tests robust? I think the SOLID principles – which can be found in code, not just in mindset, are much more solid ground (pun intended!) to build software on than TDD. It comes down to: I think results should be specified, not methods.

Dean Radcliffe

AMD is great. It has changed the way I think about code. Just a short reminder that an AMD module looks like:

// mymodule.js
define(['jquery', 'underscore'], function($, _){
   return {foo: 1, bar: function(){console.log('whassuuuuupp');}}
});

and a user of that module looks like:

require(['mymodule'], function(mymod){
  if( mymod.foo === 1 )
    mymod.bar(); //logs whassuuuuupp
})

Very clearly, the code asks for dependencies, and once they have been loaded and provided, the code runs. Deceptively simple. I call it the Ask For What You Need principle (AFWYN).

If you structure a project using AMD/AFWYN, then you know the following:

• every module file contains zero (0) variables that aren’t either asked for, or locally created
• the dependency tree of my app is traversable at run-time, or at build-time by analysis/building tools
• the app could be as lazily or eagerly loaded as you want

I bring this up now, because I’ve seen among experienced server-side web devs, that they have made the shift from synchrony to asynchrony in terms of the service requests their app makes, using callbacks or promises as needed. But they’re still seemingly unaware that fetching parts of your application may be async like service calls too! And this blows their minds, and they just can’t handle it. So, they do things like write code that’s global for all pages, or include javascript libraries from within partials, or ditch jQuery ready handlers, executing code at Javascript load time. They’re stuck praying that dependencies are loaded when their code is evaluated, and doing the Cargo Cult rain dance all the way through IE-purgatory into true Dependency Hell! It doesn’t have to be this way!

NodeJS has given people a way to ask for what they need:

var m = require('dependency');

and this is great. I don’t think it goes far enough, and I prefer the AMD way if only because your list of deps forms a kind of header. But at least CommonJS style as shown above gets the Node developer into the mindset that they have to AFWYN.

The state of the world is far worse in Ruby. Rubyists also have ‘require’, but since Ruby modules don’t have to declare exports, they may return nothing, load many things, or simply monkey with other classes when they load. Ruby require is far more like eval. Most Rails apps don’t even use require in their main files. It’s not that Rails has your code loaded all at once – Rails only gives you the illusion that you don’t have to AFWYN by having an autoloader. The autoloader is like a method_missing, but for constants/types that are not defined – it uses convention to find a suitable file to require, and then loads that file’s objects into the global namespace so other users (also not practicing AFWYN) can have access.

Folks- it’s just not a great idea to not ask for what you need! You make people have to write autoloaders, and in general you unleash Zalgo. But, alas, when you work strictly server-side, it’s a thing you can get away with for a while.

define(['thisone', 'thatone', 'theotherone', 'thekitchensink', 'canYouTellThatThisFileHasTooMuchEfferentCoupling?'],
  function(this1, thatone1, blah, blah){

});

There are other reasons to AFWYN, as well. For the author of a module to pay a tax, even if trivially small, in having to declare a dependency, they and the team become mindful that they have added a new dependency. Any future maintainer can quickly scan the header of that file, and if the file depends on too many externalities, the maintainer (or static analyzer) can say “this is a smell”, or take action.

Now I’ve said enough to sound completely convinced of my viewpoint, and I hope you know that I am. Just kidding – as usual I’m always open to discussion. But I’m converting a project now to AMD and the number of smells it has started to clean up has really convinced me that I’m headed in the right direction. Time will tell.

Well, thanks for following, dear reader – go write some killer code now. And remember “In Life, as in Code – Ask For What You Need! (AFWYN)”

Update: Get your own AFWYN sticker here !

Thanks OpinionLab, for this awesome write-up on me on their blog.

Hello imagined reader.

Since you are a projection of my own imagination, I see your best qualities so clearly ! And you have clearly noticed an absence of writings from this blog. I have so much to write about, and so much I’m learning, yet a paucity of posts recently. How did this situation come about, you ask ?

Well, I found that writing on a blog != participating in a community.

As you can tell by my StackOverflow profile, I’ve been posting answers here and there. My reputation recently went north of 500, putting me in the top 5% of users on the Stack. Admittedly I have a long way to go before my reputation reflects where I feel my professional competency is at, but writing blog posts won’t help that.

Also, I’ve submitted a few (minor) patches to projects on GitHub that I care about. Notably, I made the contributors list of Reactive CoffeeScript, thanks Yang Zhang for that very cool library. I hope to contribute to RequireJS soon as that too has been revolutionizing how I think about front-end work, thanks too, JR Burke.

So in a nutshell, while I hope to synthesize my recent months of learning in an ImpressJS presentation that I take to local user group (and post on this blog of course), in the meantime, I’m content to have my learning manifest in accepted pull requests and SO answers.

So dear Reader, in the meanwhile, catch up with me in the world of actually getting stuff done – you can find me there an awful lot of the time ! Cheers !

PS One thing that I do hope to post on this blog, since it’s more rant-oriented, is about the regressions I feel iOS7 made compared to iOS6, in both esthetics and actual usability. But I’ll need to gather some sources to really bolster that since I can tell it’s likely to be skeptically received. Bring it on I say ! :)

TL;DR – see this ScreenCast about some good practices to adopt in applications running on PostgreSQL.

When it comes to web developers, we’ve become more and more abstracted from the databases we operate on, and more reliant on test automation to ensure certain behavior of our applications and their databases. Make no mistake – this is a Very Good Thing ! Still there is no substitute for data integrity rules enforced at the source. It may involve looking inside at the database, or ‘under the hood’ so to speak, but if that’s what it takes, well you do it. If your database had a switch that said “Never allow bad data in”, and you failed to flip that switch early, you’d have noone but yourself to blame for not knowing about that switch.

In my previous post on Postgres datatypes, some of you may have been wondering “Why bother?” with database constraints ? Rails, in particular, is a framework that seems to have little respect for DRI , and even can have some famous issues with certain types of DRI turned on.

The reason to bother with constraints and specific datatypes in your (relational) database is that that’s what your database was built to do for you, and it’s the best place to do it ! The first letter in DRI stands for Declarative. If a Declaration is in place that a column meets certain constraints, then you can count on that declaration to essentially never fail, if you’ve written it right. The last letter is Integrity. The purpose of these declarations is to ensure integrity of the data. We all know the kinds of messes that arise when data is admitted into the DB that could have been kept out by simple rules initially.

If a person on your team is moving to turn some DRI switches in the database on (further constraining allowable data), this could be a Very Good Thing, which can give everybody a level of confidence in data going forward. A few good questions to ask:

• Did they write tests to evaluate whether any existing application code breaks once these are turned on ?
• Do new validations / error handling need to be added to applications to support these constraints ?
• Are there other systems that talk to the database that need to be checked for possible breakage ?
• Are these constraints intended to apply to future database objects as well ? If so…
• Is there a way for developers to easily add these new constraints ?
• Is there an automated test to catch if they do not ?

This is not a complete list by any means. But it is a finite list of concerns which, once satisfied should eliminate any F.U.D. around making a change not prescribed by a framework and thus apparently unconventional. Mind you, in the database world, declarative constraints are entirely conventional, so whether such a change represents “needless complexity” is a matter of perspective.

Summing up, there should be a barrier to making database changes, especially those which can cause application errors in unaware applications. But there is no substitute for Integrity being applied to your data as it enters. Whether or not you’re a fan of strong-typing your code, or whether your favorite framework uses or eschews constraints, you must recognize that there’s no substitute for database-enforced integrity. Garbage data can be as toxic as garbage code.

TL;DR – Failure contains valuable lessons, and feedback if you listen for them.

Reentering the full-time workforce after a 6 month period of creative hiatus and freelancing, I found the road less paved than ever. I chose the companies I applied to carefully, but faced multiple rejections. Was my sabbatical costing me jobs ? Had I passed my peak ? As a person who’s often felt like the road just rolls out behind me, this was unsettling and doubt-raising. But I was determined to learn a lesson from this. It reminded me of once being cleaned out at a poker table. I said aloud “Well, I learned a lesson there”. To which the winner, who was still stacking his winnings said “Yeah, a lesson is what you get when you don’t get what you want”. Here for posterity are my tales of rejections, hopefully not to be repeated !

Company L was the first company who rejected me this year. They called very interested, phone calls led to a phone screen, and then an online coding session. I must have been ruled out quickly because I had trouble getting the interviewer to answer questions between all the emails he was writing which I could hear him typing. Since when is knowing the Java threading library a relevant interview to a Javascript/RoR position anyway ? Good riddance with that one. It was early – I wasn’t worried yet, only a bit disappointed perhaps because I liked what the company did.

Company D was the next casualty. I liked what they were about, had coffee with the owner, passed technical assessment and pair-programming, then was invited in for a multi-day on-site co-working/mutual evaluation arrangement, which I was told ‘usually results in an offer’. I wanted it, although I questioned their hiring process: Why did they need 3 days ? How could they attract candidates that didn’t have the time to do that ? (It turned out they’d never hired an ‘outsider’ before and so had no real process, but I digress..) Still, I was disappointed to hear that “I was not a good culture fit”. Really ? Glad I helped your company for free for 3 days, only to be told I lost it on ‘style’ aka ‘culture fit’.

After a day or two to process everything, I knew that I had to redouble my efforts to find a place that was right for ME. Because after all, I told myself, if they don’t like you enough, the chances are you’d have been unhappy there eventually.

With Company S I had several technical assessments and skype calls, eventually hearing that there did not seem to be ‘enough alignment’ with their needs and my skills.

Company B, told me there ‘was hesitation’ which was all I needed to hear, and all they deserve to have written about them.

Company N, I had a fascinating in-person interview which I’d looked forward to for weeks. The technical interviews were grueling and exciting. I was sure I’d land Company N. But the following day they informed me I had good instincts but remained a bit ‘non-committal’ in some of my answers. That was news to me.

Later that day, Company G sends me the most impersonal rejection yet, not even a name on the letter.

Fortunately the light was at the end of the tunnel, even though I didn’t know it yet. I had a really good pipeline going, and I already had an interview lined up with company O. Earlier I’d requested they move the interview date up because I was sure I’d be fielding multiple offers and wanted theirs on the table as well. Well it didn’t go down that way, but in fact, for company O, I was a great fit. The interview felt better and less nerve-racking than the others, and I was offered a great job the day after the interview. Doubts lifted, faith was restored, and I was sure I’d be ok :)

How do I see these ‘failures’ in light of the recent events ? For one, it was the Company D failure that lit a fire under my butt, and caused me to improve my search strategy. At that time I’d not had a ‘pipeline’ of discussions with various companies at various stages, I was relatively all-in with D and did not have another on the back-burner. This is not the best way to be. Surely spamming 1000 companies is not the best way either, but for many reasons, including the ability to emotionally deal with a rejection, it’s better to have many potential opportunities in progress.

Also, it reminded me that interviewing is itself an art and skill, and the interviews I did later in the search certainly went better than the ones I did earlier. I had some dust to shake off before I hit my stride.

It also got me obsessed with the concept of Questions. “Have you got any questions for us?” was both the most worrisome and most exciting part of any interview, I probably geared more preparation toward being able to handle that part of the interview, than the technical parts. That is where you get to drive and assess fit from your perspective. It’s uber-important to have lots of questions and to think them out before hand, since that transition from proving yourself, to asking them to prove themselves can be rough, and you need to be ready.

So as you can see, failure can be a filter through which experiences that aren’t the best for you get filtered out. Failure can be a sign that your own redundancy and coping mechanisms need some bolstering. Failure can provide motivation to do better next time. And failure can help you not take for granted what you do eventually achieve. A great thing to remember around this Thanksgiving time of year !

(More to come soon on my adventures with Company O, aka Opinion Lab)

Throwing people into the deep end so that they may learn is a great idea, but we don’t need to skip the steps of teaching them how to visualize success and understand what’s actually going on.

Lets start with the deep-end swimming metaphor. As anyone who’s treaded water can attest to, when you’re doing it efficiently, the hands make a sculling figure-8 motion to generate lift. Now, if I want somebody to learn to stay afloat, I’m going to show them this motion and create a mental model in their head first. I’m still going to have them experientially practice it for themselves in the deep end. But I’m going to send them into the water with this idea already in their head, giving everyone a similar model of what is a successful to stay afloat. If I don’t, some will learn to stay afloat with doggie paddle, some on their back, others doing whatever motion they stumble into. This is an unfortunate outcome which can be avoided.

The book Refactor Your Wetware cites the need to engage both modalities of the brain, R-mode and L-mode. When you paint a picture for the students ahead of time, you are giving them a framework they can use to guide, and then sort through their deep-end experiences. When it comes to software – say, learning git – if you only show them series of ever more complicated git commands and procedures, without drawing a diagram of a tree graph, you are going to end up with students with incomplete mental models, who will be struggling over the most basic things for a long time.

I think no instruction in git is complete without a depiction of a tree with many branches. While learning, a drawing of the tree of commits can gain new branches as we add new commits with git commit -m, or remove them with git reset HEAD^, or switch a marker to another branch as we git checkout branch_name. This way the verbal side of the commands marries up to the imagery of the tree, and an intuition can develop, for what is possible.

Why leave it to chance what mental model and practices the students will end up with, when there’s really only one way that it works ?? We don’t want to end up with Cargo Cult ideas ! Also I don’t want students to have to reverse-engineer the mental model of git from its commands – git sucks for that. Instead they should learn to be comfortable adding and removing nodes from the git tree, and most importantly – assessing their current state ! This is why git diff --cached and git log -2 are indispensible to teach early.

There are lots of ways to teach and learn swimming and git. We’ve learned things about learning, and we should use those things to give students every possible advantage they can have.

This is going to be a confessional kind of post. I want to take a chance by revealing some really deep and vulnerable things about me, so that people know exactly who they are getting when they work with me.

I took this summer and autumn off of my full-time work to go freelance and work consulting-style. Like The Leap Year Project, I felt it was time for experiential education. And boy, did I ever get experience, and learn several lessons. As somebody once told me when they cleaned me out at a poker table “A lesson is what you get- when you don’t get what you want”

I thought I could go to freelancing, or more recently, to teaching, to escape what I felt like was an industry pulling me into corners I didn’t want to be in. Pair all the time ? I want to go faster than that ! Unit tests for everything ? Maybe for part of the app, but let me write the algorithm already ! I had the mentality of a ‘producer’, and produce I did. Not by writing tons of code, but by writing the right code. By listening to the business. But unknowingly dismissing the input of my fellow engineers. I got bonuses. But what was I missing ? Camraderie. Inviting people in to be my brothers and sisters in aspiring to climb peaks made of pure logic.

Nothing makes you feel more alone as an engineer than solo consulting. No hourly rate can compensate you well enough. I’ve found I’m lucky if I get 2 solid solo-producing hours in a day among all the other more connecting oriented things that need to get done. Those hours can be stretched much further in team environments. I’d be willing to do without solo-hours altogether in favor for a blended teaching/learning/doing vibe that I’ve seen coworkers have, yet have been too focused on individual success to embrace. That’s my skeleton, on display now. But the truth is I’m moving past it.

So, do call and check my references. I have some very good references to sing my praises of my productivity and smarts, also some close friends from my last years of work. But I put off a few others, to whom I have been, unknowingly, a dick of an engineer. My apologies if you count yourself among them, but believe it or not you will inspire me to be the teammate I could have been going forward.

Thanks for sticking this out with me, see you around !

— PS In response to my previous post about leaving development to go to teaching: I see now that the same opportunities exist within a development job, I just missed them more often than not. Yes, I would still consider a full-time instructional opportunity (building my coding chops in my spare time), but I see now that I need the camraderie of working engineers more than I first thought. I had a really good time teaching a NodeJS class at the Startup Institute today, though, and will continue to put together presentations and assignments because I feel it’s a great way to get on the same page with others, and I enjoy it.