Shortcut of Being A Senior Engineer

The brilliant article On Being A Senior Engineer came in my mailbox via A Smattering of Selenium #125 – as it’s a long text, here’s my essence:

  • (…) This is because they [mature software engineers] know that nothing they make will ever only be in their hands, and that good peer review is what makes better design decisions. As it’s been said elsewhere, they “beg for the bad news.”
  • [About criticism of someones code:] „But the attitude that someone’s code is their baby should come to an end.“
  • Mature engineers do not shy away from making estimates, and are always trying to get better at it. (…) No one should be allowed to avoid the issue by the old formula, “I can’t give a promise because it depends upon so many uncertain factors.”
  • Mature engineers lift the skills and expertise of those around them. (…) we call this a “generosity of spirit.”
  • They know that they work within a spectrum of ideal and non-ideal, and are OK with that. They are comfortable with it because they strive to make the ideal and non-ideal in a design explicit.
  • A great manager of mine said to never go to your boss with a complaint about anything without at least one (ideally more than one) suggestion for a solution.
  • Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.”
  • The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge
  • .

About efficiency in test-automation

With GUI-based test-automation (e.g. with Selenium) you establish a system of checkpoints (=testcases/ =scenarios (in terms of gherkin)) for the functionality of the software. The functionality is a set of features. Features have 0..n checkpoints. Beside the system as a whole, every checkpoint is ressource-consuming. That’s because you have to establish and maintain them – the latter in case of the feature changing. Hence the checkpoints shouldn’t be uniformly-distributed over the software for logical reasons. There are 3 main criteria for deciding about the density of checkpoints and which influence the efficiency of your test-automation efforts:
1.) criticality of the feature: How important is the feature for the over-all-functionality of the software – ask the manager!
2.) fragility of the feature: How frequently bugs have appeared in relationship with the feature in the near past – ask the developer!
3.) persistence of the feature: How probable are changes to the feature in the near future and as a consequence a ressource-consuming maintenance – ask the manager!
With these criteria you can make a lightweight plan, where to start the test-automation.
Over the time you add more and more checkpoints as new features come and as you learn about the „organism“ of the software.
Learning should result in heuristic rules like „make a new checkpoint for every new bug“.