The Juice

the juice.png

I was recently asked (paraphrasing) what parts of the work of software engineering do I find “juicy” so I came up with this diagram. Any software engineering task involves both developers (if only me), customers (might be a client), and the processes of design and implementation.

The “external” blue lines are where the customer potentially interacts with the developers, the output of the design, and the implementation phase (you can probably imagine how Agile fits in this.) The “internal” red lines are where the developers interact with the each other and the design and implementation phases.

From a certain perspective, the left side represents the “process” and the right side represents the “results.” Process and results should be balanced – developers may discover they require training in new skills, teams adjust based on where the team is in the process, etc. The process creates results which the developer and customer team review.

The process – results flow iterates with each result. The earlier results are produced, the better for everyone because this is where “education” occurs, for example, the developers learn more about the customer’s requirements, the customer may refine their requirements (or change them!) Both the developers and the customers learn things during iterations which in turn create adjustments in the process.

The list of items within the boxes is basically just all the stuff that I find “juicy” – the more of those items that get checked off for a project, the more excited I typically find myself regarding working on the project.

What’s the difference between Junior vs. Senior Developers


Duncan Brown posted a very interesting question on DZone: “Junior vs Senior Developers: What’s the Difference, Anyway?”

It occurred to me that the answer is, the ability to say “no.”  No to additional feature requests, sacrificing personal life, unreasonable deadlines, etc.  I’ve found that junior developers tend to be “yes” oriented (certainly I was) because, after all, one wants to eventually become distinguished as a senior developer.  Enthusiasm is great and needed, but an over-enthusiastic “yes” can often lead the project, the team, and the company, into disaster when the repercussions of saying yes are encountered, often by the now, unhappy, customer.

A senior developer will say “no”, and even better (after some discussion on Code Project that led me to further clarity), will be able to explain why “no” is the appropriate answer, in such a way that management can make intelligent course corrections.  Second, a senior developer will also say “no” and at the same time propose one or more alternatives for consideration.  This facilitates out-of-the-box thinking that, again in my experience, often leads to better solutions that more easily achievable (meaning, less risk.)

Sure, there are lots of technical metrics one might use, but ultimately, I think the difference between junior and senior developers is reflected in their behavior when asked to accomplish something that is demonstrably unreasonable.