first_page

the most important thing I have learned as a developer in the last ten years

I will truly be very, very blessed to have 10 more years of life on this Earth as a productive software developer. The most important thing I have learned as a developer in the last ten years is not some engineering technique. It is more of a communication technique. This is what my father taught me about public speaking:

Tell them what you are going to tell them. Tell them. Then tell them what you told them.

In my world of agile-like software development, this translates to:

  1. tell them what/where you are going to code.
  2. code.
  3. refer to the artifact produced by step 1.

That step 1 up there is the most important thing I have learned as a developer in the last ten years. In my agile-like situations, during a sprint we get cards. A card (or a ticket) will have a description and acceptance criteria (when I am lucky). I now see that it is my responsibility to turn that acceptance criteria into a card plan.

My card plan is a declaration to the team (and to the entire company) of what I intend to do. By clearly defining this planning step, I am defining a metric that answers the question, How long does it take to develop a plan for a card? Based on my decades of experience, it should take me less than six hours to write a plan when I am working with professionals. When I am working with rock stars, the plan should already be written (or the plan writes itself).

But let’s get back to my real world: when the card plan takes over 24 hours and “thought leaders” signal that I am the problem, then I know I am surrounded by well-compensated enemies/fools and I should leave the company as soon as possible. In speculative memoriam, I can imagine “thought leaders” (and some managers) from my sordid past pulling moves like:

  • suggesting that we are in a state of emergency and we should be doing instead of writing which is a luxury for those not about to go out of business (apparently, for the last 10 years)
  • suggesting that, because I am a senior developer, the need to write out this plan is a sign of weakness and reeks of an impostor
  • feeling like it is a waste of time to write out these plans (for a narcissist who designed a very proprietary, monolithic system over a period of years) and within 90 days a senior developer should “get up to speed” without much help (no documentation, no unit tests, no product training materials so face-to-face meetings must suffice)
  • when a bug breaks out related to my work, not going back to read my card plan to see that my plan steps were not related to the bug which implies the story needed to be rewritten and the Product Owner(s) are in error
  • immediately assuming that these plans would be too detailed and lengthy instead of curt, precise summaries, literally documenting how a developer’s knowledge of the system is increasing because it is harder to write something short rather than rambling on
  • insisting that we “talked” about what needed to be done and taking the time to write down what was talked about is just a waste of time (because “everyone” has an on-command, intimate memory of what was said when “we live and breathe” this everyday as there is no other “life” but our time in this office building)

So the point I am trying to make is that I have spent most of my adult, work-for-hire “life” non-working with people who were eager to blame me (as I am usually the outsider in so many ways) when Scheiße went wrong instead of taking a humble look at themselves and their long-time colleagues first. Usually, I am hired help the team do something they have never done before (largely because a previous employee with my skills and more left the company—which should be a red flag to me); rarely am I hired to do something that someone else already present can do (or wants to do). I actually consider this redundancy a privilege. Others may call it expensive.

According to people who are not me,

Developers spend most of their time figuring the system out.

My card planning step is a simple, measurable recognition of this unromantic reality. And it is too tempting for incumbent management (and their seconds in command) to accuse a new developer of being stupid rather than admit that their system is AFU (and too neglected) to figure out easily. When you or someone under your watch designed a system that your tool vendor would consider “experimental” at best or hostile to the vendor road-map at worst, then your Scheiße is probably AFU. When your service-oriented architecture is not taking advantage of the true intent behind microservices, then your Scheiße is probably AFU. When you release pre-alpha-ish code to me (featuring recursive calls to Azure Durable Functions) with optimistic expectations around me writing unit tests for it in about a day (longer than eight hours), then your Scheiße is probably AFU. This is, I flippantly assume, what one manager (who is actually quite a brilliant chap) described as my probalistic thinking.

