Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
devRant once interviewed the author Andy Hunt once. 🙂
https://devrant.com/podcasts/... -
@QuanticoCEO Would you recommend this for someone with 10+ years software development? Or is it more for early-career developers?
-
@ScriptCoded still wondering what the whole fuss about them keyboards are :P at work we got a storage room full of them, old IBM model Ms and the like
-
@BobbyTables I would definitely recommend it for both 10 year experience could always learn more, it could be good to get a new prospective or who knows a thr after 10 years the person has figured this out the ideas in the book on their own and already understand the significance of them.
As for the novice sure they can read it too, but it won’t benefit them because they will just be doing something because a book told them.. they don’t have experience to reflect on the presented concepts from the book.
Probably best fit for someone after a few legit projects under their belt, that’s probably the best bet. -
@AleCx04 please send some my way if you find any from 86.. 85 or anything of the industrial version... noted by the gray case, and the black ibm sticker..
-
@ScriptCoded @QuanticoCEO not mine to give away sadly :( still don't get the fuzz tho
-
Bubbles66124yThis is one of those I keep looking at when I go to Barnes & Noble but never can get myself to get it
-
@Bubbles honestly, most of these books can ve summarized to "use common sense and bwst practices"
don't take my word for it tho and give em a shot at it yourself -
@AleCx04 the issue is common sense isn’t common across everyone in this field. The idea of it compiles and functions your done ship... ignore performance ignore warnings ignore standards.. size.. naming conventions etc.. testing... to someone with 10 years of experience this may seem like common sense... but I also know programmers with 10 years of “experience” and they have no common sense and write literally the absolute worst code I’ve ever seen and they solve problems and approach things from left field and rudimentary level ... AND to them they literally think “we” are wrong and the rest of the world is doing it wrong or says million ways to solve a problem I choose this way end of story.... great team member eh?
-
@QuanticoCEO that itself is very true. I wonder what pain took the author into writing this now when i put it on that perspective
-
@AleCx04
That term, "best practices" it triggers me. Not everything, but this encapsulates most of it
http://blogs.tedneward.com/post/... -
@SortOfTested I don’t believe there are “best practices” that solve all problems but I do believe there are certain thought processes and design philosophies that are crucial and without them one creates shit... that can cause major problems later... for example... arrow head programming nesting a lot of if statements I won’t put a number on what’s acceptable and what is not because I don’t want to draw a line... I believe nested ifs can signal a sign to the designer hmmmm must be a better way that exists...... complexity score of a function is important... not only for testing but also for understanding and scaleability later
I would say proper naming conventions and descriptive variables and functions are a “best practice”... creating variables and functions with meaningless names is just shit.
So ideas of best practices exist.. sure maybe the term isn’t great but that’s just semantics... the idea is there are things you should and shouldn’t do. -
@QuanticoCEO
Dunno, Hungarian notation was considered proper naming for half my career, it served a purpose before namespaces and IDEs. People i = i +1 even when their compiler is noted for handling things. They never update samples until it becomes critical. There's .Net developers walking around spouting best practices like "switch expressions aren't readable" because they overloaded the switch operator. They don't bother to contextualize that the overload handles covariant type discrimination, and expression vs statements behaved differently in terms of their path execution.
Maybe I'm just different, but I never accept things without knowing why (context). Best practices rarely come with a reasonable explanation, usually just some hand wavey mysticism and pseudo-philosophy (see: Bob).
So, maybe it's just I treat best practices the way I treat anything: if you don't bring data and I can't reproduce the experiment, I'm not buying it. Doing so to me is just a lack of discipline.
To me "best practice" as an industry trend has become a way to appear competent while lacking understanding. Just seek understanding. -
@SortOfTested what would you call arrowhead programming, say 15 nested if statements
Or irrelevant naming of functions and variables -
@QuanticoCEO
Nested iftastrophe: Code smells.
I write mostly FP, so my branches tend to be absolute on the function boundary by default. -
@ashleymoss124
Yes, the book deserves attention, but I also read essays on philosophy in parallel to the books. It helps me to learn more in a short period of time. I often read essays on philosophical works, use https://gradesfixer.com/free-essay-... for this. To be honest, I enjoy reading short articles rather than whole books. It's much more interesting this way.
Related Rants
-
QuanticoCEO32From the guy who wrote all the Programming Microsoft books and the Annotated Turing book. Comes this book. Th...
-
QuanticoCEO7Working in the embedded systems industry for most of my life, I can tell you methodical testing by the softwar...
-
QuanticoCEO35Forgot to post a book yesterday, so maybe I’ll post two books today... Anyway, this book, I found it recen...
I really like this book on the basis of the philosophy overall, no this doesn’t solve all problems but it’s a good baseline of “guidelines/rules” to program by. Good metrics or goals to architect and design software projects high and low level projects.
Fight Software Rot
Avoid duplicate code
Write Flexible, dynamic, adaptable code
Not cargo cult programming and programming by coincidence.
Make robust code, contracts/asserts/exceptions
Test, Test, and TEST again and Continue testing.. this is a big one.. not so much meaning TDD.. but just testing in general never stop trying to break your software.. FIND the bugs.. you should want to find your bugs. Even after releasing code the field continue testing.
rant
bookaday