The Cost of Innovation: Influenced by the Movie "Spare Parts"
Lest everyone think I'm just a comic book movie fan-girl, I realized I need to expand my blog writing out to other movies, other genre, and discuss what I've learned from those. The movie "Spare Parts" hit me in the feels.
While I can't identify with being an undocumented immigrant in the US, I did identify with being the poor kid and trying to turn nothing into something.
When your organization doesn't have the latest and greatest, finding a way to make something out of nothing is a boon. Learning anything that could help streamline a process. Testing things and letting the results influence methods and practices is no small feat! But organizations need to be open to this kind of influence. I think the ones that are, typically keep more people and benefit from a healthy, diverse environment of thinkers. (Note that I used the word thinkers, not just testers and/or developers.)
The trap might be in looking at other organizations and seeing what they have and comparing it to yours. I've done this. I've thought this or that organization was doing was so much better and we should absolutely model those ideas and incorporate them ASAP! This kind of thinking can and does limit the creativity of your own organic growth. We should be sharing and learning on a regular basis, but if you rush to be like someone else, what have you lost in the process? A forced process is rarely maintained past the person who implemented it.
A friend reminded me the other day that while I might not be a wiz kid at writing code, yet, I'm still learning and I can still learn and continue to learn at my own pace and not push myself to know it all by tomorrow. Because A) That's not going to happen, and it's not realistic; and B) I rarely learn in a linear fashion. Pointing this out was something which I hadn't thought about myself. I don't typically pick things up and learn from point A to point Z. I've always seen the picture at a high level, like a puzzle and picked up pieces and popped them into place as I understood where they fit in the fabric of what I'm learning at the moment. Even later, when I'm learning something completely different, and a piece, hanging out on the fringe of the picture, didn't work in the big picture at first, suddenly falls into place because I was focused on something else and now understand the value of that piece from before. My creativity and my ability to look at the big picture and learn from these moments, when I need to, but maybe not at the pace others think I should, is completely me. And I shouldn't disregard this simply because it's not the norm or not at the skill level I see that others have. I need to be creative with what I do understand, and add to my skills as I can master them as the picture clarifies for me. I work with and find mentors and resources to help me incorporate my puzzle pieces. To build my big picture, or in the case of the movie, build my robot.
So how does this relate to the movie "Spare Parts" exactly?
These high school kids totally kicked ass because they dealt with being disadvantaged every day of their lives. They came up with cheaper, faster solutions than the schools with more money and time invested in the competition. They overcame a lot to create a robot, and while it wasn't the best, was exactly what was needed in the time they had to accomplish the task. They beat out MIT. Twice. Software development can follow these same principles. So can personal and career development.
Manage your defects, your people (which are people, not resources), your tech stack and your product with judicious efficiency. Don't go for the biggest shiniest thing because everybody else is doing it. The bleeding edge is called that because people bleed out there, on the edge, discovering issues and trying to staunch the blood flow caused by new code adaptations and the unexpected results from tech and languages that have very little foundation in the market place. There are some organizations that have the capital to do this and they lay the foundation for others, but that doesn't mean that the little-organization-that-could has to use it to stay absolutely relevant. But they shouldn't shy away from adopting new things either when it fits a need rather than a whim.
For those with a software development career, maybe the shiniest, latest JavaScript isn't the best thing to try to learn if you don't have a good foundation of code development. Maybe learning the latest in Data architecture isn't a good idea if you are still struggling with principles. Or maybe it is - only you can decide. Only you know what pace you can learn. Maybe your strengths don't speak to those things right now, but by doing something else, like speaking or going to meet-ups or mentoring others, you gain knowledge and access to those things and they fall into place for you.
Sometimes, you don't need the best, shiniest thing, right now, to do something new and innovative. Sometimes all you need is really clever people that can do some pretty amazing things with PVC pipe and tampons.
While I can't identify with being an undocumented immigrant in the US, I did identify with being the poor kid and trying to turn nothing into something.
When your organization doesn't have the latest and greatest, finding a way to make something out of nothing is a boon. Learning anything that could help streamline a process. Testing things and letting the results influence methods and practices is no small feat! But organizations need to be open to this kind of influence. I think the ones that are, typically keep more people and benefit from a healthy, diverse environment of thinkers. (Note that I used the word thinkers, not just testers and/or developers.)
The trap might be in looking at other organizations and seeing what they have and comparing it to yours. I've done this. I've thought this or that organization was doing was so much better and we should absolutely model those ideas and incorporate them ASAP! This kind of thinking can and does limit the creativity of your own organic growth. We should be sharing and learning on a regular basis, but if you rush to be like someone else, what have you lost in the process? A forced process is rarely maintained past the person who implemented it.
A friend reminded me the other day that while I might not be a wiz kid at writing code, yet, I'm still learning and I can still learn and continue to learn at my own pace and not push myself to know it all by tomorrow. Because A) That's not going to happen, and it's not realistic; and B) I rarely learn in a linear fashion. Pointing this out was something which I hadn't thought about myself. I don't typically pick things up and learn from point A to point Z. I've always seen the picture at a high level, like a puzzle and picked up pieces and popped them into place as I understood where they fit in the fabric of what I'm learning at the moment. Even later, when I'm learning something completely different, and a piece, hanging out on the fringe of the picture, didn't work in the big picture at first, suddenly falls into place because I was focused on something else and now understand the value of that piece from before. My creativity and my ability to look at the big picture and learn from these moments, when I need to, but maybe not at the pace others think I should, is completely me. And I shouldn't disregard this simply because it's not the norm or not at the skill level I see that others have. I need to be creative with what I do understand, and add to my skills as I can master them as the picture clarifies for me. I work with and find mentors and resources to help me incorporate my puzzle pieces. To build my big picture, or in the case of the movie, build my robot.
So how does this relate to the movie "Spare Parts" exactly?
These high school kids totally kicked ass because they dealt with being disadvantaged every day of their lives. They came up with cheaper, faster solutions than the schools with more money and time invested in the competition. They overcame a lot to create a robot, and while it wasn't the best, was exactly what was needed in the time they had to accomplish the task. They beat out MIT. Twice. Software development can follow these same principles. So can personal and career development.
Manage your defects, your people (which are people, not resources), your tech stack and your product with judicious efficiency. Don't go for the biggest shiniest thing because everybody else is doing it. The bleeding edge is called that because people bleed out there, on the edge, discovering issues and trying to staunch the blood flow caused by new code adaptations and the unexpected results from tech and languages that have very little foundation in the market place. There are some organizations that have the capital to do this and they lay the foundation for others, but that doesn't mean that the little-organization-that-could has to use it to stay absolutely relevant. But they shouldn't shy away from adopting new things either when it fits a need rather than a whim.
For those with a software development career, maybe the shiniest, latest JavaScript isn't the best thing to try to learn if you don't have a good foundation of code development. Maybe learning the latest in Data architecture isn't a good idea if you are still struggling with principles. Or maybe it is - only you can decide. Only you know what pace you can learn. Maybe your strengths don't speak to those things right now, but by doing something else, like speaking or going to meet-ups or mentoring others, you gain knowledge and access to those things and they fall into place for you.
Sometimes, you don't need the best, shiniest thing, right now, to do something new and innovative. Sometimes all you need is really clever people that can do some pretty amazing things with PVC pipe and tampons.
Comments
Post a Comment