Kick Positive Booty

After a very long and trying month and a half on a new project, it may be turning around to a success?!!! Could it be?! Maybe. The suggestion was even made by a senior coworker today of having "more than weekly" recurring meetings with the client to sync. I joked about having "Daily Two-Hour Standups". We're in a development rhythm (finally) and that is really satisfying. I'm really the only developer, though. That's been hard. Really long hours. 12 hour days are typical. Our project and delivery schedule is as follows: Plan Mondays and deliver Fridays. I twisted arms to add a ton of risks to our risk register today. Seems very simple moving forward but it's been hell getting here. I'm not sure how many teams work the way we're working. We have a very difficult problem we're solving; many moving parts and tons of senior-management pressure. Dates and deadlines. It's fun at the moment and I hope going well. I have a huge deliverable tomorrow and I've learned so much on this project about data movement, ETL, and SSIS. Also about people and leadership. Roles, and stepping down when you can. Let quality people be quality; let them help you out.

I'm designing an automated business process that removes 204 manual hours of work monthly. That's fun and satisfying.

Two skills for PMs. Make sure that the work in process is going well and that impediments for the workers are removed. That is your job. Another job is to watch how much you are whipping your employees. Assume they are smart and good; doing a good job, with good intentions. Guide and lead them. Mind the whipping and don't whip too much. Choose carrots (vision and leadership) over sticks and whips.

Don't be a slacker. Be very clear on what you're doing and why. Who knows, the customer could join you right now and want to see what you're doing and why!!!! Be prepared.

I'm reiterating my point of getting the product into the hands of the customer or the testing team as fast as you possibly can. A developer cannot be a standalone entity, operating in isolation. All individuals need feedback and we cannot deliver quality unless we have an on-looker or customer. We need an audience or we are really just performing for ourselves, without feedback. We need a mirror at a minimum! Give your code to the customer and then determine what the portfolio of needs and changes looks like. Be agile.

I'm definitely not the best at this but I think I'm getting better. Some things are taboo, some things are sensitive. This is true in both work and life of course. With specific respect to work, however, we definitely need to figure out the best way to play the politics, get ahead, and engage in the (potentially difficult or touchy) conversations that we need. This includes subjects such as compensation, coworkers, the work itself, and assignments. "Managing Up" is a skill that is talked about a lot but it is neither a class I have taken nor a subject I've read about. I just did a quick search for books on this subject: http://www.amazon.com/Managing-Up-Forge-Effective-Relationship/dp/0385507720 Does anyone recommend any good books on managing up and doing well at politics in the workplace?

As a product developer, you have to be able to 'let go' of your product. It's not for *you* anyways, so get it out of your hands and into those of the customer! I'm building an app for a friend right now and am finally to the point where I am willing to give him access and let him test it and comment. That's a big milestone! I am sure he will have feedback that I do not expect. Your users are your best testers. I don't want to be perfectionist about my product and need outside help. I don't want to float too green of a banana but I think it's good enough for now. He wants the app and deserves to know what state it's in.

