J.P. Hamilton

A very roundabout tale on recruiters

Sat, 24 Jan 2015 23:13:54 +0000

I’m 45 years old. I’ve been writing software regularly since 1979 (at the wee age of 9). To be fair, it was simplistic text adventure stuff back then - Ohio Scientific FTW! - but I progressed pretty quickly. I got an Atari 800 in 1981 and started getting into 6502 Assembly. I did that for a few years and then my dad got some 8088 based Compaq piece of shit somewhere between 1984-1986…I don’t exactly remember. Vague memories of Turbo Pascal and Prolog go here.

What I do remember was the thing sucked. My Atari had multiple graphics modes and a dedicated sound chip and this thing had nothing really…except for more memory. I never would have guessed this would be the machine that would ultimately dominate the planet. I felt totally ripped off.

Eventually I went to school, took a minor detour in the film industry, took Russian, came back to school. Always coding. Fast forward.

I’ve been getting paid to write software since 1993. That’s 21 years of coding and getting paid for it. And 35 years of being on a keyboard and trying to make stuff happen.

(Somewhere in here DirectX was in beta and I begged some Microsoft guy to give me access. I knew the guys name but I had to figure out his email address because it was unpublished. At the time they were only giving it out to game developers. I got a copy and was put on the beta. I made an Asteroids clone and interviewed at Cinematronics in Austin. But I didn’t make the cut.)

Somewhere around 1998 I started to finally “get good”. I’m a slow learner after all.

Around this time I stopped buying “Learn XYZ in 21 Days” type books and started buying books about building better software. I got sick of people telling me “how” and desperately wanted to learn the “why”.

I accidentally found Robert C. Martin’s (aka Uncle Bob) articles on the SOLID principles in C++ Report. My mind was blown. I don’t think I had ever thought about software this way before. I just wanted everything to work.

I wrote 2 books for O’Reilly.

The first was Visual Basic Shell Programming. COM bullshit. I wasted years on COM. I could go on and on about this.

The second one was Object-Oriented Programming with Visual Basic .NET (published in 2002). Uncle Bob reviewed the book for me. I never sent him a copy because I was ashamed at the direction the publisher made me take. A little known fact is this book is the first time the SOLID principles were ever addressed in the .NET space.

Anyway, last week, I was contacted by a recruiter on LinkedIn. He wanted to know what my GPA was.

Looks are everything

Fri, 23 Jan 2015 23:13:54 +0000

I’ve been brought in on a project that has been in progress for a year and a half now.

There’s a lot wrong with it. There is “architecture” for the sake of architecture. Abstractions on top of abstractions (I really hate Repository on top of Entity Framework). Layers of needless complexity - there’s 5 layers from the UI to a place where I can make a database call. One of those is a WCF service boundary.

Folks, this is a thick client desktop app where the database is going to be on the same machine.

You just don’t end up in a place like this when you are driving your design from tests (which is what I like to do) or at least doing the simpliest thing that works and refactoring when it doesn’t anymore.

And on top of everything, this project violates one of the most important rules of all…

** The App Must Look F–king Cool **

The UI is how your client is going to perceive you as a developer and the overall quality of the application. They do not care if your code is awesome or if your architecure is sweet. They want a good looking app that’s easy to use and performant. Everything else comes after. Yes, even quality. You think I’m joking? I’ve experienced time and time again.

Corporate Code Sucks

Wed, 12 Nov 2014 23:13:54 +0000

The SDLC at my current client seems to be something like this:

Find the best people to build the app.
Turn the app over to the cheapest team you can find to “maintain” it.
When the app falls apart, throw it away, go back to 1.

I’ve seen this cycle play out repeatedly. I’m watching it happen now. My client kept me on an extra year to develop new features along side the “maintenance team”. It’s been painful watching the tragedy unfold. That’s why they will get nothing but double quotes from me.

Why is the app falling apart?

I think there are a lot of really, really smart people in this field…that absolutely should not be writing code. I think they lack an eye for it.

Disclaimer: Not claiming that I am hot shit here, but I have spent a considerable amount of time studying how good software is constructed and practicing said construction. I have a decent-ish eye for it.

