‘time-management’

Time-management. Rly?

Friday, June 18th, 2010

Watched interview with Gleb Archangelsky – time-management guru from Russia… [It sounds sooo funny - time-management guru. For me, it something as laughy as urinotherapy guru. The both religions are based on a blind truth in a miracle, and ignorance of rational aspects]

Feels like the only thing time-management enthusiasts can do – extremely effectively waste time on talking about time-management. However, everything they say is so-so-so-so straightforward – I would be ashamed of saying such banal things to people. Time-management strategies they sell ("pomodoro" technique, "pond with frogs" strategy, etc.) can help only spineless creatures, who have to train themselves like dogs: has made something unpleasant? – take a sugar, good boy!

They're all of one nature: time-management for lazybones; pills for fat-asses, who want to lose weight eating hamburgers and drinking beer; success-stories of the house wives, who earned millions of dollars spending just 2 hours per day on the Internet, etc. It is for naive fairy-tail lovers, who believe in a mystery knowledge that can make anyone a mega-successful super-human with a small effort. That's crap, don't you think so?

If you want something, it's not enough just to dream about it and believe that one day it will be yours. You should work. Even worse, you will probably have to work 15-16 hours per day, without weekends, sleeping 4-5 hours. It's the painful truth, though masses still want to believe that working 4 hours per day they can achieve something.

Be yourself and follow your own inner rhythms. Time is priceless – don't waste it on learning time-management techniques.

Tags: , ,
Posted in opinion | Comments Off

The new form of Paranoid Programming

Wednesday, January 27th, 2010



“When everybody actually is out to get you, paranoia is just good thinking.”
Woody Allen

If you go look for definition of Paranoid Programming on the web, you’ll most probably find something like: “paranoid programming is good practice in coding, the sign of professionalism, which implies considering all possible and impossible failure scenarios, and adding appropriate protection from them”. Which means patiently cultivating your fears and nurturing the paranoia, one day you’ll start producing a great output (though you should have enough budget and courage to spend so much time on building such a defensive up-front design). Whilst this old form of “programming paranoia” is peculiar to minority, new form infects almost everyone. And it’s not that positive as predecessor – it slowly drains power and confidence of masses, and pushes them to find the peace and comfort in something more stable, than coding (e.g., management :) ).

So what is the modern programming paranoia all about? It’s about the fear of not being proactive enough in terms of innovative languages/approaches/platforms, and thus getting out of the programming field.  Glancing over dozens of blogposts concerning personal plans for the next year, you’ll find in 99% of them a point about learning new languages (no matter which problems they address – first of all they should be trendy and have a big market share). Majority of those guys are carriers :) OK, I’m not arguing against learning new languages – like in human languages every new one familiarizes you with completely different culture and mentality, introduces you another type of thinking. But is it equal to be able to speak and have what to say?

Surrounded with a great arsenal of powerful toys, majority looks in their production environments for any problem that generally matches the toy’s usable area, rather than finding appropriate tools to solve concrete existing problems. People all around are highly influenced with portfolio-driven self-education (to put as much technologies to the resume as possible), because they afraid to become unemployed. Jumping into new technologies, they stop climbing the learning curve halfway up, not getting to the point and failing to reach mastership in the field.

Being over-proactive in spending time on anything new (which has a vague chance to succeed in future and gain a critical mass of followers) you shouldn’t stay ignorant of fundamental concepts of software development that are true for all languages, methods and times. Considering the real ROI of the time investments you need be very careful and selective, in order to balance your self-improvement process. Java accused of being obsolete can work for many developers for the next several years as a good bridge to new approaches (though they’re brought to market with a huge delay) – just look through the feature-list of the 7th version (also, from my point of view, Java Web Profile is a movement in the right direction – having a well defined stack of technologies will allow developer to save time on picking a suitable set of tools and start designing the system sooner).

In order to protect against paranoia for a long-term, you should be a broad specialist (which is actually highly valued in Scrum) – not just a guy, who can translate business requirements into a programming language, but the versatile developer, who are remarkable for:

- Architectural knowledge. Cutting long story short, whatever trend you follow, you need architecture and design to address complexity. You should learn from success stories, best practices and patterns. Patterns are not getting from anywhere – they’re based on huge empirical experience and sum of observations in technical fields, human society, nature, etc. The other constantly important aspect  is software life-cycle management;

- Managerial knowledge. Even if you’re one of the few, who sticks to coding and don’t want to change the field for administrative work (thanks God, Peter Principle sometimes fails :) ), you may need to classify your managers (like in “Herding cats” by J. Hank Rainwater) and understand what air do they breath to build strong and productive relationships;

- Domain knowledge. Knowing your domain better you’re not only able to provide interpretation of business requirements into code, but also be an originator of innovations;

Tags: , ,
Posted in Software Development | 4 Comments »

3 reasons to work in a big company

