aesthetics

I believe in small increments: post a documentation bug here, correct a java doc or spelling error there, replace a Vector with an ArrayList when the collection is a local variable and you do not need synchronization, format a code paragraph. All this while marching on with your completely unrelated coding task.

Can't help it, but I always imagine a Grand Display, showing the product quality percentage, being run by a divine power that simply knows how to calculate it; and my change pushes that percentage up, indeed with a tiny increment, but still up, towards green.

Small and insignificant may they be, but the power of an entire crowd of developers doing small changes can be of a big importance to the product - a game changer long-term, for your next releases, for the maintainability of the product (something that the super power running the Grand Display did not teach us how to measure), because carefully crafted code and documentation will ask for code and documentation of the same quality level from the future commiters.

So encourage this practice to become contagious. Those that are likely to get infected first are those that can't help monitoring the source control commits. Don't think about your boss, but about the component owners with an interest in the component quality, the ambitious juniors that want to learn from others' code and those that want to make a name by finding other developers' bugs - all of them will appreciate your small increments.

Additionally, a trick to get more eyes to see your aesthetics changes is to include the files with small increments as part of the code review package for the bigger feature.

No, I am not preaching to occupy your time doing small changes - the vast majority of your time should go to changing the world. But big changes are never polished enough, so they will need the magic touch of small code increments.

incredibly optimistic

Mgr_to_become_dev (MTBD): I see so much garbage around, that I become excited at the chance of cleaning it - I see opportunities to fix code and simplify everywhere.

Mgr_of_a_peer_mgr (MPM): yeah, it's so easy to do something and have a good impact.

MTBD: ... turning red into green.

MPM: I am the optimistic type, it is how I am, once I commit to something.

MTBD: I think there is no other way, after you rule out being neutral.

Now, press 1 if you think this is a real dialogue, press 2 if you think it is a cheap one stolen from "How to engage your employees" by Managers.

you on you

The painter in you will find the new canvas intimidating. The writer in you will find the blank sheet of paper intimidating.

The manager in you will find the immaculate-white background of the email client window intimidating ... it is supposed to hold the yearly evaluations of your directs, instead it's blank. Where to start you're asking?

Meet self evaluations: I am finding them to be the easiest way to kick off the employee evaluation process. Is it as simple as you asking your directs for their own perspective on their accomplishments, contributions but also on unmet goals and targets over the past year. (in the Romanian immature corporate culture we sometimes call the latter bad things).

Give them time to think.

Then add your own observations - you should have observed them and taken notes throughout the year. Then add the others' feedback to the mix: team members, customers, other managers that happened to interact with your guy. Then look for some facts, in your project plan, bug tracker, emails, reviews.

That's it ... fully armed now to conquer that white background!

one team for the customer

What have you done lately to make your customers happier?

Have you called them more often? Have you stopped developing new features until you reach a Zero Known Bugs state? Did you hire the best Information Engineers to make your docs all bright and shinny?

If a lot more than this, or none, or none of the above, let me give you another idea of what we do:

We built a cross-feature team staffed with the brightest people who analyze customer escalations, observe trends and write beautiful code to make sure future escalations in the area are near to impossible. Out of 30 customer escalations on how slow your server compliance checking runs, they would come up with a new way to access your compliance rule repository using a proven web server instead of your custom (slow!) python multi-threaded code.

How would this setup work? Would they sprint together with the rest of the teams? When will they sync with the feature teams to make sure they are not writing the same optimizations? Would you have this team on a permanent basis or build it ad-hoc depending on the number of current escalations?

Know what, these are all up to you, in the end it's the client 'smile' that matters.

replacing technology <T>

- never heard of T, is it software?
  - sure I've heard of it
    - I'm a big fan
      - tried it in a Hello World
        - use T daily
          - reported a few bugs
            - contributed to the code base
              - I am T expert consultant
                - I developed a parallel technology
                  - it's history, my technology simply wiped T out of the market

- What do people say about your pet project?
  - Don't have a pet project?!
    - Are you a software engineer?!
      - ... um, never heard of you, sorry.

satisfaction

It is a few months before a new Server Automation major release ships, so it's time to let the customers take a peek at what we've been working at in the last 6 months. We are taking them on a test-drive (but don't let them in the driver's seat yet) of the new features to get them to comment, like:) or dislike:( them.

But we got more than this in the last demo. The client was so pleased with the features we developed that this got them into a chatting mood, so some of us ended up pouring questions onto the client about their environment, how they use the product for their use-cases, how they horizontally scale their work (or not) when dealing with tens or hundreds of servers. It won't be far from the truth if I said that our questions outnumbered the client's. So yes, we got something extra out of it.

And the client got something extra too: as the discussion developed, they got their share of answers and tricks about the old features they've been using for a while now.

Still, we got more than the client did: satisfaction. Satisfaction cause they were satisfied. And it was plenty of it to share, to the QA eng that did the demo cause his clicks unveiled the magic, to the functional architect who spec'ed out the magic and for the handful of developers that ... built the magic.

Are you feeling down? Ask your customer to come in for a demo!

are you the next FA? (2)

Had a discussion a few days ago with my FA, and we came up with this shorter definition of an FA, looking not at what s/he should know but instead at what s/he should do:

The functional architect is responsible for specifying a feature so that it both satisfies the client and is implementable.

Wanting to be an FA? Then make sure you can look at a problem both from 1km and 1cm away. Be able to stay off and on the ground.