Using Origami to Explain What I Do

This is interesting: Getting Crafty: Why Coders Should Try Quilting and Origami

I’ve never done any quilting (I’ve a sister who’s excellent at that), but I’ve done origami since forever. In fact, origami was a way to explain to other people what I did for a living. I’d start with a 6” x 6” piece of paper that was white on one side and black on the other (digital!). Then I’d fold a boat, or a frog, or a crane. That’s what software developers work with – they begin with ones and zeros, bits and bytes. From there, they can build some amazing things.

Not sure the explanation always worked, but at least it was entertaining and instilled a small measure of appreciation for what I and other software developers did for a living. Certainly better than describing the challenges of buffer overflow issues or SQL injection attack counter measures. That approach gets one uninvited from parties.


Image by Anthony Jarrin from Pixabay

The Limits of Planning Poker

As an exercise, planning poker can be quite useful in instances where no prior method or process existed for estimating levels of effort. Problems arise when organizations don’t modify the process to suite the project, the composition of the team, or the organization.

The most common team composition for these these types of sizing efforts have involved technical areas – developers and UX designers – with less influence from strategists, instructional designers, quality assurance, and content developers. With a high degree for functional overlap, consensus on an estimated level of effort is easier to achieve.

As the estimating team begins to include more functional groups, the overlap decreases. This tends to increase the frequency of  back-and-forth between functional groups pressing for a different size (usually larger) based on their domain of expertise. This is good for group awareness of overall project scope, however, it can extend the time needed for consensus as individuals may feel the need to press for a larger size so as not to paint themselves into a commitment corner.

Additionally, when a more diverse set of functional groups are included in the estimation exercise, it become important to captured the size votes from the individual functional domains while driving the overall exercise based on the group consensus. Doing so means the organization can collect a more granular set of data useful for future sizing estimates by more accurately matching and comparing, for example, the technical vs support material vs. media development efforts between projects. This may also minimize the desire by some participants to press harder for any estimates padded to allow for risks from doubt and uncertainty, knowing that it will be captured somewhere.

Finally, when communicating estimates to clients or after the project has moved into active development, product owners and project managers can better unpack why a particular estimate was determined to be a particular size. While the overall project (or a component of the project) may have been given a score of 95 on a scale of 100, for example, a manager can look back on the vote and see that the development effort dominated the vote whereas content editors may have voted a size estimate of 40. This might also influence how manager negotiate timelines for (internal and external) resource requirements.


Photo by Aditya Chinchure on Unsplash

Accidental Social Capital and Status

 

I was made aware recently that I have accidentally acquired some interesting social status: I’m not on Facebook. Apparently, it isn’t just that I’m not on Facebook, its that I’ve never had a Facebook account. I’ve also never had accounts with:

  •  MySpace
  • Twitter
  • Instagram
  • TikTok
  • Pinterest
  • Snapchat
  • Reddit
  • Parler
  • The list goes on and on.

I am fairly active on LinkedIn and for a brief time had a Gab account after it first launched. The latter looked like another cesspool in the making so I deleted the account and moved on.

Acquiring this status wasn’t entirely accidental, even if it wasn’t by design. It was clear early on that the only way to win the race to the bottom of the social-on-line game was to not play at all. I’d seen this movie before. I had some experience with this environment in the pre-world-wide-web days of USENET newsgroups so it was pretty easy to see where this was heading. Thought I’d seen some epic flame wars on USENET but USENET newsgroups are to 21st century social media as camp fires are to nuclear explosions, as head colds are to social diseases.

I’m not so naive to think just because I don’t participate in the vast majority of social media that others haven’t contributed data about me without my knowledge or consent nor that I’m immune to the effects of social media. It’s that nuclear explosion thing. I can’t help but be aware of the blast and getting caught in the blast zone, even being targeted for the epicenter are known risks. While zillions of people are blithely working to feed The Beast’s insatiable need for data in exchange for nano hits of dopamine, my efforts are focused on how to avoid the growing tar pit that oozes from The Beast. I study how others have inadvertently been lured into the hot mess and, even more valuable, those few who have successfully wrestled themselves free.

Neither do I think social media is devoid of value or purpose. This is where LinkedIn (so far) seems to rise above the base rabble. There is a modicum of professionalism and elevated expectation of how one behaves on LinkedIn. (Although, I see signs of this eroding at an accelerated pace.)

As I see it, there is no way I can reliably cash in on this newly acquired social capital and status. It’s value is dubious. A small-talk starter at parties. A novelty. A non-thing that’s interesting like not having purple hair, tattoos, and a pierced face is interesting. To really leverage it, I’d have to jump into the social media quagmire, thereby emptying the account or, more likely, go into serious debt. In the end, carefully curated piles of garbage are still garbage.

