Posts

by on

The biggest killer of developer time is meetings, it is a double whammy when it is run by people who do not know how to run it or how to finish it. So often a meeting eats up as much as the 25% of day without adding benefit to any of the attendees.

Image courtesy: Unsplash

Developers cannot spend time in 30 minute slots like non developers. It takes some time to get into the groove and let the mind feel the code as if it is the extension of the natural language. 3 hours of unbroken developer time is the golden rule for me, it does not matter if I am coding, writing something or just starting out of the window thinking about something. The biggest killer of my productivity is when people pull me out of my zone for status checks during the middle of the coding session.

Also too often the planned meetings are more of information gathering sessions for the highest placed person in the corporate ladder. Any agenda or plans are thrown out of the window when the first question comes from a leader. These meetings scheduled for about 30 minutes will get converted to rants, status checks, random questions, fears and more that drags on and on to go well into 90+ minutes.

The best way to run meetings is to

  • Set agenda & time window (Make sure attendees are prepared, if it is a status check it is best done at the start or the end of the day)
  • A facilitator who can keep time and moderate conversations if that goes away from the agenda
  • A parking lot to make sure to capture random thoughts that can easily derail a meeting

Any one I have spoken to, agrees to the above points, but fails to keep the meeting in check because it is mostly run by non developers who don’t mind those additional 30 or 60 minutes getting wasted; or they just keep quiet and stay on so that the seniors are not offended.

If you are a manager and have a development team, please give unbroken chunks of time to developers and learn to run precise status checks and meetings without draining the energy that can otherwise be put into solving problems.

p.s: Design discussions and dev huddles do not follow in the above category but they also need to be facilitated well by the tech lead.

by on

In the last few years I see an overall increase in the busyness of people around in all professions. Everyone keeps telling about how busy they are; always behind tight deadlines and impossible to pursue goals yet they are able to somehow get things done. Managements usually set difficult to achieve deadlines, tightly control budgets, non negotiable scope of work and leave quality as the only leverage for the ground level people.

Dirty fixes and ill fitting designs are the norm

So people end up kludging together things to make ends meet. One of the dictionary meanings of ‘kludge’ is ‘a machine, system, or program that has been badly put together, especially a clumsy but temporarily effective solution to a particular fault or problem.’ I came across this term when reading this article. Kludge appears everywhere and it looks like a clever hack.

Sending that boolean variable named ‘donotTouchThisFlag’ through multiple layers of code and systems to bring up a new feature effectively cuts the time down by several hours that should have been spent in redesign. An engineer doing this for an aeroplane is beginning to get away from these blatant engineering blunders and instead gets praised for quick delivery of features and leave the headache to the technical support team to handle.

People have no other option than to succumb to this vicious cycle of too much pressure and low quality work. If they don’t fit in, they get kicked out. What is the leverage then? It is very hard to find leverage when people are bossing around in multiple layers, I kind of miss the unions of the yesteryears in many disciplines who demanded the right conditions, pay and working hours.

Good design and quality work can never come from pressure, if an output comes out of extremely forced timeline and budget then chances are high that failure follows suit. Sadly the manager gets rewarded for timely delivery and the engineer gets the stick for poor quality.

by on

There was a time when learning css one of my friends told me a clever hack, use the ‘!important’ flag which will override all the other precedences. It was a boon for me when deadline was screaming down at me, for any css issue when I used the priority override and bam the bug was fixed. My joy was short lived, I was creating havoc in the css code and tough debug issues within a few days that I had to revert all the flags I had used and spend time fixing it properly. A big lesson learnt that stays with me, never abuse powerful tools.

I meet some managers who employ this trick in their day to day life. They take pride in answering questions like ‘When do you want this done?’ as ‘YESTERDAY’ and follow with a grin. The communication is limited to only deadlines and urgency, not the intent of what the task or the project is supposed to do. These people are high up in the power chain and use their coercive power to get things done.

What they don’t realise is the amount of things that pile up as priority items and how when everything is a priority, nothing is a priority. There is only so much that can be done with the amount of time and money in hand; with that judicial balance of outcome and effort gives a great returns compared to a series of high priority and urgent tasks that are done for the sake of being done.

I liked what I read at this link https://basecamp.com/books/calm

Great projects and products can get going with sane pace and working style. Don’t misuse the priority tag.