Growing with a software product

I spend several hours a week learning more about programming languages, stacks, pipelines, patterns, anti-patterns, concepts, frameworks, and practices relating to building software. Knowing syntactical differences between a dozen object oriented languages has never been on my agenda. Language adoption happened rather organically as job opportunities presented themselves over the last fourteen years. My primary stints so far being several years each with PHP, ColdFusion, Java, and my longest and most recent C# on the backend. All of these are roughly interchangeable and suitable for building server-side logic. As the years go by I care less about the language. Especially since C# has proven to be a solid choice over the past six years. And it should maintain it’s place as more features are added.

It’s the Indian not the arrow

I have been enamored with principles of functional languages and how they can help me produce better software. I am all over F#, too. And Domain Driven Design, CQRS, and Event Sourcing are blowing my mind as well since I grew up playing with the big ball of mud. Although it is a shame that I am over a decade late to the party, I get to dance the rest of my career.

Applying the learned skills

Growth begins after the first release.

Pushing out the first release is fun, yes. But only after a product has usage and the feedback loop is closed does the real potential for growth present itself. If you are adhering to agile principles you probably did not take months to push out the MVP release. And this may mean the product is rather vanilla or feature light. But with each successive release the product grows either in features or complexity. But the developers are able to utilize a deeper technical understanding of the product along with the old and new skills to produce a maintainable quality version of the product that satisfies the next round of refined user stories.

The more tenured the developer and the developer with a product the better the quality of the product.

It is good that a developer learns frameworks to save time, promote consistency, and patterns for writing more bug free code. If that developer works on small and isolated features for lots of software products, think coder in a software shop, I argue that the level of impact made on each of those projects would not be as significant as that which could be made over a significant portion of the lifetime of few software products.


Mentoring my first software engineering intern

I recently had the honor of mentoring a software engineering intern, Ben, for my employer from the local university’s Computer Science program. At the first mention of the program earlier in the year I was eager to get involved as I absolutely love teaching and learning from others. After the nine week internship I have zero regrets. And I did come away with some notes for the next go-around. I made sure to ask for an honest, no hard-feelings review from Ben.

Continue reading Mentoring my first software engineering intern


Realized benefits of programming in grade school

I was fortunate enough to attend a vocational high school that offered Computer Science curriculum as a first-class citizen. Years 2002-2006 included general IT (A+) and networking (Cisco networking), C++, Java, Oracle SQL and some Web design training along with traditional math, English, etc. In addition, I spent my nights learning PHP and MySQL-based Web development. By the time I started college I felt like a mid-level developer. I wasn’t, of course. But I felt like one. This early introduction to software development yielded several benefits that helped in high school, college, and in my career today.

Continue reading Realized benefits of programming in grade school