So there it sits. A helluva thing, maybe valuable only as a note on my headstone.

Here rests Gregory Engel.
@nothing, @nowhere
He lived in the real world.

The Shopping Mall in Your Inbox

Ian Bogost writes in the Atlantic:

It feels like every company and organization I’ve ever transacted with sends me email every week. Some every day, even. Some multiple times a day.

I see this in action with my wife’s “free” email account hosted by one of the major players in the email provider space. She has another email account that sees none of this. Not because that address is unknown but because it’s hosted on a private email server that I run. Nothing gets through that isn’t specifically allowed by the postfix/spamassassin filters and lists. It’s quite simple, really. If either of us wants to do business with a company that requires an email, I create an email alias with the company’s name as the username. That alias is then assigned as a value to a “whitelist_to” key for spamassassin and entered into an virtual aliases database table for postfix to know the actual email account where the message should be delivered.

If we start getting messages from companies that don’t match the username, we know the original company either sold their list or has been compromised. When that happens, the alias assigned to the “whitelist_to” key is reassigned to a “blacklist_to” key and the alias removed from the virtual aliases database table. We never see another message sent to that alias.

In a very few cases, this also means changing the email address registered with the original vendor. But more often than not, the alias was set up as a one-time purchase and can safely be excluded. I have hundreds of these aliases set up.

The major email providers could implement a system like this. But their business model relies on advertising revenue and such a system isn’t in their interests. The people who have signed up for a “free” email account are, after all, part of their product. And why would they listen to their product and not their paying customers.

Speculating about a perfect world, Ian continues…

The algorithms churn until you’ve interacted with enough promotional emails that every store you like delivers perfectly timed messages that cater to your every need and desire. Fulfilled, happy, you purchase every item advertised to you. Of course, this is not actually what happens. The irony of people’s supposed desire to receive emails from their favorite companies is that more than half of consumers in the United States and Canada say they receive too much promotional email. Personalization is supposed to make relevant messages get through and irrelevant ones falter. But what “relevance” means is constantly changing. If I need new pants, an apparel ad might be welcome. If I don’t, it’s just annoying.

This is the downside of a push system. My email server is more aligned with a pull system. If w need or want something, we go look for it, usually at some place we’ve shopped before. It’s a minimalist mindset thing. The personal habits around this approach greatly minimize impulse purchases. The lack of stuff in our life reflects the success of this strategy – we have no debt, drive 20 year old cars, and replace phones only when the apps we need no longer work because Android no long supports them.

Ian continues…

The fundamental reason marketing emails are clogging up everyone’s inboxes is that email marketing represents the collective outcome of a company’s interactions with its customers and the mailbox services; it does not, in other words, represent me.

Indeed. Virtually all the email marketing from a vendor is opt-out once you’ve given them your email address. Research suggests there would be significant shift in the amount of follow-on marketing if everything was opt-in.

Quoting Helena Tse, the vice president of marketing at Bonobos, Ian observes:

She also told me that the company “continuously explores how to better our toolkit to automate and optimize the frequency business rules.” A professional proclamation such as this might elicit nods at an industry conference, but it casts me in the role of a generator of data rather than a paying customer—let alone a living person who doesn’t need so many invitations to partake of Riviera shorts.

As I said, when you give your “free” email address to a business, you’ve become part of the overall product.

Update – 2021.11.16

Mozilla is offering a paid version for Firefox users the exactly the system I setup and use on my email server. They call it “Relay.”

As you browse, the ⁨Relay⁩ icon will appear where sites ask for your email address. Select it to generate a new, random address that ends in @relay.mozmail.com.

This is pretty slick, but you have to pay for it.


Photo by Matthew Henry on Unsplash

Achieving 10x

Crossed paths with an old but still relevant conversation thread on Slashdot asking “What practices impede developers’ productivity?” The conversation is in response to an excellent post by Steve McConnell addressing productivity variations among software developers and teams and the origin of “10x” – that is, the observation noted in the wild of “10-fold differences in productivity and quality between different programmers with the same levels of experience and also between different teams working within the same industries.”

The Slashdot conversation has two main themes, one focuses fundamentally on communication: “good” meetings, “bad” meetings, the time of day meetings are held, status reports by email – good, status reports by email – bad, interruptions for status reports, perceptions of productivity among non-technical coworkers and managers, unclear development goals, unclear development assignments, unclear deliverables, too much documentation, to little documentation, poor requirements.

