In October of 2001, I was contacted by a job search firm to write an article on my experiences and thoughts as a software engineer for their website clients. I don't know if the article was ever published, but find it interesting to periodically re-read my thoughts. They seem appropriate as a footnote to this discussion, so I include them for anyone who may be interested.
Job Description (2-3 line job description)
I design and build end user business software applications in both client-server and web based environments. I am currently involved in working on internet ecommerce reservations and bookings systems for airlines, hotels, car rental companies, and large travel agencies.
Pertinent Skills (Skills you use everyday on the job)
Java, Object Oriented Analysis and Design, UML, HTML, SQL, RDBMS, JavaBeans, JavaScript, JSP, JRun, XML/XHTML.
Previous Experience
Project Manager, Project Leader, Senior Programmer/Analyst, Director of Production and Shipping for systems software company. Also real estate investment and mortgage brokerage, tax and estate planning, over 30 years in karate with 8th degree black belt.
Education (Where you went for school, including degree)
1972 B.S. Physics, Eastern Illinois University, Charleston, Illinois, USA.
In your opinion, what qualities are the most important to ensure success in your field? (What traits allow you to perform well on the job, ie. creativity, organization)
You must be able to organize scrambled business logic into a cohesive and easily maintainable code base. You have to be able to focus and have a love of solving problems. You can't be afraid to scrap a process and try another approach. You have to want to learn new things and to study and read about your profession off hours: software engineering is not a 9 to 5 carefree job. What you do is the lifeblood of a company's execution of its financial and accounting plan: you need to be able to appreciate this as a responsibility and not just a job.
What advice would you give to a student who is interested in pursuing a career in your field?
Get a book on the language of choice. Today that is Java. You will have to learn (through a book or by taking a course in) Object Oriented Analysis and Design (OOAD) as well. Then, think up a project. If you are interested in web based technology, then you will have to learn html, http, servlets and some jsp as well. Then design and build your project. If you get bored, or have to give it up for a few days to get a fresh start: forget software engineering. A software engineer is paid to go to work each day and figure out how to do stuff they don't already know how to do. That's got to be fun for you, or you should find something else to do. Admittedly, there are days when I question my sanity as to what I do, and start practicing, "…would you like fries with that?".
Describe your typical day on the job, from start to finish. (Include hours worked and lunch and breakdown of breaks)
I am generally in the office between 7:30am - 8:00am. I'd be in earlier, but I have a commute that can run from 1 to 2 hours depending on traffic. I do not do well getting up early in the morning; I am a "night person". So that's the best I can do for now. Coffee is first up. I do nothing before my coffee. I then review my notes from the previous day to recall where I left off, and review my calendar to see how to plan my day, i.e. if I have any progress report meetings to prepare for, project sizing estimates to complete, or a code release that is due.
Generally, I have a business problem that I am trying to solve and I need to either write the code for it or rework someone else's code. For example: What information do I need to have to make sure that in an airline reservation system requirements gathering screen I can make a booking for the customer? And when that customer types in their departure and return dates, what checking do I need to do to make sure that these are done legally? Is the departure date request either for today or after today but less then some max number of days in the future? Is the return date request before or after the departure date, and if it is before the departure date is it a date in the next year within the valid max number of days? And if any of this is wrong, how do I trap for these errors? And how do I inform the user of the problem so that they can change their request?
Generally, projects are worked on in a group so periodically during the day team members will interact with each other to make sure everyone is on the same path. Sometimes, a formal meeting with a structured agenda is necessary. This is particularly the case as a major milestone deadline or delivery/release date draw near. The better you are at being able to not only express yourself in these types of meetings but to also condense your thoughts to specific relevant points the more your input will be appreciated. There is nothing worse than being in a meeting where one of the members is either unprepared or rambles on.
Commercial software development is a fast paced environment. In many places this is because the management pushes you to get your work done. This can be a little tiring for the more experienced engineers as this is not considered motivating. The work that we do is very difficult and challenging, but we do it because we enjoy it. The end result of this is that a good engineer works at peak performance all the time because they enjoy it- not because they are told to do it. This is probably the first thing you have to grasp as you enter the software engineering work force: you are expected to do the work in a self directed manner without being prodded by your project manager to do so. Senior engineers can not count on someone who needs to be constantly motivated- we simply do not have the time or desire to. As a result, a person like this will not get good performance reviews. And this translates directly to salary.
I personally very rarely go out for lunch. I usually bring lunch with me as every office I have worked in has a refrigerator, microwave, etc. I eat at my desk so that I can continue to work. Since I enjoy what I am doing, anyway, I don't mind this at all. Every now and then I get frustrated with my inability to solve an issue as quickly as I'd like to and then I do get out of the office for lunch. Sometimes even in the middle of the day I'll just walk out of the building and find a dry patch of grass to park on while I clear my head. Software engineering requires you to be creative and you can't be creative when you are either frustrated, tired, or sick.
Not only due to my commute, but also just because it is my personal desire to be home with my family for dinner at a reasonable hour, I try to wrap things up by 5:00pm. Sometimes this is not possible. I have been on projects where I have never left and just slept on the floor. If I am involved in a particularly interesting or challenging issue, I will talk it through to myself in the car on the ride home, or work on code segments at home at night or on the weekend. Most of the time I do this because I want to, but sometimes you just have to do it because it's the only way the work will get done. But that goes with the job.
Software engineering is a lot of fun and you do have a tendency to become all-encompassed by the challenges of the work. I learned long ago that you have to have balance in your life and that working 10 or 12 hour days for weeks on end not only drains you physically (regardless of your age), but it impacts on your creative ability. Then the work isn't so much fun. I have been doing this a long time and hope to continue to do so. I want to keep it fun. I want to continue to get up in the morning looking forward to the work ahead. I keep the work hours on a weekly basis reasonable.
Having said this, it is critical that I conduct my day in as organized a manner as possible so that I maximize my efforts. Just as I survey the day's work ahead when I get into the office, I try to build in a half hour or so at the end of the day to wind things down and set the stage, so-to-speak, for the next day. I usually have several things I am working on at a time, and so the ability to prioritize and schedule is critical. In past jobs, I have seen unorganized engineers working needless hours on a project simply because they lose sight of the big picture and flounder from task to task.
As part of this wind down process at the end of the day, I generally try to clean the day's clutter from my desk before I leave. This clutter is a synopsis of the work I have done and am continuing to work on. This gives me an opportunity to review what I have done and what I will need to do the next day. More often than not, going through this process reveals solutions to what I have been working on because I am looking over the day's work as a totality.
Besides, leaving clutter to accumulate into heaps, organized or not, implies unfinished work. As that mounts, so does my frustration at "all the work", regardless of actual progress being made. To avoid this, I "clear the deck" before I head out at the end of the day. I leave with a sense of accomplishment- even if that accomplishment has only been to clean up the junk. At least it's something. Sometimes a software engineering effort can go on for literally weeks before a feeling of accomplishment can be had. I admit to needing a daily sense of accomplishment. If nothing else, leaving my desk neat and ordered gives me that sense of accomplishment.
What do you enjoy most about your current job?
For me, the process of analyzing, structuring, and writing code that solves a particular business issue is really satisfying. In my current job, I have an opportunity of expanding my experience into a new arena, that of automated reservations and bookings systems. This if very appealing and interesting for me.
As you know, there are actually two types of software engineering: systems and applications. The two are quite different and require different types of skills, and different personalities. About 15 years ago I made a conscience decision to work in the applications area vs. systems development. I enjoy solving business related problems vs. technology related problems. The technology is a tool that I use to craft my business solutions. For me figuring out network routing algorithms or writing compilers or xml parsers is not as interesting as building a business user application. But that's just me. I have friends who write protocol software that would go nuts trying to deal with writing end user applications with clients suggesting that the background color of an input screen needs to be "…just a little greener…", or that they want a change added to complex business logic at the last minute prior to a major release. Oh well. Whatever floats your boat, I guess!
Oh, the other thing I like about my job is that I get paid really well to use my brain instead of my body; I'm just not built to be on a jackhammer all day, or drive a delivery truck, or climb around on scaffolding. I am quite happy banging "the boards" for a living. Statistics show that something like 78% of workers either do not like their jobs or are unhappy in them. I feel fortunate that I am able to enjoy what I do. This makes me good at what I do and gives me the motivation to continue to get better. As the famous CEO of Viacom, Sumner Redstone said, "If you enjoy what you do for work, then you're a very lucky guy." I'm a very lucky guy. But I had to work hard to make that luck stick.
Back to Thoughts On Technology Page | Back to Peter's Home Page | Back to Family Home Page