are you the next FA (4)?

It should have occurred to me much earlier to put it like this: what an FA really is ... it's the Product Owner in SCRUM ... bridges the gap between the technical and business worlds, OWNs stuff, takes DECISIONS!

And I am telling you: It has never ever been easier than today to take decisions in software!

And here is why:

1. We are encouraged to take risks. Risks may bring in failure. Goto line 2.

2. We are taught that failure is part of the game.

3. We are taught to embrace change, change brings in risks. Go to line 1.

4. Agile practices tell us that upfront planning is not the thing to do. Without complete upfront planning, risks are higher. Goto line 1.

5. There is so much complexity, so many unknowns, so much competition that getting it wrong will not be a surprise.

6. There is this notion of a throwaway prototype. In case your feature fails, declare it was a throwaway protoype.

7. There are so many other smart boys in the industry that simply could not figure it out!

8. Management continuously pushes us to innovate. Innovation leads to uncertainty, uncertainty leads to risk, goto line 1.

9. If you are working in an enterprise, high chances that you are part of a feature team. As opposed to component teams, features teams do not specialize in certain product areas but instead are mobile and take tasks in multiple areas of the product. This implies they do not own stuff, the ownership is collective. This implies collective risk taking. Thus collective blaming. But since management can not afford to send an entire team home ... you see my point.

So step up into this role. You'll have visibility, you'll be admired, you'll get your pay raise. Just be armed with the knowledge above for the 1:1 with your boss when you mess it up.

Take decisions. Or somebody else will. You're definitely smarter than somebody else!

the tools that saved the OS ... [2]

Fresh from MS Build conference, the Ubuntu on Windows project is along the lines of this older post of mine.

After this project goes live, it will be interesting to watch if the usage of Cygwin in Windows 10 will be lower than that in Windows 7.

the bold and the bullshit

The high demand for software professionals transformed them into these picky creatures that indulge with free lunches, fusball tables, designer office spaces, paid membership at the gym, sponsored medical care, company matched volunteering programs, and massages at the office.

Hiring software professionals has become the HR's nightmare. Annual reviews don't scare anyone, as a low performance review can be followed up with a new job in another company that is craving to grow past the 500 figure to appear on the radar of Western companies looking for outsourcing partners ... hugh, that was quite a long sentence.

This is the perfect context for being bold. It is not about saving the long-haired blond Princess from the jaws of the hungry Lion, nor the Kid who is drowning in the muddy waters of Amazon. These deeds had been done by other heroes.

I am talking this bold:
  - adopt a no bullshit policy
  - give honest feedback
  - contribute to discussions, even if you start with "I think ..."
  - have the courage to say "I don't know shit about this"
  - have the courage to say "This meeting is a waste of my time"
  - keep your desk messy ... actually I see a lot of these heroes

We are talking opportunity here: act like this while you still can laugh at the prospect of being fired.

And this is all for your own good. Philosophy says that sincerity boosts happiness, and science that happiness fuels success. (Warning: some say that success is the inverse of happiness, so you be the judge; but if you go for happiness first, it might redefine success.)

Oh oh, let me not get all too involved in this philosophy - science - beliefs ... philosophy, and step back a little ... you are an engineer right? so Success must be what you are looking for ... gotcha ya you little un-bold prick!

structuring Python's main()

You would not imagine that such a seemingly trivial topic deserves a blog post of its own. Until you see this:

def main(argv=None):
    if argv is None:
        argv = sys.argv
    opt, args = parser.parse_args(argv[1:])

...and this

if __name__ == "__main__":
    sys.exit(main())

repeatedly in the code, and you start thinking this is a pattern somebody defined elsewhere. And indeed it is, find Guido's original article here.

From the issues that the original post addresses, let me only focus on the ones printed above, so mainly leaving out the details of argument parsing and displaying the usage message.

We are after a function that's easy to invoke in other contexts, e.g. from the interactive Python prompt. 

Let's add print statements for opt and args and run the code above from the command line:

c:\Temp>c:\Python27\python test.py arg1 arg2

{}

['arg1', 'arg2']

And let's call it from the interactive shell, looking after the same behavior:

