Yeah. It was pretty awful early in my career. The good news is that “The person with an opinion has no power over the person with an experience.”
As I’ve built up years of my own work experiences, I don’t spend as much energy on each new idea I encounter.
Now I’m just proud that I still, once in awhile, significantly change the way I work, thanks to new information.
But, since what my team is doing works well already, I have to encounter the same advice from several trusted sources. And then we put it through a test sprint with a thoughtful team retrospective, after.
It’s possible to find a happy balance, but it takes experience to get there.
Edit: So to answer the obvious question - what advice stuck with me?
Host team retrospectives. The rest of Agile is optional. Effective retrospectives are mandatory, because they’re what tunes everything else correctly for my team and my organization.
Cherish plain text under version control. I’ve slept soundly many nights when others were up and working late, thanks to the simplicity and clarity of the process of reviewing what changed in plain text files. Any time a tool supports being setup with plain text files under version control, I advocate for that option.
Pick one thing that matters for today. It helps me focus, and forces me to really decide what matters, today. It helps me say “no” to requests that need to wait. And it helps me choose to give myself a break after I get that one thing done. One important thing per day adds up to awestriking levels of annual productivity, given reasonable opportunities.
When I was learning to program in the 1990s, at university, it was easy to get good advice and learning from the printed word: both in books and on websites. I think if I had to start learning all over again, and not be in a good school, it would be very hard for me to do as well.
Today there is too much advice, too many influencers who recently learned whatever they are peddling, too much AI, too many fields of tech.
I think the best way to learn now is how many of us learned decades earlier; use a list of books that are vetted by many ( can find lists here and there, saw one in GitHub last year). And while reading the books read the documentation even if they are gaps in one’s knowledge and the docs are badly written.
I don’t think one needs recent books for many concepts and basics. The wheel has been reinvented many times in the hundreds of tech stacks in use today. And the same concepts will be easy enough to learn in newer docs once a technology and programming set of tools is invested into by the learner.
As for new software engineering ideas and architecture concepts: usually these are reiterated from earlier ideas and often marketed for profit. So older architecture books, refined by several editions, are still best.
Yeah. It was pretty awful early in my career. The good news is that “The person with an opinion has no power over the person with an experience.”
As I’ve built up years of my own work experiences, I don’t spend as much energy on each new idea I encounter.
Now I’m just proud that I still, once in awhile, significantly change the way I work, thanks to new information.
But, since what my team is doing works well already, I have to encounter the same advice from several trusted sources. And then we put it through a test sprint with a thoughtful team retrospective, after.
It’s possible to find a happy balance, but it takes experience to get there.
Edit: So to answer the obvious question - what advice stuck with me?
Host team retrospectives. The rest of Agile is optional. Effective retrospectives are mandatory, because they’re what tunes everything else correctly for my team and my organization.
Cherish plain text under version control. I’ve slept soundly many nights when others were up and working late, thanks to the simplicity and clarity of the process of reviewing what changed in plain text files. Any time a tool supports being setup with plain text files under version control, I advocate for that option.
Pick one thing that matters for today. It helps me focus, and forces me to really decide what matters, today. It helps me say “no” to requests that need to wait. And it helps me choose to give myself a break after I get that one thing done. One important thing per day adds up to awestriking levels of annual productivity, given reasonable opportunities.
When I was learning to program in the 1990s, at university, it was easy to get good advice and learning from the printed word: both in books and on websites. I think if I had to start learning all over again, and not be in a good school, it would be very hard for me to do as well.
Today there is too much advice, too many influencers who recently learned whatever they are peddling, too much AI, too many fields of tech.
I think the best way to learn now is how many of us learned decades earlier; use a list of books that are vetted by many ( can find lists here and there, saw one in GitHub last year). And while reading the books read the documentation even if they are gaps in one’s knowledge and the docs are badly written.
I don’t think one needs recent books for many concepts and basics. The wheel has been reinvented many times in the hundreds of tech stacks in use today. And the same concepts will be easy enough to learn in newer docs once a technology and programming set of tools is invested into by the learner.
As for new software engineering ideas and architecture concepts: usually these are reiterated from earlier ideas and often marketed for profit. So older architecture books, refined by several editions, are still best.
Yeah. It’s hard to do better than the classicsl books. The language structures have changed, but the core principles endure.