DaedTech

Stories about Software

Jan
26

By

The Pyramid Corporation: Your Grade School Teacher for Adults

Category: The Life of a Programmer Tags: , | 17 Comments

I can now proudly say that I have finished the initial draft of Developer Hegemony.  Currently, it weighs in at a robust 376 pages that contain my blood, sweat, and tears.

Digitally speaking, anyway.

I haven’t yet published the preview of it because I want to give the people I interviewed a chance to peruse the draft before I make their words available.  But I promise that you’ll have a chance to read in its entirety soon.

I have a lot more coming on that front as well, including the announcement of a launch date, so stay tuned.

I mention completing the book because this should leave me with more time and material to post here on DaedTech.  I’ve mostly cross posted from the other blogs I write for of late, but look for an uptick in posts here.

Alongside that change, I’m going to be shuffling some other things around in my life as well, and changing my focus somewhat in the coming months.  I’ll get to all of this later, but for now, suffice it to say that I plan to post more about the suboptimal current state of the corporate entity and what I believe we can do about it.

And, I’ll start that tonight, with a theme that I wanted to address but didn’t fit particularly well in the book itself.  I’m talking about all of the ways that the corporation has come to simulate a sort of parental/teacher hybrid for adults.

Caveats

Before I go too far, I want to say that I’m not intending to serve up a blistering critique of society, per se.  I feel more philosophical and observational about this.

In other words, think less “this is all so stupid and people are sheep” and more “how and why did we get to this place?”

I understand the how, to some degree.  I think, anyway.

Pyramid shaped corporations (the standard corporate structure) have a knack for becoming less than the sum of their parts.  You can get buy with common sense up to a certain level of scale, and then finally you get some weirdo that likes to clip his fingernails next to the coffee machine no matter how much anyone asks him not to.

Then, bam.

You’ve got a sign next to your coffee machine exhorting people not to clip their fingernails, and your whole company looks ridiculous.

I think that organizational childishness tends to scale more than linearly with the average marginal childishness of individuals hired.  The bigger you get, the more your collective adulthood escapes.

Still, though, it’s amazing we don’t blink more often and scratch our head at the state of things.

Read More

Jan
22

By

Automate Your Documentation

Category: The Life of a Programmer Tags: , |

Editorial Note: I originally wrote this post for the SmartBear blog.

Few things, I’d say, strike boredom into the developer heart faster than the subject of documentation.  Does anyone out there really just love wrapping up development on a feature and then cranking out a Word document with a bunch of screen shots and step by step instructions.  Or, perhaps you fancy the excitement of pasting a legal header above a class you’ve just written, and then laboriously documenting all of methods, variables, and function parameters in the class?  If not that, how about the thrill of going back and updating comments that no longer make sense after the code has changed?

I suspect I don’t have a lot of takers at this point.

Documentation is boring, at least for the overwhelming majority of us.  After you’ve built a thing, you want to go build another thing — not rehash in laborious detail what you just did.  And yet, documentation is essential for communicating across time and teams to other people.  Your users will need documentation.  Future maintenance programmers need documentation.  Unless you’re going to be around in perpetuity to handle all that comes, you need to leave some sort of persistent knowledge transfer vehicle.

But that doesn’t mean it has to be tedious, repetitive, or boring.

Repetitive labor offers a certain counter-intuitive appeal, since it creates a “pain is gain” feeling of diligence and accomplishment when complete  But don’t be fooled.  People make many sloppy mistakes when doing repetitive tasks and drudgery is a terrible use of company money when you’re collecting a salary as a knowledge worker.  As people in the software industry, we earn a living automating grunt work out of existence, so let’s take a look at how we can help ourselves when it comes to documentation.

Read More

Jan
19

By

Collaborating with Outsiders to the Dev Team

Category: The Life of a Programmer Tags: , |

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.

Developer news sites, blogs, books, and tutorials tend to speak at length about how developers should collaborate with one another to maximize team effectiveness. The subject of how developers should collaborate with people outside of their team often gets shorter shrift, however.

Personally, I find this to be a shame.  I think it tends to reinforce the stereotype that developers do a poor job of human interaction and need an organizational layer of people to translate between them and normal humans.  I would prefer to live in a world where people didn’t draw distinctions between “the developers” and “the business” because it was simply assumed that software development was part of the business.

For this reason, I’d like to offer some thoughts on how you, as a developer, can most effectively collaborate with non-developers — people outside of your team.  I will offer the caveat that some teams, particularly Scrum teams, are cross functional and thus include non-developers in the team itself.  I understand that, but for the purpose of speaking to the broadest audience, I will presuppose that your team is specialized in the sense that it is made up exclusively of software developers.  Besides, if your team does include other disciplines, it isn’t as if advice on how to collaborate with those folks magically becomes invalid.

