Written by Chris Rowe on 10 Jun 2016
Having spent more time than is reasonable trying to convert my GPG Authentication key into an SSH key, and wondering where
gpgkey2ssh has gone on Ubuntu 16, finally found the answer.
Turns out (since GPG 2.1.11) it's now as simple as
gpg2 --export-ssh-key <Key ID>.
Written by Chris Rowe on 30 May 2016
One of the banes of my life, usually within larger organisations was the annual performance review process. That delightful time of year when you have to scramble round your colleagues for feedback and fill in a mountain of paperwork justifying to your boss (who you'd have hoped would be up to speed on your performance already) as to why you deserve to receive whatever pay rise or bonus they've already decided they're going to give you.
After one particularly annoying experience, I decided to test a theory. One year, despite my having excellent feedback from colleagues and clients, and having billed 105%, my manager threatened to grade me as 'Not Meeting Expectations' because I hadn't contributed enough to the company's internal (virtual) software development community. No, the extra money they'd made from my overtime didn't make up for that, and after all, he had a curve to grade all his employees against. After much to-ing and fro-ing, and a hastily thrown together paper (that I'm pretty sure nobody ever read), I was graciously admitted to the 'Meets Expectations' group. At which point we were told that the company's performance hadn't been great, so the pot of money for bonuses would only be sufficient to pay 50% of what we'd otherwise expect. And no pay rises.
Basically, after several hours of pestering colleagues for references (whilst they're doing the same), and filling out dozens of open-ended questions, all in your own time (no billing code for internal paperwork), and the result is based on which of 5 categories you get lumped into, and how much money the company has decided to give to that group. All rather detached from what was (presumably) the original intent - to recognise and reward/manage employee performance.
I wrote previously about the reasons for doing things being lost over time (because of inertia, or whatever), and it strikes me that the same is true of organisational policies and procedures as it is of software development.
So what is the answer? In this case, I decided to take a leaf out of 37Signals' book. When deciding what features should go into their products, they take a simple approach - they listen to what their customers ask for, then ignore it. Anything that is truly important will bubble to the surface again, and you'll soon get an idea of what is truly important. The same goes for 'corporate' stuff - those small (and large) demands on your time that come from within an organisation. Everybody is busy within an organisation, so although something is being asked for, doesn't make it important. Saying no (or simply ignoring requests) seems to be a pretty effective filter - people will push for the things that they really need, and let the trivial stuff slide. In other words, make tasks earn your attention.
And the result of my experiment? Well, after another year of billing over 100%, I didn't spend tie filling out the reams of performance review paperwork, nor did I pester my colleagues for reviews. And ended up with the same result as I had the previous year...
Written by Chris Rowe on 14 May 2016
One of the simplest and most useful feature of modern IDEs is in their support for automated refactoring, code generation, and generally taking away some of the more mundane tasks from the developer. Let's face it, who wants to go back to sorting out your own Java imports at the top of a class file?
Useful as these features are, there are downsides to relying on having the environment do too much for you. On a couple of recent projects I've seen it lead to a some bad habits - the impact of which have varied from the possibly-annoying to the actually-dangerous.
By way of an example, on a recent project, it was common practice amongst a number of the developers to always override the
toString() methods of DTO-type classes, incorporating all members. Both IntelliJ IDEA and Eclipse will happily produce this code for you if you ask.
toString() in particular made observing the current state of an object simple, either in the console or debugger. The natural extension to this was to use it for logging too -
log.debug(domainObject) and you've written a full snapshot of the state of the object to the log in a single statement. So far, so easy.
However, not all of our domain types were simple with a handful of members. There were a number that were far more complex, either by number of members, or by the fact that they held references to other DTOs (with their own
toString() implementations that would also be called). It does not take long for your single line of code to produce dozens of lines in the log file. The majority of which may not even necessarily relevant to the reason you're writing a log statement in the first place.
I see this kind of practice as being an extension of the that's the way we've always done it attitude - basically a process that has become so much of a habit, that no consideration of why it's done is generally given. I took to calling such behaviour 'Autopilot Programming' - people were willing to continue with doing things the same way and not really thinking about the consequences.
Now, of course, having busy log files because you've auto-generated
toString() the whole time isn't the end of the world. Yeah, the SNR sucked, but disk is cheap and analysis tools are getting better and better. But what happens when one of the members of your DTO contains something sensitive? Like a private key, for example? Yeah, that happened - was written out every time we wanted to log anything to do with one of those objects. Which was a lot. Because a developer didn't think about what they were doing and just carried on on autopilot...
Written by Chris Rowe on 11 May 2016
To entirely mis-quote a recent production of Cosi Fan Tutte, the idea that it is the Scrum Master's role to protect the team from outside influences is something akin to the Lost City of El Dorado - frequently talked about, but seldom seen.
It is, of course, part of Scrum orthodoxy that this be the case. The Servant-Leader ensuring that the team is able to progress its work by removing any impediments encountered, and ensuring that distractions from elsewhere within the organisation are controlled. The reality, however, often seems somewhat different.
It be former Project Managers finding themselves re-roled as Scrum Masters. Introducing Scrum or other Agile disciplines into an organisation that isn't used to it. Or even contractual constraints that were written on the assumption of a Waterfall approach. There are any number of competing pressures the Scrum Master is going to have to deal with over the course of a project.
In my experience, both as a team member and a Scrum Master, the 'Servant' side of the equation almost always seems to come more naturally. The 'inward-looking' part of the role should be easy - an empowered team, once it gets into flow, should be relatively low maintenance. This is the Scrum Master as a guide, mentor, and offering the occasional push in the right direction. As long as everyone is headed in the same direction, the team should almost take care of itself.
There are, as previously noted, two sides to the equation, and it is on the 'Leader' side that weaknesses tend to appear, as this is where the pressure is being applied. Depending on the organisation this may be with other teams, from management above, or even directly from customers. Co-ordinating resources and handling interruptions is usually a management or organisational issue, and can generally be taught and/or learned. It's in handling the pressure from above that the Scrum Master is really going to have to earn his money.
The problem with pressure applied to a team from above is that it's almost always comes with an element of authority to it. Be it Line Management or project funding related, there will almost certainly be an assumption by the person making the request that they're entitled to do so. And it's here where the Scrum Master must lead rather than manage - being able to stand up to someone that is potentially much higher up the corporate food chain (and may be directly responsible your progression within the organisation), is not necessarily something that comes naturally to people. But, being able to hold that umbrella up and protect the Scrum team is something that will pay dividends in terms of delivery (and indeed developer happiness!).
It is often easier, in these circumstances, for the Scrum Master to follow the path of least resistance - "Sorry team, my hands are tied - this has come from above" is a refrain I know I've heard more than once. But by adopting that position, the Scrum Master is basically ducking the 'difficult' part of their role, and allowing their team to pay the price. Yet this is exactly where the role adds most value.
One of the values espoused in the British Army is of having 'Moral Courage' - that we do what is right, not necessarily what is easiest or most convenient. It's a standard that the Scrum Master should also hold himself to.
Written by Chris Rowe on 08 May 2016
Well, consider this the metaphorical ribbon-cutting on the company website. After all the usual administration headache getting things set up, we're now ready to go.
I'm currently looking at securing some longer-term contract work - can offer a breadth of experience in designing and building Java-based back-end services for organisations large and small. Most of my recent project work has involved construction of RESTful APIs and work with NoSQL datastores. I'm also comfortable working in an Agile manner, and am a Certified Scrum Master.
Have a look at my personal LinkedIn page for a fuller idea of the skills I can offer, and feel free to get in touch.