DaedTech

Stories about Software

By

Developer Tips for Sublime Productivity

Editorial note: I originally wrote this post for the Infragistics blog.  You can check out the original here, at their site.  They also have a lot more .NET-oriented content in general and some really nice tools if you want to go check out their site.

The most common term I’ve heard to describe the zoned-in feeling that a developer gets when engrossed in code writing is “flow.”  This seems like a good term to me — it conveys the sudden ease with which technical tasks seem to become complete.  It’s a heady feeling.

But it’s also an elusive feeling.  If you’re a programmer, the corporate work day is essentially a minefield, filled with flow-killing charges everywhere you step.  During the course of my career, I’ve developed a number of tricks to help me spend as much time in this state as possible, and I’ll share some of them with you today.

TeamRowing

Read More

By

Modern Software Development at Its Core

I spend a lot of time in hotels, so it’s pretty unremarkable that I would spend the first week of 2016 on the 6th floor of some Marriott.  I unpacked and put my things in their usual places.  I make coffee in the room’s coffee-maker the same way each morning.  And I hit the hotel gym each day for a 3-4 mile jog between end of business and going for dinner.  In terms of my routine, the first week in January is like every other week of the year that I’m on the road.

What’s not the same as every other week of the year is what awaits me when I arrive at the hotel gym.  In December, it’s a roomful of softly humming treadmills and a TV firing out staccato bursts of salacious, 24 hour news at a mercifully low volume — the exercise room equivalent of a ghost town.  This week, it’s full of newly New Years-resolved exercisers, armed with old walkmans, weird headbands, and pitted out T-shirts that, until this day, were reserved for painting the house.

A Pitched Battle with a Treadmill

One such man came in at the same time as me, and took the treadmill next to mine.  I punched in my workout settings and started out at my usual 6 miles per hour, while the man next to me fiddled with his treadmill for a few minutes.  Once he got started, he peered at me every few seconds, as if I were taking a midterm via treadmill and he wanted to copy my answers.  He worked himself up to a speed similar to mine, and everything seemed to be in rhythm for 2-3 minutes, until his breathing became extremely labored and ragged.

Naturally, at this point, rather than pausing the treadmill or slowing the speed, he lifted himself off of the belt like a gymnast performing on the parallel bars.  Once this became untenable, he set one foot down on either side of the belt, tottered awkwardly a bit, and then jumped off the treadmill.  I assumed he was done, wanting to live to fight another day, but a few minutes later, he returned with a towel and leapt back onto the treadmill, using his arms to resume his former pace.  Luckily for him, he did then figure out how to adjust his speed, allowing him to alternate between sprinting and walking until he decided he’d had enough.

TreadmillBattle

A lot of gym regulars, as I understand it, find New Years resolvers to be annoying.  I understand this sentiment if you take them as an entire group, seriously clogging up the gym for the first 3-4 weeks of the year.  But it’s hard to fault any individual for wanting to engage in some self improvement and overcoming inertia (and annoyed veterans) to get started.  In fact, it’s downright laudable.

Read More

By

The Best Way to Hire Developers

Editorial Note: I originally wrote this post for the Infragistics blog.  You can find the original here, at their site.  There’s a lot of good stuff over there, so go give it a look.

The other night, I was remembering what might have been my most impressive performance in the interview process.  What makes this performance particularly interesting, however, is not how well I did, but rather how I did well.  And the how left me feeling unsatisfied with myself and with the process.

I was interviewing for a software development position, and this particular organization’s interview process was (1) phone interview, (2) programming exercise, (3) in-person interview. The phone interview went pretty well, and the recruiter had told me that the company was excited about me – a mildly good sign, for whatever it was worth.

However accurate the recruiter’s assessment may or may not have been, the company’s feelings were positive enough to give me the programming exercise.  This all occurred back when I was in grad school, and, at the time of this particular interview, I was in a class called “Advanced Database Design,” in which we explored persistence options beyond the traditional, relational database.  This was a bit of an avant garde class, at the time, because the NoSQL movement had yet to gain a ton of steam.

When they handed me the programming exercise, I had just, in this very class, wrapped up a chapter in which we’d studied using R-Trees to store geographical information.  This unit of study included what they were, how they were used, and a bit of pseudocode to really drive the point home.  As fate would have it, the R-Tree happened to be an extremely elegant solution to the programming exercise for this interview.

BigPileOfMoney

Read More

By

Encouraging Creative Conflict: Form, Storm, Top Gun

If you have any designs on management, it’ll help your cause to learn some of the more iconic bits of that problem domain’s lore.  Software people would be more impressive at cocktail hour by being able to speak intelligently about object oriented vs structured vs functional programming or about relational vs document databases.  Management people would be more impressive at their own cocktail hours being able to bandy about Drucker, lean principles, and Maslow’s Hierarchy of Needs.  And if you hang out at enough of these cocktail hours, you will be unable to avoid Tuckman’s stages of group development.

The short version of these stages is the catchy rhyme, “form, storm, norm, perform.”  The groups starts off being polite and feeling one another out, but they’re more or less too deferential to make serious progress.  After a bit, egos and tempers flare, people jockey for influence and rivalries emerge — the group ‘storms.’  Only once the team has duked it out and subsequently hugged it out can they move on to ‘norming,’ wherein they gruffly put up with one another’s peccadilloes in pursuit of a common goal.  And, finally, in the end, they all live happily ever after, humming along as a well-oiled machine.

Of course, this not only applies to feel-good stories of organizational politics, but also to about 90% of action movies in the history of the planet.  Whether it’s erstwhile enemies Maverick and Iceman agreeing to wingman each other at the end of Top Gun or the romance plot between Han, Leia and Luke eventually sorting itself out, we all get warm fuzzies when the former stormers become performers.  (Sorry, I couldn’t resist.)  Everyone likes a good tale of “form, storm, norm, perform.”

TopGunStorm

We like it so much, in fact, that I commonly hear variants of the idea that teams should be encouraged to ‘storm.’  It’s something like, “we want a team full of people that engage in fierce, angry debate to surface the best ideas, then, when 5:00 rolls around, they let it all go and happily go out to dinner.”  I’ve heard this described as “harnessing creative conflict,” or some such, and it echoes the management (Hollywood) narrative that through challenging one another and letting emotions run high, a catharsis of sorts occurs and all participants come out more creative and more closely bonded for their ordeal.  It’s an appealing notion, and it’s also the epitome of the “extrovert ideal.”

The extrovert ideal was a term coined (I think) in Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.”  It refers to the notion that society has deemed extroversion the ‘correct’ choice between introversion and extroversion.  “Storm to perform” is very much an extrovert thing.  But I’ll return to that later.

Read More

By

Avoiding The Politics of Code Review

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  They have a number of authors over there that are writing good posts.

Asking someone to look over your work is a pretty common practice in any discipline. We’ve been conditioned with the idea that it’s always good to have a second set of eyes look at your work prior to officially marking it as done.

Writing and reviewing code is no exception.  It’s pretty easy to forget to check an argument for null, so having someone review your work only makes sense.  In fact, it makes so much sense that software departments tend to formalize and mandate the process, calling it “code review.”  And the practice is quite effective.

But formalizing and mandating a process in a corporate setting can lead to a variety of unintended consequences.

NuclearDuck

Read More