Leadership Lessons: Appreciation

Leave a reply

There are plenty of lists, books and seminars out there that tell you how to be a leader, a good leader, even a great leader. But the real measure over time is how others view you in a leadership role. How did you treat each person? Are they individuals or resources? Are they people or employees?

I wasn’t always a leader. And I’m not always a good leader. I have my good days and my bad days. There are days when I’m confident in my skills and my decisions. And there are days when I question myself, what I’ve said and how I’ve acted. Did I treat someone poorly? Did I let my frustration turn into anger? Was I a jerk?

Sometimes I just need a confidence boost like any other person.

And today, I found it.

I was finally doing some cleaning in my home office. It seems that I’ve worked in a lot of different places and I’m not always good about tossing out the junk when I clean out my office desk. Of course, I don’t take it to the new office — I just let it pile up in random boxes at my house.

Today, I decided to consolidate, trash and otherwise clean it up.

I saved a handful of my business cards showing all the different roles (15) I’ve had since 1989 when I started as a newspaper reporter right out of college (actually before I graduated). But I tossed away every other business card that I had saved from meetings over the years.

As I was making my way through my fifth or sixth box, though, I found a “going away” card that I received from one my teams about seven years ago. It was buried deep under a pile of receipts and other junk.

It said “We’ll Miss You” on the front; and I opened it up to see what job it was from — I wasn’t sure. Inside were more than dozen notes with personal messages and signatures.

  • “Thank you for taking a chance on hiring me, Twice! I appreciate the encouragement to work harder towards larger goals.”
  • “Thank you for the opportunity you provided when you took a chance and got an independent developer.”
  • “Thank you for your guidance and support over the five years we worked together.”
  • “I’ll never forget that you noticed and complimented my pocket square during my interview. I knew I was making the right choice!”
  • “Thank you for the support you provided me during the past year.”
  • “You took a chance on a fresh grad with little experience. I will always appreciate & remember!”
  • “Thanks for bringing me on board. I’ve learned and grown a lot since then.”
  • “I will always appreciate and be grateful that you believed in me enough to hire me and support me these past couple of years.”

What a shot in the arm that gave me! I needed it. I have to admit that my eyes got a little watery. I’m not posting this because I want you to think I’m great. There are two main reasons.

First, to all the people who work with a leader — if they inspire you, guide you, help you, let them know it. Don’t wait for them to the leave the organization, tell them. People in leadership roles need reassurance, just like you do.

Second, for all the leaders out there — my goal is to make you think about how you are interacting with your team and others. Do you notice the little things? Are you giving people a chance to prove themselves? Are you inspiring them and recognizing their good works? How do you react to failures? People on your team need your attention and reassurance, just like you do.

When I read through that list of good-byes, I saw a few themes: opportunity, growth, support and appreciation.

A couple of folks said I took a chance when I hired them. If that’s true, then they took a chance by accepting the job offer. Either one of us could have failed. Did I create an atmosphere for them to succeed? Did they seize that opportunity?

A couple of them said they saw growth in themselves over the years we worked together. Wow! I saw it, too! I still see it — especially when they get a new job or are promoted at their new companies.

And so many of them expressed appreciation, which makes my heart swell.

The reality is that I grew a lot in those years, too. And I put the blame squarely on them — my team members. Each one of them gave me a chance. They all provided me with support and guidance. They taught me so much.

Simply put, they made me a better person and a better leader. Thank you, all. I really appreciate it — and I miss you all, too.

The Toughest Software Bugs

Leave a reply

Someone recently asked me what I thought were the toughest bugs to find and fix.

I’m pretty sure they wanted a technical answer — one that would dive deep into the code and talk about the stickiest math problem, logic issue, endless loop, null pointer error, or buffer overflow.

This was one technology guy to another technology guy, so you would assume it would be something like the stuff above.

Instead, I told him that the toughest bugs are the oldest bugs. That’s right — it doesn’t matter how hard or how deep in the code the bug is, the faster you find it, the easier it is to deal with.

This is because after a developer has released their code, they treat it like a known and trusted quantity. As such, they stop thinking about it. They expect it to work just like they expect the sun to rise in the east. If the sun is up, then that code works. They don’t think about it any longer and they may actually forget that they wrote it.

So, the best way to debug your code is to find the bugs as soon as possible. … Before you write more code and forget what you were working on. Before you commit more code and you’re unsure what is causing the bug. Before you release it to the public.

