joshhogg

It can help to set more strict 'triggers' for yourself.

ie: - When it is 12, I will take a break for lunch. - At 3 o'clock, I will take a break for a snack and stretch

I get what you are saying, in that once you are in a flow, you don't want to stop. But, you need to be strict about it, like the user you are replying to is saying. Don't let yourself off the hook.

Also, it helps me to realize there is value in stopping and stepping away from something. It helps me recharge, and step away from any problems I am trying to solve.

Are you using the leadsheets to improvise accompaniments on each pass or, just enjoy the melodies as written?

Can you clarify bat wings? Are they sinilar to YTWLs? When I google, all I find are Moms trying to get Michele Obama arms.

This books looks super interesting. Did you find any of it applicable to particular problems you are working on or was it good general knowledge?

Thank you so much for getting back to me. Awesome reply.

I agree on the pragmatic vs dogmatic approach to "Don't repeat yourself". I have been playing a lot with this at my company right now. It's hard not to reach for an abstraction right away, but if the abstraction muddles the code / implementation, I find myself questioning its value.

I also love your comment "Code should make intuitive sense like a great UI makes intuitive sense". This forces the engineer to avoid being too fancy, and allows future devs to work on it without needing the original (who might be on vacation or moved on).

Kahneman's work is awesome, and I'd never really thought of it in the context of coding. We have been struggling at work with our redux lately, because the developers haven't stopped to question why we were structuring things in a certain way, or how we were dispatching actions and handling async flow. We just kept building things and trying to move quickly. It can be tough when product is asking for things to get released, and you are trying not to bikeshed / overcomplicate things. But a healthy dose of stepping back and rethinking why you are doing things is helpful.

Any particular approaches / design philosophies you found useful, either to discard or embrace? ie: Testing, "SOLID" principles, etc.