Hanselminutes #427 was an excellent interview with Jonathan Barronville, the author (perhaps the most intelligent and articulate 19-year-old I’ve ever heard) of this article on Medium. The discussion covered a lot of ground, and posed a number of thought-provoking questions. Three of the questions struck me as especially important.
What is senior?
While industry today seems to have a fetish for young developers, there is merit to that interest in one respect. Men and women entering the industry right now, whether they’re fresh out of college (or even younger) are too young to have any memory of a world where Google didn’t exist. They’re too young to remember a world before web pages. Some of them have been writing software for the majority of their lives. It’s natural to them in a way it wasn’t for me because I had to go to college to get access to really good computers and high-speed Internet.
That said, the number of years (or lack of them) isn’t an advantage or disadvantage if you haven’t had the sort of experiences you can grow from as a developer (and learned the right lessons from them). Regardless of what age you were when you had the experiences, if you’ve had to build software that solved enterprise-level problems, dealt with scaling, refactoring and enhancement of large systems, or integration of systems, both succeeding and failing at addressing those challenges are what really make a senior developer. More time in industry may give someone more opportunities to have those experiences, but if they haven’t had them, they’ve just been writing software for a long time.
What is the rush to be senior?
Hanselman made a comparison between tradesmen like carpenters and plumbers (who have to work as apprentices for 3-5 years and pass an exam before they can become journeymen) and our industry, where someone can have senior in their title without much experience. While some of it (if not most of it) has to do with pay, there are drawbacks. Because our field is relatively young in the grand scheme of things, there aren’t universally accepted standards and practices (especially compared to some branches of engineering, which have hundreds of years of history). We place too much of a premium on speed, and not enough on depth of experience (and the time it takes to earn it). One of the end results of this is the sort of interviews I’ve experienced on a regular basis. I’ve seen tons of resumes from people with senior titles who are stymied by interview exercises that ask fairly basic questions (on the level of the Fizz Buzz test).
I’d been working for less than four years when I first got “senior” added to my title. It came with a nice raise (which I was certainly happy about) and more responsibilities (team leadership), but I certainly wasn’t senior in terms of software development experience after that short a period of time. Not unlike what the classic Peter Norvig essay suggests about teaching yourself programming in ten years, that’s about how long it took for me to see myself as legitimately senior from an experience perspective. Even now, having spent over 17 years in industry, I’m sure there are workplaces where I wouldn’t be considered senior because I haven’t architected super-large systems or led a team with dozens of people—and I’m alright with that. I’ve matured enough after this amount of time to be more concerned with what kind of work I’m doing (and what I’m learning) than I am with what title an employer gives me.
Are we okay with not knowing something and then learning?
This question points in two directions:
- are we okay with ourselves not knowing something and then having to learn it?
- are we okay with others not knowing something and then having to learn it?
For me, the answer to the first question is yes. In the case jQuery and knockout.js (and other unfamiliar technologies like RavenDB), I had to be okay with not knowing. Doing my own research, and not being too proud to ask a lot of questions younger developers on the team who clearly had more experience with those technologies was necessary to advance to the point where I could do all that work myself.
The answer to the second question is the key to many of the problems with our industry, particularly when it comes to issues of gender and diversity. Too many in our industry go beyond not being okay with someone not knowing something and cross the line to being condescending, rude, and even hostile. I’ve been on the receiving end of that kind of treatment more often than I care to remember. Too many workplaces allow people with superior technical skills to act like children instead of adults in interacting with their co-workers. There is more and more being written about the sexism in the industry (pieces like this one, and this one), but not nearly enough on the negative impact that environment has on the ability and desires of others to learn and grow as professionals. I think the persistently low numbers of minorities and women in the tech industry has as much to do with the perception (if not reality) that a lot of tech companies have high “a**hole thresholds” as it does with insufficient exposure to math and science in school.
The bottom line for me from the article and the podcast is not only that everyone in this industry starts out as junior level, but that technology changes so quickly that we will all be junior at something at multiple points throughout our careers in the tech industry. We need to keep that knowledge in mind so that we can be more patient with ourselves as we learn and with those we work with as they learn.