This has been sitting in my draft folder for a bit. It's rough, but I'm going to publish it now in the spirit of "release early, release often".
So, I give a fair amount of advice. Sometimes it's solicited, mostly it's not. There's two main topics - the first is career advice (avoid doing an advanced degree unless
you're sure you're positive you want to work in a job that requires it, try to find a job in an area that you have a personal interest in so that learning naturally occurs beyond the work day) and the second is how to build web things. The main thing I'm actually interested in is the civic participation in the design and maintenance of modern infrastructure, but no one asks for my opinion about that ...
Part of my spiel about building web things usually involves paraphrasing Tim O'Reilly poorly and then sending my interlocutor a link to Steve Yegge's rant. I noticed that I've sent off that link about 10 times in the last 6 months, so I thought that it would be a good idea to take a few minutes to write down some of the thoughts that I usually share.
I'm not sure what the best order is for these ideas, so I'm just going to spill them out on the table.
- "Small pieces, loosely joined" is a good design philosophy for software.
Actually, probably just stop reading this and go read that whole chapter. It's a much better use of your time.
If you need more convincing, here - from the preface:
"Beyond all these technical specifics, the Unix culture has an unwritten engineering tradition that has developed over literally millions of man-years of skilled effort. This book is written in the belief that understanding that tradition, and adding its design patterns to your toolkit, will help you become a better programmer and designer.
Cultures consist of people, and the traditional way to learn Unix culture is from other people and through the folklore, by osmosis. This book is not a substitute for person-to-person acculturation, but it can help accelerate the process by allowing you to tap the experience of others."
My only addition to this, is that, considering the technological moment we're living in, this book will not just make you a better programmer or designer, it will make you a better citizen.
2) A way of doing small pieces loosely joined is Service Oriented Architecture. In response to a question asked on Stack Overflow asked 8 years ago: Is SOA a fad?
The most important thing to realize about SOA is that it's not really a technology, it's a way to organize IT infrastructure as a bunch of reusable services that can be combined, rather than the current norm of a bunch of applications that require extra effort to integrate when necessary.
Of course, making this work requires technology, but "learning" or buying that technology is meaningless if you don't (re-) organize your IT that way.
I think the basic idea of SOA is sound and here to stay (though it may not be useful in every context). SOA-as-a-technology, on the other hand, is a buzzword fad that will die.
3) Sometimes when we talk about government and tech we talk about "Government-as-a-Platform" -
defined by O'Reilly here as "government is a convener and an enabler rather than the first mover of civic action." Regarding IT architecture, this is what we call taking a services-oriented approach and include the external world as an user of those services.
I've been hoping that the GC Collab team inside the Government of Canada were going to take a service-oriented approach to some of their IT stack, and I was very heartened to hear from one of their leaders that indeed they are. Specifically, I was hoping that they would use their specific application as a lever to make other applications SOA-ified and thereby make them accessible to the outside world.
Here's a recent post from Chris about their work.