WanTii, Inc. Tech Blog

So I decided to start blogging… Why not? It’s only been about 5 years since blogging has became cool. My goal is really to help people with issues that I come across while I am working. I have had some success as a software engineer, but that has less to do with my specific knowledge of advanced technology and more to do with some really good troubleshooting skills. To write software, it does not take a CS degree or thousands of dollars of training, it takes the ability to understand and absorb what you read. Most reference documentation is written by other programmers who would much rather skip the documentation step. This is often apparent just by reading the docs. This is not meant as a complaint or insult, but the hardest step to hurdle for most mortals is wading through the documentation that often only presents more examples of code that the reader is already having problems understanding.

A little about myself. I started my IT career thinking that I would be a Systems or Network Administrator for life. I worked first at a start-up ISP, after that I moved around a bit, teaching at a community college and maintaining their servers, network and PCs. Eventually I took a Systems Administrator position at a very large Internet company. I am not sure if I can give you the name, but suffice it to say that if I did, everyone has heard of them and most likely used one or more of their services at some point.

Along the way, I had picked up some programming skills. While maintaining the campus network, I learned that it was much easier to automated tasks so that things remained uniform and organized. I was teaching a full-time schedule and there were hundreds of PCs and seven to ten mission-critical servers. My help usually came from students working in the labs. The need for automation became apparent at the start of every quarter. A long line would form ending at the desk of the Lab Assistant. His job was to create a network login and email address for each student in the line and give them the appropriate information. This seemed a bit unnecessary since the status of the student was available in the student management database, and everything the Lab Assistant needed to create the logins was available as well.

I had recently spent some time learning Perl for a course I was planning to teach and it seemed like a good opportunity to exercise my new skills. A bunch of hacking later, and my first real program was born. Previously, I had automated administrative tasks using shell scripts for backups and routine maintenance, but to me, this was the first real program I had ever written. Once I was finished and my application was up and running, I was hooked on programming. A strong knowledge of system administration helped me to understand the protocols I was working with and Perl is a useful language for beginners (that is of course if you are able to wrap your mind around some of Perl’s features).

When I left the college, I was moving up to a much larger company with many of the traditional practices and values of a large IT company. I was left in charge of monitoring the software that the developers were writing for fulfillment of one of our products. I was brought in because the product had many external dependencies which left it a bit fragile. The other administrator/analysts on my team would watch log files and go to meetings to discuss performance and gather information on what the processing output should be. Since most of these processes were written in Perl, I took it a step further and read the code. Quickly I was up to speed and began providing valuable input to the developers.

At the same time, my knowledge of Unix (which is meant to mean to refer to the generic unix-like platform including Linux, *BSD, Solaris and just about everything else) began to stand out. This was a point in time where Unix platforms were not particularly popular, so it was a useful skill. Most of the developers were familiar with their work and appreciated my input on both the system where their software would run and the knowledge of the system they were contributing to.

Six months after I was hired, the architect for the developer team asked me why I was not a developer. It was a hard question to answer. I had never had the title of Software Engineer and really had not taken the step because I was worried about starting at the bottom of the totem pole when I had gained so much good karma in my current line of work. The architect, who I consider to be a great friend and valuable resource, talked things over with his director and found that he had thought the same thing about moving me onto the development team. Next thing I knew, I was approached by a Technical Manager in the development department and offered a position on his team.

I was excited and nervous, I felt like I had just graduated to something better. My biggest concern was that the team I was on developed mostly web-based tools using Java/JSP. When you write Perl code, Java often seems like a lot of extra work. Even to this day, I can often whip out one-liners on the command-line that would require multiple jar-files and a month or more of development time if I were using Java. In my next installment though, I will discuss why I stick to Java.

