Happy new energy! This is how you make bitrix work with git.

I wish everyone a pleasant new 2015!

May your business flourish, your apps find new users and your customer forget the number of your technical hotline.

Besides, if you should ever happen to work with 1C-Bitrix framework here are some hints how to befriend it with git. If you just try to plain start developing a Bitrix app under git you may encounter few uncomfortable things – since Bitrix is huge (more than 18000 files) ever commit will take long. In most cases I received plain errors instead of pleasant working.

So here what you should do:

First, add this to your local git config

git config --local pack.windowmemory=100m
git config --local pack.sizelimit=100m
git config --local pack.threads=1

You may want to play around with the numbers, just keep in mind following:

Larger window sizes may allow your system to process a smaller number of large pack files more quickly. Smaller window sizes will negatively affect performance due to increased calls to the operating system’s memory manager, but may improve performance when accessing a large number of large pack files.

As seen here

So now which files to exclude from bitrix using rather .gitignore or /.git/info/exclude? Of course I can’t tell you where to put your development files, but it is a good practice not to touch those:


Meaning ignoring them is generally a good idea. This will save you a lot of time! Happy coding. (For the record – we’re using GitLab instead of GitHub for reasons of security, however commands are just the same for both of them)

Next book sneak peak

The next one, „The Software Development Edge“ by Joe Marasco is finally done. Since I’m continuing my more „scientific“ approach on book summarizations this time it turned out to be really extensive. I guess it will take a while to write everything important down.

A little sneak peak on my work regarding this awesome book by Joe Marasco.
A little sneak peak on my work regarding this awesome book by Joe Marasco.

[readolog_blockquote ]One of the main reasons for Joe being able to deliver software in time was his effort to understand every detail of development, every problem occuring, thus, leading to knowledge where you can make right decisions for the whole project movement. This effort is not based upon some kind of magic, but simply upon investing a lot of time in talking with developers.[/readolog_blockquote]

Coders at Work – a book review

So here I finished this work. While being sometimes entertaining, sometimes delivering useful thoughts and sometimes being boring ass stories I found it overall… decent. Just as the last book –  by Robert Glass –  this one falls a little bit after it.

As for now I want to give you a more scientifig approach on rating book if it please you – an idea I grabbed from one of other book’s publisher. I will rate the usefullness of the ideas. How will I perform such a task? Well, clearly subjective, but nevertheless I will try to mark every interesting idea, then divide the amount of pages by the number of interesting ideas. An ideal book may reach far beyond 100% by having multiple impressive text passages… but this percentage rate appears rather imaginary. I guess some values above 20% will indicate a lecture worth your time and thus, reading.

The most appealing thoughs and ideas I will quote directly so you can make a clear picture rather to believe and agree with my view or not. Let’s start with „Coders at Work“.

Short opinion

As with Fallacies by Robert Glass this book comes a bit… outdated. Yes, one should never judge by youth and appear but only by inner values, however reading every chapter (as the author asks almost same questions) about PDP-10, DECsystem-10, IBM 1130 and so on and so forth

Calculating the worth

I started to mark worthy ideas by page number 280. Given the total amount of pages to be 525 it makes 245 pages difference. I counted 13 useful text passages. This leads to 0,0531 or about 5.3%. It may not seem to be very much, thus, leading to a bad overall rate, on the other side, in turn, I liked the thoughts that much, you could easily double the value if you find them impressive too. Since 13 is a good number and not a big one, following you can find all of the parts at once.

Job interviews – seeing the spark

Important on job interviews – it’s not nessesary a good sign if a person can solve logical puzzles. It just shows that they can solve logical puzzles. What is however more important – how attendants deal with technical problems. How do they think? How do they work with someone? Did they do their homework – are the basics on an acceptable level? Can they say „To solve this problem, I need A, B and C. This is how I would use those approaches together (explains it). Maybe I should look up about part C more, but I’m sure this leads us towards a right solution“. Until now you should get a rough idea about the interviewer as a technical specialist. And of course you should ask him or her to write down code on a peace of paper or blackboard. They should know their ABC without Googleing it every time. Additionally they should be – of course – able to work in a team.

Ask people about what they’ve done, what they’re mostly proud about. If they truly went through hell and back for a project they will be passionate about telling you such a story. Let them take the wheel, be initiative. The most important part here is not only letting them tell you what they’ve done, but although how.

If interviewers can’t tell you anything they’re interested in (it has not to be only about professional treats) they probably won’t show any performance in your project either.


