I currently live and work in the beautiful city of Trieste, Italy.
I am a signatory of the Manifesto for Agile Software Development and of the Manifesto for Software Craftsmanship, which I hold, in some incarnations, among the simplest yet best ideas about software development for the 21st century. Their focus on people, relationships, and values takes what was considered a technical-only task - software development - to a different level, bridging the gap between what is just a software and what is a 'really useful' software.
I work mostly using Java and Python programming languages, yet I think that a developer should be language agnostic and pick the best tool to perform his job in a certain context; lately I'm quite happy when using Ruby, especially for small tasks that need to be automated, and I'm becoming increasingly interested in functional languages.
I'm quite experienced at developing web-oriented, distributed applications with a lot of networking inside, in medium-sized development teams (10-15 people).
I strongly support the idea that quality matters - any way to do something is not the best way to do it.
Teamwork is an essential part of software development. Very few great pieces of software have been created and evolved by a single person, and a motivated, well-jelled team can achieve a development speed which is orders of magnitudes greater than the sum of its components. Let's forget the myth of the genius programmer
I think that problems should be solved where they arise, at their root, and that software is not a solution for business process issues. Creating a software to solve an issue caused by a poor business process may just create a crappy software, and estabilish a bad practice as the 'right way to do it'.
I believe automation is a key factor to highly efficient organizations: as soon as a task can be automated, its burden is gone. How long does that task take is not really important: a lot of time every day is wasted in small, trivial, and yet necessary, manually-performed tasks.
I think that an essential part of software development involves dealing with complexity: mapping a complex concept requires a proper analysis and decomposition in smaller pieces that can be understood and individually handled. A complicate problem doesn't justify a complicate solution.
I like to say that software development is partly a science, partly an art; both faces deserve their own merits and woes, and balance between them should be achieved when programming.
Continuous improvement is the way to achieve better and better results. No one knows everything from the beginning, but that's not a good excuse for not learning from the past. The fact that something has worked (or not worked) someway since long is not a good reason not to improve it.
Innovation can provide groundbreaking advantages to an organization; it often stems from research and needs a favourable environment in order to flourish. Failure is a necessary by-product which must be accepted and learned from.
Here you can find some links to my presentation stuff, slides, and some videos.
Do your once-looking-good projects crumble after some amount of time? Do you spend more and more resources on just maintaining something working rather than improving it? Technical debt may be the root cause of all your issues, even though you may not know it - but you can handle it.
Some example of async programming using Python and Twisted. No link available at this time.