I was on the phone with the Hewlett-Packard Customer Support line this morning and (without the agent's help) figured out the solution to the problem I had called about. When I announced the solution, the customer service rep said, "You sound disappointed that you solved your problem." And I answered, "Yes, I do." (It shouldn't have been the case, I don't think that *I*--rather than *he*--had figured out my problem.)

I would add to this that there are other problems that when solved, there is no real "EUREKA" moment. As they say, "Huh" is a better discovery than Eureka. The truly big shifts do not occur via some drastic "explosion" of change, but rather a new realization or perspective that can be as small as "huh", or "that sucks".

An example of this is working on a computer bug that when you solve it you have tried so many things that cause so much time and pain that when you finally do solve the thing and make it work you are simply disappointed that it was THAT HARD. Such is life.

People have very different reactions while waiting for computer systems (any process for that matter) to complete or change. Take for example launching a program on your home computer: you click a button and the "wait cursor" comes out. What do you do? Get angry? Wait patiently? Hope for the best? Some people tap their foot and get anxious, others watch and wait and think about what might be happening and how things might be working. We have a chance to be introspective about systems other than ourselves.

We can witness the same behavior on the road every day in our driving: some drivers are patient and don't give too much thought about what the drivers around them are doing while others are very critical of the other "stupid" drivers. I'd say that the way we think about other systems and what they are doing is a very clear reflection of how we think about ourselves: Are we patient? Are we forgiving? Are we intelligent? Are others intelligent? …All of these things cross our mind in computing and in other life-systems as well.

In this way, I recommend that we be more patient and seek to UNDERSTAND what the other systems around us are doing and why…and in that process we will learn much more about ourselves, our intuitions, and how we are actually impacting the systems around us. Thinking at this level will help us change things for the better.

Many situations call for us to rise to the actual level of stress. This to me means that we are highly dependent on the context of the situation around us. For the most part, all we can really do (consistently) is to respond to how things are changing around us; we are a part of the system and are not—by any stretch of the imagination—the system itself. Systems are dynamic and we have to see and recognize ourselves as being a key and critical part of those systems. We must treat them carefully. We need to think very carefully about different perceptions and realities and decide to act in accordance with our beliefs and wishes. Act cautiously. Although we may be in a position of power or leadership, our thoughts should drastically govern our speech and actions. Seek to change the perceptions around us through our intuition and inner strength. Be careful with what you say and think very critically about the 'network effects' of your actions. You are at the center of the system but you are not the system yourself!

I'm skipping the Huskies basketball game right now and playing with friends because I am trying to help my buddy with his business. There are sacrifices that come with doing good. Working on my buddy's problems makes me feel happy and like I am doing something good. The Huskies will win or lose, my friends will (hopefully) still be there for me, and I am feeling better by contributing to my friend's business. Social to me is helping other people, not necessarily drinking or watching sports with them although that might be more 'fun'. Fun creates a short-term reward. Work has lasting benefits.

Nothing more to say here, really. As a developer, you are coding for one purpose: remove the most urgent and important business problem that exists. You are fighting fires all the time but you may not realize it. If you're not, then become a better business analyst. You are trying to free business resources so they can do more value-added things.

You might care, I might care, but how do we make 'everyone' care? It's impossible. We can't. We can attempt to add one person at a time to our way of believing. But most likely--by the time we reach the last person--our thought process and beliefs will have changed so drastically that our purposes will shift. It's like painting a bridge: by the time you're done, it's time to start over again from the beginning and repaint. Make your bridges small. Build many bridges. And be flexible.

Remove impediments, improve the process. Understand what's being added to the backlog. Understand what kinds of "shortcuts" or workarounds are being taken by the team. Understand the consequences and better solutions to these items.

The stuff you're doing now will likely amount to something bigger and better once you're done. Keep doing what you're doing and getting better at it but keep in mind that there are consequences of what you are creating. Prepare for the consequences and get ready to tackle the next big problem they create when you get there; but only then.

Development speed and efficiency might matter more than anything else. Yes, customer requirement and needs are paramount in general, but sometimes they are unclear and the development team can produce something really good that isn't EXACTLY what was corrected. This discrepancy is fine. If the development team can produce Product X which CLOSELY RESEMBLES the 'perfect product' described by the customer, then that is the product that should be produced. Future iterations can make it perfectly align.

Workflow can be seen in two ways: that of the SYSTEM USER and that of the DEVELOPMENT TEAM. The end goal for most projects is to create a "perfect and efficient" workflow for the user. Being efficient may involve trade-offs as there is a cost for realizing perfect workflow. If the development team isn't paid for the realization of every incremental user workflow bit, then there is a problem.

Don't get bogged down doing a bunch of boring repetitive stuff now unless it is required. Follow the Pareto Principle http://en.wikipedia.org/wiki/Pareto_principle and knock out the big stuff. Demonstrate as much value as you can. Solve the problems you know how to but don't solve them throughout the whole system just yet. You can do that later. Yes, you'll develop a backlog of little stuff that has to be fixed; the time will later come when that is urgent.