← Back to context

Comment by whateveracct

5 years ago

This sentiment is exactly why programming in an org-chart is so much different than programming as an individual.

Don't apply corporate best practice designed to withstand turnover to personal programming - you're leaving abstraction and efficiency on the table.

The better code for your own projects is almost definitely inscrutable to a newcomer a lot of the time. It's okay for there to be prerequisites to understanding.

I agree with this in principle but in practice code I write that’s quick & easy and not very readable is usually not understandable by me in a few months either. So if it’s a personal project I hope to last I still want to keep it simple with my code.

  • I'm not saying to hack away and make a mess necessarily.

    Sometimes the simplest solution also requires learning and building upon other concepts. Or sometimes, a simple interface is written around a complicated core.

    For example: The OP's quote is used time and time again to argue against FP concepts in industry - a newcomer doesn't know the first principles, so by the OP's folksy razor[1], that code isn't as good as less abstract code that doesn't require learning a new concept or two once and for all.

    [1] Folksy razors are the essence of every principle-ish-level engineer's methodology I've run into. Corporations value the ability to remove all human agency & decision-making from software development where possible.

    • > Corporations value the ability to remove all human agency & decision-making from software development where possible.

      Corporations value the ability to continue as an operating entity and make changes to the code after the proponent of Kleisli arrows and lenses has departed for greener pastures.

      1 reply →

I’m not sure, you can become the newcomer yourself when you have to come back to parts of your code base months later. My experience writing simpler code has been pretty successful to respond to customers wanting random new features.

  • That's true, but it's not true in situations where you build on more abstract concepts that a newcomer wouldn't be able to understand.

    e.g. I'll understand my monad transformers in a year, but a new hire with no Haskell experience will not.