Friday, January 15th, 2010





    I’m getting sick of hearing over and over again how cool free-lance developers are. It’s like a cliche or the form of good breeding to talk about their courage and professional skills. I agree, there’s a certain percent of gifted self-employed consultants among them, but nearly the same percent is true with respect to the entire industry. Free-lancers is not an extraordinary caste. Moreover, the most of talented ones are finally being employed by the major players (sometimes, to hold executive positions). It’s inevitable.
     My point is that you have a better chance to become an eminent specialist working in a big company. The reasons follow:

  1. Working for a big company you learn to think big. You can get experience of complex systems design, as big businesses have resources to build the enterprise-scale solutions. The other case is integration of ERP, CRM, ECM, etc.  that normally implies using sophisticated integration patterns and adoption of SOA practices. Being a free-lancer, it is doubtful whether you will participate in 50 man/year development process or complex enterprise infrastructure roll out.
  2. Big companies invest money in innovations and staff education. A lot of businesses invest money in staff education which includes training camps, conferences, coaching. Employees may have some spare time every week for their own activities unrelated to their day jobs (open source projects, reading, blogging). You can certainly spend as much time for self-education as you want being self-employed, but every second you’re not working, you lose money. Secondly, the resources you can utilize. Big companies can spend huge money to buy innovative platforms and software, you can play with.
  3. It’s easier to keep your work/life balance. As a free-lancer your working day starts early in the morning, when you wake up, and ends, when you go to sleep (or more likely, vice verse). Interrupted with hundreds of coffee breaks, football on TV, having a shower and a million other activities you’ll do, if you stay at home. Unless you’re a time-management guru of a great willpower, you’ll fill more comfortable working in the office and having a limited business day. With a fixed number of hours per week you have less chance of burning out and forgetting how does your wife look like. It’s easier to keep up good performance over a long period of time.

     After 4 years of work for a huge enterprise, I’m not going to change the game shortly as I can see benefits clearly, and most probably I will stick to big firms for the next 4 years.

     P.S. First of all, thanks to everyone who’ve found time to give a feedback on my post. I had plenty of interesting conversations last several days. Here’s the short summary:

  1. Majority of freelancers truly think they’re extraordinary (I heard the phrase “freelance is not for everyone” 100+ times yesterday);
  2. Most of the people, who were against my first point, think that patterns and architecture are just for marketing giving no performance or scalability benefits (like, when you use SOA, REST, “cloud”, “grid” and other buzz-words, it’s easier to sell your ideas to CFO). Afterwards they agree that in some cases architecture is finally important, but add that majority of developers doesn’t know or misuse best practices, anyway. It’s not the argument – majority of people are sluggards (including developers, who’ve came into industry for money), who work 9-to-17, then come home, watch MTV, play computer games, etc. The thing I expected is that many of those who think the architecture is all about marketing have came from the PHP world (well-know source of really bad practices);
  3. Many people doesn’t take into account that freelancing implies a lot of business activities (searching for leads, turning them into opportunities, making agreements, etc.) that steal time you can spend nourishing your perfectionism, if you work for a big company;

Tags: , , ,
Posted in Software Development | 24 Comments »

3 practical advices to survive on the maintenance project

Saturday, December 26th, 2009

     Unless you’re not a natural born maintenance engineer and your main target of the life is helping clients of your company (I’m not sarcastic here – I do believe this branch of development is very important and I respect those guys who support for years systems written in COBOL in early ‘80 for their great patience), maintenance is a burden, and your first thought every morning is how to survive this hell. I understand your feelings, as I’ve spend almost 3 years for this nasty activity in the beginning of my career. If you’re a green horn in development, this kind of experience may be useful for you (getting expert in, at least, some technologies; learning business processes of your company; having fun chatting with the customers),  but if you’re dreaming about software architect position and have grown from your pants, maintenance may be really stressful. To keep your brains from being atrophied (and survive on the maintenance project for the better times) you may follow three simple rules that helped me and some of my depressed colleagues forced to maintain legacy code:

-         Don’t spend more then 70% of the day on routine. It’s already a proven fact that statistically you’re not spending more then 6.2 hours per day effectively (so called “in the flow”). If you’re involved in a hardcore maintenance, sometimes it seems like number of bugs in your bug-tracker is infinite, and when you close one, 2 new ones appear there instead. Concentrate on bug-fixing  for 5-6 hours per day (depending on priority of the opened bugs), and spend the rest of time on analytics and self-education. Automate everything (use continuous integration tools, static code analysis checkers, hand-made scripts, etc.), but be ready that your working day will be longer. You may be sure, you boss will commit to this kind of time investments – you mental health and up-to-date knowledge are the most important during the marathon;

-         Read you favorite blogs everyday at least 30 minutes per day to be connected (better 1 hour), listen to technical podcasts in your mp3 player on the way home (work) and spend not less then 1 hour at home for reading books. My personal preference is to read technical/management blogs at work and domain-dedicated books at home (normal velocity is 1 book in two weeks). “Vertical” understanding of the development process is very important. If the pressure at work is too high (say, last week before going live) it’s acceptable to stop reading for some time, but the first free week I prefer to spend 1 day for looking through all the posts I’ve missed. Spend as much time for reading as possible – always have a book with you to read when you travel, wait for a queue in the bank or any other situation when you’re idle;

-         Have as much practical experience during the working hours as possible. Even if you’re tied to any particular platform or technology and it’s not possible to introduce something fresh and trendy in the system you’re maintaining/developing (enterprise giants are often built on their own home-made frameworks, using legacy approaches to architecture, etc.), you still have a wonderful opportunity to practice new technologies during your working hours outside of the product you ship. To train new approaches I’m writing scripts for automation, installation and migration on Groovy and Ruby, internal wiki’s and support portals with OSGi/REST, etc.;

Tags: , , ,
Posted in Software Development | 3 Comments »