06.01.07
Posted in Dorks, Dweebs, Geeks, Programming, Funny, Work, General at 9:34 pm by gatormha
Have you ever met a programmer? Do you wonder what a programmer might be like in real life? Would you know how to communicate with him? This guide will classify programmers into their three distinctly unique groups and provide detail into how these different types of programmers go about their daily lives.
The Dork
The dork is, by far, the most common type of programmer. The dork will seem to the untrained eye a normal, albeit oddly dressed, member of society. Dorks can be spotted in many common places such as the grocery store, the barber shop, the movie theater, or popular restaurants, but will most often seem uncomfortably out of place as he would much rather be in front of a computer screen leveling his 4th gnome warlock.
Communication with dorks, though taxing, can be facilitated by surrounding yourself with expensive computer equipment, carrying World of Warcraft installation discs on your person, or starting the conversation with the following question, “As a feral druid, would it be wiser for me to dual wield or to carry a two handed weapon?”
WARNING: Touching a dork’s computer without invitation, insulting his PvP abilities, or refusing to believe his story about his online girlfriend who is a model in Iowa
can result in the dork becoming violent, flailing his arms about wildly, and accompanying this with high-pitched shrieks and wails.
The Geek Who Doesn’t Want to Be a Geek
This is the second most common type of programmer, though he is significantly rarer than the previously mentioned dork. He is rarely spotted in public, though can be easily differentiated from normal people by his distinct lack of taste in clothing and hair style and by his pasty white skin. This type of programmer will go to great lengths to hide the fact that he just used Dijkstra’s Algorithm to determine the quickest path to the grocery store through traffic, but generally fails miserably to deceive anyone.
WARNING: Be gentle with these individuals. The soft glow of his several monitors provides just enough sunlight to prevent complete vitamin D deficiency, but his weakened bone structures can be damaged from even slight contact. Additionally, he will own you in Unreal Tournament.
The Geek Who Know’s He’s a Geek — And Loves It
This is the rarest — and most dangerous — form of programmer. He is well aware of his physical shortcomings, but thrives on developing new software modules for obscure programming languages. He is often known on the internet by a moniker that he will often respond to in real life. He often has an army of computers at his disposal, and he could tell you all about his most recent achievements in person, but would rather IM you the link to his wiki page where his life is detailed by the minute.
The only time this type of programmer is spotted is during his rare sustenance excursions when he travels to the nearest grocery or convenience store to replenish his supply of Cheetos, Tab, and Mountain Dew. Any human contact is often responded to with loud hisses and scratching.
WARNING: This individual is a master in all forms of online combat. He has killed you in Battlefield 2 about a dozen times and has probably managed to do the same to most members of your extended family. Any attempt to subdue this individual on the internet will become violent — programmatically speaking, of course.
I sincerely hope this guide has enlightened you to the different types of code monkeys you might encounter during your day-to-day life. Memorizing the aspects of each class might save your life some day.
Permalink
05.31.07
Posted in Programming, Sad, Depressing, Visual Basic, VB6, Funny, Work, General at 9:31 pm by gatormha
I learned everything I need to know about my job in the first week I was there.
When I graduated college, I thought that my days of carefree and reckless abandon were over. I had started a career with a respectable, billion-dollar publicly traded software company in the midwest. I was no longer a poor college student, I was a “Software Developer”! I had a job description, roles, and responsibilities; I had to go to meetings, meet deadlines, and make money; but most importantly, I had to develop software.
Some of my key responsibilities included:
- Working with Solution Designers (Business Analysts) to define and clarify software requirements,
- Creating (and having reviewed) technical design documents consisting of well defined database diagrams, solid class definitions using object-oriented design principles, and well defined and structured database designs,
- Writing elegant, maintainable, well documented code,
- Reviewing the code of my peers in order to improve said elegance and maintainability as well as to learn and share new coding tips and best-practices.
I used to read The Daily WTF and laugh thinking, “Nobody could ever program so poorly!” As far as I knew, all IT departments ran as smoothly as the one I was at. Like a well-oiled software writing machine.
After almost two years of this near utopia for software developers I felt my needs were no longer being met by my employer, and I decided to move on to greener pastures. I decided to find a new job.
The search was quick! I found a seemingly solid job in South Florida with a respectable, billion-dollar publicly traded construction company. I was no longer going to be a complacent software engineer from the midwest! I was going to be a VB (not yet known to me 6) programmer! I didn’t blink an eye at the difference in title. I assumed my responsibilities would be similar and my new work environment would at least be comparable to my previous one. I expected to continue being a naive software developer. But as I soon found out, my days of reckless abandon were just beginning!
One of my first jobs was to begin fixing defects for an application that nobody on my team of 3 programmers understood or had even looked at for more than 10 or 15 minutes before blowing off. The customers needed bug fixes and bug fixes I was going to give them! The programmer who originally wrote the application still worked for the company, but in another capacity at another location. I tried to call, but got no answer. I sent an email and got a nearly immediate, single syllable response that didn’t even come remotely close to answering the myriad of questions I asked. Maybe he just got back to his desk.
Another phone call — answering machine. Was he ignoring my calls?
Out of pure desperation, I sent another email thinking he was very busy and just didn’t have time to respond. I made sure to make it perfectly clear he could get back to me whenever it was convenient for him. Another immediate, monosyllabic response.
Definitely ignoring my calls.
After nearly a dozen back and forth emails like the first two, I felt I had dragged enough information out of him to begin looking into the defects I had set my sights on. I opened the code.
It was at this point, I learned the difference between being a developer and being a programmer. No longer did I have the key responsibilities I mentioned above, the responsibilities of a programmer are much different:
- Don’t even think about trying to get requirements! Even if someone tells you what an application needs to do, it’s almost guaranteed to be different tomorrow. And again the day after.
- Technical design documents are for cowards. So is testing. The only way to find out if something will work is to do it and get it into production! Most designs I have anymore consist of poorly scribbled, incoherent circles and boxes on the back of a notebook that even I don’t understand anymore. Any text is probably the phone number to a restaurant or what my coworkers want for lunch.
- Writing maintainable code is the quickest way to get yourself fired! If you write code that only you can understand, you’re guaranteed to have a job — at least until they rewrite your application (which is probably never). And documenting is just going to set up your replacement to succeed! He took your job, why the hell should he succeed?! You know what the code does, why would you need to waste your time writing useless filth like comments or user manuals? They pay you to code!
- Code reviews at my work are kind of like the unwritten rule in a men’s locker room. You just don’t look. I don’t want to see yours, you don’t want to see mine, let’s just keep our eyes above the neck.
Now don’t get me wrong, I like my job. Nowhere have I had the freedom to do what I want, when I want, how I want, where I want like this place. The only thing is that everyone I work with has the same freedoms. Everything I do, the guy next to me does 10 times worse. And chances are, I’ll be the one maintaining his code in a year.
Permalink
05.29.07
Posted in Visual Basic, VB6, Work, Funny at 6:54 pm by gatormha
As a software developer, I’m often faced with the daunting task of “dealing with customers.” At my job, “customers” are usually those who work in my office for my company in another department. Because we work for the same company, these “customers” believe they can treat me either as
- a moron, or
- the guy who caused all their problems.
A typical conversation with a “customer” starts as follows:
<phone rings — I pick up>
Me: This is Matt…
Customer: <fuming with anger> The app is broken AGAIN! Why can’t we get all these bugs fixed?!
Me: OK, slow down, what app are we talking about?
Customer: It’s the app that <insert name of developer who was fired before I started (and probably for good reasons)> wrote.
From there, things go downhill. It turns out that said previously-employed-by-my-company developer wrote a critical financial application that isn’t working anymore. After a little more interrogation, it also turns out that this application hasn’t been working for nearly 4 months, but everyone in the customer’s department neglected to tell IT about it, all the while becoming daily more incensed at the manual workarounds required to do the work the broken application used to do. I also learn that because this is a critical piece of financial software, it needs to be fixed right now.
Now I try to calm the customer — who I can tell is wringing his hands nervously, worrying about what his boss will say when whatever it is you business people do isn’t done on time — by telling him that I will investigate the issue, but because said unemployed developer isn’t working with our company any longer, it may take some time for me to pinpoint the issue, but I’ll keep him posted of any major developments. This is hardly ever enough to please a customer. For some reason, customers feel that IT should have a magic wand that will instantly diagnose and solve any number of issues relating to hardware, software, network problems, or general user error.
Now, I get to the fun part — DEBUGGING SOMEONE ELSE’S CODE! I don’t know if you’ve ever tried to read a bad programmer’s code before, but it’s like trying to decipher the Da Vinci code while someone is pouring bleach into your eyeballs. The fact that the application is written in VB6 only exacerbates the problem.
After about 3 hours of stepping through countless GoTo statements and decompiling DLLs only to find out they return CONSTANTS (yes, I actually had to decompile since our no-longer-employed programmer friend believed in not checking code into any sort of source control system), I track the issue down to a hard coded server IP address that is no longer pointing to the correct database. I’m tempted to start rewriting the entire program so the next unlucky soul won’t have to live through what I did, but I put it off for another day to save time and get the application fixed for our endlessly patient customer who only called me 17 times during my ordeal.
I get the new EXE built and deployed on the 12 different terminal servers my customer’s subordinates use, and I call my customer to proclaim proudly that his super urgent need has been met and the critical financial application is ready to be used! Just as my excitement is peaking at the thought of fixing a problem and getting a “win” under my belt, my customer lets me know that he had his people go ahead and do the manual work around this time, but he’ll be sure to let me know if they have any problems the next time they run it — at the end of the NEXT fiscal year. Massive disappointment abounds.
They should let programmers drink at work.
Permalink
