What don't people tell you about programming, my response

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. Newbies who only know one language tend to be “fanboys” of that language. For instance, graduates from school only exposed to, say, Python, treat it like a religion and get their egos bruised easily when you tell them that not only Python is slow, there are far better languages they could be using.

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)

Don’t even think of calling yourself a “senior developer” unless you have at least 5 programming languages under your belt, and at least 5 years of real-world experience.

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.

Many today don’t seem to think you need to know the ins and outs of computer hardware and how your toolchains work “under the hood”. While this is mostly true, it is not a good idea to avoid this deep level of knowledge in the long run.

3. It is insane to me, how many “developers” think that hardware is irrelevant, or unnecessary to understand. Maybe this is why Electron is so popular. I see developers not understanding why their Electron Apps are sucking up 300+ MB of RAM, and running slower than a sloth. To any who wish to become better aware, I encourage finding the Handmade Network. (A group of developers concerned with creating software which is deterministic ‘you should know how it will act or perform’ because you didn’t include 2 million lines of javascript from npm, to say helloworld)

4. I have no real comments on this....

Learn you a functional programming language for great good. Haskell is the granddaddy of functional languages, but there is OCaml, Elixir, Erlang, Clojure, and others. You should have at least one under your belt.

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.***

Life does not end for the developer at 40. Far from it. I’m in my late 50s and am still doing software development. Many are even older.

6. I Absolutely love this point. I don’t plan to stop developing software (for fun or otherwise) until I stop breathing.

Beware of micromanagers wearing Scrum/Agile clothes. If you run into this situation, consider your exit options.

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.

Always seek to learn new languages, techniques, frameworks, approaches, and the like. Perhaps you can apply Haskell, for example, instead of Rust for a crypto application. Rust forces you to spend too much time thinking about memory ownership issues rather than solving problems. Haskell, on the other hand, allows you to think about the problem mathematically., and less about what thread owns what object. Just an example of how paradigms can shift your focus in a good way.

8. I agree on the premise, but if security is key, then memory ownership is critical.

When you ascend, later in your career, into the lofty domains of management, never lose touch with the code. Those who write software are actually more valuable than those who manage them. Always be aware of that.

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 --

Guys my age simply think differently than the younger crowd. We are seasoned and have tons more experience. If you throw a leet-style coding challenge our way, we are most likely not going to like it, and may not even pass it — not because we are unable, but typically the short times given to solve those challenges does not allow us to think and reflect about our solutions over a coup of coffee, but expects us to grind out code by the seat of our pants.

We are used to solving real-world problems, not whizz-kid ones. If a major problem arises, we are the ones that will sit down and solve it, not run home crying to mama. We will save your bacon where the neophyte would be completely lost, even if he did all the leet code challenges in record time.

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