With our software teams, we start that process with unit tests. Those are followed by peer reviews. This leads to an automated system that verifies the project builds without errors. It also runs the unit tests and checks the code style. This is followed by verification that the feature works as expected — including math checks. Then there’s manual testing and finally automated tests using Selenium. After all this, the whole application is tested. 

That gives us many chances to find a bug before it is released.

The majority of that testing is done on the feature itself, which reduces the amount of code that must be reviewed and debugged. The smaller the footprint, the less investigative work you need to do. The sooner you start, the more familiar you are with the affected code.

One of the tenants of the Agile Scrum development methodology is to inspect and adapt. Review your work and change it if it needs to be changed. This is often applied to project stakeholders who are supposed to get frequent demos so that they can react early and request changes before you complete the project. 

But I believe this also applies to the software development process. As software engineers, if we pause a little to inspect our code and adapt it, then we will fix our bugs more quickly. In the end, the minutes we spend finding and fixing errors now will save us hours and days later.

This isn’t about never writing a bug. It’s about finding our errors first and fixing them. Someone else once told me, “it’s not about whether you fail, it’s how you respond when you do fail that sets you apart.” Expecting bugs, looking for them and fixing them right away is the fastest and most responsible way to deal with them.

Software Security is Not an Option

Leave a reply

When it comes to software development, many customers (external or internal) will not request, require or even ask you about the security features you are implementing. Either they don’t know enough to consider it or they think you’re going to do it because you’re the professional.

Whether you are a contractor or an internal software engineer, you need to make sure that security is considered, it is strong and it is tested. No customer is going to put security on your feature list. If they do, it may be something as simple as making sure there are eight characters in the password, that there is an uppercase and lowercase letter, that it includes a number and a special character. 

Whew. My work is done. I’ve met the requirements. The password is secure.

No. No, it isn’t. 

  • If you are transmitting the password as plain text, it is not secure.
  • If you are storing the password as plain text, it is not secure.
  • If you are encrypting the password, it is not secure.
  • If you aren’t using HTTPS (TLS v1.2), it is not secure.
  • If you are using SHA-1 to hash the password, it is not secure.
  • If you are hashing the password only once, it is not secure.
  • If you aren’t using a random salt, it is not secure.
  • If the database has a simple password or none at all, it is not secure.
  • If the database is exposed online, it is not secure.

There are so many things to think about here that you can’t rely on your customer to ask for them all. And if they do ask for security, they may be asking for the wrong things. For example, customers will ask to make sure that users can’t use the same password twice before they ask if you’re hashing the user’s password. What’s really more important? You need to help that customer make the right decision.

A customer is not going to know that encrypting a password is not the same as hashing it. If they do, will they know that you should hash the password multiple times? Will they know that you need to supply a random salt each time? Will they know which hashing algorithm to use?

No, they won’t. And they shouldn’t have to know these things. 

It’s up to you, the software professional to make sure that software security is baked in from the beginning. It’s up to you to make sure that software security is constantly evaluated to ensure you stay on top of the latest hacks, hashing methodologies and more. It’s up to you to test for security.

Have you tried a SQL injection attack against your own system? Have you run your database of passwords through a rainbow table to see if you can hack your own data? Have you tried to access your database through unconventional means?

So, I challenge you to read some good articles on password security. Write some example code. Create a database on an AWS server, populate it with some test passwords. Then try to steal your own data. Then pretend that you did steal your user table and see if you can reverse engineer the passwords. 

Create a sample login screen. Spam that login screen. Try to push SQL through it. Send a hashed password through it. Write a script to try to guess usernames and passwords. Improve your login screen with bot filters, Captcha, and SQL injection protection.

Take this time to have a little fun and build some security libraries. Then you will have what you need for new projects and upgrades to older products.

Remember, software security is not an option … in today’s environment, it is required.

Unit Testing Your Code (aka Test-Driven Development)

Leave a reply

A few years ago, I scheduled a meeting with the software engineers on my team to introduce them to Test-Driven Development (TDD).

I had started reading the book “How Google Tests Software” and I felt I had to share what I was learning. I started a book study with the team.

The first thing I wanted to focus on was unit tests. This was a completely new concept to the team and to me. I looked around online and found some good tutorials and a video from a teenage developer who was showing other engineers how to write their first unit test.

I built a Google slide presentation and walked through it with the team.

One of the first slides focused on the reasons (excuses) why engineers don’t write unit tests:

  • It’s too late to start
  • It’s too much work
  • It has to be maintained
  • It slows down real development

