I. Michael’s Immutable Law of Software Requirements

Users always perform the same process to the same data every time…except when they don’t.

II. Michael’s Law of Vocabulary Variance

Words like “required” seem to have a different meaning to a developer (“always must exist”) than to a user (“it must exist, unless I don’t feel like it”). Also “optional” also seems to mean “required”; unless, of course, if it doesn’t.

III. Michael’s Law of Feature Longevity

The feature that is a “must have” and is the hardest to code will be the feature that will be reversed in six months. See Laws I and II.

IV. Michael’s Law of Prioritization

Every feature or request is absolutely the highest priority, even if the requests are from the same person and there’s only one programmer to implement them.  When pressed to prioritize which features/requests should be addressed first, the answer is “all of them”.   Apparently, having dual core processors on computers now means that a programmer can program multiple features simultaneously.

V. Michael’s Law of Project Accountability

The lateness in delivery of code for testing is directly proportional to the perceived failure of the project.  However, the length of time it languishes waiting for testing and signoff, even if greater than the lateness of code delivery, has no effect on the perceived failure of the project. In a word, it’s always the developer’s fault.

VI. Michael’s Law of Diminishing Returns

When joining a successful company or new group within a company, that company or group will immediately lose resources (budget, personnel, etc.) approximately one year after you join it.  And it only gets better from there!

I’ll continue to update these as I uncover more laws of software development.  This blog would not be possible without the pioneering work of Mr. Murphy and all who came after him.

First, a confession.  This topic is slightly self serving, in that in my new day job, I am now a programmer in the maintenance group.  In fact, my recent trials and tribulations at work made me really appreciate how hard maintenance programming really is and how the skills essential to maintenance programmers are a little different than a developer.

The Obligatory Star Trek Reference

Using Star Trek as an example, I see developers as the Starfleet Engineers who build the starship and the maintenance programmers as the Scotty’s of the world.  Think about it – Scotty is always enlisted to perform miracles to make the ship work because Kirk (the user) wants it to do something it was never designed to do or has messed it up so badly that it needs heavy duty maintenance.  And Scotty usually has to perform these feats of miraculous engineering under extreme time constraints or without key personnel or resources.  Sounds like the kind of day I had every day for the last week and a half!

Obviously, Star Trek is fictional because Scotty always gets the accolades and praise…when was the last time maintenance programmers got praised for working diligently to fix a problem?  Usually it’s, “That’s nice, now here is my list of another 20 things for you to fix…”

Skills Essential for a Maintenance Programmer

• Ability to Read and Decipher Someone Else’s Code – It goes without saying, that most of the time, maintenance programmers don’t actually write the code they have to support.  Nothing says you’re going to have a day of fun like digging into a steaming pile of…code.
• Ability to Be a Forensic Scientist – Not only do you have to be able to read the code, you have to figure out how it actually works in the REAL WORLD.  Developers rarely see their code live in the world and don’t have to worry about pesky details like when the database table is locked because one process is doing something while another is trying to update the same table.  You have to make friends with every kind of debugger/trace tool that you can lay your hands on so that you can do a little CSI work on the culprit (the problem).
• Ability to be Sherlock Holmes -  Hand in hand with the CSI work, you need to be able to logically deduce what is happening from the (hopefully) piles of evidence you have discovered.  Remembering that when you you have eliminated the impossible, whatever remains, however improbable, must be the solution,  goes a long way in maintenance programming.
• Dogged Persistence – You have to keep beating your head against the problem until either you win or the problem miraculously disappears.  This is where the rubber meets the road…you’re the one who has to get it working for the users.
• Being a Jack of All Trades -While it’s great to be an expert in a development language, once that code hits the real world, it is likely interacting with any number of other things out of your control (like it might have been in development) – like web services, networks, databases…you name it.  Knowing at least something about all of the elements of helps give you an appreciation for all of the possible areas to explore.
• Intuition – Sometimes intuition is the best tool for trying to figure out what is happening.  This is sort of an addendum to the previous skill.  When you’re grounded in a varied background, you begin to make connections and improve your  intuitive skills.
• Patience – You really need to have the patience of a saint to keep from going crazy.  Each roadblock that’s thrown up by the code or the production environment has to be either worked around or driven over.

The Stigma of Maintenance Programming

But let’s face it, maintenance programmers don’t get treated the same as developers.  Why?