The ability to think stepwise makes us more adaptable to the outer world. And you don’t need any programming skills for that. There is a difference between – „Oh, our cabinet door won’t close. Let’s take a look – here, a screw is missing“ and „Door won’t close. Let’s call someone!“.

Project leading

A good project leader should know the goal – if you are self-confident about what you’re doing it will fall easier for others to accept you and to follow you. This self-confidence widens out to the whole team, whole project which leads to a complete win-win situation for everybody. However be alarmed not to take too much care of everything as it may drive away the motivation – why put any effort in this if it’s all clear anyway – just sit back, relax the reigns in such case.

To put it short – know what you’re doing, don’t interfere, but be technically educated so you can give adequate feedback.

In chapter 14 I encountered again same thoughts. Additionally there was this one – project revisions. Each team member has had to present their part of work. And the goal was to get the part where the declarator wasn’t sure about. Sure, it sounds like an examination at the university, but the clever trick behind it – get company’s best minds to review your work. This is turbo mode help.


The bigger your programs are, the more you need to care about interfaces. How will this connecting link between those two program parts look like? What’s the input? What’s the output? Which part of the task should be solved by which part of the program?


Proper documentation should be regarded as the same kind of art as programming itself. Most of the time it’s either too sparse or too filled with unnecessary details. Bringing together right amount of information and in right form takes a lot of time and invested time should be considered same as for writing code.

Good code, bad code

Thrifty definition of good code – if you need to add some functionality, you do it in just one place, while bad code leads you to changing dozens of places.

A bit about talent

In the middle aged reading and writing were regarding as special talents granted only to the chosen. In the beginning of the 20th century same could be said about art – creating films, writing books, making music was a prerogative for selected people. This is why learning about informational technology is important for everyone – like reading and writing earlier. Computers just extend our creational possibilities, enabling more and more people concentrate on what they really like to do.


Don’t be too clever. Sounds harsh? Do not spend weeks or months to increase some algorithm efficiency if this algorithm will only trigger once in a while in your program. You may even do worse by trying your best, since your program will become more and more difficult.

Beautiful strings

Today I found an interesting challenge on CodeEval – it’s from Facebook Hacker Cup 2013 Hackathon. At first I had my issues with understanding the task. Here’s the description:

[readolog_blockquote ]Given a string s, little Johnny defined the beauty of the string as the sum of the beauty of the letters in it. The beauty of each letter is an integer between 1 and 26, inclusive, and no two letters have the same beauty. Johnny doesn’t care about whether letters are uppercase or lowercase, so that doesn’t affect the beauty of a letter. (Uppercase ‚F‘ is exactly as beautiful as lowercase ‚f‘, for example.)

You’re a student writing a report on the youth of this famous hacker. You found the string that Johnny considered most beautiful. What is the maximum possible beauty of this string?[/readolog_blockquote]

Your input are few lines of senseless strings. Output should be a number, a sum of values for every letter. In other words this challenge can be described as following:

[readolog_blockquote ]Count encounters of every letter. Since you can use every number only once and your goal is to produce the biggest possible sum you should assign the bigger numbers to letters, which occur most often.[/readolog_blockquote]

If there are letters with same presence amount it makes no difference to which you assign the exact number. Let’s say you have three ‚a‘, three ‚b‘ and three ‚c‘. If you decrease your assignment by one each time it won’t matter to which exact letter you’ll assign exact number, since the math is 3*26 + 3*25 + 3*24 and it doesn’t care to which letter ‚belongs‘ the number ‚3‘.

So here is my code. I’m sure it can be done in a one-liner, however I wouldn’t consider this challenge as trivial, therefore I’m a bit proud of my solution.

def largestHashKey(hash)
  hash.max_by{|k,v| v}

def letter?(lookAhead)
  lookAhead =~ /[[:alpha:]]/

File.open("beautifulStrings.txt").each_line do |line|
	charFrequency = Hash.new {0}
	line.split("").each do |char|
		if letter?char then charFrequency[char.downcase] +=1 end
	# Now iterate through all hash values, find maximum, assign 26 to it, then maximum-1, assign 25 to it and so on

	i = largestHashKey(charFrequency)[1]
	sum = 0
	stringValue = 26

	while i>0
		if charFrequency.key(i)
			charFrequency.each_value do |value|
				if value == i
					sum += i*stringValue
					stringValue -= 1
		i -=1
	puts sum


Nobody knows what it’s like… to be the PM.

Thankeee’sai for waiting. This post took a bit longer than it should have. But since I’m reading a real heavy one – Coders at Work, next book review will follow not so fast. However I want to share another few thoughts with you.