I spent the majority of my career at this company on this development team. I learned a lot and gained experience that only comes from working on systems that are expected to process thousands of requests per minute. I eventually left that company to move back to my home town and help out with the family business. Outside of my day job I still write software. Most of the people in my home town that know me know that I am an experienced developer and ask for help. To organize and manage these tasks, I created a small corporation that provides custom development services. I would love to say at this point that I am wildly successful with this business, but I really spend most of my time concentrating on my day job and program because I enjoy it and I can’t turn down a friend in need.

To be a good programmer, there are many skills that have helped me along the way. The most important skill is to be able to read technical material and apply it. This may seem like an obvious thing, but it is not as easy as it sounds. There are so many good technologies available to developers that are often overlooked because no one on the team is ready to use something new. To create the best solution for your customers, you will have to know all of your available options. In many cases, knowing your options will likely mean that you have to wade through partially completed online manuals, man pages, or even piece things together on your own. There are a few instances in my career where my persistent urge to learn has benefited both myself and the companies where I worked. The biggest is learning Linux. While I worked at the community college, I was able to create an email server running on a Pentium 133 with 32 Megabytes of RAM. This server services over 2,000 users and also ran a web-based email application so that users could read their email off-site. I built this system with spare parts and saved quite a bit of money on both hardware and software licensing. My replacement eventually replaced that server with an MS Exchange farm. She was pretty excited to get the budget to do so, and we were talking about it right before she was going to roll it out. I was amazed at how much money the project would cost. The cost savings of running Linux as a web server versus Solaris is substantial as well (in my experience). There are other examples, such as Tomcat versus WebLogic and Eclipse versus IntelliJ’s IDEA. Now, I do not mean to turn people away from commercial software. But, in many cases, the open source solution is viable. The point is, be willing to learn and apply. If you are active in learning some of the technologies that are difficult to learn, then you may find yourself saving a lot of money and getting pats on the back from your employer.

The next important skill is to be able to work on a team. I can’t say enough about being a team player. When it comes right down to it, your programming tasks will be your own, but you will need teammates at some point or another. I have met really smart people that were socially handicapped. It is unfortunate because in more than one case, very talented IT people have been fired because of what could be considered bad social skills. Your teammates and coworkers can help you get things done. Imagine having the next great idea, but being unable to assemble a team to help you implement it because your condescending attitude has driven all your associates away. Time to market is important and if you have to write every line of code yourself, it will take you three times as long as if you had a three person team. You do not have to like everyone you work with, but you have to work with everyone you work with. Just try to look for a person’s good qualities and in some cases be persistent with creating a relationship. I have picked up important allies in my life simply by giving people and a chance when other people didn’t. Most people who are highly productive, yet unable to get along with their coworkers generally feel that they are misunderstood. It does some good to try to understand those people and help them out whenever you can so that they will return the favor.

The last skill I will talk about is the ability to understand everyone’s needs. As an IT professional, you will become frustrated with a user’s perceived incompetence or a manager’s silly objective. You have to learn to deliver what is requested. There have been many times where I have been handed a request that I did not agree with. I would bring up an alternative that I felt might work better only to be shot down. At this point, many people lose their enthusiasm to complete the project. When it is completed, it can often become like a self-fulfilling prophecy. In one case, I watched an engineer suggest to management that an entire process be re-written because there were more bugs than what he was assigned. He was told to perform the tasks he was given and that a rewrite would come later. The programmer was upset with this answer, but began working anyways. He complained the whole time he was working and ended up missing his deadline. He ended up being right about the stability of the process, but much of the blame fell on his shoulders afterwards. It was a bad situation because this was part of a big project that had high expectations and I think his bad attitude created much more tension than necessary. Not to mention the time that was wasted by all the complaining. Although programming gives you the freedom to be creative, it is still a job. When given a task, strive to do what’s expected, not what you think is best. As you get experience and karma, your opinions will be treated with more and more respect over time.

If you have read all of the above and were expecting something monumental, then I apologize. The purpose of this blog is to create a resource for people who use the same technologies that I use. This entry is meant to help readers understand some of the assumptions I might make and hopefully give readers insight into my habits. Thanks for reading!