Before getting into specifics, I want to mention two universal principles.  The first I will call out only briefly now and not again because it should be common sense and go without saying.  But, in case it doesn’t, treat these colleagues with courtesy and respect.  They are intelligent knowledge workers that simply have a different specialty than you do, and you ought to treat them as such.  If you can’t do it simply as part of being a decent human being, do it because acting like a primadonna is career limiting.  The second principle I’ll mention is that, because these collaborators are intelligent knowledge workers with a different specialty, you should endeavor to learn from them to improve your own work.

Read More

Jan
15

By

How to Turn Requirements into User Stories

Category: The Life of a Programmer Tags: , | 6 Comments

Editorial Note: I originally wrote this post for the SmartBear blog.  

Let me ask you something.  When you read the title of this post, did you envision it laying out some onerous process for converting gigantic Word documents full of requirements into “user stories” in JIRA?  If so, I’ll set your mind at ease right now.  It’s not that.

Indeed, I am not talking about the mechanics of taking the square peg of “traditional, waterfall-style requirements document” and jamming it into the round hole of some ALM suite’s agile workflow.  Instead, I’m talking about the more labor intensive practice of taking a document like that and using it to generate actual, agile-style user stories.  There is absolutely a difference, and not even a subtle one.  Putting, “1.4.2.3 System shall cause cursor to blink twice after user types A key” into Jira and calling it a “user story” does not make it one.

Anatomy of a User Story

It bears asking, then, “since you say that’s not a user story, what is a user story?”  The most common way one sees it defined is via a mad lib.  “As a ______ I want to ________ so that _________.”  The definer then creates an example, such as, “As a personal banking customer, I want to know my account balance so that I don’t overdraft with my next withdrawal.”

To get a bit more philosophical, the user story has three components: persona, action, and value proposition.  The person is the “who” and it typically involves a description of a user or “actor” in the broader context of the system.  Some groups will actually define personas, give them names and characteristics, and then use the names, instead.  “Dave is a 35 year old stock broker with a checking and savings account, who…”  The user story is then, “As Dave, I want to know my account balance so that I don’t overdraft at my next withdrawal.”

The action is the way in which the user interacts with the system.  It is not framed in terms of minutiae and sequential, detailed actions.  Rather, it is framed in terms of goals that can be accomplished in a sitting.  There is a certain amount of art and subjectivity to what is an appropriate goal, but you’ll get the hang of it with practice.

And finally, there is the value proposition of the user story.  In my experience, this is the part that is both most frequently omitted and most important.  (It is also the part that is hardest to grok for people used to waterfall/contract-style requirements).  The value proposition explains why the person in question wants to do the thing in question.  And including it is particularly urgent for two reasons.

  1. If the value proposition is weak or nonexistent, you may deprioritize or eliminate this story altogether.
  2. If you hit a roadblock during a implementation of the action, you can immediately start thinking of other, more technically feasible ways to achieve the value proposition.

Read More

Jan
3

By

Resolutions Like You Mean It

Category: The Life of a Programmer Tags: , |

Let me start this off on an improbable foot by saying I’m not huge on the concept of New Years resolutions, per se.  But I do value reflection and improvement.  And if just after the winter solstice seems like a good time for it, don’t let me stop you.

Finding Feedback

Last fall, I began participating in a mastermind group.  If you have a W2, your employer will typically offer you rather paternalistic guidance under the heading of career development.  I call it paternalistic, since it generally assumes that your goals include working for the company forever, and emulating the people that have worked there forever.  But, set that aside, and you can often extract a bit of value from it.  For instance, you’ll get someone’s take on how to secure a promotion or get assigned to a better project.

If you go the solo consultant or entrepreneur route, nothing like this really exists.  I don’t think someone has used the words “exceeds expectations” in front of me for about 5 years.  This I attribute to the fact that nobody uses those words outside of the corporate performance review.  And I haven’t had one of those in half a decade.

A mastermind group, more or less, fills that gap.  A few people get together at some interval (weekly, for instance), brainstorm, share ideas, hold one another accountable, and offer mutual advice.  Pound for pound, this offers much more individual value than the corporate perf review/boss one on one because it focuses entirely on my goals, not my goals in the context of being a perpetual good solider.

Measure It

At one of the mastermind group calls, we laid out goals for 2017.  Not having done this before, I lurked more than participated, to see what sorts of goals these meant.  The other participants laid out real plans, with real numbers, to do things like change revenue by X% or shave Y% of time off of some operational concern.

I came to the table with vague notions of, “I want to spend less time in cold places.”  Part of this results from my tendency to let lifestyle goals dictate work arrangements.  But part of this comes from sloppiness and the consultant’s peril of not taking one’s own advice.

Read More

« Older Posts
Newer Posts »