PM Tips – Part 1 – sales, talking, clients

I was wondering – are there any concepts that make a difference between a good it project manager and a mediocre one? Was I able to make this transfer or am I still somewhere deep below the ocean?

Let’s try to take a look from a bird’s view – if it’s possible.

[readolog_blockquote ]You will have clients[/readolog_blockquote]

That’s the sad truth. You will have to deal with clients. This means – oh gosh! – talking to them, persuading them, selling services to them, explaining stuff to them. By no means you should feel like a sales manager, but you will always have verbal relationships, like it or not. You may not like it, you may even hate it and be worst misanthrope ever walked on earth, but you’ll have to deal with it. Even if you work as technical manager, or CTO or just for a company where clients, paying your company, are cleared by other people, regard your superior as your client.

Do the experiment, you will discover they act just the same… they wont understand most things you say, so you’ll have to explain, you’ll need to persuade and sell them everything (you need new chairs for your team? It’s kind of a sales process too!). This part of PM tips doesn’t suggest that you should be or have experience as active sales manager, however you should get used to similar sales processes.

[readolog_blockquote ]Clients don’t know what they want[/readolog_blockquote]

Most of the time this statement is true, unfortunately. On the other hand… this is 70-80% what you’re paid for. See why you should get familiar with your clients? Because it’s not completely true, that they don’t know what they want, in most cases they simply don’t know how they want it (meaning the software you’re creating) done. Some research should be done to extract exact numbers, but I would guess the ratio 40%-60%.

[readolog_blockquote]Experience matters[/readolog_blockquote]

If you’ve done a few online shops you’ll probably know what to suggest to your customer next time. You won’t know every detail, your client either, but in this case your both percentage knowledge doesn’t work multiplicative, but convergent, thus, creating desired result.

How to get your team organized with 5$ per month

Some time ago I had a pleasure (no irony intended!) to start working in a company with no established developing process at all. There was no issue tracking, no communication tools, no code hosting…nothing (nothing but a Russian Bitrix system, but it doesn’t count, since it’s awful and nobody was using it). Now I want to share with you one of myriads of possible approaches. As it happens we pay only 5$ per month to make it work.

How to start?

First of all you’ll need a webserver. We decided to pick up the cheapest DigitalOcean droplet which is available for exactly 5$ per month. You can pick Linode or any other server, where you’ll be granted full root access. DigitalOcean comes with a fancy possibility to create a Redmine-Droplet in just 55 seconds, this is just what we did.

Where to host code?

Trust me, even if you have just one developer you better start using version control. Github is the most common service just to do so, however if you can’t afford sharing your code with the community you got to pay for private repositories. A wide known alternative would be Gitlab, which not only allows you to host the service on your own machine, but also doesn’t charge you for creating private repositories if you continue using on-demand version. I didn’t manage it to install Gitlab on our 5$ droplet (maybe I’m just not gifted… maybe it has something to do with recommended RAM size of 2 Gbyte and two unicorn worker units to be able to handle http requests – 5$ droplet got only 512 MB RAM), so we’re using private on-demand repos. However if you manage to install gitlab on your machine the following routine will be much easier, since pulling from Gitlab won’t requre any hooks as it will be on the same machine as Redmine itself.

How to connect them?