A second theme in the conversation is reflected in what systems dynamics calls “shifting the burden”: individuals or departments that do not need to shoulder the financial burden of holding repetitively unproductive meetings involving developers, arrogant developers who believe they are beholding to none, the failure to run high quality meetings, code fast and leave thorough testing for QA, reliance on tools to track and enhance productivity (and then blaming them when they fail), and, again, poor requirements.

These are all legitimate problems. And considered as a whole, they defy strategic interventions to resolve. The better resolutions are more tactical in nature and rely on the quality of leadership experience in the management ranks. How good are they at 1) assessing the various levels of skill among their developers and 2) combining those skills to achieve a particular outcome? There is a strong tendency, particularly among managers with little or no development experience, to consider developers as a single complete package. That is, every developer should be able to write new code, maintain existing code (theirs and others), debug any code, test, and document. And as a consequence, developers should be interchangeable.

This is rarely the case. I can recall an instance where a developer, I’ll call him Dan, was transferred into a group for which I was the technical lead. The principle product for this group had reached maturity and as a consequence was beginning to become the dumping ground for developers who were not performing well on projects requiring new code solutions. Dan was one of these. He could barely write new code that ran consistently and reliably on his own development box. But what I discovered is that he had a tenacity and technical acuity for debugging existing code.

Dan excelled at this and thrived when this became the sole area of his involvement in the project. His confidence and respect among his peers grew as he developed a reputation for being able to ferret out particularly nasty bugs. Then management moved him back into code development where he began to slide backward. I don’t know what happened to him after that.

Most developers I’ve known have had the experience of working with a 10x developer, someone with a level of technical expertise and productivity that is undeniable, a complete package. I certainly have. I’ve also had the pleasure of managing several. Yet how many 10x specialists have gone underutilized because management was unable to correctly assess their skills and assign them tasks that match their skills?

Most of the communication issues and shifting the burden behaviors identified in the Slashdot conversation are symptomatic of management’s unrealistic expectations of relative skill levels among developers and their inability to assess and leverage the skills that exist within their teams.


Image by alan9187 from Pixabay

Deliberate Practice and Coding

Deliberate practice applied to coding offers some unique opportunities. Unlike other skills, like learning to play the cello (to pick one that I have some experience with), you can go very far without a personal mentor. The feedback from the computer is about as objective as it gets. It will let you know exactly how good your code is.

This also helps remove the emotional component – positive and negative – that can sometimes impede progress with an in-person mentor. This doesn’t remove all emotion, however. Just about everyone who’s worked in a professional coding shop has witnessed the rare occurrence of a coder cursing at or even physically attacking their computer because their code isn’t working as expected. Those are surreal moments when an avalanche of cognitive biases and unconscious behavior become visible to all but the coder. That’s a topic for for a different post. Suffice it to say, learning how to control your emotions, channel frustration, and ignite curiosity is part of what distinguishes good coders from great coders.

Which gets met to finding quality feedback. While I’ve made a good living writing mountains of proprietary code for various business and corporations, I earned my coding chops by working on or authoring open source projects. This was the best source I found for getting feedback on my code. It also taught me another important lesson: Do not attach your identity to the code you write. Like any noob, I had a lot of pride in my early code that was pretty much untested outside my little work environment. In the open source world, the feedback was often swift and harsh. Or, at least is was when my identity was attached to it. Learning to separate work product from identity revealed just how much emotional spin I was putting on what was in hindsight reasonable feedback. I have concerns that the current climate in the coding world is opting for soft feedback and good feelings over legitimate and reasonable feedback. This, too, is for another post.

It’s worth giving some thought about the the pros and cons of working with an actual person for mentorship. Along with good instruction, a single mentor will pass along their own limitations and biases. Not necessarily a bad thing, just something to be aware of. So multiple mentors are better than just one, which starts to move down the path of actively participating in open source projects. By “actively” I mean not just contributing code, but studying the code (and it’s history) of existing successful projects. There are usually many ways to solve a problem with software. Work to understand why one approach is better than another. Insights like this are best gained, in my experience, by studying good code.

Somewhat related, if you are working from a book or a training program, actually type in the examples – character by character. Don’t cheat yourself by copy-pasting code examples. This is the muscle memory component to coding that you will find when learning other more physical skills (like playing the cello.) If you really want to experience the gnarly edge, ditch the IDE and code with at text editor. I still do all my coding in vim and this keyboard.

