The idea of monolithic software is a rarity for most folks. Even an operating system, which is itself a big monolithic beast as far as most users and developers are concerned, has it's own plugin ecosystem. The operating system does a lot of work, but the vast majority of that work is in support of plugins, or applications, that run on top of it. Like it or not, its these plugins that make the software on which they run useful. They support the idea of an ecosystem, new plugins evolving from old ones, old and stable plugins becoming dependencies of other plugins — once the plugin development community forms, it seems there is no stopping it. The ecosystem that plugin development sets forth opens up the door to an interesting development culture, one that seems to have a strong experimental, and thus, strong educational feel to it.
Showing posts with label ecosystem. Show all posts
Showing posts with label ecosystem. Show all posts
Friday, February 22, 2013
Thursday, January 19, 2012
Learning and Software
Michael Gove's speech on the digital literacy campaign, currently underway in the UK, got me thinking about how software developers go about learning new software systems. The digital literacy campaign aims to resolve deficiencies in the educational system. This is a fantastic initiative and I think other nations follow suit. Without transitioning from traditional teaching techniques we're used to, our children will be left behind.
What I'm thinking about isn't so much the education system. I'm looking at the young working adults, many of whom don't have a formal education to speak of — friends and colleagues of mine that have gone on to lead promising careers in IT. The positions they hold require they really know their stuff. How do they obtain this knowledge? How do you beat the competition when it comes to know-how?
The Ecosystem
There is an important difference between learning the principles of computer science, and learning how to work with pre-built components. If those entering the field were taught an important lesson, they'd know that re-inventing the wheel is a no-no. It's highly probably that you can build what you need by assembling parts, possibly customizing them slightly along the way. With computer science, everything is from the ground up. And that's important too, to have a sound theoretical understanding of what software is made of. Competing in the job market requires that you have at the very least a rudimentary understanding of everything that goes on between the keyboard and the screen.
The software ecosystem of today is uninterruptedly growing and evolving. Some software components stabilize over time, attracting a wider development audience and thus making further improvements. Some software components don't gain acceptance in any communities — they subsequently die off. Understanding the context in which these open source software packages are used is a valuable asset. It would be a much better learning opportunity to participate in the development of something with staying power. Something that has proven feasibility and impacts a large group of users for a long time. Before embarking on a new software project — an experience where you learn a new programming language or a new problem domain — do some research into why you prefer one project over another. Is there a real future for this project? Is there an alternative that might better suit your learning goals for the long term?
The way software systems work with one another is increasingly relevant — a lot of development work these days is integration rather than writing new code. Reusing existing components, utilizing the best tool for the job — skills that matter. If you spend enough time practicing this evaluation exercise, you'll be able to identify when, exactly, there simply isn't anything suitable for the gap you're trying to fill. This is your time to write something new. This is how the ecosystem evolves. Maybe you're new software package will acquire a following and become a huge success. Maybe it will serve as the basis for a superior project, earning you a reputation. Or maybe it will be a spectacular failure, in which case you take away some valuable lessons.
Teaching by Learning
One unique property of doing software development in an open environment is the shared roles of teacher and learner. That is, anyone participating in a software development can, and should, fulfill the role of teacher. Software development is a nascent field — it's constantly changing because we're constantly building better components. There is no such thing as a dedicated teaching role because it's impossible to keep abreast with everything new that's happening. That responsibility is distributed throughout the team — everyone should be making discoveries on their own and sharing them with their peers.
Learning to write software is an enlightening experience. It has never been more accessible to anyone, regardless of stature, this ability to acquire new knowledge and to apply it. Simultaneously. With software development, theory and practice are tightly integrated. This is why I love my job — my education didn't end with college — it only just got interesting when I started building real software for real customers. The open source ecosystem serves as an ideal launchpad for anyone looking to further their experience. Understanding how this ecosystem evolves and how to best utilize it's inhabitants is a skill no school can teach. You have to do it yourself. And it's no trivial investment, but well worth it. Maybe we'll start seeing educational institutions adopt these new methods of software-based learning in the not-too-distant future.
What I'm thinking about isn't so much the education system. I'm looking at the young working adults, many of whom don't have a formal education to speak of — friends and colleagues of mine that have gone on to lead promising careers in IT. The positions they hold require they really know their stuff. How do they obtain this knowledge? How do you beat the competition when it comes to know-how?
The Ecosystem
There is an important difference between learning the principles of computer science, and learning how to work with pre-built components. If those entering the field were taught an important lesson, they'd know that re-inventing the wheel is a no-no. It's highly probably that you can build what you need by assembling parts, possibly customizing them slightly along the way. With computer science, everything is from the ground up. And that's important too, to have a sound theoretical understanding of what software is made of. Competing in the job market requires that you have at the very least a rudimentary understanding of everything that goes on between the keyboard and the screen.
The software ecosystem of today is uninterruptedly growing and evolving. Some software components stabilize over time, attracting a wider development audience and thus making further improvements. Some software components don't gain acceptance in any communities — they subsequently die off. Understanding the context in which these open source software packages are used is a valuable asset. It would be a much better learning opportunity to participate in the development of something with staying power. Something that has proven feasibility and impacts a large group of users for a long time. Before embarking on a new software project — an experience where you learn a new programming language or a new problem domain — do some research into why you prefer one project over another. Is there a real future for this project? Is there an alternative that might better suit your learning goals for the long term?
The way software systems work with one another is increasingly relevant — a lot of development work these days is integration rather than writing new code. Reusing existing components, utilizing the best tool for the job — skills that matter. If you spend enough time practicing this evaluation exercise, you'll be able to identify when, exactly, there simply isn't anything suitable for the gap you're trying to fill. This is your time to write something new. This is how the ecosystem evolves. Maybe you're new software package will acquire a following and become a huge success. Maybe it will serve as the basis for a superior project, earning you a reputation. Or maybe it will be a spectacular failure, in which case you take away some valuable lessons.
Teaching by Learning
One unique property of doing software development in an open environment is the shared roles of teacher and learner. That is, anyone participating in a software development can, and should, fulfill the role of teacher. Software development is a nascent field — it's constantly changing because we're constantly building better components. There is no such thing as a dedicated teaching role because it's impossible to keep abreast with everything new that's happening. That responsibility is distributed throughout the team — everyone should be making discoveries on their own and sharing them with their peers.
Learning to write software is an enlightening experience. It has never been more accessible to anyone, regardless of stature, this ability to acquire new knowledge and to apply it. Simultaneously. With software development, theory and practice are tightly integrated. This is why I love my job — my education didn't end with college — it only just got interesting when I started building real software for real customers. The open source ecosystem serves as an ideal launchpad for anyone looking to further their experience. Understanding how this ecosystem evolves and how to best utilize it's inhabitants is a skill no school can teach. You have to do it yourself. And it's no trivial investment, but well worth it. Maybe we'll start seeing educational institutions adopt these new methods of software-based learning in the not-too-distant future.
Subscribe to:
Posts
(
Atom
)