Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
I would tell my younger self to write up test scripts. The idea of automated unit tests was not something I learned about until I adopted Ruby on Rails. But I've seen their value. Namely in refactoring existing code and conveying intention. I've also seen how they can become a false positive.
Yet test scripts are not automated tests; they could be, but they don't need to be. Instead, they focus on stating "How can you verify that this is done?" As a software developer, I would likely look for ways to automate this, but the reality is not all tests need to be automated. But they do need to be remembered.
And knowing my past self, this would be a hard conversation. He was full of hubris, thinking that logic could handle all things. Which, in software, is mostly true, but we invariably make concessions, oversights, and short-cuts. It's the nature of modeling in the abstract.
What I would hopefully instill in my younger self is a sense of helping others come along in the journey of understanding the code I'm delivering. Hence the test plan.
Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
One of my guiding principles is "If it's hard to test, it's going to be hard to maintain and scale." So, make it easy to test.
This influences my low level decisions (make methods easy to test by using dependency injection). And also my higher level decisions (in Rails testing controllers is painful, so minimize the amount of tests you need. Which quickly becomes writing objects for actions.)
I wrote most of github.com/ndlib/sipity, and it's been the most maintainable codebase I've ever wrote. There are a few bad decisions in there based on requirements that later proved to not be necessary.
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.
I would tell my younger self to write up test scripts. The idea of automated unit tests was not something I learned about until I adopted Ruby on Rails. But I've seen their value. Namely in refactoring existing code and conveying intention. I've also seen how they can become a false positive.
Yet test scripts are not automated tests; they could be, but they don't need to be. Instead, they focus on stating "How can you verify that this is done?" As a software developer, I would likely look for ways to automate this, but the reality is not all tests need to be automated. But they do need to be remembered.
And knowing my past self, this would be a hard conversation. He was full of hubris, thinking that logic could handle all things. Which, in software, is mostly true, but we invariably make concessions, oversights, and short-cuts. It's the nature of modeling in the abstract.
What I would hopefully instill in my younger self is a sense of helping others come along in the journey of understanding the code I'm delivering. Hence the test plan.
I would definitely keep this with me. I suffer from too-lazy-to-test-personal-projects disease and this really motivated me to write tests.
Also a great write up, Jeremy. I'm wondering what you have in mind when it comes to writing maintainable and scalable code.
One of my guiding principles is "If it's hard to test, it's going to be hard to maintain and scale." So, make it easy to test.
This influences my low level decisions (make methods easy to test by using dependency injection). And also my higher level decisions (in Rails testing controllers is painful, so minimize the amount of tests you need. Which quickly becomes writing objects for actions.)
I wrote most of github.com/ndlib/sipity, and it's been the most maintainable codebase I've ever wrote. There are a few bad decisions in there based on requirements that later proved to not be necessary.