Right ... just to be clear, I wasn't meaning to be disrespectful, but in my honest opinion when your blog post is titled "MINIMAL list of the things EVERY software professional should know", followed by a huge laundry list of topics, then to me it does not really come across as practical or realistic - that's what triggered my comments.
So, personally I don't think that "every" software professional should "minimally" know all these things. I think that most software professionals are craftsmen who know how to build good systems, and who need to make a living and have bills to pay at the end of the month.
I don't think that for those professionals it's a productive use of their time, or it's going to improve their skills or their career, if they study ALL of this theory - being aware of these topics and having studied a couple of them in detail would be more than adequate.
"It will differentiate you from your team": there's exactly where the risk is - the most valuable employees are the ones that are good team players, not the prima donnas who've read too many theory books and think they know it all.
Thank you again for your reply! ;) The fact that you are the bookman inside a team is not to become the prima donna of it, but to be challenged to think outside the box and suggest new approaches to unknowing problems.
Humility is a good trait of a good character and a good professional.
Because of that, I am not allowed to criticize Robert Cecil Martin, who originally wrote this piece of text.
I have just shared what I have read in his very acclaimed book, but if you feel comfortable criticizing his ideas and his work, no problem at all.
Maybe, and just maybe, you fall into the self-made man's trap as I felt in the past.
I'm not really afraid to fall into that trap - actually I've studied most of the topics in this list, and having done that I often wondered "was the time spent studying this really productive or useful"? And in many cases I concluded "no not really" ... theories come and go, and a lot of stuff that's touted as 'important' is rarely even used in practice.
My main point is the assertion that "every" software professional SHOULD "minimally" know all of this - I think there's no basis for that ... for someone who's in a certain specific situation and in a certain role it might be beneficial, but for the other 95% of us it probably isn't. The necessity to have knowledge of certain topics (or not) is highly personal, there is no "one size fits all".
So the problem (if it really is a problem) is that the title of your post is a bit misleading - if you change it to "List of topics that a software professional might want to study" then I'm all for it.
P.S. by the way, Uncle Bob is one of the greats and it's absolutely not a waste of time to read one of his books and to know about his ideas ... but the list of things you "should" know is fluid and not constant or a given. For instance in bullet point 4 I'm missing Functional Programming ... and we can probably remove Structural Programming from that list, COBOL or punch cards aren't really that mainstream anymore :-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Right ... just to be clear, I wasn't meaning to be disrespectful, but in my honest opinion when your blog post is titled "MINIMAL list of the things EVERY software professional should know", followed by a huge laundry list of topics, then to me it does not really come across as practical or realistic - that's what triggered my comments.
So, personally I don't think that "every" software professional should "minimally" know all these things. I think that most software professionals are craftsmen who know how to build good systems, and who need to make a living and have bills to pay at the end of the month.
I don't think that for those professionals it's a productive use of their time, or it's going to improve their skills or their career, if they study ALL of this theory - being aware of these topics and having studied a couple of them in detail would be more than adequate.
"It will differentiate you from your team": there's exactly where the risk is - the most valuable employees are the ones that are good team players, not the prima donnas who've read too many theory books and think they know it all.
Thank you again for your reply! ;) The fact that you are the bookman inside a team is not to become the prima donna of it, but to be challenged to think outside the box and suggest new approaches to unknowing problems.
Humility is a good trait of a good character and a good professional.
Because of that, I am not allowed to criticize Robert Cecil Martin, who originally wrote this piece of text.
I have just shared what I have read in his very acclaimed book, but if you feel comfortable criticizing his ideas and his work, no problem at all.
Maybe, and just maybe, you fall into the self-made man's trap as I felt in the past.
I'm not really afraid to fall into that trap - actually I've studied most of the topics in this list, and having done that I often wondered "was the time spent studying this really productive or useful"? And in many cases I concluded "no not really" ... theories come and go, and a lot of stuff that's touted as 'important' is rarely even used in practice.
My main point is the assertion that "every" software professional SHOULD "minimally" know all of this - I think there's no basis for that ... for someone who's in a certain specific situation and in a certain role it might be beneficial, but for the other 95% of us it probably isn't. The necessity to have knowledge of certain topics (or not) is highly personal, there is no "one size fits all".
So the problem (if it really is a problem) is that the title of your post is a bit misleading - if you change it to "List of topics that a software professional might want to study" then I'm all for it.
P.S. by the way, Uncle Bob is one of the greats and it's absolutely not a waste of time to read one of his books and to know about his ideas ... but the list of things you "should" know is fluid and not constant or a given. For instance in bullet point 4 I'm missing Functional Programming ... and we can probably remove Structural Programming from that list, COBOL or punch cards aren't really that mainstream anymore :-)