Another approach to deliberate practice is the idea of coding “katas.” This never clicked with me. I attribute this to having studied martial arts for 25 years, most of that time at the black belt level. Mapping the human psycho/physical world and the purpose of katas in the dojo to the machine world is too much of a mis-match. Much is lost in the translation, in my experience. The katas in the dojo, regardless the art form, translated easily to other styles and practices. The coding “katas” are more tightly coupled to the coding language in which they are written. In my view, it’s yet another example of swiping a cool sounding word and concept and force-fitting it to another domain. A software version of cargo cults – expecting form to create function. “Black belt” or “Ninja” coder are other force-fits. Yet again, something for another post.

But those are my limitations. Your experience will no doubt be different. As learning exercises and proficiency tracks, many of the coding “katas” look to be very good.

(For related thoughts on how building your own tools can deepen your understanding of a skill, see “Tools for Practice.” The examples in the article combine software development and cello practice.)

 

Image by Robert Pastryk from Pixabay

Tools for Practice

Building the tools you need to develop a skill will also deepen your understanding of that skill.

The pandemic has offered unprecedented opportunity for reflection and self-improvement. Unsurprisingly, most people don’t see it this way and therefore have failed to take advantage of the opportunity. Upsetting the status quo and the familiar – however slight – leads to a disproportionate amount of stress and anxiety for many people. The prospect of getting to know their families or themselves better proves uncomfortable enough to drive people toward bing-watching TV, over-eating, alcohol, or any number of other distractions. Anything to avoid introspection. My theory is that this happens because most people have either lost or never had the skills for self-reflection. External validation is the way of the 21st century. That usually ends up with them expending exorbitant amounts of effort justifying their shortcomings or assigning blame to the nearest face they can put on their problems – an “annoying” partner, an “uncooperative” co-worker, etc.

I also believe it takes very little effort to begin the work of reflection, introspection, and self-improvement. Start simple.

When it was clear the pandemic lock-downs were going to go on longer then the “experts” kept saying – evidenced by the weekly movement of the goal posts – I began to wonder how I might use this newfound flexibility for how I organize time. No longer confined to the hours during which I would normally be in the physical office, I could now complete my 8 hours of work – broken into pieces – at almost at any time during my waking hours. Plus the distance I had to commute back and forth from home and work shrank to an incredibly small fraction of what it used to be. This, too, opened up more time. This change didn’t just occur in my world, but globally. And since everyone else still needed to stay employed, many creative people found ways to continue their professions in a virtual environment. Suddenly, engaging in things of interest but were unattainable because of time and space requirements became available.

I had been wanting to rekindle my interesting in playing cello for years. I hadn’t had a lesson in over 10 years and practice had fallen by the wayside. Now, connecting with an instructor was not only possible, but the number of options had exploded. There are now many on-line videos and instructors available. After a little research, I connected with an instructor in New York City and have been taking weekly lessons for the past three months.

The re-introduction of live music – particularly music that I’m playing – has had a surprisingly positive impact on my disposition. As a card carrying introvert, I thought I’d been handling the pandemic lock down pretty well, especially when compared to many of my peers. Yet this small change, focused on personal development, brought warmth and light to mid-winter days.

So that’s the back story. Now that I’m in the groove again with playing cello, I can describe several things about this experience that I’ve learned with respect to practice, particularly deliberate practice.

Along with playing cello, I wanted to deepen my understanding of music theory and learn how to sight read music. During one of my lessons, the instructor and I kicked around the idea of using flash cards. The card would show a single note and the student would play that note. Searching later for such an application was unsuccessful. It probably exists, but it wasn’t something I wanted to spend more than 30 minutes trying to find.

All the flash card programs I looked at are designed to teach things in a question – answer format. They work well for subjects like history or learning a new language. But nothing that would simply show a new card after a time delay. So I wrote my own program to accomplish this. In the process, I developed my understanding of the cello’s range of notes and music keys in general. Here’s a screen capture of the first iteration’s MVP:

At an adjustable interval, a new note within the cello’s range is displayed in the selected key. For my skill level, this is immensely challenging. And I can tell it is developing my skills for sight reading and quickly finding a particular note on the instrument.

Developing tools like this is second nature to me and the result of many years of experience working with wood and solving business problems with software. Each of these activities has a tenet that if you can’t find a tool you need, you build what you need from scratch. This tenet is all the more powerful by having stewed in the mindsets associated with hand tools and open source software. In a very real sense, creating tools that support acquiring a new skill are part of the practice. To build an effective tool, you must fully understand the problem it is intended to solve. An effective tool is the result of having asked and answered many good questions. And, of course, all this is driven by an Agile mindset (iterations, tests, experiments, redesign, retest, etc.) design thinking, and understanding the context in which the tool will be used (systems thinking.)

 

Image by endri yana yana from Pixabay