I cringe when I read that a "software professional" MUST know ALL of this:
You ought to be able to describe ALL 24 PATTERNS in the Gang of Four book
You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design
You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables
You gotta be kidding me ... I think a software engineer (let's just replace that with "developer") should know how to produce good software, and how to work in a team (i.e. be a team player) ...
If an employer is crazy enough to demand that I have knowledge of this complete laundry list of "essential" tools, techniques and methodologies, then I don't know how fast to run for the door.
Just being broadly familiar with 3 or 4 patterns from GoF, yes I can see value in that. Knowing the principles of Agile or Scrum, sure. Having seen a couple of UML diagrams, yes it's valuable ...
But knowing ALL of the above? That's completely insane. A developer should spend his/her time building things, instead of learning all of this theory, a large part of which is already outdated, questionable, or even harmful. Fill your head with practical skills and knowledge, not with this much academic theory.
First of all, thank you for leaving a comment. It is very important to me as a writer.
Commenting on what you said, I have to clarify that if you are only focusing your career on build things, just using the theory created by others in the past, you are being only a consumer, just a pair of hands, not a creator. You are just paying to put the pieces together in order to solve a puzzle.
How can we build new things without knowing the previous theory? How can we criticize theories that we didn't understand? It's simply impossible to create something without previous knowledge, isn't it?
I agree with you that some theory is outdated, but we are not going to have a clear understanding of our world without previous ancient knowledge.
In this book, Uncle Bob suggests we pursue the domination of our field, knowing as much as we can about our field in order to raise our hand when an unknowing problem rises. It will differentiate you from your team.
Another good excerpt from this book: "Your career is your responsibility. It is not your employer's responsibility to make sure you are marketable. It is not your employer's responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility." ~ Uncle Bob
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.
I cringe when I read that a "software professional" MUST know ALL of this:
You gotta be kidding me ... I think a software engineer (let's just replace that with "developer") should know how to produce good software, and how to work in a team (i.e. be a team player) ...
If an employer is crazy enough to demand that I have knowledge of this complete laundry list of "essential" tools, techniques and methodologies, then I don't know how fast to run for the door.
Just being broadly familiar with 3 or 4 patterns from GoF, yes I can see value in that. Knowing the principles of Agile or Scrum, sure. Having seen a couple of UML diagrams, yes it's valuable ...
But knowing ALL of the above? That's completely insane. A developer should spend his/her time building things, instead of learning all of this theory, a large part of which is already outdated, questionable, or even harmful. Fill your head with practical skills and knowledge, not with this much academic theory.
First of all, thank you for leaving a comment. It is very important to me as a writer.
Commenting on what you said, I have to clarify that if you are only focusing your career on build things, just using the theory created by others in the past, you are being only a consumer, just a pair of hands, not a creator. You are just paying to put the pieces together in order to solve a puzzle.
How can we build new things without knowing the previous theory? How can we criticize theories that we didn't understand? It's simply impossible to create something without previous knowledge, isn't it?
I agree with you that some theory is outdated, but we are not going to have a clear understanding of our world without previous ancient knowledge.
In this book, Uncle Bob suggests we pursue the domination of our field, knowing as much as we can about our field in order to raise our hand when an unknowing problem rises. It will differentiate you from your team.
Another good excerpt from this book: "Your career is your responsibility. It is not your employer's responsibility to make sure you are marketable. It is not your employer's responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility." ~ Uncle Bob
Wish you all the best, Leo. Thanks again.
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 :-)