God, I really love/hate it when Apple, or any other framework & API developer, does shit like this.
Love it, because they do exactly what I want them to, they modify an old existing API with an arcane interface (NSIndexPath in this case) to provide convenient, direct access to what we really need as developers (in this case, the row and section of the UITableView).
Hate it, because they don’t document the new API in a reasonable way. Yes, it turns out that there is at least documentation in this case, but it wasn’t accessible in XCode, the way everything else is…I had to google the problem, and find someone else’s nice reference to the NSIndexPath UIKit Additions documentation. Now that I know it is there, I go back to XCode, and yup, I can find it. And it’s not totally un-obvious, but it’s just that one extra click away for me to have missed it the first time.
The API I’m very happy to have just learned about here, is 2 new accessors added to NSIndexPath by the iPhone SDK, .row and .section, which provide convenient access to the relevant information about a multi-section UITableView. If you do any development on the iPhone, you will at some point very quickly want to use a UITableView, and likely a multi-section variety. The plain one works fine for many cases, but sometimes a multi-section table provides a better or more natural organization.
The normal API for NSIndexPath is really lame, it’s basically an array of numbers, which are themselves indices into a tree of nested arrays. You can read all about it on your own time in XCode, have a blast. The row/section API, makes all the sense in the world, and it’s great to have it.
But please, oh god please, API and framework developers across the lands, make your documentation just as orthogonal as your API (or preferably, even more orthogonal). A poorly documented API is sometimes worse than no API at all (take, well, any API that Microsoft has written since the original win32 api. MFC will suffice. Had microsoft never bothered to release that abomination, no one would have been under the false impression that they could actually *use* the API to do something useful or efficiently, and would have just stuck to the ugly, but reliable, for windows anyway, win32 api) Apple’s API documentation is historically pretty questionable, and their API implementations are also similarly pretty questionable. As much as I love application development compared to web development, comparing the NS* API, on which most of the iPhone SDK is based, to something like Rails…the degree to which the iPhone API falls short is just sad. A part of me deep inside cries whenever I think about it.
But still, at the end of the day, I love to write iPhone applications, and I hope that business continues to allow me to fill my time with client work for iPhone apps. If you or anyone you know needs iPhone work, http://www.rcloudconsulting.com ftw.*
*ftw = for the win, meaning if you want the best iPhone developer in the world, that’s where you find him. Any resemblance to the author is strictly intentional.
In the professional world of engineering, there are certain words and labels that are commonly used, and uncommonly defined or understood. In software engineering, “Module” is probably the most amorphous, ill-defined, appropriate-for-almost-anything term we commonly throw around. VP of Engineering is another one, or Director of Engineering. What exactly does it mean to have that title, and what do those people do, especially in an environment like, say, a company of less than 5 people?
My all-time favorite though, is “Senior Engineer.” Commonly “Senior Software Engineer,” occasionally “Software Architect” (which is a completely different job, but I’ve seen the two used interchangeably by many people), and there is a long list of other variants. The main purpose of these seems usually to be to stroke the ego of the person who is the descriptor of the title, but aside from that, the title’s main purpose is usually to distinguishing them from the ill-fated “Junior Engineer” title or status.
On occasions across my career, I’ve pondered these titles…and often wondered what exactly was it that made someone worthy of one title or the other. It was clear to me long ago that many unworthy people held the title of Senior Engineer, so either everyone else knew something I didn’t know, or my standards and evaluation method was different than those commonly held in the industry.
What really does it mean to be a Senior Software Engineer?
Recently certain events have caused me to reconsider this question. Recent events set one, a good friend of mine, someone who is without any question or debate in my mind, a very, very senior software engineer, was repeatedly turned down by multiple software companies, for failing technical interviews. And when I say undebatably senior, I mean Caltech graduate, IQ 3 to 4 standard deviations above the norm at the very least, 15-20 years of very solid experience, and a well-rounded programming god. You may even know his name. In one instance, the technology in question that was his downfall was CSS.
C.S.fucking.S. The technology that, unless you are going to be a browser UI wizard who just focuses on layout and design, has essentially no logic to it, you just look up the features you want or need at any given time on the web like a dictionary or encyclopedia. And he wasn’t interviewing for a front-end job, he was going for a server-side position. CSS was totally irrelevant to his job, and in my book, is basically irrelevant to just about any engineering job. You look up what you need, when you need it, then forget it. You don’t waste brain-space on CSS, it’s just not that kind of information.
Recent events set two, another engineer I know has similarly been judged to be “too junior” by another handful of software companies. His particular situation was slightly different, he was actually in multiple jobs, and then sometimes politely, sometimes impolitely shown the door…but basically, both he and the previous engineer’s situation look pretty identical in nature. This friend of mine has slightly lower credentials than said engineer above, but not significantly different. I can’t help but feel bad for the both of them.
So I ask myself, how could not just someone, but multiple someones, look at the same engineers as I do, and evaluate them completely differently? There are lots of subjective issues involved in all of these types of situations, but the thing that gets me is that it was never those subjective issues that were the cause of the evaluation…it was the hard facts, the objectively measurable metrics that were used to disqualify the engineers in question in every case. Yes, I know that it’s very common to take a subjective dislike, and mask it with an objective window-dressing to make a lay-off look fair…but I honestly believe that wasn’t what was going on. What I think was happening, is that the standards by which the engineers were being evaluated were totally different than what I use. And I think it was due to the relative seniority of the people who were making the evaluations, in large part if not in full.
What exactly do I mean by that? I’ll start my explanation, by referencing Paul Fusel’s book “Class,” which is a piercingly honest and brutal whirlwind of premises, arguments, but mostly observations about the social mechanisms of modern-day America. The basic premise, is that social status in America is, whether you like it or not, a class-based system, and one’s understanding of what “Class” is, is heavily influenced by the level of one’s status in the system. So, for instance, following Paul’s narrative, lower-class people tend to think that money and “showy” things are a measure of class (think of what the term ghetto-fab really means); middle-class people tend to deny that class exists at all, but when pushed they show a strong belief that class is a factor of one’s profession, education, and knowledge (all things that can be acquired); while upper-class people know that class is something that one can not change, it is something you are either born with or you are not…it is a factor of blood a family. Your family is a family of class, or it is not…kind of like medieval royalty. One very interesting observation that Paul Fusel makes, is that upper class people, especially the very top of the upper class, tend to look a lot like lower class people, especially the lowest of the very low. Uneducataed (why get an education, when you are born into the Rockafeller family? It’s certainly not going to help at your upper-class society parties), uncouth (no need to follow social standards, because you are basically above them), and generally unaware of what’s going on in the world (why keep up with events, you already have everything you would ever want or need). It’s not that upper class people are bad people, it’s that they don’t have any external motivation, because they are born with all their means of survival met…so everything in life can be seen as optional.
Now…take that metaphor, and do a quick translation, of “class” into “professionalism”, and class status (middle and upper) into professional titles (junior and senior) and you start to get a decent idea of what I think is going on in the professional software engineering world. When you have junior engineers (middle-class people) interviewing, working-with, and evaluating senior engineers (upper-class people), they find that the senior engineer in some way does not measure up to their standards (of professionalism, which are all things that can be gained, learned), they come to the believe that the person is junior, and that they are in fact senior – it says so on their business card, and they are better than this other fool who was supposed to be senior, so it seems like a reasonable assumption…and god does it feel good to feel superior to another human being (engineers really love this, I don’t know why, it’s in the DNA though). It’s not a difficult mistake to make, but it starts to explain, at least in a metaphorical way (which is how we humans tend to make meaning), how my view of these things can be so different than the people I find myself around.
Metaphors aside, to me, what does it mean to be a senior software engineer? What is it that sets those people apart from their junior bretheren? First of all, it’s not technical knowledge. Or more specifically, not strictly a matter of memorized technical knowledge or ability. For me, it’s a matter of breadth of awareness, and the flexibility to be able to be effective in any area, any environment, any situation, any company, any codebase, any language, any product…in short, any job. It’s the ability to do whatever needs to be done, be that writing code, testing code, designing product specs, setting up servers, maintaining client relationships, balancing work and life, presenting oneself appropriately, acting appropriately…whatever it is, I expect a senior engineer to be able to adjust and manage through, while I would not expect a junior engineer to be able to handle the same wide variety of situations. I would not expect a senior engineer to know any specific language, but I would expect him to be able to program in any language or technology stack necessary to do whatever job needed to be done.
What I expect out of a junior engineer, is productive, technical competence in a small range of areas. This for instance, might be someone who can write solid C++ windows code, for shrink-wrap applications. It could be someone who knows Oracle databases inside and out, someone who is a browser UI wizard, guru, ninja, or whatever other absurd noun your marketing people would like to apply to us next, or it could be a server engineer, who can spin out PHP or Ruby code for days on end with no sustenance except Jolt cola and a 5 pound bag of gummy bears.
I expect almost complete technical competence out of a junior engineer…and I think this is where I get mixed up with people. I believe that my description of a junior engineer, is what most people would label as a senior engineer. And my description of a senior engineer, is what most people…don’t know what to do with. They certainly don’t call them senior engineers. They seem to have 2 alternatives, from what I’ve observed of those around me: 1) become an entrepreneur, and start your own company, 2) ignore much of what you know and can do, and do the menial, repetitive job of being a feature developer…because that is what is available most of the time. Occasionally, there is a position for a real, senior engineer in an existing company…but it’s increidibly rare. Most of the time, if you take a job with a company, no matter what the title, you are going to be a feature developer. That’s just what needs to be done most of the time. And to be honest, coming from someone who’s done it for years, good god it gets boring after a while.
I remember exactly the date, or really range of dates, when I became a senior engineer by my own standards. I had held the title for some number of years previous to that, but it was just a misplaced title, as most of them are. It was 2006. That year, I worked on close to a dozen different technology stacks, from top to bottom, OS to language to framework to APIs to machines. I was pushed, hard, from my comfort zone, by the necessity of a project with a very small number of people with a large vision in a big company, where it is very difficult to make waves and stand out. I went from being someone who was incredibly talented and competent at writing C++ application code, to someone who could write any kind of code, in any environment, any language. It all became the same. There was something very zen-like about it. All of the differences just started to melt away, when I realized that all programming jobs were essentially the same. You get a language, a device, a language, a framework, and an API, or some number of each of the above, and you write the same 6-10 types of code blocks.
There are quite a lot of counter-arguments, many of them very valid, but I’m not here to write a philosophy paper and defend my thesis. I did enough of that back in the day (god bless the Philosophy department at Cal Poly for putting up with me, may they reset in peace), what I hope you might take away from this…is to ask yourself, what does it mean to me to be a Senior Software Engineer, and how can I make sure I don’t make the mistake of pursuing the wrong career goals, or misinterpreting someone else’s behavior. Maybe you will pause for a moment and question your own ideas, to see if they stand up to even your own probing. Maybe I’m way off target for you…but maybe, I’m dead on, and I’ve hit on something that you knew all along, but couldn’t quite articulate.
One way or another, I hope I made you think.