Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
For me, one thing I believe but have no direct evidence for is that focusing too much on automated testing up front in the early stages of the product design and delivery lifecycle can have a net negative impact on both software quality and speed of delivery, because it takes you out of problem space exploration mode and into under-the-hood solution-refining mode.
Another belief I have is that developers who focus too much on language and framework-level best practices and patterns are often less skilled at (or at least less interested in) in focusing on what the actual lived experience of their customers are. And while in theory these two things should support one another, they often end up in tension.
Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
For automated testing, it really depends. I think it starts around zero and then ramps up over time, usually whenever you hit a situation where you actually feel the pain of not having enough tests, it's a sign that adding more would be good.
As for focusing on best practices and patterns, any more than 5% of your energy is a waste of effort. Have a reasonable set of defaults, tweak it over time, and only worry when it hurts.
(These are again, things that are just based on my own experience/feelings. Keeping w. the theme of the post)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For me, one thing I believe but have no direct evidence for is that focusing too much on automated testing up front in the early stages of the product design and delivery lifecycle can have a net negative impact on both software quality and speed of delivery, because it takes you out of problem space exploration mode and into under-the-hood solution-refining mode.
Another belief I have is that developers who focus too much on language and framework-level best practices and patterns are often less skilled at (or at least less interested in) in focusing on what the actual lived experience of their customers are. And while in theory these two things should support one another, they often end up in tension.
What is "too much"?
For automated testing, it really depends. I think it starts around zero and then ramps up over time, usually whenever you hit a situation where you actually feel the pain of not having enough tests, it's a sign that adding more would be good.
As for focusing on best practices and patterns, any more than 5% of your energy is a waste of effort. Have a reasonable set of defaults, tweak it over time, and only worry when it hurts.
(These are again, things that are just based on my own experience/feelings. Keeping w. the theme of the post)