agile architecting

The whole IT world "is" / claims to be / wants to be agile today, which reminds me of the days when the hype was about multimedia ... every CD out on the market was multimedia.

But actually this title has quite some substance if you watch this presentation The evolving Guardian.co.uk architecture. A presentation worth watching from which I would extract these ideas:

• architects, don't underestimate developers when tech issues must be solved !
  
• having a parallel platform team to deal with non-business, purely technical stuff
• new architecture optimizations and improvements being much later needed than estimated
  

paradox

It's a bunch of smart people, I hear them all the time in meetings and I read their emails ... How can I say they are smart ... a good percentage of what they say I don't understand! They are the core that built and are now extending and selling a well known HP product. And they are polite and helping, which is another sign that they are smart ... I mean they must be smart, I feel it.

How come their frameworks are over-engineered, the code is full of dirt, the test coverage is close to zero? And something along this paradox to be tagged as sad: how come they are forgiving with this state of facts?

the young and the motivated

Its probably the young IT industry in Romania that makes recruiters add this sort of benefit in most of their emails and ads: You will be part of a young and motivated team.

I am looking forward for the times when I'll read this instead: You will be part of a very experienced team with great past achievements.

intuitive [/] emacs

... a screenshot of mcedit, no comment

new comers are right

They see the code base differently, they are unbiased: they don't know who owns a package, they don't know there are historical reasons why the code is so bad, they don't know the past trade-offs and political games, they are unaware of the dirty workarounds that still keep things moving.

You've been "contaminated" all this time you've spent in the project. You know package A is owned by the team lead so you won't review it harshly, you naturally justify the bad dependencies with the schedule pressure two releases ago, you got used to unsetting this environment variable and creating that magic file by hand each time you run a deployment and those worthless TODOs seem a natural code outfit, they almost please your eye.

New comers can't see the forest for the tree, but this makes them focus on every tree. And sometimes healing tree by tree is what gets a global healing effort started. What they see is the current technical debt at a granular level. They are not yet bored with the codebase so they are eager to find the problems you have long accepted.

Only if there was someone to weight their opinions against the contaminated ones ... and do it faster than the team contamination velocity.

my wider resume

... you're looking at it.

It's the entire collection of material I've been posting here. It's not mere writing, it shows a way of thinking (consistent?) that a standard resume won't show. Anyone working with me or who I am working for can expect I'd want to implement the ideas outlined here during the partnership, so they'll be well informed when choosing if they want such a partnership. It's a solid step to openness.

It's my contributions to software in general: code snippets, reviews, technical HOWTO-s, quality assurance, coding for fun and contribution to OSS, and they are all linked to from here, each with its own story.

And it's fueled by contributing. There are still many other ways of contributing that I can think of: writing a full blown article for an IT magazine, registering as a speaker to a software conference, giving a speech at your local university, creating and maintaining a product or website.

Is this worth the effort? Probably not if it's an effort and there is no fun in it. But if it _is_ fun, then this is a step forward for you who want to play in a higher league.

You could be invited to join a company and not apply to join one, you could have a discussion partner and not an interviewer in front of you, it could be a dialog like We heard about you and appreciate your work versus an interview like Please tell us about yourself and your last 5 professional years; then it would continue with We are perfectly aware that someone with your capabilities can help us ... compared with We'll continue with a short list of 10 questions.

Now, tell me, is it worth the effort?

the tired programmer

Are you? A programmer ... I mean tired? Aaa ... both? Well ... are you chronically tired?

Of what? Innovation, progress, change, every-day learning, designing for change ... CHANGE !!! brand new everything, industry immaturity, the multitude of unsolved problems, technology stacks that resemble a sky-scraper, embracing CHAAAAAAANGEEE ... ?

What if this were true? Well, got you thinking ...?