At this point in history, I think every programmer has heard of the term DRY and knows what it means. But you’d never guess if you could peek into the average, corporate code base. Blocks of duplicated code everywhere. This is the #1 bad thing I see.

No grasp of data hiding. Public things that should be private. This is the #2 bad thing I see.

Poor understanding of encapsulation. If you always have to call method A, then B, then C. How about putting the calls to B and C inside A so I don’t have to remember that stupid shit? People generally seem to be unable to group related things together. And they like to write long methods that take 20 parameters. This is the #3 bad thing I see.

This stuff is all bad, but the real reason the app is falling apart is because the people making the financial decisions don’t understand their poor choices. This is really the #1 bad thing I see, so re-order the others.

Keep it fresh

If I was runnin’ this maintenance mode show, here’s what I would do:

Refactor, refactor, refactor.
Test, test, test.
Keep 3rd party libraries up to date.
Keep updating the UI. Users like this.
Keep the documentation current.

Basically, non-stop TLC.

The “maintenance” team on my project is basically stabbing holes into the architecture and putting their code into the bloody wounds. There is no attempt to understand how everything fits together or try to make the app better. The only concern is fixing the bug, duplication be damned. Over time this app is definitely gonna die.

They have two “testers” who apparently have the easiest job in the world, because they don’t test. When my team was in place we did a full regression test every release. We had 1 tester. They don’t do that now because they say there’s no time. When I asked about changing the release cycle to accommodate a full regression test, they acted like I was an idiot. But then if you cause a bug you get shamed by management. And everyone acts like you are an idiot then, too.

We are behind on several releases of the major libraries we use. The team is still using old versions of Visual Studio, too. In the glory days, we used to update everything after every release. We were always current. We were always updating the UI, too. It sounds superficial, but the users love it. If the app feels fresh, they keep using it. It keeps them really excited about doing a bunch stuff that probably doesn’t even matter in the grand scheme of life.

If You’re Gonna Trash it Anyway

I tried to explain to my client that the requirements documentation was probably the most important thing that could come out of the project. They didn’t listen to me, of course. “No one reads that”, they said. When I said, “Wouldn’t it have been nice to have at the beginning of this project?” they didn’t quite grasp the irony.

I think that if you are going to continually rewrite your apps, it would be a big help to have all of the business rules documented.

It’s going to be a big help to the next team that comes in.

A Simple Blog

Wed, 12 Nov 2014 23:13:54 +0000

After a 3 year hiatus, I came to the conclusion that I needed to start blogging again. But I didn’t want to deal with Azure or web hosting or some overly complicated blogging platform so I kept putting it off.

Then I remembered Github Pages.

It was super-simple to set up, even on Windows (which is not really supported)

Setup Repository

Follow the directions at Github Pages. Go ahead and clone your repo.

Install Ruby

For Windows, the easiest thing to do is install it from RubyInstaller.

You will also need to install the “Development Kit” that matches your version of Ruby. This will allow you to compile native C/C++ extensions, which is required by Jekyll

Install Jekyll

gem install github-pages

Get a Theme

Grab a theme from Jekyll Themes. Dump all of the contents in your local repo. The theme should contain all the files and directories that are needed to start. Just poke around. You will figure it out.

Syntax Highlighting

Install Python. Jekyll uses pygments for syntax highlighting. No need to install pygments. It’s there already.

Comments

Add Disqus. You want to select “Universal Code” when asked. This will show the HTML/js block for your site.

In _layouts/post.html template add the block where you want the comments to appear:

{% if page.comments %}
	<Disqus Universal Embed Block>
{% endif %}

Turn comments on and off in your posts

---
layout:     post
title:      A Simple Blog
comments:   true # <-------------------- Like this
date:       2014-11-12 23:13:54
summary:    Setting up Github Pages on Windows
categories: github pages jekyll
---

Build

After making a post or two, build the site (this will also serve it locally):

jekyll serve

The _site directory will contain the results. Never directly modify anything in this directory because it’s emptied on every build.

If things look good locally, push back to Github.

It can take several minutes for the changes to show up.