• They are not perceived as being able to grasp new technology – Maintenance programmers may seem like they don’t “get” new technology, but I don’t think that’s universally the case.  In my limited stint as a maintenance programmer, I have to understand a wide variety of things – XML, web services, C#, Java, JavaScript, SQL Server, and mainframe JCL to support the applications.  Sure there’s old technology, but there’s a good chunk of new technology that I have to learn quickly.  And usually without the training that the developers got so they could figure out how to develop the system.
• Keeping things going is not as glamorous as building new stuff – This is universal it seems.  This happened at a previous employer. I’ve had co-workers and friends that never seemed to do well and weren’t looked on favorably by management because they went about the job of keeping things going silently and efficiently.  I know that some of peoples were on the list of people to be downsized because they weren’t producing new exciting work.  But they kept the business going.  If it were my business, I would have hired them without reservation because they were model workers.  Yet somehow, the idea of doing what’s needed to keep the business going is not as important as producing new things.  I don’t care how many new systems/products you develop, if you can’t execute on a day to day basis, it just doesn’t matter.
• They are not “real” programmers because they don’t create anything – That’s simply hogwash.  Maintenance programmers are usually the ones who have to extend/recreate/totally rewrite the original application when the business needs (or the user’s minds) change.  They are the ones usually stuck with refactoring – now that’s a REAL programming task.

What Can Be Done to Fix the Maintenance Programmer’s Lot?

In reality, probably nothing.  As a business culture, we only seem to care about the next new thing.  I realize that business can’t just stay focused on doing the same thing all the time, but if you don’t have stable, dependable systems, all the new development work in the world is not going to keep the business going.  So, here’s my wish list for what could be done to help maintenance programmers:

• Recognition for the important work that’s done – Sure, there might be some sort of celebration for a new project that was completed, but how about some sort of recognition for someone who finally fixed a long standing problem?  Came in in the middle of the night to get the jobs running?  Yes, I know it’s part of the job, but you know what?  So is delivering a project if you’re on the development team.  A little recognition would could go a long way.  It doesn’t have to be an elaborate thing: an email to the group praising someone’s efforts or a mention at a staff meeting. Although food is always good!
• Rotate developers and maintenance programmers through projects – I think it would be great if one maintenance programmer could join a specific development project, while one development programmer took a tour of duty as a maintenance programmer.  I think it would have very many positives – maintenance folk get in on the ground floor and get to build something , they get to see the struggles that developers have in trying to create something from nothing, and they may get a chance to pick up a new technology.  Developers get to see what it’s like to have to support code over the long haul and deal with the inevitable changes that occur as the software is let out in the wild.  This may help inform their development choices later…especially if they know they may have to support it at some time.
• Make sure that maintenance folk get the same training opportunities as developers – How many times have you seen this?  A new technology comes in and the people who are going to implement it get training.  Down the road, they move on or the system moves to the maintenance group…who now have to figure out how to support or even change this thing.  But there’s no training for the maintenance group because the company has already spent enough money training people…who are now completely consumed doing something else and have no time to help.  If it’s important in enough to train people to develop with a technology, it’s just as important to train the maintenance people!

So to all my fellow maintenance programmers out there:  keep the faith and keep doing what you’re doing to keep things running!

Why the silence?  You would think that while I was unemployed, I’d have a lot of time to write.  And that’s true.  But as the title of this blog implies, I was lost.  I couldn’t focus on anything.

Anatomy of My Unemployment

After the initial depression and rage of being involuntarily separated, I settled into a somewhat productive rhythm where I looked for jobs, did some programming on my project, and took care of my son over the summer and doing a lot of cooking.  And all was well…OK, all was at least not totally sucky.

Soon the summer faded into autumn and I still was no closer to employment than I was the day I was let go.   By September I had only had one interview.  But not many rejections…because a rejection letter would imply that you would actually receive a response.  And a job that I had previously applied for re-opened at a local company and I re-applied.

And…nothing.  I did get a second interview and was promised a response within a week….And nothing….three weeks of calls and email to company netted….an email that they wouldn’t be extending an offer.  I had other interviews and never heard another word from all but one of the companies. 

Autumn became winter and again, I had no more prospects than on the day I was escorted out.  And the winter weather drove me inside and one of my only outlets, running, was shut off.  And more emails and calls…and no response. 

And Then a Ray of Hope

Then an interview….and then a programming assessment test (that told me I wasn’t a great programmer), then a second interview and almost 7 months from the day I was involuntarily separated, I started a new job.

The Emotional Toll of Unemployment on My Psyche

