Why Write About Software Development

"Why?" should be the first question you always ask before starting anything.

This question is the most important part of any successful project. Asking "Why?" sends the thought process towards the more abstract; towards further discovery / declaration of "the problem" (whatever "the problem" may be is unimportant). In my experience, not enough time is granted or available for "why". I think this is because development teams tend to focus on solutions before problems. It is, after-all, "what we're paid for". To an extent, I think some are bound-by-circumstance to think about solution spaces more than problem spaces; bound by money and time of the client / employer. Through conversations I've had with folks outside my sphere, I've come to realize that I'm luckier than I previously believed.

I am fortunate to work in an environment that is not driven entirely by budget; not driven by procuring the next client or seed money. Given that freedom, my environment also has a series of "cons"; the most egregious being ignorance (and I mean this in the absolute best sense of the word).

So, that said, "Why write about software development?". The first thing that popped in my head while writing was "community". That is not an answer to the question, but it is what it is. Some may say it expands my "brand" and some might say that it serves as a knowledge-bank to direct folks to. Brand and bank-of-knowledge are important, but my mind still comes back to "community". Why?

I'm in a development team of 3, a group of 6, an organization of ~20, college of thousands, university of tens of thousands. There are other development teams of smaller and similar size, groups larger than mine, organizations and so-on; all under the same university. This decentralization creates an environment where communication is staggered and strenuous. I've had multiple occasions where I find that folks from other teams scattered are working on solving the same problems I am. This is problematic when given an environment that supposedly has ultimate resources to truly discover and understand problem spaces. My mind comes to "community" because I realize that the silo-ed developers in my environment are ignorant to the conversations and growth that my team experiences daily. I am like-wise ignorant to the growth other teams are experiencing. I need to be able to take advantage of this growth. Community mitigates ignorance.

Then I consider the PHP community at-large. I've been lucky to attend conferences and have time to get involved with a few open-source projects; meeting people along the way. When you step into that space, a whole world of opportunity is opened to you. I have the opportunity to communicate with some of the brightest minds in the PHP community and at the same time have the opportunity to help mentor newcomers. This is a truly amazing space to work in. As great as the PHP community is, I recognize a similar pattern to my own environment. When I think about PHP, I consider a programming community, a systems community, a business community; up-and-up we go, growing every step. There are conversations and patterns trending in the PHP community that got their start in 1960-70. Things like "Domain Driven Design" gave a name to concepts that have been written about for the past 50 years. As an exercise, I've forced myself for the past year to attempt to stay up-to-date with at least 3 other communities outside of PHP. This has been one of the greatest benefits to my development I've come to and I recommend it highly. There is a great programming community out there that has half-a-century of knowledge and experience waiting to be tapped.

This is getting longer than I wanted, so I'm going to wrap it up by getting to the point: "Why write about software development?"…

I am going to write about software development in order to explain HOW I reason about the WHY. Most of the literature I've read on the web for the past year is so focused on solving a particular problem, that the "why" is lost-in-translation and the reader comes away from the material with no more than "this is how I do X thing". This type of content is definitely valuable when you're "stuck in a sawtooth" and need something to "pop you out of the bind" (Stack Overflow comes to mind here. Love it!). Even when approaching more abstract or theoretical material, the examples used to apply the theory are so generic that they approach being borderline useless. As an aside, I'm not criticizing these types of materials. The fact of the matter is that when you approach communicating an advanced subject, the concrete examples you use need to be simple. If they are not, you risk overwhelming the reader. I've heard many speakers / writers remark that they regularly receive mails from readers either saying the examples used were too simple or advanced. It's hard to write content for everyone.

I want to write an ebook and a series of presentations, but writing (like all skills) is only obtained through practice. That said, I'm going to focus on writing material that uses interesting real-world scenarios I encounter to explain some of the "theoretical nonsense" :grin: I've picked up over the years in a way that explores trade-offs in designing solutions in a pragmatic way. I'm going to stress the importance of thinking relatively and crushing "the absolute mindset". Statements that get blasted across Twitter from our communities' celebrities have (in most cases) years of experience and nuance behind them. This is lost in 140 characters.

Bah, done for now.