Software on the Brain

Who are you growing?  It's important for leaders to ask themselves this question regularly.  And if the answer is "I'm not sure" it's time to get busy.  Building up your leadership bench is among the most important things you can do.  And you don't need to manage people to be a leader.  Are you a Tech Lead or someone that has a strong influence across your organization?  If so, you're a leader.  Read on. Leadership development isn't a luxury.  It's a necessary risk reduction technique for your business, one of the basic facets of succession planning.  For every leader in your organization (that includes VPs, Directors, Managers, Tech Leads, etc.) it's ideal to have someone that could step into their shoes (with support), ideally someone they have been grooming for some time.  Key leaders will depart the organization or move on to other roles.  They're in high demand and have no shortage of opportunities.  It's not a matter of *if*, it&#

The Single Responsibility Principle  (SRP) is the first of the SOLID design principles that have been highly influential in software engineering since they were introduced by Robert Martin ("Uncle Bob") in 2000.  Unfortunately, this particular principle is often misunderstood.  When coupled with blind faith this can engender overly simplistic thinking and design mistakes. The principle has often been framed as "each software module should have one and only one reason to change".  And then the name seems to suggest that the module should have a "single responsibility".  That seems pretty easy to understand.  So the module should only do one thing, right?  No .  There's a different rule of thumb around that: a function should only do one thing.  Have you ever held your nose while naming a function something like "ImportData And LoadIntoDatabase".  We know this: a function should have a single, well, function . The SRP is a license to sometim

“What’s your 3-5 year plan?  Where do you see yourself in a few years?  What do you want to accomplish?”  Unless you’re in a massively trusting setting (e.g. a spouse or best friend), who wants to answer these kinds of questions?  You might feel put on the spot.  You might feel ashamed at not having an answer or that the answer might somehow be graded.  Am I ambitious enough?  Am I humble enough?  Is it ok to say “If it were open I’d like to have your job”?  Is it ok to say I want to start my own business even though that may imply leaving the company?  Stumbling for an answer you might mutter a platitude such as “I see myself seeking gradually increasing levels of responsibility while maximizing my positive impact on the dynamics of the business...” (zzzz)  So on the receiving end, we see these conversations as challenging.  When we ask these questions of those that we mentor or manage is it any wonder that they don’t always go so well? What is the desired outcome of exploratory discu

The "you" and "I" in the post are both me (yes, I'm talking to myself).   Note that, in this post, the term "feedback" denotes constructive criticism only.  I also exclude from consideration cases where the person giving the feedback is deliberately lying or where critical aspects of the feedback are built upon presumed facts that are demonstrably incorrect. Remember that: All feedback is a gift .  Imagine feedback to be a stated observation regarding a non-deterministic system that is essential for you to get anything done; but the system has no documentation, no source code, no unit tests and thus no ability to be upgraded.  In order to understand the system, all you can do is create a set of conditions, perform an operation using some input and observe the system's non-deterministic response.  Whenever you uncover problems in the system's behavior that you think will happen again, you devise workarounds.  But you don't always remember t

I usually post tech things on my blog but before being a technologist, I'm actually a human and occasionally experience something worth sharing. And so, an anecdote... In the fall of 2013 I found myself exploring new career opportunities.  At the time, my network within the Philly community was fairly weak as I had worked in Princeton, NJ.  I was targeting VP-level Technology opportunities in the Philly area but I had no idea where to start.  I met a recruiter who had a position open.  We met over coffee and it turned out I wasn't a fit.  But he introduced me to a man that he used to work with whom he said "helps people out". This man didn't know me from Adam.  But on fairly short notice he agreed to talk with me over the phone on a Friday evening.  He had a long drive in front of him and we ended up talking for about an hour and a half.  He listened to me and made me feel comfortable.  He didn't tell me I was aiming too high like others did.  He anticipated m

Introduction   We all know that clean, separated environments are critical for developing and testing our software.  And yet somehow we tend to get it wrong, often.  The Continuous Delivery movement puts this at the forefront of its concerns, which is great.  So if you're headed down the CD path, chances are you are tackling or are about to tackle the "environment problem".  Because it's a tough thing to get right and because it involves up-front and continuous investment, it tends to be de-emphasized in the feature-crazed Agile world.  But unless you're just doing a proof-of-concept, not solving the environment problem will slow you down, hurt quality and become harder to fix over time.  There are a few anti-patterns that I see over and over: Not giving proper attention to the data tier(s) of the stack (e.g. relational database, NoSQL database, text/search database, file systems used for storage, etc.) Not extending environments "all the way out&quo