Months of being ignored made me feel more and more worthless.  Each unreturned call or email was another chip out of  my confidence.   I could make no plans and had no plans.  I had no schedule other than getting my son up for school and being here when he finished.

And as a result, I couldn’t focus.  I’d sit in front of the computer to program or write…and…nothing.  I’d mess around on Facebook or play games or go play on the Wii.

 What I Learned from This Ordeal

• I (apparently) am a more structured person than I thought I was  – I’ve always thought I was more of a random person, but apparently I need structure.  I had no schedule or anything to frame my day. And I got nothing done.  Since returning to the nicely structured world of 9:00 – 5:00, I am able to get more accomplished in less time because I think I know I only have x minutes to do something, so I focus and do it.
• “I’m good enough, smart enough, and doggone it, people like me” – I guess I needed Stuart Smalley with me during the dark days of my unemployment.  In my new job, I’ve been able to jump in and be really useful – in fact, coming up with a solution for a problem that the vendor hadn’t figured out yet. Self confidence certainly takes a beating when you’re unemployed and it’s hard to remember that you are as good as you think you are.  See this excellent article by Pamela Slim.
• Working as part of a team sure beats the lone wolf approach – In my new position, I’m part of a group supporting a couple of systems and we are part of a bigger team supporting a whole line of systems.  And I like it!  Although we’re dealing with the challenge of coordinating changes and activities, it’s a refreshing change from having to do everything yourself!  For most of my career, I’ve been the only person working on a project or, in the case of my previous employer, the only IT person responsible for all of the systems.  Having a much smaller, focused scope of work is…refreshing.

Mike Has Found His Groove

I feel like I’m finally getting back in the groove.  I realized that despite being ignored, rejected, and told that I’m not a good programmer, I AM a decent programmer.  Maybe I’ll never build truly amazing, transformational software, but I’m a decent developer.  I have the desire and stubbornness to not give up on problems.  I may be a bit of a jack of all trades, but it continues to serve me well. 

So, I’m back and I’m getting back to development and blogging. 

I am geek, hear me roar!!!

I thought, “Hey, I can start running outside”.  So I laced up the sneakers and ran to the end of my street ( about 0.6 miles)… and felt like I was going to die.  For the next three days, I felt like my thighs were going to explode everytime I moved.

A couple of weeks later, I tried again.  This time, I got a real running plan and followed it.  It started slowly with more walking than running.  Each week, and later each run, increased the amount of running and decreased the amount of walking.  After eight weeks, there I was running for 30 minutes straight for the first time in my life.

So What Does This Have to Do With Software Development?
I’m in the middle of rewriting an application and trying to upgrade my skills all at the same time.  And my result to date has been much like my first attempt at running.  I think I can do it because I’ve done it before and I start hammering away…and then it doesn’t work and my head starts hurting from not seeing what I should be doing.  I’m trying to run before I’ve built up the mental muscles that support the understanding that I need to move forward.   What I need to do is to start walking and adding my running minutes gradually. 

Who Cares?  Why Is This Important?
I think one of the weaknesses of technical people (myself included) is that we don’t like to admit we don’t know something.  We’re often thrown into circumstances where we have to do something we’ve never done before.  And so we boldy go where we’ve never gone before….and get frustrated.  We may reach  the solution, but we feel like there has got to be a better way.   Sometimes we get lucky in the Google roulette and find a code snippet that will do most of what we need without ever having to think about it.  Sometimes, this is a good thing – especially if it’s for one esoteric feature that a user ABSOLUTELY has to have, but it’s not  part of the core of the application (like say, a routine for changing the colors of the graph reports).  But it’s very easy (and tempting for the sake of expediency) to throw together a whole application of disparate snips of code…and that is a recipe for disaster.

What we should be encouraged to do at our places of work or even on our own, is to embrace the beginner’s mind.  By beginner’s mind, I mean that stage where you go through the basic exercises and start to make the connections that enable you to figure out how to more and bigger things.  In beginner’s mind, you don’t necessary even know what you don’t know.  But you start slow and build the intellectual muscles that you need to start.  And you continue to build those muscles so that you can do more.

How Do You Begin the Journey of a Thousand Miles?
 With a single step, Grasshopper.  By that I mean start at the very beginning.  For me, I’m going back to the .Net books that I have that patiently walk you through the steps to building a .Net application.  No more skimming to find the section that I think will do what I need to do. I also will look at Microsoft’s tutorials online and also squeeze in some online training.  As I learn, I will start to apply each piece to my application, re-enforcing my learning.  To speed up, I have to slow down; move carefully through the preliminaries until I have mastered them.

