The term ‘experienced’ is a nebulous one. I call to mind former Democratic presidential candidate Hillary Clinton (no hate mail please), who claimed that she had “35 years of experience in government.” Which was strange, since I seem to recall that as of 2008 she had only served eight years in either elected or appointed office.
Likewise, just saying you have 5 years of .NET experience doesn’t make you an experienced .NET engineer. You might have spent all of those 5 years on CRUD apps moving controls around on WinForms. Not that there’s anything wrong with that, but that kind of work does not make for a well rounded .NET engineer.
To me, someone experienced with a technology has had enough depth and variety in assignments to have explored most of the features available in that technology. For instance, if you say you are experienced with.NET, does it mean .NET version 1.0? 1.1? 2.0? 3.0? 3.5? Have you used, or at least understand, collections? generics? multithreading? delegates and asynchronous I/O? garbage collection? If not, you can’t truly call yourself experienced in .NET.
Some may quibble that I’m using a trivia contest to the question of whether someone is experienced in a technology. However, there’s experience and then there’s experience. To me you’re only qualified as experienced if you can confidently discuss the technology in depth and apply it readily to problems. To do this you have to know the ins and outs of the technology, what it’s capable of, and what its limitations and weaknesses are.
Also just as important, if not more so, than the number of years with a technology is what you have done with it. Did you maintain an existing system and fix bugs? Play around with scripts? Or did you actually participate in specing out, building, releasing, and supporting an actual system? There is a huge difference between designing and coding up something from scratch versus just patching holes in it. You will most likely not be considered ‘experienced’ unless you have gone through at least one full development cycle, and preferably several.
Monday, November 24, 2008
Monday, November 17, 2008
What Makes for a Senior Engineer? An Architect?
At larger, more established companies an architect is typically a highly experienced engineer who has distinguished himself/herself during at least 15-20 years of work experience. At other companies, typically smaller, younger ones, the architects may be engineers in their 20s who developed the original systems, however good or bad those systems might be.
So obviously you cannot compare a 45 year old architect with a PhD who has worked at six companies to a 23-year old architect who wrote the first version of their company’s website using Perl and SQLite. The first architect is likely to have a wide breadth of experience in a variety of technologies and design approaches; the second architect will likely have superb in-depth knowledge of how his company’s site operates and the tweaks needed to keep it healthy. Both skillsets are important, but they are not equally transferable.
The same issues apply to the title “Senior Engineer”. An engineer may achieve that title through many years of experience, or because they just happen to be among the most senior members of a very young team. In both cases they are likely relied upon to provide leadership for the more junior engineers, which may be more important than the actual number of years they’ve been working. Still, giving a “Senior Engineer” title to an engineer with 2 years experience is somewhat of a silly game.
The bottom line? Do not place too much weight on titles. An architect or senior engineer at one company may have less experience than a junior engineer at another firm. Just remember that titles are relative, and a fancy-pants architect at one company may flounder at another company. It’s kind of like how someone who skis black diamond runs in the Midwest might get themselves in way over their head trying to do the same in Colorado.
So obviously you cannot compare a 45 year old architect with a PhD who has worked at six companies to a 23-year old architect who wrote the first version of their company’s website using Perl and SQLite. The first architect is likely to have a wide breadth of experience in a variety of technologies and design approaches; the second architect will likely have superb in-depth knowledge of how his company’s site operates and the tweaks needed to keep it healthy. Both skillsets are important, but they are not equally transferable.
The same issues apply to the title “Senior Engineer”. An engineer may achieve that title through many years of experience, or because they just happen to be among the most senior members of a very young team. In both cases they are likely relied upon to provide leadership for the more junior engineers, which may be more important than the actual number of years they’ve been working. Still, giving a “Senior Engineer” title to an engineer with 2 years experience is somewhat of a silly game.
The bottom line? Do not place too much weight on titles. An architect or senior engineer at one company may have less experience than a junior engineer at another firm. Just remember that titles are relative, and a fancy-pants architect at one company may flounder at another company. It’s kind of like how someone who skis black diamond runs in the Midwest might get themselves in way over their head trying to do the same in Colorado.
Thursday, November 13, 2008
Job Titles
I talked earlier about the term ‘IT’ being used in different contexts. This can be a problem because people often have different notions of what IT is. It can be a general term to describe the technical field, which is how I use it, or it can also refer to internal corporate IT departments. I tend to refer to such departments as ‘IS’ or ‘MIS’ rather than IT.
Similar confusion abounds when it comes to job titles. What exactly is the difference between a computer programmer vs. a software engineer vs. a developer? Or an analyst vs. a systems analyst vs. a programmer analyst?
To a large degree this is a game of semantics. In theory all people who write software should be considered software engineers, in the sense that engineers are people who apply scientific and technical knowledge to real world problems. However, in practice there are real distinctions between the various titles that can lead to differences in pay, prestige, and more than a bit of elitism.
A (business) analyst (or systems analyst) is commonly one who translates business needs into software requirements. This type of position exists mostly at internal IS organizations; software companies in comparison tend to have product managers who fill such roles. At any rate, analysts and product managers both tend to stay out of the purely technical realm, except perhaps for those designated as “programmer analysts”.
As for programmers vs. engineers, that distinction came about in large part due to the different educational programs that many universities provided. Students often had a choice between undertaking a computer science degree offered in a school of engineering versus a CS degree from a math or liberal arts college. If you undertook an engineering track, you were exposed to more hard sciences (think chemistry / physics / calculus); in comparison, the math/liberal arts curriculum was seen as a less hard core approach (think more ‘softer’ classes like English Lit.).
To some degree this is an unfair distinction between two very similar programs, but the distinction has still stuck in many people’s minds. So much so in fact that some people saw a ‘programmer’ title as being inferior to an engineer title. As a result, even people who did not have a true engineering degree started calling themselves “software engineers” just for the added prestige. Some saw that as a cheapening of the title, but others felt entitled to the designation due to the nature of their responsibilities.
As for the term ‘developer’, it gained popularity with the advent of the web when people who put together static HTML pages started being called web developers. Some of these people eventually moved on to write some Cold Fusion or PHP code, but the title of web developer stuck with them. Unfortunately this has led to the term becoming somewhat ghettoized in certain circles, such that a “web developer” is thought to be someone who doesn’t write any ‘real’ code, at least not in the classic O-O sense.
My point of view? Call yourself what you like – developer, engineer, programmer. I don’t care, as long as you produce results. But if pressed, I’ll use the term ‘developer’ to avoid the programmer / engineer title controversy.
Similar confusion abounds when it comes to job titles. What exactly is the difference between a computer programmer vs. a software engineer vs. a developer? Or an analyst vs. a systems analyst vs. a programmer analyst?
To a large degree this is a game of semantics. In theory all people who write software should be considered software engineers, in the sense that engineers are people who apply scientific and technical knowledge to real world problems. However, in practice there are real distinctions between the various titles that can lead to differences in pay, prestige, and more than a bit of elitism.
A (business) analyst (or systems analyst) is commonly one who translates business needs into software requirements. This type of position exists mostly at internal IS organizations; software companies in comparison tend to have product managers who fill such roles. At any rate, analysts and product managers both tend to stay out of the purely technical realm, except perhaps for those designated as “programmer analysts”.
As for programmers vs. engineers, that distinction came about in large part due to the different educational programs that many universities provided. Students often had a choice between undertaking a computer science degree offered in a school of engineering versus a CS degree from a math or liberal arts college. If you undertook an engineering track, you were exposed to more hard sciences (think chemistry / physics / calculus); in comparison, the math/liberal arts curriculum was seen as a less hard core approach (think more ‘softer’ classes like English Lit.).
To some degree this is an unfair distinction between two very similar programs, but the distinction has still stuck in many people’s minds. So much so in fact that some people saw a ‘programmer’ title as being inferior to an engineer title. As a result, even people who did not have a true engineering degree started calling themselves “software engineers” just for the added prestige. Some saw that as a cheapening of the title, but others felt entitled to the designation due to the nature of their responsibilities.
As for the term ‘developer’, it gained popularity with the advent of the web when people who put together static HTML pages started being called web developers. Some of these people eventually moved on to write some Cold Fusion or PHP code, but the title of web developer stuck with them. Unfortunately this has led to the term becoming somewhat ghettoized in certain circles, such that a “web developer” is thought to be someone who doesn’t write any ‘real’ code, at least not in the classic O-O sense.
My point of view? Call yourself what you like – developer, engineer, programmer. I don’t care, as long as you produce results. But if pressed, I’ll use the term ‘developer’ to avoid the programmer / engineer title controversy.
Monday, November 3, 2008
Thankless Tech Jobs
I’ve mentioned working in a CRUD position at a cost center as a job you should avoid. But there are plenty of other jobs that are likely much worse than the one you’re in now. So the next time you feel tempted to tell your boss where to shove it, you may want to pause and thank your lucky stars you don’t have one of the tech jobs below.
IT Helpdesk – answering phones all day helping corporate lusers open Outlook or change their password is not my idea of a career.
Customer Support – Neck and neck with Helpdesk in terms of mindless work dealing with clueless people. Often a stepping stone to QA Analyst.
QA Analyst – Repetitively testing the same software day in and day out and pointing out problems is probably not what you had in mind when you spent four years to get your computer science degree.
System / Network Administrator – The only time you hear about them is when something is broken, and then it’s always seen as their fault.
Project Manager – Often a role where you have the responsibility to get things done but not the authority to get people to do the work. You need influencing skills, otherwise known as cajoling, begging, pleading, pestering, conniving, threatening, yelling, and bribing.
Game Developer – Working 80+ hour weeks is expected in this field, and the pay’s not even that great. If you like games, then play them; don’t throw away your youth making the game companies rich.
Junior Recruiter – Despite the negative feelings I may sometimes have for hungry junior recruiters, I fully understand it’s really a high-pressure sales position. Usually it’s sink or swim in the first 90 days. Their choices are to cold-call prospects who hang up on them or else get yelled at by the managing partner who sees them as dead weight.
IT Helpdesk – answering phones all day helping corporate lusers open Outlook or change their password is not my idea of a career.
Customer Support – Neck and neck with Helpdesk in terms of mindless work dealing with clueless people. Often a stepping stone to QA Analyst.
QA Analyst – Repetitively testing the same software day in and day out and pointing out problems is probably not what you had in mind when you spent four years to get your computer science degree.
System / Network Administrator – The only time you hear about them is when something is broken, and then it’s always seen as their fault.
Project Manager – Often a role where you have the responsibility to get things done but not the authority to get people to do the work. You need influencing skills, otherwise known as cajoling, begging, pleading, pestering, conniving, threatening, yelling, and bribing.
Game Developer – Working 80+ hour weeks is expected in this field, and the pay’s not even that great. If you like games, then play them; don’t throw away your youth making the game companies rich.
Junior Recruiter – Despite the negative feelings I may sometimes have for hungry junior recruiters, I fully understand it’s really a high-pressure sales position. Usually it’s sink or swim in the first 90 days. Their choices are to cold-call prospects who hang up on them or else get yelled at by the managing partner who sees them as dead weight.
Subscribe to:
Posts (Atom)
