There's a few things that have come to mind after reading this.
Firstly, you're describing what to me is a key thing - solution oriented Vs problem
orientated.
Context is everything and knowing the problem better allows me to apply the best (known) solution or at least figure out the least painful one!
Second, it's about scope, personal to business etc. If the problem is inside my personal scope, then I'll apply my best solution come what may, outside of me is then another matter.
And so yes, I do make sure I apply dark mode to 'everything' and did spend hours figuring out how to apply it to a really old IDE that I was forced to use for 'reasons' on more than one occasion 😉
A thorough answer would require a book. I’m particularly prone to the hero on the white horse syndrome, so I deeply suspect when I think revolution is necessary. Then if I totally run out of incremental options I go for it.
Agree, very tricky subject with no easy answers. I recently was given a lot of autonomy on credit (unusual) and decided to go for a revolution (risky). Other unique factors are involved that are too local to get into. 4 weeks in, we made several production deployments and are building reputation through delivering value. The business is starting to take advantage of early and frequent releases but it is straining parts the organization. So far it’s holding up but long term success is far from certain. Will have to pull back on revolution as needed.
Most my days start with something on fire and each morning a developer, let's call him Victor, logs into the web server and pull the logs for that day's catastrophe. Not too long ago I suggested logging the errors to a database so everyone can access them via a simple web page. The response was why? What's wrong with Victor getting the logs?
Sometimes, people don't see the problem that is plain as day to you. And there is nothing you can do to convince them otherwise. It just means they haven't experienced enough pain to see a problem.
I like the article, but I do not really see what’s wrong with bringing your „toolbelt“ with you, as you described in the first paragraph. Granted, my toolbelt consists of configurations for my shell more than any specific scripts or programs, and maybe that’s already different enough that this first paragraph does not apply anymore, but I think bringing something with you, if it’s sufficiently standalone does provide a great benefit.
Actually I think this fits into he metaphor: if you’re looking at a problem in your new place that was solved in your old place already, you do bring something with you: components A, B, C, D and so on that you know can solve the problem. But as it was correctly written, the context should be observed, and the solution proposal should start from general abstractions of the previous solution rather than from the specific implementation that one knows from before.
The point I'm trying to make is to 1) be aware of the importance of context & 2) have confidence enough that you don't have to recreate your whole previous situation before you feel comfortable. I hear seniors saying, "Well, I just can't possibly work with <favorite tool>." Sure you can. Recreate it piecemeal & you'll be fine. Or just try doing without it.
I like this. I think, or example, in my current situation I didn’t full grasp this point.
I think the toolbelt can also include practices like TDD, user stories, story splitting, refactoring and patterns. One aspect context can be that different organization prioritize different values. The different values might mean they favor different practices. It can be really hard to let go of these practices when they’ve worked so well.
Saving this post to my private collection of wisdom that I reference from time to time. The Value --> Reputation --> Autonomy --> ... loop is money.
There's a few things that have come to mind after reading this.
Firstly, you're describing what to me is a key thing - solution oriented Vs problem
orientated.
Context is everything and knowing the problem better allows me to apply the best (known) solution or at least figure out the least painful one!
Second, it's about scope, personal to business etc. If the problem is inside my personal scope, then I'll apply my best solution come what may, outside of me is then another matter.
And so yes, I do make sure I apply dark mode to 'everything' and did spend hours figuring out how to apply it to a really old IDE that I was forced to use for 'reasons' on more than one occasion 😉
Great advice. How do you recognize moments for revolution?
A thorough answer would require a book. I’m particularly prone to the hero on the white horse syndrome, so I deeply suspect when I think revolution is necessary. Then if I totally run out of incremental options I go for it.
Agree, very tricky subject with no easy answers. I recently was given a lot of autonomy on credit (unusual) and decided to go for a revolution (risky). Other unique factors are involved that are too local to get into. 4 weeks in, we made several production deployments and are building reputation through delivering value. The business is starting to take advantage of early and frequent releases but it is straining parts the organization. So far it’s holding up but long term success is far from certain. Will have to pull back on revolution as needed.
Most my days start with something on fire and each morning a developer, let's call him Victor, logs into the web server and pull the logs for that day's catastrophe. Not too long ago I suggested logging the errors to a database so everyone can access them via a simple web page. The response was why? What's wrong with Victor getting the logs?
Sometimes, people don't see the problem that is plain as day to you. And there is nothing you can do to convince them otherwise. It just means they haven't experienced enough pain to see a problem.
And then you have to decide whether to just go do the thing or to live with the consequences of not doing the thing.
I like the article, but I do not really see what’s wrong with bringing your „toolbelt“ with you, as you described in the first paragraph. Granted, my toolbelt consists of configurations for my shell more than any specific scripts or programs, and maybe that’s already different enough that this first paragraph does not apply anymore, but I think bringing something with you, if it’s sufficiently standalone does provide a great benefit.
Actually I think this fits into he metaphor: if you’re looking at a problem in your new place that was solved in your old place already, you do bring something with you: components A, B, C, D and so on that you know can solve the problem. But as it was correctly written, the context should be observed, and the solution proposal should start from general abstractions of the previous solution rather than from the specific implementation that one knows from before.
The point I'm trying to make is to 1) be aware of the importance of context & 2) have confidence enough that you don't have to recreate your whole previous situation before you feel comfortable. I hear seniors saying, "Well, I just can't possibly work with <favorite tool>." Sure you can. Recreate it piecemeal & you'll be fine. Or just try doing without it.
I like this. I think, or example, in my current situation I didn’t full grasp this point.
I think the toolbelt can also include practices like TDD, user stories, story splitting, refactoring and patterns. One aspect context can be that different organization prioritize different values. The different values might mean they favor different practices. It can be really hard to let go of these practices when they’ve worked so well.
Pull those tricks out of your bag a little at a time. That's the point of the essay.
This hits so close to home :)
Oops 😉