Because running is just like software development – just because you have been doing for a while, it’s still never really easy – it just gets less painful.

Since I’m now looking, I’ve been think about my ideal job.  I’m imaging a place called Utopia Software Company.  Here are some of the elements of Utopia Software Company:

IT/Development  Work is Either THE Product of the Company or an Integral Part of the Company’s Products – In my previous IT jobs, IT was always viewed as, either a necessary evil or a black hole where money was poured with nothing coming out.  When the inevitable tough times would come, IT would be the first on the block.  In my first job, I watched IT get chopped in third. Recently, my IT department of three employees was reduced to one contractor.  The companies I worked for had lots of intelligent people working for them.  Companies where technology (not necessary computer/electronic) are key. You would think that if they could give IT at least some of the resources it needed that there would be a big return for the business.  But what IT got was usually the shaft.

Also, IT had little or no clout within the organization.  Trying to get things done that were needed for the IT organization to work better was damn near impossible.  No one wants to hear that we need a new air conditioning unit for the computer/server room or that we need this or that tool to do our job more efficiently.  And when trying to get the attention of management, if it had to do with IT, forget about it.  As friend of mine said, “You can’t spell shIT without IT!”.

That’s why I want to be part of an organization that either makes software or view software development and the systems as a key part of their business.  IT would not be considered a second rate department, but critical to the success of the company.  I would like to feel valued and supported.

An organization that ACTIVELY supports learning – One of my biggest frustrations with my corporate IT career has been the lack of opportunity for learning, particularly for classes.  I’ve been part of two corporations who SAY they value learning, but I have not seen it pan out.  I have rarely been able to take training I need just to be able to do my job, let alone learn any new skills.  It’s a good thing I can pick things up quickly, because that has been the way I’ve had to learn almost everything.  I did have one good manager who really let me take a number of courses to improve my skills – that was nearly 13 years ago.  I’ve had almost zip since. 

I want to be part of an organization that really encourages learning and gives people the time and resources needed to learn and continue to learn.  Allowing people to take web classes while trying to continue to do support work doesn’t cut it.  If I’m supposed to be learning something, I want to be learning it and concentrating on that. Not trying to learn a new database technology while supporting applications, correcting data entry errors, and fixing printers.

Pay and Compensation

I’ve worked for two companies whose view of pay and compensation couldn’t have been more different.  One paid people in proportion to their performance – the percentage of your raise was clearly tied to your performance that year.  The other company SAID they believed in performance based compensation. But if you worked your ass off or just did what was needed, you might get the same 3.5 %.  The one company expected alot out of you, but actually gave you something back.  Most managers at that company would give you time off if you had to do night or weekend support.  The other company wanted you to work even more than the former, but you were lucky to receive a pittance of an increase and no time off if you had to give up nights, weekends, or even holidays for support.

I want to work for a company that rewards their employees for a job well done with meaningful increases.  If the company expects a great deal of their employees, the employees should expect a great deal in return.  And night, weekend, and holiday support work should be compensated by either time or money. 

Room to Grow

In both my corporate jobs, there really was no place else for me to go.  In my first job, the only way up was into management and at the time, I wasn’t willing to make the sacrifices (move away from my family) to make that happen…I’m still not ready to make that sacrifice.  In my last job, there was, at least on paper, more technical levels for me to pursue, but I knew that no one would want to have someone of that level working in the plant…apparently they didn’t even want to have someone of my level working at the plant…but I digress…

I want a job where there is a technical and management ladder.  I was a pseudo manager for a while (all of the responsibility, none of the power), and I’m not sure I was real great at it then.  I’ve learned a lot since then (particularly what NOT to do) and think I have a better mindset for being a manager, but I still like technical things.  I’m not sure I’m ready to go into management, so I’d like a position where I could advance either technically or managerially.

In Search of Utopia Software Company…

Am I asking too much?  Does this company even exist?  In Central New York (state)?  That’s the kind of company that I would like to build some day, but for now, I’d like to just see on functioning in the wild.  My horror stories of Corporate IT are mild compared to many I have heard with psychotic management and cutthroat politics – I’ve been spared that.  But wouldn’t it be nice to work for Utopia Software Company or at least in the IT department for Utopia where dreams can come true?

When I asked my manager about comp time for the time that I drove in on a weekend to bring things up after an extended power outage, I got told “that’s part of being a professional”.  And the day after I stayed almost an hour and a half late to fix a printer that would mess up production, I was chided because on the same day, I arrived 5 minutes late.  The company got 1 hour,  25 minutes extra time from me that day, but the five minutes was a problem.