For each of these reasons, I added a translation into what it really meant:

  • I don’t know where to start.
  • This looks scary. Am I a tester or a developer?
  • I don’t want to maintain this code, too!
  • I have deadlines for real features!

My goal was to head-off the concerns early. I put myself in their shoes, thinking about what it would mean to add unit tests to my code. One thing that really hit home with me was “I don’t know where to start.”

I encouraged the team to start writing unit tests. I showed them the video of the teenager writing them. I called him “Kid Coder” and I told the team — “If Kid Coder can do it, you can, too!”

It worked, the team started writing unit tests. Most never got to the point of actual test-driven development where the tests are written first followed by the code. But we now have thousands of unit tests to go with our many projects.

The second half of my presentation — which we covered on another day — focused on the role of software engineer in test (SET). I wanted to train them on this concept because one of our next steps was to hire an SET and to set up a build server which could also run our unit tests.

It wasn’t long before we hired our first SET and set up a Jenkins server. Not only do we now automate unit tests, we’ve also automated our builds, our code style checks and more. We spawn test nodes in the cloud when we are testing certain projects and more.

It’s come a long way since that first presentation.

Now, I don’t write code too often. My team discourages it! 🙂 And I have other things to do. But I have a few side projects — some for business and some for personal use. I have a lot of code to support web projects. I write in Perl — and I’ve gotten pretty good at it

Can you guess the one thing that I had never done? You got it — I had never written a single unit test.

What a hypocrite. What had been blocking me? I didn’t know where to start.

This weekend, though, that changed. I did some research on Saturday and before I knew it I had five unit tests. Then I had eight. It’s Sunday and I’m up to 71 unit tests.

Writing the unit tests wasn’t all that hard. The hard part was fixing all the bugs I found!

Yup, I found multiple math errors, poor error-handling, incorrect date formatting and some bad regex that just didn’t work.

It’s amazing. I’m converted and I can’t imagine writing code in the future without writing my unit tests.

Setting MySQL to Load on Startup (Mac OS X 10.10)

Leave a reply

It used to be that you could easily set up MySQL to load at startup using a MySQL plugin on system preferences. Unfortunately, Apple killed support for this in recent versions of OS X. So, you must set this up using a more Unix-like setting with launch daemon (launchd).

Here are the instructions for setting that up.

First, create a plist file at the following location. I’m using the vi editor because it’s easy.

sudo vi /Library/LaunchDaemons/com.mysql.mysqld.plist

Then fill it with the following XML.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Disabled</key>
    <false/>
    <key>GroupName</key>
    <string>_mysql</string>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>com.mysql.mysqld</string>
    <key>Program</key>
    <string>/usr/local/mysql/bin/mysqld</string>
    <key>ProgramArguments</key>
    <array>
        <string>--user=_mysql</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>Umask</key>
    <integer>7</integer>
    <key>UserName</key>
    <string>_mysql</string>
    <key>WorkingDirectory</key>
    <string>INSTALL_PATH/mysql</string>
</dict>
</plist>

Then an adjust the permission:

sudo chown root /Library/LaunchDaemons/com.mysql.mysqld.plist
sudo chgrp wheel /Library/LaunchDaemons/com.mysql.mysqld.plist
sudo chmod 644 /Library/LaunchDaemons/com.mysql.mysqld.plist

Setting up Git Pulls in Crontab

Leave a reply

I have a small application that reads Git data and processes developer contributions based on lines of code (inserts + deletes), files edited and the number of commits each month. I wanted to automate the Git pull command so that this application would stay up to date without me having to manually run a command-line script.

My first thought was to schedule it in cron so that I didn’t have to worry about it. This is running on my development laptop — at least for now — and I knew that if I ran the “git pull” command under my username, I shouldn’t have any issues.

However, that was not the case. Every time the script was run from cron, it failed with a permission error. Running the same script by invoking it from the command line, however, executed without an issue.

But what was the permission error? Was it that Git could not be invoked? After some serious searching through Google and Stack Overflow, I determined that it was likely an SSH problem. Stack Overflow is filled with comments about using Git hooks and setting up a “bare” repository, etc. That was a lot more complicated and I resolved to just run it by hand.

A day later, though, I discussed this with one our senior developers — who has a much deeper understanding of Git. He agreed that this was an SSH issue. Together, we determined my script — when run from cron — did not have the rights to access my RSA key file, which is how I access my Git server (not GitHub).

