DEV Community

Discussion on: Minimal list of the things every software professional should know

 
rezende79 profile image
Marcos Rezende

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.

Thread Thread
 
leob profile image
leob • Edited

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