And what did I get for all of this extra effort?  I was about the first salaried person to be downsized.

Here is my call to arms to my fellow IT workers: 

NO MORE UNCOMPENSATED WORK!

Part of being an IT Professional means making changes when they have the least effect on systems and the users.  This necessitates after hour/weekend work.  I accept and agree.  HOWEVER, that is not card blanche for the company to steal that time for you without compensating you with either money or time.

Professionals – doctors, lawyers, accountants – all charge for their time.  They are compensated when they work.  Why should IT workers be any different?  Employers have successfully used the whole “salary exempt” classification to weasle more work out of workers without compensating them for it.  It’s time for us to just say no to this game.  If we are told we have to do the work on non working hours, we get either time or money in return.  Plain and simple.  And we have to be given the ability to use that time!

I did it out of a misplaced sense of loyalty and professional pride…and it got me an early ticket to the unemployment line.  I’ll never get back the time I didn’t spend with my wife and son when I had to go in on the weekend to restart systems or see my son go to school because I got back home at 4 AM because of a problem and actually wanted a few hours sleep before I returned.

I think every person in IT should adopt the mantra of the movie “Network” :

“We’re mad as hell, and we’re not going to take it anymore!”

I have no idea what they were thinking.  There is now no IT at the plant and an ERP and a main system that runs most of production that need support – and no one to support it.  The ERP system was supported locally since Corporate runs SAP and the other system was a Visual Basic system built over 13 years.  And no there’s no one.

I have run the gambit of emotions – anger, shock, depression, relief (today I seem to be centering on depression).  I know that this too shall pass, but it doesn’t make it any easier while I’m going through it.  Mostly, it  makes me feel like wasted four years of my life at a place that obviously didn’t think much of me if they can get rid of IT so cavalierly.  It’s not like my company is losing money – it’s probably a case of not making “enough” money.  Truthfully, I don’t see how they are going to save money and support the business because they’ll have to pay contractors to do it all.

It makes me mad for all of the middle of the night trips I made to get systems up so that production could continue, the working on Christmas holiday so that payroll could get processed and financial closing could complete on time – all obviously meant nothing in the end.  It’s an object lesson to me about trusting any corporation – all they seem to want is to suck out your knowledge and time and when you become inconvenient, you are jettisoned.  And this isn’t a “if we don’t cut people, we declare bankruptcy” kind of decision – this is a “we’re not making enough money” decision.  That I can only hope hurts them in the long run…not that I’m vindictive or anything…

So after having a pity party for myself, I’m redoubling my efforts on my business in hopes of finishing my product this summer and starting the search again.  The last time, it took me over a year before I found this position and the economy was better.  I don’t like my odds this time…

As someone said to me recently, God doesn’t give you anything you can’t handle – sometimes, I wish God didn’t have so much faith in me.

 ”The cliché of the solitary coder is dead.”

The article goes on to talk about a number of Corporate IT application development groups that have done some pretty phenomenal things for their companies. 

This is a subject near and dear to my heart as I am the IT department at my day job and I am the only developer for my business.  I can categorically say that in my day job, it is certainly not by my choice. 

Is It Possible to Deliver Great Results By Yourself?

I don’t know – I think it depends on the developer.  I can say that in my twenty plus years of IT, the amount of stufff you need to know has grown tremendously.  For the applications that I typically develop (your based Create Report Update Delete – CRUD applications – and yes some of them are just that), here’s a short list of what you need to know:

1. Database/Table Design
2. Object Oriented Design
3. User Interface Design
4. Requirements Gathering
5. Application Development tool
6. Testing
7. Implementation/Installation Packaging

Notice I didn’t even get into the application development tool of choice or platform – Web vs. Windows.  This is a pretty steep learning curve for anyone.  A person can become a master in any single topic I listed and still not know everything.  I find it ironic that while a development tool like Visual Studio .NET can make you more productive because many of the things you might want to do are part of the .NET framework, it is so huge that it seems like an endless task to figure out how to do what you want.

Is It Desirable?

I don’t know;  I have mixed feelings about that.  As a developer, I love owning the application and being able to point at it and say “I built that.”  That’s on the good days when everything is running as it should.  On the days that there seem to be more new bugs than lines of code in the system, you want to hide in a cave, lest the users arrive with pitchforks and torches…

But the practical reasons that it is not a good idea are:

