In this response to What don't people tell you about programming?, I wanted to outline a few things that many might not know. But also, areas where I think I am in the minority of critical objections. You can read the original post for yourself at the above link. I have only brought in part of the text, and the statements that I am commentating on.
Agree, but not exactly
In general, I agree with you, however, on a few points, I think that are ill conceived or conveyed.
1. Spot on (I do happen to know several Ruby developers, whom treat it as a sacred religion, and any criticism is blasphemy of sorts)
2. I think Time as a metric, for seniority is a poor choice. I have been writing software (both system applications and web) for a long while, starting with QBASIC 4.5 and TurboPascal, then Delphi and VB6, on to .Net, PHP, C, C++, Assember(s)* and so on. I was stuck in Delphi and VB6 for a good long while, and Until recently, I would have considered myself a Senior Developer but I was full of garbage, I didn’t understand the hardware that I was writing applications for, maybe I was good at solving business needs, but certainly not a Senior Developer. Maybe now I qualify, but I am not so sure of that.
4. I have no real comments on this....
5. Haskell is a relatively modern Functional Programming language (first introduced 1990). Erlang predates it, being introduced in 1986. And the real grandfather of functional is Lisp being introduced in 1958. — Better than learning a Functional Language, ***I would recommend, everyone to implement an Interpreter or Compiler for a functional language.***
6. I Absolutely love this point. I don’t plan to stop developing software (for fun or otherwise) until I stop breathing.
7. I have had my share of run-ins with these. They suck, but, if you can handle it, some of them pay. And it is a good point of reference, for when you do have a nice cushy gig. You can know it is good, having experienced the grass on the other side.
8. I agree on the premise, but if security is key, then memory ownership is critical.
9. First, not all promotions end in management. Become a Systems Architect for a company is usually the same level as a Personnel Manager, but responsible for the direction and implementation of the Systems. Just as a Personnel manager manages people, so do Architects their Systems. Management of people, is a skill completely disconnected from Development of any kind. And honestly, having been there, is a complete Sh*t show. Non contributing managers, have to prove their worth to the company, and they do so, by trying to make you work harder, more hours, less meaningful raises or pay, or some other attribute that correlates to some metric that they can somehow quantify to the company. (This is where I believe Micromanagers are born, and under the guise of Scrum/Agile/etc.) -- Optional Reading, this is way off topic: I am inching closer to hiring for my company, and I am trying to find a good balance of freedom, accountability, and productivity. I don't think it has to be field of study, such as the HR Professionals do, but I don't think, it should be left to chance either. Probably finding the right fit will solve this problem. Sorry this is way off topic here --
10. I more or less agree with the. Experience is not about the length of time you have programmed, but the quantity of solutions which you have been involved in, and can summon in your head in times which you need a point of reference or some ideas about how to solve a problem at hand. Summoning many different memories, might take a long time. But you will most likely settle on a solution that is far more stable, maintainable and likely simpler than a fresh developer out of college (even if the college kid can pound out these coding tests. They likely had years of practice working with these tests)
At any rate. I hope this response is taken well, I don't mean to ruffle any feathers. I have a different perspective in Business and Systems than most. If anyone is offended by any statements I have made, it was not my intention, so try to not be so sensitive. Or, just don't read anything on my blog, I write these for myself, not for you.
*By Assembler(s) I mean assembly language for different chipsets and syntax; all depending on the “Platform” for which I am writing. Don’t be nit-picky You Know What I Mean — Me