I have worked with arschlöcher who would have prevented me from publishing my card plan in an inter-departmental forum (like JIRA) because it would reveal to non-technical people what is actually going on. Something as simple as indicating a file that others said needed no more work can be a political train wreck. In my new-guy ignorance, I would be unaware that some “embellishments” were in play and my transparency would be seen as a hostile act of sabotage instead of something inclusive and constructive. And, by the way, one hostile act of sabotage deserves another. Had I known about this technique earlier in my career, it would have been easier to find these arschlöcher faster.

My card plan is also a way to find out whether I am an idiot with godspeed as well (of course!)—because senior developers who only want to work eight hours a day can ask stupid questions (to be fair to pessimistic management with no faith in how fast I can adapt and learn, a misplaced question can reveal a serious lack of critical thinking skills and pure ignorance). I would rather be called a stupid planner than a stupid developer because I have never celebrated my planning abilities on my resume. In fact, the very reality around why I am an employee of corporation that I do not own betrays my weak planning skills!

I wasted much of my work-for-hire “life” confusing planning work with actually working. (Actually, more of my professional life was wasted waiting for the first draft of the agile manifesto.) I would have been able to position myself psychologically in the space where I am not blindly angry because an arschloch is trying to passive-aggressively accuse me of being lazy. When an arschloch defines work as pretending to know what I am doing, then yes, untermieter, I am lazy.

um, can a PR duplicate your card plan?

This is a passive-aggressive, science-fiction, time-traveling question asked by an arschloch who does not like to write in human readable languages. The answer to this fantastic (as in science-fiction fantasy) question is yes. In fact, a PR (a pull request) can be proof that a card plan worked which means it is effectively a duplicate of a card plan. But the card plan is meant for humans to read and is used as a historical journal entry to uncover and measure units of work. It is also a warning in place sent to the stakeholders of what is about to happen while the PR records what actually happened (assuming the commit comments are excellent). In the world of unit testing, this is expected and actual, respectively.

er, why do you say “agile-ish”

Sadly, kids, most “normal” Americans are in management (or they leave the industry) before the end of their second decade as a software developer. Few would agree, but I argue that this is case because few organizations have agile values at the core. The agile values I have been hinting at in this artifact you are reading here are of:

  • Transparency
  • Artifacts
  • Inspection

These are filed under Empirical Process Control. In most of the organizations I have experienced, transparency is forced on the organization through some third-party investigation or regulation which threatens to escalate to litigation. In a cultural climate of corporate espionage, the need for secrecy can go too far.

Almost every agile-ish organization is ‘forced’ to define units of work to be done in a clearly defined work period (sprint). This helps to prevent leadership from changing the work that needs to be done without warning (which happened quite a bit in my pre-agile-ish days).

However, I use the term agile-ish because my post-agile-manifesto work history is littered with companies that routinely violate the clearly defined work period, placing pressure on developers instead of product owners/stakeholders (often because there is a hard promise in place for a customer who will give money to the company which is what “running” a business is all about). There is a double meaning to the phrase “push beyond the boundaries” which can romantically suggest a passionate quest for innovation or can be an ask for human beings to destroy their work-life balance without mercy for years. Too many organizations are caught up in the romance and eagerly look for a chance to “push beyond the boundaries” which can translate into giving team members too much work to do. Having enough time to actually plan what you are going to do is a red flag for these toxic people that you do not have enough work. These people are garbage, of course.

my card plan addresses the distraction problem

One famous complaint in the software development world is around distractions. The high cost of commercial real estate means developers will work in environments full of acoustic distractions—let alone organizational distractions like being invited to too many meetings. Blocking out what is supposed to be a relatively small time to plan actual work leaves me with a simple TODO list that I can cling to most of the time—while being jostled around by distractions surrounding my team. It follows that this planning revelation of mine also represents a compromise with the typical environmental disasters of the modern, barbaric workplace.

how does your card plan write itself?

When the acceptance criteria uses domain names (or business terminology) that maps directly to source-control artifacts, the card plan writes itself. In my ignorance, I assume that SpecFlow and Gherkin can automate and accelerate this process. In my current day job, there is the promise (or very strong suggestion) that I will have the opportunity to look into this technology further in a team setting. Maybe not.

https://github.com/BryanWilhite/