Read how Matt Simmons created this parody of a speech titled "God made a farmer" over on his blog.
It's a widespread practice to give sysadmins and developers that have accrued a few years of experience a new prefix to their job title: "senior". So they suddenly become Senior System Administrator, Senior Ruby Developer and so on.
So, senior something. What does that even mean?
The very senior John Allspaw shared his thoughts on this topic a few months ago on his blog under the title "On Being A Senior Engineer".
John cites Theo Schlossnagle who asked what might come next:
After five more years will you not have accrued more invaluable experience? What then? “Super engineer”? Five more years? “Super-duper engineer.”
When you get promoted to a "senior", you haven't actually become someone else over night. It's not an event of metamorphosis, neither of enlightenment. John chose to find another adjective that has more meaning:
I expect a “senior” engineer to be a mature engineer.
And he lists these main characteristics of a mature engineer:
- Mature engineers seek out constructive criticism of their designs.
- Mature engineers understand the non-technical areas of how they are perceived.
- Mature engineers do not shy away from making estimates, and are always trying to get better at it.
- Mature engineers have an innate sense of anticipation, even if they don’t know they do.
- Mature engineers understand that not all of their projects are filled with rockstar-on-stage work.
- Mature engineers lift the skills and expertise of those around them.
- Mature engineers make their trade-offs explicit when making judgements and decisions.
- Mature engineers don’t practice CYAE (“Cover Your Ass Engineering”)
- Mature engineers are empathetic.
- They don’t make empty complaints.
- Mature engineers are aware of cognitive biases.
He explains each characteristic in depth, so don't miss reading his post!
So, can you tick all the boxes of the mature engineer for the seniors in your team, for yourself? Yes? Then there's one last aspect.
After listing "The Ten Commandments of Egoless Programming", John adds another essential requirement that I was missing in quite a few senior sysadmins I have been working with over time:
Dirty secret: mature engineers know the importance of (sometimes irrational) feelings people have. (gasp!)
When you'd like to become a senior, or better, a mature engineer, then first and foremost become a mature person.
If you're going to speak at a conference, as I will at the Drupal Dev Days in Dublin, you must read Kate Matsudaira's post "So you want to speak at a conference…". It's chock full of great advice on first getting a speaking slot at a conference and then making the best of this opportunity. I've got years of speaking experience and still learned (or remembered...) some important bits that will help me leave a good impression on my audience.
After trying collaboration tools like Yammer for a while, email had a renaissance at freistil IT. Our decision of giving the dreaded mailbox another chance was triggered by a post about how the team at Stripe practices email transparency. We've adopted their system and it works well; we still need to get more used to it, though.
This is how it works: Every team and project by default has three or four mailing lists (like Stripe, we're using Google Groups for Business):
- A conversation mailing list ("marketing") for the communication within the team. Everyone in the team (and maybe beyond) subscribes to this list.
- A low-traffic announcement mailing list ("marketing-announce") that reaches many or even all coworkers.
- A "bacn" mailing list ("marketing-bots") that receives automatically generated emails, for example from social networks and external services. Everyone that manages or uses such a service subscribes to this list.
- An archive mailing list ("marketing-archive") that is mainly used to preserve emails that don't concern anyone at the moment. Very few people will subscribe to this list, but it makes it easy to share emails instead of hiding them in personal mailboxes.
The effect of this approach is not only easy written communication but, just as important, transparency:
"As we’ve grown, the experiment has become about both efficiency and philosophy. We don’t just want Stripe to be a successful product and company. We also want to try to optimize the experience of working here. As as we’ve grown, we’ve come to realize that open email can help."
By sorting the daily email influx into many mailing lists (Stripe has more than 100) to which only these people subscribe that have the need, the amount of email anyone has to deal with stays on a managable level.
At freistil IT, we still need to get better at adhering to the addressing rules described in Greg's post. Too much email still only reaches personal mailboxes without being shared in a group visible to the team. I think I'll start by copying the rules into our Company Runbook and from there get them into people's heads (mine included).
But apart from that, it's an interesting experience. As I wrote in a previous post, email can be very disruptive to my daily work. At the same time, being able to at any time tap into exactly these email streams that I'm interested in is engaging and efficient.
As a long-time disciple of Jobs, I use Mac OS applications for almost every task. And if there's a solution from Apple, it's normally the first I try out and probably use. Photo archiving is no exception -- well, was no exception. I've been using iPhoto for quite some time and over many a version jump.
But recently, I've noticed that iPhoto doesn't quite fit my requirements as much as I'd like it to. Especially, I missed having access to my photo library from every device I use. I'd like to be able to process new photos on the fast Mac Mini, sort them into albums during work breaks on my Macbook and show off the latest cute picture of my adorable baby son on my iPad over coffee.
I felt that a change was necessary and it was finally triggered by Sven Fechner's blog post "Exporting your iPhoto library to Dropbox". Using the tools described in the article, I was able to export all my photos together with their metadata into
Dropbox/Pictures/Library. To be exact, they're sorted into subfolders for every month. And all pictures that Dropbox downloads from my iPhone or that I put into
Dropbox/Camera uploadsmanually get automatically sorted into the right month folders by this magic fairy named Hazel.
Other people are obviously doing the same. Just while Phoshare was exporting my iPhoto library, a blog post by Panayotis Vryonis appeared in my feeds. And the subtitle after Leaving iPhoto for Dropbox puts it very succinctly: "from feature rich to future proof". Yes, iPhoto has many useful features and Dropbox won't apply face recognition to automatically tag photos with names. On the other hand, I'm now independent and can choose whatever tool -- and device! -- I like to manage my photos. That's what made it worthwhile for me to spend 20 minutes on exporting all my photos to Dropbox.