On Saturday, October 6, 2012 6:03:17 PM UTC-4, Rod Pemberton wrote:
> > If you're hired as a programmer, you will indeed spend
> > nearly 100% of your time writing code.
>
> That's completely untrue.
Most reasonable people don't count the time in necessary (or unnecessary) administrative or random ancillary work. Such work is a given of pretty much every job of any real responsibility. If you're going to play your usual games and count /all/ time, then you'll next probably try to count bathroom breaks, water-cooler discussions, time to find a parking spot, time for lunch, time for recovering from the food coma after lunch, etc.
You have a talent for taking what people write, ignoring the reasonable interpretation, and going straight for the most ridiculous interpretation possible. Are you this amazingly tedious in real life? If someone tells you, "I spent all day working on this problem" is your response, "that is clearly factually incorrect, the day is 24 hours long, and you slept during part of that." Duh.
> Many programmers want to just program. They don't want to
> handle the "BS" of non-programming business and corporate
> political issues. Why would they? [...]
I don't consider the various other aspects of software development I listed (and didn't list) to be "BS". Different companies have different amounts of "BS"; I've been lucky in that except for one company, my job has been largely "BS"-free. I'm sorry if the companies you've worked for had a Dilbert-like environment. That's not true of everyone.
What is being discussed here is that the common job title of "programmer" describes someone who spends most of their time (unsurprisingly) writing code. My point-- and one you don't seem to substantially disagree with-- is that software development is a (much) larger set of activities than just coding.
Hugh dismisses this. The only reasonable interpretation of what Hugh has written on the subject is that anything beyond the act of banging on the keyboard and looking at a flashing cursor is stupid and/or unnecessary work. And that might actually be true. If the programming work you've done is generating slide rules with your name on them for future post-apocalyptic generations to cherish, maybe spending time thinking about design and structure isn't necessary. Or say you want to inefficiently manage a symbol table based on a faulty and untested premise-- no need think about measuring your assumptions and proving your work has value over simpler solutions. But for the rest of us who aren't paid to slap out ad hoc solutions, things are a bit different.
Hugh's statements demonstrate that he is nothing more than the traditional definition of a programmer. And again, that's fine-- if that's what he likes and that's what he's good at, then all the more power to him. But just because he doesn't recognize the value of analysis, design, testing, maintenance, project management, and dozens of other related activities doesn't mean they don't have value.
Part of the problem here is that what experience Hugh has seems stuck somewhere in the 80's. Take for example the word "design". In the 80's, the majority of software developers followed some flavor of a waterfall methodology and "design" usually meant a discrete phase that occurred prior to any coding. Now, the only people following that kind of methodology are those who enjoy seeing projects fail (or those who must do so because of other external factors). In modern software development (pretty much everything since the mid 90's), the "design" phase is more typically incremental, spread out over the course of the project on smaller sections of the project. Any up-front design is usually limited to setting up the general architecture, patterns, and practices the rest of the development will follow. It's usually high-level stuff to keep a project on track, consistent, comprehensible, and maintainable.
Hugh doesn't understand this because he's stuck in time. When I say a word like "design" he's using a 80's sense of the word and thinks I'm talking about what the agilists call "Big Design Up Front." He's wrong of course, but he doesn't know that. Because he relishes in being just a programmer, he's not even aware that things have changed in the past 25ish years.
> > As a software engineer, [...]
>
> We've been over this before. There is no such thing
> as a software engineer.
Yep, there is. It's part of a series of job titles that broadly define the set of roles and responsibilities of various flavors of software developers. It certainly includes coding, but also includes all the other things I described that Hugh dismisses.
> You're misusing the term "engineer".
Nope. There is an *obvious* distinction between the job title and function of software engineer, and people who additionally have achieved academic certification and licensing with that title. If you don't like that such distinctions are made in the world, then you've got at least 30 years of historical precedent you'll have to change. Good luck with that.
My guess as to the origins of "software engineer" is that companies were searching for a term that meant "more than just a programmer". They noted the increased scope of roles and responsibilities engineers in other disciplines had and wanted to convey that in the job title. For example, most engineers in other disciplines are equally concerned with requirements, analysis, process, methodologies, measurement, maintenance, and so on. It isn't surprising that employers seeking candidates who saw value in these things would reuse the word "engineer" in the job title.
You of course are free to ignore this and claim that the job title of "software engineer" is invalid for one of your typically tedious reasons. But what you aren't free to ignore is that regardless of the job title, the role and responsibility of someone hired as a "software engineer" is typically larger than "programmer".
> Are you licensed by the state? Is your immediate
> manager? If you answered "No." to both, then
> you're not an engineer.
The answer for me and probably the vast majority of those who have been *given* that job title is no. Companies that are specifically looking for those that have certification as an engineer may certainly exist, but I haven't come across any in my past job searches. The advertisements for "software engineer" in the various sources (newspapers, job boards, Monster, Dice, etc.) make absolutely no requirement for certification. Take it up with them, not me if you disagree.
> That's called a "programmer analyst". It's when you are
> spending a larger percentage of your time doing analysis
> and design. If you're no longer programming at all, then
> you're a "systems analyst".
Yes, those are common terms I remember from the 80's. Maybe you and Hugh are stuck in the same time warp. Crawl out to the edge of your event horizon, you guys. 2012 is an amazing place. We don't have hover-cars yet, but otherwise, it's pretty cool.
If you want to use terms like "programmer analyst" to describe me and others like me, feel free. Our employers tend to use more modern terms that better reflect that we aren't just programmers, and aren't just analysts. Maybe terms like "programmer analyst" and "systems analyst" are still in common use in some industries, but I haven't seen that in embedded systems for years. Indeed, when we start talking about my actul job, it also includes quite a lot of stuff on the hardware side; I'm also responsible for designing and implementing digital logic in our systems.
So let me turn this around; what should my job title be in Rod's perfect and universe? I don't _just_ do programming, I don't _just_ do analysis, I don't _just_ do design, I don't _just_ do the other software activities I've listed (like managing projects and people). And on top of that, I don't _just_ do software. What ultra-precise Rod-world job title captures that? Please let me know because I need to order new business cards (there are a lot of fishbowls in local restaurants offering free lunches).
> You're belittling him because he worked for a very small company?
Certainly not! I'm belittling him because he's a twit. He appears to have worked for *one* small company in the distant past, had a very narrow role and probably minimal responsibility, and despite all this, he feels that he can expertly comment on this and related issues. If you don't see a problem with that, perhaps you need medical advice? I once did some contract work in a medical lab, so that should qualify me to dispense medical advice, right?
> Your resume seems to indicate you haven't worked for any
> large companies either. Most seem to have fewer than
> 65 employees.
Yep, and the engineering departments of those companies are even smaller; where I work now, we have just ten engineers. I'm a big fan of small companies. I like that small companies pretty much force people to wear multiple hats and that (in my experience) leads to companies where people are less parochial in their approach. In my case, it forced me to learn more about electronics and to take a wider interest into software process and methodology. The down side about working in a small company is that... you actually have to work. It's very difficult to get lost in the machine when you're the machine.
I spent a year as a sub-contractor at (then) corporate giant Kodak and hated every millisecond of it (well, except for the amazing cafeteria at their corporate headquarters). What I saw was a work environment where people became hyper-specialized into either a narrow subset of a discipline or some picayune aspect of a product. Having such depth is great... up to the point where because of your specialization you can't see beyond your own work. I was offered a job there and turned it down in a heartbeat. I would have made more money there, but while money is nice, it isn't what motivates me.
So no, I certainly don't criticize Hugh for working for a small company. I think it's great! It's the true engine of the economy! His sob story is that the company he worked for paid him badly and screwed him over. What most people do after such an experience is stand up, dust themselves off, and move on. Hugh didn't do that. I don't know why... and at this point, I don't really care.
> One can say the same thing about you. He could say you
> limited your career because you only have a two-year
> community college degree instead of a four-year
> university CS degree.
Hugh probably would say that-- he's partially attributed his own career failure to get a job in software development to the lack of a degree. But that's just an excuse. I bailed out of college for three reasons:
1) I was bored because of the pace and found I didn't get much out of it. I learn better by exploring, not by following a rigid curriculum. Different people learn differently.
2) I was making money as a TA and tutoring students taking 400-level courses at two of the four-year schools here.
3) I was given a job opportunity that paid very well, doing work that I enjoyed, and was in an industry that I loved (and still love).
You're right that not having a degree has limited my career. Specifically, I found it limited me from being hired by a tiny handful of larger companies that require such a degree. But since I had no real interest in working for those companies, it didn't matter. The companies I have chosen to work for never cared about degrees; they cared only if I could do the job and what ideas I could bring. And that's actually true for many companies. If you look at most job listings, many of them will list a B.A. or higher as a job requirement and then follow that "...or equivalent experience."
So no, I don't see how not having a degree has limited my career. I'm paid competitively, I'm doing the work I love, I'm working in an industry that I love, and I'm constantly learning and expanding my role, making myself more valuable. So where is the real limit here?
Related to this, back in the 90's, the company I worked for asked me to handle the technical interviews for new job candidates. There was one fellow who had the most amazing resume you've ever seen. When we saw it, we had to get him in for an interview, and I was shocked as during the interview (which included a simple skills assessment), he completely flubbed it. He knew lots of things, was bright, but had zero practical experience. That same interview process gave me a resume of a woman who had a doctorate degree-- in theology. We didn't expect much, but we brought her in, interviewed and tested her, and found she was amazing.
Anyone who believes that not having a degree limits you is wrong. Anyone who believes that having a degree means you can do the job is wrong. Any company that refuses to use actual skills and experience instead of academic credentials is not worth working for.
> Once you get that degree, he can ask you
> why you didn't get a more valuable, and
> in-depth, MBA degree.
Because getting a MBA has no relationship to the work I want to do. I guess it comes down to how one judges if one's career is a success. If one takes the traditional view that success is defined by climbing a corporate ladder, moving into a management role, and then spending your time waiting for retirement, then that's not a definition of success to me. That's fine for some people, but it's not what I want.
> You don't know that it's his attitude that affected
> his programming career.
Correct, but it's not hard to infer from his own words. Hugh has stated in the past that he doesn't work well in groups and sees no value in doing research. Now, if you were interviewing him for a typical position, would you find that a plus or a minus? Don't take my word for it-- you love endlessly scanning old newsgroup messages. Do that for Hugh, and compile in your own head if his attitude, skills, knowledge, and experience make him a prime candidate for anything but the lowest-level code monkey.
> It could easily be numerous unrelated life events.
Could be. Back when I first questioned the time and space efficiency of his "symtab" I remember a sob-story message he wrote about how (cue violins) that programming is the only thing that gives him joy and how he spent lots of time on it. He had other messages where he talked about how he was screwed by the company that hired him, couldn't find work after that, and so on. Gosh, I actually felt sad for the little feller. (Excuse me, I need a tissue.)
Then the little Ayn Rand in the back of my head kicks in and I don't care. Hugh offers endless excuses (he doesn't have a degree, he doesn't know anything about electronics, he can't get hired because he puts Forth on his resume, various bizarre conspiracy theory involving Elizabeth Rather, etc.). And on top of this steaming pile of nonsense, he has doubled-down on his goofy statements so many times that you need to take the base-2 logarithm to get a reasonable number.
> He could be required to live where he is to take care
> of his parents or family, or he could be injured and
> be living close to needed healthcare, or he could be
> unable to sell his house, or he could have court
> mandated locality requirements, or he might not have
> the correct degree or skills for the current market,
> or maybe his finances are so messed up that he can't
> get college loans, or maybe the environment where he
> programmed was so "toxic" he has mild "PTSD" and
> doesn't want to program for pay. You just don't know.
Don't let Occam's Razor accidentally cut you, Rod. Feel free to freely generate more speculation about what Hugh's problem is. When you're done, you might consider using Hugh's own words. That seems a more reliable indicator of reality than your ability to invent sad circumstance. Sometimes things *are* exactly as they appear.
Sorry, my inner Ayn is kicking in again: Boo fucking hoo. Hugh isn't the only person on the planet who has had to face challenges and overcome adversity. I believe that the character and worth of a person isn't defined by challenge and adversity, but by how they respond to it. Hugh responds with excuses and ignores the responses:
* Doesn't have a degree...
... but doesn't need one.
* Doesn't know about electronics...
... but doesn't get off his ass and learn.
* Can't find a job doing Forth...
... excuse, or are his skills really that specific?
* Doesn't know how to work with others...
... but refuses to believe he's not the center of the universe.
* Doesn't do research...
... which is part of the reason why symtab sucks.
That last one is probably the core of the problem. Part of the reason why people do research and study the work of others is that they want to learn. And with learning comes an implicit understanding of one's limitations. You get to see problems from new perspectives, appreciate clever solutions, and learn about problems you didn't even know existed.
Hugh doesn't know what he doesn't know. And when I and others point out what he doesn't know, his reaction isn't to go, "oh wow, I should look into that." His reaction is "you're all wrong."
The only sad thing here is that at this point, it may be too late for Hugh to turn things around. He's had nearly two decades of making excuses and he's aging at the same rate we all are. If he wanted to work for a large company, he's going to be competing against people who are younger, will work for less, and have been trained in current skills. He may have a shot at a smaller company that cares more about what he knows, but given his misanthropic attitude and lack of experience, why on earth would anyone hire him? Because he knows how to efficiently code an array defining word? Because if he runs into a complex problem that goes beyond his capabilities, he'll steadfastly ignore study and research and instead waste his employer's time with a journey of personal discovery?