Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Stop That! Questioning Dogmatic Programming

Stop That! Questioning Dogmatic Programming



Doug Hiebert questions conventional wisdom that is taken for granted when writing code, and presents alternatives by way of before-and-after examples.


Doug Hiebert is a software developer at Protegra, with over five years of software development experience. His passion for deeply learning technologies both new and old has often landed him in a mentorship role with those around him. His programming interests outside of his day job as a Java developer are playing around with Ruby and Scala frameworks and exploring aspects of functional programming

About the conference

SDEC is an annual conference hosted by Protegra where industry professionals share their own real-world experiences gained through delivering solutions.

Recorded at:

Apr 26, 2014

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Disagree on Commenting

    by Roger Fischer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Obvious comments are not useful. But there are many cases where the why is important and an abstraction of the how is helpful. Don't document the obvious, but help the future reader understand without having to read every line of code.

    Also conditionals may be ugly, but they are easier to understand than polymorphism.


  • Re: Disagree on Commenting

    by Frank Lloyd Teh,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with you Roger.

    When using third party libraries, I believe it is faster to browse through Java Doc than to read the code. So developers in Apache, Spring and other open source communities have my sincere thanks.

    I like preventing NPEs by returning an empty Collection, if returning that does not have a logical difference with returning null. But seriously? polymorphism and Options over the simplicity of null checks? Didn't this speaker say we should prefer simplicity at the very beginning of this presentation?

    If I have several layers of nested properties, each of which can be null and I'd just do one thing if any of those were null, I'll just wrap it in a try catch block.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p