Nick Hodges

Nick Hodges is a Software Developemnt Manager at Gateway Ticketing Systems. A long-time Delphi developer, he has recently turned his attention to TypeScript and Angular.

Nick has a BA in Classical Languages from Carleton College and an MS in Information Technology Management from the Naval Postgraduate School. In his career he has been a busboy, a cook, a caddie, a telemarketer (for which he apologizes), an Office Manager, a high school teacher, a Naval Intelligence officer, a software developer, a product manager, and a software development manager. In addition, he is a former Delphi Product Manager and Delphi R&D Team Manager. He’s a passionate Minnesota sports fan — especially the Timberwolves — as he grew up and went to college in the Land of 10,000 Lakes. He currrently lives with his family in Gilbertsville, PA.

Angular 101: Angular from Start to Finish

Friday, November 16th, 2018 at 8:30 am

This will be a hands-on session on Angular development.

It will assume zero knowledge about Angular and TypeScript. We’ll start from scratch and build an application that will cover the following topics:

* Introduction to Angular
* Introduction to TypeScript
* A basic Angular Application
* Components
* Databinding
* Directives and Pipes
* Dependency Injection in Angular
* Asynchronous Services
* Routing
* Forms in Angular

The workshop will introduce attendees to Angular and TypeScript and by the end, they will have built a database driven ToDo application in Angular.

Connascence, or How to Measure Coupling

Wednesday, July 20th, 2016 at 6:15 pm

Everyone talks about loose coupling, but what exactly does “coupling’ mean? How exactly do you measure coupling? In 15 minutes, I’ll outline the nine types of coupling and show you how you can reduce coupling through the concept of “Connascence”.

Unit Testing: What it is, Why you should be doing it, and how to do it

Saturday, June 21st, 2014 at 7:30 pm in

Michael Feathers defines “legacy code” as “code that has no unit tests”. Without unit tests your code is fragile, hard to change, and unreliable. Unit testing is the only way that you can be sure that your code does what it is supposed to do.

This talk discusses the basics of Unit Testing by defining terms, discussing what Unit Testing is and is not, and talking about the best techniques and practices for writing unit tests.

All the demos will be in Delphi code, but the principles all remain the same: There no longer is an excuse for not writing unit tests.

Nick’s Nuggets: Software Development Wisdom from Twitter

Saturday, November 23rd, 2013 at 1:30 pm in 211

I tweet a lot. A lot of software developers tweet a lot. Despite the limit of 140 characters, a lot of wisdom can be packed into a tweet. In this presentation, I’ll review upwards of 50 tweets — that’s almost one a minute! — that talk about smart, funny, wise, and interesting things to do with software development. This fast-paced, light-hearted yet insightful set of tweets by me and others will leave you full of mirth and wisdom about how you approach the software development process.

Can Developer Productivity Be Measured?

Saturday, May 11th, 2013 at 8:30 am in 112

If you go to Google and search for “measuring software developer productivity” you will find a whole lot of nothing. Seriously — nothing.

Well, okay, not exactly nothing. You’ll get a ton of links. But almost all of the links you find will talk about how measuring the productivity of software developers can’t be done effectively. Some people will even argue that it shouldn’t be attempted at all. Some others will describe techniques to measure developer productivity, that, well, everyone else knows don’t really work.

There have been many valiant attempts to measure developer productivity, but all seem to end in less than successful territory. (We all know to laugh at “Lines of Code” as a productivity measure). Virtually any objective measurement you can apply to the software development process can be “gamed” into submission.

There are just too many variables to account for everything that goes into the development process. Measuring any one of them, or even a combination of them, simply cannot begin to capture effectively everything that is involved. You can’t pick a surrogate thing to measure, but because of human nature, developers will react in ways that will skew the measurement. Many studies have been done on this topic, with little to show for it. Every software development manager who has to fill out a developer’s evaluation or determine who gets bonuses has struggled with this. Many a leading expert and guru has thought about and researched this thorny topic.

This talk will discuss the futility of trying to *objectively* measure developer productivity and instead will propose a means for making an attempt at an “objectively subjective” way to measure developer productivity.