• All the knowledge of the application is embedded in one person’s head.  I don’t care how well it’s documented, there’s stuff that someone will want to know quickly that is very difficult to extract from a source code listing.
• There is no second eye for design choices.  It is that person’s design, warts and all.  While I don’t recommend design by committee, having other resources to assist in the design phase will certainly create a better product.
• The pressure to get it done can override a developer’s natural (or unnatural) tendencies to follow good development practices.  Sara Chipp wrote an excellent description of this phenomena here. 

Is It Really The Death of the Single Developer?

In a word, no.  For one very simple reason: COST.  Many small and medium size companies (even if they are part of a bigger corporate parent) can’t justify having a team of programmers.  These companies always need someone to develop something that works exactly the way the business works.  As much as the big software vendors like to throw everyone in the same functionality pool for their applications, truth be told, each business is unique.  It has a unique structure, culture, and institutional history.  All that stuff becomes the DNA of their business processes.  And as a developer it’s your responsibility to turn that DNA into something – hopefully not a genetic mutant hell-bent on world domination…

Can a single developer do that?  The answer is…it depends.  If the company realizes all of the things that a developer can bring to the table and is willing to invest in that developer in terms of training and decent tools to do his/her work, it might just work.  The developer does have to be linked into the business and know what’s happening.  He/she has to be sensitive to the business climate, really understand what it is the business wants from the developer, and have his/her pulse on the work going on out on the floor.  Likewise, the business needs to listen to the developer when it comes to what’s needed to accomplish a project in terms of time, money, resources (not necessarily other developers – users too!), and respect the developer’s technical decisions and expertise.  If the developer says “If we don’t start to rewrite this critical business from Visual Basic 6 to a .Net platform now so that it will run when we migrate to Vista/Windows 7, we are going to be dead in the water”, you might want to listen to him/her, instead of (figuratively) patting him/her on the head and saying “That’s nice. When’s the next release?”.  If you find a company like that, please let me know…

However, in many small shops, the developer is also the Server Admin, Network Admin, PC Hardware and Software Support, and Printer Repair person.  Now take that list from above and then add everything you need to know to support THIS list of duties and I fear that the majority of people’s heads would explode at the amount of knowledge needed.  And end result?  I think it’s safe to say that the company gets exactly what they paid for – a jack of all trades, master of none.

Conclusion

 I still think it’s possible for a single developer to succeed.  While the single developer has many hurdles to clear that aren’t found in a development team, there are two things that the single developer and the development team both need to succeed – a clear commitment from the business to support the development team and excellent communication between the team/single developer and the business.  If I ever can find a company like that, I’ll let you know!

One thing I neglected to mention in my previous post is the gradual erosion of IT resources since I joined almost five years ago.  Towards the end of my first year, my manager (who also did IT project work ) left the company…and they didn’t rehire anyone to fill the role in IT.  I’m sure the headcount where somewhere, but I don’t know for sure.  Then, three years ago, my co-worker was outsourced to another company.  He’s now responsible for the PC’s, servers, and network (for which he was already the primary support person) and I inherited about 40 % of his job (and got rid of precious little).  So I now have the work of two people.    Then, to top it off, I have now been asked to answer any PC related questions if someone calls/pages me instead of calling the Help Desk (that we pay for with each PC).

Not getting my training and hearing that someone else was approved for elective training made me blow my stack last Friday.  Fortunately, I didn’t talk to my boss because I was VERY angry.  So after committing myself to do it in the blog last night, I had the discussion with my manager today.  I let him know I was very upset about what I found out on Friday and said that as a result, I felt like what I do must not be valued and that I felt set up for failure (I had said this to him over a year and a half ago).  He dismissed how I felt, but miraculously, the money has been approved.  I don’t have the actual training yet because I’m having problems getting hold of the vendor (curse you companies that refuse to put phone numbers on your websites!  People still need to TALK sometimes!), but it’s going to happen.

I feel a little better because it’s off my chest and I’m finally getting the training.  But a part of me knows that nothing else is going to happen and I’m still going to feel unvalued and set up for failure.  I was thinking today that if I was a manager and one of my reports came to my office and said what I said, I would be floored and try to move heaven and earth to get to the bottom of what’s happening.  I’m making a vow that if I ever am successful enough to have my own company (because I’m sure not getting  a promotion here), that I would listen to my employees and at least consider how they feel.  If someone is that unhappy, something is seriously dysfunctional…which is a good description for how things are.  I’m sure this will come back to haunt me in my performance review, but I had a very small win today.

Sometimes, that’s all you can expect…