Productivitatea in programare

Posted In: , . By Bogdan

O perspectiva asupra a ceea ce inseamna programare productiva si (i)relevanta cantitatii ca metoda de evaluare, via

Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on. It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.

The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”

 

Herding cats

Posted In: , . By Monica

Famous quote: Managing IT people is like herding cats. by Unknown author


 

Calm voice of reason

Posted In: , . By Monica

Am gasit intr-un articol un citat care mi-a placut( in context se referea la project management si controlul unui proiect care pare ca nu se mai termina) :

As project managers we have to be the calm voice of reason. We have to revert to the fundamentals of good project management and not let the situation drive us to the wrong behavior. If we stick to the basics, we can at least minimize the damage.

Meditand mai bine, cred ca se aplica (sau ar trebui sa i se aplice) oricarui manager.

 

2 feluri de oameni

Posted In: , . By Monica

Wulffmorgenthaler.com

Atat de adevarat :)

 

Intrebare si raspuns

Posted In: . By Monica

Question :
Open-heart surgery can be viewed as a project and a program. Why?

  • A. Because heart usage does not have a definite ending, the project is also a program.

  • B. Because the surgery requires a tremendous amount of resources, it is considered a project.

  • C. The surgery is a project; the ongoing support is a program.

  • D. Getting the skills and resources is a program. Scheduling and coordinating the skills and resources is a project.



Answer :
Answer C is correct. Open-heart surgery has a beginning and ending and therefore constitutes a project. The post-surgery maintenance and ongoing support is a program because it does not have a definite ending to the treatment. Answer A is incorrect because the heart usage timeline does not determine whether it is a project or a program. Answer B is incorrect because resource allocation does not determine whether the surgery is a project or a program. Answer D is incorrect because getting the skills and resources is not a program.

 

...apa e de vina!

Posted In: , , . By Monica

In sfarsit pot da vina pe ceva pentru agitatia si bataielile din picior care exaspereaza pe oricine sta la masa langa mine.Se pare ca apa la sticla m-a afectat pe viata :(

O campanie virala foarte simpatica de care am aflat via http://mydaysof.com

 

Scrise mai mult ca note to self pentru momentele in care sunt mai optimista decat e cazul sau in momentele in care am impresia ca daca totul e clar pentru mine, atunci e clar pentru toata lumea.

Riscuri si controlul lor

  1. Ce anume din ce presupune acest proiect este nou pentru echipa de proiect sau nu a mai fost facut in mod asemanator?

  2. Ce resurse cu experienta sunt disponibile pentru a oferi suport in cazul unor dificultati?

  3. In cazul in care au fost dezvoltate proiecte asemanatoare, care au fost principalele 3 dificultati intalnite pe parcursul acestora? Privind in urma, ce masuri de prevenire ar fi fost indicate?

  4. Ce probleme ar putea interveni la nivelul fiecarui task care sa intarzie finalizarea acestuia?

  5. Care sunt dependentele fiecarui task (externe proiectului sau nu) fara de care acesta nu poate incepe sau nu poate fi finalizat?

  6. Care ar fi metoda potrivita de raportare (si la ce interval) care sa asigure semnalarea in timp util a intarzierilor?
Comunicare si intelegerea cerintelor
  1. Care sunt cerintele formulate ambiguu sau care ar necesita explicatii aditionale? Care parte a cerintei poate fi considerata interpretabila?

  2. Poti sa imi reformulezi cerinta (sau sa imi descrii livrabila asociata) pentru a ne asigura ca avem aceeasi viziune asupra a ce trebuie implementat?
Ultima intrebare poate avea uneori niste raspunsuri uimitoare :)