1. Yes, software development is about managing state change. If the state has not change, the software is idle or not running
2. The mix of concepts between programming paradigms, architectural design, etc. doesn't body well supporting the conclusion about "every programming philosophy"
Consider that maybe he had some form of Asperger's.
The lack of ability to prioritize is because every single detail is consider important. Which is why he gain the reputation of writing perfect programs.
Choosing your battles is good in the interpersonal relationships; but Mother nature does not choose battles when enforcing its laws, it doesn't say "well... right now we should suspend gravity because there are bigger fish to fry".
From that perspective there are not major or minor points, there are only points. So, what might seem petulant for neurotypical people, for Asperger's people is much more black and white; which is a blessing and a curse. but you will thank me later.
Or obsessive-compusive personality disorder, which is what I have.
I tend to either care entirely about something or not at all, and the only standard is "perfect" (there are no visible ways something can be improved) – "good enough" doesn't really make sense emotionally. And even though I'm completely self-aware and I recognize this as it's happening, it's difficult to control what I feel.
It's very frustrating. I sometimes wonder at how much more I'd enjoy things and how much more progress I'd make at work and with my hobbies if there weren't these... unbidden demands that take time to satisfy, the stress that the demands cause, and the constant internal battle between what I want to do or know I ought to do and the arbitrary need for something to be a certain way.
> Consider that maybe he had some form of Asperger's.
Far be it from me to armchair diagnose someone, but the "Strachey had always displayed a talent for the sciences but rarely applied himself" is a story told over and over again for those with undiagnosed neurodivergence.
It's weird that this is a point to make in any form when it comes to C, which, as a language, is certainly very aloof and non-judgemental over what you want to do. (IE undefine behavior, non safety, nul terminated strings)
My experience, personal and observed, of 30+ years as software engineer:
- don't directly address the point of your question / provide a much complex answer (or even worse, a non-answer) to a simple question
Simple or easy? For once, a lot of time the question oversimplified the problem that is been asked about, and reality is very nuanced. The fact that the person asking assumes that the question is simple and, on top of that, gets frustrated when it is not leads me to believe that doesn't know what is asking or that does not have the emotional maturity to manage his/her feeling. As the person provided the answer, my obligation is to give all the information necessary to understand the answer. This means removing assumptions; specially the assumptions that make believe that the question is easy. If you don't want to hear it, that is on you, not the person answering. What I don't want is later on to get "I asked you and you told me X", without me been able to say "true, within the context I explained, and the context changed"
- don't stay focused to the point of the discussion
Deflection is a good technique that a lot of people uses when trying to tell bad news to power. Other times, maybe what you are asking has origins on other places that you think are unrelated, put attention. In short, if you want to get shot accurate answers, then foster an environment around you where people feels that they can trust you with bad news, and that you are knowledgeable enough to know that what you don't know might be important. Fostering such environment is up to you, and ranting on HN is not going to help you
- don't have some level of clarity in their train of thought and speech
Or maybe it takes time to formulate an answer that can cross the listener's emotional state and reach with the piece of knowledge that is been asked for. When I see that, I need to consider if I stablish a relationship were people is confident that telling things by their name will not result in retaliation, including but not limiting to your personal frustrations.
- generally over-complicate matters by wandering off to other related subjects and extending the scope of the discussion
Ufff... 2 red flags here: "Over-complicate matters" and "other RELATED subjects". Yeah... if people feels that need to walk around you in tiptoes, and measuring what they can or cannot say to you, or how to say it, then that is you not creating trusting relationships, and venting your frustration in HN is not going to fix it.
Work at gaining people trust and feeling safe around you, then you can remove your potential lack of soft skills out of the equation, and will allow you to discover what people need to communicate more clearly with you
"can't bare the devs that go out of their way to work weekends without being asked"
But that is a problem for those devs, not you. As long as you are producing high quality results on time, shame on them. Why "you" can't bare it?
"I can't bare the endless meetings"
The meeting might feels endless because it is not where you want to be. That sounds more like you expected that the life of professional development should be only what you like to do, I assume coding, and it didn't turn out that way. Maybe you should adjust your expectations to reality and get the most out of those meetings?
"constant micromanagement"
I have deal with this in the past:
a) Over report. Micromanaging is consequence (in very general terms) of insecurities in managers. Over report, be constantly in their faces telling every detail of what you are doing, until they are tired of you and they know you can take care of things
b) Find another company... there is a shortage of developers anyway
Bottom line: You cannot change them, but you can change how you approach them.
"bringing the stress home to my family"
Your family is not at fault of what is going on at work. My experience is that there has to be some level of compartmentalization. You need to learn to flush out your frustrations before arriving home.
I understand that you don't like the industry, but the question is what are you going to do about it? How are you going to process your feelings? How can you take advantage of where you are? In other words, can you develop your soft-skills?
<sarcasm>
I like your suggestions... I would add that they are more effective if you keep a background noise with whips cracking sounds and random screams
</sarcasm>
Asking "what fundamental knowledge" is like asking what telescope makes the best astronomers.
The problem with knowledge is applicability. You can know a lot of fundamental things, but if you cannot recognize the patterns were they are useful is dead knowledge.
My personal experience through my life (30+ years in the field) and observing and interviewing developers in many different industries tells me that curiosity, logical thinking, and emotional intelligence win the day. And these are not pieces of knowledge, but personal characteristics and skills to develop. And they apply to many careers, including software engineering.
I think that more important than knowledge accumulated is your ability to conceptualize and recognize the concepts in a different context. Knowledge is just a side effect of this.
Seems like you vote for vector space embedding :) I’ve seen interesting paper about finding unknown embeddings and I think it’s important skill that AI also will poses.
this is an unhelpful response: the guy asks a straight question and the response is to "challenge the underlaying [sic] idea" It would be better to answer their question, rather than attempt to knock it down. (good example of zero-sum bias.)
It is actually pretty astute and on the topic to me. Skimming through here, a lot of people mention the fact that as they grow into their careers, one of the biggest gains is judgement about what sorts of problems even should be solved.
Or like. If someone came in asking "I'd like to make my car go faster, should I paint it green, or blue?" it's not unhelpful to point out that that's a solution to a different problem.
Plus anyway the audience is greater than just the person who initially posed the question. Conversations around this and other similar answers are vibrant today, so clearly they're helpful to someone.
I have deep technical knowledge on some subjects, but how I got there is through curiosity and reasoning, like the parent commenter said.
There is knowledge you can acquire, and then there are skills that can allow you to acquire the right knowledge at the right time. For example, having a baseline understanding of logic and mathematical reasoning could help you to understand when a problem area might already be formalised, and to find that area and understand the work therein.
"Likewise, if two mouse embryos are mushed together like a snowball, a single, normal mouse results"
And
"This is intelligence in action: the ability to reach a particular goal or solve a problem by undertaking new steps in the face of changing circumstances"
I write software that can account for changes in context and still reach a particular goal. This is not new, creating TCP from UDP where the network can constantly be changing is not something that I will call "Intelligent". The guy(s) that created the original algorithm are, but the network packets themselves are not.
There are differences between intelligence and just following well crafted procedures.
That is (very limited) intelligence imo. It's nothing more than a very complex, ever increasing set of procedures plus a huge amount of data and a fast processor.
I mean, the more you know about something, the less "magic" it seems. You know algorithms, the author may not. Pretty sure someone from the 1700's would think a smartphone with some personal assistant software on it was intelligent (even if possessed), for example.
2. The mix of concepts between programming paradigms, architectural design, etc. doesn't body well supporting the conclusion about "every programming philosophy"
It feels to me like much ADO about nothing