And you are here why?

"Seniority" is a pretty loaded term, which depends on the organization one is in, and what that organization wants to get out of it. After all, at Alice’s Software Factory there might be a bajillion gradations involving all possible combinations of [ junior, senior, systems, lead, principal, etc. ] and [ developer, engineer, analyst, architect, wizard, etc. ]. And additional combinations too —  senior principal systems analyst  wouldn’t be out of the question. If you ignore the labels, there is a much more basic question at hand here, and that involves the people attached to the titles. To wit,  what allows people to climb up these ranks?  Mind you, this is more abstract than just straight up software engineering — it’s about pretty much any field, and how you differentiate “seniority” in that field. Me, I tend to break this up at a very high level into a few basic categories, viz.  Junior ,  Mid-Level , and  Senior . The difference? I’m glad yo...

Interviewing is hard. You don’t need me to tell you that, but it bears repeating regardless — the stakes are high, and the repercussions from making a bad choice can be enormous. Oh, the negative impact can seem smaller as your team size grows, but that is an illusion — the loss of productivity across the entire team can easily swamp the (illusory) benefits of making a bad choice. (•) There are an (higher order of) infinity of articles around how to go about interviewing people, including   some seriously weird s**t.   I won’t get into any of that here, but   will   cover some of the main things   I   look for when interviewing. Mind you, most of these focus — intentionally — on   soft skills .   In most cases, these tend to be   the   dominant factor in the success or failure of projects (and this only increases with the number of people on the project) /via http://explosm.net/comics/2717/   1. Chemistry   (aka: “Va...

Do *you* know how to make your team productive? I sure as hell don’t. Mind you, I know any number of ways to  decrease  productivity. Some of them are ludicrously obvious (open-plan offices, daily all-hands, audible Slack notifications), and some, not so much (poor air quality, working through breaks). ( I mean yeah, if you want to go down the “you increase productivity by removing things that decrease productivity” route, well, yes, I’ve got ideas. But that’s already pretty meta, and not quite the direction I’m going in. ) See, the problem starts when you get down and dirty, and start trying to figure out what exactly it is that you mean by “productivity”. We ourselves are quite to blame here — once we realized that making decisions without data was prone to error (who would-a thunk it?), we started measuring  everything . That’s been A Good Thing for a lot of stuff (Instrumentation, Observability, etc.), but it’s also caused no end of issues thanks to  M...