So, we created a new RSA key just for this process using ssh-keygen and storing it in a specific directory. The key to this was to hit the enter key each time ssh-keygen asked for a password. This allows the script to pull the repos unattended.

ssh-keygen -f .git-ssh/id_rsa

Once my public key id_rsa.pub was copied to the Git server, I was then able to modify the pull command in my script to force it use the new ssh key.

ssh-agent bash -c 'ssh-add /Users/username/.git-ssh/id_rsa; git pull'

This was about a five minute process and it works perfectly.

My crontab entry looks like this:

0 9-16 * * 1-5 /Users/username/scripts/update-repos.pl  > /path/to/logs/git-perl-pull.txt 2>&1

This will run between 9am and 4pm Monday through Friday.

MySQL Time Zone on OS X Mavericks

Leave a reply

Setting up the time zone table on your MySQL instance on OS X shouldn’t be this hard, but it is. Normally, you do this with the following simple command and you’re done, but not on OS X.

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

The first problem you’ll encounter is that mysql_tzinfo_to_sql is not accessible from the command line. You either have to walk the path to its location and prepend the command with a dot or you have to reference the full path before the command (sans the dot).

The second problem you’ll encounter is that there are multiple errors in the time zone files, which will prevent the data from loading. I found a few options for dealing with this, but the easiest — by far — was to tell MySQL to force-load the files that worked and skip those that didn’t.

Here is the working command on my Mac.

/usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p --force mysql

MySQL & Perl on OS X Mavericks

Leave a reply

After upgrading to Mavericks, my local development environment stopped working — more specifically, Perl would no longer talk to MySQL.

Recently, I decided to figure it out.

I was getting the following error from a Perl script that was trying to talk to my database. The database was there, it was accessible from the command line, and I verified that my Perl DBI libraries were installed.

install_driver(mysql) failed: Can't load '/Library/Perl/5.16/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Library/Perl/5.16/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle, 1): Library not loaded: libmysqlclient.18.dylib
  Referenced from: /Library/Perl/5.16/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle
  Reason: image not found at /System/Library/Perl/5.16/darwin-thread-multi-2level/DynaLoader.pm line 194.
 at (eval 21) line 3.

After some searching, I realized that Perl was trying to load MySQL, but from the wrong location. Perl expected the libmysqlclient.dylib to live at /usr/lib but Mavericks had installed it at /usr/local.

So, I created a symlink to redirect Perl to the right location.

sudo ln -s /usr/local/mysql-5.6.17-osx10.7-x86_64/lib/libmysqlclient.18.dylib /usr/lib/libmysqlclient.18.dylib

It should be noted that libmysqlclient.dylib will contain version information in the filename and Perl will expect it there. Your version is likely different than mine, so be sure to update it as needed. If you’re wondering, what version Perl is looking for, read your error message and that will tell you.

Requisite First Post

Leave a reply

Hi folks, this is the requisite first post of a new blog to tell you what to expect.

The reality is that you can expect anything: Personal Notes, Technical Documentation, Mobile Rants, Technology Reviews, Journalism Missives, or anything else I have in mind at the time. I decided to set up this blog so that I can talk — at length (i.e. not Twitter shortness) — about topics of import to me and perhaps others.

I’ve tried focused blogs in the past, but I keep abandoning them because I want to talk about other subjects. My goal is to blog more often based on things I read. That means I need an open blog with no forced subject matter. It’s going to be wide open.

Who am I? Well, you can read more about me in my resume or the summary page I created on my web site, but here’s a quick synopsis. I am a former newspaper journalist turned technologist turned software development manager. I’ve worked in print, online and mobile. I’m now managing software teams building cash automation tools. I’m a father, a husband, a brother, a son, a Christian, a Democrat and more.

As a crime reporter, I’ve borne witness to people who died in car wrecks, shootings and by lethal injection. As a son, I was at my mother’s side, holding her hand when she passed away from lung cancer. I’ve interviewed killers by phone, in person and in prison. I’ve travelled near and far to investigate the motives of those who killed. I’ve angered federal judges, pissed off local and state cops, and been threatened by a state judge, a doctor and local government officials.

I’ve also managed the development, deployment and maintenance of more than 400 mobile products for about 200 customers. Everything from J2ME apps for flip phones to iOS apps for iPhone and iPad to Android, Kindle and mobile web apps. I conducted the first live stream to mobile for a local TV station in the US. You could’ve watched that last one on your BlackBerry or Treo in 2007.

That’s enough for now. I hope you enjoy the blog.

Tom Rouillard