You’ll probably don’t want maintaining two systems at a time. This is where so called hooks come in play. You can try and install https://github.com/phlegx/redmine_gitlab_hook but for me, although I set up (at least I suppose so) everything correctly, it didn’t work.  What I did instead was following:

  • create an ssh-key on your server, where redmine is hosted (since chances are you won’t be able to copy the key to your clipboard you’ll need to send the file to your local machine first via scp
pbcopy < .ssh/id_rsa.pub
scp your_username@remotehost.edu:foobar.txt /some/local/directory
(I never know how to connect to my local PC, so instead I connect to remote machine and download the file)
For example - scp root@ /directory_created_for_the_key
  • now comes a tricky thought – since Redmine hooks only its local repos but your local environment is another one, we need a workaround. As depictured below you need to set up your remote origin as gitlab
git remote add origin git@gitlab.com:your_project/your_repo.git
then you push using 
git push -u origin master
Gitlab Redmine connection visualization
Gitlab Redmine connection visualization
  • To keep your Redmine repo up-to-date, you’ll need, first of all, to create one (on the Redmine server) – simply git init /home/redmine_projects/project1
  • Create a cronjob – nano /etc/cron.d/sync_repos
  • Repeat the line for each repository (app should be the owner of the repository. In our case it is „root“)
    */5 * * * * app cd /path/to/project.git && git fetch origin && git reset --soft refs/remotes/origin/master > /dev/null
  • Wooosh! You’re done! Now every push will be visible just 5 minutes thereafter in your Redmine repo-tab.
Now your repo on the server where redmine is installed is always up-to-date (with a 5 minute delay).
Now your repo on the server where redmine is installed is always up-to-date (with a 5 minute delay).

The mythical man-month

Would you call me arrogant for retitling this book as „Mythical technology no one cares for now“? You have the right to do so. However I want to provide some argumentation for that if it please ya.

To tell long story short – the main thesis of the title, that adding people to late projects will delay them even further is mentioned in the second chapter of the book. Until the 17th chapter you’ll deal with ancient stuff about OS/360 (what the heck is that?) and IBM 1771, Machine 881295, coding languages so ancient they make Greek Gods seem modern. I have no issues with people wanting to learn from the very basics. But generally this is not effective. If you want to dig a hole in your garden you go to the supermarket, buy a shovel and do the dirty work. You won’t, however first go and buy seeds, plant a tree, watch it grow, go to the mines, prospect the ore, process it, create the shovel blade, cut your tree (same procedure for the axe by the way?), make the handle, connect the blade with the handle and…finally dig!

Yes, you could do that, but it’s just not effective. You just rely on people who create this stuff for you. It’s important to have a basic knowledge (that a shovel blade made from paper might seem as a bad idea) but still you need other qualifications for digging a good hole.

Is this post just about nagging or will there be something constructive?

It’s the same with this book – not only it gives the reader such outdated information (ok, ok, it was written few years ago, 1974), but it’s also written so damn complicated and jumps from one extreme to the other – it’s either written too general (although I’m not the dumbest person I wasn’t able to understand) or so heavily loaded with detailed information about things one one knows they even existed without even explaining it!

You see, this is the main point – if this book should be an introduction it clearly lacks all introductional features as explaining material. If this book is a summarization of some facts… well I guess it was good back then, but now I don’t see the point of it. The mythical man-month suggests that this book is about people, about working with people but it’s just a practice report from over 40 years now. I might seem to brag here often about the release date, but you know what – other authors show that this is clearly not an issue at all, just take a look at DeMarco & Lister (if you haven’t read my article about their book – just skip the article and go buy their „Peopleware“)


Let’s consider two quotes from the book:

Consider the linkage editor, designed to load separately-com- 
piled programs and resolve their cross-references. Beyond this 
basic function it also handles program overlays. It is one of the 
finest overlay facilities ever built. It allows overlay structuring to 
be done externally, at linkage time, without being designed into 
the source code. It allows the overlay structure to be changed from 
run to run without recompilation. It furnishes a rich variety of 
useful options and facilities. In a sense it is the culmination of 
years of development of static overlay technique.


The unexpectedly hard part of building a programming system is 
system test. 1 have already discussed some of the reasons for both 
the difficulty and its unexpectedness. From all of that, one should 
be convinced of two things: system debugging will take longer 
than one expects, and its difficulty justifies a thoroughly system- 
atic and planned approach.

You take the meaning? First quote – my wtf moments: what is linkage editor? Cross-references? Program overlays? Overlay facilites? Structuring to be done externally? There is a lot of information in this text. But is it useful?

Second quote – a hell lot of text for saying… debugging is hard?

My advise at the end, if you really want to read this book – skip chapters 4-13 and chapter 15 and 16. Just do it, you won’t miss anything you’ll require for a start of your career. Basically in chapters 18 and 19 (of the second revision) the author summarizes his own book, commenting own statements 20 years later (revision was published in 1995).

[schema type=“book“ url=“http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?ie=UTF8&qid=1412691597&sr=8-1&keywords=mythical+man+month“ name=“Mythical Man-Month“ description=“This is the official description from Amazon, don’t come hereafter and complain – I warned you! Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.“ author=“Frederick P. Brooks Jr.“ publisher=“Addison-Wesley Professional“ pubdate=“1995-08-12″ edition=“2nd Edition“ isbn=“858-0001065793″ paperback=“yes“ ]

Facts and Fallacies – trust them or prove them wrong?

Facts and Fallacies of Software Engineering is without a doubt s decent book. It could be even considered as a good book, but I – fully subjectively and emotionally – just cannot do it. While the main thesis can be summarized as following

Programming is too complex to be measurable, deal with it

and while the facts themselves are quite interesting, I can’t get rid of the feeling that the purpose of the whole book was to proclaim the great goodness of the author. It may sound a bit harsh, but reading on almost every page

as shown in blah-blah [Glass, 19xx] or stated in blah-blah [Glass et al., 19xx] etc. etc.

makes me wonder – is there anything besides author’s work that’s worth mentioning? Will ever a book have a chance to be regarded as a reference for our Robert Glass? I doubt that. Additionally a lot of „facts“ are based upon own researches or researches of a very small groups, which is not bad per se, but makes statements like „list of derivative requirements grow by 50 times“ seem not a great deal trustworthy. Why 50? Why not 49 or 20?

I don’t want to fully degrade the book since it’s nevertheless pretty decent and now I’ll explain why. The answer is pretty simple – some statements are indeed to such an extent obvious that they may be truly regarded as facts. A few of them I’d like to highlight here in a shortened and combined version.

Every project evaluation is made by false people and at wrong time without correcting the vector.

This is basically the essence of all failure. True is, most of the time the work is estimated by managers or even product owners without involving developers at all. In better cases teams play planning poker, but usually it is discarded because it takes so much time „we can’t afford to invest, better start earlier and give us just an estimation“. In 99.99% of the cases your estimation as manager will evolve into a… real value upon which everything will be based. Deadline? You said project will be done in 3 months, so deadline is now+3 months! No one will ever care to adjust the evaluation or, more correctly expressed, care to accept your changes willingly.

The difference between worst and best developers is a big gaping hole, the difference in their salaries, however, not.

First of all here we have numbers telling us (numbers lie, you know?) that the difference is up to 28 times – again, I’m not a big fan of such numbers, but the essence of the statement is quite true – you gain a lot by hiring best people, because the salary you’ll pay to worst people will come back to you twice – you’ll pay more at the end of the day, because you’ll need more of that sort of people and you’ll deliver mediocre products because those people won’t be able to produce good software.

Supporting your software will cost you up to 80% of invested capital.

Glass mentions numbers span between 40% and 80% and whether you agree or not with those numbers, we all can’t deny the fact. It’s simply true, that your every neat customer will come to you after project „is done“ and demand – hey, can I have a button here, a function there? Trust me, and if you don’t trust me, trust Glass – this will eat, no, this will devour and annihilate your time.

[schema type=“book“ url=“http://www.robertlglass.com/“ name=“Facts and Fallacies of Software Engineering“ description=“You can trust the facts blindly or try to prove them. Let this short summary be an introduction to this book.“ author=“Robert L. Glass“ publisher=“Addison Wesley“ isbn=“5-93286-092-8″ paperback=“yes“ ]

Keep in mind – the deadline is your pal

Usually there are posts and books (a great one though – „The Deadline: A Novel About Project Management“) about managing deadlines, however this post will be about setting them – even for yourself.

Are you nuts? Why should I willingly determine a deadline if there is no pressure from outside?

If you happen to be one of the more luckier people out there who don’t get stuck with deadlines from outside consider yourself still in the same boat. The answer is simple – there are always time limits. If someone says otherwise, slap them. A-l-w-a-y-s, meaning at any given point of time there is someone who will ask you after a few weeks/months/years


And believe me, you want to avoid that situation at any cost. So if you’re working in a tiny-shiny-fancy-nancy startup, realize – they will ask you. And sooner you get your project organized the better.

If nobody provides you any tools, information or cooperation at all, remember – where there’s a will, there’s a way. At the end of the day they paying you exactly for it – for you getting things done regardless of the „how“. So my advice – get yourself a few sheets of paper and a pencil, start a prototype, draw a silly face, a cartoon, then try to write down your project’s goal. Can it fit in one sentence? No? Think again. Eat. Sleep. Rave. Repeat. Try to think what components is the project made of – are there reocurring modules? Can you extract some pages?

Decomposition is the keyword

Work top down, from goals to tasks which can be estimated. This estimation gives you your ace card. The more time you got the deeper you should get, meaning if you have just a vague goal you could guess it as 5 months or 5 years, if you have 100 tasks each guessed by 4 hours, you get 400 hours, 200 working days meaning somewhat 8.5 months. Having such a value will give you a much better situation because it’s based on smaller estimations where even a 100% volatility won’t hurt much (the probability of having all 100 tasks estimated wrong by half is incredibly low).

Peopleware by DeMarco and Lister

If there is one core sentence that could summarize whole book, it would be – even in the IT field most problems arise around people, not around technology. And you can solve those problems by addressing at people’s issues, not implementing another METHODOLOGY. This leads to the main concept of peopleware – caring for your team, trusting them and creating best conditions for creative work.

Well, it’s clearly a pity, that I read this book that late in my path as a PM, in fact if you want to join the journey, make sure to read it first! Don’t even bother reading further my summarization since it will be all like how great this book is. And indeed it is.

Simply said, just read this book and skip my post.

If it’s so simple, why are a lot of projects failing, why can’t we just make this book a METHODOLOGY, a standard for every IT company out there? Well, because it’s unpleasant. A hell lot of managers (including myself) love to operate with numbers, measure story points, velocity, team performance because they trust numbers more than feelings. You can explain a number, but in most cases you won’t be able to explain a feeling. And your boss won’t accept a feeling either. And your team won’t provide you any numbers, like – hey, I’m feeling down today because the loudness level raised by 20%, thus, lowering my productivity by 15%. And and and.

You should care about your people and create or try to create best possible environment for them (simply try to rhyme peopleware with peoplecare). Because there is no mass production in such an intellectual field of work. Coding is not like working along an assembly line. You will need a „flow“. It’s not trivial to get into the flow-state, it takes some time and every interruption will force you to leave the state.

If you need the shortest summarization of the book, here we go – find right (means qualified) people, infect them with your idea, create best possible conditions for their work, leave them alone.

Here are few total no-go’s that no one should ever do to his/her team:

  • Huge open spaces – no, no, no and again no. When your brain is working you need silence. That’s as simple as it is. People listening to music or other environment’s sounds can work too, but they can’t create new, alternative solutions, they can just do their routine work.
  • Engulf your people in beaurocracy  – just think over it – do your really need a daily report? If you answer is ‚yes‘, think again. And again. And then again. If the answer is still ‚yes‘ you haven’t found the right people you can trust.

Why do you even mind mentioning short phone calls and furthermore call such distractions evil? Are you out of your mind?

Do you like math? I bet you do, at least numbers, since we all love numbers. Let’s say there are two employees, both instructed to do one task, consisting of several sub-tasks and few random phone calls. Let’s even assume they require same amount of time to carry out the work and need approximately about 5 minutes to adjust between some interruption with just one slight difference – we will place a phone near the first employee while leaving the second one completely exposed to silence handing out the phone to him at the end.

[bs_row class=“row“]
[bs_col class=“col-xs-6″]

Subtask 1 – done in 5 minutes

Subtask 2 – done in 5 minutes

Subtask 3 – done in 5 minutes

Subtask 4 – done in 5 minutes

Subtask 5 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 1 – 5 minutes

Phone call 2 – 5 minutes

Phone call 3 – 5 minutes

Phone call 4 – 5 minutes

Phone call 5 – 5 minutes

[bs_col class=“col-xs-6″]

Subtask 1 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 1 – 5 minutes

Adjusting time – 5 minutes

Subtask 2 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 2 – 5 minutes

Adjusting time – 5 minutes

Subtask 3 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 3 – 5 minutes

Adjusting time – 5 minutes

Subtask 4 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 4 – 5 minutes

Adjusting time – 5 minutes

Subtask 5 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 5 – 5 minutes[/bs_col]


Holy cow – 95 minutes vs. 55 minutes – that’s an increase of almost 100%!

Now imagine what happens when a phone is always in reach of your employees‘ ears (even if they don’t have to answer it directly, for every call you can add some adjusting time. Additionally, by all means 5 minutes is a value suitable for a very professional employee, for your more-than-average protege you may increase this value by 100%-200%.

The journey begins

Oh, hello there! You finally somehow ended up being in my corner of the world wide web right now. What can you expect here? Well, a lot of things. Or maybe not that many… depends on your expectations. Basically this is my blog about (big part) project management and (smaller part) development. I do indeed strive after evening out this imbalances but I can’t promise it yet.

So again – what is it all about? Since I’m working as project manager and being a hobby-like developer I will post from time to time interesting ideas or summarizations of books, so the main idea of this blog is – if you are a beginning PM you could just read through every post from the very beginning and at the end be an already advanced PM.

But why should anyone read all or any of your posts if he/she could could just buy the books? Well, first of all – books are not for free, my blog is. Second, even using a strong filter like colleagues with years of experience you can end up reading some real crap. Third, you can use my posts just as a kind of appetizer – if you liked it, feel free to buy and read the book. Fourth – maybe you’ll find some coding stuff interesting too.