c:\Temp>c:\Python27\python

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.

>>> import test

>>> test.main(['arg1', 'arg2'])

{}

['arg2']

>>> test.main(['arg_that_nobody_cares_of', 'arg1', 'arg2'])

{}

['arg1', 'arg2']

You'll also feel the smell once you try to document it:

def main(argv=None):

    """

    Parses argv and prints the results as parsed by optparse.OptionParser.parse_args(), after dropping argv[0]. So if calling it from another script, make sure the args you care about start at index 1.

    Keyword arguments:

    argv: array of options and arguments. If None, it defaults to sys.argv.

    """

I would argue that main() should exhibit the same behavior when called the same way from different contexts and expose a consistent interface. Here is the proposal:

def main(opts_args=[]):                      # (1)

    opt, args = parser.parse_args(opts_args) # (2)

if __name__ == "__main__":

    sys.exit(main(sys.argv[1:]))             # (3)

(1) opts_args defaults to [] instead of None, because calling parser.parse_args(None) will actually parse sys.argv[1:] (see optparse.py), and you don't want this if calling main() from another script.
(2) if you want to use the script name in the help message, __file__ should do, you don't need sys.argv[0]
(3) all sys code in one place

I'm already used, you know?!

Every once in a while I come across a type that it is documented as being used by another type:

/**
 * Used by {@link SupremeCook} to bake supreme cakes.
 */
public class NewFlavor { ... }

As the author of a blog takes pride into having his posts read by many individuals, it would be the pride of the author of a type to have it reused as much as possible within the codebase.

Practicing over-documentation, the author of the type above softly coupled it with another type, defeating the above stated goal by making potential new users think the new type was not designed for reusability ...

3 years have passed by ...

Miles and miles away from our programmer, in a remote conference room in a remote part of the world, upon being advised by his lawyers, the young entrepreneur decided to withdraw the flavor packages still on the supermarket shelves to make the following correction to the usage instructions:

not by the book

How would you cope with entering an idea brainstorming meeting and the very first words the organizer says are along these lines "Welcome, here is an idea I had this morning, please help me refine it"?

Today I've wanted to make people approach something ordinary (be in a meeting) into an out of the ordinary way (not be aware of any meeting process or outcomes).

So I entered the room. And I said something along these lines "Welcome, here is an idea I had this morning, please help me refine it".

So they were all ears, then timidly contributed to the idea, but there was something missing in the air. Then one person did the unimaginable: my meeting co-organizer broke a deal I had made with him hours before the meeting: that there would be no slides.

He professionally waited until the conversation paused a little. Then there they were:

THE SLIDES

The slides I've tried to part with. I could, but he could not. Or maybe they could not.

I imagine he could not stand the situation anymore. Or he noticed that others could not stand the situation anymore, and he wanted to avoid a failed meeting. Because they needed

THE RULES

They attentively watched the 4 slides unrolling before their eyes, and then all was fine. The sky was clear again. Ideas started flowing, 6 in one hour. Astonishing. 3 people left the room to attend other duties or answer the phone and came back. One KPI checked. It was a "really good, 4/5 meeting" said one of the participants afterwards.

But in the thin air _they_ were still there. Waiting to bite us again. 

What do we do with these ideas?

Who is taking this further?

When can we expect results?

This was a closed-door meeting, how will we let the others know about such next meetings?

They needed

MORE RULES

But there is a line. Cause we only need just enough rules to allow us to have no rules.

Cause we don't need a formal email to let the others know what we did today. They will hear it from the participants if they left the meeting excited.

Plus I and my co-organizer will repeat the same meeting with another group, possibly half of today's participants and half first-comers. Why half of the ones from today's meeting? Simple, because they already know

THE RULES

are you the next FA (3)?

Every now and then I can not help but admire what StackOverflow has become. Tricky errors scare no one anymore. Badges make you feel stronger than ever. People take pride in contributing there. Resumes display the reputation.

So if the word Functional in the job title Functional Architect is not music to your ears, and you long for the more handsome System Architect title, take note that it is the functional aspects that made StackOverflow what it is today, what made the difference between the other thousand forums with the same intent of helping users in trouble and StackOverflow.