21–30 of 116 posts
Agree that the repository/service pattern is a good way to adhere to separation of concerns and make refactoring and readability easier. That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a fr…
One of the great things about working from home is that I often don't do anything. As in, I'm not even by my computer. I'm still thinking about what to do, but I'm not implementing anything. I'm not typing stuff, I'm not waiting for a compile, I'm not outwardly moving the project forward. But the project is moving forward. Inside, I am considering the tradeoffs. I'm thinking about what the business needs, and what th…
It's kind of maddening, after having the space to Just Think during the WFH days, to be back in the office and any time you stop typing for more than 30 seconds risk being interrupted by co-workers who think you're Not Busy.
I didn't face a ton of unscheduled conflict for my time, and there were many rooms available at that job. But the change in perspective was amazing, just so much power to help me really consider things in new light.
It's funny because I grew up with Steve Roberts as my role model of role models, as the guy who showed me that being an adult could be fun & interesting, with his work-from-bike Winnebiko. And I was a seasoned coffee shop coder, which I found amazing with its change of scene & deliberateness. But seeing Adam have such a practice of getting up, grabbing a notebook (also a seasoned writing-things-down person; another key element of Hammock Driven Design), and going for a stroll (DC's Rock Creek Park was a bit over half a mile away) was amazing, really opened me up.
As other comments mention, Rich Hickey's Hammock Driven Design is excellent, amazing. Some deliberateness about figuring out what we are doing, letting the waking mind come up with problems and possibilities, and giving time and written down ideas for the passive/sleeping mind to cycle through options & combine them... Kind of like protein synthesis, a soup of amino acids/ideas and your mind as rna, blindly bumping elements together to see if they bond. https://youtu.be/f84n5oFoZBc
With experience, you learn to find balance between pragmatism and purity more often than not. You will still not always be right.
It is all still a mix of skill, experience, team and external factors.
So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach. But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more r…
I used to think that, until I worked on my first large scale system, infra heavy. It turns out it works both ways.
If changing infra is hard, slow, painful and risky, people will be less inclined to do so. If changing infra is fast, easy, and with low risk, people will be much more inclined to change things.
Even if you had very stable requirements (doubtful in this day and age), I see no reason why you wouldn't build your system in a way that is easy and safe to change, for the day when it's needed.
Agree that the repository/service pattern is a good way to adhere to separation of concerns and make refactoring and readability easier. That said, I really disagree with any precommit checks. Committing code should be thought of as just saving the code, checks should be run before merging code not saving code. It'd be like Clippy preventing you from saving a Word document because you have a spelling error. It's a fr…
But if need be, I will spam my commits locally with `—no-verify`. Once the code is ready, I reset to head and remake them as nice, conventional commits.
One of the great things about working from home is that I often don't do anything. As in, I'm not even by my computer. I'm still thinking about what to do, but I'm not implementing anything. I'm not typing stuff, I'm not waiting for a compile, I'm not outwardly moving the project forward. But the project is moving forward. Inside, I am considering the tradeoffs. I'm thinking about what the business needs, and what th…
>I'm still thinking about what to do, but I'm not implementing anything. I'm not typing stuff, I'm not waiting for a compile, I'm not outwardly moving the project forward.
This is literally the nightmare scenario of middle managers and c-suite managers about wfh employees. You walking around visibly doing nothing and them paying you to do it! Somehow when you do the same thing near your cubicle or in your office you "look like" you're working so that is much better!
So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach. But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more r…
> even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements I used to think that, until I worked on my first large scale system, infra heavy. It turns out it works both ways. If changing infra is hard, slow, painful and risky, people will be less inclined to do so. If changing infra is fast, easy, and with low risk, people will…
Both things are true: you should move slower and more thoughtfully on infrastructure projects, and "ship often" is still valuable advice and a worthwhile goal
So much of our “ship fast” culture is based around end-user application development, where it’s a reasonable and defensible approach. But the further away you go from end users toward libraries, then internal services, then even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements, and getting it right pays dividends. Or more r…
> even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements I used to think that, until I worked on my first large scale system, infra heavy. It turns out it works both ways. If changing infra is hard, slow, painful and risky, people will be less inclined to do so. If changing infra is fast, easy, and with low risk, people will…