I found today a list of things that might hit programming productivity. I liked the list and even though that is a not a fully analyzed and formal study on how these things happen, I agree with them to a certain extent and seems to be a pretty good observation of the environment that we as developers, experience.

Here:

The 15 worst ways to kill programming productivity

Meetings, know-nothing managers, productivity metrics -- here's what's threatening to slay the next generation of great software

By Peter Wayner, Contributing Editor, InfoWorld | Nov 25, 2013

 1. Meetings.

 3. Trying to measure productivity.

 4. Prima donna developers.

 5. fix it later aka "technical debt".

 6. Nonprogrammer managers.

 7. Programmer managers.

 8. Macho programmers.

 9. Selfish  or cowboy coders.

10. Poor documentation.

11. Slavish devotion to documentation.

12. Distraction-rich environment. 

13. Cultural fit. 

14. Clinging to legacy tech.

15. Lust for the latest and greatest. 

  

Some CSS basic standard

Standards CSS - LESS

Règles de déclaration des variables

• Utilisez pas le namespace du core pour nommer une variable. Pour des composants au niveau des outil, ajoutez le namespace correspondant à l'outil.
• Les variables de contexte du composant sont déclaré avec le préfixe de contexte suivi de deux traits d'union.
• Propriétés toujours en fin de déclaration
• Les déclarations de variables suivent une imbrication en cascade. Seuls le nom du composant et la propriété CSS sont requis.

Exemple :

// CORE component variable name
[CONTEXT]--[COMPONENT]-[EXTENTION]-[PSEUDO CLASS]-[PROPERTY]
@reverse--componente-name-extention-property

// TOOL component variable name
[CONTEXT]--[TOOLNAMESPACE]-[COMPONENT]-[EXTENTION]-[PSEUDO CLASS]-[PROPERTY]
@reverse--adb-memberdataupdate-componente-name-extention-property

Règles de déclaration du composant

• Le nom du composant doit être unique. Assurez vous de faire un recherche sur les fichiers LESS de la solution avant de le nommer.
• Utilisez de la classe à la place du id pour la identité du composant.
• Fournissez toujours des renseignement sur les composants, surtout de particularités nécessaires à la compréhension, qui ne sont pas claire sur le code.
• Les déclarations doivent être toujours dans le namespace #adb-webtools-container.
• Déclarez pas le margin au composant pour ajouter une distance distance vers son parent ou ses fréres doit être, ça doit être déclaré au contexte.

Syntaxe du code du composant

//*****************************************************/
//  Component name
//*****************************************************/
/*
    Component description
    ...
*/
@my-component-color: 1px solid @color-g6;
@my-component-border: 1px solid @color-g6;
@my-component-active-color: @color-acive;
@reverse--my-component-color: @color-g7;
#adb-webtools-container {

    // Component
    .my-component {
        color: @my-component-color;
        border: @my-component-border;

        // Component elements
        .my-component-title {
            ...
            
        }

        // Component extension/states
        &.my-component-active {
            color: @my-component-active-color;
        }
        &.my-component-medium {
            ...
        }
    }

    // Contexts
    .reverse{
        .my-component {
            color: @reverse--my-component-color;
        }
    }

    // Print mode
    &.adb-webtools-print {
        .my-component {
            color: @color-black;
        }
   }

    // Browser support
    &.adb-webtools-browser-internet-explorer {
        .my-component {
            // Fix
        }
    }
}

LESS client



Variables

Changer les variables toujours au début du fichier less.

@color-primary: #DDD;



Pour de variables spécifiques à l'outil utilisez le namespace de l’outil comme préfix.

Ces variables doivent être déclarées dans le fichier Less core de l’outil avec un valeur par default.

@memberdataupdate-section-boder-color : @color-primary;
Utilisez toujours de variable du core pour des propretés standardisées.



color: @color-primary;
font-size: @font-size-sm-a;
@media @media-sm-max-width{
    padding: @layoutHorizontalSpacing;
}
Namespaces, class, id, print


Les déclarations des classes et des ids doivent être toujours dans le namespace #adb-webtools-container.
@color-primary: #DDD;

#adb-webtools-container {
    
    // CORE prefix adb-webtools
    // Overridez JAMAIS une class or id du core. Discutez avec le responsable au besoin.
    .adb-webtools-header{
       color: red;
    }

    // NAMESPACE
    // Utilisez le namespace de outil pour déclarer des classes et id spécifiques à l'outil.
    // Jamais utiliser le namespace du core adb-webtools pour ça.
    // Utilisez des classe pour de composant au section générique.
    .adb-memberdataupdate-my-component {
        color: @color-primary;
        font-size: @font-size-sm-a;
        @media @media-sm-max-width{
              padding: @layoutHorizontalSpacing;
        }
    }
    
    // CONTEXTE
    // Utilisez des id de section pour donne un contexte au changement.
    #adb-memberdataupdate-section-x {
        .adb-memberdataupdate-my-component {
            color: @color-secondary;
        }
    }

    // PRINT MODE
    // Utilisez la classe adb-webtools-print liée #adb-webtools-container 
    // pour déclarer le changement de style au mode print/pdf.
    &.adb-webtools-print{
        .adb-memberdataupdate-my-component {
            margin: 0; 
        }
   }
}

Bits from the book "97 Things evey project manager should know" from O'reilly

This is a list of some of the subjects I felt more close to my vision of project management.
Of course it is not an extensive list and tried to put together a small one. So there might be other gems not being considered in this list. My suggestion would be to read book, it's not that long of a read and should be something you can finish on a week of late night/before bed reading session. Here I only put some of the phrases that catched my attention and not the whole piece.

1. Developer productivity: skilled versus Average. Neal Ford. P. 26.

"Let's debunk some of the myths about developer skills for project managers who have been assigned for the first time to software projects. Understand  that really good software developers are much more productive than average ones...The point is, a skilled programmer isn't  just a little better than an average one; the difference is huge."


2. Managing  Human Factors in IT project management. James Graham. P. 48

"As software project managers, we obsess over the scheudle details. We huddle with our teammates to try to anticipate risk factors that could derail our projects. We crunch numbers to see if we can squeeze the project deliverables out of the allocated budget. But we tend to overlook, or ignore, the most prevalent cause of project failure: the human factor".

Nsubstitute basic test & TDD note

I have been working on creating unit tests and to some extent also doing some TDD. I think TDD at the beginning when you come from a background of classical development of develop-first test-later, is a change that might not come so naturally the first time you tried. However the more you try to understand the test driven model the more you actually realize how you can benefit from thinking on what is the purpouse of you code and the how to fix it. Refactoring is a big part of TDD and something I think I am used to but never thought of it like a natural process to deliver a more robust design based on testing while coding. So here is a small example on nsubstitute:

Here we have the beginning of the class to test a cube iterator.  In the image below I created a class to fill the values on a setup mode to be called when the data is about to be treated([TestInitialize]).

The method Setup is where I am going to setup the mocking for my classes.









Finally I test my values on a Given-When-Should pattern so I know what I am passing what method/action I am invoking and what I expect as a result. Nsubstitute handles some easy  fluent methods.